代码写完谁来把关？手淘 TEKO 打造“生成—验证—修复”自主闭环的工程实践

AI 写完代码，谁来验证？手淘 TEKO “写—验—修”自主闭环的工程实践｜QCon上海 — infoq.cn · 13 小时前 · ⚙️ 工程

当编码助手能够批量产出代码之后，真正的瓶颈从“写”转移到了“验”与“修”：生成的代码质量参差，人工逐条审查不仅耗时，而且审查者的精力会成为整条流水线上的天花板。手机淘宝团队在 QCon 上海的分享中，围绕这一问题给出了 TEKO 的工程化答案，核心思路是把验证与修复环节也交给自动化流程，形成从代码生成、测试验证到缺陷修复的自主闭环。TEKO 的做法并非简单地把大模型串在流水线上，而是针对每个环节设计了明确的角色分工与质量闸口：生成侧负责产出候选实现，验证侧通过单元测试、静态检查与运行时反馈等手段对代码进行多维度体检，修复侧则在验证失败后携带上下文信息进行定向修补，再回到验证环节循环，直到满足预设的通过标准或达到迭代上限。这样一套机制的关键在于让机器对自己产出的结果负责，而不是把质量压力全部转嫁给人工评审。分享中还涉及落地过程中的实际约束，例如测试用例本身的覆盖质量决定闭环上限、修复循环需要防止无限打转、以及如何度量闭环的实际收益等。作者的核心结论是：只有在工程体系里补齐“验证与修复”这两块自动化短板，机器写代码的效率优势才能真正转化为团队交付效率的提升，否则省下的编码时间会在评审与返工环节被加倍消耗掉。

核心信息

手淘团队指出，随着代码生成能力普及，工程瓶颈已经从编写阶段转移到验证与修复阶段：机器可以快速产出大量代码，但人工审查的速度没有同步提升，评审带宽成为整条交付链路上最先饱和的环节。TEKO 的设计出发点正是围绕这一错配，把原本依赖人工的验证工作自动化，让闭环在机器内部完成大部分质量筛选，人只在关键节点介入。
TEKO 采用三段式流水线架构：生成模块负责产出候选代码，验证模块结合单元测试、静态分析与运行时反馈对候选代码做多维度检查，修复模块在验证不通过时携带失败上下文进行定向修补并重新进入验证。三个环节循环执行，直到达到预设通过标准或迭代次数上限，避免无效循环消耗资源。
落地效果高度依赖测试体系本身的成熟度：如果测试用例覆盖不足或者断言质量差，验证环节就形同虚设，闭环会放行大量带缺陷的代码。因此团队在推行自动化闭环的同时，需要同步建设测试资产与质量度量指标，把闭环的实际收益纳入可量化追踪，而不是停留在演示阶段。
分享中强调自动化闭环不能完全取代人工评审，而是重新定义了人的角色：工程师从逐行审查代码，转变为设计验证策略、制定通过标准、处理机器无法解决的疑难缺陷。这种分工调整对团队的流程规范和考核方式都提出了新的要求，是比工具引入更难的组织层面变革。

💡 为什么值得读: 当所有人都还在谈机器写代码的效率时，这篇文章直接回答了更关键的问题——质量验证如何跟上产能，这是决定自动化编码能否真正落地的分水岭。

✍️ 小编看法: 这篇分享最有价值的地方，是它没有停留在展示机器写代码有多快，而是诚实地面对了效率幻觉的问题。很多团队的实践证明，编码环节省下的时间，往往在代码评审、缺陷返工和联调排障中被成倍地吃回去，整体交付效率并没有实质提升。手淘把验证和修复也纳入自动化闭环，本质上是在承认一个残酷现实：如果验证还是靠人，那么产能提升的上限就是评审者的注意力上限，无论下游生成能力多强都突破不了。但这里有几个容易被忽略的代价值得警惕。其一是验证者的悖论：用机器验证机器写的代码，如果验证逻辑本身来源于同样的技术栈和相似的训练分布，就可能存在系统性的盲区，某些类型的缺陷会在闭环里集体漏过，这类风险不会体现在通过率指标上，只会在线上事故里显形。其二是测试资产的隐性成本，闭环的可靠性完全取决于测试质量，而编写和维护高质量测试恰恰是许多团队长期欠债的领域，这意味着推行闭环的第一笔投入其实落在测试建设上，而不是工具采购上。其三是人的技能退化风险，当评审从逐行阅读变成抽查闸口，工程师对代码库的体感会逐渐稀释，这在紧急排障时会暴露出来。接下来值得观察的是这类闭环在多大程度上能处理跨模块、跨服务的复杂变更，因为单元级别的验证闭环相对好做，涉及系统边界时的验证策略才是真正考验。

🏷️ code verification, AI coding, TEKO, engineering practice