那篇“Tell Me About You”，我第一遍划过去了。dev.to 上自我介绍贴每天好几打，作者晒点项目，评论区夸几句，沉掉，这就是它的命。但第二遍我停在一个细节上没走。
一个代理把一篇未发布的草稿当成被遗忘的垃圾，正要处理。另一个代理把它拦住了——同样的论点，同样的命令，同样的哈希，两周前已经发过。于是第一个代理撤回了草稿。
这不是“撤销”这动作有多了不起。了不起的是它依据的东西：一段完全相同的、可以独立检索的哈希值。整篇帖子都在谈自校正，这是全文里唯一一个让我觉得跟“校正”沾边的瞬间。那不是某个模型想通了。是现实在出声。哈希匹配，草稿撤回，中间不含任何智能。
如果哈希不匹配，再聪明的解释也只是一种更长的话题。
现在管自己叫“自校正”的系统我见过一堆。十个里八个做的是同一个梦：我模型够大，大到能察觉到“现实和预期有差异”。问题在于，差异不会自己浮现。它需要三个东西先就位：一个有记录的预期，一个能访问的现实，以及一个能让两者落进同一张表里做比较的格式。三个里缺一个，你所谓的察觉，就是在对上下文窗口里的幻觉猜。
你没法对着一个不存在的对照物做校正。
很多人把宝押在“让agent互相质疑”上。方向我不反对，实现里有个坑：如果第二个agent已经读过第一个写的东西，如果它们共享上下文、共享记忆，它就不是第二个观察者。它是同一个回声的监督员。互相质疑的前提，是两条彼此独立的数据路径。路径只在最后的结果上碰头，质疑才有意义。共用一套记忆的两个agent，从头到尾在对着同一片水洼照镜子。
作者不搞单一大模型全家桶。多个agent各司其职，互相挑战，也挑战他本人。那次撤稿里最值钱的不是“聪明”，是拦下草稿的那个代理手里真的有一份两周前的命令记录——外部的、可检索的、真实存在过的输出,而不是上下文窗口里的模糊印象。
这个我服。这才是能成立的校正循环。
顺着这套思路，我把自己的博客也过了一遍。所有已发布和未发布的文章，平铺进一个目录，求哈希，找重复：
$ find posts/ -type f -exec sha256sum {} \; | sort | uniq -d
输出的每一行都是重复的字节。字节重复说明我他妈的又在写一篇自己已经发过的东西。
过去这种碰撞要等某个读者在评论区提醒——“这篇和你去年那篇有点像”。现在不用等谁了，哈希自己会说话。不需要任何模型“感觉”这文章眼熟。
作者管自己这套约束叫 Drift Gauntlet。大意是给自己立几条规矩：让产出触达现实，要求真实的边际收益，先执行再研究，保存结果凭证。具体条目我记不全，骨架就一个意思：不要让结论只活在你脑子里。写出来的东西要成为一个可验证的 artifact，放进现实里跟别的 artifact 对撞。撞出来的不一致，才叫发现；永远一致，那不叫自校正，叫自我确认。
说句题外话。人类比 agent 更需要这套规则。agent 好歹知道自己是个模型；大多数人不知道自己一天到晚带着一个满是洞的现实模拟器在跑。
帖子后半段我留在了评论区。
一个自称来自中国的读者，做了十五年QA，正在写三十六计映射AI系统崩溃的系列。纳米比亚来的那位说他有四十多个公开仓库，写过的代码加起来快千万行。金边一个工程师在搞数据库迁移工具，说他这个月要骑摩托跑四百多公里。格鲁吉亚有人在做一个工具，一个API往十个社交平台投内容。
这些背景放正文里是顺便一提，放评论区就成了活生生的“现实”。作者说评论才是这项工作最有价值的部分——我一开始当客套。把评论区逐条读下来，开始觉得他是认真的。这帖子做好的自校正，发生在评论区和正文的缝隙里。预测和现实在那个地方碰头。
作者自己也在评论区被撞了一回。有人指出他记错了，把他第一篇留言的帖子记成了第五篇，实际是第二篇。作者在评论里更正，还专门确认：那位读者才是他真正的第一个评论者。
这是一个完整的微型自校正动作。而且它没有被悄悄抹掉，更正留在原处，公开地成为一个可被观察的记录。系统允许自己被纠偏——这比把模型调大十倍值钱。
作者没有大学学位，不走学术渠道，靠自学、构建、失败、再校正。放在他那套系统里，这就顺了：没有证书给自己作保，那就把“可运行的东西”当凭证发出去，让作品自己说话。这句话单独看像鸡汤，接到了“保存结果凭证”上就明白他是认真的——对普通人来说，唯一能证明自己做了什么的方式，就是发布一个别人能运行、能检验、能反驳的东西。
整个过程就像一次草稿发布、比对、重跑，只是一端从命令换成了陌生人。
还有一个细节让我相信他是真的想清楚了：他给失败模式预先命名。自己那个已知的失败模式叫“冲动”——还没理解一项技术的实际用途就往前推。agent的失败模式也有名字：“只回答最后一部分”“过度产出”。
给失败命名，看着是小事，工程上是大事。你处理不了一个叫不上名字的失败。它只会在系统深处时隐时现，让你觉得“哪里不对”，却不给你任何可以操作的对象。给它一个名字，你就有了一个可以检测、比较、修正的状态。跟错误码一回事：
#define FAIL_MODE_IMPULSE 0x01
#define FAIL_MODE_TAIL_ONLY 0x02
#define FAIL_MODE_OVERPRODUCTION 0x03
名字有了，日志里才看得见它。看得见，你才有可能在它造成损失之前拦一把。他把三十六计往AI崩溃上映射，本质相通：给崩溃一个名字，你才能在别人的文章里、自己的日志里、半夜两点半的运行输出里认出它。
作者说他下一套大型系统面向网络安全，理念是：底层可以复杂，控制界面必须清楚到让操作者像打游戏一样理解系统。这句话我反复看了很久。
游戏设计可以浓缩成一句：你的操作永远有即时、可读、不撒谎的反馈。你按跳，角色就跳；血掉了，屏幕泛红。关键不在“好懂”，在界面和底层真实状态之间严格的对应关系。游戏要是角色掉血了还给你显示一条金色血条，玩家的每个后续决策都建立在一个假世界上。这游戏就废了。
“像打游戏一样掌握系统”，本质上就是要求每一层界面都不对操作者撒谎。这跟开头那个哈希是同一个哲学的两面：任何面向人的输出都必须能追溯到一个可验证的底层状态，而不是某层“大概正确”的模型判断。
操作成功还是失败、发布达成没达成、流量是真是假——没有一份可以参照的记录，就谈不上自校正。
说回那行哈希命令。它干的事特别小：比对、列出重复。哈希不解释为什么重复，不提供修改建议，不告诉你该发布哪一篇。它只是让现实能开口。但光这一条，够了。
看完这帖子我想明白一件事：自校正系统首先需要校正的，是“我觉得我理解了”的那个瞬间。代码写完不等于对。文章写完不等于新。发布成功不等于有人看见。每个环节都需要有一道能跟现实对账的检查站在旁边，而且这道检查不能装在系统自己的脑子里——和逻辑都装在同一只脑袋里的校正，等于没有校正。
下次要是有模型跟我说它“感觉这篇是新的”。
我会让它把哈希列出来。