受访的软件架构师 Carlos 立过一条近乎行为艺术的规矩：禁止自己的主 Agent 直接写代码——主 Agent 只负责提问、澄清意图、整理上下文，执行交给子 Agent。有一次 AI 连续干了几个小时，他看完结果，全部扔掉。
他讲的那个悖论值得每个正在上 AI 的组织记住：AI 在提高个人生产力的同时，可能正在削弱组织的学习能力。本篇把访谈里的七个判断逐一整理，最后附我们自己踩过的一个真实的坑，和给企业的三条落地建议。
AI 正在制造一个危险的悖论：每个人都变强了，团队却可能越来越弱。
过去年轻工程师提交代码，资深同事会追问"为什么这样设计、需求变了怎么办"——这些争论表面降低效率，实际在传递经验、形成团队共同的判断标准。现在一个 Agent 写、另一个 Agent 审，甚至流行一句话："先问你的 AI，再来问我。"人和人之间，不再交换判断。
十个人的效率各自翻倍，不等于团队能力翻倍。组织最值钱的不是把十个人的产出加起来，而是让十个人的判断能够相互校正。更隐蔽的代价在年轻人身上：直接拿到资深工程师的结果，却跳过了成为资深工程师的过程。
衡量团队有没有真的升级，两个硬指标就够：一个人离开后，别人能不能接手；一次错误发生后，经验能不能留下来。个人效率是流量，组织能力才是存量。
Carlos 学陌生技术的习惯：先让 AI 研究优秀开源项目、解释设计取舍，然后离开电脑去喝杯咖啡，让信息在脑子里消化。获得答案不等于形成理解——AI 能在十秒内解释一个复杂问题，却不能保证你下次遇到变化还知道怎么判断。
真正的分水岭不是拿到正确答案，而是答案出错、互相冲突时，你能不能指出问题。对应的练习：追问依据——结论从哪来？有没有反例？换个前提还成立吗？会提问只是起点，能反驳 AI 才开始拥有判断权。AI 替你完成一次任务，不等于替你积累一次经验。
规矩的起因：他开发游戏引擎时随口问 Agent 怎么看约翰·克里斯（John Cleese）关于创造力的演讲——这是探索，Agent 却答"要不要我把它实现到引擎里"。人还在思考，它已经急着动手。
于是有了那条规矩：主 Agent 不能改代码、改文件、动机器，只提问、澄清、整理上下文；并设一个内部门槛——任务理解的自信评分超过 90% 才提议执行。这是他的工作流规则，不代表模型真有 90% 准确率；重要的也不是数字，而是角色分工：主 Agent 负责把问题想清楚，子 Agent 负责把事情做出来。
他还让主 Agent 维护可检索的知识线索，保留项目做过的关键决定——否则每次新对话，AI 都把关键取舍重新猜一遍，今天的决策很快被明天的生成覆盖。未来优秀 Agent 的第一能力，也许不是马上行动，而是知道什么时候不该行动。
让 AI 开工前，他会先花二三十分钟、有时一小时搭"工程脚手架"：目录、模块边界、关键接口、数据结构、依赖关系，必要时写几个函数签名和注释。看似只是准备，实际是提前锁定影响整个系统的关键决定——没有框架，Agent 就会替你拆架构，拆错了可能一夜长出几千行错误代码。描述目标只是告诉 AI 去哪，规定边界才是决定它会不会走偏。
更反直觉的是：他尽可能把任务做大，而不是切小——Agent 擅长在清晰约束下一次完成完整任务，不擅长对混乱的历史代码反复打补丁。他吃过亏：一个月的快速迭代后，发现同一套逻辑被实现了五次，每段单看都能跑，放进系统全是重复冲突。
所以不是"大任务 vs 小步迭代"二选一：思考前置，执行集中；任务可以大，但边界清楚、中途检查、结果可审核。真正的自动化不是取消人的控制，而是把控制前移。
生成偏离架构、或没法迅速看懂为什么这样实现——他不修补，直接放弃该分支，回到需求和设计修正问题，再从干净的上下文重启。他甚至让三个 Agent 并行尝试，第四个负责提交，只保留真正有价值的部分。
背后的账：过去代码贵，推倒重来是损失；现在生成便宜，长期维护一套错误结构才是更大的浪费。写过不代表值得保留，投入过不代表值得继续。底线仍然在：便宜的是代码生成，不是质量责任——数据安全与产品信誉不能试错，所以要测试、架构审查、过程验证。
代码越便宜，越应该舍得丢弃错误代码；生成越容易，验证就越值钱。
Demo 证明你能够生成一个结果，产品要求你长期兑现这个结果。用户不会因为你一天写几万行代码付费，只会因为问题被可靠解决而留下。AI 降低开始的门槛，没有消除完成的难度——演示能力可以靠生成，信用只能靠兑现。
放大到整个时代：创造门槛下降，不等于财富和机会更平等。算力、基础模型、分发渠道和资本仍集中在少数公司手里；拿到工具，不等于拿到客户、数据、信任和议价权。当人人都能生成产品，生成产品本身就不稀缺了——稀缺的转向需求、信任、分发和长期交付。工具把入场券发给了更多人，但没有把赢家的席位一起发出去。
AI 改变的其实是能力的价格：代码更便宜，架构更重要；答案更便宜，独立思考更重要；个人执行更快，协作更重要；原型更容易，长期交付更重要。真正危险的是只统计前半句，却很少问：理解增加了吗？组织更强了吗？客户真的获得价值了吗？
我们内部有一条内容流水线：会议录音自动转写、自动摘要、自动归档进知识库，跑了一个多月很顺。结果一条 3 秒钟的误触录音进了系统——太短，AI 出不了摘要，管线每 5 分钟自动重试一次，试了一晚上。转写、摘要、归档全是自动的，唯独"这条值不值得处理"这个判断，没人管，也没有规则管。
按这套法则复盘，这就是没留检查口：自动化只保证顺的时候跑得快，例外全靠撞。修法也不是打补丁，而是把控制前移——超短输入直接过质量门，标记为噪声，不进重试。事很小，道理同源：自动化程度越高，越要在关键节点留一个判断——要么是人的判断，要么是一条写死的规则。
最后说句二十年制造业 IT 的感慨：剧情一点也不新。当年我们说"上了系统，管理就变了"，大量项目倒在同一个地方——部署完成了，理解没发生（那篇复盘的三类坑至今成立）。AI 只是把这对老矛盾放大了十倍。当每个人都在加速，最稀缺的，是那个敢于先确认方向的人。
不是让企业照搬，本质是角色分离：把"想清楚的"（提问、澄清、定边界）和"做出来的"（执行）分开，人至少占住前一端。小团队的最小实践：让 AI 先复述需求、列实施计划，人确认后再动手；结果不合意就重开一轮，不在错误代码上叠补丁。
三步补救：先给存量补一页纸"边界文件"（模块边界、关键接口、数据结构）；再立检查口——每次生成必须通过测试或审查才合入；对无法快速看懂的生成，按"重写比修补便宜"的新成本观果断重做。详见本文第九节。
