开发者构建开源插件The Enforcer，用强制约束替代提示词让Claude Code守规矩

我在开发一个名为 The Enforcer 的开源 Claude Code 插件。倒不是因为我喜欢写更多规则，而是因为客客气气地请求一个编程 agent 乖乖听话，显然不够用。

如果某件事必须发生，我不想靠运气指望模型记得住。我要让系统把错误的事情变得难以做到。

编程 agent 跑偏时，惯常的补救办法是加更多提示词。加一条规则。解释一下错在哪。再写一个 skill。告诉它别再那样做。如此反复。到某个时候你不得不问自己，我们为什么还在干这种事。

我遇到过 Opus 5.5 在错误的时机尝试调用工具、光说不做、停下来推荐没人要的记忆。单看每件事都不算什么。但够多次会话之后，你花在盯着它上面的时间比干活还多。

我对演示看起来多惊艳没兴趣。每次发布都带着一轮新的“信我兄弟”式基准测试，Anthropic 的也不例外，而它们没有一个能告诉我，模型在普通一天的工作进行到一半时表现如何。与此同时 X 上全是人在炫耀一次性 vibe-coding 的演示，这些东西本来就平平无奇，视频一结束就毫无用处。

我想要的是对真实代码库做小而正确的改动，以及对于什么测过、什么没测过给出一个直截了当的答案。

没人会通过在 README 里写“请保持完整性”来保护数据库。我们用约束和事务。那我们凭什么对关键的 agent 行为另眼相待？

模型解决不了模型的问题。再加一段提示词，无非是让那个出了错的家伙自己盯着自己。这是个软件工程问题，而这类问题我们早就会解了。我们写确定性的代码。

所以我的 harness 用 hooks、schema 和状态门。Claude 可以自己想办法完成任务。但它不该有权决定某条硬性规则是否适用。

有一段摘录展示了我的 PreToolUse:Bash hook 拒绝执行一条 shell 命令，直到所要求的回复已经发出。Claude 又试了一次。同样的拒绝。等它回复完之后，stop hook 给了它一个相当明确的推动：“工具能用。去干活。”边界之所以守住了，是因为工具被挡住了，而不是因为 Claude 突然领会了任务。

这段也展示了让人抓狂的地方：Claude 花了好几轮解释自己为什么没法继续，而不是恢复过来接着干。所以这道门尽职了，却还是浪费了我的时间。

这是我没想到的教训。一个能挡住错误操作的 hook，如果 agent 没法快速通过它，那就算不上好的强制执行。没有恢复路径的强制执行，只是一种新的烦人方式。好的门需要一条清晰的通过路径，而不是开启一场关于这道门的新对话。

另一段摘录里，Claude 请求把一个相当普通的测试观察存入记忆。我说不行。不是因为我想要关掉自动记忆。

我确实想听听那些想法。偶尔有一个值得保留。但我估计我接受的建议大概只有 1–2%。其余的通常是当天任务里的细节，被包装成了永久的智慧。把好的那些给我，但别让每次运行都变成一道行政手续。

这个问题是另一类问题，值得把话说清楚。一条记忆是否值得保留是判断问题。没有任何 schema 能决定它。hook 能决定的是机械的那部分：没有我的同意，什么都不会写入记忆。

这也是我给这个插件划的线。硬性要求强制执行。偏好则保持为引导。如果 The Enforcer 试图强制执行品味，那它就只是一个更繁琐的提示词。

下一段摘录跟 Claude Code hooks 完全无关。CS126 是我 MakerSketch 应用里 Ask 功能的一项工作，这个功能让模型通过工具调用来完成工作。这是同一个原则在不同边界上的体现。在 Claude Code 里我只能把门设在工具前面。而在 Ask 里，模型对话的工具归我所有，所以规则直接写进接口本身。

CS126 的报告比又一份精心润色的、关于 agent 打算如何表现的说明有用得多。它说七个切片已落地，工具接口有改动，三次录制的回放已运行。实际加进去的是控制措施，而不是又一页指令。

这才是有用的工程：规范化输入、拒绝无效操作、维护状态，并度量输出结果。

然后，就在同一份报告里，我们看到最终的 engine 复查没有跑，两个应用测试失败仍然存在，也没有进行 live-model 桥接运行。

所以，是的，工作落地了。不，这不等于一个验证通过的绿色构建。我不该需要去读那些小字才能弄明白这一点。

“我已完成所有必需的任务”和“所有必需的验证均已通过”是两句不同的话。

完成与否必须来自测试结果和记录下来的状态，而不是模型给自己发奖状。

讲个我团队里初级工程师的小故事。我可以给他们一个含糊的任务，而他们多半会自己去挖。读代码。问了解来龙去脉的人。检查边界情况。回来时带的东西比我预期的多。

这种事发生得足够频繁，以至于我习以为常。不是完美，也不是读心术。是韧劲、好奇心，以及在需求有点糟糕时真心想把事情做好的决心。有时他们也会理解偏，但他们会先努力找对方向。

现在拿这个跟 agent 比一比。我坐在那些据说以非凡水平运行的模型面前，捂着脸，因为它们停下来叙述一个拒绝、凭空扩大范围，或者在测试跑完之前就宣布胜利。我在初级工程师身上从没见过哪怕接近这种情况，这才是真正让我抓狂的地方。生成代码和展现工程判断力之间，有着相当大的差距。

The Enforcer 就是我在写的插件，用来让这件事可复现。不是又一个性格提示词。而是一种把重要指令变成 agent 无法悄悄越过的边界的方式，并在它试图越过时给出有用的反馈。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）