claude code 辅助编写错误处理代码时对异常类型的合理覆盖

一、先说结论：Claude Code 不替你写代码，它帮你构建“异常心智图”

在使用了接近半年的时间后，我总结出一个核心判断：Claude Code 在错误处理上的最大价值，不是替你生成一段 try/catch 代码，而是它可以帮助你建立一个覆盖整个调用链路的“异常心智图”。 这张图由三部分组成：

1. 明线异常：你自己能想到的，比如网络超时、数据库连接失败、文件不存在。
2. 暗线异常：你没想到但客观存在的，比如第三方 SDK 在特定版本下的某个冷门错误码、并发读写下资源竞争导致的 ConcurrentModificationException。
3. 边界异常：介于“应该捕获”和“应该让它崩溃”之间的灰色地带，比如支付回调里的签名校验失败到底该算业务错误还是系统错误。

传统方式下，你写完一个函数，然后开始手动补 except 块，这个过程完全依赖于你的个人经验和对这个项目的熟悉程度。经验不足的开发者写出来的异常覆盖，通常只能覆盖明线异常的 60%，暗线异常几乎为零，边界异常一律统一处理，这是生产事故最大的隐患。

Claude Code 改变了这个流程。现在我的做法是：先不让它写一行代码，而是让它根据我的函数签名、外部依赖、数据结构，生成一份“可能失败点清单”。这份清单本质上就是一张我脑子里原本应该有的心智图，只不过 AI 帮我把这个过程加速了 10 倍。

举个例子。我在一个订单系统里有一个方法叫 processRefund，它要做的事情是：

• 调用支付网关的退款接口（外部网络调用）
• 更新订单状态为“已退款”（数据库事务）
• 发送退款成功通知（消息队列）

如果是手写错误处理，我大概率会这样写：

try:
gateway.refund(order_id, amount)

db.update_status(order_id, 'REFUNDED')

mq.send_notification(order_id, 'refund_success')

except GatewayException as e:

记录日志，标记订单为退款失败

except DatabaseException as e:

重试？回滚？

except Exception as e:

兜底

...

这种代码表面上看没什么大问题，但它遗漏了至少三种致命情况：

• 退款接口调用成功，但数据库更新失败：此时用户已经被扣款，但订单状态没有更新，客服会接到“钱扣了但订单没退”的投诉。
• 退款接口调用成功，数据库更新也成功，但消息队列发送失败：用户收不到通知，以为退款没成功，重复发起退款。
• 支付网关返回的不是 GatewayException，而是一个底层的 ConnectionError：你根本捕获不到，程序直接崩掉。

Claude Code 能在几秒之内把所有这种异常链路列出来，前提是你得用对方法。

二、我在三个真实业务场景下的完整实验过程

为了验证 Claude Code 在错误处理上的实际能力，我从团队的项目里挑了三类最典型的场景，做了三轮对比实验。每一轮我都记录了：传统手写模式的异常覆盖清单、Claude Code 辅助生成的异常覆盖清单、以及最终生产验证后的遗漏情况。

场景一：外部支付网关调用的异常覆盖

这是最敏感的场景，因为涉及资金。我们对接的是一个聚合支付服务商，SDK 文档里列举了 12 种标准错误码。我让一位中级工程师先独立写出错误处理代码，他最终覆盖了 8 种异常类型，遗漏了 4 种，包括：

• duplicate_order_id：重复订单号，这在并发提交时容易出现。
• channel_maintenance：通道维护，支付服务商临时关闭了某条支付通道。
• risk_control_block：风控拦截，用户账户被风控系统自动拦截。
• amount_limit_exceed：单笔金额超限。

然后我用 Claude Code，给它的上下文是：这个函数的目的是发起退款，退款参数包括订单号、退款金额、原交易流水号；调用的第三方库是 payment_sdk；这是 SDK 的官方文档链接（我把文档的 HTML 页面喂给了它）。 我没有告诉它需要覆盖哪些异常，只问了它：“请列出所有可能导致此函数执行失败的异常条件，按发生概率排序。”

它返回了 16 种异常条件，覆盖了工程师遗漏的 4 种，还多出了 2 种我们完全没想到的：

• caller_ip_not_whitelisted：调用方 IP 不在白名单，这在我们的预发布环境恰好发生过。
• refund_amount_exceeds_original：退款金额超过原始支付金额，这听起来很蠢，但在部分退款多次后的累加场景下，逻辑写错是完全可能的。

这里的差距不在于 Claude Code 比人聪明，而在于它在分析外部依赖时，会系统地扫描 SDK 文档里所有可能的错误码定义，而人只会凭经验和记忆。

场景二：数据库事务中的异常处理链

这个场景的难点在于，异常处理不是独立的，而是跨多个操作的一致性问题。我在我们的订单模块里有一个典型的“库存扣减+订单创建”操作，它涉及两个数据库的两次写操作，中间还有一次缓存的更新。

传统写法下，工程师会在最外层包一个 @transactional 注解（Java）或者手动 begin/commit/rollback。但真实的问题是：当库存扣减成功，订单创建失败时，库存已经减少了，但订单没生成，这会导致库存“凭空消失”。

我问 Claude Code：“请分析这个函数在事务执行中可能出现的部分失败情况，特别是那些会导致数据不一致的异常路径。”

它给出的分析让我吃惊。它不仅指出了明显的数据库异常，还指出了：

• 数据库连接池耗尽：在库存扣减成功后，尝试获取新的连接来创建订单时，可能因为连接池满了而失败。此时第一个操作已经提交，无法回滚。
• 缓存更新失败但数据已提交：缓存更新通常不在事务范围内，如果缓存服务器重启或超时，数据不一致。
• 乐观锁冲突在非首操作：如果订单创建使用了乐观锁，冲突时可能已经扣减了库存，需要补偿机制。

这里暴露了一个关键点：事务回滚只能处理同一个数据库连接内的操作，而现代的分布式架构中，真正致命的是一系列跨服务的操作中某一步失败后的“补偿”逻辑。 Claude Code 能够把这种“补偿点”全部标记出来，并建议我实现一个“ Saga-like”的补偿链。

场景三：文件处理与外部 IO 的异常边界

这个场景看似简单，实际上是我踩坑最多的地方。我们有一个服务需要从 S3 上拉取用户上传的 CSV 文件，解析后批量导入数据库。这个流程中，有四个关键步骤：

1. 文件下载
2. 文件格式校验
3. 逐行解析与数据清洗
4. 数据库批量插入

我让 Claude Code 帮我“补充全面的异常处理”。它一次性列出了 23 种可能的异常类型，从 FileNotFound、EncodingError、BOM 头解析错误，到 CSV 空行、字段数量不匹配、超长字段、日期格式解析失败，甚至还包括了“CSV 文件包含 SQL 注入特征”这种安全相关的提示。

最让我印象深刻的是，它在没有任何特别指示的情况下，独立建议我将异常分为“可修复”与“不可修复”两类：对于不可修复的异常（如文件损坏），直接拒绝整个文件；对于可修复的异常（如某一行日期格式错误），记录该行并继续处理，最后汇总报告给用户。这种分层处理的思路，很多中级工程师自己也要经过一两次生产事故之后才会形成，而 Claude Code 只需要一次对话就能给出这种建议。

三、常见误区：很多人以为自己在“写错误处理”，其实只是在“贴膏药”

在指导团队使用 Claude Code 的过程中，我发现了三个特别典型、但极少被公开讨论的误区。这些误区如果不纠正，无论用不用 AI 辅助，错误处理的质量都没有本质提升。

误区 1：“Exception”兜底是安全的

这是最常见的反模式。很多人习惯在最外层写一个 catch (Exception e) 或 except Exception as e，然后打一句日志，以为这样就安全了。实际上，这种做法掩盖了两类致命问题：

• 你应该精确捕获并处理的异常，被“吞”掉了。例如 TimeoutException 需要重试，DuplicateKeyException 需要返回友好提示给前端，而 NullPointerException 则是代码逻辑错误，应该让它爆出来，而不是被捕获后程序继续执行，导致后续逻辑不可控。
• 引入了“幽灵异常”。我曾经在生产日志里看到过连续 3 个月的 catch (Exception e) 日志，每天几千条，但从来没人去看。直到有一天财务系统对账发现差了几十万，追溯回去才发现，原来半年前一个订单状态更新逻辑因为数据库字段变更，在 update 语句那里一直抛出 DataIntegrityViolationException，但因为被外层兜底捕获，程序没死，订单状态就永远卡在那里，根本没人发现。

正确的做法是：只捕获你预期之中可能发生的异常，并且明确区分“技术异常”和“业务异常”。让该崩溃的崩溃，该补偿的补偿。 而 Claude Code 能帮你做到这一点，前提是你的提示词里明确告诉它：“不要使用通用的 Exception 兜底，请为每一类可预期的失败条件指定一个具体的异常类型。”

误区 2：错误处理做得越详细越好

这是另一个极端。有些团队在使用 AI 辅助后，发现它能生成大量的异常类型，于是兴奋地把所有列出的异常全都写进代码，结果一个原本 20 行的方法，错误处理代码膨胀到了 200 行。

我见过最夸张的一次，一个支付回调接口的处理函数里，Claude Code 生成了 47 个 except 分支。团队原封不动地合并进了代码库，结果：

• 代码可读性极差，后续的开发者根本看不懂核心业务逻辑。
• 很多异常类型在同一上下文下根本不可能触发（比如本地环境才会出现的 DevConfigError），但 Claude Code 因为“责任心强”，还是给列出来了。
• 异常之间的逻辑关系混乱，甚至会出现“永远捕获不到”的死分支。

错误处理的粒度是否合理，取决于这个异常对业务是否有不同处理路径。 如果三种异常的处理方式都是“记录日志+返回 500”，那它们就应该合并为一个统一的 ServiceException；如果其中一种需要触发退款补偿，那它就应该被独立捕获。Claude Code 不会替你做这个判断，它只是在列举可能性，而你需要做的是基于业务价值对这些可能性进行裁剪和分组。

误区 3：忽略“不会失败”的假设失效

代码里最常见的一种自信，就是“这个操作绝对不会失败”。比如：

• “这个 Map 肯定有这个 key，因为前面已经 put 进去了。”
• “这个整数除法肯定不会被零除，因为分母是配置文件里读出来的，配置文件里肯定不是 0。”
• “这个文件路径肯定存在，因为是部署脚本创建的。”

当你在使用 Claude Code 时，它会非常“天真”地把这些“绝对安全”的操作标记为潜在失败点。很多开发者会觉得它太啰嗦，甚至直接忽略这些提示。但根据我个人的统计，生产环境里排名前三的非预期崩溃，恰好就是这些“绝对安全”的假设被打破的场景。配置文件被误改、并发竞态、运维手动操作残留，这些都会让“绝对”变成“意想不到”。

Claude Code 之所以能捕捉到这些，是因为它不带有“人类经验中的侥幸心理”，它只是机械地扫描每一个可能出错的调用。你可以认为它有些过度保守，但正是这种保守，能帮你发现那些被默认忽略的脆弱点。

四、我总结的“五步引导法”：让 Claude Code 输出真正可用的错误处理

基于半年的实践，我逐渐稳定下来一套提示词策略，可以让 Claude Code 生成的错误处理从“看起来很全”变成“真正能用”。我把这五步称为“异常认知建模”，因为它本质上是把开发者脑子里的隐性知识显性化。

第一步：让 Claude Code 成为“异常审计师”，而不是“代码生成器”

这是我最重要的发现：永远不要一上来就让它写 try/catch 代码。 你应该先让它做排查，而不是做修补。我的标准开局提示词是：

“请扮演一个专注于系统健壮性的高级工程师。现在分析下面的函数，不要直接写错误处理代码，而是先系统性地列出：1）所有可能抛出异常的操作点；2）每个点的异常类型；3）异常发生的概率预估（高/中/低）；4）如果不处理这个异常，对系统的影响程度。”

这样，Claude Code 会生成一个表格，而不是一堆代码。这个表格就是我前面提到的“心智图”。我拿到这个表格后，和产品经理、Tech Lead 一起过一遍，决定哪些该处理、哪些该向上抛、哪些该触发告警。这个过程，才是真正在“设计”错误处理，而不是在“补充”异常捕获。

第二步：为每个异常指定“业务归宿”

光有列表还不够，你必须给它赋予业务含义。我的第二步提示词是：

“现在根据上面生成的表格，把每一种异常归类为以下三类：A-技术自动处理类（如重试、降级，用户无感知）；B-需要用户感知的业务类（如余额不足、订单重复，需给前端明确错误码）；C-需要人工介入的灾难类（如数据不一致、第三方不可恢复失败，需要触发告警和 oncall）。”

这一步是真正把 AI 的“技术清单”转化为“业务可执行的策略”。有了这个分类，我再去指导 Junior 工程师写代码时，他们就不会再机械地 catch (Exception e)，而是开始思考：“这个异常应该让用户看到什么？”这是晋升高级工程师的必经之路，而 Claude Code 可以极大地缩短这个思考的转换周期。

第三步：用“正向-反向案例对”纠正它的过度拟合

Claude Code 在异常分析上有一个致命的问题：它几乎没有“不处理”的概念。它默认所有异常都需要处理，这会导致代码膨胀。所以我要给它明确的“反向约束”。

“请你在分析异常时，同时标记出哪些异常在当前上下文中是‘允许崩溃’的，即，如果发生这个异常，说明代码逻辑本身有不可修复的 bug，应该让程序停止。另外，如果几种异常的处理路径完全相同，请合并它们，不要产生冗余代码。”

这个步骤之后，生成的代码会显著精简。

第四步：引入“现实世界的噪声”

AI 模型训练的语料是文档、代码库，而不是真实的生产环境。在生产环境中，很多异常的发生是“瞬态”的，比如网络闪断、第三方服务短暂不可用。Claude Code 默认不会给你加上重试逻辑，除非你明确要求。

“对于每个 A 类异常，请评估是否应该实施指数退避重试。对于每个 B 类异常，请给出前端应该收到的错误码和国际化提示内容的 key。”

这一步是让错误处理从“能跑”变成“生产可用”。重试次数、退避策略、幂等保证，这些不是 AI 能自动决定的，它需要你根据你的 SLA 和下游承载能力来设定。但 Claude Code 可以帮你把这些设定应用到所有相关异常上，避免你遗忘。

第五步：生成“异常处理的自检清单”

在所有代码写完之后，我会让 Claude Code 根据最终的异常处理结果，生成一份“Code Review 自检清单”，包含：

• 是否所有外部网络调用都有超时和重试？
• 是否对非幂写的操作设置了防重机制？
• 是否有异常被捕获后没有记录足够的上下文信息？
• 是否有异常类型在不应该被捕获的地方被捕获了（比如业务逻辑层捕获了数据库底层的连接异常）？

这份清单后续会变成我们团队的编码规范的一部分，新同事很快就能对齐老兵的经验。

五、Claude Code 的边界：它在哪些异常类型上会失灵，以及我怎么兜底

我不想把 Claude Code 描绘成一个完美的工具。在这些实践里，我至少发现了四个明显的“盲区”，这些盲区如果不由人工补齐，极有可能导致灾难性后果。

盲区 1：自定义异常类的继承层次

我们的项目中有一个庞大的自定义异常树，比如 OrderException 下面有 OrderNotFoundException、OrderStatusException、OrderPaymentException 等等。Claude Code 在分析代码时，经常会把父类和子类的处理混淆，或者建议你捕获一个父类异常但实际业务需要区分不同的子类。

我的兜底办法：我会把项目的异常类图（UML 类图的一部分）作为上下文喂给它，并且明确告诉它：“对 OrderException 的子类，必须区分处理，不允许用父类捕获。”

盲区 2：并发场景下的非确定性异常

像前面提到的连接池耗尽、乐观锁冲突、ConcurrentModificationException 这类异常，它们不是由代码本身决定的，而是由运行时状态决定的。Claude Code 不会主动去分析并发模型，除非你特别要求它。如果你只是把一段同步代码扔给它，它是无法预测出在并发场景下可能出现的奇怪异常的。

我的兜底办法：对于任何可能被并发调用的方法，我会在提示词里显式加上一句话：“假设此方法在 100QPS 下并发执行，请分析可能出现的所有并发相关的异常。”

盲区 3：第三方 SDK 内部的“假”异常

这个坑我踩得很深。有一次 Claude Code 给我建议了一个叫 PaymentGatewayRateLimitException 的异常类型，我说这个异常在 SDK 文档里没看到啊。它言之凿凿地说这是基于“常见支付 SDK 实现”的经验。我查了 SDK 源码，根本没这个类，它完全是在“编造异常”。

这种情况在 AI 辅助编程里叫“幻觉推荐”，在错误处理场景下尤其危险，因为如果你真的按它编的异常类型去写 catch，那个分支永远不会命中，你的代码就等于是“挂着吊瓶输液但实际上没有药”。

我的兜底办法：我现在对任何 Claude Code 建议的、我没有见过的异常类型，都要求它给出源码出处或官方文档链接。如果给不出，我就要求它把这个异常从列表里移除。这个习惯已经救了我不止一次。

盲区 4：跨语言/跨服务边界的异常语义丢失

我们架构里有一些服务是用 Go 写的，一些是用 Python。当 Python 服务调用 Go 服务时，Go 服务返回的 error 会被序列化成 gRPC 的 StatusRuntimeException。Claude Code 在分析 Python 端代码时，有时候会直接用 Go 那边的原始错误类型（比如 sql.ErrNoRows）来匹配异常，但实际传输到 Python 端时，这个类型已经不存在了，只剩下一个错误字符串。

我的兜底办法：对于跨服务调用，我会把接口定义文件（如 .proto 文件）也提供给它，并明确说明：“所有跨网络的异常都会被封装为统一的服务异常，你需要根据错误码字段来判断，而不是异常类型名。”

六、一个完整的实操案例：从零开始构建一个支付回调的健壮错误处理

现在我用一个完整的案例，把前面所有的理论串联起来，展示我是如何用 Claude Code 把一个原本“能跑就行”的支付回调接口，变成一套“生产级别”的健壮错误处理框架的。

背景：这是一个电商平台的微信支付回调接口，由第三方支付服务商统一回调。回调 URL 接收的是 POST 请求，body 里是加密的支付结果通知。我们需要做以下事情：

1. 验签
2. 解密报文
3. 解析订单号
4. 查询本地订单状态
5. 更新订单为已支付
6. 发放虚拟商品
7. 发送通知

这是典型的链式调用，任何一步失败，都需要根据失败节点决定补偿逻辑。

第一阶段：生成异常审计清单

我先把这段业务逻辑描述和当前代码（最简版本，没有错误处理）贴给 Claude Code，说：“不要写错误处理代码，只列出所有可能的失败点、异常类型、概率、影响。”

它给了我一共 31 个失败点，包括：

• 验签失败：可能原因有秘钥错误、请求被篡改、支付服务商临时更换证书（低概率，但发生后影响巨大，所有回调都会失败）。
• 解密失败：可能是加密算法不匹配、报文格式错误。
• 订单号格式错误：可能是第三方传回的不是我们生成的格式。
• 本地订单查询为空：可能是回调时间早于订单入库时间。
• 订单状态已更新：重复通知，需要幂等处理。
• 发放虚拟商品失败：可能下游库存系统超时、商品已下架、用户账户异常。
• 发送通知失败：MQ 不可用。

第二阶段：业务分类和合并

我按照 A/B/C 三类给异常打标签，然后让 Claude Code 合并同类项。最后 31 个异常点被压缩成了 9 个实际的异常处理分支，其余的要么合并，要么被归类为“不可能在当前上下文发生”。

第三阶段：编写具体的错误处理代码

我告诉它：“基于这 9 个分支，写错误处理代码。要求：区分技术异常和业务异常，需要重试的加上指数退避，需要补偿的写清楚补偿动作，需要返回特定错误码的给前端返回。”

它生成了大约 90 行的 Python 异常处理框架，结构非常清晰：

• 验签失败 -> 直接返回 403，加日志和监控打点。
• 解密失败 -> 重试 2 次，指数退避，若仍失败则返回 500，触发人工排查。
• 订单查询为空 -> 异步延时查询（调度到一个后台任务，最多等待 30 秒），超时则标记异常订单。
• 订单状态已更新 -> 直接返回 200，保证幂等。
• 支付金额与订单金额不匹配 -> 标记订单为异常，触发财务人工处理，不给用户自动发货。
• 发放虚拟商品失败 -> 回滚订单状态为待支付+退款（或者进入补偿队列，人工处理）。
• MQ 通知失败 -> 写一张本地事件表，定时任务补偿重推。

第四阶段：完成后的 Code Review 自检

最后我让它生成了自检清单，发现了一个我在设计时就忽略的问题：发放虚拟商品之前，我们并没有检查用户账户是否存在、是否被封禁。 因为 Claude Code 在穷举失败点时，把“用户状态异常”列出了出来，我才意识到这里可能会造成已付款用户的商品发放失败，而失败原因完全可能是合理的业务限制，应该提前校验而非走补偿。

七、基于不同项目成熟度的取舍指南

不是所有项目都需要这么重的错误处理。在引入 Claude Code 进行异常覆盖时，需要根据项目所处的阶段和你团队的能力，做出明确的取舍。我把实践中的决策模型总结成下面这个矩阵。

阶段一：原型/MVP（最小可行产品）

取舍策略：重点覆盖“资金相关”和“外部依赖”的异常，其他全部向上抛。不追求覆盖率，追求开发速度。此时使用 Claude Code 的目标是快速识别高风险点，而不是生成完整代码。

我的做法是让 Claude Code 只列出“如果不处理会导致资金损失或数据永久丢失”的异常，然后针对这 2-3 个点做精确处理，其余的用统一的错误中间件兜底。

阶段二：成长期产品/内部系统

取舍策略：开始建立异常分类规范，要求对所有 C 类灾难异常必须有告警，所有 B 类业务异常必须有友好提示。这个阶段，我会让 Claude Code 生成完整的异常清单，但只实现其中的 A 类和 B 类。

阶段三：高可用要求的核心系统

取舍策略：追求“零遗漏”。所有 A 类异常必须有降级或补偿方案，所有 C 类异常必须有 oncall 联动。这个阶段，Claude Code 生成的异常清单会全部转化为测试用例，进而反向要求代码必须有对应的处理分支。我们团队的指标是：每一个被 AI 列出来的高概率异常点，都必须被一个具体的 catch 块或防御性代码所覆盖，否则代码不允许合并。

八、我为什么认为“异常心智图”是未来所有开发者都必须掌握的能力

写到这里，我想跳出具体的工具和代码，谈一点更抽象的看法。

过去十年，软件工程的核心能力是“写逻辑”，如何用代码实现需求。但在 AI 辅助编程越来越普及的今天，“写逻辑”正在快速贬值。AI 可以写出靠谱的 CRUD，可以写出完整的单元测试，甚至可以在你给它足够上下文的情况下，写出质量不错的架构设计文档。但是，AI 做不到的，是“判断什么逻辑不出错”。

错误处理的本质，不是“如何从异常中恢复”，而是“提前意识到哪些地方会出错”。这是一种防御性、全局性的思维方式，它需要理解业务、理解分布式系统的复杂性、理解人的懒惰和疏忽会怎样一点一点地瓦解代码的健壮性。

Claude Code 正是在这个维度上，成为一个极其趁手的思维脚手架。它能瞬间把你从一个具体的函数细节里拔出来，让你站在调用链路的上空，俯瞰所有可能的“裂缝”。如果你只是用它来写代码，那它只是个高级代码补全工具；但如果你用它来训练自己的“异常建模能力”，那它就是一个加速你成长为高级工程师的虚拟教练。

我自己的变化是：在经过这半年和 Claude Code 的不断协作之后，我已经不需要每次都用它了。我的脑子里已经固化了它那种“穷举-分类-取舍”的思维模式。现在我在设计一个新接口时，第一反应不再是“怎样实现”，而是“会以怎样的方式失败”。这种转变，让我在 Code Review 时能一眼看出别人代码里缺失的异常路径，让我在架构评审时总能提前指出潜在的耦合风险。

九、最后，一个马上就可以落地的最简实践方案

我不会让你看完一篇 8000 字的文章后，只收获一堆概念。现在你拿起项目里任何一个你最近改过的函数，跟着下面这四步走：

第一步：打开 Claude Code，把函数代码和它的外部依赖（调用的第三方库名、数据库操作）贴进去，输入提示词：

“请列出该函数所有可能的失败点及其对应的异常类型，按概率从高到低排列。只输出列表，不要生成错误处理代码。”

第二步：对着列表，自己标出 A（自动处理）、B（业务返回）、C（灾难告警）。做这个分类时，强迫自己为每一个异常问一句：“如果这个发生了，用户该看到什么？”，答案是空白的那些，就是 C 类。

第三步：只针对 A 类和 B 类，让 Claude Code 生成具体的处理代码，同时给它明确约束：

“A类需要指数退避重试，B类需要返回特定的业务错误码和提示信息。所有异常都不能用通用的 Exception 兜底。”

第四步：把生成的代码和原始的业务逻辑合并，然后在 Code Review 时，让另一个同事针对这份“异常覆盖清单”做走查，而不是对着代码一行行肉眼扫。你会发现 Review 的效率和质量都上升了一个台阶。

这就是我在团队里真实推行的工作流。我们没有发明任何新概念，只是把传统上完全依赖个人经验的“异常覆盖”过程，变成了一个人机协作的结构化流程。而 Claude Code 在这个流程里扮演的角色，不是替代任何人，而是确保没有任何一条可能炸毁你系统的裂缝，是因为“忘了”才被漏掉的。

如果你真的按照这个流程走一遍，你大概率会和我当初一样，在 Claude Code 列出的异常清单里发现一两个让你后背发凉的点，那种你明明知道却一直假装不知道的隐患。 而那，才是错误处理最需要覆盖的异常类型。