我让 AI 写了大半个项目,却还是不敢放手
AI 写了我大半个项目,但核心重构我一直不敢让它自己跑。后来我想通了:卡住我的不是 AI 的能力,是我从没把'什么叫对'做成一个能自动跑的检查。AI 时代真正稀缺的,是把判断编译成可执行代码的能力。

先接上个月我写过的一句话。
那时我说,AI 让代码变便宜了,真正贵的是判断——决定做什么、确认它真的对了。但那篇留了个尾巴我一直没答好:判断这东西也得我自己一个个去做啊,那不还是被我自己卡住?我造得再快,也快不过我一个人审的速度。
这个问题我一直没答好。直到最近,我盯着自己的仓库,突然想通了。
我在做 AssistantBrain——一个让 AI 帮我写和维护知识库的系统。里面大半内容是 AI 写的,效果不错。但核心的编译和重构,我一直不敢让它自己过,还是要手动盯着。每次 AI 改一片,我心里都犯嘀咕,这个会不会连累到别的地方,然后自己点一遍才敢合。
我一直以为,是因为 AI 还不够聪明,所以我不放心。
后来发现不是。是因为我压根没给它一个东西——一个不靠我盯着、也能自动判断它写对没有的东西。卡住我的不是 AI 的能力,是我自己的懒:我从没把"什么叫对"做成一个能自动跑的检查。
"能跑"和"敢放手",中间隔着一样东西
我把这个感觉拆开看,发现所有用 AI 写代码的人其实卡在同一条缝里:让 AI 写出能跑的东西很容易,敢让它在重要的地方自己跑很难。中间隔的那样东西,就是你有没有一个不依赖你本人、能自动判对错的验收标准。
没有它会发生什么?我太熟了。
AI 每次改动单看都合理,合起来系统慢慢变形;你不给它明确的边界,它就拿假设去填空白,猜着猜着代码就漂了。于是你只能亲自当那个验收标准——每一片改动都过你的脑子、你的眼睛、你的时间。你成了整条流水线上唯一的质检员,一个不能复制、不能并行、会累会漏的质检员。
你造得越快,这个瓶颈卡得越死。这就是那个尾巴问题的答案:判断卡住你,不是因为判断难,是因为你的判断还锁在脑子里,没变成机器能执行的东西。
一件小事,我盯着自己的仓库看了很久
不用举什么惊天动地的例子,我自己项目里一件小破事,就把这道理照得透透的。
AssistantBrain 有条铁规矩,白纸黑字写在 CLAUDE.md 里:新建概念前必须先查有没有相关条目,避免重复。我写得很清楚,AI 每次编译前也确实读了。
然后呢?7 月初,AI 编译一批新素材,还是造了一个跟已有条目重复的概念。我是过了几天翻 changelog 才发现的,手动删掉——变更日志里到现在还留着那行"移除 1 个重复条目"。
我当时的第一反应是"规则写得不够狠",想回去把 CLAUDE.md 那条写得更严厉。写到一半我停住了:问题根本不在措辞。
一条写成文字的规则,对 AI 来说永远只是建议。它每次都得记得去执行、愿意去执行,这是个概率事件。素材一多、上下文一挤,它就漏了。我把"什么叫对"锁在一段散文里,然后指望一个概率系统每次都读懂并照做。这不赖 AI,是我把活儿交错了地方。
正确的做法不是写更狠的规则,是写一个脚本。一个在 AI 落笔新条目前就自动跑的检查:新标题、别名跟现有条目撞不撞?撞了就拦下来。这样"不许重复"就从一句靠人记的话,变成了一道机器每次都会执行、永远不会忘的门。

你看,同一条判断,写在 CLAUDE.md 里是散文,写进校验脚本里就是验收机。前者替我扛不住信任,后者能。差别不在 AI 聪不聪明,全在我有没有把判断做成可执行的。
所以,该练的是"把判断编译出来"
想到这我有点激动,因为它正好补上了我这套"编译器"世界观缺的一块。
我一直把仓库当编译器用:原始素材是源码,AI 把它编译成知识。但我漏了最关键的一环——编译器是要有测试的。没有测试的编译器,你敢让它自动跑吗?不敢,你得盯着每一次输出。这不就是我一直在干的蠢事。

所以 AI 时代真正稀缺的能力,我现在会这么说:不是把判断留在脑子里,是把判断编译成一个能自动执行的东西。
- 你觉得"这次重构不能破坏 A 功能"——别记在脑子里,写成一条测试。
- 你觉得"生成的 wiki 条目必须有这几个字段、链接不能断"——别每次人肉检查,写成一个校验脚本。
- 你觉得"这个 API 的输出格式必须长这样"——别靠肉眼比对,写成一个契约测试。
每这么做一次,你就把一份原本锁在脑子里、只能你本人执行一次的判断,变成了机器能执行无数次、还能并行执行的判断。你从唯一质检员,变成了定标准的人。这是判断能规模化的唯一路径。

有意思的是,这跟我之前写 Loop 系列讲的"修流程,不修代码"是同一件事的两面:验收标准,就是那个能自我纠错的循环里判断对不对的那个环。你把标准做厚,循环才转得起来。
我打算怎么改
说点具体的,不然又成了空谈。
我回去翻了自己的 tools/,那个叫 validate.py 的校验脚本一直很薄,就查查链接断没断。我以前总想着"能跑就行,回头再补"。现在改主意了,就三件事,也送给同样卡在这儿的你。
动大手术前,先补验收层,别先动代码。准备让 AI 做大重构、换框架、大迁移?先停一下问自己:改完之后我靠什么自动判断它对不对?如果答案是"我人肉点一遍",那就先别动,先把那个自动判对错的东西做出来。这不是拖延,这是能不能放手的前提。
验收要测结果,别测过程。你要校验的是 AI 产出的条目对不对——字段全不全、链接断没断、有没有撞车,而不是它内部怎么一步步生成的。盯住最终产出和契约,这样哪怕 AI 换了套写法、底层被改得面目全非,你的标准照样成立。
出问题先改标准和流程,别急着手改产物。AI 写错了,第一反应别是自己上去补那一处。先想是什么让它这么写的,改那个;顺手把新学到的约束补进校验脚本和 CLAUDE.md。修一次流程,挡掉一整类问题。
我这周的头号任务,就是把 validate.py 从"查链接"做成一套"行为校验"——把我脑子里那些"一个好 wiki 条目该长什么样"的隐性标准,一条条榨出来变成代码。做完这件事,我才敢真正对 AssistantBrain 放手。
回到开头那个没答完的问题:判断会不会永远把你自己卡死?
会,只要你的判断还只活在你脑子里。
所以这周我不打算再往 CLAUDE.md 里加一条更严厉的规矩了。我去改 validate.py。把"一个好条目该长什么样"一条条榨出来变成代码——能榨出来多少,我就敢放手多少。