1. 遗留代码补测试的真实困境为什么覆盖率总是卡在 30%接手一个跑了三五年的老服务最怕的不是需求变更而是线上告警指向一段没人敢动的代码。我遇到过最典型的一个类OrderService.process()四百多行if-else 嵌套七层静态单例直接调外部支付网关没有一行单元测试。你想给它补测试会发现连 Mock 都不知道从哪下手——方法体里直接new数据库连接静态方法满天飞全局状态随手改。这类代码的核心问题不是“没有测试”而是“不可测试”。写单元测试它真去扣钱写集成测试环境配三天。更麻烦的是你想加测试得先重构但重构遗留代码没有测试保护本身就是个死循环。很多团队卡在这一步覆盖率长期停在 30% 以下CI 里的覆盖率门禁形同虚设。我试过一条相对务实的路径不急着写测试先让 AI 帮我做代码考古再用统一的 API 通道把分析、生成、验证串成工作流。三天时间那段 400 行的方法补到了 87% 行覆盖率顺带挖出两个藏了三年的边界 bug。下面把可复制的配置和步骤拆开讲。这里的关键认知是AI 辅助不是让模型一次性吐出全部测试代码而是把它当成一个能快速梳理执行路径、识别边界条件、生成测试骨架的加速器。决策仍然由人来做尤其是业务语义相关的分支判断。遗留代码里经常有if (type 3)这种魔法值AI 只能告诉你“type 为 3 时走特殊逻辑”但只有你知道 type3 对应的是内部测试订单这个分支五年没被执行过。这种上下文模型给不了你。所以工作流的设计原则是AI 做苦力路径分析、边界枚举、骨架生成人做决策哪些分支值得测、断言怎么写、Mock 到什么程度。而要让这套工作流跑顺第一步是解决工具链的接入问题——你需要一个稳定的 API 通道让 Claude Code、Cline 这类工具能统一调用模型而不是每个工具配一套 Key、一套代理设置。2. TaoToken 统一 Key 接入config.toml 与 settings.json 配置骨架我早期给团队配 AI 辅助环境时最烦的是每个工具都要单独填 Base URL、API Key、Model ID。Claude Code 一套、Cline 一套、Codex 又一套Key 散落在各个配置文件里换个人接手就得重新问一遍。后来我把这些统一到 TaoToken 的 API 通道上一个 Key 走天下配置文件也收敛成两份骨架。TaoToken 在这里的角色是统一 API 入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api注意这个不加 UTM 参数。你拿到的 Key 可以同时给多个 AI 编码工具用Base URL 统一填https://taotoken.net/apiModel ID 按你需要的模型填。先说 Claude Code 的配置。Claude Code 读取的是项目根目录或用户目录下的settings.json我一般放在项目里方便团队共享。骨架如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Read, Write, Bash(git diff:*), Bash(mvn test:*) ] } }这里三个字段必须齐全Base URL 指向 TaoToken 的 API 地址API Key 填你申请到的密钥Model ID 填具体模型标识。少任何一个Claude Code 启动时都会报认证或模型找不到的错。permissions里我特意放了mvn test和git diff因为补测试的工作流里需要频繁跑测试和看改动。再说 ClineVS Code 插件的配置。Cline 用的是config.toml风格的设置在插件设置里选 “OpenAI Compatible” 模式然后填[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model_id claude-sonnet-4-20250514 [options] max_tokens 8192 temperature 0.2温度我设成 0.2因为生成测试代码需要确定性高一点太发散会给你一堆跑不通的用例。max_tokens给到 8192遗留代码分析动辄几百行输出太短会被截断。如果你用 Codex 类的工具它读的是auth.json结构类似{ base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥, model: claude-sonnet-4-20250514 }三件套Base URL Key Model ID在哪个工具里都是这个逻辑。配好之后你在终端里跑一次claude或者打开 Cline 面板能正常对话就说明通道通了。这一步别急着写测试先确认工具能连上模型不然后面排障会混在一起。3. 可复制的 AI 辅助测试生成工作流从代码考古到边界值枚举配置通了之后真正的工作流分四步走。我拿那段OrderService.process()举例每一步都给可复制的 prompt 和操作动作。第一步是代码考古不写测试先让 AI 梳理执行路径。把方法体贴给 Claude Codeprompt 这样写分析这段代码的所有执行路径列出每个分支的触发条件 标注所有外部依赖数据库、文件、网络、静态方法 给出每个依赖的 Mock 方案。输出用表格。Claude 几秒返回一张路径表比我手动梳理快十倍。它标出了三个我肉眼没发现的分支一个 catch 块吞了异常后继续执行一个 switch 的 default 直接 return null还有一个 if 条件用了! null但变量在之前已被赋值为空字符串。这一步的产出是“测试地图”你拿着它决定哪些分支优先覆盖。第二步是搭安全网。别一上来追求覆盖率先给最核心的 happy path 写一个不 Mock 任何东西的集成测试只测那些不产生副作用的分支。比如订单状态为已取消时直接返回这个分支不调外部服务、不写数据库。先让它跑通验证测试环境本身没问题。很多遗留代码连编译都过不了因为依赖的 jar 包版本不对先解决这些基础设施问题。第三步是边界值枚举。prompt 示例列出代码中所有数值比较、字符串比较、日期比较的边界条件 生成 JUnit 5 的 ParameterizedTest 用例用 CsvSource 注入边界值。Claude 会给出类似这样的输出if (amount 1000)的边界是 1000、1001、999if (status.equals(PAID))的边界是 PAID、null、空字符串、其他状态if (date.before(today))的边界是今天、昨天、明天、null。把这些组合成参数化测试覆盖率能直接拉到 40% 以上。用CsvSource的好处是代码量少一个测试方法覆盖十几个边界。第四步是 Mock 外部依赖打通剩余分支。这是最耗时的部分。遗留代码的外部依赖往往没有接口Mock 起来很痛苦。我的做法是让 Claude 识别所有外部调用点然后手动给这些点加测试开关。对于静态方法用 Mockito 的mockStatic()私有方法用反射final 类用 PowerMock。虽然这些工具被很多人诟病但对付遗留代码它们是救命稻草。我那段代码里有个File.separator的拼接逻辑测试时在不同操作系统上结果不一样。Claude 帮我生成了一个Rule来临时修改系统属性跑完自动恢复。这个细节让我少踩一个坑。整个工作流跑下来从 0 到 87% 用了三天其中 Mock 环节占了一半时间。4. 验证请求与覆盖率对比跑通第一个 AI 生成的测试配置和工作流就绪后你需要一个明确的验证动作来确认整条链路是通的。我一般分两层验证先验证 API 通道再验证覆盖率提升。验证 API 通道最简单的方式是用 curl 直接打一次请求确认 Key 和 Base URL 没问题curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-你的TaoToken密钥 \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 256, messages: [ {role: user, content: 回复 OK 两个字母即可} ] }返回里能看到content字段带OK说明通道通了。如果返回 401说明 Key 不对如果返回 model not found说明 Model ID 写错了。这一步排除掉认证问题后面工具里的报错就只剩配置格式问题。通道验证完跑第一个 AI 生成的测试。我让 Claude 给“订单已取消直接返回”这个分支生成一个测试它给出的骨架大致是Test void process_shouldReturnEarly_whenOrderCancelled() { Order order new Order(); order.setStatus(CANCELLED); OrderResult result orderService.process(order); assertNull(result.getPaymentId()); assertEquals(CANCELLED, result.getStatus()); }跑mvn test -DtestOrderServiceTest如果绿了说明测试环境、依赖注入、断言逻辑都对。然后跑覆盖率mvn test jacoco:report打开target/site/jacoco/index.html看OrderService那一行的覆盖率数字。我记录过前后对比补测试前行覆盖率 12%补完安全网和边界值测试后到 43%Mock 打通所有分支后到 87%。分支覆盖率从 8% 到 79%。这个对比数据是验证工作流有效性的硬指标也是给团队看的最直观证据。这里有个细节单纯看行覆盖率会骗人。我见过覆盖率 90% 的代码改一行就崩因为那些覆盖到的行只是被执行了断言根本没验证正确结果。所以每个测试生成后我会手动检查断言是否足够。一个测试如果没有断言或者断言只检查了不为 null那它基本没用。更狠一点可以跑变异测试用 PIT 修改代码比如把改成看测试能不能发现。Claude 可以帮你分析 PIT 的 report找出哪些变异没被杀死然后生成对应用例。5. 常见报错排查401、local proxy failed 与 reading choices 报错配 AI 辅助工作流时报错基本集中在几个固定位置。我把踩过的坑按报错原文列出来方便你对照。401 Unauthorized最常见。原因通常是 Key 没填对或者 Base URL 末尾多了斜杠。TaoToken 的 API 地址是https://taotoken.net/api不要写成https://taotoken.net/api/有些工具对末尾斜杠敏感。另外检查settings.json里ANTHROPIC_API_KEY字段有没有被环境变量覆盖Claude Code 会优先读环境变量。local proxy failed / connection refused这个报错说明工具在尝试走本地代理但代理没起来。检查你的工具配置里有没有残留的http_proxy或https_proxy环境变量。在终端里跑env | grep -i proxy看一眼有的话unset掉。TaoToken 的通道是直连 API 地址不需要额外代理层。reading choices 报错 / unexpected response format这个通常出现在 Cline 或 OpenAI Compatible 模式的工具里。原因是工具按 OpenAI 的响应格式解析但实际返回的是 Anthropic 格式或者反过来。检查你的config.toml里 provider 类型选对了没有。Claude 系列模型走 Anthropic 格式如果你在 Cline 里选了 “OpenAI Compatible”需要确认 TaoToken 的对应端点支持该格式转换。Model ID 写错也会导致这个报错比如把claude-sonnet-4-20250514写成claude-sonnet-4模型找不到时返回体结构不对解析就炸了。OAuth 相关报错Claude Code 某些版本会尝试 OAuth 登录流程如果你用的是 API Key 模式需要在settings.json里显式禁用 OAuth。检查有没有forceLoginMethod: apiKey这类字段没有的话加上。OAuth 报错通常伴随浏览器跳转失败看到这类提示直接往 API Key 模式排查。覆盖率报告为空跑完mvn test后jacoco.exec没生成或者报告里没有目标类。检查 pom.xml 里 jacoco 插件的prepare-agent有没有绑定到 test 阶段。另一个常见原因是测试类命名不符合 surefire 规范*Test.java或Test*.java才会被扫描到。排障的顺序建议是先用 curl 验证通道再验证工具配置格式最后看业务代码层面的问题。这样能把问题范围快速缩小到某一层不用在多个配置之间反复猜。6. 把工作流固化下来从个人技巧到团队可复用资产一个人用 AI 补测试效率高不代表团队能复制。我后来把这套工作流固化成了三样东西一份共享的settings.json模板、一份 prompt 清单、一份覆盖率门禁规则。settings.json模板放在项目根目录新成员 clone 下来填自己的 Key 就能用。prompt 清单写进docs/ai-testing-workflow.md把代码考古、边界值枚举、Mock 生成这几个 prompt 固定下来避免每个人问法不一样导致输出质量参差。覆盖率门禁在 CI 里配 jacoco 的check规则新代码行覆盖率不低于 70%遗留代码模块单独设阈值逐步提升而不是一刀切。长期跑下来我建议把 AI 编码相关的调用走 Coding Plan 这类套餐比按量计费更可控团队多人共用时成本也好摊。模型对话类的临时验证可以用模型对话入口快速试接入文档在接入文档里Key 管理在 API Keys 页面。这几个入口分工清楚日常用起来不会乱。最后说一个真实体会别追求 100% 覆盖率。从 0 到 60% 可能一天就够从 60% 到 80% 需要两天从 80% 到 90% 可能要一周从 90% 到 100% 基本不可能——有些分支是死代码有些是异常路径Mock 成本极高。核心业务逻辑覆盖到 80%异常路径覆盖主要场景死代码和极低概率路径直接跳过。把时间花在“改了会出问题”的代码上而不是“永远不会被执行”的代码上。AI 是加速器业务判断还得人来做。
1. 遗留代码补测试的真实困境为什么覆盖率总是卡在 30%接手一个跑了三五年的老服务最怕的不是需求变更而是线上告警指向一段没人敢动的代码。我遇到过最典型的一个类OrderService.process()四百多行if-else 嵌套七层静态单例直接调外部支付网关没有一行单元测试。你想给它补测试会发现连 Mock 都不知道从哪下手——方法体里直接new数据库连接静态方法满天飞全局状态随手改。这类代码的核心问题不是“没有测试”而是“不可测试”。写单元测试它真去扣钱写集成测试环境配三天。更麻烦的是你想加测试得先重构但重构遗留代码没有测试保护本身就是个死循环。很多团队卡在这一步覆盖率长期停在 30% 以下CI 里的覆盖率门禁形同虚设。我试过一条相对务实的路径不急着写测试先让 AI 帮我做代码考古再用统一的 API 通道把分析、生成、验证串成工作流。三天时间那段 400 行的方法补到了 87% 行覆盖率顺带挖出两个藏了三年的边界 bug。下面把可复制的配置和步骤拆开讲。这里的关键认知是AI 辅助不是让模型一次性吐出全部测试代码而是把它当成一个能快速梳理执行路径、识别边界条件、生成测试骨架的加速器。决策仍然由人来做尤其是业务语义相关的分支判断。遗留代码里经常有if (type 3)这种魔法值AI 只能告诉你“type 为 3 时走特殊逻辑”但只有你知道 type3 对应的是内部测试订单这个分支五年没被执行过。这种上下文模型给不了你。所以工作流的设计原则是AI 做苦力路径分析、边界枚举、骨架生成人做决策哪些分支值得测、断言怎么写、Mock 到什么程度。而要让这套工作流跑顺第一步是解决工具链的接入问题——你需要一个稳定的 API 通道让 Claude Code、Cline 这类工具能统一调用模型而不是每个工具配一套 Key、一套代理设置。2. TaoToken 统一 Key 接入config.toml 与 settings.json 配置骨架我早期给团队配 AI 辅助环境时最烦的是每个工具都要单独填 Base URL、API Key、Model ID。Claude Code 一套、Cline 一套、Codex 又一套Key 散落在各个配置文件里换个人接手就得重新问一遍。后来我把这些统一到 TaoToken 的 API 通道上一个 Key 走天下配置文件也收敛成两份骨架。TaoToken 在这里的角色是统一 API 入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api注意这个不加 UTM 参数。你拿到的 Key 可以同时给多个 AI 编码工具用Base URL 统一填https://taotoken.net/apiModel ID 按你需要的模型填。先说 Claude Code 的配置。Claude Code 读取的是项目根目录或用户目录下的settings.json我一般放在项目里方便团队共享。骨架如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Read, Write, Bash(git diff:*), Bash(mvn test:*) ] } }这里三个字段必须齐全Base URL 指向 TaoToken 的 API 地址API Key 填你申请到的密钥Model ID 填具体模型标识。少任何一个Claude Code 启动时都会报认证或模型找不到的错。permissions里我特意放了mvn test和git diff因为补测试的工作流里需要频繁跑测试和看改动。再说 ClineVS Code 插件的配置。Cline 用的是config.toml风格的设置在插件设置里选 “OpenAI Compatible” 模式然后填[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model_id claude-sonnet-4-20250514 [options] max_tokens 8192 temperature 0.2温度我设成 0.2因为生成测试代码需要确定性高一点太发散会给你一堆跑不通的用例。max_tokens给到 8192遗留代码分析动辄几百行输出太短会被截断。如果你用 Codex 类的工具它读的是auth.json结构类似{ base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥, model: claude-sonnet-4-20250514 }三件套Base URL Key Model ID在哪个工具里都是这个逻辑。配好之后你在终端里跑一次claude或者打开 Cline 面板能正常对话就说明通道通了。这一步别急着写测试先确认工具能连上模型不然后面排障会混在一起。3. 可复制的 AI 辅助测试生成工作流从代码考古到边界值枚举配置通了之后真正的工作流分四步走。我拿那段OrderService.process()举例每一步都给可复制的 prompt 和操作动作。第一步是代码考古不写测试先让 AI 梳理执行路径。把方法体贴给 Claude Codeprompt 这样写分析这段代码的所有执行路径列出每个分支的触发条件 标注所有外部依赖数据库、文件、网络、静态方法 给出每个依赖的 Mock 方案。输出用表格。Claude 几秒返回一张路径表比我手动梳理快十倍。它标出了三个我肉眼没发现的分支一个 catch 块吞了异常后继续执行一个 switch 的 default 直接 return null还有一个 if 条件用了! null但变量在之前已被赋值为空字符串。这一步的产出是“测试地图”你拿着它决定哪些分支优先覆盖。第二步是搭安全网。别一上来追求覆盖率先给最核心的 happy path 写一个不 Mock 任何东西的集成测试只测那些不产生副作用的分支。比如订单状态为已取消时直接返回这个分支不调外部服务、不写数据库。先让它跑通验证测试环境本身没问题。很多遗留代码连编译都过不了因为依赖的 jar 包版本不对先解决这些基础设施问题。第三步是边界值枚举。prompt 示例列出代码中所有数值比较、字符串比较、日期比较的边界条件 生成 JUnit 5 的 ParameterizedTest 用例用 CsvSource 注入边界值。Claude 会给出类似这样的输出if (amount 1000)的边界是 1000、1001、999if (status.equals(PAID))的边界是 PAID、null、空字符串、其他状态if (date.before(today))的边界是今天、昨天、明天、null。把这些组合成参数化测试覆盖率能直接拉到 40% 以上。用CsvSource的好处是代码量少一个测试方法覆盖十几个边界。第四步是 Mock 外部依赖打通剩余分支。这是最耗时的部分。遗留代码的外部依赖往往没有接口Mock 起来很痛苦。我的做法是让 Claude 识别所有外部调用点然后手动给这些点加测试开关。对于静态方法用 Mockito 的mockStatic()私有方法用反射final 类用 PowerMock。虽然这些工具被很多人诟病但对付遗留代码它们是救命稻草。我那段代码里有个File.separator的拼接逻辑测试时在不同操作系统上结果不一样。Claude 帮我生成了一个Rule来临时修改系统属性跑完自动恢复。这个细节让我少踩一个坑。整个工作流跑下来从 0 到 87% 用了三天其中 Mock 环节占了一半时间。4. 验证请求与覆盖率对比跑通第一个 AI 生成的测试配置和工作流就绪后你需要一个明确的验证动作来确认整条链路是通的。我一般分两层验证先验证 API 通道再验证覆盖率提升。验证 API 通道最简单的方式是用 curl 直接打一次请求确认 Key 和 Base URL 没问题curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-你的TaoToken密钥 \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 256, messages: [ {role: user, content: 回复 OK 两个字母即可} ] }返回里能看到content字段带OK说明通道通了。如果返回 401说明 Key 不对如果返回 model not found说明 Model ID 写错了。这一步排除掉认证问题后面工具里的报错就只剩配置格式问题。通道验证完跑第一个 AI 生成的测试。我让 Claude 给“订单已取消直接返回”这个分支生成一个测试它给出的骨架大致是Test void process_shouldReturnEarly_whenOrderCancelled() { Order order new Order(); order.setStatus(CANCELLED); OrderResult result orderService.process(order); assertNull(result.getPaymentId()); assertEquals(CANCELLED, result.getStatus()); }跑mvn test -DtestOrderServiceTest如果绿了说明测试环境、依赖注入、断言逻辑都对。然后跑覆盖率mvn test jacoco:report打开target/site/jacoco/index.html看OrderService那一行的覆盖率数字。我记录过前后对比补测试前行覆盖率 12%补完安全网和边界值测试后到 43%Mock 打通所有分支后到 87%。分支覆盖率从 8% 到 79%。这个对比数据是验证工作流有效性的硬指标也是给团队看的最直观证据。这里有个细节单纯看行覆盖率会骗人。我见过覆盖率 90% 的代码改一行就崩因为那些覆盖到的行只是被执行了断言根本没验证正确结果。所以每个测试生成后我会手动检查断言是否足够。一个测试如果没有断言或者断言只检查了不为 null那它基本没用。更狠一点可以跑变异测试用 PIT 修改代码比如把改成看测试能不能发现。Claude 可以帮你分析 PIT 的 report找出哪些变异没被杀死然后生成对应用例。5. 常见报错排查401、local proxy failed 与 reading choices 报错配 AI 辅助工作流时报错基本集中在几个固定位置。我把踩过的坑按报错原文列出来方便你对照。401 Unauthorized最常见。原因通常是 Key 没填对或者 Base URL 末尾多了斜杠。TaoToken 的 API 地址是https://taotoken.net/api不要写成https://taotoken.net/api/有些工具对末尾斜杠敏感。另外检查settings.json里ANTHROPIC_API_KEY字段有没有被环境变量覆盖Claude Code 会优先读环境变量。local proxy failed / connection refused这个报错说明工具在尝试走本地代理但代理没起来。检查你的工具配置里有没有残留的http_proxy或https_proxy环境变量。在终端里跑env | grep -i proxy看一眼有的话unset掉。TaoToken 的通道是直连 API 地址不需要额外代理层。reading choices 报错 / unexpected response format这个通常出现在 Cline 或 OpenAI Compatible 模式的工具里。原因是工具按 OpenAI 的响应格式解析但实际返回的是 Anthropic 格式或者反过来。检查你的config.toml里 provider 类型选对了没有。Claude 系列模型走 Anthropic 格式如果你在 Cline 里选了 “OpenAI Compatible”需要确认 TaoToken 的对应端点支持该格式转换。Model ID 写错也会导致这个报错比如把claude-sonnet-4-20250514写成claude-sonnet-4模型找不到时返回体结构不对解析就炸了。OAuth 相关报错Claude Code 某些版本会尝试 OAuth 登录流程如果你用的是 API Key 模式需要在settings.json里显式禁用 OAuth。检查有没有forceLoginMethod: apiKey这类字段没有的话加上。OAuth 报错通常伴随浏览器跳转失败看到这类提示直接往 API Key 模式排查。覆盖率报告为空跑完mvn test后jacoco.exec没生成或者报告里没有目标类。检查 pom.xml 里 jacoco 插件的prepare-agent有没有绑定到 test 阶段。另一个常见原因是测试类命名不符合 surefire 规范*Test.java或Test*.java才会被扫描到。排障的顺序建议是先用 curl 验证通道再验证工具配置格式最后看业务代码层面的问题。这样能把问题范围快速缩小到某一层不用在多个配置之间反复猜。6. 把工作流固化下来从个人技巧到团队可复用资产一个人用 AI 补测试效率高不代表团队能复制。我后来把这套工作流固化成了三样东西一份共享的settings.json模板、一份 prompt 清单、一份覆盖率门禁规则。settings.json模板放在项目根目录新成员 clone 下来填自己的 Key 就能用。prompt 清单写进docs/ai-testing-workflow.md把代码考古、边界值枚举、Mock 生成这几个 prompt 固定下来避免每个人问法不一样导致输出质量参差。覆盖率门禁在 CI 里配 jacoco 的check规则新代码行覆盖率不低于 70%遗留代码模块单独设阈值逐步提升而不是一刀切。长期跑下来我建议把 AI 编码相关的调用走 Coding Plan 这类套餐比按量计费更可控团队多人共用时成本也好摊。模型对话类的临时验证可以用模型对话入口快速试接入文档在接入文档里Key 管理在 API Keys 页面。这几个入口分工清楚日常用起来不会乱。最后说一个真实体会别追求 100% 覆盖率。从 0 到 60% 可能一天就够从 60% 到 80% 需要两天从 80% 到 90% 可能要一周从 90% 到 100% 基本不可能——有些分支是死代码有些是异常路径Mock 成本极高。核心业务逻辑覆盖到 80%异常路径覆盖主要场景死代码和极低概率路径直接跳过。把时间花在“改了会出问题”的代码上而不是“永远不会被执行”的代码上。AI 是加速器业务判断还得人来做。
