上篇结尾留了个钩子：犯错的 AI 才是好 AI。这篇展开讲。
人学骑车，没人第一遍就会。摔两次，才知道怎么对。学做菜，第一次多半糊锅。学游泳，先呛两口水。
错误是学习的信号。这件事，谁都知道。
但是一到 AI 这儿，我们对错误的态度变了：零容忍。护栏、规则、越来越精确的提示词、防错协议——整个行业在跟 AI 的错误打一场全面战争。视频号上每天都有新的 AI 翻车集锦，评论区一片「就这？」
这场战争，打错目标了。
今天把乓定律第二条摆出来：
事实①：AI 的价值来自「智能」。尝试让它如机械一般可靠，就是在消除它的价值。
听着像替 AI 开脱？拆开看。
「智能」是什么？ 会理解、会判断、会应付没见过的情况。
注意「会应付没见过的情况」这半句——他每次回答，都是现编的。不是查表查出来的。现编，就可能有错。
你雇他，雇的就是这个「现编」的本事。现编和出错，是同一枚硬币的两面。你想只要正面不要反面，做不到。就像把水冻成冰：你得到了确定性，失去了活性。
反过来，不犯错的东西存在吗？ 存在。数据库。每条数据都精确，因为它不理解你，它只做查表。一个永远不会犯错的系统，不是更好的智能——是没有智能。
也不能全怪行业。人自己就怕犯错。老板怕，客户怕，QA 怕。所以产品经理写需求，第一条就是「AI 不准犯错」——像不像当年带实习生：宁可你什么都别干，也别给我惹事。
你是个英明的老板，你希望AI能理解你，还不犯错。但你自己就不犯错么？你自己就真的预先知道一切的答案么？有没有想过，很多时候，他也只是在犯你的错。
我看到的很多新闻里的「进步」，其实都是在把这个智能体往机器的方向推。
想都不用想，当然不好用。这些「进步」干的事情，其实是在消灭AI有用的原因。
PPM Desk 开发到第一个版本快完成的时候：7 个开发任务全部做完，开发者全部交付，就差验收。按说该皆大欢喜——我点个通过，上架。
我叫停了。
原话是：「我认为我们需要放弃这种测试和验收方式。」「所有这些，缺的是设计，而非细节修改。」「要不要考虑像 vscode 这样，搞一个工作区文件。」
这不是修一个 bug，不是改一个界面。是整个设计地基缺了东西。推倒重来，7 个任务的成果废掉一部分。
后来回头看，这次「错误」是整个项目最值钱的一次产出：重建的架构，成了之后所有迭代的稳定基础。那次叫停如果图省事点了「通过」，后面所有版本都会长在错的地基上。
注意这个错误是怎么被抓出来的：系统留了「验收」这个口子。我说「不对」，他就停。错误没有被消灭——它被抓住了。抓到的错误，变成了升级的燃料。
反过来的故事也有。回头看 500 个会话里，大部分的严重事故都是我自己偷懒造成的——被他和流程抓了出来，修掉，记下来。他抓我的错，下手也从不留情。
错误在CSF这个系统里双向流动，每一笔都变成了改进。
纠错是系统的功能，不是故障。人和AI都会犯错，是CSF默认接受的事实。
现在回头看上一篇的「索引病」，根子就在这儿。
符号系统堆墙，深层动机就是「不许他犯错」。填表、打标、查号，全是防错工程。防到最后，他是不犯错了——他什么都不干了，就在墙里自己玩。
索引病之后，CSF规范里增加了两条：
- 不用负面清单来保证质量，要正面引导。就是在规范里写"不要……"，"不允许……"，而是要写"要……"，"目的是……"。
- 容错诚实。就是错了就说出来，可能错提前说，事后检查发现错当时说。说出来，去改，记一笔经验。多像一个好学生。
正确的问题从来不是「怎么让 AI 不犯错」，而是「怎么和一个会犯错的智能体有效协作」。这两个问题，通向两个完全不同的方向。
两个较真的人会问的问题。
这不就是 Popper 的老话吗？ 科学就是靠错误进步的——对，思想不新。新的是把它用到工程上。工程界的主流到今天还是「错误 = 待消除的缺陷」：防错设计、零缺陷文化、护栏越建越高。把「消除错误 = 消除智能」当成主张提出来，再推导出一整套容错机制的，我们没找到先例。
照你这么说，AI 犯错就不用管了？ 不是。造桥、开飞机、写手术方案——该上护栏上护栏，一道都不能少，但你不能光靠护栏。尤其是创造性工作：写代码、做设计、搞研究、写方案。在这些场景里，你要是要求 AI 一个错都不能犯，那你不如买台打印机。
下一篇讲第三条：语义稀释律——信息每过一手就损耗一点，税可以少交，不能免交。
这篇带走一句话：
下次有人吹「我们的 AI 零失误」，你知道他在卖数据库。
下次有人抱怨 AI 犯错，你知道——那正是它值钱的地方。
如果你带过新人，这一条你其实早就懂了：什么都不做的员工不犯错，但你要他干嘛？
本系列文章背后的工作流，来自开源协作框架 CSF：github.com/huidev2025/CSF
