有人 review 别人的 Go 代码，挑错、谈设计都能说出门道，真给他一个空白文件，要他从零写个 HTTP handler，他连怎么把服务器起起来都想不起来。另一个人在拿 Rust 让 AI 代理重写 PostgreSQL，性能也许有得谈，但那个项目这么多年修 bug 攒下的深层理解搬不过来。再往前翻，Stack Overflow 时代抄代码、贴教程，早就能把人搞成这种状态——看得懂，构造不了。
三件事散在不同时间、不同工具里，单看都像个人状态问题。摆到一起就不是了。所有人撞的是同一堵墙：审查能力和生产能力分叉了。它到现在有个准确叫法吗？没有。大家说“手生”“退化”“AI 依赖”，说法不少，没有哪个能指到那条确切的裂缝上。
我把它叫做：审写脱钩。
review 和 write，本来是同一块肌肉的两端，现在中间被 AI 代理截断了。这个叫法，总算把“啥都看得懂、写起来就露馅”那种比划不清给钉住了。
等等，我差点把它叫成“能力断层”。收住了。那个词起宽了。“能力”这俩字什么都能往里装，沟通、架构、调试全能装，反而把水搅浑。审写脱钩只指一个特定的、可检验的症状：对着 diff 能说出门道，对着空白文件迈不动。要窄，窄才抓得住。
Adam 说得更狠一点：识别和生产是两种能力，能看懂解决方案不等于能独立构造解决方案，这俩依赖不同的神经通路。review 是在别人的构造上做判断，写代码是在一片空白上做构造，大脑走的不是同一段路。所以“我能看懂”根本不构成“我能写”的证据。
最阴的一层是，审写脱钩不只是在当下写不出来，而是你绕过了写代码过程里那些被迫咽下去的难吃东西。糟糕代码、失败设计、深夜调试、长期权衡，这些苦活才是工程直觉长出来的地方。Adam 自己说了句很重的话：经验无法下载，好的软件源于对糟糕代码的反复处理。代理把“生产”外包出去，你把这些全绕过去了。表层症状是写不出，深层损失是直觉长不出来。
所以 review 不会救你。你能在审查里指出别人十个错，构造能力不会因此长回来，这俩不走一条路。Rust 重写 PostgreSQL 那个例子，就是这个逻辑：代理能在性能上折腾，却搬不动项目通过修 bug 和性能教训攒成的深层理解。你以为在加速，其实是在悄悄腾空。
评论区有人提“认知债务”，Adam 回得也冷静：这不是 AI 首创的，抽象层早就这么干了。把问题包进一层 API，你就欠一笔不知道里面怎么转的债。AI 代理只是把这个模式加速到“当下就还不上”的程度。这个词我拿过来用一下，但不收进我的筐。它跟审写脱钩不是一层东西：认知债务是账单，审写脱钩是症状。
那怎么办？Adam 的动作很具体：从零用 Go 写分布式系统算法，完全不用 AI，写完才让 AI 审查。注意顺序——先写，后审。现在很多人是反的。Randall 的三层模型指到同一个点上：关键子系统，得保持盲写水平，不能只有审查水平的掌握。
这里我要把话说偏一点：不是所有代码都值得你留住盲写能力。胶水部分、配置模板、一次性迁移脚本，外包就外包。但靠它吃饭的那一层，你真正负责的子系统，你必须还能在没了补全的情况下白板重写。否则你不是在使用 AI，你是在给自己签一份停工协议。
挑一个你快不会的东西，关掉补全，白板重写！写完再让 AI 审。
你应该把这个词认领走。下次 review 完别人代码，先问自己一句：这个模块，我能不能白板重构一遍？问的人多了，审写脱钩才会从一句群里的自嘲，变成一把实际的尺子。它得被用来做决定——哪块肌肉必须保住，哪块可以外包。只把它当聊天时觉得自己废了的梗，这词白起了。
附带一个作废条件：如果半年内没人用它指“构造能力被识别力架空”这个确切的裂缝，只拿它当“手生”的同义词，或者只在水群时卖惨，不落到“要不要保住盲写能力”这个决策上，这词就没群唱起来，我回炉，不占这块空地。造词的特权，止于能不能让得出。