AI 交回一份补丁后，还需要证明问题确实解决、修改没有越界、测试能够发现错误。工程质量闭环，把这些要求变成一套可以执行、可以验收的工作方式。

假设你把"订单重复提交"这个 Bug 交给 AI。

它增加判断、补上测试，最后告诉你："已修复，全部通过。"

这时，你还需要确认一件事：同一个业务操作重复触发时，系统是否真的只留下了预期的结果。代码看起来合理、测试界面变绿，都还需要具体证据来解释。

"工程质量闭环"这套技能，把要求放在了编码的整个过程中：先弄清问题，再做必要的修改，最后交出可复核的结果。它适用于开发、缺陷修复、重构和代码评审。

动手前 先把问题复现出来

修复之前，先读相关代码、现有测试和调用关系，也要看清项目里已经有哪些未提交的修改。

订单在什么情况下重复？重复请求从哪里来？现有测试为什么没有发现？这些信息会直接影响修复方案。

修复缺陷时，应先得到一个确实由它引起的失败测试。新增功能则先明确输入、输出和边界条件；重构需要先固定必须保持的行为。

测试因为环境缺失而失败，不能证明业务缺陷已经复现。项目原本就存在的失败，也要与本次修改造成的问题分开记录。只有起点清楚，后面才说得清哪些变化来自这次修改。

任务范围同样要在这里定下来。只读评审就交付发现和依据；修复订单问题，就围绕相关模块和测试推进。无关的历史问题可以另行记录，用户已有的工作要保留下来。

顺着调用链 找到错误的起点

看到异常就再加一层判断，补丁往往很好写。但在动手之前，需要沿调用链往回找：错误状态最早是在哪里产生的？

以订单为例，按钮防重复点击可能有帮助，还需要继续检查服务端如何处理重复请求，以及重试会不会产生额外副作用。系统应当先明确，同一业务操作重复执行后，最终允许留下什么状态。

如果问题出在状态归属或数据结构，就要修正那个位置。外围的特殊分支越堆越多，后面维护的人越难弄清正常流程。

最小修改也要结合根因来理解。几行代码遮住症状，未必解决了问题；合理的修改应刚好覆盖目标，并尽量利用项目已有的机制。

需要较大调整时，就拆成能够单独验证的小批次。每完成一批，检查一次结果。一旦行为发生变化，也更容易定位是哪一步引入的。

让测试盯住业务结果

测试应该检查调用者能够观察到的结果。

在订单这个例子里，要关注最终产生了几笔业务记录、状态是否正确、重复执行有没有额外副作用。只检查某个内部函数被调用过，还不足以说明这些行为正确。

一条有用的修复记录，应当能说明：修改前，测试因这个缺陷而失败；修改后，相同场景通过。不能为了让测试变绿而删除有效断言，也不能把错误行为写成预期结果。

这也给重构留下了空间。只要对外行为符合约定，内部实现可以调整，测试不必跟着每一次合理的代码搬动一起失效。

如果环境确实无法运行测试，就写清限制和替代证据。一次没有发生过的验证，无论描述得多完整，都不能成为验收依据。

用质量工具发现问题 再作判断

这套技能还结合了三个工具：crapper 检查复杂度与测试覆盖，dryer 查找结构重复，mutator 检验测试能否发现代码中的错误。

其中，变异测试值得单独解释。它会对代码作出有意的小改动，例如改错一个边界条件，然后运行现有测试。如果业务行为已经被破坏，测试却依旧通过，就需要检查是否缺少用例，或者断言太宽松。

变异结果需要分类分析：哪些改动被测试发现，哪些改动后测试依旧通过，哪些位置尚未被覆盖。对于测试未能发现的改动，还要判断它是否确实改变了业务行为；环境异常则单独说明。

复杂度和重复代码也一样需要解释。复杂的函数若缺少有效测试，值得优先关注；两段看起来相似的代码，则要先确认是否承担相同的业务职责，再决定是否合并。

为了降低分数，把清楚的逻辑拆成碎片，或把含义不同的代码硬凑成一个抽象，可能让维护更困难。工具给出线索，工程判断决定该不该改。

检查始终围绕本次任务展开。涉及模块关系时，再看真实依赖是否合理；普通局部修改不必为了流程齐全，强行做一套架构图。

交付时 让完成的依据看得见

一份可以验收的交付，需要说清楚：解决了什么问题，改动为什么必要，实际运行了哪些检查，以及还有哪些地方没有验证。

"通过"要带着范围。验证了订单模块，就说明订单模块的结果，不能直接宣称整个项目已经达标。

没有运行、执行失败和证据不足，也要分开说明。过期的覆盖率报告、零次实际执行的变异检查，都不能包装成"全部通过"。文案等不适合行为测试的修改，则采用对应的检查方式。

操作范围也要守住。测试可能连接真实服务，需要使用已获准的隔离环境；提交、推送、部署等操作，继续遵守已有授权。完成一项修复，并不自动获得处理整个仓库的权限。

真正有用的交付，会让接手的人知道当前可以确认什么，还欠缺什么，以及下一步怎样补齐。

下次让编码 Agent 修复问题，可以把任务说得更具体：

使用工程质量闭环修复订单重复提交。先复现并定位根因，只修改订单模块及相关测试。每批修改后验证，完成时说明行为回归、代码质量和测试有效性的实际结果，并列出未验证的部分。不要提交或推送。

收到结果后，你就可以沿着最初的问题、实际改动和验证记录逐项验收。每一项结论，都应当能找到对应的依据。