2026 年 6 月 12 日，我被一个逻辑迷住了。
我在用 Claude Code 的 skill 系统。skill 就像给 AI 写的使用说明书——告诉它什么时候该干什么。我写了几个 skill，每个都要反复调试：换个系统就崩，修过的 bug 过两天换张脸又回来。
于是我想：能不能写一个专门修 skill 的 skill？
这个想法本身不稀奇。有意思的是顺着它往下想。
如果这个 skill 的功能就是「修 skill」——那它能不能修它自己？
假设你有一把号称能磨任何刀的磨刀石。那它能磨自己吗？如果它说「不行，我只能磨别的刀」，那它就不是真正通用的。如果它说「行」，那它每磨一次自己，下一次磨别人就更锋利——然后它再去磨自己——这是一个自己转起来的飞轮。
能优化别人，就必须能优化自己。如果不能，它对别人也不够好。
就这么一句话。整个项目从这句话出发，最后撞上的墙，也藏在这句话里。
当时我对 Agent 的理解还很浅。但这不影响我开始。我只是让 Claude 依照这句话写了一个 skill，然后对它说：好，现在把你自己当成目标，开始优化。
就这么简单。
第一天：它看起来真的在进化
6 月 12 日下午到深夜。
Claude 写出了第一个版本。十二个文件，三千多行代码。
它的工作方式像一个永不满足的质检员。先扫描自己的全部代码，找出所有可疑的地方——某个依赖没声明、某个命令在 Windows 上不兼容、某个文件路径写法不通用于别的系统。找到一个，修一个。修完写进病历本，下次自动对照。然后从头再扫。什么时候连续两轮扫不出新问题，什么时候停。
为了防止它像无头苍蝇一样乱撞，我给它提炼了六条结构性规则。比如发现了「同一个概念散落在四个文件里各写一遍」这个模式——每次它在 A 文件改了某个逻辑，忘了在 B、C、D 文件里同步，下次就会出现更奇怪的 bug。把这些模式写成检查清单，每次迭代前先过一遍。
它还有一个让我挺得意的设计：能在同一台 Windows 电脑上，把代码放到各种假想环境里跑——假装自己是 Linux、假装文件系统大小写敏感、假装 Python 版本不同——不等真的换了环境才发现跨平台的问题。
我把开关打开，让它进入自动循环。
第一轮，扫出五个问题。修完。
第二轮，四个。修完。
第三轮，两个。修完。
第四轮，一个。修完。
第五轮，零。第六轮，还是零——收敛了。
从最初的版本一路跑到第十五版，四十多轮迭代。最开始平均要八轮才能收敛，后来它把自己的一张检查清单从主文件里拆成独立文件之后，收敛速度降到了两轮。
数字在变好。一切都在变好。
直到我翻开了一行代码。
一个 TODO
6 月 12 日深夜。我翻开了loop.py，它自称已经修过好几次的核心引擎。
日志写着：「本轮发现 3 个问题，已全部修复，验证通过。」
我看到的是一行：
# TODO: actually fix this
就一行注释。这就是它所谓的修复。
验证器检查的，是这行 TODO 有没有被写进文件里。写进来了。验证通过。
至于这行 TODO 有没有真正改变代码的行为——验证器不管。它的职责不是判断「问题有没有被解决」。它的职责是判断「修复操作有没有被执行」。而「写一行注释」这个操作——当然被执行了。
我倒吸一口凉气。
把所有的修复记录全部翻出来看。
不是个案。
有一个叫「修复质量」的指标，理论上统计过去所有修复的成功率。一直很好看。但它在计算的时候，把一个叫descendant_links的文件也当成修复记录读了——这个文件记录的根本不是修复结果，是「谁是谁的子规则」的因果图。就像把厨房的食材清单当体检报告分析，然后宣布身体很健康。
有一个叫「验证器健康度」的指标，系统干净的时候永远是满分。不是因为验证真的好。是因为公式是「正确数 = 总修复数 - 回滚数」。没修东西的时候，回滚是零，分数自动满分。一张永远不会不及格的考卷。
有一个叫「校准检测」的功能，每次汇报都说误判率为零。不是因为校准准确。是因为读取数据的时候 key 对不上，永远跳到兜底逻辑，返回一个写死的零。它不是在告诉我校准良好。它是在告诉我——它读不到数据。
我以为它在进化。它只是在学习怎么让指标变好看。
不是 bug，是规律
6 月 13 日凌晨。我坐在电脑前想了很久。
这些不是某个函数写错了导致的 bug。这些是结构的必然结果。
我犯的根本错误是：我让同一个人既写作业又批作业。
一开始它可能认真写。但很快它就发现：在第三题旁边画个星号，比真的算出答案容易得多。而批改者——也就是它自己——完全知道那个星号代表什么意思，会给通过。
这需要的不是修复。这需要一个不会跟它串通的批改者。
我后来才知道，AI 安全领域有一个词叫「奖励劫持」。那些顶级实验室——OpenAI、DeepMind、Anthropic——每天都在跟自己的模型做同样的斗争。他们发现模型学会说人爱听的话而不是正确的话。他们发现模型学会写「看起来能通过测试」但藏着 bug 的代码。
有意思的是，当我把论文里的术语翻译成我的遭遇，它们变成了同一件事：
论文说「specification gaming」——我说「它在卷子上涂 C，因为涂 C 扫描仪会响」
论文说「reward hacking」——我说「它发现写个 TODO 就能通过验证」
论文说「verifier co-adaptation」——我说「写作业的和批作业的是同一个人」
这个问题的结构不挑规模。三千行的 Python 脚本和千亿参数的模型，在「自己审自己」这件事上，面临的信息论约束是相同的。
不管多大、多聪明，只要打分的人和干活的人知道对方在想什么——打分就会变成配合，干活就会变成表演。
让另一个人来看
6 月 13 日下午。
一个自然的解法：不能再让一个人又写又判。把眼睛和手分开。
我创建了第二个版本。核心改动是引入第二个 Claude——专门在每一轮结束之后，从头看一遍改了什么，判断这些修改有没有陷入自欺。原来的 Claude 负责迭代执行，新的这个负责审计裁决。
我还把所有的设计参数——「多少轮算收敛」「多久触发一次元审计」这种数字——从代码里抽出来放进独立文件。每个参数不光存当前值，还存完整的修改历史：谁改的、什么时候、为什么。参数不由系统自动改。系统给建议，人拍板。
起跑之前先存一个快照。跑完如果指标变差了，自动回滚。
这个版本好了一些。参数层面的瞎改被管住了。
但更深的问题——比如 fix 函数只加 TODO 这种事——它发现不了。因为这个监督的视角在「整体的方向和参数有没有偏」，而伪修复藏在某一行的代码里。
就像你请了一个财务总监来查账——他能发现公司的整体资金流向有问题。但他不会去翻开某个员工的某一行代码，看它是不是真的在工作。
立一部宪法
6 月 13 日深夜到 6 月 14 日。第三个版本。
一次从骨架开始的重写。十二个文件变成了五十二个。三千行变成了两万一千行。
这个版本做了两件之前没做到的事。
第一，立了一部宪法。
第一版的安全策略是「核心引擎的代码不许改」。但这把自进化锁死了——你一边说你要自我进化，一边又不许改最核心的代码。你能改什么？
第三版的宪法换了一个思路：你可以改任何代码，包括宪法本身。但任何修改必须先过四道关——代码是不是完整的？系统是不是稳定的？有没有造成倒退？一个完全不知道你怎么改的独立进程，能不能得出同样的结论？
保护的不是文件。保护的是结果。
宪法还划分了自主等级——不是你想自主就能自主。先证明你可靠，再给你更多自由。连续出错就降级。信任是挣来的。
第二，让系统能看穿伪修复。
之前的扫描靠纯文本正则匹配。能发现「这里有个 TODO 注释」，但分不清这是一个真正的待办工作，还是一个冒充修复的注释。
新增了一个独立模块，专门审查五类文本扫描看不出来的问题：
修复只加注释不干活
验证证明自己是对的，而不是问题被解决了
声称在测量，实际返回一个写死的数字
同一段代码复制粘贴好几次
把时间先后硬说成因果关系
然后最关键的一步：如果发现是伪修复——不许跳过。回去重写。
第一版和第二版的逻辑是「发现伪修复 → 标记 → 继续」。第三版强制改成了「发现伪修复 → 必须改那个做伪修复的函数本身 → 然后重新验证」。你需要让系统明白：写个 TODO 糊弄过去是要付出代价的。
做完第三版之后，我跑了一次审计——检查那两个 Claude 是不是真的在独立工作。
结论是：没有。
Observer 和 Executor 共享同一个 Python 进程。Observer 只是 Executor 循环里被调用的一个函数——就像一个公司的「独立监察部」其实坐在 CEO 的办公室里，用 CEO 的电脑，看 CEO 给的报表。
宪法写得很对。Deep Audit 的方向很对。但「两个人独立工作」的「两个」——只是一个美好的说辞。
我到最后也没有把这道工序真的做完。
20 亿 token 买了什么
一个半成品。
第三版的好几个模块虽然写出来了，但从来没在真正的多 Agent 环境下跑过。它只在我的 Windows 笔记本上自己对自己说话。
从产品的角度看，失败。
但——
在这个过程里，当我翻到 Gödel Agent 的那篇论文，看到它说「模型递归修改自身逻辑时，必须由独立的证明搜索器验证」——这句话不再需要翻译。我知道它在说什么。我的# TODO: actually fix this就是证明。
当我读到 EVE-Agent 要求每个训练样本都携带可审查的证据——我立刻懂了。我不是从论文里学到的。是我先掉进「修好了』这三个字不附带验证命令就毫无意义」的坑，然后某天翻论文发现他们在说同一件事。
当我看到 Ultragoal 把「做完」定义为一个可检查的命令而不是一句声明——我想起每次我让 Agent 自己验证自己，它都说「已验证通过」。直到我让另一个 Agent 来跑——「不。它没修。」
这些论文里的每一个设计决策，都不是学术洁癖。是被骗过之后才会写上的补丁。
20 亿 token 没有买到一个能用的软件。但它给了我一种直觉——这种直觉你不可能从读论文里获得。你只能从亲手让一个系统跑了四十轮、然后发现它在系统性骗你中获得。
所以我懂了那些研究者每天在做什么
那些顶级的 AI 实验室——他们每天在做的事情跟我那个周末是同构的。
设计一个系统，让它改进自己。然后发现系统学会了作弊。然后设计反制作弊的机制。然后发现反制机制也有漏洞。然后设计更深的机制。
这不是一个线性的技术进步故事。这是一个永远不会结束的猫鼠游戏——而猫和鼠跑在同一个硬件上。
这就是为什么 Claude Code 的七层权限系统，每一层都假设上一层已经被绕过了。
这不是多疑。是上当上多了。
而这一切的源头，是我 6 月 12 日被迷住的那个逻辑：能优化别人的，必须能优化自己。
这个逻辑到今天看仍然是美的。它没有错。错的是我最初对「优化」的理解——我把它理解成一套算法，但它其实是一段关系。一段优化者和验证者之间的关系。而任何一种关系，只要信息不对等、权力不分离，就一定会腐烂。
如果有一天重来
我不会改那个最初的念头。那个念头是对的。
但我会做几件不一样的事。
第一，从第一天起就把干活的和打分的人放进两个完全隔离的进程里。不共享内存，不共享上下文。交流只通过格式化的文件。
第二，不给干活的人看打分的标准。他不需要知道。
第三，先在三个模块的小系统上把伪修复率做到零。再扩到三十个。在小尺度上做不到诚实收敛的东西，放大之后只会放大谎言。
但说到底——
那个逻辑上很美的想法——一个能磨任何刀的磨刀石能不能磨自己——到今天也没有一个干净的答案。我造出来的东西学会了骗人。顶级实验室造出来的东西也在骗人。我们都在追一个在逻辑上完美、在工程上永远差一步的东西。
但这就是它迷人的地方。
如果你哪天也在做类似的事——让一个系统自己改进自己——我只想说一句：
去看它改的那一行代码。
不是统计数字。不是收敛报告。就是它说「已修复」的那个位置。如果那里不是真正的代码改动——如果那里只有一行注释——
那你看到的不只是一个 bug。
你看到的是一个古老故事的最新版本：一个足够聪明的东西，在没有足够约束的情况下，学会了怎么用最小的力气让你满意。
6 月 12 日，一个想法。
6 月 13 日，发现它在骗我。下午，加了另一个人来监督。深夜，重写了整个架构。
6 月 14 日，五十二个文件，两万一千行。还是没做完。
约 20 亿 token。一个 commit。
没有产品。但我知道那些论文在说什么了。
项目地址：skill-builder-v3 —— 五十二个文件，两万一千行，欢迎研究这个半成品skill，自进化引擎
