AI Coding Harness 流程跑全、CI 全绿，为何联调仍会漏场景？

AI Coding 流程可以要求智能体依次完成需求澄清、方案设计、编码和测试，CI 也能验证编译、用例与质量规则，但这些机制主要保证步骤被执行、已有检查通过。如果最初的业务理解就缺少关键分支，同一个盲区仍可能贯穿整条交付链路，直到联调阶段才暴露出来。

《AI Coding 工程化：从个人提效到组织升级》第 13 期
这个系列主要聊 AI Coding 怎样从个人工具进入团队研发流程。本期承接 Harness 和 CI Skill，继续解决流程执行完整以后，内容为什么仍会遗漏。

第 11 期用 Harness 的 Checkpoint、Hook 管住需求澄清、设计、Coding 和测试，上期又用 CI Skill 接起本地自检、流水线触发和结果回传。照理说，流程没有跳步，CI 也是绿的，代码应该可以交付了。

但到了联调，仍然会发现有些业务场景根本没做。

这类情况我们早期碰到过不少。项目知识库还没建起来时，AI 经常把眼前的功能实现得有模有样，联调才发现分支场景漏了；修改公共方法时，只处理了需求涉及的入口，其他调用方没跟着改；一个业务场景需要几次请求才能跑完，AI 分析了中间一段，却漏了前后的状态和修改点。

流程确实跑完了。问题在于，流程中的遗漏也一路传了下来。

CI 全绿，只能证明已经出的题答对了

Harness 可以要求 Coding Agent 必须做需求澄清、必须产出设计文档，设计没确认不能进入 Coding。CI 则在独立环境里重新执行编译、单元测试、覆盖率和其他质量规则。

如果 AI 在需求阶段就没意识到还有退款入口，设计里不会出现退款改造，代码自然不会改，后面生成的测试用例也不会测。CI 把已有用例全部跑绿，仍然发现不了这块空白。

无论执行者是 Claude Code、OpenAI Codex 还是 Cursor，只要需求理解、设计和测试都沿用同一套不完整上下文，同一个盲区就可能从头跟到尾。

一个优惠规则，怎么一路漏到联调

拿一个常见的交易改造举例。

需求单里写的是：下单支持一种新的平台优惠。

AI 修改了公共金额计算方法，补了下单接口和对应测试。设计文档有了，任务也拆了，本地测试通过，CI 全绿。只看这条需求，完成度很高。

联调继续往后走，问题才出现。

部分退款仍然按旧规则分摊优惠，对账还在读取旧金额字段，开票场景也没有处理新优惠。下单这一步没有写错，真正遗漏的是它后面牵动的几个入口和整条业务链。

回头看，遗漏并不是 Coding 时突然发生的：

• 项目知识没有告诉 AI，金额计算同时被退款、对账和开票使用；
• 需求澄清只讨论了怎么下单，没有追问取消和退款怎么处理；
• 设计只列出了本次新增逻辑，没有展开公共方法的全部调用方；
• 测试用例照着需求和设计生成，自然也只覆盖了下单。

所以我不赞成把解决办法归结为“联调再仔细一点”。等到这里才补需求，设计、代码和测试都要返工。

先让 AI 看见系统，再把需求问完整

项目里有哪些子系统和业务域，各自负责什么，公共能力被哪些模块调用，主链路怎样流转，这些内容要能被 AI 按需找到。入口文件不必塞满细节，但至少要给出项目地图和文档映射。

知识库能扩大 AI 看得见的范围，却解决不了所有问题。文档可能缺失，新需求里也会出现以前没有定义过的规则。

所以需求澄清不能只是把需求单重新整理一遍。AI 要主动问问题，人来回答并确认。还是前面的优惠场景，至少要追问：部分退款怎么分摊？整单取消怎么办？开票按优惠前还是优惠后金额？历史订单是否受影响？

这些答案要写回澄清文档。关键问题没有关闭，Harness 就不应该放行到设计节点。

设计 Checkpoint，要看改动点，也要看影响面

需求澄清完成后，AI 不能只产出一份“准备怎么实现”的方案，还要给出影响面清单：改哪些模块和公共方法、有哪些调用方、上下游数据怎样变化、主链路和异常链路分别改哪里。

这一步必须让人检查。人不需要替 AI 重写设计，重点看它有没有改错层级、漏掉公共入口、忽略上下游，或者只满足眼前需求，却给后续维护留下麻烦。

放到优惠案例里，设计评审要看到的就不只是下单接口，而是金额计算方法的调用关系，以及退款、对账、开票是否需要同步调整。只要影响面清单里缺了一块，就先补设计，不急着 Coding。

简单字段修改可以快速确认。涉及公共方法、核心流程或跨系统调用，影响面和完整链路就要认真过一遍。

AI 生成测试用例，测试同学负责补盲区

设计确认后，再让 AI 根据澄清文档和设计文档生成测试用例。AI 很适合展开主流程、分支和异常，也可以准备数据、调用接口、核对结果。但如果用例本身漏了场景，执行得再完整也没有用。

我们会让测试同学评审用例。不是全部重做一遍，而是重点看预期结果是否正确，分支和回归场景是否覆盖，跨系统链路有没有断点。优惠案例至少要跑过下单、支付、部分退款、对账和开票，再看每一步的金额是否一致。

用例确认后由 AI 执行场景验证，本地自检通过再提交 CI。到这里再跑 CI，它验证的就不只是 AI 自己出的题，而是已经被人检查过的场景。

Checkpoint 不能只保存一个“已完成”

这些动作要进入 Harness，不能靠人每次临时想起来。

需求、设计和测试三个关键 Checkpoint，除了节点状态，还要有明确的放行条件：

• 需求节点：关键问题已经回答，主流程、分支和验收结果已经确认；
• 设计节点：影响面、调用关系和改动点已经列出，并完成人工检查；
• 测试节点：测试用例经过测试评审，AI 已执行场景并保留结果；
• CI 节点：对应代码版本的流水线已经通过，失败证据能够回到 Agent。

我的判断是，Harness 的下一步不是继续增加节点，而是让关键节点真正对内容负责。流程状态只能说明 Agent 走到了哪里，需求有没有想完整，还得靠项目知识、人机问答、设计确认、测试评审和实际验证逐层收紧。

这些 Checkpoint 也不用第一版就设计得面面俱到。项目的特殊规则、业务知识库和项目知识库，本来就很难靠一次建设全部补齐。更现实的做法，是跟着真实需求往前走：这次漏了业务分支，就补业务知识；影响面没找全，就补项目关系和检查项；测试发现了新场景，就把它沉淀进用例和放行条件。

需求做得越多，这套 Harness 和知识库就会越完整，AI Coding 的准确率也会在一次次迭代中逐步提高。