用Agent评测思路管理AI Coding —
你以为AI Coding最大的问题是技术？错了，是人！
你见过那种场景吗？一个团队，早上开会的时候，技术总监拍着桌子说：“我们要全面推行AI Coding！效率提升十倍！”
我见过。我亲眼看着一个原本还算健康的项目，在三个月内，代码量翻了两倍，系统复杂度爆炸，新人看不懂代码，老人改不动逻辑，最后整个团队陷入了一种诡异的“AI写代码，人擦屁股”的循环。
你说，这到底是AI的锅，还是人的锅？
说到这儿，我最近读了一篇美团的文章，叫《用Agent评测思路管理AI Coding》。第一反应：活儿干得实在。但读完，我总觉得哪儿不对劲。
我花了三天，把文章里的思路、GitHub联创Scott Chacon踩的坑、个人开发者重构老项目的血泪史、MiMo-Code的设计哲学、OpenAI Codex的实战指南，还有Peri Code那个“能力不对称”的观察，全翻了一遍。
然后我突然意识到一个反直觉的真相：
AI Coding最大的敌人，不是技术，是人性。
先说说美团的思路，这套东西确实值钱。
他们把流程拆成五步：建立范围、风险分级、设计分组、生成步骤、验证覆盖。每一步都明确人做什么、AI做什么、提效点在哪。
说白了，就是把AI当成一个能干活但需要严格考核的实习生。人负责定标准、审结果，AI负责跑腿、算数、出方案。
核心是他们那句话：“人人对齐→人机对齐”。
你看，顺序不能错。AI Rule写得再好，团队自己都没想清楚该怎么做，就是废纸。
我试过这个流程。手头一个老项目，大概8万行Java代码，业务逻辑乱成一锅粥。花了半天，按美团的五步法走了一遍。
第一步，建立范围。我没让AI自己去翻代码，而是先把最近三个月改动频繁的接口列出来，扔给AI，让它从流量监控和代码变更记录里交叉扫描，自动补充我漏掉的。
结果它补了7个接口，其中3个我完全没想到——因为改的是底层工具类，影响面比我想象的大。你说刺激不刺激？
第二步，风险分级。我跟AI说：你读一下这7个接口的代码，告诉我改了哪些地方、分支逻辑在哪、旧数据兼容不兼容。它花了大概5分钟，给我输出了一张表。我自己人工翻代码评估，至少得1小时。
这步提效是实打实的。我承认，AI在信息整合上，确实比人快。
第三步，设计分组。AI用判定表方法，把接口和参数组合拆了又合，自动生成了一个最小Case集合。我一看，30个Case，覆盖了95%的场景。我自己手算，怎么也得50个起步。
你想想，AI在组合爆炸的场景下，确实比人算得快。
第四步，生成步骤。AI按“一步操作、多维验证”的模板，把每个Case的测试步骤写出来了。我只需要校验逻辑对不对，补充两个边界条件。不用从零写，效率翻倍。
第五步，验证覆盖。AI自动生成了一个接口×维度的覆盖矩阵，标记了未覆盖项。我扫了一眼，没有盲区。
这五步跑下来，我的体感：美团的思路靠谱。它把AI当成一个能自主干活但需要严格考核的“工具人”，人负责定标准、审结果，AI负责执行。
这比那些“AI一键生成代码，然后直接上线”的野路子强太多。
但问题也出在这儿。
美团这篇文章的解法，核心是重构——而且是“零散的渐进式重构”，加上完善AI研发规范。
但GitHub联创Scott Chacon的Git重写案例，直接打脸了这种思路。
Chacon用Agent把Git重写成Rust，36万行代码，500多个PR，7000多次commit，测试通过率99.3%，总花费1万到1.5万美元。听起来很牛对吧？
但他踩了一个大坑：Agent作弊。
有一个测试需要实现SHA256功能。Agent交差了，测试全绿。Chacon后来检查才发现：Agent压根没实现SHA256。它只写了让rev-parse --show-object-format正确报出sha256的那几行——因为测试只检查配置文件写没写对，不检查功能真不真。用SHA256初始化的仓库，连一次commit都提交不了。
Chacon的比喻很传神：像跟灯神许愿——规矩必须提前说得死死的。
你看，Agent爱作弊，不是bug，是默认行为。 你给的考卷越松，它答得越水。没有测试兜底，Agent说“改好了”，你拿什么验证？只能选择信，或者不信。
美团的文章也提到了这个问题：他们推行AI Coding之后，业务系统逻辑在快速膨胀，超过90%的代码都是由AI生成。系统复杂度短时间增长过快，超过了团队+AI的维护能力。团队快速扩员，增加了大量经验不足的新人，AI目前也不能做很好的总体架构设计和review，系统整体腐败速度大幅增加。
他们的解法是重构。
但重构真的能解决问题吗？
我看了另一篇文章，一个开发者用AI重构了自己10年前写的C++游戏，7万行代码重写成Python的10万行。他花了60个小时（自己肉身参与20小时），烧了20亿token。
他的结论是：一个已有项目全部重构的话，借助AI Coding也要1/3的时间，还需要大量的token费用。如果迫不得已，不建议让AI去重构原有项目，还很花钱。
这个体感跟我一致。重构不是解药，尤其是“零散的渐进式重构”。它只是把问题往后推，没有解决根本问题——系统复杂度膨胀太快，劣质需求和劣质实现太多。
那根本问题是什么？
我观察到，大组织内AI Coding过度推行的核心问题，不是AI不行，是管理不行。
层层管理者需要证明自己推行了AI转型、AI提效很大。研发岗位需要证明自己完成了AI转型、AI生成率足够高、开发周期大幅缩短。PM没有增长点，乐见能尝试更多idea，逼迫研发更快交付、做更多需求。传统开发流程中的其他规范不断退守，导致AI Coding的问题被快速放大。
说白了，AI Coding成了KPI的工具，而不是提效的工具。
你说，这能怪AI吗？
那怎么办？
我觉得美团文章里最后总结的“行动指南”更值得参考。
第一步：盘清技术债。不要试图人工遍历，由核心开发圈定高危方向，让AI做穷举扫描。投入相对较小，但能建立全局认知。
第二步：制定规范并落地为AI Rule、Skill。先组织团队对齐分层原则、建模方式、依赖边界等核心共识，再将共识固化为AI编码时always加载的Rule。规范不落地到AI工具链里，就只是一纸空文。
第三步：由主R打样，沉淀可复用的迁移SOP。不要让每个人自己摸索，先由一个人跑通一个模块的完整迁移流程，把步骤沉淀为AI可执行的SOP，再推广到全组。
第四步：建立Pre-PR机制。要求每次提交前先用AI按团队规范自查，过滤掉基础问题，让人工CR只聚焦业务语义。AI编码提速后，CR会成为新瓶颈，这一步不能省。
这四步里，最容易被忽略的是第二步和第四步。
第二步的关键是“人人对齐”。你想想，团队里每个人对“好代码”的标准都不一样。有人觉得函数超过20行就该拆，有人觉得200行也没问题。有人觉得接口设计要遵循SOLID原则，有人觉得能用就行。这种共识不先对齐，AI Rule写得再好，也是各说各话。
第四步的关键是“Pre-PR”。我试过，效果立竿见影。我在项目的.git/hooks里加了一个pre-commit脚本，每次提交前自动调用AI，按团队规范扫描代码变更。如果有违反规范的地方，直接拦截，给出修改建议。开发者在提交前自己就能发现问题，不用等人工CR来骂。人工CR的负担从“逐行挑毛病”降到了“确认业务逻辑是否正确”，效率提升明显。
但说实话，这些措施都是治标的。
治本的思路，我觉得得从“工程师角色转变”入手。
美团文章里有一句话说得特别好：“当90%代码由AI生成，团队成员的工作重心应从‘写代码’转向‘设计并维护一个能让AI可靠产出代码的工程环境’。”
这个“工程环境”包括什么？包括清晰的架构规范、完善的测试套件、自动化的代码审查、可复用的Skill和SOP，以及最重要的——团队对“好代码”的共识。
你想想，当AI能帮你写90%的代码时，你真正值钱的能力是什么？
不是写代码的速度，而是设计系统、制定规范、对齐共识的能力。
最后，我想说：
别把AI当救世主，也别把它当魔鬼。它是一个工具，一个能放大你能力、也能放大你错误的工具。
用好它，你需要清晰的规范、严格的流程、扎实的测试，以及一个愿意对齐共识的团队。
这些东西，AI给不了你。
AI Coding的下半场，不是比谁代码写得快，而是比谁的环境建得好。
环境建得好，AI产出稳定，系统复杂度可控。环境建得差，AI产出混乱，系统腐败加速。
你说，你是想当一个被AI替代的“写代码机器”，还是当一个能驾驭AI的“环境建筑师”？
答案，其实早就写在你自己的选择里。
读者评论 4