推荐语

AI时代最大的谎言被揭穿：不懂编程也能开发软件？深度剖析LLM本质与可靠性的数学困境。

核心内容：
1. 当前AI开发神话背后的真相与LLM本质特征
2. 从数学角度解析AI不可靠性的根源（p^n困境）
3. 构建可靠AI协同系统的三大原则与未来展望

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

“Vibe Coding”——这个词在2024年席卷了整个科技圈。社交媒体上铺天盖地都是令人震撼的演示视频：只需要几句话描述需求，AI就能自动生成完整的应用程序；不懂编程的产品经理用Cursor开发出了完整的SaaS产品；创业者声称靠AI单枪匹马完成了原本需要整个团队的工作。这些故事如此诱人，以至于很多人开始相信：编程的门槛彻底消失了，只要会说话，就能让AI帮你实现任何想法。

然而，当我们真正尝试用AI来开发一个稍微复杂一点的项目时，却发现现实与宣传之间有着巨大的鸿沟。AI生成的代码经常出现莫名其妙的bug，刚刚还能正常工作的功能突然就崩溃了，明明已经告诉它很多次的需求它还是会理解偏差，一个简单的修改竟然引发了连锁反应把整个项目都搞崩了……最后你会发现自己大部分时间都在给AI“擦屁股”，反复修正它的错误，甚至花的时间比自己直接写代码还要多。这时候你不禁困惑：网上那些人是怎么做到的？为什么别人可以轻松Vibe Coding，而我却陷入了无尽的调试地狱？

其实，这个问题背后有两个层面的原因。

第一个层面，是我们对AI抱有不切实际的期待。受到媒体和自媒体的影响，我们误以为AI已经达到了“无所不能”的程度，只要给它下达指令，它就能像一个经验丰富的高级工程师一样，理解你的意图、做出正确的判断、写出优雅的代码、处理所有的边界情况。但现实是，AI远没有我们想象的那么可靠。它会犯各种低级错误，会“一本正经地胡说八道”，会在简单问题上翻车，会莫名其妙地遗忘之前的上下文。这不是某个AI产品的缺陷，而是当前所有大语言模型的本质特征。

第二个层面，是网络上那些“Vibe Coding神话”的过度夸大。那些看起来几分钟就完成复杂项目的演示视频，往往是精心挑选的成功案例，或者只是Demo级别的原型，根本经不起生产环境的考验。而那些声称“完全不懂编程也能开发”的说法，更是彻头彻尾的误导。Vibe Coding确实是未来软件开发的新范式，但它绝对不是很多人想象和网上吹嘘的那样——一个啥都不懂的门外汉，只需要几句话就能完成专业级的软件开发。

那么，Vibe Coding的真相到底是什么？它真正改变的是什么？要回答这些问题，我们需要从最根本的地方开始——理解AI到底是什么，它的能力边界在哪里，它的工作原理是怎样的。只有建立了这些基础认知，我们才能真正掌握与AI协同工作的方法，才能让AI真正成为提升效率的工具，而不是制造混乱的麻烦制造者。

要理解 AI 协同开发，得先搞清楚最根本的问题：LLM 到底是个什么东西？

对大多数人来说，LLM 就像是一个无所不知的“神”。它几乎掌握着世界上所有的知识，不管你问物理、历史、编程还是文学，它都能给出看起来很专业的回答。更让人惊叹的是它的效率——眨眼之间就能完成人类大半天的工作量，写代码、画图、分析数据，样样精通，而且从不抱怨、从不疲倦。这种体验实在太震撼了，以至于很多人开始觉得:“有了 AI，还有什么做不到的?”——但，这只是它光辉耀眼的表象。

当你真正尝试深入使用时，尤其是在你自己擅长的领域，你会发现一个诡异的现象: 它在我不懂的领域侃侃而谈，一到我懂的领域就露馅了。你让它写一段你不熟悉的代码，看着挺像回事儿;可让它写你精通的领域的代码，你立马发现各种问题——逻辑不严谨、边界情况没考虑、性能有隐患、甚至有明显的错误，但它依然用那种“我很确定”的语气给你解释为什么这么写是对的。这时候你才意识到:那些你不懂的领域，它说的话有多少是真的靠谱，又有多少只是“看起来靠谱”?

这种落差感其实揭示了一个关键问题:如果我们真的要依赖AI，把它应用到严肃的场合，我们必须理解 AI 的能力边界和工作原理，不能再把它当成一个完全的黑盒。就像医生不能光凭症状开药，还得懂疾病的病理机制一样；工程师要用好 AI，也得明白它为什么有时候“神”，有时候又“蠢得离谱”。

当前的 LLM 本质上其实是一个概率预测器。这可不是打比方，而是严格的技术定义。它的工作原理说起来也很简单：你输入 写一个排序算法 写一个排序算法，这句话会被切成一个个 Token（可以理解成词的碎片）：["写", "一个", "排序", "算法"]。然后 LLM 开始它的核心任务：根据已有的 Token 序列，预测下一个 Token 的概率分布。注意，它不是在“思考”该写什么，不是在“理解”你的需求，更不是在“设计”算法。它就是在做一个纯粹的统计计算：给定前面这些词，下一个位置出现什么词最有可能。

这个计算基于什么呢？基于它在训练时“见过”的海量数据里学到的各种规律和模式。这些规律和模式信息，在训练完成后，就是变成了模型的参数保存下来。比如，GPT-4 有超过1000亿个参数。你可以把这些参数想象成 LLM 的“知识库”，或者说是“认知库”，但它不像数据库中的文档那样结构清晰，更像是一个巨大的、模糊的、难以解释的、高维的“直觉网络”。比如说，看到 import pandas as 时，LLM不是去知识库搜索类似的语料，而是根据某种概率，算出下一个词多半是 pd；看到 def quicksort( 时，接下来大概率会出现排序算法相关的代码。因为模型在训练时见过无数类似的例子，它学习到了某种“特征规律”，所以它“知道”什么问题通常对应什么解法，什么代码结构常出现在什么场景下。

具体的生成内容的过程大概是，根据当前的Token序列，模型先算出下一个 Token 的概率分布，然后根据某些策略从概率较大的备选项中选择一个，更新token序列，然后继续生成，不断往复，直到结束。比如：

1: [我 爱你](老婆、中国、宝贝)  --> pick 中国2: [我 爱你 中国](亲爱的 美食 ...)  -> pick 亲爱的3: [我 爱你 中国 亲爱的]...end: [我 爱你 中国 亲爱的 母亲 我 为 你 流泪 也 为 你 自豪]

从这里可以看出，它不是真的在思考，只是在做概率预测和选择。理解了这一点，我们就可以很容易明白一个道理，如果要提高AI生成的准确性，那就给它更多有效信息呗，这样预测准确率就提高了。就像天气预报一样，气象数据越全（温度、湿度、气压、风向），预测就越准。但这里有两个关键：“更多”和“有效”。“更多”好理解，就是多给信息。“有效”就复杂了——什么信息才算有效？

• 任务描述要精确：不是“写个排序”，而是"写一个针对整数数组的快速排序算法，包含详细注释，时间复杂度说明，以及边界情况处理"

• 上下文要相关：如果你在开发一个 Web 应用，那么相关的技术栈信息、项目结构、编码规范都是有效上下文

• 约束条件要明确：性能要求、兼容性要求、安全要求等

• 期望输出要具体：不是“帮我优化”，而是“针对这个函数的内存使用进行优化，保持 API 兼容性”

到这你可能就会理解，为什么网上看到的prompt，通常一开始都是“你是一个xxx角色，你擅长xxx……”。这些前置的输入虽然很短，但是它给出了更多的“已知条件”，这会大大影响LLM的Token预测的方向性和准确性。比如，你问AI：肚子痛怎么办？，AI的回答可能是非常随机的。但是如果你给了一些前置token去影响它的预测方向：

• 你是一个医生，针对患者的提问给出一些针对性的建议。患者： + 肚子痛怎么办，LLM就会给出一些医疗建议

• 你是一个搞怪主播，对粉丝的提问进行嘲讽是你的特色。粉丝： + 肚子痛怎么办，LLM的输出可能就会很扎心

然而，另一个不得不面对的问题就是，LLM的上下文窗口是有限的。这就引出了个核心问题：

在有限的上下文窗口里，怎么塞进去尽可能多的有效信息？

这个问题看似普通的问题，其实这是整个 AI Agent工程优化的核心命题。所有的 Prompt Engineering、Context Engineering、AI Agent做的各种优化，说到底，都是在解决这个问题。

不过在深入讨论解决方案之前，得先面对一个更现实的问题：概率预测器有个天生的“缺陷”，既然是概率——它不可能百分百准确。这不是工程问题，是数学问题。只要基于概率，就必然有误差。再牛的 LLM，再精心设计的 Prompt，都没法让准确率达到100%。

这个局限的影响有多大呢？假设有个复杂任务要拆成多步来完成，AI对于每个单步任务一次性就能完全搞定的概率是95%，看着挺高了吧？但连续10步任务的成功率就变成了 0.95^10 ≈ 60%，50步任务直接掉到 0.95^50 ≈ 8%。这就是我们接下来要详细聊的 p^n 困境——AI完成复杂任务的成功率会呈指数级下降。而通常我们期望AI帮我们干的活，可远不止50步…

理解这个困境，才能真正开始构建可靠的 AI 协同系统。既然单纯提高 LLM 的“智能程度”有天花板，那有没有别的路子？这个答案，可能和你想的不太一样。

理解了 LLM 的概率本质后，一个残酷的数学现实就摆在眼前：复杂任务的成功率会呈指数级下降。这不是工程问题，不是优化问题，而是数学必然。

假设 AI 完成单个步骤的成功率是 p，那么完成 n 个步骤任务的成功率就是 p^n。这公式看着简单，但威力惊人：

• 0.95^10 = 60%

• 0.95^20 = 35%

• 0.95^50 = 8%

这个数学规律解释了一个普遍现象：为什么 AI 在简单任务上表现优异，在复杂任务上却频频翻车？为什么那些宣称能“自主完成复杂项目”的 AI Agent 往往言过其实？我们想象中的“只要给AI配上各种MCP，AI就能完成一切”，为什么几乎啥也干不成？原因就在这个简单而无情的公式：p^n，我们初中就学过，当P<1时，它是一个单调下降的指数函数。

更关键的是，这是指数级的衰减。任务复杂度从10步增加到20步，成功率不是减半，而是从60%骤降到12%。复杂度再往上加，成功率会快速趋近于零。 很多人会想，随着技术的进步，如果当AI的能力持续提升，成功率p变大，是不是就可以缓解这个问题了呢？想法很自然，但其实也不行。为什么？算笔账就知道了。

将单步成功率从90%提升到95%，看着只提升了5个百分点。但对20步任务来说：

• 0.90^20 ≈ 12%

• 0.95^20 ≈ 36%

成功率提升了3倍，这确实可观，但依然只有可怜的30%+。并且更大的问题在于，继续提升 p 的边际收益递减，而成本却指数上升。从90%提升到95%可能需要10倍的训练数据和计算资源；从95%提升到98%可能需要100倍；而从98%提升到99.5%可能需要1000倍。实际上更是如此，我们可以发现近期的新发布的大模型，相较于前一代，在测评集上的提升很多只有1~2个百分点。且更根本的问题是：你永远不可能让 p = 1，概率预测器的本质决定了它必然有误差。

那真正可行的解决方案是什么？答案从数学上讲很简单：对于p^n，既然p的提高很难，那就想办法减小n，也就是 让 AI 承担的事情尽量少。但是这又会让人困惑，我们是期望让AI承担更多，但是为了让效果更好，有需要让AI承担更少，这不就又回到原地了吗？虽然结论可能令人感觉沮丧，但是并不意味着AI Agent的上限被锁死到demo级了。我们应该转变思维，从“通过完全把任务交给AI来提效”这种目标，转换为“人和AI协同来提效”。

举个例子。假设你要开发一个用户注册功能，包含这些子任务：理解需求、设计数据库表结构、编写API接口、实现表单验证逻辑、处理错误情况、编写单元测试。

方案A，全交给 AI 期望能够端到端一次性完成。AI 需要独立完成所有6个子任务，每个子任务的成功率假设是90%（p = 0.9），总成功率：0.9^6 ≈ 53%。也就是说，有近一半的概率 AI 会在某个环节出问题——可能是数据库设计不合理，可能是忘了处理某个边界情况，可能是测试覆盖不全。而且在越靠前的环节出问题，对后面影响越大。如果一开始表结构就设计错了，后面基于这个设计来开发的代码即使准确无误也没有意义了。

方案B，人机协同。你先来理解清楚需求、设计整体技术方案，并输出详细的文档，然后再让 AI 根据你的文档生成具体的代码实现（AI的部分：2个子任务，成功率 0.9^2 ≈ 81%），然后由你来列出详细的测试点，再由AI来实现测试代码（p=0.9），最后用自动化工具跑测试和检查。AI只参与3个部分，因此总成功率：0.9^3 ≈ 72%。显著高于第一种端到端的方案

这个例子说明了一个深刻的工程哲学：当某些子任务可以用确定性的方式完成时，永远优先使用确定性的方法，而不是依赖“智能”。自动化工具不比 AI 聪明，但它有 AI 没有的东西：确定性。只要输入对了，它就会给出正确结果，成功率100%。好比我们在做一张数学试卷时，为了得到更高的分数，能用计算器（程序）算的就一定不要用笔算（智能）。

这道理在软件开发中到处都是。原始的开发团队什么都靠人工：手动编译构建、手动测试、手动把二进制拷贝到服务器执行发布……每个环节都依赖人的“技能”和“细心”，结果只会是出错频繁故障不断。而成熟的开发团队则大量用自动化：通过CI/CD把编译、构建、测试、部署全自动化，自动化代码扫描静态分析，监控告警自动化检测异常、自动限流熔断，每个环节都依赖“确定性程序”而不是“人的可靠性”，两种团队负责的系统的稳定性自然也是天差地别的。

理解了 p^n 困境和确定性原则，我们就能重新审视 人和AI 协同开发了。错误的思路是 期望找到某种方法让 AI 能独立完成复杂的端到端任务。不断优化 Prompt 试图提高单步成功率，这在简单任务上虽然可能有改善，但复杂任务依然会频繁失败。而正确的思路应该是是 合理规划 人、程序、AI的分工，让拆解出尽量多确定性的部分让程序去完成，AI只处理难以程序化的模糊部分，然后人来做质量把控和关键决策。

p^n 困境告诉我们的一个事实是：你无法通过提升智能来彻底解决复杂任务的可靠性问题。即使到了gpt-100 claude-1000，只要p不是1，这个问题就依然存在。提高p用处不明显，而现实中的n又一定很大，那怎么办呢？我们该如何看待AI的价值？

前面说了，要让AI输出更准确，就要在有限的上下文窗口中输入充足且有效的信息，但通过大量实验和观察，我发现“有效信息长度”和“输出质量”的关系很像是一个有最值的类二次函数——一条决定了所有 AI 工程优化策略的曲线。

画出来的话，X轴是有效信息长度（用 Token 数量衡量），Y轴是输出质量（成功率、准确性、有用性等综合指标）。

这条曲线有三个阶段：

• 上升期（左侧）：有效信息很少时，输出的内容很难符合预期，AI 基本在“猜”，随机性非常高，和我们的预期可能相差甚远。随着有效信息的增多，AI的输出就会越靠近我们想要的内容。

• 平稳期（中间）：当有效信息可以足够详细地描述我们期望AI交付的任务时，AI输出的质量达到峰值。AI的输出稳定可靠，且计算速度也较快，可以称之为“舒适区间”或“可靠工作区间”。

• 衰退期（右侧）：有输入信息过载时，输出质量开始下降，虽然有效的信息可能都已经包含了，但由于信息过多，LLM的注意力被分散，关键信息被噪声淹没，幻觉现象开始出现，AI也频繁遗忘需求，输出速度也显著下降，且计算成本显著增加。这就好比让人一次性快速看完一本书，然后你去提问书里的内容，他肯定很多部分都没印象了。而如果他只看一小段内容，你再去提问，他大概率不会回答出错

但这条曲线只是逻辑概念上的，实际上我们根本无法绘制出来，因为当面对不同的任务时，到底需要多少有效信息是难以度量的，到底输出是否准确也是case by case的。面对简单任务，曲线的舒适区会左移并变宽，因为它需要的有效信息较少；而对复杂任务时，曲线的舒适区会右移并且变窄，因为需要更多信息去描述任务。

从这个图也可以看出，如果你让AI完成一个简单任务，实际上不太需要太多技巧，很容易就进入到“舒适区间”，成功率很高。而让AI完成复杂任务时，则需要我们做出很多努力才能进入到“舒适区间”。几乎可以认为，当下所有AI Agent的优化，都是围绕着这条曲线来展开的。

   4.1 快速填充上升曲线

由于AI看起来过于强大，因此大多数用户在使用 AI 时都会有个特点，就是——懒，非常懒。大家想的都是，既然AI这么强大，那我就要少干啊，否则我用它干嘛。这种懒到了什么程度呢？用户甚至连需求都不想说清楚，让我在输入框多打几个字都费劲。

典型场景就是，用户输入帮我写个在线五子棋小游戏，希望AI能准确无误地实现出来，自己可以试玩。但是这个诉求真的太模糊了，到底是运行在网页还是PC还是iOS？游戏界面具体长什么样？玩家是否可以聊天？是否需要做游戏大厅，方便玩家想玩时能快速找到对手？找不到对手时是否有AI，还是说只能真人对战？客户端使用什么技术栈开发？服务器使用什么技术栈开发？需要满足多大规模同时在线？做自己的账号体系还是直接对接微信QQ登录？……真的要上线这么一款游戏的话，这里有数不清的问题待细化。但是用户懒啊，谁用AI时愿意写一大段prompt啊？都是期望AI“看透我的心思”，甚至直接“超出我的预期”。

为了解决这个问题，以AWS 的 Kiro 和开源的 Spec Kit 等为代表的工具，采用了个巧妙的策略：问答式补全。它们的工作流程是，接到用户的模糊需求后，由 AI去生成一系列问题去向用户提问，让用户可以只需要点鼠标做选择题（没有期望的选项也可以直接输入），通过多轮对话逐步完善需求，最终得到相对充足的有效信息。

比如用户输入“我想做一个用户管理系统”，Kiro会不断地向用户提问：

• 用户规模（单选）：A) <1000 B) 1000-10000 C) >10000

• 主要功能（多选）：A) 基础注册登录 B) 包含权限管理 C) 包含组织架构

• 技术栈偏好（单选）：A) React+Node.js B) Vue+Python C) 其他(手动输入)

• ……

这方法的优势很明显：把“用户手动编写全部详细需求”变成“只需要点鼠标做选择题”，大大降低了用户的负担，但收集到了足够详细的信息。本质上是在快速填充曲线的上升段，让 AI有足够的信息支撑它后续准确地预测，也就是工作在舒适区。

除此之外，还有很多工程实践，比如项目级提示词（在 agents.md 里写清楚技术栈、代码规范、测试框架、部署平台、开发约定等），知识库集成（团队的最佳实践文档、常见问题解决方案、代码模板、架构设计文档），实时上下文收集（扫描当前项目结构、提取相关文件内容、分析依赖关系、Git 历史信息）。这些本质上都是帮用户自动化地补充一些信息，减少输入量，增加AI面对即将完成的任务的有效信息量。

   4.2 衰退区间

但当 AI 在舒适区工作一段时间后，随着对话进行，上下文会快速增长。很快，它会进入曲线的右侧衰退区——信息过载导致预测准确率降低 生成代码的质量下降。这时需要想办法减少上下文，最直接的就是使用上下文压缩技术。

想象你在听课，老师讲了45分钟，说了数不清的话，你不可能记住每句话也没必要记住，但你需要提炼出关键信息做成笔记，这个笔记理想情况下应该包含课堂上全部的重点知识。但怎么记笔记呢？班上前几名和最后几名学生，他们的笔记质量必然是天差地别的。上下文压缩就是相当于在做同样的事，把当前上下文中的关键内容记下来，把其它不重要的删掉，这样可以显著减少上下文token。但问题是：怎么提升笔记质量呢？举个例子：

原始对话（8000 Token）：

用户：我需要实现一个购物车功能AI：好的，我来帮你实现。首先需要确认几个问题...用户：我们用 React，需要支持增删改查AI：明白了。那我们来设计一下数据结构...[...详细的讨论过程...]

压缩后（1000 Token）：

需求：使用React实现购物车功能，支持 CRUD技术选型：React + Context API数据结构：{ id, name, price, quantity, image }功能清单：添加商品、删除商品、修改数量、计算总价已确认：支持本地存储，不需要后端同步

把对话中的“废话”删掉，只保留核心信息，去繁存简。这个想法当然没问题，但实际上挑战非常多。我们可以通过几个具体例子来看看到底会有哪些问题：

挑战1：哪些信息是“重要的”？

假设对话中包含这段：

用户：我们的用户量大概在10万左右AI：好的，那我建议使用索引优化查询用户：对了，我们主要用PostgreSQLAI：那可以用partial index来优化用户：嗯，但其实现在只有1000个活跃用户

压缩时，“10万用户”重要还是“1000活跃用户”重要？如果压缩掉了后者，可能导致过度设计；如果压缩掉了前者，可能失去了对未来扩展性的考虑。

挑战2：上下文依赖如何保持？

原始对话：

用户：这个按钮应该是蓝色的AI：好的，使用 #0066FF用户：不，我是说主按钮，次要按钮用灰色AI：明白，那主按钮 #0066FF，次要按钮 #999999用户：对，但hover时它应该变深一点

最后一句的“它”指的是主按钮还是次要按钮？压缩后如果丢失了上下文，这个指代关系就断了。

挑战3：隐含的约定如何传递？

对话过程：

用户：我们按照之前那个用户系统的设计来AI：好的，那就是用JWT做认证用户：对，记得加上刷新token[...后续50轮对话...]用户：这个API也要加认证

压缩时，“之前那个用户系统”包含的隐含约定（JWT、刷新token、具体的过期时间、存储方式等）如何保留？如果只压缩成“需要认证”，关键的技术细节就丢了。

挑战4：同一概念的不同表达怎么处理？

对话中可能出现：

第5轮：用户提到"购物车"第18轮：用户说"那个临时存储商品的地方"第32轮：用户说"cart"第41轮：AI说"ShoppingBasket组件"

这四个其实说的是一个东西，但压缩时如何识别并统一？如果当成四个不同的概念，反而增加了混乱。

挑战5：时间线和因果关系怎么办？

原始对话顺序：

1. 用户：我们需要支持支付功能2. AI：建议接入Stripe3. 用户：但是我们的用户主要在中国4. AI：那改用微信支付和支付宝5. 用户：对，而且要支持分期付款

如果压缩时只保留结果“需要微信支付、支付宝、支持分期”，就丢失了“为什么不用Stripe”的背景。后续如果有人问“为什么不用国际通用的Stripe”，就缺少了决策依据。

通过这几个例子你就可以感受到，上下文压缩是一件非常具有挑战的工作。这也是当下为什么很多AI编程工具在auto-compact之后，经常生成质量反而更低的原因。claude-4.5和gpt-5-codex在发布时对外宣传可以持续工作7小时，现在你能理解它们本质上在宣传什么能力了吗？

   4.3 平稳区间

还有一种策略可以让AI尽可能持续工作在舒适区：任务外包，也就是业界常说的MultiAgent。当主 Agent 需要完成一个复杂的大任务时，在某些步骤可以识别出相对独立的子任务，然后把这整个子任务外包给另一个Agent（SubAgent），只给它提供任务所需要的最精简的上下文，最后将 SubAgent 的结果整合到主流程。对主 Agent 来说，它自身的上下文长度没有增长，因为任务被“外包”了，但同时子任务也完成了，它拿到了它关心的结果。这样就可以做到上下文几乎不变的情况下推进任务进程，维持AI工作在舒适区，避免进入信息过载区。而对 SubAgent 来说，它获得了针对性的、精简的上下文，也工作在舒适区，任务边界清晰，成功率也很高。

这种做法在平时太过于常见了，比如在做产品需求时，客户端和服务器端程序员会商量好接口，然后各自进行开发，最后一起来联调。服务器端不需要关注客户端的开发细节，反之亦然。MultiAgent 策略就是这个道理。单Agent方式下，Agent需要深入理解每个细节，上下文持续增长，很快就会过载。而在MultiAgent方式下，主 Agent虽然也会进行工作，但是它会按需把部分较为独立的工作外包给SubAgent，一方面大大减缓了主Agent上下文的增长，同时也让SubAgent在上下文更加精简的状态下工作，更能提高子任务的成功率。

其实业界还有非常非常多的优化手段，你仔细分析的话，都可以发现它们就是在解决这条曲线的问题，尽最大可能让AI工作在舒适区。舒适区理论可以给我们一个有用的思维框架，帮助我们理解AI的行为模型，可以解释为什么某些优化策略有效，也可以指导工程实践的方向，帮我们避免了无效的优化尝试。

更重要的是，这个理论让我们认识到一个关键事实：无论如何优化，AI 依然是不可靠的。我们无法确定给定的信息是否足够，也不知道 AI 现在工作在曲线的哪个区间。即使尽了最大努力让 AI 工作在舒适区，但p^n 困境依然存在，复杂任务的成功率依然会随着复杂度增加而指数下降。这难道是AI的死结吗？因为不可靠，所以难堪大用吗？

可问题是，人也是不可靠的。人也会犯大量错误，人也有知识水平高低，人还受各种情绪影响，甚至经常“不可用”(请假)。我们一群“不可靠的人类工程师”可以“可靠地”完成大量复杂任务，而为啥我们对AI却心存疑虑呢？每当我们发现AI不靠谱时，最终还是由人去接手，为什么用不可靠的人去给不可靠的AI兜底就可靠了？

人类的能力有个关键特征：层级递进性。什么意思呢？想象一个能够设计复杂分布式系统的高级工程师，他会设计微服务架构、处理一致性问题、优化性能瓶颈，当然也会编写业务逻辑、实现 API、处理异常，基础能力就更不用说了——熟悉编程语言，熟练掌握IDE的运用……。这里有个重要规律：如果一个人掌握了某种高级能力，必然是因为他掌握了某些更基础的能力。你几乎不可能遇到这样的场景：一个资深工程师某天早上来到公司，突然不知道怎么打开 IDE 了，或者不记得程序要从main函数开始了。听起来很荒谬对吧？但这恰恰揭示了人类能力的本质特征：它是累积性的、层级性的、稳定的。

再看个更明显的例子。假设一个学生数学考试考了145分，且最后的压轴题都做对了，那么试卷前面的简单题对他来说肯定不在话下，只是可能会因为粗心算错，但绝对不至于说简单题反而不会做。为什么？因为能够获得高分且能解决压轴题，意味着他已经牢固掌握了所有更基础的数学知识，并且能够灵活运用。高级能力的获得，必然以基础能力的稳固为前提。

但 AI 的情况完全不一样。AI 可以在国际数学奥赛中横扫人类选手，解决极其复杂的数学问题。但同一个 AI，可能会在下一秒告诉你：1.11 大于 1.9。这不是我编造的夸张例子，这是真实发生的事情。让LLM做逻辑推理时，它经常会出现这种“低级错误”。类似的问题很多，能够一句话生成完整 React 应用的 AI，可能会算错 73*52=?；能够解释量子力学的 AI，可能会数不清strawberry这个单词里有几个'r'。这违背了人类的能力层级规律。

为什么会这样？回到文章一开头说过的LLM的本质：它是概率预测器。

我想起了哲学家约翰·塞尔在1980年提出过的一个著名思想实验——中文房间论证：

想象一个完全不懂中文的人被关在房间里，房间里有一本详尽的规则手册，告诉他 “当收到某种符号组合时，应该输出某种符号组合”，规则手册涵盖了所有可能的中文问答组合。当有人从门缝塞进一张写着中文问题的纸条，房间里的人按照手册查找匹配的规则，然后写下对应的中文答案递出去。从外面看，这个房间“完美地”回答了中文问题。但房间里的人理解中文吗？不，他只是在机械地匹配符号。

LLM 的工作方式与此惊人地相似。它有海量的“规则手册”（模型参数中的概率分布），根据输入的符号（Token）匹配最可能的输出符号，可能给出看似正确的答案，但这不代表它“理解”了。LLM 不是先学会加法，再学会乘法，最后学会微积分。它是在海量数据中学习各种模式的概率分布。在这个过程中，每次预测都是独立的概率计算，不是严密的逻辑推断，不存在“能力依赖”关系。

正因为人类能力具有层级性，我们的错误也是可预测的。这种可预测性来自于我们对“能力层级”的理解。我们知道一个人可能会在哪里犯错，即使不知道具体会犯什么错。这就是 Known Unknown：我们知道存在未知，但我们知道这个未知的边界在哪里。而AI 的情况则完全不同。当你让 AI 完成一个任务时，你不知道它会在哪个环节出错，错误会是什么类型，错误的严重程度如何。我曾经使用claude去做一下关于某个Topic的深入研究，再写一篇调研报告，它很快进入了工作状态，而我眼看着账单哗哗地涨，直到花费了170块钱时终于完成了。按理说这时它需要把生成的报告写入到一个文件中，可这时它居然忘了怎么写入文件！明明Agent有内置的文件写入函数，它也在调用，但是它的调用指令就是不对。一直试一直错，而这个指令又是Agent内置了，我没找到具体文档，没法直接纠正，最后只能终止任务，消耗的token钱打水漂了。这个问题令人印象深刻的原因就是，这么牛逼的Agent，你想象不到它会在这么简单的事情上犯错，就像你难以想象你的同事突然哪天来问你，他不知道怎么把修改后的文件进行保存(vim除外)

这就是 Unknown Unknown：你不知道会有什么未知，你连未知的边界都不知道。

这种差异对系统设计有着深远的影响。当我们设计一个包含人类的系统时，我们可以识别风险点（新手工程师容易在哪里出错？），设置检查点（Code Review、方案评审、测试流程），建立防线（多级验证、灰度发布、快速回滚），培训提升（针对性地提高薄弱环节）。这些都基于一个前提：我们知道人会在哪里犯错。但当我们试图设计一个包含 AI 的系统时，无法识别风险点（AI 可能在任何地方出错），检查点难以设置（你不知道应该检查什么），防线难以建立（错误可能以任何形式出现），无法针对性提升（不存在“薄弱环节”，整体都是薄弱的）。更麻烦的是，你无法通过“测试”来穷尽所有可能的错误。人类工程师的错误有模式，AI 的错误是随机的。

这解释了为什么我们信任人类团队，却对 AI 心存疑虑。信任的基础不是“不会犯错”，而是“错误可预测、可控制”。人类团队虽然不可靠，但错误边界清晰，我们知道如何设计系统来规避风险、检测问题、快速恢复。AI 虽然在某些任务上表现优异，但错误边界模糊，我们不知道它会在哪里翻车，也不知道翻车的后果有多严重。

所以真正的问题不是AI是否可靠，而是AI的不可靠性 是否可控

• 可控：那我们就可以设计某些机制来检测和处理问题，进而才能实现我们期望的无监督运行，“完全把活交给它”。

• 不可控：那就必须在人的监督下运行。

当下的LLM，答案显然就是，它的不可靠性 不可控。这不是 AI 的缺陷，而是概率预测器的本质特征。只有深刻认识到这一点，我们才能真正理解到底该如何设计人机协同系统——不是寄希望于找方法让AI变得可靠，而是要让整个系统在 AI 不可靠的情况下依然可以可靠地运转。

那怎么才能让不可靠的AI在系统中可靠运转呢？我们每个人都是“不可靠会犯错的”，人类社会又是如何应对个体不可靠性的呢？

无论是人类还是 AI 都是不可靠的，但人类社会已经运转了数千年，我们建成了各种世界奇观，精密仪器，这些复杂的工程系统都能稳定运行，这是如何做到的？答案在于——用外部系统对抗个体不可靠。

系统设计的核心思想是：接受误差，设计容错。这包含两个层面：

• 接受现实：每个个体都会犯错，这是不可改变的事实

• 系统应对：通过系统层面的设计，对个体误差及时纠偏，或者设计容错能力，让个体的误差不会导致系统崩溃

就像工程师设计桥梁时，不会假设每块钢材都完美无缺，而是在设计中加入安全系数；汽车设计师不会假设路面总是平整，而是在设计中加入减震器、弹簧等来吸收震动和冲击。

飞机是人类工程史上对抗不可靠性的杰作。它涉及成千上万个部件的协同工作，还要在极端环境下保证安全，任何一个环节的失败都可能导致灾难性后果。飞机设计师怎么应对这种极端的可靠性要求呢？

• 关键系统有多重备份：液压系统通常有3-4套独立的，任何一套失效其他系统可以接管；双发或四发飞机的设计，即使一个引擎完全失效，剩余引擎也能维持飞行和安全降落；GPS、惯性导航、无线电导航等多套系统同时工作互相校验；多个计算机同时运算，通过投票机制决定最终指令。设计原则是：任何单点故障都不应导致系统失效。这意味着即使某个关键部件完全损坏，飞机依然能够安全运行或至少能够安全降落。

• 飞机的结构设计中融入了“损伤容忍”理念：机翼不是依赖单一主梁，而是多根梁共同承载；即使某处出现裂纹，结构设计也能阻止其快速扩展；压力分散到多个结构上，单一结构损坏不会导致整体失效。这就像一座桥梁，即使某根钢缆断裂，剩余钢缆的强度依然足够支撑桥面。

• 飞机上布满了各种传感器，实时监控系统状态：振动传感器检测异常震动，温度传感器监控引擎和关键部件温度，压力传感器监控液压和气压系统，EICAS/ECAM 系统集中显示所有系统状态，第一时间提醒机组人员。关键思想是：问题的及早发现，远比问题发生后的应对更重要。

• 飞机设计还考虑了驾驶员这个“不可靠个体”：警告分级（区分紧急警告、警告、提示，避免信息过载），防呆设计（关键操作需要特定的步骤才能执行，如起落架只能在特定速度下收起），自动保护（当检测到危险操作时系统会自动介入，如失速保护），双人制（重要决策需要机长和副驾驶员共同确认）。

如果说飞机设计是对抗物理不可靠性的艺术，那么团队管理就是对抗人类不可靠性的科学。一个成熟的软件开发团队，本质上就是一个精心设计的容错系统。比如在一个开发团队中：

• 需求与方案设计阶段：单个开发者的理解可能有偏差、考虑不全面。系统的应对就是方案评审：不同角色（产品、测试、其它工程师）共同评审，检查需求理解是否准确、技术选型是否合理、是否复用了现有基础设施、边界条件是否考虑周全、扩展性如何……。核心逻辑是，一群人同时犯同样错误的概率，远低于单个人犯错的概率。

• 编码实现阶段：开发者会写出各种 bug。系统应对是多层防护：静态检查自动化（Lint 代码规范检查、类型检查 TypeScript/MyPy 等、静态分析发现潜在问题），Code Review 人工（同行评审代码逻辑、检查潜在的性能问题、确保代码可读性和可维护性、知识共享），测试体系（单元测试开发者自测、集成测试模块间协作测试、端到端测试完整流程测试）。分层防御，每一层都能捕获一部分错误，多层组合大幅提高可靠性。

• 发布变更阶段，也会有很多问题出现。这些问题以及对应的手段都比较成熟，比如使用自动化的CI/CD系统、建设预发布环境、使用金丝雀发布等等。

• 长期维护阶段：问题是人员流动、知识流失、单点隐患。系统应对是知识与能力的冗余：Feature Team 分组，每个重要模块至少2-3人负责，避免“只有某某知道这块代码”的情况；文档体系包括架构设计文档、接口文档、运维手册、故障案例库；知识分享通过定期技术分享会、Code Review 中的知识传递、新人培训机制；自动化替代人工，包括 CI/CD 自动化部署、自动化测试、自动化监控和告警、自动化扩缩容。本质目标是避免任何“人员单点”，确保团队具有持续运转的能力。

无论是飞机设计还是团队管理，都能看到一些共同的模式：冗余与备份（飞机的多套液压系统、多个引擎，团队的多人负责同一模块、方案评审多人参与）；分层防御（飞机的结构冗余+系统冗余+实时监控+人工决策，团队的静态检查+Code Review+测试+预发布+灰度发布）；及早发现（飞机的各种传感器实时监控异常，团队的方案评审在编码前发现问题、Code Review 在发布前发现问题）；快速恢复（飞机的损伤容忍设计、备用系统接管，团队的快速回滚、紧急修复机制）；自动化优于人工（飞机的自动驾驶、自动保护系统，团队的 CI/CD、自动化测试、自动化监控）。

所有这些精妙的系统设计都基于一个关键前提：我们知道哪里可能出错。对于飞机，我们知道引擎可能失效就设计多引擎冗余，知道液压系统可能泄漏就设计多套液压系统，知道结构可能疲劳开裂就设计损伤容忍结构。对于团队，我们知道开发者理解需求可能有偏差就设计方案评审，知道开发者会写出 bug 就设计多层测试体系，知道生产环境可能有未预见的问题就设计灰度发布。

这就是前面提到的 Known Unknown——我们知道会有问题，虽然不知道具体是什么问题，但我们知道问题可能出现在哪些地方。基于这种可预测性，我们可以识别风险点、设计检查机制、建立防护措施、制定应急预案。

但当我们试图为 AI 设计类似的容错系统时，会面临一个根本性的挑战：AI 的错误是 Unknown Unknown。我们不知道 AI 会在哪里出错，简单任务和复杂任务都可能失败，之前成功的场景下次可能失败。无法设计针对性检查，因为不知道应该检查什么，测试用例无法穷尽所有可能，通过测试不代表真的可靠。冗余策略效果有限：多个 AI 可能犯同样的错(都基于类似的训练数据)，投票机制的前提是错误是独立的，但 AI 的错误可能有系统性偏差。快速恢复很困难：错误可能已经渗透到整个输出中，难以判断哪部分是对的哪部分是错的，重新生成又是一次 p^n 过程。

这是否意味着飞机设计和团队管理的那些方法完全不适用于 AI？倒也不是。冗余检查、分层防御、及早发现这些原则依然有效，但它们需要以一种完全不同的方式来实现。关键问题是:如何把 Unknown Unknown 转化为 Known Unknown？如何让 AI 的不可预测性变得相对可预测？要回答这个问题，我们需要更深入地思考AI和智能的关系。

“AI 马上就要实现 AGI 了！”，“LLM 已经具备了人类水平的智能！”，这些言论充斥着科技媒体和社交网络。1950年，艾伦·图灵提出了著名的图灵测试：如果一台机器能在对话中让人类无法区分它和真人，那么就可以认为这台机器具有智能。而2025年，GPT-4.5通过了图灵测试。这是否意味着GPT-4.5真的有了智能？

让我们回到前面中文房间的例子。还记得那个完全不懂中文的人吗？他通过规则手册“完美”地回答了所有中文问题，从行为结果上看，它就是一个懂中文的人，他通过了“中文图灵测试”。但他真的理解中文吗？不，他只是在匹配符号。图灵测试只测试了表现，但表现不等于理解。gpt-4.5通过图灵测试，只证明了它擅长模仿人类的语言模式，在某种评测集上表现优异，但不代表它具有真正的智能。当前的 LLM 拥有海量的知识储备——它训练在包含几乎全人类知识的数据集上。它知道历史、科学、文学、编程，似乎无所不知。但知识储备能等价于智能吗？AI 大佬 Yann LeCun（图灵奖得主、Meta 首席 AI 科学家）曾明确指出：当下的 LLM 技术路线不可能实现 AGI，他的观点引发了业界的广泛讨论，也有越来越多的AI圈奠基式的人物赞同他的观点。

假设未来有个 GPT-6，知识储备包括人类历史上所有的文献、代码、科学论文，推理能力可以解决复杂的数学问题、编写精巧的程序，语言能力精通所有人类语言、文笔优美。而另一边是一个蹒跚学步的婴儿，知识储备几乎为零、可能连话都说不清楚，推理能力非常有限、只能进行简单的因果推理，语言能力可能只会喊“妈妈”。问题来了：哪一个更“智能”？从知识和能力的角度看，GPT-6 碾压婴儿。但从智能的本质来看，婴儿才是真正智能的存在。为什么？

要理解智能的本质，我们需要超越“知识”和“能力”的表面，看到更深层的特质。虽然学术界对"智能"的定义众说纷纭，但几乎所有定义都包含两个核心特质。

第一个特质是自我纠错能力——能够自主判断目标是否达成，并在未达成时调整策略。婴儿想要拿到桌上的玩具，第一次够不着，它能够自己意识到“目标没有达成”（玩具还在那里，我手里没有），然后调整策略，尝试爬上椅子，再次尝试，直到它能够自己判断“目标达成了”（玩具在我手里了）。这个闭环的关键是：婴儿不需要别人告诉它“你失败了”或“你成功了”——它自己知道。

LLM 的“纠错”呢？你让它生成一段代码，它写完了，输出给你。代码有没有错？能不能运行？符不符合需求？LLM 自己完全不知道。你需要告诉它“这里有错”，它才会重新生成。更关键的是，即使重新生成了，它依然不知道新的输出是对是错——还是需要你来判断。关键区别在于：婴儿有内在的判断标准（它知道“玩具在手里”意味着成功），LLM 没有内在的判断标准（它不知道生成的代码是否正确）；婴儿的纠错是自驱动的闭环（感知目标→行动→判断结果→调整策略），LLM 的纠错是依赖外部的开环（接收输入→生成输出→等待人类判断→接收新输入）。

第二个特质是自我提升能力——能够基于经验不断改进，在同一个个体内部实现能力的增长。一个小孩学骑自行车：第一天上车就摔，扶着墙勉强保持平衡；第二天能推着车走几步了，但还是不敢骑；第三天战战兢兢地骑了几米，摇摇晃晃但没摔；一周后已经能稳稳地骑一圈；一个月后可以单手骑、拐弯、加速。这是同一个孩子，在同一辆自行车上，能力在持续提升。关键是什么？每一次尝试的经验都在改变他的大脑——神经连接在调整，肌肉记忆在形成，平衡感在增强。第100次骑车时的他，和第1次骑车时的他，已经是一个升级过的版本。

LLM 的“提升”呢？今天你让 GPT-4 写一个排序算法，它写了一版；明天你再让它写同样的排序算法，它不会因为昨天写过就变得更好——还是基于训练数据做概率预测，和昨天一样，可能对也可能错。你用它写了1000次代码，第1001次的表现，和第1次完全一样。它没有变化，没有成长，没有提升。GPT-4 到 GPT-5 的提升？那不是“同一个个体”的自我提升，而是用更多数据、更多参数重新训练出一个新模型。不是进步了，是换人了。

不只我们人类拥有智能，自然界各种动物都有智能。一只猴子，知识储备远不如 LLM，语言能力几乎没有，但它具有自我纠错能力（尝试用不同的方式打开坚果），自我提升能力（年轻猴子观察学习年长猴子的技巧），工具使用能力（学会用石头敲开坚果，并且越用越熟练）。一只乌鸦的知识储备更加有限，但它能理解因果关系（知道把石头放进瓶子可以让水面上升），使用工具（弯曲铁丝制作钩子），传授经验（教会幼鸟同样的技巧）。而 LLM 呢？知识储备远超所有动物，但它不能真正纠错（每次生成都是独立的概率计算），不能自我提升（模型参数在推理时是固定的），不能真正理解事物的运行规律（只是一味地算概率）。从这个角度看，即使是一只乌鸦，也比 LLM 更“智能”，虽然它知道的远没有 LLM 多。

问题的根源在于 LLM 的技术架构。当前的 LLM 基于 Transformer 架构：训练时调整参数、学习模式，推理时参数固定、只进行前向计算，无法在运行时学习（不能基于新的经验修改自己）。这就像一本已经印刷好的百科全书：内容丰富但固定不变，可以查阅但不能更新，再多的使用也不会让它变得更好。

真正的智能需要一个闭环：行动 → 观察结果 → 评估反馈 → 调整策略 → 再次行动。LLM 缺少这个闭环：输入 → 概率计算 → 输出 →（结束，无反馈）。即使 AI Agent 框架试图加入工具调用和反馈，但这个反馈不会真正改变 LLM 的“大脑”（参数），只是增加了Token，提高了它下次预测的成功率，表现起来像是进步了。

这里有个有趣的悖论：LLM 拥有的“知识”越多，可能离真正的智能越远。为什么？因为真正的智能不是来自于记忆大量的事实和模式，而是来自于在有限信息下进行推理的能力、从新经验中学习的能力、理解概念本质的能力、创造性解决问题的能力。一个孩子不需要理解万有引力，看到苹果悬空就会往下掉，就知道其它重物悬空也会往下掉。这种理解是通过亲身经验和思考得来的，不是通过记忆。而 LLM 恰恰相反——它依赖于观察海量模式背后的统计学规律，缺乏真正的理解。

看到这里，也许你会说：“好吧，LLM 不是真正的智能，但它确实能干活啊！它能写代码、能分析问题、能生成文档。既然能完成任务，管它是不是真正的智能呢”。这个想法很有道理。毕竟，我们雇佣一个员工，关心的是他能不能把工作做好，而不是他的认知机制是什么。

但这里有一个关键的问题：一个“能干活”的员工，和一个“能干活且对结果负责”的员工，完全是两回事。想象这样一个场景：你招了一个新员工，他技能很强能解决复杂的问题，反应很快立刻就能给出方案，知识丰富几乎无所不知。但是，他不会主动检查自己的工作成果，发现问题也不会有任何愧疚或反思，做错了事也不会承担任何后果，下次遇到同样的问题还会犯同样的错。你敢把重要的工作交给他吗？这就是 LLM 的真实写照，它能力很强，但缺乏对结果的责任感。而这个问题，比“缺乏智能”更加致命。

因为缺乏智能我们可以通过系统设计来弥补（就像我们在前面章节讨论的），但缺乏责任心意味着它根本不在乎自己的输出是对是错。这不仅仅是能力问题，而是态度问题。一个能力不足但认真负责的人，至少会小心翼翼地工作、主动检查结果、发现问题会及时反馈、从错误中学习。而 LLM 不会。它只是在完成一个又一个的概率预测，对最终结果毫无感知，不负责，就谈不上“想尽办法去搞定”了。

在讨论AI这种比较技术向的话题中，讨论责任心这种抽象的问题，看起来有点离谱，但其实，我觉得这才是根本性的问题。大家可以想想，各个团队在招人时写得要求：“有责任心，有技术热情，有自驱力”，这背后到底在期望什么？

在讨论 AI 的责任心之前，我们先要理解：人类的责任心从何而来？

想象你在写一段关键代码，这段代码会部署到生产环境，影响数百万用户。你会反复检查逻辑是否正确、考虑各种边界情况、进行充分的测试、谨慎地提交代码。为什么你会这么做？说得直白点，不就是怕出事背锅吗？如果出事故了，责任心的缺失：AI为什么不在乎？领导会找你谈话（绩效受影响），年终奖可能泡汤（真金白银），如果事故严重，还工作可能不保（房贷车贷怎么办？）。没了工作，怎么养家？这才是真实的责任心来源——你有内驱的诉求（赚钱养家），你通过工作来实现诉求，而如果不好好完成工作，你的诉求无法实现，而你无能接受这个后果，因此你产生了对工作的责任心。人类的责任心，本质上就是这种后果意识的具体表现。只有当你有内驱的诉求时，才会产生责任心，这非常关键。即这种诉求不是外界强加给你的，而是你自己内心深处产生的。

看个例子或许更好理解。假如你是一个团队的新人，你写出了一个生产环境 Bug，导致用户无法下单，老板很着急，限你今晚必须解决。你查了半天，完全没头绪，只能向公司的技术大牛老王求助。现在有两种情况：

• 情况 A：老王在另一个团队。你在微信上找到老王，把问题和各种已知信息发给他。老王看了看：“嗯，这个问题确实有点复杂，我感觉应该是缓存和数据库同步的问题，你可以看看 Redis 的配置，以及那坨同步的逻辑，大概率问题出在这里。”然后，事情就交回给了你，你按照他的方向查了一圈，但还是没解决。再去问他，已经是晚上 9 点，老王：“兄弟，你等会儿啊，我现在在处理别的问题。明天空了我再帮你看，或者找你们组的大佬帮看看？”。为什么老王不愿意深入帮忙？很简单，这个 Bug 解不解决不影响他的绩效，顺手的事可以帮一把，但要跟你熬夜排查，凭啥？解你这个Bug不是他“内驱的诉求”，是你加给他的，外驱的，而你能量有限驱不动他（如果你能找他领导，他领导让他来帮忙看下，或许就不一样了）。

• 情况 B：老王和你在同一个团队。同样的 Bug，同样找老王。但这次老王的反应完全不同：“你把traceid发我，我看看调用链。你能发请求复现吗，我登上服务器去看下”……然后老王开启了debug模式，最后顺利定位到了问题，提交了MR还顺便帮优化了代码。为什么同一个老王，行为可能天差地别？因为现在这个 Bug 关系到他自己：Bug 不解决整个团队的 OKR 受影响，团队 OKR 黄了他的绩效也黄了，即使bug不是他写的，他作为senior也有责任。所以，“这个Bug要得到解决”对他就是“内驱的诉求”，进而产生了责任心。

因此你可以看到，同一个人，同样的技术能力，责任会让行为模式完全不同。

可是LLM它不是智能，它无欲无求，不知道自己从哪里来，不关心自己要到哪里去，没有目标，没有牵挂——自然也就没有责任感。任何你布置给它的任务，都是外驱的。既然是外驱的，那你就得“额外做功”，才能“驱动”得了它。那要怎么做功呢？我们同样可以参考人类社会的做法

比如你是个技术经理，带着一些同学负责某个业务。当一个需求来了，通常你会让直接负责该模块的同学去对接需求和完成后续开发。虽然工作中的牛马们内置了“想要挣钱想要好绩效”等System Prompt，以及这种内驱力带来的责任心，驱动他们尽可能好地完成工作，但是，人始终是“不可靠的”。他可能会犯 粗心大意、方案设计时没考虑周到、写代码不小心写出bug等等非主观恶意的错误，这些问题如果不被识别和纠正，最终就会在他交付的Feature中体现，严重的会造成线上事故。进一步的问题就是，这个事故的后果，你作为团队的技术经理，你能不能承受。如果一个非常重要的系统，这个故障又导致了非常严重的后果，即使你把“始作俑者”开除了也无济于事，你依然要承担责任，甚至你可能也会被你的领导开除。又或者，你让另一个同学B去承担某个重要运营活动功能的开发，为了配合活动宣发，公司请了大量明星来预热，活动需要确保在国庆当天上线，这是项目组一年之中收入冲高的关键节点。但是突然有天，B出车祸手臂被撞骨折了，目前正躺在手术室的床上。你不可能现在打电话去问进度，问什么时候能回来加班，让他确保国庆活动按时上线吧？这时你怎么办？需求上不了线，这是你团队的问题，也就是你的问题，最后你就要承担无法交付的后果。所以，即使员工有“内驱力”，管理者也需要在“系统设计”层面“额外做功”，才能及时感知和纠正问题，最终保障能够按时保质保量交付功能。比如，合理分配人力，让各个模块都有人能够backup；组织方案评审，减少出现方案设计不靠谱的概率；建立CodeReview机制，多增加一道门槛就可能再少一些问题；建设可观测体系，优化告警准确性，及时感知线上故障；追踪每个人的工作进度和风险以便及时应对，比如深入使用tapd去追踪和管理进度，要求拆更细的task，以及周会/日会等等……

比如你是一家公司老板，你现在想新建一个公司总部大楼。你对建筑工程一无所知，但你有个初步想法：希望大楼有30层，外观大气金碧辉煌，要有大型会议厅和员工健身区，且所有一切的预算不超过10亿。于是你找到了一家知名的建筑设计公司，把你的想法告诉他们，让他们出设计方案。一个月后，设计公司交付了厚厚一沓图纸：建筑设计图、结构设计图、水电暖通图、消防图……你翻开一看，满眼都是专业术语和复杂的线条，你能看出大概的外观，能看懂楼层布局，但你真的能判断这个设计靠不靠谱吗？地基承重设计是否合理？消防通道是否符合规范？抗震等级够不够？HVAC系统容量是否匹配？设计方案的造价预算是7亿，看起来在预算范围内，但这个预算准确吗？有没有漏项？施工阶段会不会超支？这些你一概不知。怎么办？你需要找“自己人”——聘请专业的工程咨询公司，或者组建自己的工程管理团队（包括技术专家和造价工程师），让他们对设计方案进行专业审核验收。他们会逐项检查设计的合理性、安全性、经济性，核算工程量清单和造价预算，发现问题就要求设计方重新修改，直到方案真正可靠且预算可控。

方案确定后，你找来了施工单位开始建设。但施工单位会严格按照设计图纸施工吗？未必。他们可能为了节省成本偷工减料，可能因为工人技术不过关导致质量问题，可能因为赶工期而跳过必要的养护期。更糟糕的是，施工方可能会不断提出“设计变更”：“老板，这个地方按图纸施工有问题，得改，改了要加钱”、“这个材料市场缺货，换个品牌要加价”……每个变更单独看都有道理，但累积起来可能让预算失控。你不可能每天都泡在工地上盯着，你也不懂那些专业的施工工艺和造价明细。怎么办？你需要引入监理单位——一个独立的第三方，专门负责监督施工方，检查每道工序是否符合规范，材料是否达标，施工质量是否过关。地基浇筑完成，监理要验收；主体结构封顶，监理要验收；水电管线铺设完，监理要验收……每个关键环节都需要经过专业的验收才能进入下一步。

但是，仅有监理还不够。监理单位虽然是独立第三方，但他们也是你花钱请来的外部团队，他们不会像你一样在乎这个项目的最终质量和成本——这不是他们“内驱的诉求”。监理可能和施工方关系好，睁一只眼闭一只眼；监理可能敷衍了事，走个过场就签字；监理可能专业能力不够，看不出隐藏的问题；监理对施工方提出的各种变更和加价也可能缺乏足够的审核力度。所以，你作为甲方，还需要派驻自己的工程管理人员到现场“盯着”。这些人不需要事事亲力亲为，但需要在关键节点出现：重要的结构验收要在场，重大的设计变更要参与决策，发现施工和设计图纸不一致要及时叫停，对施工方提出的每一笔变更和加价要求进行严格审核。同时，你还需要建立完善的成本管控体系：要求施工方提交详细的月度进度报告和成本报告，你的造价工程师会逐项核对已完成工程量、已支付费用、剩余预算，一旦发现成本有超支风险就要立即预警和干预。你派驻的人，代表的是你的利益，这个楼最终是你要用的，预算超了也是你的钱打水漂，出了问题你要承担后果，所以即使有专业的设计方、施工方、监理方，你依然要通过“系统设计”——建立多重验证机制、关键节点把控、派驻现场人员、成本过程管控——来"额外做功"，确保最终能交付一栋真正可用、安全可靠、预算可控的大楼。

对于有有智能且有责任心的人类，尚且需要建立非常复杂的机制，才能确保最终交付可靠的产品，更不必说对于 无欲无求的LLM 了。那有没有可能，我们训练LLM时就给他植入目标和责任心呢，让它至少不出那么离谱的错误，会自己去评估自己生成的内容是否有达到交付标准，需求不清楚就主动去问而不是不明不白就开始干活，遇到不会的就去查而不是一本正经胡说八道……

   8.1 “对齐”的局限

其实也不是没有人做这件事，也许你听说过 AI 对齐（AI Alignment）——试图让 AI 能像人一样具有目标感和责任意识。OpenAI、Anthropic 等公司投入大量资源在 RLHF（人类反馈强化学习）上，试图让 LLM 更“安全”、更“负责”，让它的每次行为更像人一样“可解释”。但这有根本性的局限：RLHF 训练的是模式，不是意识。经过对齐训练的 LLM可能：

• 学会说“我不确定”（当训练数据告诉它应该这么说时）

• 学会拒绝危险请求（当识别到危险模式时）

• 学会表现得“谨慎”（当训练数据包含谨慎的回答时）

但这些学的都是pattern，不是真正的责任心。就像一个演员可以完美地表演“愧疚”的表情，但他内心可能毫无愧疚感。LLM 也只是学会了“表演”负责任的样子。宇宙大厂Anthropic就有多篇文章和播客提及这些问题：

• The Utility of Interpretability：Anthropic 研究员 Emmanuel Amiesen 举例说明了链式思考（Chain-of-Thought）并非真实演算。Claude其实已经得出了答案，但是因为提示词的要求，它“逆向利用提示，假装进行了计算”从而给出答案。看起来它是一步步地计算，但其实并没有执行所述推理步骤

• Tracing the thoughts of a large language model：Claude 在回答时会“为既定答案编造合理论证”，即尽管已经知道答案，依然“演示”看似一步步的推理过程

• Claude’s extended thinking：Claude输出的思维过程并非全貌，模型“经常根据未在思维过程中明确讨论的因素做出决策”，因此“我们无法仅凭当前模型展示的思维过程来评估其行为或安全性”

   8.2 人机协作的新范式

既然 LLM 无法拥有责任心，那我们就应该重新思考人机协作的方式。核心原则是——把责任心留给人类。这意味着，我们要把和AI的协作当成是团队管理，该深入时就要深入，该放的才放。不能完全放，也不能事事躬亲：

1. AI 负责大部分“脑力和体力劳动”，给出初版产出：需求细化、方案建议、代码生成

2. 人类负责“判断和决策”：评估风险、干预关键决策

责任主体永远是人

前面我们花了大量篇幅剖析 LLM 的本质、局限和问题。现在，是时候回答最关键的问题了：既然 LLM 有这么多问题，我们到底该如何构建可靠的 AI 协同系统？

市面上已经有很多 AI Agent 框架：LangChain、AutoGPT、MetaGPT、CrewAI...它们大多基于一个假设：“只要给 LLM 赋予足够多的感知环境和影响环境的能力，在 Prompt 足够清晰的前提下，LLM 就能够完成各种任务”。但如前所述，我认为这个假设是不成立的，因为 AI 本质上是不可靠的。即使 Prompt 再清晰、工具再多，p^n 的数学定律也会使得 AI Agent 很难成功完成复杂任务。每增加一个环节成功率就会下降，当任务足够复杂时整体成功率会趋近于零。而且，我还见过有人添加了上百个MCP给Agent，他可能还不知道这意味着什么，但是如果你从我们的那条曲线就可以想到，上百个MCP每个MCP一大串描述，会带来非常多“无用的信息”，加速context走向衰退区间。想必我们之中很多人深度使用过AI以后就很能感同身受。

真正的解决方案需要从系统地设计协同流程。基于的所有分析，我总结了构建 人与AI协同系统 的几大原则。

   9.1 第一个原则是确定性优先

能用程序化、工具化解决的，就不要用 LLM。根据p^n问题，每增加一个概率性的环节，整体成功率就会快速下降。那么反过来，减少概率环节，就能提升可靠性。但这不是说“重要的事情人来做，AI 只做简单任务”。而是，人要对不同项目做针对性地设计，在特定场合提供合适的工具，尽最大可能可靠地完成某些工作，从而让AI专注于需要思考和判断的部分。简而言之，就是不要期望找到某种方式，比如提前写好某些强大的system prompt，就能让AI在任何项目中快速发挥作用。这就好比，一个船运公司的管理者，他对团队的管理经验是无法完全照搬到一个数据库公司的。我们要针对性地设计。所谓针对性，就是分析差异分析场景，把尽可能多Unknown变成Known，让程序去确定性地完成工作，而非让人和AI去做这部分工作。比如，我们不应该在prompt里让AI“写完代码后根据需要去构建打包”，因为这涉及到一系列复杂的操作：

# Debug 版本构建RUSTFLAGS="-C debuginfo=2 -C opt-level=0" cargo build --target x86_64-unknown-linux-gnu# Release 版本构建RUSTFLAGS="-C target-cpu=native -C lto=fat -C codegen-units=1" \   cargo build --release --target x86_64-unknown-linux-gnustrip target/x86_64-unknown-linux-gnu/release/myapp# ...

这个事情AI不是不能做，它可以做，但是从提高可靠性的角度来说，不应该让它来做。因为增加每一步，就增加了出错的概率：AI 会不会忘记某个关键的编译参数？Debug 和 Release 的标志会不会搞混？LTO 优化会不会漏掉？sanitizer 该开在哪个版本？而且每次构建 AI 都可能用不同的参数组合。确定性的构建流程被变成了概率性的操作。更好的方式是：用脚本固化构建流程。把构建、测试、部署的完整流程写成脚本，比如 build.sh（你可以让 AI 帮你写和优化这个脚本，但是你需要投入精力去review保证它可靠），然后在prompt里告诉AI执行这个脚本进行构建。这样，整个流程会可靠得多。

代码检查也是一个例子。网上有人YY，每次让AI写完代码，让另一个AI去Review，是不是人就解放了？我只能说，你想太多。github和工蜂上的AI CR多了去了，你真的敢完全信任它？如果你这么信任它，你为啥不信任AI一开始就写对？ 更好更实际地做法是，用工具固化检查规则：让 AI 帮你配置.golangci.yml，在配置文件里声明各种检查点，然后使用golangci-lint这样的扫描工具去静态检查。规则是确定的，结果就是确定的。

这里还有个非常关键的启发：这是一个渐进式协同建设的过程。

每一次“确定性固化”都是一次真正的解放。第一步，识别一个重复性的、可确定的环节（比如构建流程）；第二步，让 AI 帮你实现它（生成构建脚本、配置文件）；第三步，人工验证和完善（这一步很关键，要投入精力确保这个工具/脚本是可靠的）；第四步，固化下来，之后每次都用这个确定性工具。一旦固化成功，这个环节就彻底从“概率性的 AI 任务”变成了“确定性的程序任务”，这时你才真正在这个工作上被解放了。

然后继续这个流程，找下一个可以固化的点：也许是 lint 规则（.golangci.yml、.eslintrc）、也许是测试框架（单元测试模板、集成测试脚本）、也许是部署流程（CI/CD 配置）、也许是文档生成（从代码注释自动生成 API 文档）、也许是代码审查清单（checklist 自动化检查）。

随着这样的确定性组件越来越多，整个系统的可靠性会越来越高。最开始，可能 90% 的工作是“概率性的 AI 执行”，只有 10% 是“确定性的工具执行”。经过几轮迭代，比例可能变成 50% vs 50%。再往后，可能是 20% vs 80%——大部分重复性工作都被确定性工具接管了，AI 只需要处理那些真正需要思考和判断的部分。最终的状态可能就是，你的代码仓库有了非常详尽的文档来描述项目架构、开发流程、使用示例，有各种脚本来执行各种固化操作，AI基于非常精炼却有效的上下文，就可以几乎准确无误地实现新功能。从 p^n 的角度看，n（步骤数）大幅减少了，所以即使 p（单步成功率）不变，整体成功率 p^n' 也会大幅提升。再叠加上模型的进步使得p缓慢上升，最终整个协同效率才能大大提高。

这个原则的关键点是，这个固化过程的复利效应：每固化一个确定性组件，都会让后续的 AI 协同变得更可靠；更可靠的协同又能帮你更快地固化下一个组件。这是一个正向循环。而那些一直让 AI “每次都重新执行构建命令、每次都重新审查代码”的做法，则是在原地踏步——AI 永远在做同样概率的事情，永远不会真正提升可靠性。

记住：与 AI 协同的终极目标，不是让 AI 做所有事情，而是逐步建设一个可靠的系统的协同机制，在这个系统中，确定性的事情由程序保证，不确定的事情由 AI 辅助，关键决策由人来把控。

   9.2 第二个原则是：减少可能性空间

给 AI 的选择越少，它出错的概率越低。LLM 在面对“开放性问题”时表现很差，但在“约束性问题”中表现尚可。

比如你让 AI “帮我优化这个函数的性能”，AI 面临的可能性空间巨大：算法层面优化？改数据结构？用缓存？哪种缓存（Redis？内存缓存？）？缓存策略（LRU？LFU？）？缓存多久（5分钟？1小时？）？可能性太多，你不说清楚，AI就随便选择一个答案。最后给出的东西，很大概率就不是你想要的。

更好的做法是收窄选择空间，比如：

这个函数每秒被调用 1000 次，主要瓶颈是数据库查询。我已经决定使用 Redis 缓存。请帮我：1. 设计缓存的 key 格式2. 实现缓存读取和更新逻辑3. 设置合理的过期时间（考虑到数据更新频率是每 30 分钟）

现在 AI 只需要在一个很小的空间内工作：缓存方案已确定（Redis）、需要做的事情明确（key 格式、读写逻辑、过期时间）、有具体的约束条件（调用频率、数据更新频率）。

关于这部分内容，网上有大量的prompt技巧，核心原则就是：可能性空间越小，AI 犯错的概率越低，本质就是把事情描述清楚。看起来简单，但实际非常抽象。这就跟写作文一样，就算看了《新概念获奖作文大全》，你也不一定写得好。这里就不展开了，因为本质上这里就是个人软素质的体现。如果用一句话来说就是：投入足够的精力，一定要让prompt足够清晰有效（可以自己写，也可以AIGC+人review）

   9.3 第三个原则是：让AI输出可累进的阶段性成果

不要让 AI 一次性完成复杂任务，而是分阶段交付，每个阶段都由人类验收。这个原则直接对抗 p^n 困境。假如一个任务成功率是p^50，我让AI分阶段地完成，当我验收一部分之后，前面就变成了100%，接下来整个任务的成功率就提高到了p^40，这是个简单的数学问题。

比如你要 AI 开发一个完整的用户积分系统，这个系统包含多个模块非常复杂，你几乎可以断定，AI自己搞不定。你不信邪的话，你将收获：

• 300块的claude账单

• 一堆无法运行的代码

• 白白花掉4个小时，且你也没干别的事儿，老是盯着

• 陷入痛苦地纠结：

• 要不要去debug AI的代码？这几千行代码读起来也要花时间啊，万一读不懂或者代码太复杂，最后推倒自己来，不是白白浪费时间吗？

• 直接废弃了，自己动手吧……300块钱白花了，4个小时白花了……

这让我想起了网上vibe coding和老虎机对比的图，你让AI一次搞定一个大任务，几乎就等于是在赌博。

解决方案：分阶段交付

关键认知转变：让 AI 产出可沉淀、有价值的内容，而不是一次性产出所有代码。

什么是“可沉淀、有价值的内容”？

• 需求文档：明确梳理业务逻辑，即使代码失败了，梳理需求文档也能复用

• 方案设计：技术选型、架构设计、数据库表结构设计这些不论人还是AI都需要的，即使AI写代码一团糟，人还可以参考这些设计，或者换个AI来尝试

• 任务拆分：清晰的任务分解，每个任务独立可交付可验收。对于单个任务，即使这个AI搞不定，可以换个AI尝试，最后不行就人来写

• 验收标准：明确的测试用例对整个项目价值很大，有了它我们就可以让AI自行检查代码是否正确（所谓的BDD开发模式）。即使最后人介入开发，这些测试用例也是很有价值的

相比之下，如果一次性生成所有代码：

• 如果有 bug，很难定位是哪个模块的问题

• 如果要修改，牵一发动全身

• 如果要换个 AI 继续，上下文太长无法传递

一个具体的例子

假如你要开发一个用户积分系统的功能

阶段 1：明确需求

请帮我细化用户积分系统的需求，包括：- 积分如何获得（哪些行为可以获得积分，分别多少分）- 积分如何消耗（能兑换什么，需要多少分）- 积分是否过期- 并发场景如何处理（防止超发）
请以需求文档的形式输出

人工验收：检查需求是否符合业务预期，是否有遗漏

这一步产出的需求文档，就是高质量的 Prompt。后续无论换哪个 AI、哪个开发者，都可以基于这份文档继续工作。一个需求，有无数种可行的代码实现，但清晰的需求描述才是真正沉淀下来的资产。

阶段 2：整体方案设计

基于以上需求文档，请设计技术方案：- 数据库表结构（表名、字段、索引、约束）- 核心接口定义（函数签名、参数、返回值）- 并发控制策略（乐观锁 vs 悲观锁，为什么？）- 关键流程图（积分获取流程、积分扣减流程）- ……
不需要实现代码，只要设计方案

人工验收：评估方案是否合理，是否有性能问题，是否符合现有架构

这一步产出的方案设计，是整个系统的蓝图。不论是人和AI都需要，即使AI代码写成一团乱麻，你决定不用AI自己来，但方案设计依然有效。它甚至可以作为团队的技术文档，供其他项目参考。

阶段 3：任务拆分

基于以上技术方案，请拆分成可独立实现的任务：- 每个任务应该是一个完整的、可验收的功能单元- 定义每个任务的验收标准- 说明任务之间的依赖关系
输出格式：Task 1: [任务名]  - 功能描述：xxx  - 依赖项：xxx  - 验收标准：xxx（可执行的测试用例）  - 状态：未开始/待验收/已完成

人工验收：确认拆分合理，验收标准明确

这一步产出的任务列表和验收标准，是后续开发的指挥棒。它的价值在于：

• 明确的较小的任务，可以缩小AI的可能性空间，提高成功率。就是我们常说的，缩小爆炸半径

• 验收标准本身就是测试用例，可以持续使用

• 状态位非常有用，在AI失败时，下一个对话可以快速找到着手点，让它重新接手，或者换其他AI接手继续工作。对人来说也是一样

编码阶段：逐个任务实现

根据需求文档和架构设计，开始代码实现：1. 仔细阅读agents.md中的团队代码规范，严格按照规范编码2. 仔细阅读agents.md中的技术栈要求3. 当使用三方库时，首先要通过`context 7` MCP去了解库的具体用法和约束条件4. ……
当前实现：Task1，并按照验收标准编写测试代码，且保证能够通过所有测试用例

人工验收：

1. 检查测试代码是否符合验收标注

2. 检查代码可读性、核心数据结构设计，确保如果需要你接手，代码不至于是屎山

3. 把发现没说清楚、AI理解偏差的部分，明确补充到对应的agents.md中

这种分阶段模式的优势：

1. AI 每次只需专注一个明确的小目标：减少context，降低目标难度，提高成功率

2. 人的验收成本可控：每次只验收一个小成果，不需要理解整个系统

3. 错误可以早发现早纠正：需求阶段发现问题，修改成本远低于代码实现后

4. AI 可以真正提效：重复性实现工作交给 AI，关键决策点人工把关

5. 产出可沉淀复用：高质量的需求文档和设计文档就是最好的prompt

阶段性成果管理的本质：把一个 p^n成功率的长链路任务，变成 多个独立的成功率更高的子任务，每个任务后都有人工验证和修正机会，这才是AI能够提效的关键：

• 当子任务的成功率足够高，人才有更高的概率完全不用介入——减少100%工作量

• AI生成的有效内容越多，人需要改的就越少——减少90%工作量

人在这里面扮演的角色是非常关键的！一定要有人的参与，且只有你深入参与，你才能提高效率，千万不要寄希望“让AI搞端到端交付”。

写到这里已经很长了，现在让我们把视角拉远，思考一个更宏大的问题：在 AI 时代，工程师的角色会发生什么样的转变？

过去，工程师负责把需求翻译成代码，编译器把代码翻译成机器码，再由计算机执行。未来，工程师把需求翻译成“Prompt”，AI成为一种新的编译器，把“Prompt”编译为代码，再由真的编译器做翻译，最后交由计算机执行。

这种工作模式的转变必然导致能力模型的转变。过去最重要的能力是精通编程语言的语法和特性、熟悉各种框架和工具的 API、数据结构和算法、调试和性能优化技巧。未来最重要的能力是：深度理解需求（不是简单照搬，而是理解业务的本质和边界）、结构化表达（用清晰明确无歧义的文字描述复杂的业务逻辑）、系统设计思维（如何拆解任务、定义接口、设计架构）、验收标准制定（什么叫“做完了”？如何验证正确性？）、Context Engineering（如何在有限的上下文中提供最有效的信息）。注意这些能力的共同点：都需要强大的文字能力、结构化表达能力。这是典型的文科素质。

这听起来可能有些反直觉：理科背景的工程师，未来最需要的竟然是他的文科素质？但仔细想想这是必然的，因为你的主要工作从“写代码”变成了“写文档”。过去我们评价一个工程师的标准是“代码写得好不好”，“代码可维护性高不高”。未来我们评价一个工程师的标准可能是“文档写得清不清楚”、“文档是否好维护”。这是一个巨大的转变。

最后还是回到那个老生常谈的问题：“AI时代，程序员会大量失业吗？” 我的答案是：不会，但会淘汰不适应转变的人。就像马车到汽车的转变：驾驶员职业还在，只是从驾驭马变成了开发，但拒绝学习开车的人被淘汰了，转型成功的马车夫成为了汽车司机。AI 时代也是如此：程序员职业还在在，但是效率低的人会被淘汰。当别人逐步迭代出了非常详尽的项目prompt，开发了众多项目需要的自动化工具，让Vibe Coding几乎进入到“无监督”模式，还在“古法编程”的你就失业了。淘汰你的不是AI，是比你效率高的人。并且，我觉得对工程师的需求还会更大。因为过去受限于人力很多想法无法实现，现在有了AI，我们可以低成本尝试的东西变多了，需求自然也就会涨。就像汽车取代马车后运输能力提升物流需求爆发式增长。所以工程师不会结构性失业，反而会更忙。但“忙”的内容变了：从忙着写代码 变成 忙着设计系统、拆解任务、验收成果、沉淀 Prompt。

最后我想分享一个长期视角。AI 技术在飞速发展：claude-5、GPT-6 会越来越强，Cursor、Copilot 会提供更好的协同体验，新的 Agent 框架会不断涌现。但有些东西不会变：AI 依然是概率模型（这是数学本质）、p^n 困境依然存在（这是数学规律）、人的责任心不可替代（这是人性本质）。这就是我写这篇文章的初衷：不是教你怎么用某个具体的工具，而是帮你建立一套清晰的认知框架，让你能够自己分析、判断、决策。工具会变，框架会变，但原则不变。