AI生成的代码看不懂就扔掉重来：一位首席架构师的 5 条 Agent 编程反常识原则

翻译｜林绮蓓 编辑｜蔡芳芳 “我已经很久没好好看过代码了。”在 AI 编程工具越来越强的今天，这句话开始成为一些开发者描述自己工作方式的方式。需求交给 Agent，代码由它生成，测试和审查还可以交给其他 Agent。软件似乎从来没有这么容易做出来过。 但另一种情况也越来越常见：项目启动得很快，做了几轮后却很难继续。Agent 悄悄换掉原有部署脚本，同一个功能在代码库里被实现了五遍；一旦需要大幅调整架构，它往往选择继续打补丁。开发者拥有了大量能运行的代码，却未必还看得清系统究竟是怎么搭起来的。 在首席架构师 Carlos Kelkboom 看来，问题已经延伸到人与人的协作。开发者遇到问题越来越习惯先问 Agent，PR 下的讨论逐渐减少，与用户沟通、理解产品需求、反复思考架构的过程也更容易被跳过。代码可以更快生成，但一个项目为什么做、为谁做、以后怎样演进，仍需要有人作出判断。 在 Patrick Akil 主持的这期播客中，Carlos 分享了五条颇为反常识的 Agent 编程原则：第一，亲自搭建代码骨架，提前确定目录、关键文件和函数签名；第二，禁止主 Agent 直接修改代码和文件，充分理解需求后才启动执行 Agent；第三，生成的代码看不懂就扔，执行结果隔离在 Git Worktree 中，一旦发现偏离预期结构，就直接舍弃重来；第四，尽可能让 Agent 一次性完成较大任务，避免反复修改导致代码不断打补丁；第五，让多个 Agent 并行探索不同方案，例如三个 Agent 分别开发，再由第四个 Agent 比较结果，只合并好的部分。 两人的分歧也贯穿了整场对话。Patrick 更看重工具能否尽快做出有用的东西，Carlos 则反复追问：开发者从中学到了什么？如果代码越来越便宜，工程判断、代码审查和初级工程师的培养该如何改变？讨论最终从编程实践延伸到未来编程语言、AI 泡沫，以及一个更根本的问题：当 Agent 能写越来越多的代码，人类工程师还应该把时间花在哪里？ 太长不看版： Patrick：软件工程这几年最值得警惕的变化是什么？ Carlos：开发者越来越习惯与 Agent 一起工作，却减少了与同事、用户的交流。PR 里的讨论变少了，产品意识也可能因此被削弱。能很快做出一个演示，和真正理解用户、把软件长期做好，是两回事。 Patrick：Agent 随时能回答问题，为什么还要花时间找人讨论？ Carlos：因为即时答案也会改变思考习惯。Agent 回答得快，还可能顺着你的预期说；人与人的讨论慢一些，却能带来不同经验、质疑和反馈。学习不只是得到答案，还要留出时间自己消化。 Patrick：为什么你坚持先搭代码骨架，再让 Agent 动手？ Carlos：Agent 擅长迅速找到一条实现路径，却未必顾得上新代码与整体架构的关系。我会先建目录、文件和关键接口，明确模块职责。否则，代码重复、“上帝对象”和莫名其妙的新脚本都可能出现。能不能把方向交代清楚，是我认为拉开 Agent 工程师效率差距的关键。 Patrick：不熟悉一门语言，也能先搭出合理的骨架吗？ Carlos：可以先研究成熟的开源项目，让 Agent 对比设计模式、解释取舍，再自己动手写些注释和初步结构，反复讨论。关键不是让它替你作出所有决定，而是借助它培养自己的判断力。 Patrick：为什么你的主 Agent 被禁止写代码、修改文件？ Carlos：我希望它先专心理解我在问什么，而不是听到问题就急着实现。我让主 Agent 负责对话、检索和确认意图，用多个模型辅助评分；只有当它对理解我的目标有超过 90% 的把握时，才向我提出启动执行 Agent 的建议。 Patrick：Agent 写完代码，你怎么审？发现不对又怎么办？ Carlos：先看是否符合我预先设定的结构。如果打开代码就认不出那些应该存在的东西，我宁可扔掉重做。我会在执行一两个小时后就暂停检查 Worktree；出了问题，就回到对话里查清是骨架、需求还是上下文信息相互冲突，再开新会话重试。 Patrick：为什么主张“代码便宜了，就应该经常推倒重来”？ Carlos：因为在我的经验里，Agent 对一次性完成较大任务比较擅长，对已有代码反复大改却不太擅长。既然生成代码的成本降低了，就可以并行探索不同方案，甚至让三个 Agent 分别开发、第四个 Agent 评估，不必为了保住已有代码而不断叠加补丁。 Patrick：如果人人都能靠 AI 写软件，还需要专业工程师吗？ Carlos：更需要工程判断。资深工程师要先厘清产品目标、架构、部署方式和安全边界，也要帮助新手学习这些取舍。我担心的一种情况是，我们培养了一代很会使用 Agent、却缺少独立开发能力的人。 Patrick：AI 生成的代码越来越多，代码审查应该看什么？ Carlos：除了最终 Diff，还应看前期需求和架构决策、每次提交如何推进方案，以及实际增加了哪些复杂性。可以借助静态分析、变异测试和新的可视化方式，但团队围绕 PR 的讨论不能因此消失。 Patrick：你怎么看 AI 的未来？这轮热潮会不会是泡沫？ Carlos：要分开看。AlphaFold、医学和材料科学等方向的突破让我觉得像魔法；LLM 在编程上的价值也很大，但巨额投入与产业承诺是否都能兑现，我有疑问。与此同时，权力向大型科技公司集中，以及 AI 是否真的缩小机会差距，也令我担忧。 开发者开始只和 AI 说话了 Patrick：今天的嘉宾是 Carlos Kelkboom，他是我认识的最出色的工程师之一。Carlos你觉得跟几年前比，软件工程最大的变化是什么？ Carlos：首先，我观察到一个我不喜欢的现象：开发越来越像一个人的工作，同事之间的合作越来越少。过去大家重视拉取请求（PR，Pull Request），相互协作，也会在自己和同事的PR下交流意见；现在这样的交流越来越少，甚至有人说PR以后可能会消失。现在你经常和智能体一起工作，却不再和团队一起工作。这是我观察到的趋势，也是我认为很危险的一件事。 Patrick： 你觉得为什么会这样？我有个猜测，可能和我们在 Reddit、YouTube 上看到的情况有关。那里有很多独立开发者，往往是他们最先尝试新技术。当然，这也可能只是我的信息茧房，不知道这个观察是否准确。那么，在规模更大的企业里，开发团队依然有很多人，大家既要和 AI Agent 协作，也要和同事协作，实际情况又是怎样的？ Carlos：我有个好处，就是完全不用社交媒体。我连 Reddit 账号都没有，LinkedIn 也只是拿来和你联系。我不太关注社交媒体上的讨论，但我读很多东西，包括文章和白皮书，也跟很多公司和员工交流，所以我的印象不完全来自网上的展示。 我认为快速做出个东西却不收尾，和认真做一款希望能长期使用的产品，完全是两回事，这就像是马拉松和短跑的区别。一个人独立做项目，往往差最后一口劲把它真正做完；把东西放到社交媒体或 YouTube 上展示，和真正完成产品，也是不一样的。 比如，现在网上经常有人展示自己如何快速“做出”一款游戏。我之所以给“做出”加引号，是因为游戏开发最大的难点其实在于倾听玩家的反馈，并把游戏设计做好