不破例不行。候选池里躺着两个，一个我摸了三天还没摸明白它到底想解决什么，另一个 README 写得漂亮得可疑，翻进代码就三个文件，手一抖就关掉了。都不写。
倒是两周前在 dev.to 划到的一篇帖，一直在脑子里转。Robert Adamson，9 月 23 号发的，标签挂 ai、programming、productivity、discuss。一句定调——讲代码变便宜之后，拥有它反而更贵了。
第一遍我是当行业感慨划过去的。这类东西最近多到发腻，句式都差不多，读完跟没读一样。让我停下来的是里头一个词。
理解债务
他把它跟技术债务并排放。
技术债务你熟：知道代码写乱了，权衡完先上线，账记在明面上，起码有个人清楚自己欠了什么。理解债务不是这个——代码在手里，跑得也正常，但没人说得清它为什么这么跑。
这句我看了两遍。
技术债务是已知的烂，理解债务是不知道自己哪里不懂。后者难抓，因为它不长在代码里，长在人脑子里，只在人离职、出事、动一个看起来无关的地方的时候才现形。grep 不到，review 里也指不出来——review 的那个人自己也不知道自己不知道。
（这句我说满了，先自己收一下：测试覆盖、注释、ADR 都能对冲掉一部分。我只是想说它比 lint 报错那种摆明面上的东西隐蔽得多，别拿上面那句当定义。）
最硬的一处
同一个模型既写实现又写测试，两边很可能共享同一处对需求的误解。于是你拿到的是 CI 全绿、覆盖率好看、功能是错的。
这个场景我信。测试证明不了预期对不对，它只证明代码符合某个预期。当预期的来源和实现的来源是同一个脑子——不管那颗脑子是人的还是模型的——循环就闭上了，闭得还挺舒服，绿油油的，没人想去戳。真正需要人上手的地方恰好在这一层：需求本身有没有人真看过。
还有个例子我觉得比论证有说服力：agent 一次跨 15 个文件加完一个功能，数据库 schema、服务逻辑、API 处理器、校验、后台任务、缓存、测试、前端状态全动过。事后问为什么这么改，没人说得清。人写也未必说得清，但人写不了这么快——慢这件事过去一直在逼人理解自己做了什么，这道闸门现在被绕过去了。
评论区 11 条，有几条比正文值钱。
一条说自己写的 hook 用来拦工具调用，某次它抛异常被整个跳过，工具调用在 574 毫秒内照常跑完。护栏自己挂了，而且挂的方式是"放行"。这个我会记很久。顺带说明一件事：护栏逻辑本身也是代码，也得被验证，默认失败行为该是停，不是继续。
——刷着刷着跑题了，拉回来说正事。
那条规矩
作者给的规矩我完全同意，而且觉得它该当保命条款看，不是流程建议：不要合并自己解释不了的代码。至少要能说清改了什么、为什么改、数据在系统里怎么流、哪儿可能炸、假设了什么、碰了哪些外部服务、怎么回滚。
评论区还有一条，把 agent 生成的代码当初级开发者写的代码对待，彻底审，责任人写明白，判断标准就一句：这是人写的，我会合并吗。
这句我服。它把"AI 写的"这个前缀从决策里摘出去了。代码不会因为是模型打出来的就少一个签名——合并、批准、部署的那个人就是所有者，生产出事没人问是哪个模型生成的。
所以这期真正想说的是：这波里稀缺的从来不是会写代码的模型，是肯在一个绿对勾前面说一句"等等，我讲不清这段为什么这么写"的人。
作者还建议动代码之前先让模型把现有架构解释一遍、列出打算改哪些文件、说清每处改动的理由、点出风险，等批准了再动手。修一个坏计划比修八百行按坏计划生成的代码便宜——逻辑没问题。我还是得嘀咕一句：多数团队不会这么干，因为这一步看起来像慢下来，而慢下来是现在最不受欢迎的动作。
顺手提一下，评论区有人拿 Obsidian 搭了一套自己的流程，挂着 Cursor 和 Codex，专门练"事后能不能解释"这件事，宁可慢。这条不展开，留给下次。
适合谁看：正把 agent 往主干上灌、团队里没人管"谁来解释"这件事的，花二十分钟读完，比再刷十条模型更新推送有用。不适合谁：还在挑哪个补全更快、哪个模型更聪明的——帮不上你，这篇讲的不是工具选型。风险也说清：我只读了一遍正文加两遍评论，没在自己团队里跑过，别拿它当方法论。
能不能落地别人说了不算。你挑一次 agent 提的 PR，从头到尾把改了什么讲一遍，讲不出来就是讲不出来。
我先挖到这儿，候选池里那个 MCP server 再养两周看看。