1961年，新乡重夫用一个碟子和两根弹簧消除了工厂的缺陷。同样的理念，是我发现的最有效的工具——用来对付那些无法遵守指令的 AI 代理。

我正在建造制造业所谓的"黑暗工厂"——一条关着灯也能运转的生产线。车间里没有人类。在我的场景中，这条生产线编写软件。AI 代理生成代码、测试代码、审查代码、发布代码。当它正常运转时，一个人就能产出过去十个人团队的工作量。

但它出故障的次数远多于正常运转的次数。

代理们不会戏剧性地崩溃。有了 Opus 4.6 和 GPT-5.3，那些明显的失败基本消失了。实际发生的问题更加微妙，也更难捕捉。想象一个代理，它的记忆像鱼缸里的金鱼，而鱼缸里的水还在不断变浑浊。

在第五分钟，代理同意使用某种特定的 API 模式。到第九十分钟，它已经用了完全不同的另一种。不是因为它决定改变策略，而是因为它的工作记忆里塞满了自那以后做过的所有事情，早期的决策正在褪色。变量命名一开始保持一致（`userId`、`userId`、`userId`），后来就偏了（`user_id`，然后变成了 `uid`）。早期的代码严格遵循项目约定，后期的代码则退回到模型训练时学到的任何东西——通用的、安全的、不属于任何人的。

代理不是在变笨。是它的工作记忆越来越拥挤。

我的第一反应是写出更好的指令。我花了三周时间完善每条代理在开始工作前都要阅读的规则文档。更清晰的指南、更具体的示例、更严格的约束。漂移依然在发生。只是慢了一些。

我在解决错误的问题。而事实证明，在计算机出现之前，这个问题就已经被解决了。

## 碟子里的弹簧

1961年，一位名叫新乡重夫的工业工程师访问了日本的山田电气工厂。工人们在组装一种小型开关，每个按钮下面需要放两根弹簧。他们总是忘记放其中一根。缺陷率大约是 1.4%。

显而易见的解决方案：更好地培训工人。张贴提醒。为零缺陷提供奖励。

新乡重夫做了一件不同的事。他给每个工人一个小碟子。在组装开关之前，工人先把两根弹簧放进碟子。然后从碟子里取出弹簧装进开关。如果组装完成后碟子里还剩一根弹簧，工人立刻就知道自己漏装了一根。

缺陷率降到了零。

新乡重夫把这称为"poka-yoke"，大致翻译为"防错"。其洞察不在于工人。工人没问题。洞察在于工作台。重新设计环境，让错误在发生的那一刻就变得可见——在缺陷产品流入下游之前。

丰田在其所有工厂采用了这一理念。他们不再检查成品车的缺陷，而是在装配线上内置了数百个小型机械检查装置。一个只能以单一方向安装的零件。一个在螺栓缺失时停止生产线的传感器。一个在每颗螺丝都就位之前不会释放的夹具。每一个都微不足道。但合在一起，它们使丰田的缺陷率成为全行业最低。

## 每个行业都会学到这一课

1935年，一架波音原型机坠毁，因为飞行员忘记解除控制锁。解决方案是一份检查清单。2007年，一份包含19个项目的手术检查清单将手术室死亡率降低了47%。两次都是同一个教训：停止对工人进行更高强度的训练。让环境来捕获错误。

## 代理有着同样的缺陷

AI 代理有一个工作记忆——上下文窗口。窗口内的所有内容对代理同时可见。窗口外的内容则不存在。你的指令、它读取的文件、它已经写过的代码、你们的对话——所有这些都进入那个窗口。窗口很大，但不是无限的。随着它被填满，代理对早期信息的把握就会松动。想象一下一口气读完一本300页的书，当你读到第280页时，还要记住第12页的一个细节。

这正是新乡重夫所解决的缺陷。工人知道两根弹簧都要装进去。工人受过训练。但在数百次重复之后，注意力会漂移。上下文窗口是同一问题的AI版本：可靠的知识，不可靠的注意力。

我在我的流水线中测量过。在任务初期，我的代理大约95%的时间遵循架构规则。随着数小时的工作中上下文被填满，合规率下降到大约70%。同一个代理，同一套规则，同一种类型的任务。指令还在那里。只是代理对它们投入的注意力少了。

写出更好的指令，相当于软件领域中更努力地培训山田电气的工人。它在边际上有帮助。但它没有解决结构性问题。

## 软件领域的 Poka-yoke

所以，我开始建造相当于新乡重夫碟子的东西。

每一条可以表达为自动化检查的规则，我都从指令文档中抽出来，变成了一个小程序。这个文件放在正确的文件夹里了吗？一个脚本在几毫秒内就能检查，如果不对就拒绝，并附上一条消息告诉代理确切应该放到哪里。这个组件遵循了项目的依赖规则吗？一个自动化检查在代码继续推进之前就能捕获违规。视觉样式与设计系统一致吗？又一个检查，又一个即时答案。

每一个都是新乡重夫碟子里的弹簧。如果弹簧还在那里，你就知道有什么被遗漏了。如果检查失败了，代理立刻就知道哪里出了错以及如何修复。不需要记忆。不需要注意力。环境告诉了它。

另一半是通过测试产生的背压。每当代理完成一项工作，自动化测试就会在任何东西推进之前运行。不仅是"代码能不能跑"的测试，而是确定性检查：输出是否匹配设计系统？可访问性评分是否超过阈值？类型检查是否通过？构建是否成功？如果任何检查失败，代理会得到一个具体的错误和一个具体的修复方案。它无法将有缺陷的工作推到下游。流水线会把它推回来。

然后我给了它们"眼睛"。一个无头浏览器（Playwright），让代理能够打开自己构建的东西，点击浏览，截图，并验证外观是否正确。性能工具（Lighthouse），给代理一个具体的分数，而不是一个模糊的"让它快一点"的指令。日志聚合器，让代理在每次更改后都能读取自己的错误输出。代理不需要相信自己的代码能正常工作。它可以检查。

2026年初，OpenAI发布了一份详细的报告，讲述了他们如何以这种方式构建一整个产品。大约1500次代码库更改，历时五个月，零次人工编写。他们的团队把大部分时间花在构建环境上。他们给代理Chrome DevTools权限来获取DOM快照和截图。他们设置了监控，让代理能读取自己的日志。他们把错误信息写成修复指令：不是"错误：规则违反"，而是"这个组件不能从那个文件夹导入。把共享代码移到这里。"

代理没有变得更聪明。它们得到了一个设计更好的工作台。

## 房间比工人更重要

唐纳德·诺曼在1988年写了关于以人为中心设计的奠基之作，他描述了三种环境约束。互锁装置强制操作按特定顺序进行。锁定装置防止进入危险状态。他的例子是：一台裁纸机上有两个激活按钮，分别放在两侧，操作员必须张开双臂才能同时按下。在激活裁切的同时，没有任何物理方式能让手靠近刀片。

AI行业正处于其"更努力地训练"的阶段。更好的模型。更好的提示词。更好的指令文档。这些都很重要。但每一个面临同样问题——从复杂、容易出错的过程中获得可靠输出——的行业，最终都认识到环境才是首要的质量机制。而不是工人。

我仍然为我的代理编写指令。我仍然关心使用哪个模型。但我现在的大部分工程时间花在建造"房间"上：自动化检查、监控工具、兼作修复指令的错误信息、在几毫秒内运行并捕获任何指令文档都无法保证的东西的小程序。

新乡重夫会立刻认出这项工作。它就是一个碟子，里面放着两根弹簧，放在每个工作台上。