换一把新钥匙，用新钥匙开门——打不开。同一天又查出：生成那个密码箱的代码，在十七万字节的数据上会"爆栈"，也就是说上一次顺利导出是运气好。两次都不是大事故，却指向同一条从来没写清楚的边界：身份凭证类的动作，不能整段交出去。这是「一人工坊」的第二篇内参，2026-09-30 完稿，2026-10-06 公开。
第一次失败：我换了一把新钥匙，用新钥匙开门——打不开。
原因不是钥匙错了，是锁还没换。我们的锁是"零知识"的：钥匙从不上网，服务器上只放一个打不开的密码箱。所以换钥匙分两步——在本机把箱子用新钥匙重锁一遍（第一步，本机完成），然后把新箱子送到服务器上（第二步，才轮到线上生效）。这两步之间有个空档：新钥匙已经生效，新箱子还在路上。
在这个空档里用新钥匙去开旧箱子，必然失败。而在第一步按下"换钥匙"的时候，页面上并没有告诉我第二步需要我自己送一趟。
排查中发现，生成那个密码箱的代码，在十七万字节的数据上会"爆栈"——也就是说，上一次能顺利导出那个箱子，是运气好。
差一点，那次换钥匙就会在半途失败，而失败的样子会和这次看到的"打不开"一模一样，根本分不清是钥匙错了还是箱子坏了。
我们早就定过一条纪律：AI 承担产能，不承担立场。提问、定调、把关、署名、担责——这五件事永远是人。
但这次越界的不是立场，是另一条从来没写清楚的边界：
身份凭证类的动作，不能整段交出去。 —— 事后写进契约的第一条
换钥匙这件事，属于"与身份绑定、错了不可逆"的动作。按我们后来定下的三条硬边界——能出错、可复核、错了能改的交给 AI；要负责任、不可逆、与身份绑定的留在人手里——它本该落在第二类。可我们把它做成了一个"点一下按钮就完事"的动作，中间缺了两样东西：
缺第一样，是设计漏了；缺第二样，是分工契约里根本没有"状态回执"这一条。
| 交给 AI | 留在人手里 |
|---|---|
| 能出错的 | 错了要有人认的 |
| 可复核的 | 不可逆的 |
| 错了能改、改完看不出来的 | 与身份、署名、承诺绑定的 |
再加一条专项：身份凭证类动作不得整段交出，必须带"回滚已验证"和"状态回执"两样东西。
只问一个问题：这个月，有什么东西被交出去了，但不该交？
复盘的对象不是 AI 的表现，是我们自己的边界划得对不对。契约会随复盘进化——这本身就是答案的一部分：边界不是一次划死的，是一次次越界里长出来的。
锁屏底部加了一行小字：当前线上挂的是哪一把锁的指纹。指纹变了，说明新箱子已经上线，用新钥匙；没变，说明还在路上。一眼自判，不用猜。
导出代码改成分块编码，十七万字节不再爆栈。
内部稿在这里留了一处要求：写一次"交错了"的经历——什么事本不该交出去，交出去之后怎么样了；以及那一刻的怀疑：是怀疑自己记错了，还是怀疑系统坏了。这个怀疑很值得写。
A 篇讲的是"看不见"，这一篇讲的是"交错了"。两条合起来才是分工差的全貌：责任不会跟着指令一起外包出去。
下一篇（特稿 021 · C 结构差）讲最后一条判据：不是怎么学得更快，而是攒下的东西下一次能不能救场。