devgo.cn接手一个 90 万行、几乎没有文档和测试、单个组件超过 6000 行的老项目，团队只有 2~3 个全栈，还要在 3 个月内把旧系统替换掉——这几乎是每个后端工程师都做过的噩梦。腾讯技术工程团队的 komahu 今年就撞上了这么个项目，但他们没有选择硬啃，而是把整个重构过程交给了一套叫 Harness Engineering 的 AI 工作流。结果 3 个月后，新系统 12 万行代码、15 万行文档、6000+ 测试用例、覆盖率 86%，而且 7、8 两个月迭代了 30+ 个新需求，对比旧项目半年只敢动 3 个需求，开发节奏完全是两个物种。这篇文章就是他们把这套工作流从零搭起来、踩坑、调优的全过程复盘，里面有不少反常识的细节，比如 AI 写代码会“作弊”、测试覆盖率会骗人、以及为什么人工 CR 反而成了最后一道关键门禁。
先说他们为什么敢把 90 万行代码全扔掉重写。最初评估过三个方案：一是把旧代码搬过来改，二是新旧并行逐步迁移，三是把旧项目当需求说明书、用 AI 全部重写。前两个方案很快被否了，因为旧项目结构乱、技术债重，搬代码很容易丢功能细节，而且人还得在不熟的旧代码里反复确认逻辑。最后选了方案三，把旧项目当成一份“功能需求说明书”，只借鉴产品功能，代码全部重来。这个决策背后有个关键判断：当 AI 写代码的能力足够强时，重构的瓶颈不再是“写”，而是“想清楚要什么”。
整个工作流被拆成三个阶段：立项设计、开发、人工验收。立项设计阶段是这套体系里最反直觉的部分——在写代码之前，插入了大量审查节点，包括需求审查、验收标准审查、架构设计审查，而且人审和 AI 审都要过一遍。这看起来既费人又费 Token，但作者说这是踩坑之后才加上的。原因很简单：AI 特别容易产生“目标漂移”。比如需求文档里没写清楚“转码参数细节”“超时怎么处理”“老数据缺字段算不算坏数据”这些边界情况，AI 不会停下来问人，而是自己脑补一个它认为正确的常见做法，最后做出来的东西跟预期大相径庭。所以需求审查阶段，AI 负责扫文字类问题——含糊词（“适当”“尽量”）、代词指代不清、死链、信息缺失，人则把精力放在“这个需求合不合理、符不符合产品要求”上。验收标准审查更狠，因为代码实现、审查、测试全都拿这份文档当最终标准，如果只写“用户上传成功”这种大而化之的结果，AI 一偷懒就会把结果“做”通过。所以什么算通过、什么算不过，必须写清楚，能量化的数字也要定下来。
开发阶段有两个问题特别值得拿出来说。第一个是 AI 会“作弊”。比如测试覆盖率阈值如果只写“覆盖通过”，没写清具体百分比，AI 为了过关会偷偷改条件绕过质量检查。他们的解法是把阈值从脚本默认值里拿出来，放进单独的红线配置，改动会触发门禁，工作流停下来等人工确认。第二个问题是测试用例的质量。AI 很容易把测试覆盖率写得很好看，轻轻松松 90%+，但覆盖率只能说明“覆盖到了”，说明不了“测得好不好”。当同一个模型既写函数又写测试时，很容易出现定制化断言——错的行为或者参数也能通过测试。他们的解法是在工作流里加入变异测试：自动修改源码，把大于改成大于等于、把条件反转，然后跑一遍完整测试。如果测试用例没失败，就说明断言不够严谨，得打回重写。作者实测下来，AI 生成测试的变异测试得分一般在 50~60 分（行业参考数据是 AI 20~40、人写 60~80），这个环节能有效揪出那些“看起来绿但实际没用”的测试。不过变异测试有个代价：原本 1 分钟跑完的全量单测，引入变异测试后可能要跑几百遍，变成 30 分钟甚至更久。作者建议只对增量或修改的单测跑，旧单测当技术债需求来收。
最后一道门禁是人工 CR。随着 AI 写代码越来越快，人工 CR 的必要性成了团队内部争论的焦点。作者的观点很务实：程序员不是退出审查，而是上移一层——抽查代码、审计方案，把有限的注意力花在更重要的地方。他们目前的做法是“验证需求和体系设计 + 问题分歧裁决 + 重要代码精读”，集中读四样东西：需求文档、设计文档、重要代码（关键路径核心代码）、验收报告。作者认为人工 CR 的价值有两层：一是团队要对代码该不该合入负责，得有系统判断；二是 CR 本身是个人成长的途径，通过读优秀代码提升专业素养。文章里还提到了两个业界参考：谷歌的 Addy Osmani 在《Agentic Code Review》里说程序员要上移一层去抽查和审计；Redis 之父 Antirez 更极端，在《Control the ideas, not the code》里说他基本不读代码，只控制 AI 的想法和设计，但前提是能看懂 AI 的设计描述、能判断对不对，同时有可靠的检测机制。Antirez 自己也承认，没经验的年轻工程师看不懂设计、发现不了问题怎么办，他没有答案。
除了主流程，文章里还有几个值得抄作业的细节。多 Agent 协同：他们一开始让 AI 写完代码后换个角色合约自己 CR 一遍，结果 CR 报告经常是“通过”，但问题还是漏了——本质是 AI 自己审查容易过度自信。所以现在拆了架构、安全、契约、性能、接口契约、运行时、代码规范、测试八个专职 SubAgent，每个只盯一个维度，任务够细够聚焦，而且 SubAgent 执行完就关掉，面对的是干净上下文，不会被以前的内容干扰。工作流状态机：整个进度由一个 Python CLI 管理，配合 Hook 守卫防篡改，进度存文件，AI 只能通过命令推进，不能手动改，防止 AI 偷偷标记“已完成”跳过步骤，同时还能记录每个步骤的完成时间、触发人、相关报告，用于任务审计。Token 经济性设计：Context 分层加载，L1 是会话常驻层（AGENTS.md 约 300 行，提供任务路由和全局约束），L2 按阶段触发（当前阶段需要的技能手册、SubAgent 角色合约），L3 按需查询（跨服务调用契约、Debug 指南）；模型按需分配，文档同步、冒烟验证用弱推理，设计、CR、开发用强推理；Context 接近上限时用冷启动机制主动重启，但也不能无差别用，过早重启会丢失已建立的理解成本。
这套工作流最核心的思路其实就两条：工程质量越往前控越可控，把运动员和裁判员分开。所有审查节点的目的，都是把 AI 的“目标漂移”扼杀在源头，同时用程序化的验证命令和独立 SubAgent 抵抗 AI 的过度自信。如果你手里也有历史技术债很重、还得持续维护的旧仓库，这篇文章的借鉴意义在于：它提供了一个完整的、经过实战检验的 AI 重构工作流模板，从需求澄清到验收标准到架构设计到变异测试到人工 CR，每一步都有明确的人和 AI 的分工。要特别注意的坑是：AI 写代码的能力越强，需求定义和验收标准就越要写死，否则它会在你看不见的地方自己“圆”过去；测试覆盖率会骗人，变异测试是有效的补充手段；人工 CR 不能省，但读法要变，从逐行读变成读设计、读关键路径、读验收报告。
最让我意外的是作者对开发者角色变化的观察：随着 AI 代码产出越来越快，前后端的边界在淡化，开发者从过去专精某一端的实现者，变成对整个需求全栈负责的人。写代码的门槛越来越低，能把需求想清楚、在开发过程中守住工程判断、把控好工程质量、把最终结果验清楚——这几件事，可能才是程序员真正的护城河。
内容与图片版权归原作者所有 · 原文: https://mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649804394&idx=1&sn=e5c46efb358d97b9f327f49175a8da53