强烈建议经常用 AI 写代码的朋友，去听听 Carlos 的这期访谈。

他是一位业内顶级的首席架构师，在播客里他抛出了一个很反常识的规定，「AI 生成的代码，只要第一眼看不太懂结构，直接扔掉重来。」听到这句话，我一开始心里挺不服气的。大家现在找 Agent 帮忙，图的就是一个撒手不管，只要跑通就行了，谁还有耐心去逐行细看？但 Carlos 毫不留情地戳破了这个幻觉，他提醒大家，如果一味图快而放弃对代码结构的把控，后期必定会面临一个死局，极小的一个功能，代码库里都会长出五遍一模一样的废代码，整个项目彻底变成一团乱麻。作为在这个行当里摸爬滚打了二十几年的老兵，他非常干脆地给出了 5 条 Agent 编程实操原则。除了刚才说的「看不懂就扔」，里面甚至还有一条是「绝对禁止主 Agent 修改代码」。每一条都很辛辣，打破了我们平时的使用习惯。1、先把规矩和边界定清楚，再让机器干活拿到新需求，多数人的反应是直接让智能体写代码。Carlos 的做法完全不同，在机器敲下第一行代码前，他一定会亲自搭好整个骨架。他会花上几十分钟建立目录、新建空白文件并写好核心注释，甚至提前敲定类名和关键的函数签名。基础设施确立清楚了，才让智能体去填补细节。增加这步，是因为他看透了智能体的缺陷，「Agent 很擅长沿着一条路径快速解决问题，甚至可以说是暴力求解，但它经常忽略这些代码该如何融入应用的其他部分。」不提前划定职责，机器就会为了眼前的单点任务破坏整体内聚性，最终堆砌出无法维护的复杂对象。 为守住边界，Carlos 设了一条极严的限制，要求主 Agent 保持开放交流，专心理解需求，绝不能一听到问题就急着去实现。这引出了第二条原则，绝对禁止主 Agent 修改本地业务代码和文件系统。主 Agent 专门负责聊天、检索并确认真实意图。只有当它对目标的理解把握超过百分之九十时，才被允许提议启动子 Agent 去执行编码。这种物理隔离，从根源上阻止了机器拿到需求就盲目动手的行为。2、拥抱一次性生成，对无法辨认结构的代码零容忍子 Agent 启动后可能会连续运行几个小时。面对交付出的大量代码，大部分人的习惯是直接运行，报错了立刻让智能体去针对性修改。Carlos 同样拒绝这种做法，他的第三和第四条原则直指执行与验收。他主张尽可能让 Agent 一次性完成较大的开发任务。大量经验表明，智能体单次完整输出一套逻辑的表现，远好于在同一个代码库里反复大修。进入连续修改循环后，智能体极易丢失最初指令，只会顺着错误代码叠加临时逻辑，「因为在我的经验里，Agent 对一次性完成较大任务比较擅长，对已有代码反复大改却不太擅长。」为此，他的验收动作非常干脆，所有执行结果必须隔离在独立的 Git Worktree 里。他不去纠结单一功能是否跑通，而是快速扫一眼整体结构分布。对待偏离预期的结果态度非常坚决，「如果打开代码就认不出那些应该存在的东西，我宁可扔掉重做。」只要发现偏离了亲手搭好的骨架，他连深挖纠错的时间都不花，直接废弃整个工作分支。查清到底是骨架还是上下文信息冲突，调整后开新会话重跑。既然生成成本极低，方向偏离时推翻重来的效率，其实远高于在烂代码里逐行调试。3、并行多条开发路线，用算力换取工程判断的空间既然代码随时可弃，开发者就能用算力探索更多路径，这也是第五条原则，让多个 Agent 并行探索不同方案。面对同一需求，直接拉起三个独立分支安排智能体分别开发。最后引入第四个智能体综合评估，对比优劣，只挑选结构最合理、逻辑最清晰的一版合并。这套流程治好了 AI 开发半路卡壳的痛点，但也引出了更深层的行业追问，写代码变得如此轻而易举，人类工程师的核心价值究竟在哪。Carlos 对行业现状有个敏锐又担忧的观察，「开发者越来越习惯与 Agent 一起工作，却减少了与同事、用户的交流。」遇到难题第一反应是问机器，同事间激烈讨论代码质量的场景正大量消失。 即时的答案虽然便捷，却也剥夺了开发者自己消化知识、思考架构的时间。只追求程序快速运转而忽视可维护性，质量必然崩塌。所以他强调，「能够很快做出一个演示，和真正理解用户、把软件长期做好，是两回事。」在资深架构师看来，工具普及让产出代码不再是门槛。真正决定软件能走多远的，是开发者开工前理清产品目标、规划部署方式、设定安全边界的工程判断力。放弃对架构的控制权，盲目顺从输出，人就沦为了发指令的执行者。机器再强，也需要清醒的判断力来掌舵。