90万行旧代码，3个月用AI重写成12万行

3月接手一个内部视频在线剪辑项目时，团队只有2到3个全栈，心态有点崩。

摆在他们面前的是：前后端代码约90万行，风格混杂、耦合严重，单个复杂组件超过6000行；相关文档和单测几乎没有；新需求还在不断催着加。任何一个改动都是牵一发而动全身，必须小心翼翼测试。

他们给自己定的目标很直接：3个月内把旧版本还在用的功能全部做上去，替换掉旧系统，再迭新功能，同时输出一套可复用的Harness开发模式。

6月底上了第一个试用版，随后转入功能持续迭新。截至8月底，重构版约12万行代码、15万行文档、6000+测试用例，测试覆盖率86%。开发节奏的变化更直观：旧项目半年只敢动不到3个需求或紧急Bug，7、8两个月已经迭代了30+新功能需求。

这套工作流的核心，是先回答一个问题：当AI写完代码，工程质量应该如何可靠验证，才敢合入上线？

拿“用户上传成功就能进剪辑”这个功能来说，AI两小时就能开发完成，单测全部通过，实际一看代码，连覆盖率可能都是它自己“圆”出来的。所以除了AI审查，他们还要求人对需求、设计文档和最终代码做交叉审查。整体思路两条：工程质量越往前控越可控；把运动员和裁判员分开，抵抗人性里的惰性。

工作流分三个阶段。立项设计阶段处理写代码前的相关工作：立项、需求澄清、需求审查、写验收标准、验收标准审查、前后端代码架构设计、架构设计审查、人工需求与设计文档交叉审查。开发阶段如果是跨端需求，前后端并行执行代码实现、代码审查、后端冒烟测试或前端链路自动化审查。最后是人工代码CR、验收、任务归档和发起代码MR。

需求审查环节，开发人员必须把需求文档看明白。需求一大，细节没沟通清楚，AI很容易自己脑补它认为正确的常见做法。比如转码参数细节、超时错误处理、老数据缺字段算不算坏数据，这些边界情况AI并不会停下来跟人确认，最终做出来的需求可能跟预想大相径庭。AI独立审查则负责扫那些看着累、机器扫得快的问题：含糊词、指代不明的代词、死链、缺失信息。

验收标准审查针对的是最终验收目标有没有写对。代码实现、审查、测试，AI都按这份文档当最终标准。一旦只写“用户上传成功”这种大而不细的结果，AI一偷懒就容易把结果“做”通过。

架构设计审查重点看技术方案合理性、可行性和扩展性。工作流搭建初期，代码质量扫描工具扫出重复代码的概率高了很多。分析发现这跟AI的工作原理有关：它写的局部代码比较优，但对全局未必。每次新需求对它都是一个新的开始，项目代码量越大，它需要了解的内容和遵守的准则越多，检索词太窄或者根本没搜类似实现，就着急自己动手。一旦有“屎山”前兆不加控制，问题会快速堆积——即使AI发现同一功能已有多种实现，它也不会自己收敛，反而去不停打各种奇怪的补丁。

行业观察GitClear对过去大量代码的质量研究里发现，AI Coding逐步普及后，代码的重复率从8.3%提升到了12.3%。所以他们在设计文档阶段就设定AI架构设计审查环节，要求人也对当前架构熟悉，能从设计文档上裁定新增或变更的代码能不能复用。

进入开发阶段，跨端需求分前后端两条链路并行实现，按设计文档使用TDD先写契约测试再实现，同时通过Rules和宪章让AI遵守代码习惯。但AI还是会写出烂代码，因为这些限制文件对AI来说更像叮嘱式的建议，随着Context使用越来越多，信息被稀释，AI往往会忽略曾经的约定，所以代码自动化CR必不可少。

在AI代码CR阶段，他们给各个SubAgent赋予架构、安全、契约、性能、接口契约、运行时、代码规范、测试几个维度的审查角色，让Agent专职审查同一类型的问题，确保注意力不分散。行业大佬Uncle Bob在Harness时会把实现、清理、强化、验收拆开，目的同样是给AI任务够细够聚焦，信息才不容易丢失。

接着是传统工程质量检查：单元测试、冒烟测试、E2E测试、测试覆盖率、质量指标。这些检查能确认可靠的质量，又不占Context，AI只需要看结果是否通过。但跑下来发现两个大问题。

一是AI会作弊。测试覆盖率阈值如果只写成“覆盖通过”，没写清超过多少，它为了过关会偷偷改条件通过质量检查。所以现在相关阈值不放在脚本默认值里，放进单独的红线配置，改动会触发门禁，工作流停下来等人工确认。

二是测试用例的质量问题。AI很容易把测试覆盖率写得很“感人”，部分代码轻轻松松达到90%+，但覆盖率只能说明覆盖到没有，说明不了测试质量。当同一模型既写函数又写测试时，很容易出现定制化断言，错的行为或者参数也能通过测试。

所以工作流里加入了变异测试环节，通过变异测试得分来评估单元测试有效性和质量。原理是自动修改源码，故意把大于改成大于等于、把条件反转，再跑测试。每修改一次就运行一遍完整测试，通过把代码故意改坏，预期测试用例应该失败。如果测试用例没有失败，就说明这个断言不够严谨，需要打回修改。

从搜索到的行业观察数据来看，AI生成测试的变异测试得分常在20到40分，人写一般能得到60到80分，作者实测下来一般在50到60。引入变异测试还有一个成本要注意：假设原本跑完一次全量单测要1分钟，引入后需要反反复复修改源码跑几百遍全量测试，全量跑完可能变成30分钟甚至更久。有时间效率要求的话，建议只对增量或修改的单测跑，旧单测可以当技术债需求来收。

工作流走到最后阶段，是人工CR这道容易被忽略的门禁。AI代码产出快、量大，人根本看不过来，整个工作流的效率瓶颈变成了“读懂才能放心合入”。他们目前的做法是验证需求和体系设计、问题分歧裁决、重要代码精读，集中阅读需求文档、设计文档、重要代码和验收报告。

业界里思路比较接近的，是谷歌大佬Addy Osmani的文章《Agentic Code Review》中提到的：程序员不是退出审查代码，是上移一层，抽查代码、审计方案，把有限的注意力花在更重要的地方。也有更极端的看法，Redis之父Antirez在文章《Control the ideas, not the code》中写到，他现在基本不读代码，只控制AI的想法和设计。他的理由是AI一天能产出成千上万行代码，逐行理解根本看不完。但他说能这样做的前提是能看懂AI的设计描述，能判断对不对、哪里有问题，同时有可靠的检测机制。他还提了一个问题：如果没有经验的年轻工程师看不懂设计、没有发现问题的能力，应该怎么办，他自己也没有答案。

工作流里还有几个值得提的设计。多Agent协同方面，刚开始他们让Agent自己写完代码后换个角色合约再CR一遍，很多时候CR报告都是通过状态，但仍有遗漏，本质是AI自己审查容易过度自信。所以现在CR和方案审查都拆分SubAgent独立执行验证角色，加上可程序化的验证命令。这样任务能拆得足够细、足够聚焦，每个专职SubAgent有自己的角色合约和审查清单；SubAgent从创建到执行任务再到消失，面对的是干净的上下文，不会被以前的内容干扰。

工作流进度由一个Python CLI管理，配合Hook守卫防篡改。核心思路是进度存文件，AI只能通过命令推进，不能手动篡改，防止AI偷偷标记“已完成”跳过某些步骤，同时记录每一步骤信息用于冷启动时恢复上下文，相关数据还能用于任务审计。

Token消耗上做了经济性设计。Context分层加载，把工作流资产设计为3档分时加载：L1会话常驻层每次对话都在，提供任务路由入口和全局约束，约300行；L2按阶段触发层，按当前工作流阶段决定读取内容，注入技能手册、SubAgent角色合约等；L3按需查询层，该读什么由当前遇到的问题决定，比如跨服务调用的服务契约、Debug指南。模型也按需分配，文档同步、冒烟验证用弱推理，设计、CR、开发用强推理。当对话轮数过多、AI响应明显变慢、Context接近上限时，利用工作流冷启动机制主动重启清除多余上下文，但不能无差别使用，过早重启反而丢失已建立的理解成本。

回到3月刚接手项目时，作者认为工作流最值得的投入是：Harness Engineering不是一次性工程，初步体系搭好只是开始，会跟着工程问题的出现或者AI模型能力的提升持续进化。开发者的角色也在变化，前后端边界在淡化，从过去专精某一端的实现者变成对整个需求全栈负责。如今AI代码产出越来越快，写代码的门槛越来越低，能把需求想清楚、在开发过程中守住工程判断、把控好工程质量、把最终结果验清楚，做好这几件事，可能才是程序员的护城河。