# 我让 AI 写了大半个项目，却还是不敢放手 > AI 写了我大半个项目，但核心重构我一直不敢让它自己跑。后来我想通了：卡住我的不是 AI 的能力，是我从没把'什么叫对'做成一个能自动跑的检查。AI 时代真正稀缺的，是把判断编译成可执行代码的能力。 - 原文链接: https://laojin.blog/blog/20260713_compile_your_judgment - 作者: 老金 - 发布日期: 2026-07-13 - 标签: AI 编程, Claude Code, 验收标准, 自动化测试, 判断编译 --- ![我让 AI 写了大半个项目，却还是不敢放手](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260713/00_cover.png) 先接上个月我写过的一句话。 那时我说，AI 让代码变便宜了，真正贵的是判断——决定做什么、确认它真的对了。但那篇留了个尾巴我一直没答好：判断这东西也得我自己一个个去做啊，那不还是被我自己卡住？我造得再快，也快不过我一个人审的速度。 这个问题我一直没答好。直到最近，我盯着自己的仓库，突然想通了。 我在做 AssistantBrain——一个让 AI 帮我写和维护知识库的系统。里面大半内容是 AI 写的，效果不错。但核心的编译和重构，我一直不敢让它自己过，还是要手动盯着。每次 AI 改一片，我心里都犯嘀咕，这个会不会连累到别的地方，然后自己点一遍才敢合。 我一直以为，是因为 AI 还不够聪明，所以我不放心。 后来发现不是。是因为我压根没给它一个东西——一个不靠我盯着、也能自动判断它写对没有的东西。卡住我的不是 AI 的能力，是我自己的懒：我从没把"什么叫对"做成一个能自动跑的检查。 --- ## "能跑"和"敢放手"，中间隔着一样东西 我把这个感觉拆开看，发现所有用 AI 写代码的人其实卡在同一条缝里：让 AI 写出能跑的东西很容易，敢让它在重要的地方自己跑很难。中间隔的那样东西，就是你有没有一个不依赖你本人、能自动判对错的验收标准。 没有它会发生什么？我太熟了。 AI 每次改动单看都合理，合起来系统慢慢变形；你不给它明确的边界，它就拿假设去填空白，猜着猜着代码就漂了。于是你只能亲自当那个验收标准——每一片改动都过你的脑子、你的眼睛、你的时间。你成了整条流水线上唯一的质检员，一个不能复制、不能并行、会累会漏的质检员。 你造得越快，这个瓶颈卡得越死。这就是那个尾巴问题的答案：判断卡住你，不是因为判断难，是因为你的判断还锁在脑子里，没变成机器能执行的东西。 --- ## 一件小事，我盯着自己的仓库看了很久 不用举什么惊天动地的例子，我自己项目里一件小破事，就把这道理照得透透的。 AssistantBrain 有条铁规矩，白纸黑字写在 `CLAUDE.md` 里：新建概念前必须先查有没有相关条目，避免重复。我写得很清楚，AI 每次编译前也确实读了。 然后呢？7 月初，AI 编译一批新素材，还是造了一个跟已有条目重复的概念。我是过了几天翻 changelog 才发现的，手动删掉——变更日志里到现在还留着那行"移除 1 个重复条目"。 我当时的第一反应是"规则写得不够狠"，想回去把 `CLAUDE.md` 那条写得更严厉。写到一半我停住了：问题根本不在措辞。 一条写成文字的规则，对 AI 来说永远只是建议。它每次都得记得去执行、愿意去执行，这是个概率事件。素材一多、上下文一挤，它就漏了。我把"什么叫对"锁在一段散文里，然后指望一个概率系统每次都读懂并照做。这不赖 AI，是我把活儿交错了地方。 正确的做法不是写更狠的规则，是写一个脚本。一个在 AI 落笔新条目前就自动跑的检查：新标题、别名跟现有条目撞不撞？撞了就拦下来。这样"不许重复"就从一句靠人记的话，变成了一道机器每次都会执行、永远不会忘的门。 ![散文规则只是建议，校验脚本才是门](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260713/01_prose_vs_gate.png) 你看，同一条判断，写在 `CLAUDE.md` 里是散文，写进校验脚本里就是验收机。前者替我扛不住信任，后者能。差别不在 AI 聪不聪明，全在我有没有把判断做成可执行的。 --- ## 所以，该练的是"把判断编译出来" 想到这我有点激动，因为它正好补上了我这套"编译器"世界观缺的一块。 我一直把仓库当编译器用：原始素材是源码，AI 把它编译成知识。但我漏了最关键的一环——编译器是要有测试的。没有测试的编译器，你敢让它自动跑吗？不敢，你得盯着每一次输出。这不就是我一直在干的蠢事。 ![没有测试的编译器，你不敢让它自动跑](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260713/02_compiler_with_tests.png) 所以 AI 时代真正稀缺的能力，我现在会这么说：不是把判断留在脑子里，是把判断编译成一个能自动执行的东西。 - 你觉得"这次重构不能破坏 A 功能"——别记在脑子里，写成一条测试。 - 你觉得"生成的 wiki 条目必须有这几个字段、链接不能断"——别每次人肉检查，写成一个校验脚本。 - 你觉得"这个 API 的输出格式必须长这样"——别靠肉眼比对，写成一个契约测试。 每这么做一次，你就把一份原本锁在脑子里、只能你本人执行一次的判断，变成了机器能执行无数次、还能并行执行的判断。你从唯一质检员，变成了定标准的人。这是判断能规模化的唯一路径。 ![从唯一质检员，到定标准的人](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260713/03_bottleneck_to_scale.png) 有意思的是，这跟我之前写 Loop 系列讲的"修流程，不修代码"是同一件事的两面：验收标准，就是那个能自我纠错的循环里判断对不对的那个环。你把标准做厚，循环才转得起来。 --- ## 我打算怎么改 说点具体的，不然又成了空谈。 我回去翻了自己的 `tools/`，那个叫 `validate.py` 的校验脚本一直很薄，就查查链接断没断。我以前总想着"能跑就行，回头再补"。现在改主意了，就三件事，也送给同样卡在这儿的你。 动大手术前，先补验收层，别先动代码。准备让 AI 做大重构、换框架、大迁移？先停一下问自己：改完之后我靠什么自动判断它对不对？如果答案是"我人肉点一遍"，那就先别动，先把那个自动判对错的东西做出来。这不是拖延，这是能不能放手的前提。 验收要测结果，别测过程。你要校验的是 AI 产出的条目对不对——字段全不全、链接断没断、有没有撞车，而不是它内部怎么一步步生成的。盯住最终产出和契约，这样哪怕 AI 换了套写法、底层被改得面目全非，你的标准照样成立。 出问题先改标准和流程，别急着手改产物。AI 写错了，第一反应别是自己上去补那一处。先想是什么让它这么写的，改那个；顺手把新学到的约束补进校验脚本和 `CLAUDE.md`。修一次流程，挡掉一整类问题。 我这周的头号任务，就是把 `validate.py` 从"查链接"做成一套"行为校验"——把我脑子里那些"一个好 wiki 条目该长什么样"的隐性标准，一条条榨出来变成代码。做完这件事，我才敢真正对 AssistantBrain 放手。 --- 回到开头那个没答完的问题：判断会不会永远把你自己卡死？ 会，只要你的判断还只活在你脑子里。 所以这周我不打算再往 `CLAUDE.md` 里加一条更严厉的规矩了。我去改 `validate.py`。把"一个好条目该长什么样"一条条榨出来变成代码——能榨出来多少，我就敢放手多少。