看不懂就扔掉：一位首席架构师的AI编程原则
10月19日，MiniMax M3.1 Flash发布；10月17日，DeepSeek-V4.1-Flash-1017更新。再往前几天，Meta推出Muse Spark Open；OpenAI更新GPT-6 Pro的并行Agent能力；Google也推出面向复杂任务的Gemini 4 Argon……
模型迭代越来越快，AI编程工具也在不断改变开发者的工作方式。生成代码、搭建网站、开发游戏，现在只需要几轮对话就能完成。可是代码写得更快，就意味着软件更好做了吗？
在播客《Beyond Coding》中，主持人Patrick Akil问了首席架构师Carlos Kelkboom一个问题：与几年前相比，软件工程最明显的变化是什么？
Carlos回答：“我注意到一个我不太喜欢的现象：开发者之间的协作正在减少。”“你会和自己的Agent一起工作，但不再和团队一起工作了。”
AI带来的编程变化，早已超出代码生成本身。如何把控代码质量、安排不同Agent协同工作，以及在效率提升的同时保留工程判断力，都成了开发者应该面对的新问题。
围绕这些问题，Carlos分享了自己的实践经验。他总结的五条原则，提供了一套理解AI编程的具体视角：
1.亲自搭建代码骨架，提前确定目录、关键文件和函数签名。
2.禁止主Agent直接修改代码和文件，充分理解需求后才启动执行Agent。
3.生成的代码看不懂就扔，执行结果隔离在工作树中，一旦发现偏离预期结构，就直接舍弃重来。
4.尽可能让Agent一次性完成较大任务，避免反复修改导致代码不断打补丁。
5.让多个Agent并行探索不同方案，例如三个Agent分别开发，再由第四个Agent 比较结果，只合并好的部分。
AI只是项目马拉松的起点
在协作变少的背景下，还有一个更直接的问题：AI让启动项目变得容易，却没有让完成项目变得同样容易。主持人也有类似的感受，他发现，自己可以轻松启动很多项目，却经常没有把它们做完。
Carlos曾经启动过五个编译器项目，最终真正完成的只有一个。项目开始却没有完成，并不是AI时代才有的现象。希望做出产品，开发者就不能停留在不断尝试的阶段。
Carlos用马拉松和短跑作类比，“快速做出一个东西却不把它完成，和做一个希望能够长久存在的东西，是两回事。一个人独自做项目时，通常不会再多走那一步，把它真正做完。”
Carlos还以开发游戏为例：“比如你会看到很多人“很快”做出游戏。我之所以要给“很快”打引号，是因为做游戏最大的问题，是听取用户意见并把游戏设计做好。你可以和智能体反复迭代，但你仍要和外部世界沟通。”
当生成代码越来越容易，开发者很容易完成一个初步结果。但却不一定愿意持续投入时间，解决后续的工程问题。Carlos告诫开发者：“你必须抵制那种一上来就立刻得到东西的多巴胺快感。”
干活之前先帮Agent定规矩
如果说快速启动项目是AI编程带来的便利，那么如何让项目持续迭代，就成了Carlos更关注的问题。
Carlos介绍了自己的工作流：开始开发前，他会先手动创建目录和文件，有时还会补充语言规范、代码示例和模块之间的关系。整个过程通常需要20分钟到1小时。
他把这一步叫做Scaffolding，也就是搭建脚手架：“比如我要写编译器，就会先建好目录，写出词法分析器，再写一点语言规范。我会安排好中间表示如何从抽象语法树一路流转的目录结构，也会用目标语言写出许多示例。之后，Agent就像一位大师一样，直接生成恰好适合这门语言的编译器。”
他解释了这样做的原因：“我发现，Agent很擅长用蛮力找到一种解决方案，但它们经常忘记这套方案应该如何融入整个应用。”
Carlos曾经尝试过直接让Agent从零开发应用。项目推进一两个月后，他发现代码越来越难理解，原有的部署脚本被其他脚本取代，部分新脚本的用途也不知道了。
Carlos建议，面对陌生领域，可以先找一些成熟的开源项目，让Agent帮忙提炼其中的优秀设计模式，等自己理解后，再从小型概念验证开始逐步搭建脚手架，并让Agent 帮忙检查设计是否合理。
基于前期框架清晰的基础上，Carlos倾向于提前规划完整的功能，再让 Agent一次性完成较大规模的任务。
“Agent不擅长修改，却擅长一次性完成。它们的训练好像更接近一次性任务，而不是在代码库上接受迭代式开发训练。”Carlos表示，“这正是脚手架发挥作用的地方，大部分东西已经被规定好了。”
当然，Carlos不主张所有项目都投入一样多的准备时间。只是验证一个想法的话，开发者完全可以快速尝试，一旦方向不对马上重新开始。
他分享了一种并行探索的方法：“建三个分支，让三个智能体分别在三个分支或工作树里完成工作。然后让第四个Agent比较三份结果，只合并其中好的部分。”
看不懂的代码，直接扔掉
AI能快速生成代码，也能根据反馈不断修改。可是随着项目规模扩大，重复实现、模块混乱和架构偏离等问题会逐渐累积。
Carlos曾让Agent开发一款编译器。一个月后，他让Agent检查列表功能，结果发现，同一个功能竟然被重复实现了五次。每次修改可能都解决了眼前的问题，反复叠加后，代码却越来越难维护。
所以，他会定期检查代码是否符合预期。如果实现方向偏离，宁愿回退重做，也不愿在错误的基础上继续打补丁。
Carlos说得很直接：“它们目前还不擅长构建一个完整的应用。”他还有一条判断标准：“如果我看不懂，我就把它丢掉”。
这里的看不懂，是代码已经偏离了原先设定的结构和预期。Carlos会先检查实现是否符合设计；如果关键部分对不上，就回退当前结果，重新梳理需求和脚手架，再启动新一轮任务。
在国内，美团技术团队于今年5月公开过一项工程实践。其负责的业务系统规模达到31万行代码，90%以上都由AI生成。随着系统快速扩张，团队发现如果缺少统一的架构规范，不同开发者借助AI生成的代码会加剧系统复杂度，历史技术债也会拖慢后续迭代。
为此，团队将工程规范转化成AI能执行的规则，还在提交代码前增加AI自查环节，让模型先检查规范、缺陷和异常处理，再由工程师重点审查业务逻辑和技术方案。
个人开发者通过阶段性检查控制代码质量，企业团队则需要将规范落到自动化检查和审查流程里。这说明，代码生成速度提升后，质量检查必须跟上。
既然Agent一次能生成大量代码，那么审查也面临新的压力。Carlos的建议是，继续保留正常的迭代和审查流程。“大家常拿代码量太大当理由。可如果代码太多，为什么不让Agent少写一些？”
与其一次生成大量代码后再集中检查，不如控制每次变更的规模，增加审查节点，并保留开发者之间的讨论。这样更容易发现问题，也能让团队理解代码为何发生变化。
主Agent不写代码，只负责理解你的需求
Carlos还设计了一套特殊的Agent工作流：直接交谈的主Agent不改代码，也不碰文件系统，它只负责交互。真正工作时，再派出子Agent。与此同时，还会运行另一个具有相同行为的主Agent循环。
主持人很疑惑：“为什么默认不允许主Agent改任何文件？修改文件本来就是它们能做的事，而且它们对此非常积极主动。你却有意识地禁止它们这样做，为什么？”
Carlos说：“因为我希望它专注于我真正问的问题。”他曾经在做游戏时，问AI怎么看待John Cleese关于创造力‘开放模式’和‘封闭模式’的那段演讲？对方随即反问Carlos：“要我把这个实现在你的项目里吗？”
他突然意识到，“如果Agent看待所有问题的角度都只是‘我现在能不能替你写代码’，我怎么可能得到一个好答案？”所以，他将主Agent设置为一个默认不修改文件的角色。这个Agent负责讨论、解释、澄清需求，也可以调用子Agent完成实际工作。
为了避免Agent在没有充分理解任务时就开始执行，Carlos引入了置信度评估机制。只有当系统判断自己对需求的理解程度超过90%时，才允许启动子Agent。“一旦启动子Agent，它们就可以直接完成任务，跑十二个小时也没关系，可以同时启动多个Agent，我不在乎。但在它极其确信自己理解我的意思之前，不准开始。”
这套流程把需求讨论放在了执行之前。开发者可以先把目标、设计思路和约束条件梳理清楚，再让Agent集中完成工作。
一种全新的编程语言
Carlos认为，“我们正站在需要一种新编程语言的临界点。”他提出有几个问题必须改变：去掉堆内存，开发者不再需要指针，不需要动态内存，不需要围绕它们产生的那些东西。
这门新语言应该分为三个层次：第一层供人类表达需求，可以结合自然语言和结构化语法，描述组件及其功能。第二层系统可以生成图表、视频等可视化内容，让开发者检查系统准备如何实现目标，再进一步交流调整方案。第三层再将确认后的设计转换成机器能执行的表示，尽可能提高运行过程中的确定性。
Carlos认为：“我们需要重新回到一种状态：可以推理机器上实际在运行什么，而不是面对如今这种不可控的AI式东西。”
为什么确定性语言如此重要？想象一颗卫星，把它发射到太空，它的内存是有限的。如果程序使用堆分配，卫星里就可能出现内存不足异常或空指针异常。我们正越来越多地进入机器人、卫星、机器学习等领域，所以希望系统尽可能确定。
交流协作是AI coding时代下的第二语言？
AI编程降低了开发门槛，如果越来越多代码由Agent生成，开发者还需要花时间学习编程语言、框架和底层原理吗？
在Carlos看来，有扎实基础的开发者更能发挥AI编程工具的优势。知识需要时间才能真正内化，只是让Agent生成代码的话，其实自己并没有学到这些东西。他还担心，开发者依赖向AI寻求帮助，与他人的交流随之减少。
有人甚至会直接告诉同事“先问你的Agent，再来问我。”这涉及到另一个容易被忽视的问题：独立思考和创造力需要空间。
Carlos借用John Cleese关于创造力“开放模式”和“封闭模式”的观点。开放模式需要人处在放松状态，暂且放下眼前任务，让思绪自由流动，才可能产生新想法。
可是，社交媒体、AI随时随地向人们灌输信息，“你再也没有一个时刻，只是坐在那里、闭上眼睛，认识自己。”AI可以迅速给出答案，让多个模型相互质疑，但这不代表人能完全跳过思考过程。
软件行业未来需要什么样的人？Carlos希望软件开发能真正走向民主化，让更多人有能力通过软件解决现实问题。
例如，医疗服务中会存在一些流程问题，有人可以尝试开发软件，帮助相关人员解决实际困难。
过去那种“我们是专家，只有我们能做的说法已经行不通了。”主持人也表示，能力下限被拉低，入门门槛突然变得人人可及，“但我又觉得，在这个行业工作多年的人知道什么是对的、什么是错的；新一代还没有形成那种品位或直觉。”
Carlos回应：“如果你看看学校里选择工程，尤其是软件工程的人数正在下降，就会发现未来非常可怕。我们不再培养初级工程师，只是把智能体交给他们。”
他提出了一个极端可能：如果未来Token变得极其昂贵；或者AI因为某种原因消失了，那么一切都会垮掉。
顺着Carlos的话，主持人提出疑问“这是一场泡沫吗？泡沫会破，最后什么都不剩吗？”
Carlos谈到，三件事目前正在发生：
第一，AI确实带来了革命性的突破，在医疗、材料科学、机器人等等领域，这些都令人震撼，非常美。Carlos用“魔法”形容这个世界。
第二，大语言模型酷得惊人，但它们非常浪费，能源效率很低。Carlos认为这是一场炒作，尽管它们在编程中带来的收益确实极大。公司投入巨额资金，却不确定能否兑现对所有人许下的承诺。
第三，权力平衡发生极大变化。那些规模最大的公司几乎全是科技公司，Carlos担忧未来的隐私安全问题。AI一直被宣传成一种“伟大的平权工具”，但目前还没看到它真正让大家变得平等，未来可能只是富者愈富。
在访谈最后，Carlos认为，我们都越来越孤立在自己的世界里，唯一的对抗方式，就是重新聚在一起，一起动手，一起犯错，一起欢笑，一起学习。”
本文来自微信公众号“数智奔流”，作者：田渝，编辑：沈校，36氪经授权发布。