发表于 | 分类于

Burn Rate

——Paul Graham风格：极简、反直觉、创业者视角

整理自一场三小时对谈。一个工作十年的程序员和一个大二学生，聊AI、聊代码、聊钱、聊人生。以下是最锋利的部分。

一个大学老师问学生：你不自己写代码，怎么知道AI写的是对的？

这个问题听起来很有道理。但它有一个隐含的假设——人读代码就能确保它是对的。

如果这个假设成立，公司就不需要测试人员了。

事实上，在工业界，没有人通过“读代码”来保证正确性。你通过测试来保证正确性。单元测试、集成测试、端到端测试。代码是否可测试，比代码是否被人类读过，重要一百倍。

而AI恰好让测试变得极其便宜。以前TDD（测试驱动开发）是个好主意但没人愿意做——太反人类了，先写测试再写实现，多出来的工作量谁愿意干？但AI不在乎。AI就是牛马，你说先写测试就先写测试。

所以一个有趣的反转出现了：TDD，一个存在了二十多年但一直被程序员抵制的方法论，在AI时代突然变成了最佳实践。不是因为人变了，而是因为做测试的成本变了。

这场对谈里最有意思的一个命题是——

一个人能有效烧掉的token数，约等于这个人的能力上限。

乍听之下这像是在开玩笑。但想想它的逻辑：

AI是一个放大器。你投入一个指令，它给你一个输出。输出的质量取决于两个变量：模型的能力，和你的指令的质量。

模型能力大家差不多（同样花钱用Opus）。差别在指令。而指令的质量取决于你的知识面、经验、判断力和想象力。

一个初级程序员可能只知道让AI“写一个登录页面”。一个高级程序员会说“用OAuth2.0实现SSO，考虑token刷新、CSRF防护、会话管理，然后写完整的测试套件”。同样一个模型，输出完全不同。

所以问题不是AI够不够聪明。问题是你能不能给它足够好的指令。你能给的指令越多、越精准、越有创造性，你能“烧掉”的token就越多，产出就越大。

Burn rate就是能力。

这个程序员每个月花1200到2400美元在AI工具上。他的一个重要发现是：

创新来自于浪费。

他一开始的200美元额度用不完。于是他开始做“没必要”的事——让AI控制浏览器帮他登录公司系统、让AI自己找优化方向而不是等他下指令、让AI从十个方案里自己选最好的。

这些在旧思维里都是“浪费token”的行为。但正是这些浪费让他发现了AI能力的新边界。如果他一直小心翼翼地省着用，他永远不会知道这些。

这跟创业一样。你不会通过精打细算发现product-market fit。你通过快速试错发现。试错就意味着浪费——但那些浪费是必要的学费。

他讲了一个例子。他让Cursor帮他优化登录流程，一开始要90秒。他说：“我希望你缩短到30秒以内，你现在是90秒，我很不满意，你自己去优化。”

注意他的措辞。他没有说“请把第三步改成并行执行”或者“把等待时间从5秒减到2秒”。他只说了目标，没说方法。

AI说60秒已经是极限了。他说“你是最智能的大模型，你一定可以”。最后真的降到了30秒。

这里面有一个深刻的管理学洞见：告诉下属目标而不是方法，是给对方最大自由度的工作方式。 大多数人会忍不住去指导过程——这恰恰限制了对方（不管是人还是AI）的可能性。

那个学生说了一句我觉得整场对话里最好的话——

“对AI的悲观，其实是对人类的盲目乐观。”

展开说：当你批评AI“不够好”的时候，你的参照系是什么？是人类吗？

那我问你：人类一行行读代码的正确率是多少？人类手动管理自己注意力的效果怎么样？人类凭直觉做的职业规划靠谱吗？

如果你诚实地回答这些问题，你会发现人类的基准线其实没那么高。

对AI的批评很多时候不是在维护一个更高的标准——而是在维护一种熟悉感。人们说“我不相信AI写的代码”的时候，他们真正在说的是“我习惯了相信自己写的代码”。但习惯不等于可靠。

这个程序员的哥哥第一次用ChatGPT时，问了NBA历史前十球员是谁，然后嘲笑答案。三年过去了，他可能还在嘲笑。而他弟弟已经用AI做了十几个APP、重构了整个工作流、每个月省下了几百个小时。

差距不在智商。差距在于：一个人把时间花在证明AI不行，另一个人把时间花在发现AI能做什么。

关于跨领域学习，有一个很精确的观察——

以前的比较维度很窄。你是后端程序员，就比后端能力。你是前端程序员，就比前端能力。分工明确，专长就是优势。

但现在分工在崩塌。前后端在融合。一个人用AI就能做全栈。如果你只会后端，别人不会专门搭配一个前端给你——你的人力成本就是两个人的。

所以关键能力变了。从“某一项技能有多精”，变成“能不能快速跨到一个新领域并达到及格线”。AI能帮你从0分到3分，但从3分到7分，需要你的学习能力和判断力。

这对“全面但不顶尖”的人来说其实是个好消息。以后的竞争越来越像CEO的工作——你不需要每个领域都是专家，但你需要知道每个领域的关键问题是什么、怎么用人（或用AI）、结果应该是什么样。

最后一个观点。这个程序员用了一套三步法来管理自己的注意力：量化→自动化→决策化。

第一步，量化。用APP记录阅读时间、喝水量、饮食、体重。不自动化，就手动记。

第二步，自动化。做成APP，让统计自动跑。手机一打开就记录。

第三步，决策化。基于数据给建议。连续几小时没喝水就提醒。连续几天喝太多就建议少喝。

这套方法论的本质是：不信任直觉，信任系统。

跟TDD的逻辑一样。你不信任“我觉得这段代码是对的”，你信任“测试跑通了”。你不信任“我觉得今天喝了够多水”，你信任“APP告诉我喝了1.5升”。

成功的路径可以复用。番茄APP验证了阅读，喝水APP验证了健康，饮食APP正在验证体重管理。每一个新场景都是同一个框架的新实例。

这场对谈的核心，用一句话概括就是——

在智能变得廉价的时代，瓶颈不是工具，是你的想象力。

你的想象力决定了你能给AI什么样的指令。你的指令质量决定了你能烧多少token。你的burn rate决定了你的能力上限。

所以，别省着用。

发表于 | 分类于

AI对谈七讲：一个程序员和一个大学生的认知碰撞

——万维钢风格：精英日课，洞见提炼

这是一期特殊的“精英日课”——不是解读一本书或一篇论文，而是整理一场真实的对谈。2026年4月的一个周日，工作十年的程序员李文业和大二统计学专业的学生葭月二三进行了三个多小时的对话。我从中提炼了七个核心议题，每个议题都有一个可以带走的洞见。

一、“读代码确保正确性”为什么过时了

这场对谈的起因是一位大学老师的追问：“如果你不自己写代码，你怎么判断AI写的代码是对的？”

学生当时答不上来。但程序员李文业给出了一个很犀利的反问——

李文业：你怎么能保证你读了代码，你就能判断它是对的？如果读代码就能确保正确，那为什么公司还需要测试人员？微信不是程序员把代码写出来就让大家用了，它还有专门的测试人员去保证正确性。

这个反问的力量在于：它把“代码审查”从一个神圣化的行为还原成了众多质量保证手段中的一种。而当AI能快速生产大量代码时，人工阅读代码就变成了一个性价比极低的手段。

更有意思的是TDD（测试驱动开发）在AI时代的复兴。TDD要求你在写实现之前先写测试——以前程序员觉得这“很反人类”，因为它消耗额外的时间和精力。但AI不嫌累。AI就像牛马一样，你让它怎么做就怎么做。于是TDD从一个“知道好但做不到”的理想，变成了AI编程的最佳实践。

洞见：卡尔·波普尔说科学的特征叫“可证伪”。代码也有一个类似的特征叫“可测试”。保证代码正确的手段不是“我读过”，而是“我测过”。当AI让测试的成本趋近于零，代码正确性的保障体系就会被彻底重建。

二、一个人能烧多少Token，就是他的能力上限

李文业提出了一个大胆的命题——

李文业：一个人能有效烧掉的token数，约等于一个人的能力上限。AI是一个放大器，初级程序员放大两三倍，高级程序员放大一千倍甚至一万倍。

这句话乍听夸张，但逻辑是自洽的。“有效烧掉”是关键词——不是乱花钱，而是你能想到多少有价值的指令去下达。这取决于你的知识面、经验、判断力和想象力。

他三月份花了1200刀（约8000人民币），四月预算翻倍到2400刀。而学生葭月二三坦承她的使用量连一个200刀的账号都用不完——“不是token的上限，是时间的上限。”

但李文业认为，更深层的限制是想象力。他讲了一个自己的经历：一开始200刀的额度用不完，于是他开始用“看似浪费”的指令让AI做各种实验。结果发现了AI能控制浏览器、能自主优化登录流程等新能力。“如果没有这种超出日常需要的支出，我是发现不了这些东西的。”

李文业：创新来自于浪费。

洞见：这跟黄仁勋提出的“token是新能源”的说法异曲同工。如果你还在用“这个问题值不值得动用AI”的心态使用AI，你的思维就还停留在上个时代。正确的心态是：“这个问题我为什么不先让AI看一眼？”从节省token转向消费token，就是从匮乏思维转向丰裕思维。

三、AI的两种主动性

葭月二三问了一个好问题：AI有主动性吗？

李文业把它拆成了两层：

手段主动性——在解决问题时的灵活性。他举了Opus 4.6的例子：当它发现从A点到B点走不通时，会自动尝试绕路，甚至跳过中间步骤直接去够最终答案。“它有好几次直接想修改底层代码去绕过某个限制。我有时候得盯着它，怕它用太非常规的手段。”

目的主动性——自己给自己设定目标。这个AI没有。“我会突然想着要不要业余也写代码，公司给的账号不好那我就自己买。这种驱动力AI不具备。”

洞见：手段主动性的强弱取决于模型能力和你舍不舍得花钱——用Opus和用免费模型，体验差了一个世纪。目的主动性则完全属于人类。在AI越来越能“怎么做”的时代，人类的核心价值越来越集中在“做什么”和“为什么做”上。

四、跨领域学习比专长更重要了

对谈中出现了一个关于“专才vs通才”的讨论——

葭月二三：有了AI之后这个社会不缺斜杠青年，甚至试错成本非常低。反而这个时候专长变得重要了。

李文业：我会认为跨领域学习的能力比以前更重要了。以前你是后端，只需要学后端。现在大家都是全栈——如果你只会后端，别人不可能专门搭配一个前端给你。

他用了一个CEO的类比——一个大老板不需要知道所有技术细节，但他要知道怎么用人、要什么结果、怎么分配资源。“你不觉得这个跟AI很像吗？”

以前的编译原理就是一个例子。对上一代计算机人来说，编译原理是基础中的基础。但今天绝大多数程序员用不上编译原理——除非你专门搞编译器。“需要懂的人自然会懂，其他人不需要。”

洞见：AI时代的竞争维度变了。以前可能只比一个维度（比如后端能力），以后是多维度的。这对那些跨领域学习能力强的人来说是好消息——AI能帮你在短时间内把一个新领域提到及格线，但从及格到优秀，还是需要你的学习能力和判断力。

五、注意力管理的三步法：量化→自动化→决策化

李文业分享了他通过做APP积累出来的一套“注意力管理哲学”——

第一步：量化。 用番茄APP记录阅读时间，拍照记录饮食，APP记录体重和喝水量。不需要自动化，手动记录就行。关键是建立“看数据”的习惯。

第二步：信息自动化。 做成APP，让数据的采集和统计自动完成。手机打开就自动记录打开次数和使用时长，页面自动生成图表。

第三步：决策化。 基于数据给出建议。喝水APP会在你连续几小时没喝水时提醒你；如果连续几天喝水过量，它会建议你少喝一点。

李文业：我的终极目标是手机上只有我自己做的APP，使用时长要占大部分。用这些APP的时候，我的注意力管理是最科学的，最符合我自己意志的。

洞见：这套三步法的底层逻辑是——人对自己的注意力分配能力是不可靠的（这跟行为经济学的大量研究一致）。与其依赖意志力，不如建立一个外部系统来校准你的行为。番茄APP验证了阅读量，喝水APP验证了健康习惯，饮食APP正在验证体重管理。每一个新场景都可以复用同一套方法论。

六、假设Opus成本下降100倍，你会做什么？

这是李文业提出的一个思想实验——

李文业：假设Cursor的Opus会员从200美元/月降到2美元/月，你会做什么？

葭月二三的回答很诚实：“我没有一个很确定的答案。我可能还没有放开手脚地去想象。”

李文业认为这正是需要做的功课：“你现在能想象到的都是你已经掌握的东西。要探索新的可能性，你就得花时间——花那些‘看似浪费’的时间。”

他举了自己的例子：现在他会让AI主动去找一个项目里10个可能的优化方向，然后他挑几个让AI去改，好的保留、不好的回滚。以前你不可能这么对待一个程序员——“你搞了两三天发现不行让他回滚，他第二天就离职了”——但AI没有这个问题。

李文业：我们的思维还停留在智能非常昂贵的时代。如果你想做前沿的事情，你的思维至少要比别人先进一个阶段。你要用明年的做法去做今年的事。

洞见：这个思想实验的价值不在于答案，而在于它暴露了你的思维边界。如果你想不出来成本下降100倍之后你能做什么不同的事，说明你的使用方式还有巨大的提升空间。正如以前电话费贵的时候人们只打“必要的电话”，现在通话免费了，打电话的方式和频率完全变了。

七、对AI的悲观，是对人类的盲目乐观

最后，我想用葭月二三在对话中说的一句话来收尾——

葭月二三：对AI的悲观，其实是对人类的盲目乐观。

这句话值得展开。

当人们说AI“不够好”的时候，潜台词是“人类的方式更好”。但你认真问一下：人类手动管理注意力的效果好吗？人类一行行读代码来确保正确性的成功率高吗？人类翻一本本书来做文献综述的效率够吗？

如果答案都是“也不太行”，那所谓的“对AI的批评”就不是在坚持一个更高的标准——而是在维护一种熟悉的、但可能已经失效的工作方式。

李文业讲了一个例子。他哥三年前第一次用ChatGPT，问了一个NBA历史前十球员的问题，然后开始嘲笑答案。“这就是很典型的——在新事物刚出来的时候，人们会迫切地证明自己更好，从中获得心理优势感。”

这种心态的问题在于：它会阻止你去学习新的东西。你如果把所有时间都花在证明AI不行上面，你就没有时间去发现AI能帮你做什么。

本期总结

这场对谈最有价值的七个takeaway——

  1. 保证代码正确的手段从“我读过”变成了“我测过”，TDD成为AI时代最佳实践
  2. 你能有效烧掉的token数≈你的能力上限，创新来自于“浪费”
  3. AI有手段主动性但没有目的主动性，人的核心价值在于“做什么”
  4. 跨领域学习能力比单一专长更重要了
  5. 注意力管理三步法：量化→自动化→决策化
  6. 思想实验：如果成本下降100倍你会做什么？——答不出来说明还有巨大提升空间
  7. 对AI的悲观本质上是对人类能力的盲目乐观

下期见。

发表于 | 分类于

漫长的星期天：AI时代的一场对话

——许知远风格：文学凝视，时代肖像

这是一场发生在2026年春天的对话。一位三十出头的程序员和一位二十岁的统计学女生，每周日通过视频通话讨论他们各自在AI时代的观察与困惑。这篇对谈录记录的是四月第一个周日的那场谈话。对话经过剪辑，但尽力保留了那些跑题的、犹豫的、未完成的片段——在这个所有人都在追求清晰答案的时代，这些模糊的瞬间或许更值得珍视。

一、三个老师，三个世界

四月初的昆明大概还有些凉意。葭月二三坐在宿舍里——六楼的研究生实验室，不同课题组的学生混杂在一起。她这学期遇到了三位老师，恰好代表了对AI的三种截然不同的态度。

“第一位江老师是比较开放的，但处于矛盾状态。”她说话的时候会稍微停顿一下，像是在确认自己的表述够不够准确。“他问一个学长PPT是不是AI做的，学长很不好意思地说是。然后江老师就提出了一个问题：如果下一代人都用AI了，他们是否还需要学习代码？”

她当时给出了一个她自认为合理的答案：有代码基础，能判断AI写的代码是否符合需求就行了。

老师反问：那你怎么判断它是不是对的？

“我不知道该怎么回。”

屏幕另一端的李文业——一个在深圳工作了十年的程序员——对这个问题有一个更干脆的回应。“这个观点已经过时了，”他说，“‘我为什么能确保代码对？因为我读过’——这个逻辑在今天不成立。如果读代码就能确保正确，那为什么公司还要有专门的测试人员？”

他从去年八月到现在没有自己写过一行代码。全部都是AI生成的。领导问起来他就直接说。同样用AI写代码，有同事被骂了甚至离职了——“因为他代码看都不看就敢提交。我是充分理解、充分测试之后才提交的。每次leader问我问题我都能立刻给出答案。”

但第三位老师的态度就没有这种可商量的余地了。

“他直接说‘你这个又是用AI写的吧’。”葭月二三描述那个时刻的语气里有一种被误解的委屈。“那个语气不是开放的，是‘你用这个玩意儿就不可取’。但相比于自己写，我花了更多的时间和精力去学习、去确认、去为文档里每一句话负责。”

老师不这么认为。用了AI就是判了标签。

二、旧时代的愧疚

对话在这里出现了一个微妙的转折。葭月二三不再是在描述外部的困境，而是转向了内心。

“我会有一种旧时代的愧疚感。就是觉得自己没有那种探索，没有经验的收获。做完之后就只是做完了，仅此而已。就是有一种被动地接受——它告诉我这个结果是最好的，然后我就去研究它为什么最好，然后写论文。总感觉少了点什么。”

她停了一下。

“少了点我的成分。”

这句话在空气中停留了几秒。如果你仔细听的话，你能听出这不是一个关于效率的抱怨，而是一个关于存在感的困惑——当AI替你完成了探索的过程，你获得了结果，但你失去了什么？

李文业的回应很实际：“你给AI的提示语，是所有人都能给的吗？”

“不是。”

“那你其实已经帮它压缩了可能性空间。思维要转变——你要找到你的成长点在哪里。”

这个答案当然是对的。但它没有真正触碰到葭月二三话语里更深层的东西。那个“少了点我的成分”指向的不是能力问题，而是一种身份焦虑：在一个过程被技术接管的时代，“我”在哪里？

三、创新来自于浪费

话题转向了钱。

李文业三月份在AI工具上花了1200美元——大约8000多块人民币。四月份他打算把预算提到2400美元，接近16000块。“一个人能有效烧掉的token数，”他说，“约等于一个人的能力上限。”

葭月二三听到这个数字的时候“有一点震惊”。但她随即说——“我又想到可以玩一个月，突然又变得很明朗了。”

然后她又退缩了：“我还是有一点紧张。我好像没有那么大的想象力。你扩大到2400刀，但是我的想象力可能只有200刀的范围内。”

这是整场对话中最打动人的时刻之一。不是因为200刀和2400刀之间的差距，而是因为她说出了一个很少有人愿意承认的事实：想象力是有范围的，而这个范围往往由你过去的经验和当下的资源决定。

李文业对此的态度是——去试。“我之前一开始不需要用Opus。但200刀的账号用不完，我就开始用一些看似很浪费的指令。后来就有了新发现——比如它能控制浏览器。如果没有这种超出日常需要的支出，我是发现不了这些东西的。”

他说了一句格言式的话：“创新来自于浪费。”

然后他讲了一个知乎上看到的故事：一个农村女孩考研，为了省几百块钱买了旧版教材。“你省了这几百块钱，但影响的是你整个前途。”

这个故事的逻辑和token经济学是同构的——你以为你在节省，其实你在缩小自己的可能性空间。

四、目的的荒原

“AI有主动性吗？”葭月二三问。

李文业把“主动性”拆成了两层。第一层是“手段主动性”——在解决问题的时候，AI已经展现出很强的灵活性。“我用Opus 4.6的时候，它有好几次发现从A点到B点走不通，就想着绕过去，甚至直接跳过B点去够最后的答案。”

但第二层——“目的主动性”——AI是不具备的。“我们会突然想着，要不要业余也写一下代码？公司给的账号太差了，我自己买一个。这种驱动力AI没有。”

葭月二三接了一句：“一边是要看AI成长成什么样子的小孩了，与此同时我们也要去探索自己到底想要什么。”

这句话说得很轻，但它指向了一个巨大的问题：在一个手段越来越不稀缺的时代，目的反而成了最稀缺的东西。你可以让AI帮你做几乎任何事情——但前提是你知道你要什么。

而“知道你要什么”这件事本身，可能是所有问题中最难的那一个。

五、对AI的悲观，是对人类的盲目乐观

对话接近第一个小时的时候，葭月二三说出了整场谈话中最被引用的一句话——

“对AI的悲观，其实是对人类的盲目乐观。”

李文业对此深表认同。他讲了他哥的例子：三年前他兴致勃勃地给家人推荐ChatGPT，他哥问了一个NBA历史前十球员的问题，然后开始嘲笑AI的答案多么不合理。“这就是很典型——在新事物刚出来的时候，人类会迫切地证明自己更好。”

葭月二三补充说：“在这种比较中获得心理上的优势感。”

这个观察精确得让人不舒服。当我们说AI“不够好”的时候，我们往往没有问：那我们自己够好吗？我们自己手动管理注意力的效果好吗？我们一行行读代码来确保正确性的成功率高吗？

如果这些答案都是否定的，那所谓的“对AI的批评”就不是在维护一个更高的标准，而是在守护一种熟悉的低效。

六、笨拙的爱与沙漠中的行走

对话在第三个小时转向了更私人的领域。李文业要去给同学的妹妹讲最后一次课——高考还有不到两个月。他问葭月二三：最后两个月，你回过头看觉得需要注意什么？

她的回答出人意料地温柔。

“我每天去吃饭的时候脑袋都是懵懵的，整个人目中无神地走到我妈面前。有一次她突然给我一个拥抱，说你不要压力那么大。我就真的很想哭。”

她说家里对她的期待从来没有她对自己的期待那么强烈。过年回家妈妈说：你要是不想读研究生，直接去工作也可以。“我会感觉到一个非常笨拙的爱。”

然后她讲到高三有一次心情很不好，跟爸爸说帮我请个假，我要去附近的公园走一走。“我爸没有问我到底怎么回事，就直接说好。我的生活里没有太多的杂音。”

在谈到保研选校的焦虑时，葭月二三说了一段很长的话。大意是她有能力够到好学校，但又达不到顶尖，所以没有很强的理由告诉自己“你是非常自信的”。

李文业回了一个故事。万维钢专栏里的一个人，国内211毕业想去美国读研，没有按正常路径走，而是直接给系主任打电话。系主任说：我们不只看绩点，我们要的是最适合的人才。最后他申请上了。

“有人做过实验，在大街上找陌生人借手机打电话，成功率是95%。你低估了别人的善意。”

葭月二三说：“但主要是你不知道他到底想要什么。感觉像在沙漠里走路，有的人走得比你快。”

李文业说：“很多天龙人都不需要自己走。”

葭月二三接：“人家直接飞过去。”

然后两个人笑了。

尾声

对话结束的时候，他们约定了四月份的目标——使劲用token。李文业说“花钱也不是那么容易的”，两个人都笑了。

如果你从远处看这场对话，你会看到一个很典型的当代场景：一个年长一些的人用自己的实战经验试图帮助一个年轻一些的人少走弯路，而那个年轻人带着属于自己时代的困惑——那些困惑不完全是知识上的，更多是关于“我是谁”和“我要去哪”的。

这些问题AI回答不了。但有意思的是，正是因为AI替代了越来越多的技术性工作，这些关于自我和目的的问题反而变得更加迫切。

当手段不再稀缺，你得面对那个一直被忙碌所掩盖的问题：

你到底想要什么？

这个星期天还很长。

发表于 | 分类于

把AI作为方法：一个程序员与一个大学生的对谈

——项飙风格：田野视角，冷静诊断

2026年4月的一个周日上午，一位工作了十年的程序员李文业和一位云南大学大二统计学专业的学生葭月二三，进行了他们的例行周会。这场对话持续了三个多小时，覆盖了AI与代码教育、token经济学、注意力管理、人生取舍等话题。以下是经过整理的对谈实录。对话中的犹豫、跑题和未完成的思考被有意保留——它们本身就是这个时代的田野笔记。

一、三位老师：同一个校园里的三个时代

葭月二三：我这学期接触了三位老师，他们对AI的态度完全不同。第一位江老师，他是比较开放的，但处于矛盾状态。他当时问一个学长说你的PPT是AI做的吗？学长很不好意思地说是AI总结的，他说自己表达得没有AI好。然后江老师就提出了一个问题：现在学生不写代码了，下一代是否还要学习代码？

我当时说，有代码基础，能阅读代码、判断AI写的代码是否符合需求就可以了。然后老师回了一句：那你怎么去判断它是不是对的？那你是不是还是得学？

我不知道该怎么回。但我一直有一个声音就是AI没有那么厉害。

李文业：可能得分为两种场景。学术界有点像数学推导——你要保证从A推到B、B推到C都是正确的。但是在工业界，我只需要它是一个能用的产品就行了。

而且你怎么能保证你读了代码就能判断它是对的？如果读代码就能确保正确，那为什么公司还需要专门的测试人员？人工阅读代码在AI时代是一个性价比很低的手段。

编者注：这段对话有一个值得注意的结构。学生关心的是“AI的能力边界在哪里”，而程序员关心的是“保证正确性的手段是什么”。两个人其实不是在争论同一个问题。这种错位本身很有意思——它反映的是两种不同的焦虑：一种是关于知识的完整性的焦虑，一种是关于效率的焦虑。

葭月二三：第三位李老师就不一样了。他是数学系的，让我推导运筹学建模。当我把文档发给他的时候，他直接说“你这个又是用AI写的吧”。那个语气不是开放的——不是问你用了什么工具，而是“你用这个玩意儿就不可取”。

但是相比于自己写，我花了更多的时间和精力去学习、去确认、去为文档里的每一句话负责。老师不这么认为。他觉得你一旦用了AI，就直接给你判了一个标签。

李文业：同样是用AI做东西，我公司也有同事被骂了。领导很生气地在群里说，AI生成的代码你必须每一行都要读。但我从去年八月到现在一行代码都没自己写过，领导问我我就直接说是AI写的。为什么那个同事被骂了我没有？因为这是结果的问题。他的代码看都不看就敢提交，我是充分理解、充分测试之后才提交的。每次leader问我问题我都能立刻给出答案。

重点不在于是不是我写的——至少在工业界，这已经不重要了。

编者注：这里出现了一个很有趣的现象。在学术界，“谁写的”这个问题关联着“知识是否内化”的判断；在工业界，“谁写的”这个问题关联着“结果是否可靠”的判断。同一个行为——用AI写东西——在不同的制度环境中被赋予了完全不同的道德含义。这不是简单的“开放”与“保守”的区别，而是两套评价系统在用不同的标准丈量同一件事。

二、廉价智能与旧时代的愧疚感

李文业：TDD——测试驱动开发——以前我们都不喜欢用，因为它很反人类。我们的常识是先写代码再写测试。多写测试会影响开发效率。但AI不存在这个问题。它不会嫌累，我让它怎么做就怎么做。所以现在TDD变成了AI编程的最佳实践。

AI作为一个廉价智能，能替代我们做以前认为只有智能才能做的事情之后，很多事情都发生了变化。“我为什么能确保它对？因为我读过这个代码”——这个观点我认为已经过时了。

葭月二三：但是我会有一种旧时代的愧疚感。就是觉得自己没有那种探索，没有经验的收获。做完之后就只是做完了，仅此而已。总感觉少了点什么——少了点我的成分。

李文业：这个就是思维要转变。你要找到你的成长点在哪里。你给AI的提示语，是所有人都能给的吗？

葭月二三：不是。

李文业：那你其实已经帮它压缩了可能性空间。你会告诉它你做过哪些尝试、哪些走不通、哪些领域比较有可能性。你有新时代的工具，就有新时代的缺陷，但好处远远大于缺陷。

编者注：葭月二三说的“少了点我的成分”，如果用人类学的语言来说，其实是一种“主体性的焦虑”。她不是在担心结果不好，而是在担心自己在生产过程中的位置被抽空了。这种焦虑值得认真对待——它不是守旧，而是一个人在试图理解：当工具替代了过程，我还是我吗？

三、你能烧多少Token，就是你的能力上限

李文业：你觉得你一个月能有效地烧多少钱的token？

葭月二三：不是token的上限，是时间的上限。我觉得我时间不够。

李文业：我很认同一句话：一个人能有效烧掉的token数约等于一个人的能力上限。AI工具是一个放大器。初级程序员放大个两三倍，最后结果也不会太高。但一个非常厉害的程序员有了AI之后，可能比普通程序员厉害一千倍甚至一万倍。

我三月份的支出是1200刀，四月份的预算我打算定2400刀。我也想看看全部花完的话会有什么发现。

葭月二三：我看到四月份的预算要快两万的时候有一点震惊。但我又想到可以玩一个月，突然又变得很明朗了。不过我还是有一点紧张——我好像没有那么大的想象力。你扩大到2400刀，但我的想象力可能只有200刀的范围内。

李文业：我之前一开始不需要用Opus的。但200刀的账号用不完，我就开始用一些看似很浪费的指令让它做事情。后面就有了新发现——比如它能控制浏览器。如果没有这种超出日常需要的支出，我是发现不了这些东西的。

创新来自于浪费。

编者注：“创新来自于浪费”这句话，放在更大的社会背景下来看，是一个很值得讨论的命题。它暗含的前提是：你必须先有浪费的能力。这意味着创新在某种程度上是一种特权——你需要有足够的资源、足够的安全感，才能去做那些看起来“没用”的探索。对于一个还在用200刀额度的学生来说，这不仅仅是“敢不敢花钱”的问题，而是一个结构性的起点差异。

四、AI有主动性吗？

葭月二三：之前好多老师都认为AI缺少主动性——就是能自己发现问题、解决问题的能力。但在我自己的使用体验上，我觉得它有一定的主动性。

李文业：我分两方面理解。在解决一个问题的时候，它的主动性已经很强了。我用Cursor里面的Opus 4.6，它有好几次发现从A点到B点走不通，就想着绕过去，甚至直接跳过B点去够最后的答案。这个主动性已经很强了。

但是“目的主动性”——自己给自己定一个目标——AI是没有的。我会突然想着要不要业余也写一下代码，公司没给我配好账号那我就自己买。这种主动性AI不具备。

葭月二三：对。一边是要看AI到底成长为什么样子的小孩了，与此同时我们也要去探索自己到底想要什么。

李文业：通过理解AI的主动性，我们其实也在关照自身——我们人类的主动性是怎么回事。

葭月二三：但我觉得现在大家对AI的使用太功利化了。你有用就是好的，没用就是坏的。可能还需要更多地去融合和体会。

五、注意力的管理：量化、自动化、决策化

李文业：我做了很多APP之后，发现了自己的一个注意力管理哲学。第一步是量化——番茄APP记阅读时间，拍照记录饮食，称体重。第二步是信息自动化——做个APP，自动统计这些数据。第三步是决策化——喝水APP会提醒我该喝水了，连续几天喝太多它会说可以少喝一点。

这些信息如果让我自己管，也能管，但成本太高了。我的终极目标是手机上只有我自己做的APP，而且使用时长要占大部分。

编者注：这套“量化→自动化→决策化”的框架，如果换一个角度来看，其实是一种非常现代的自我治理术。它的底层逻辑是：人对自己的身体和注意力的直接感知是不可靠的，必须借助外部系统来校正。这个判断可能是对的——但它同时也意味着，人与自身的关系正在进一步被技术所中介化。你用APP来管理自己喝水这件事，某种意义上和需要AI来确认代码正确性是同一个逻辑：不信任直觉，信任系统。

六、取舍是唯一的时间管理

葭月二三：我一直感觉时间不够。看完时间管理的书反而更不会管理时间了。

李文业：我自己从来没用过任何时间管理方法。我认为就是一个取舍的问题。我要维持每个月300小时的阅读时间，那我就不能去找一份996的工作，哪怕工资再高也不会去。时间永远是不够的。一天只有24小时，一辈子也就活个七八十岁。所以最后还是取舍——你只能做几件事情。

葭月二三：对AI的悲观，其实是对人类的盲目乐观。

编者注：这句话是整场对谈中最值得停下来想一想的一句。它的意思不是“你应该对AI乐观”，而是：当你因为AI“不够好”而放弃使用它的时候，你其实在假设人类的那一套方式是足够好的。但这个假设经不起检验。你自己手动管理注意力的效果好吗？你自己一行行读代码来确保正确性的成功率高吗？你自己翻书找资料的效率够吗？如果这些答案都是否定的，那对AI的批评就不是在维护一个更好的标准，而是在维护一种熟悉的无效。

七、大胆假设，厚着脸皮去试

葭月二三：我想发顶会文章，想去很好的学校读研。但我觉得自己以为自己很厉害，其实又不是很厉害。这种矛盾状态。

李文业：自信是来自于你做出来的东西。我自己认为AI能力比别人强，不是自己感觉的——我有数据支撑：我做的APP、我的代码质量、我的事故率、我的返工次数。

胡适说过“大胆假设，小心求证”。你想去清华跟某个老师做研究？那你就去考察他需要什么能力，甚至给他写邮件、手写信寄过去。你以为别人不会理你？有人做过实验，在大街上找陌生人借手机打电话，成功率是95%。你低估了别人的善意。

葭月二三：但主要就是你不知道他到底想要什么。感觉像在沙漠里走路，有的人走得比你快、比你更轻松。

李文业：有一句话叫——“爷爷我也想成为院士”，爷爷说“你已经是院士了，你只需要长大”。

编者注（笑）：这个笑话之所以有力量，是因为它揭示了一个不舒服的事实：起点的差异往往不是通过努力可以弥合的。但这场对谈里两个人共同认可的一点是——不管起点在哪里，行动本身是有价值的。哪怕最后够不上那个120分的老师，你在过程中积累的能力是通用的、可迁移的。“求乎上得其中”——这不是安慰，这是策略。

后记

这场对谈结束时已经过了中午。两个人约定了四月份要“使劲用token”——一个的预算是2400刀，另一个的目标是三天用完一个200刀的账号。

如果有一个观察者从外部来看这场对话，他会看到什么？

他会看到两个人在试图用自己的经验去理解一个正在快速变化的世界。一个人站在工业界，带着十年的实战经验和每个月上万块的AI支出，已经形成了一套可复用的工作流。另一个人站在学术界的入口，带着对数学建模的困惑、对导师态度的无措、对自己是否“够厉害”的忐忑。

他们之间的差距不仅仅是经验和资源——更是想象力的边界。一个人的想象力已经扩展到了“如果Opus成本下降100倍我会做什么”，另一个人还在“我的想象力可能只有200刀的范围内”这个位置。

但这不是一个悲观的故事。因为后者正在做的事情——把自己的困惑诚实地摊开，在对话中一点一点地调整自己的认知——正是“把AI作为方法”的第一步。你不需要一开始就知道答案。你需要的是一个足够好的对话对象，和一个愿意持续投入的态度。

这场对谈本身，就是一种方法。

发表于 | 分类于

1

前几天，我的阅读时间达到20000小时。

第1个一万小时的书山路，我走了整整7年。从2016年9月1日，到2023年9月26日，一共2581天，平均每天看书4小时。

第2个一万小时，我走了2年半。从2023年9月26日，到2026年3月23日，一共909天，平均每天看书11小时。除了吃饭、睡觉和上班，几乎所有时间我都用来看书。

有的人可能会问，你在之前的文章里，说你经常跟ChatGPT对话，怎么可能还有这么多时间看书呢？

因为我把跟ChatGPT对话，也算到阅读时间里。首先，我跟ChatGPT对话，要么是在讨论书里的内容，要么就是讨论延伸出去的话题，并不是闲聊。然后，ChatGPT输出的大段文字内容，也是在积累我的阅读量。

还有人可能会问，现在AI都能帮人阅读、帮人总结了，我们自己还有必要亲自读书吗？

我的回答是，不仅必要，而且比之前更加必要。

2

在解释为什么在AI时代，阅读能力对我们来说变得更重要之前，我来跟大家报告我看到的AI发展得有多快。

在AI冲击之下，程序员这个行业最为明显。大量的初级岗位被取消，几乎所有的公司都要求在职的程序员必须学会使用AI辅助编程工具，还有的单位会要求必须要有一半以上的代码由AI直接生成。

很多程序员都在焦虑，自己是不是快要被淘汰，要永久失业了。

我从去年8月份开始，就没自己写过一行代码，AI生成代码占比是100%。我不会焦虑，因为我觉得我比以前能力更强了。

以前的我，只要把功能写出来就完事了，还是会有很多bug。经过测试阶段，修复了一些bug，就发到正式环境给用户使用，还是会偶尔出问题。

现在的我，因为AI能快速地生成代码，速度是我手写的10倍以上，所以我可以花大量的时间去分析需求，跟AI讨论设计。在开始写代码之前，很多前置问题都能想清楚，不会经常返工。写代码的过程中，我会让AI写很多的测试代码，包括单元测试、集成测试和端到端测试，让它自己去跑，保证了代码的质量。

这样写出来的代码，基本上没有明显的bug。测试给我提的bug数量，随着我使用AI工具的熟练程度逐渐加深，变得越来越少。

同样一个任务，以前的我可能要干5天，现在的我只需要2天，质量却是之前好几倍。这么算下来，我的效率比之前提升了一个数量级。

这样的效率提升，有赖于AI工具的发展速度，这在一年前都是难以想象的。短短一年，换了人间。

3

AI工具发展得快，为什么我们还需要提升阅读能力呢？

第一，跟AI交互的效率要想高，我们必须要有足够的阅读能力。文字篇幅决定信息密度。如果想要把一件事情讲清楚，不可能短短一两句话就能说明白。AI输出的来龙去脉，如果我们的阅读能力不够，就很难一下子了解透彻。

我现在每天最多的工作形式，不是写代码，而是跟AI对话。这个需求是怎么回事，我们要怎么做。那个设计有什么问题，我们要怎么改进。这些代码要怎么写，我们来定个方案。

AI就像一个勤劳的下属，给我产出很多方案和代码，我要给它做审查、提建议和找错误。

第二，AI的能力越强，我们要看懂它产出的内容就要不断学习。

AI经常会给出我以前没接触过的建议，以前没看过的方案。如果我一味拒绝，就限制了AI的能力。如果我盲目接受，就会引入巨大的风险。我必须学习，而且是快速学习，学习这些概念和知识是怎么回事，判断AI给的建议是不是靠谱，方案是不是可行。

第三，AI工具让每个人都很容易跨界，侵入别人的“知识领地”。

以前，前端看不懂后端的代码，后端看不懂前端的代码。现在有了AI，不懂代码也能指挥AI写代码。我不会写手机APP的代码，但是我懂需求，我懂交互，就可以给AI下指令，让它给我做了好几个iOS APP，而且还非常好用。

现在所有人都具备这种跨界的可能性，竞争格局会有一个天翻地覆的变化。

因此，不管是与AI交互，还是本领域的深耕，抑或跨领域的学习，都需要强大的阅读能力。阅读，是最高效的信息获取和知识学习的手段，没有之一。

4

那么，我们要如何提升自己的阅读能力呢？

第一，我们还是要读纸质书，尤其是在校学生。读纸质书，就像是打基础，就是学走路。直接看电子书，或者只跟AI对话，基础会不牢靠。

这个阶段就是积累阅读量。没有量变，就没有质变。至少要有2000小时的纸质书阅读经验才行。

第二，阅读要学会提问题。打好基础之后，就可以开始跟AI对话了。看书过程中，遇到什么问题想不明白，有什么问题引起了你的好奇心，都可以跟AI讨论。

这个阶段就是滋养你的好奇心，培养你的批判性思维。至少要有500小时的AI对话经验才算合格。

第三，我们要学会挑选学习资料。经历了前两个阶段，我们积累了足够的阅读经验，有了一定的判断能力之后，就可以有意地挑选学习资料了。挑书，要挑适合自己的书。挑文章，要挑爱读的文章。

最终，我们可以让AI给自己生成文章。如果对某个主题感兴趣，我会先跟AI讨论。讨论了几个来回之后，初步形成结论了，我就让AI生成一篇10000字左右的文章。经过几轮不同模型的润色和改写之后，会上传到我的个人图书APP，我可以在APP里阅读和学习。

5

除了健身和睡觉，我都会坐在电脑面前，要么用AI写代码，要么用AI学习，其实都是在阅读、思考和学习。

AI发展给我带来的不是焦虑， 而是惊喜，持续不断的惊喜。模型版本隔三差五就有更新，能力又有所提升。没有一个人会嫌弃自己的工具太好用。

我其实不知道程序员这份工作是不是可以做到退休，还可以做多久。我不太关心这个问题。我只知道在这个AI时代写代码很好玩——能赚钱是最好的，以后如果赚不到钱我也还会一直编程。

就像阅读一样，我刚开始看书的时候，也不知道看书会给我带来什么好处。我只是模模糊糊觉得阅读有意思，我喜欢阅读。

前面的两万小时目标达成了。接下来的目标是花三年多的时间，走完第3个一万小时。也就是在2029年11月，我一定要达成看书30000小时。

发表于 | 分类于

AI Coding 的真正难题不是 AI

大多数人对 AI coding 的理解是错的。

他们以为难题是”让模型写出正确的代码”。好像只要模型再聪明一点，context window 再长一点，事情就会自然变好。

但真正在生产环境里大量使用 AI coding 的人都知道，瓶颈从来不在那里。模型已经足够聪明了。问题是：聪明的模型在一个糟糕的系统里，只会更快地制造高质量的混乱。

这听起来像悖论，但它不是。理解这一点，是理解 AI coding 的起点。

有三个很老的理论——系统论、控制论、信息论——恰好能帮你理解这件事。它们各自问了一个不同的问题：

系统论问：整体是怎么组织的？
信息论问：信号是怎么失真的？
控制论问：跑偏了怎么拉回来？

你不需要读过这三个领域的原始文献。你只需要理解，AI coding 的几乎所有难题，最终都能归到这三个问题中的某一个。

系统问题

先说系统论。

人们讨论 AI coding 时最常犯的错误，是把它当成一个模型选型问题。”用 GPT-4 还是 Claude？””这个模型 SWE-bench 多少分？”这些问题不是无意义，但它们遮蔽了一个更重要的事实：模型只是系统的一个部件。

一个 AI coding 系统至少包含：用户的目标、代码库的现状、文档、prompt、工具链、测试套件、CI 流程、review 机制、部署管道和监控。这些部件之间的关系，比任何单个部件的性能更能决定最终结果。

这就像足球。你可以买世界上最贵的前锋，但如果中场传不出球，后防线乱成一锅粥，门将又不和防线沟通，这个前锋只会变成一个很贵的摆设。

OpenAI 的 agent 指南有一个很精确的表述：agent = 模型 + 工具 + 指令。三者必须协同。如果指令模糊，再强的模型也只是在猜；如果工具不对，再清晰的指令也执行不了。

这引出了系统论最重要的洞见：局部强不等于整体强。

我见过太多这样的案例：一个很强的模型放进一个没有测试、没有文档、没有 CI、没有人工审查的项目里，产出的代码看起来很专业，但一周后你发现架构被悄悄破坏了、命名被偷偷改了、异常处理链路断了。模型不是故意的——它只是在一个没有约束的空间里做了局部最优化。

反过来，我也见过用一个中等模型、但系统结构极好的团队：目标明确、上下文干净、测试充分、反馈快速。他们的产出反而更稳定、更可预测、更少翻车。

教训很清楚：不要投资在找最好的模型上。投资在建最好的系统上。

信号问题

再说信息论。

Shannon 在 1948 年提出了一个模型：信号从信源出发，经过编码，通过有噪声的信道，到达解码器，最后被信宿接收。他关心的核心问题是：信号在这个过程中损失了多少？

把这个模型搬到 AI coding 上，你会发现一个让人不安的对应关系：

你脑子里的需求是信源。你写的 prompt 是编码器。上下文窗口是信道。所有模糊的措辞、缺失的约束、矛盾的文档、无关的日志，都是噪声。模型的内部处理是解码器。最后生成的代码是信宿接收到的结果。

这个类比能解释一个让工程师们反复挫败的现象：你明明说得很清楚了，模型还是做错了。

但你真的说清楚了吗？

Anthropic 有一条建议特别好：把你的 prompt 给一个对任务完全没有背景的同事看，如果他会困惑，Claude 也会困惑。

大多数时候，工程师以为自己在”下达指令”，其实他们在做的事情更接近”在一个有损信道上传输一个编码质量很差的信号”。你的需求里有大量隐含假设，你的 prompt 里有大量歧义，你扔给模型的上下文里有大量噪声。模型不是不聪明，是你的信号到达它时已经面目全非了。

信息论还揭示了另一个被低估的事实：文档在 AI 时代变成了一等公民。

为什么？因为 LLM 不继承默会知识。人类高手可以靠直觉和经验补齐文档里没写的东西，模型做不到。它只能消费外显材料。所以，你的需求文档、设计文档、接口契约、样例输入输出——这些不只是给人看的说明书，它们同时也是给模型看的编码协议。

写好文档从来就重要。但在 AI coding 时代，写好文档从”应该做”变成了”不做就会翻车”。

纠偏问题

最后说控制论。

控制论的核心非常简单：定目标，测状态，算偏差，做修正。循环往复。

在 AI coding 里，这意味着什么？

意味着 AI coding 的核心能力不是生成，而是纠偏。

这个判断和大多数人的直觉相反。人们看到 LLM 能秒出一整个文件的代码，会觉得”生成”才是核心价值。但生成是便宜的——而且越来越便宜。真正昂贵的是判断生成结果对不对。

这就是为什么 TDD 在 AI 时代突然变得合理了。

很多工程师以前不喜欢 TDD，不是因为不知道测试重要，而是因为在人工时代，写实现已经够痛苦了，测试被当成额外负担。但 AI 时代翻转了这个等式：实现的成本塌陷了，验证的价值就相对飙升了。

TDD 本质上不是”先写测试”。它是先把”什么算正确”用机器可判定的形式写出来，然后才允许系统去搜索实现。用控制论的术语说，就是先设定参考值，再打开反馈回路。

控制论还有一条关键原则：反馈必须快。

反馈太慢的控制系统，和没有控制差不多。导弹如果每十秒才测一次位置，它就会飞到不知道哪里去。

AI coding 也一样。模型生成的速度极快，如果唯一的反馈点是”PR 合并后线上出故障”，那中间的所有偏差都在高速累积。更好的做法是把反馈层层前置：lint 在本地拦，单测在提交前跑，契约测试在 CI 里拦，trace grading 在部署前做，人工 review 作为最后一道门。

每多一层反馈，偏差就少累积一步。

真正的竞争力

把这三个视角合在一起，你会得到一个关于 AI coding 的统一认识：

AI coding 的真正操作对象不是代码，而是一个生成的可能性空间。系统论决定这个空间的形状，信息论决定空间里的信号质量，控制论决定空间的收敛速度。

一个模型很强但系统很差的项目，就像一台高马力发动机装在一辆没有方向盘的车上——跑得越快，偏得越远。

一个系统很好但模型一般的项目，就像一辆底盘扎实的车装了一台够用的发动机——不会飙出最高速度，但能稳定地到达目的地。

你应该选哪个？

如果你是在做 demo，选前者。如果你是在做工程，选后者。

方法论的重心迁移

这篇文章真正想说的，其实是一个更大的判断：

软件工程的方法论重心正在从”实现”迁移到”治理”。

传统时代的工程师是实现者：理解需求，手写代码，调试发布。AI 时代的工程师更接近于系统设计者、信息架构师和反馈回路工程师。

这不意味着写代码能力不重要了。它意味着写代码能力被纳入了一个更高阶的框架。最终，最有价值的工程师不是那个手写最多代码的人，而是那个能——

  • 把复杂目标变成清晰的系统结构
  • 把模糊意图变成高保真的信号
  • 把不稳定的生成纳入可控制的反馈回路

的人。

你可能觉得这些话太抽象。那我给你五个明天就能做的具体动作：

  1. 在让 AI 写代码之前，先写测试。不是因为测试高尚，而是因为它能让你更快地知道 AI 写的东西对不对。

  2. 写 prompt 之前，先把它给一个对任务没有背景的同事看。如果他困惑了，改 prompt，不要改同事。

  3. 反馈做短。能在本地验证的别等 CI，能在单测里抓的别等联调。

  4. 文档当工程资产写，不当行政材料写。因为模型真的在读它。

  5. 复盘 AI coding 失败时，区分三类原因：系统问题（边界没划清）、信号问题（信息失真）、反馈问题（测试没覆盖）。别只说”模型不行”——这句话几乎没有信息量。

结尾

三论不是老知识。它们是理解 AI coding 的底层语法。

系统论告诉你：别只看模型，看整体。
信息论告诉你：别只怪模型蠢，先看你的信号有多脏。
控制论告诉你：别指望一次说清，建反馈回路。

AI coding 的真正难题不是 AI。是你围绕 AI 建的那个系统。

发表于 | 分类于

AI Coding 的反脆弱：为什么追求完美 Prompt 的人注定失败

I. 脆弱性的伪装

现代技术工作者中流行着一种特别危险的幻觉：他们相信，只要找到一个足够聪明的 AI 模型，再配上一条足够精巧的 prompt，就能一次性得到正确的代码。

这种信仰和赌场里相信”必胜公式”的赌徒没有本质区别。他们都犯了同一个错误：把一个根本上不确定的系统当作确定性系统来对待。

OpenAI 自己的文档都白纸黑字地写着：生成式 AI 是可变的，同样的输入有时会得到不同的输出。换言之，你面对的是一个非确定性过程。你能做的不是消灭波动，而是学会在波动中存活。

但大多数工程师不愿意面对这个事实。他们更愿意相信”模型的下一个版本会解决这个问题”。这就像暴风雨前加固房屋和祈祷明天放晴的区别——前者是工程，后者是迷信。

II. 三副透镜

在中文学术圈，人们把系统论、控制论、信息论合称”三论”。这个并称粗糙，钱学森批评过它，学界对此有争议。但这不妨碍我使用它们。我不关心学科划界的政治，我关心的是：这三套理论是否能帮我们看清 AI coding 中的脆弱性来源。

答案是肯定的。

系统论揭示结构性脆弱：你的系统由哪些部件组成？部件之间有没有隐藏的耦合？边界是不是模糊到任何部件都可以越界？

信息论揭示传输性脆弱：你的意图在传递给模型的过程中丢了多少？噪声从哪些缝隙钻进来的？模型”理解”的那个东西，和你脑子里的那个东西，距离有多远？

控制论揭示动态脆弱：当系统开始偏离目标——它一定会偏离——你有没有机制去发现、去量化、去修正？还是说你只有在灾难发生后才知道出了问题？

脆弱的 AI coding 系统，通常在这三个维度上同时失守。而那些看起来”很先进”的系统——多 agent、长 prompt chain、花哨的编排层——往往恰恰是最脆弱的，因为复杂度本身就是脆弱性的温床。

III. 系统脆弱性：为什么更强的模型可能让你更脆弱

这是一个大多数人不愿意听的论点：在一个结构糟糕的系统中，模型越强，你越危险。

为什么？因为强模型会产出看起来极其专业的代码。它的语法完美，注释详尽，命名规范。你看了以后会觉得”太好了”，然后合并进主干。两周后你发现架构被无声地破坏了——异常处理链路断了，日志格式被改了，一个关键的不变式被违反了。

弱模型犯的错误是显性的：编译不过、测试挂了、语法有问题。你一眼就能看出来。强模型犯的错误是隐性的：代码能跑、测试能过、review 时看着很顺眼，但系统的长期一致性正在被侵蚀。

这和 Nassim Taleb 在《反脆弱》中的核心论点完全一致：真正的风险不是那些波动很大的东西，而是那些看起来很稳定、实际上在暗处积累偏差的东西。 大波动你会注意到，小偏移你不会——直到它们突然以灾难的形式爆发。

系统论在这里的启示很明确：不要把精力花在选”最强模型”上。花在定义清晰的边界上。花在划清可改区域与不可改区域上。花在让接口契约不可绕过上。OpenAI 的 agent 指南说得很对：先用最强模型建立性能基线，再逐步替换成更小模型。这是因为在好的系统结构中，模型是可替换的部件——而如果你的系统只有在搭配最强模型时才能工作，那你的系统就是脆弱的。

IV. 信息脆弱性：你的信号在到达模型之前就已经面目全非

Shannon 的信息论从来不关心”意义”。它只关心一件事：信号在经过有噪声的信道之后，还剩下多少可以被正确解码的内容。

把这个模型套到 AI coding 上：你脑子里有一个需求（信源）；你把它写成 prompt 和文档（编码）；这些材料经过上下文窗口、工具调用链、检索管道（信道）到达模型；在这个过程中，模糊措辞、缺失约束、矛盾文档、过长上下文都在注入噪声；模型根据收到的信号进行”解码”并输出代码。

问题是：大多数工程师根本不知道自己的编码质量有多差。

他们写了一句”重构这个模块”，脑子里有五十个隐含假设——保持接口不变、不破坏下游、不改日志格式、不碰那个丑但正确的 hack、输出格式跟之前一致。这五十个假设一个都没写出来，全靠默会知识。然后模型做了一个”重构”，破坏了其中十五个假设，他们却怪模型蠢。

模型不蠢。你的信号蠢。

Anthropic 有一条原则说得极其精准：把 prompt 给一个对任务没有背景的同事看，如果他困惑了，Claude 也会困惑。这其实是信息论的工程化表述：如果你的编码连同类型解码器（人类同事）都解不对，凭什么指望异类型解码器（LLM）能解对？

信息论还暴露了一个被所有 multi-agent 爱好者忽视的问题：每多一跳 handoff，信号就多衰减一次。

你的 manager agent 给 specialist agent 传达了一个任务。传达的过程本身就是一次编码-信道-解码。如果描述不够精确，specialist 理解的东西就已经偏了。它做完以后把结果传回来，又是一次编码-信道-解码。两跳之后，原始信号可能已经走样得不成样子了。

所以，多 agent 系统成功的前提不是”角色分工看起来合理”。前提是每一跳的信息协议必须极其清楚——清楚到你在人类之间做 handoff 时都不需要这么清楚的程度。如果做不到这一点，多 agent 只是在用架构复杂度换来了信息衰减。你不是在解决问题，你是在把问题藏进了一个更难调试的结构里。

V. 动态脆弱性：没有反馈回路的系统注定崩溃

控制论的核心洞见只有一个：任何会运动的系统都会偏离目标，所以你需要的不是完美的初始条件，而是持续的修正机制。

恒温器不需要第一次就把温度设对。它只需要：（1）知道目标温度是多少，（2）能测到当前温度是多少，（3）能根据偏差决定加热还是制冷。

导弹不需要一开始就对准靶心。它只需要反馈够快、修正够及时，就能在飞行过程中不断逼近目标。

AI coding 也一样。你不需要一次 prompt 说清一切。你需要的是：

  1. 一个明确的目标定义（什么算”正确”——测试用例、验收标准）
  2. 一个快速的测量机制（跑测试、lint、trace）
  3. 一个及时的修正手段（再提示、补约束、换策略、人工介入）

TDD 之所以在 AI 时代焕发第二春，不是因为工程师们突然变保守了。而是因为 TDD 恰好就是一个控制回路：

  • 写一个 fail 的测试 = 设定参考值
  • 让 AI 写实现 = 让系统运行
  • 跑测试 = 测量
  • 红变绿 = 偏差归零

这比”请帮我把这整个功能写完”高明得多。后者把控制回路的周期拉到了极长——你要等整个功能写完才能知道它对不对。而在这段时间里，偏差在高速累积。前者把回路缩短到了函数级、行为级，偏差刚出现就被捕获。

反馈回路的速度是系统存活率的决定性因素。 这是控制论的铁律，没有例外。

在 AI coding 中，这意味着反馈应该层层前置：lint 在本地拦，单测在提交前跑，契约测试在 CI 里拦，smoke test 在部署前做，trace grading 在运行时监控。把反馈点放在”PR 合并后线上出事故”的工程师，和把体检放在”进 ICU 以后”的人，犯的是同一种错误。

VI. 反脆弱的 AI Coding

脆弱的系统害怕波动。鲁棒的系统承受波动。反脆弱的系统从波动中获益。

大多数 AI coding 实践还停留在”脆弱”阶段：一次 prompt 赌一次结果，赌赢了沾沾自喜，赌输了怪模型。

少数实践达到了”鲁棒”阶段：有测试、有 CI、有 review，模型波动了也能兜住。

极少数实践触及了”反脆弱”：

  • 每次模型犯的错都被捕获、分类、转化为新的测试用例或文档约束——系统因为失败而变得更强。
  • 每次 prompt 失效都触发一次信息编码的优化——文档越来越精确，默会知识加速外显化。
  • 每次控制回路发现的偏差都反馈到系统设计中——边界越来越清晰，接口越来越严格。

在反脆弱的 AI coding 系统中，模型的每一次”犯错”都不是纯损耗，而是一次免费的压力测试。它暴露了系统的薄弱环节，给你改进的机会。你应该感谢这些错误——前提是你有足够的传感器来捕获它们，有足够的结构来消化它们。

这就是三论合在一起的真正力量：

  • 系统论告诉你在哪里布防线（结构）
  • 信息论告诉你在哪里防衰减（信号）
  • 控制论告诉你在哪里装传感器（反馈）

三者合力，你就能把一个脆弱的”生成 + 祈祷”流程，变成一个反脆弱的工程系统——它不只是”抗住”波动，而是利用波动变得更好。

VII. Guardrails 不是官僚主义，是保险丝

很多工程师讨厌限制。他们觉得 guardrails、review gates、部署门禁是”管理层加的官僚主义”。

这种想法非常脆弱。

在电路里，保险丝不是”对电流的不信任”，而是”对过载的现实主义”。你不知道过载什么时候来，但你知道它一定会来。保险丝是便宜的、局部的、快速的失败点——它烧断自己来保护整个系统。

AI coding 中的 guardrails 也一样：

  • 禁止直接改主干分支：一根保险丝。
  • 高风险文件必须人工 review：一根保险丝。
  • 数据库迁移前生成回滚脚本：一根保险丝。
  • 部署前 smoke test 不通过则阻断：一根保险丝。
  • Trace 显示 agent 在仓库里反复打转则暂停：一根保险丝。

没有保险丝的系统不是”更自由”的系统，而是”更脆弱”的系统。自由和脆弱之间，中间只隔着一层缺失的约束。

OpenAI 的 agent 指南建议给工具按风险分级——根据是否可逆、是否写入、权限等级和财务影响，决定是自动执行、暂停确认还是升级到人工。这不是过度谨慎，这是工程师对现实的尊重。

凡是你不愿意为之设置保险丝的地方，就是你最终会为之付出灾难性代价的地方。

VIII. 对”多 Agent”的怀疑

当前技术圈有一种倾向：一谈 AI coding 就要上 multi-agent。好像代理越多，系统越高级。

这让我想起金融领域的一个经典陷阱：把一个简单产品层层打包成复杂衍生品，每层打包都有”合理理由”，但最终没有人能说清风险在哪里。2008 年的金融危机就是这么来的。

多 agent 不是免费午餐。每多一个 agent 就多一次编码-解码，多一个可能失真的信道，多一组需要管理的状态。你获得了”概念分离”的好感，但你支付了”信息衰减 + 调试难度 + 同步复杂度”的代价。

OpenAI 自己的建议其实很克制：先把单 agent 能力用满，只有当 prompt 条件分支太多、工具选择持续出错时，才考虑拆分。

这是对的。复杂度不是成就，是负债。 每一层复杂度都需要用等量的结构清晰度来偿还，否则它就会变成脆弱性的温床。

好的多 agent 系统不是因为”分了很多角色”而好，而是因为每一跳的信息协议极其清楚、每个节点都有独立的反馈回路、故障可以被定位到具体环节。做到这些极其困难。如果做不到，你的多 agent 系统就只是一个”分布式的混乱”——比集中式的混乱更难修。

IX. 五条原则

  1. 假设模型会犯错——然后据此设计系统。 不是因为模型差，而是因为非确定性系统不可能不犯错。你的工作不是消灭错误，而是确保错误被快速捕获、廉价修正。

  2. 投资信号质量，而非 prompt 技巧。 花哨的 prompt engineering 是在末端做优化。真正的杠杆在上游：清晰的需求定义、完整的接口契约、无歧义的验收标准。信息论告诉你：输出的质量上限取决于输入的信噪比。

  3. 把反馈回路做到极短。 每一层反馈——lint、单测、契约测试、trace——都在缩短偏差的累积时间。反馈越快，系统越反脆弱。

  4. 对复杂度持怀疑态度。 多 agent、长 chain、花哨的编排——它们是不是真的必要？能不能用更简单的结构达到同样的效果？复杂度是需要被证明的奢侈品，不是彰显技术力的装饰品。

  5. 把每一次失败变成系统改进。 脆弱的团队复盘时说”模型今天状态不好”。反脆弱的团队复盘时问：是边界没划清（系统问题）？是文档失真了（信息问题）？还是测试没覆盖（反馈问题）？然后把答案变成新的约束、新的测试、新的文档。

X. 结语

软件工程正在发生一次深层的范式转移：从”制造代码”到”治理生成”。

治理什么？治理一个高能力但高波动的非确定性系统。

用什么治理？用系统论的结构思维来划边界、定接口；用信息论的信号思维来降噪声、保真；用控制论的反馈思维来测偏差、做修正。

那些追求”一条完美 prompt 解决一切”的人，犯的是和追求”一次完美预测解决一切”的金融分析师同样的错误。他们不理解不确定性的本质——不确定性不是一个可以被消灭的障碍，而是系统运行的永恒背景音。

真正的工程智慧不是消灭波动。是在波动中建立秩序。是让系统因为暴露于压力而变得更强，而不是更脆弱。

这就是三论给 AI coding 的终极启示：

别做预言家。做舵手。

舵手不预测风浪。舵手面对风浪。舵手有罗盘（目标）、有传感器（反馈）、有舵（执行修正的能力）。风浪越大，好舵手与坏舵手的差距越明显。

AI 时代最稀缺的，不是生成代码的能力——这个能力正在变得像电一样廉价。最稀缺的，是让生成收敛为可靠产物的能力。而这种能力的底层逻辑，恰恰就是七十多年前那三个理论家所奠定的：看清结构、守住信号、闭合回路。

发表于 | 分类于

三副眼镜看 AI 编程：为什么你的代码”看起来对了”却总出事

一、一个被低估了六十年的老工具箱

1948 年，Claude Shannon 发表了信息论的奠基论文。同一年，Norbert Wiener 出版了《控制论》。再往前几年，Ludwig von Bertalanffy 已经在推销他的一般系统论。这三个人各干各的，互相之间未必认同，但后来被中文学术圈捆在一起，称为”三论”。

这个并称其实有争议——钱学森就批评过，说这种并列太粗糙。但争议本身不重要。重要的是：这三套理论，恰好提供了三副不同焦距的眼镜，而 AI coding 碰巧需要你同时戴上这三副。

你可能会想：1948 年的东西，跟我今天用 Claude Code 写项目有什么关系？

关系大了。而且不是那种”知识分子硬拗”的关系，是那种”不理解这三个视角，你在 AI coding 里踩的坑就会一直踩下去”的关系。

二、先用三十秒把三论讲清楚

系统论问的是：这东西整体是怎么组织起来的？哪些部件在互相影响？边界画在哪？

信息论问的是：信号从发出到接收，中间丢了什么？噪声从哪儿混进来的？

控制论问的是：事情开始跑了以后，怎么发现它跑偏了，又怎么把它拉回来？

就这么简单。但这三个问题一旦叠加到 AI coding 上，杀伤力极大。

因为 AI coding 偏偏同时具备三个特征：它是一个复杂系统（不只是模型，而是人 + 模型 + 工具 + 代码库 + 测试 + 部署的整体）；它天然有信息失真（你说的话模型未必懂，模型做的事你未必察觉）；它非确定性地波动（同样的输入，今天能跑，明天可能翻车）。

这就是为什么三论突然变得有现实感。不是你去找它，是 AI coding 把你推到了它面前。

三、系统论：别只盯着模型——那只是冰山一角

很多人理解 AI coding，起点是”哪个模型最强”。

这不能说错，但太窄了。就好像问”哪个发动机最好”，却不看底盘、变速箱、悬挂、轮胎和路况。

系统论会逼你把镜头拉远。一个 AI coding 系统至少包含：用户目标、代码库、文档、提示词、工具链、测试、CI、review 流程、部署管道、监控机制，以及人和模型之间那个微妙的交互契约。真正决定结果的，往往不是某个点最强，而是这些部件之间的接缝有没有漏风。

OpenAI 的 agent 指南把 agent 的基本形态概括成三样东西：模型、工具、指令。你看，这已经很系统论了。一个 agent 能不能工作，不在于其中哪一项单独有多猛，而在于三者有没有咬合成一个整体。

这里有一个反直觉的结论：一个 90 分的模型放进 60 分的系统，不如一个 75 分的模型放进 85 分的系统。

为什么？因为强模型在弱系统里只会更快地产出高质量的错觉。它把函数写得漂亮极了，但破坏了架构；把 bug 修掉了，但引入了回归；帮你加了功能，但顺手改坏了日志链路。没有清晰的边界定义，没有完备的测试，没有人工审查，模型越强，翻车越隐蔽。

所以系统论给 AI coding 的第一课是：别搞模型崇拜，去搞系统设计。

问自己：这个系统的部件如何协同？知识如何沉淀？故障如何暴露？出错后如何恢复？一旦这样提问，你就已经站在了正确的地面上。

四、信息论：你以为你在下指令，其实你在做编码

这是我觉得三论里对 AI coding 最有穿透力的一个视角。

Shannon 模型里有六个环节：信源、编码器、信道、噪声、解码器、信宿。把它类比到 AI coding——

  • 你脑子里的需求，是信源。
  • 你写的 prompt、文档、示例，是编码器。
  • 上下文窗口、工具调用、检索结果，是信道。
  • 模糊措辞、缺失约束、冲突文档、无关日志、过长上下文，全是噪声。
  • 模型的内部处理，是解码器。
  • 最后吐出来的代码，是信宿收到的结果。

这当然是类比，不是 Shannon 原意。但它能解释一个让人抓狂的现象：你明明讲过了，模型还是做错。

为什么？因为你不是在”下命令”，你是在做”编码”。你的意图要经过语言表述、上下文组装、信道容量限制、噪声干扰，才能到达模型的”解码器”。中间任何一环出问题，结果就失真。

Anthropic 的 prompt 最佳实践里有一句话特别到位：把你的 prompt 给一个对任务几乎没背景的同事看，如果他会困惑，Claude 也会困惑。

这句话的信息论翻译是：你的编码器输出的信号，连人类解码器都解不对，凭什么指望 LLM 解码器能行？

这个视角还能解释另一件事：为什么文档在 AI 时代突然变重要了？

过去很多高手靠默会知识工作——架构意图在脑子里，隐含规范在经验里，边界条件靠直觉兜。LLM 不继承默会知识。它吃的是外显材料。所以，需求文档、设计文档、ADR、接口契约、样例输入输出、错误码说明——这些不只是给人看的说明书，它们也是给模型看的编码协议。

谁能把默会知识转成高保真、低歧义、可复用的表达，谁就掌握了信息论意义上的优势。

再补一个容易踩的坑：上下文不是越多越好，而是信噪比越高越好。 Anthropic 建议编码任务一开始就提供完整上下文，把相关代码片段一次性给全——但”完整”不等于”把仓库垃圾一股脑扔进去”。关键是让模型在最少噪声下接触到最关键的信息。过量且无组织的信息，会把信号淹没。

所以信息论给 AI coding 的第二课是：结果之所以乱，常常不是末端的问题，而是信号在前面就已经失真了。 工程师最该升级的，不是”写更花哨的 prompt”，而是设计更高质量的编码结构。

五、控制论：既然拦不住波动，那就别拦——去设计纠偏回路

这是三论里最实用的一副眼镜。

控制论的核心操作只有四步：定目标、测状态、算偏差、做修正。恒温器是这样工作的，导弹制导是这样工作的，自动驾驶也是这样工作的。

把它翻译到 AI coding：先定义”正确”长什么样（测试、验收标准）；再测量模型实际产出（跑测试、review 代码）；识别偏差（哪些测试挂了、哪些风格不对）；然后通过再提示、重跑、补约束、人工介入等方式修正。

这就是为什么 TDD、eval、review、CI、回归测试、trace，本质上都是控制论装置。它们不是”附加管理”，而是系统稳定性的核心硬件。

这里有一个特别关键的洞见：AI 时代，实现的边际成本在暴跌，而验证的边际价值在暴涨。

想想看：过去人工写代码，实现是最痛苦的部分，测试容易被当成拖后腿的成本。现在 LLM 可以秒出代码，真正贵的不是生成，而是确认。TDD 之所以在 AI 时代突然变得顺理成章，不是因为工程师突然变保守了，而是因为经济学翻转了——生产便宜了，质检就值钱了。

控制论还会提醒你一个容易忽略的点：反馈必须足够快。

反馈太慢，系统就会在错误轨道上跑很远。AI coding 时代尤其如此——模型生成速度极快，如果你把唯一反馈点放在”集成测试结束后”或”PR 合并前”，那你其实是在允许错误高速累积。更好的做法是把反馈层层前置：lint 是一层，类型检查是一层，单测是一层，契约测试是一层，trace grading 是一层，人工 review 又是一层。多层反馈的目的不是苛刻，而是降低单次偏离的代价。

所以控制论给 AI coding 的第三课是：不要妄图靠一次 prompt 把一切说死，去设计一套能持续修正的反馈结构。

六、三副眼镜合在一起看：你管理的不是代码，是”可能性空间”

单独戴任何一副眼镜，你都只能看到一部分。三副一起戴，画面就完整了：

系统论决定了这个空间的边界和部件——有哪些工具、文档、规则、角色、回路。
信息论决定了空间里的信号质量——目标有没有传清、约束有没有丢、上下文有没有被污染。
控制论决定了空间的收敛机制——当输出偏离目标时，系统如何把它拉回来。

一个模型非常会生成，但只要系统边界模糊、信息编码糟糕、反馈回路稀薄，它就会在错误方向上高效前进。反过来，一个不是榜单冠军的模型，如果系统结构清楚、信号高保真、控制回路密实，它反而能持续产出稳定价值。

这就引出了一个更大的判断——

七、时代判断：从”制造代码”到”治理生成”

传统时代，工程师的核心形象是”实现者”——理解需求，亲手编码，调试发布。

AI 时代，这个形象在变。工程师越来越像一个系统设计者 + 信息架构师 + 反馈回路工程师。

软件工程的重心，正在从”如何制造代码”转向”如何治理生成”。

治理什么？

  • 治理部件关系——系统论。
  • 治理语义传输——信息论。
  • 治理偏差收敛——控制论。

你对 TDD、评测、工作流、验证这些词越来越有感觉，不是因为你变保守了，而是因为你在直觉上抓到了 AI 时代最稀缺的东西：不是生成能力，而是让生成收敛为可靠产物的能力。

八、五个你明天就能做的事

理论再好，不落地就是空转。收缩成五个动作：

第一，把 TDD 扩展成广义测试驱动。 验收清单、API 样例、错误码断言、边界 case、回归场景表，都是”先定义正确，再驱动生成”。

第二，设计阶段优先考虑可测性。 你的模块如果副作用太重、输入输出不可观察，后面 AI 再强也难合作。

第三，把文档当编码协议。 需求文档、设计文档、ADR 不是项目装饰品，它们是减少信息失真的工具。谁先把默会知识写成模型能理解的材料，谁先建立优势。

第四，把反馈回路做短。 能在本地检查的不等 CI，能在单测发现的不等联调，能在 eval 复现的不靠线上事故学习。

第五，复盘时用三论分类。 别只说”模型今天状态不好”。问自己：这是结构问题（边界没划清）？信息问题（文档失真）？还是反馈问题（测试没覆盖）？一旦这样分类，抱怨就变成了工程改进项。

九、一句话收尾

如果把整篇压缩成一句话：

AI 时代的软件工程，就是在一个高能力、高波动的生成系统中，通过好的系统结构、清晰的信息编码和密实的反馈回路，把”可能正确”不断压缩成”稳定正确”。

三论不是老知识。它是 AI 时代的工程母语——只不过你今天才有了足够的实感去听懂它。

发表于 | 分类于

从 Shannon 到 AI Coding：信息、控制与系统的工程之美

引子

在技术史上，有些理论诞生时看起来离实践很远，但过了几十年，工程世界的演化反而把它们推到了舞台中央。系统论、控制论和信息论就是这样的例子。

这三套理论在中文语境里常被合称为”三论”。这个称呼本身有争议——钱学森后来批评过，认为把三者简单并列不够严谨，系统科学应当把控制与信息吸纳到更大的框架中去。不过，争议归争议，如果我们不纠缠于学科分类的精确性，而是把它们当作三种不同的观察复杂问题的方法论，那么它们在今天的 AI coding 实践中确实各有不可替代的解释力。

这篇文章不打算做思想史梳理。我想做的事情更具体：从工程角度说清楚，为什么一个现代软件工程师在使用 AI 辅助开发时，会自然地遇到这三套理论所关心的核心问题。而理解这些问题，能帮助我们更理性地看待 AI coding 的能力与局限。

第一章 三论各自在解决什么问题

让我们先回到每一套理论的原始关切。

系统论：部分如何组成整体

系统论的核心命题可以用一句话概括：整体不等于部分的简单相加。 它关心的是结构、边界、层级和关系——一组相互关联的部件，如何通过特定的组织方式涌现出单个部件所不具备的性质。

这个思想今天看来平淡无奇，但它在方法论上的意义很深：当你面对一个复杂对象时，不应该只看局部性能，而要看局部之间的关系和约束。一个由优秀零件组成的系统未必优秀，一个由普通零件组成的系统只要结构得当，可能运行得非常稳定。

控制论：运动中的系统如何不跑偏

控制论关心的不是静态结构，而是动态行为。用 Britannica 的经典概括来说，它研究的是：一个监测者如何把系统当前状态与某个标准进行比较，再由控制者根据偏差来调整系统行为。

这个定义里有四个关键角色：目标（参考值）、传感器（测量当前状态）、比较器（计算偏差）、执行器（实施修正）。恒温器是最简单的例子：设定温度是目标，温度计是传感器，温差是偏差，加热器是执行器。导弹制导、自动驾驶、工业过程控制，都是同一个逻辑的不同实现。

控制论不试图一次把事情做对。它假设系统一定会偏离，然后研究如何通过反馈持续地把偏差压回可接受的范围。

信息论：信号如何在噪声中保真

Shannon 在 1948 年发表的那篇论文，刻意把”意义”排除在理论核心之外。他关心的不是一条消息说了什么，而是一条消息在从信源到信宿的传输过程中，如何被编码、通过有噪信道传输、并尽可能正确地被解码。

Shannon 模型的几个环节——信源、编码器、信道、噪声、解码器、信宿——构成了一个非常普适的分析框架。它的核心洞见是：任何通信系统的可靠性，都受限于信道容量和噪声水平，而好的编码方案可以在物理极限内最大化传输的保真度。

把这三者摆在一起，它们的分工就清楚了：

理论 核心问题
系统论 部件如何组织成有效的整体？
控制论 动态系统如何持续纠偏？
信息论 信号在传输中如何保真？

接下来，我要说明为什么 AI coding 恰好需要同时回答这三个问题。

第二章 AI Coding 为什么是一个复杂系统

理解 AI coding 的本质，首先要摆脱一个简单化的认知：它不只是”代码补全”。

Anthropic 的 Claude Code 文档把这类工具定义为 agentic coding tool——它不仅生成代码片段，还会读取代码库、编辑文件、运行命令、与开发工具集成。常见工作流包括理解陌生代码库、调试、重构、写测试、生成 Pull Request。换言之，现代 AI coding 工具的操作对象已经从”单个函数”升级到了”整个仓库”。

其次，AI coding 具有本质上的非确定性。OpenAI 的评测文档明确指出，生成式 AI 是可变的——同样的输入有时会得到不同的输出。这意味着传统软件测试方法并不足以覆盖这种架构，必须引入专门的评测框架（evals）来持续度量性能和稳定性。

最后，SWE-bench 等基准测试揭示了真实任务的复杂度。它把问题定义为”给定一个代码库和一个 issue，让模型去修改代码并通过仓库测试”。这些问题常常要求跨多个函数、类乃至文件进行协调，还要与执行环境交互、处理很长的上下文。

这三个特征——仓库级操作范围、非确定性波动、真实工程复杂度——叠加起来，使 AI coding 成为一个典型的复杂系统。它不是一个可以用输入输出函数完整描述的黑箱，而是一个由人、模型、工具、代码、测试、流程共同构成的动态整体。

第三章 系统论视角下的 AI Coding

从系统论的角度看 AI coding，最重要的认知转变是：决定产出质量的不是模型这个单点，而是整个系统的结构。

OpenAI 的 agent 指南把 agent 的基本形态概括为三个要素：模型、工具、指令。这三者需要协同工作。模型负责推理与决策，工具负责与外部系统交互，指令负责定义行为边界。它们之间的匹配程度决定了 agent 的实际效能。

在此之上，还有更高层次的系统设计问题：单 agent 还是多 agent？循环何时终止？何时移交（handoff）？何时触发防护机制（guardrail）？这些都属于编排（orchestration）层的决策。

系统论在这里提供了一个非常重要的警示：局部最优不等于整体最优。 一个能力极强的模型，如果放进一个没有明确边界、缺乏测试、没有审查流程的环境里，往往会快速产出表面正确但深层有害的结果——函数级代码可能很精致，但架构级一致性已经被破坏了。

反过来，一个中上水平的模型，放进目标明确、上下文清晰、测试完备、回滚方便的系统里，产出的可靠性反而更高。OpenAI 的 agent 指南建议先用最强模型建立性能基线，再逐步替换成更小模型以优化成本——这正是系统论思维的体现：模型是系统的一个可替换部件，而不是不可动摇的核心。

从系统论出发，工程师需要关心的问题包括：

  • 系统的边界在哪里？哪些文件可改，哪些不可改？
  • 各部件之间的接口是否清晰？模型、工具、指令之间是否有模糊地带？
  • 知识如何在系统中沉淀？是停留在个人经验里，还是已经固化到文档和测试中？
  • 故障如何暴露？有没有机制让错误在早期就变得可见？

这些问题看起来朴素，但它们决定了 AI coding 系统的真实产能上限。

第四章 信息论视角下的 AI Coding

如果系统论解决的是”结构”问题，那么信息论解决的是”传输”问题——更准确地说，是人的意图在传递给模型的过程中如何失真的问题。

这是一个非常值得仔细思考的类比。Shannon 模型中的六个环节可以这样对应到 AI coding 场景：

Shannon 模型 AI Coding 对应
信源 用户头脑中的需求
编码器 需求文档、prompt、示例、接口约定
信道 上下文窗口、工具调用、检索结果
噪声 模糊措辞、缺失约束、冲突文档、过长上下文
解码器 模型的内部表征与推理过程
信宿 生成的代码、改动和答复

这个类比当然不是 Shannon 原意的严格应用，但它有很强的解释力。它帮助我们理解为什么”你明明讲过了，模型还是做错”——问题往往不在解码端（模型智力不足），而在编码端（你的表述引入了歧义）或信道端（上下文组装引入了噪声）。

从信息论的角度，有三个工程启示值得重视。

第一，写 prompt 本质上是在做编码。 Anthropic 的最佳实践明确建议：清晰、直接、具体；把 prompt 给一个对任务没有背景的同事看，如果他会困惑，模型也会困惑。这不是修辞建议，而是编码质量要求。

第二，上下文的价值取决于信噪比，而不是绝对量。 Anthropic 建议编码任务一开始就提供完整上下文，但”完整”指的是”所有关键信息到位”，不是”所有能找到的材料都扔进去”。无组织的海量信息会降低信噪比，反而损害输出质量。

第三，文档在 AI 时代获得了新的工程角色。 传统开发中，很多知识以默会形式存在于工程师的经验中。LLM 无法继承默会知识，它依赖外显材料。因此，需求文档、设计文档、ADR、接口契约、样例输入输出不再只是”人看的说明书”，它们同时也是”模型读的编码协议”。

从信息论的角度看，一个工程团队在 AI coding 中的效能上限，很大程度上取决于它把隐性知识转化为显性、可机器消费的材料的能力。这一点的重要性在今天被严重低估了。

第五章 控制论视角下的 AI Coding

信息论帮助我们理解信号失真的问题，但信号即使传输完美，系统也不一定能稳定运行——因为模型本身是非确定性的。这时候就需要控制论。

控制论的核心逻辑很直接：定义目标 → 测量实际状态 → 计算偏差 → 执行修正。在 AI coding 中，这个回路对应的是：

  1. 定义正确性标准（测试用例、验收清单、评分标准）
  2. 让模型生成产物
  3. 通过自动化或人工手段检测产物是否符合标准
  4. 根据检测结果修正（再提示、补约束、换策略、人工介入）

OpenAI 的评测文档把这个过程说得很清楚：eval 的基本流程是定义目标、收集数据、定义指标、运行并比较、再迭代。另一篇关于测试 agent skills 的文章更进一步，把 eval 描述为”prompt → captured run → checks → score”，并强调要把 outcome、process、style、efficiency 分开检查。这几乎就是经典控制系统的工程化实现。

控制论视角带来的一个特别重要的工程认知是：TDD 在 AI 时代获得了新的合理性。

在纯人工编程时代，很多工程师不爱 TDD，是因为写实现已经够痛苦了，测试容易被当作拖慢速度的成本项。但 AI 改变了这个经济等式：当实现的边际成本因 LLM 而大幅下降时，验证的边际价值就相对大幅上升。TDD 本质上不是”先写测试”，而是”先把目标函数外显化”。用控制论的术语说，就是先设定参考值，再允许系统运行。

控制论还强调一点：反馈回路的速度决定了控制的精度。 反馈越快，偏差累积越少。在 AI coding 中，这意味着应该把反馈层层前置——lint 和类型检查在本地就做，单测在提交前就跑，契约测试和 smoke test 在 CI 中拦截，人工 review 作为最后一道防线。如果唯一的反馈点是”PR 合并后线上出事故”，那控制回路就太长了，偏差会在无形中放大到难以收拾的程度。

第六章 三论合一：可能性空间与收敛

把三个视角合在一起，我们可以获得一个更完整的认识框架：

AI coding 的真正操作对象，不是代码文本本身，而是一个由结构、信号和反馈共同塑造的”生成可能性空间”。

  • 系统论决定这个空间的边界与拓扑——有哪些部件、哪些接口、哪些约束。
  • 信息论决定空间内的信号质量——目标是否传达到位、约束是否完整、上下文是否干净。
  • 控制论决定空间的收敛机制——当产出偏离目标时，系统如何检测到偏差并实施修正。

一个高能力的模型在一个边界模糊、信号嘈杂、缺乏反馈的系统中工作，就像一台高性能发动机装在一辆没有方向盘和仪表盘的车上——速度越快，偏离越远。反过来，一个结构清晰、信号干净、反馈密实的系统，即使搭载的模型算不上顶尖，也能在多数实际工作中产出稳定而可靠的结果。

SWE-bench 这类基准之所以有价值，恰恰是因为它测量的不只是”模型能否写出一段正确的代码”，而是”模型能否在复杂仓库中完成任务并通过既有测试”。后者是一个系统级的度量，不是模型级的度量。

第七章 工程启示与实践建议

把以上分析收敛为具体的工程实践，以下五点值得特别重视。

一、把测试驱动从技术习惯升级为系统基础设施。 不要只把测试理解为单元测试。验收清单、API 契约、边界样例、回归场景表，都是”先定义目标，再驱动生成”的方法。在控制论意义上，它们就是系统的参考值。

二、在设计阶段就为可测性和可观测性预留接口。 一个模块如果副作用太重、边界模糊、输入输出不可观察，那么无论搭配多强的 AI，也很难建立有效的控制回路。

三、把文档视为降低信息失真的工程手段。 需求文档、设计文档、ADR、接口契约不是形式主义的附属品，而是把默会知识外显化、降低编码歧义的核心工具。在 AI 参与开发的团队中，文档质量直接决定了人机协作的信噪比。

四、把反馈回路做短、做密。 能在本地检查的不等 CI，能在单测发现的不等集成联调，能在 eval 数据集中复现的不靠线上事故学习。控制论最忌讳的就是回路太长——长回路意味着偏差在暗处累积。

五、复盘时按三论分类定位问题。 遇到 AI coding 的失败，不要笼统归因为”模型不行”。有针对性地问：是系统结构问题（边界没划清、部件没协同）？还是信息问题（文档失真、上下文噪声太大）？还是反馈问题（测试没覆盖、trace 没监控）？分类越精确，改进越高效。

结语：三论作为工程思维的底层语法

回到文章开头的判断：有些理论诞生时离实践很远，但时代演化会把它们推到实践的中央。

在传统软件工程时代，工程师的核心身份是”实现者”——理解需求，亲手编码，调试发布。在 AI 参与开发的时代，工程师的身份正在演变为”系统的设计者与治理者”。他需要设计部件关系（系统论），需要管理语义传输的保真度（信息论），需要构建偏差检测与修正的闭环（控制论）。

这不是说编码能力不重要了，而是说编码能力被纳入了一个更高阶的能力层次。最终，优秀工程师的竞争力将体现在三个方面：

  • 系统设计能力：知道如何布置部件、划定边界、定义接口。
  • 信息架构能力：知道如何把隐性知识转化为模型能正确吸收的显性材料。
  • 反馈工程能力：知道如何把测试、评测、审查、trace、监控组织成可持续纠偏的闭环。

如果用一句话来概括这篇文章的核心观点：

AI 时代的软件工程，本质上是在一个高能力、高波动的生成系统中，通过良好的系统结构、清晰的信息编码和密实的反馈回路，把”可能正确”持续压缩为”稳定正确”。

这是三论在 AI coding 时代焕发活力的根本原因——不是旧理论被硬套到了新场景，而是新场景的内在结构恰好与旧理论的核心命题高度吻合。从 Shannon 到 AI Coding，中间隔了七十多年，但工程之美的底层逻辑从未改变：面对复杂性与不确定性，好的工程永远是结构、信号与反馈的协奏。

发表于 | 分类于

主权

大多数人对 AI 编程的理解，停留在一个很表层的画面：你打字更快了，搜索更快了，写代码更快了。就好像你原来骑自行车上班，现在换了辆电动车。速度是变了，但你走的还是同一条路，干的还是同一件事。

但真正发生的事情不是这个。

真正发生的事情更像是——你原来自己一个人搬砖，现在突然有一百个人可以帮你搬。问题不再是“怎么搬得更快”，而是“到底该搬去哪”。

我注意到这个变化，是从一个很小的体验开始的。

有一天我发现，我手上几个平台的强模型额度，怎么都用不完。以前我会精心组织一个 prompt，想尽办法一次性把问题问清楚，像在跟一个按小时收费的律师谈话，每一分钟都不想浪费。但突然有一天，我发现这个律师不怎么收费了。或者说，他的费用低到我根本不用想“值不值得问”这个问题。

这个变化看起来很小，但它改变了一切。

因为当你不用再犹豫“要不要调一次模型”的时候，你的工作方式会悄悄发生一个根本性的转变。你不再是先自己想半天，实在想不通再去问。你开始变成：先让模型跑一轮，出三个方案，然后你从三个方案里选一个。你不再小心翼翼地节省每一次调用，而是开始把模型当成自来水——拧开就用，想用就用。

以前的心态是：“这个问题值不值得动用 AI？”
现在的心态变成了：“这个问题我为什么不先让 AI 看一眼？”

你可能觉得这只是效率提升。不是。这是范式变化。

要理解为什么这是范式变化，想想工业革命。

蒸汽机的意义不是让马车跑得更快。蒸汽机的意义是让能源变得便宜到一个程度，使得整个生产组织方式都必须重新设计。以前太贵所以不做的事——质量检查、冗余设计、大规模试错——突然之间都可以做了。不是因为人变聪明了，而是因为能源变便宜了。

AI 对认知劳动做的，就是蒸汽机对体力劳动做的事。

以前很多认知动作太贵了——让人反复审查一段代码、让人从十个角度分析一个设计、让人把每个边界条件都想一遍、让人写完代码再从安全和并发的角度各检查一遍。不是不知道这些事情应该做，而是做不起。一个人一天只有那么多小时，注意力只有那么多，脑子会累，情绪会烦。

现在不一样了。这些认知动作的边际成本正在迅速下降。你可以让模型跑十个方案，可以让模型从三个角度审查同一段代码，可以让模型把测试用例铺到以前你连想都不敢想的密度。原来舍不得做的事，现在都可以做了。

所以，我们面对的核心问题，已经不是“AI 太贵，能不能少用点”，而是“AI 已经这么便宜了，我们整个工作方式该怎么重新设计”。

大多数人对 AI 的定位是“一个聪明的助手”。这个定位太窄了。

把 AI 往抽象了看，它其实是一种新型生产要素。它最本质的特征不是“聪明”，而是便宜、可复制、可并发。

一个人一天只有二十四小时，注意力只有一份，做完 A 才能做 B。但 AI 可以同时跑十个任务，一百个任务。你不用等它做完这个再做那个。它天然就是并行的。

一个人做到第九遍会烦，会走神，会偷工减料。AI 不会。它不会因为重复就变得敷衍。这让它特别适合那些高重复、需要铺量、需要长时间巡检的活。

一个人犯了错，可能职业生涯就拐弯了。AI 犯了错，你让它重来就行。它的试错成本几乎为零。所以它特别适合探索，适合把搜索空间摊开，适合同时给你五种方案让你挑。

把这些特征加在一起，你会发现 AI 最擅长的事情，不是“替你写代码”，而是替你把世界摊开来看。它是认知世界里的廉价能源。不是单次神来之笔，而是大规模、低成本地执行那些以前你舍不得做的认知动作。

但这里有一个很多人搞错的事情。

很多人把 AI 和人类看成同一个刻度上的高低之分：AI 是低配版的人，人是高配版的 AI。AI 笨一点但便宜，人聪明一点但贵。所以问题就变成了“AI 什么时候聪明到能替代人”。

这个理解是错的。AI 和人类根本不是一种东西。

关键区别不在于谁更聪明。关键区别在于谁有 stake。

什么意思？AI 可以给你十个方案，每个方案看起来都挺有道理。但它不需要为其中任何一个方案承担后果。它不会因为选错方案而丢工作，不会因为上线出事故而失眠，不会因为一个糟糕的架构决定而在未来三年里天天给自己擦屁股。

人不一样。人的每一个决定都绑着代价——名誉、时间、关系、职业路径、情绪。你做的决定不是悬浮在空中的，它会回到你自己身上。你要解释，要承担，要复盘，要消化后果。

这就是为什么 AI 天然适合扩张可能性，而人天然适合压缩可能性。

AI 可以帮你看到十条路。但最终选哪一条，只能你来走。因为只有你会真正活在那个选择的后果里。

如果要我用一句话概括人和 AI 的分工，我会这样说：

AI 负责扩张可能性，人负责把可能性压缩成命运。

“扩张”和“压缩”，是两个完全不同的动作。

AI 的活儿是发散。帮你看十种方案、二十种边界条件、三十种失败模式。它从多个角度读需求，从多个角色审设计，从大量组合里生成测试。它天生适合把一个模糊问题的搜索空间铺开，让你看到更多你原本看不到的东西。

人的活儿是收敛。你要在这些可能性里决定什么进入现实，什么被过滤掉，什么虽然可行但不值得，什么虽然漂亮但代价太高，什么虽然技术上正确但时机不对。AI 给你一百条路，你要选一条，然后走下去。

这不是“AI 做简单的，人做难的”。这种分法太粗糙了。今天看起来很难的事，明天 AI 可能做得比你好。但有一类事情始终天然更接近人：定义目标、排序价值、做出取舍、承担后果。这些事情不是因为计算复杂才留给人，而是因为它们和“谁来负责、谁来承受、谁要把这件事纳入自己的人生”有关。

想想看：你到底想成为什么样的人？你觉得什么值得，什么不值得？你愿意为什么承受痛苦？你在一堆路径里为什么选了这条？

这些问题没有“正确答案”。它们需要一个有限的、会死的、不能同时活一万种人生的存在来回答。恰恰因为你不能无限复制自己，你的选择才有分量。恰恰因为你的时间有限，你的注意力才是最贵的货币。

人的有限性不是缺陷。它是承诺的前提。

在 AI 时代，有一个非常重要但很少有人讲清楚的区分：死摩擦和活摩擦。

我们当然希望 AI 帮我们减少痛苦，提升效率。但不是所有痛苦都应该被消除。有些痛苦只是在浪费你的生命，有些痛苦却是在塑造你。

死摩擦，就是那些不会让你成长、只会消耗你注意力的东西。写大量样板代码，机械性地整理格式，反复搜索同一类信息，批量改名，补充重复性的注释，搭测试骨架，翻十几个文件只为了确认一个简单的调用关系。这些事情当然需要被正确完成，但它们本身不会让你变得更好。AI 越能把这些消灭掉，你就越应该高兴，因为这些东西只是在烧你的生命。

活摩擦就不一样了。比如你纠结“这个设计到底够不够好”的那种折磨，你权衡“长期架构和短期交付到底怎么平衡”的那种痛苦，你面对不完整信息必须做判断时的那种焦虑，你检视自己是不是在因为懒惰或者虚荣而做出某个决定时的那种不舒服。这些摩擦看起来效率很低，但它们是你变成你自己的过程。你的判断力、你的边界感、你对风险的直觉，都是从这些痛苦里长出来的。

所以 AI 最有价值的用法，不是帮你消灭一切不舒服，而是：帮你拿走那些没有成长价值的痛苦，把真正塑造你的痛苦保留下来。

落到具体工作里，这个原则特别实用。批量生成 DTO、扫调用链、整理变更说明、补测试骨架——这些是死摩擦，尽管交出去。设计取舍、风险定义、抽象边界、上线标准、关键逻辑是否可信——这些是活摩擦，你得自己穿过去。

一旦你接受了“AI 是廉价可扩展的智能”这个前提，软件工程的重心就会发生一个根本性的迁移。

以前的瓶颈是写代码。程序员的自我想象是：想清楚、写出来、调通、提交。“写”是核心动作。

但当 AI 能大量写代码的时候，“写”就不再是瓶颈了。真正开始变贵的，是另外几样东西：需求到底定义清楚了没有？设计有没有被比较和证伪？实现有没有被验证？测试有没有杀伤力？上线有没有可控性？事故经验有没有变成约束？

换句话说，“写出来”越来越不值钱，“证明它值得信”越来越值钱。

未来的优秀开发者不会长得像一个手艺精湛的木匠。他更像一个控制系统的设计师——设目标，放出候选方案，建测试网，做对抗审查，根据反馈修正，反复让系统收敛到一个足够可信的状态。

以前工程质量靠什么？靠一个经验丰富的人“看一眼就知道哪里不对”。这种直觉当然仍然珍贵，但它太依赖个人了。未来更稳定的路线是建立系统化的验证结构：多方案竞争、独立实现、差分测试、红队 review、回归回放、文档和实现一致性检查。

当智能稀缺的时候，你舍不得做这些。当智能丰裕的时候，你应该默认去做这些。

软件工程的未来，不是让一个程序员变成超人，而是让每一行代码都被一群廉价但强大的智能体反复挑战、验证、解释、重放。

说到具体的工具，很多人陷入一个低层次的问题里出不来：“到底哪个模型最好用？”

这个问题本身就问错了。就像问“到底锤子好用还是螺丝刀好用”一样。它们不是互相替代的，它们应该放在不同的环节。

便宜模型的价值在于铺量。它的单次判断未必最准，但它可以大量调用。适合拉全局地图、列风险清单、扫仓库、扫 diff、补文档、生成骨架、做第一轮分类。它的优势不是“最对”，而是“最广”。就像一支侦察部队，你派出去不是为了它能打赢仗，而是为了它能帮你看清战场。

贵的模型的价值在于压缩不确定性。它应该只在真正难、真正模糊、真正一旦出错代价很高的环节出手：架构方案仲裁、事务边界、一致性语义、幂等设计、权限风险、疑难 bug 根因分析、上线前红队审查。它的价值不是铺量，而是高风险判断。

所以我特别反对两种浪费。

第一种，让强模型去干廉价活。你用最贵的智能去扫文件、补样板代码、写机械注释，就像请一个顶级律师去帮你复印文件，这是在浪费最稀缺的资源。

第二种，让便宜模型直接终审。便宜模型适合大规模探索，但你不能让侦察兵直接拍板战略决策。否则你会把大量“看起来有道理”的半成品直接带进主干。

好的分工是：便宜模型负责多做，强模型负责少错。

这个原则不只适用于不同工具之间，它也适用于 AI 和人之间。AI 负责多做，人负责少错。

把这个思路铺到整个开发流程上，每一个阶段都应该重新分工。

需求阶段最怕什么？不是没想法，而是大家以为自己理解一致，实际上理解完全不一致。我见过太多线上事故，根因不是代码写错了，而是需求本身就有模糊地带——成功到底怎么定义？失败怎么回滚？重试算不算新请求？部分成功部分失败怎么办？权限的边界在哪里？

便宜模型在这个阶段最该做的，不是急着给方案，而是帮你把雾拨开。读现有代码，拉调用链，列出所有你没想到的歧义点和失败场景。强模型则该扮演挑刺者：这个词定义清楚了吗？这个边界会不会炸？这个场景出了错解释成本有多高？

而你必须裁决的是：这次到底做不做？做到哪里？哪些明确不做？验收标准是什么？哪些风险不能接受？

需求阶段，人定义业务真相，AI 只是帮你把真相周围的迷雾拨开。

设计阶段最大的误区是急着追求“一个看起来完整的方案”。智能丰裕时代的正确做法是默认生成多个互相竞争的设计：最小改动版、最可测试版、最长期可维护版、最强调回滚版。让不同方案各自暴露代价，然后你再选。

设计阶段重要的不是“更漂亮”，而是“更可收敛”。

实现阶段最容易犯的错是浪费强模型。绝大多数低风险、高重复的实现工作——DTO、VO、controller 骨架、参数校验、注释、文档——都应该下放给便宜模型。强模型只在少数关键点出手：金额计算、状态转换、权限校验、幂等逻辑、事务和锁。

而你在实现阶段的角色不是生产者，是收敛者。你要防止系统发散——判断某个抽象是不是过头了，某个 diff 是不是需要逐行审，某次小重构会不会稀释主线。

测试阶段，在智能丰裕时代，很可能是变化最大的环节。过去很多团队测试做得薄，不是因为不知道测试重要，而是因为做不起。现在大量便宜智能意味着你终于可以默认去做那些原本觉得太奢侈的验证动作。边界矩阵、权限矩阵、状态转移矩阵、异常路径集合、回归测试、文档和实现一致性检查。

测试阶段的核心不是让灯都变绿，而是建立一种你真正愿意相信的确定性。

上线阶段是所有哲学都会显形的地方。因为到了这里，事情不再只是代码质量，而是“谁来承担结果”。AI 可以帮你生成影响范围图、发布清单、回滚方案、监控建议。它可以做上线前的红队审查：最坏会出什么事故？最先看哪几个指标？哪种情况必须回滚？

但最后那个 go/no-go 的决定——谁来盯盘、出了问题是回滚还是热修、灰度策略怎么定——这些事情没有任何模型能替你承担。AI 只能给建议，发令权必须在你。

说到这里，最底层的问题就浮出来了。

在智能越来越丰裕的时代，一个人到底该保留什么？

我越想越觉得，答案不是“我要坚持自己敲多少行代码”，也不是“我必须手写每一个文档”。如果把亲力亲为本身当成价值，你很容易滑回低效和防御。

真正该保留的是主权。

什么是主权？不是凡事都自己做。而是你有能力、也有意识地决定什么交出去、什么必须自己来——而且这个决定是清醒的，不是顺着便利性滑过去的。

具体来说，有四样东西必须留在自己手里。

第一，目标定义权。这件事为什么值得做？做到什么边界算完成？什么明确不做？这些不是 AI 帮你定义的。

第二，价值排序权。速度和质量怎么平衡？短期收益和长期债务怎么权衡？哪类风险不能接受？这些本质上都是“你愿意为哪种结果负责”的问题。

第三，关键判断拍板权。尤其在高爆炸半径的环节——权限模型、金额逻辑、状态机、不可逆迁移、上线回滚。可以让模型给你一百条建议，但“就这么做”必须由你亲自说出来，而且你知道为什么。

第四，后果承担权。出了事谁解释？谁复盘？谁背结果？谁决定下次怎么防止？AI 可以分析，但不能替你承担后果。凡是最终回到责任结构上的事情，都必须有人在场。

这四样东西一旦也交出去了，你获得的可能是一个极高效的流程，但你可能已经不再是自己工作和人生的主人了。

过去很多年，我们训练自己的方式，本质上都是匮乏时代的训练。学会记忆，学会计算，学会搜索，学会组织材料——因为资源有限，外援很少，智能昂贵。

但现在世界开始翻转了。智能供给越来越多，建议越来越多，草稿越来越多，路径越来越多。这个时候，真正稀缺的能力反而变成了另一种东西：

你能不能在很多建议里形成自己的标准？
你能不能在很多草稿里做出真正属于你的终稿？
你能不能在很多路径里选一条，然后长期走下去？
你能不能在很多优化机会面前知道何时该停？
你能不能在大量 AI 产出面前，不让自己的判断肌肉萎缩？

这是一种全新的训练。不是匮乏时代那种“多做一点就赢了”的训练，而是丰裕时代的训练——靠少迷失一点、少发散一点、少把主权外包一点来取胜。

我越来越觉得，未来一个人最重要的能力，不是生产力，而是收束力。不是谁能调更多模型，不是谁能让系统生成更多东西，而是谁能在海量可能性面前仍然保持方向感。

这个方向感不是 AI 给你的。它是你通过长期的价值排序、风险承担、实践复盘和自我诚实，一点一点长出来的。

这也解释了为什么“自己安静想一想”在 AI 时代反而更重要了。AI 太会给答案了。你很容易在还没真正形成自己理解的时候，就满意于一个表达很漂亮的外部答案。你以为自己想通了，实际上只是借用了一个看起来完整的结论。所以你至少要给自己保留一些不靠 AI 的思考时间：自己写一版判断，自己做一版复盘，自己走完最后一公里的表达。不是反技术，而是给自己的认知肌肉留训练场。

如果把这整篇文章压成几句话，我想说的是：

AI 是廉价的可能性，人是昂贵的承诺。可逆的事让 AI 多试，不可逆的事由人来定。便宜模型负责多做，强模型负责少错，而你负责裁决。该被 AI 消灭的是死摩擦，不该被外包的是活摩擦。软件工程的未来不是更会写，而是更会让系统不容易写错。在智能丰裕的时代，人的核心任务是守住主权。

如果还要再压成一句话：

未来不属于最会调用智能的人，而属于最会治理智能的人。

不属于最会生成内容的人，而属于最会在海量可能性面前做出承诺、把事情带入现实的人。不属于拥有最多外部智能的人，而属于在巨大外部智能加持下，仍然没有丢掉自己中心的人。

AI 会越来越像一种基础资源。但人必须决定，资源为什么而用。AI 越来越擅长展开世界。但人必须把世界压缩成自己愿意承担的一条路。

在智能丰裕的时代，真正的修炼不是怎样拥有更多外部智能，而是在拥有巨大外部智能之后，仍然保有自己的主权、判断和承诺能力。

这大概是未来很多年里，最值得反复提醒自己的一件事。