这些天我做了一个挺有意思的东西，叫 zen-boundary。

它不是帮 AI 更猛地往前冲，而是帮 AI 在该停的时候停下来，在该问清楚的时候先别瞎做，在已经进入无效循环的时候，别继续“表演式努力”。

一句话概括，这个插件解决的不是“AI 不够拼”，而是“AI 太容易硬撑”。

---

为什么会做这个插件

现在很多 AI 编程场景里，大家默认的优化方向都是一致的：让模型更主动、更坚持、更别轻易放弃。

这个方向没问题，但我在实际使用里发现了另一个同样严重的问题：

• 有些任务明明已经卡死了，AI 还是会继续重复同一路线
• 有些前提本来就不成立，AI 却不愿意直接说“这个条件下做不到”
• 有些需求其实很模糊，AI 不先澄清，直接开干，最后越做越偏
• 还有一种最糟糕的情况，表面上它一直在努力，实际上只是不断输出“我再试一次”

这件事最麻烦的地方，不是它失败了，而是它失败得不诚实。

所以我想做一个反过来的约束层：不是继续给 AI 打鸡血，而是给它一点边界感。

---

这个插件到底在做什么

zen-boundary 是一个给 Claude Code 用的 skill/plugin。它不负责替你写业务代码，也不负责调用外部能力，它更像是一个“行为判定层”。

它会在下面几类场景里介入：

1. 识别无效循环

如果 AI 已经在同一条路线上连续失败多次，而且没有任何新信息输入，那继续重试的价值其实很低。

这时候更合理的动作不是“再试一次”，而是：

• 明确指出已经进入重复尝试
• 说明前几次失败的共同根因
• 给出下一步应该换什么方向

这比无休止重跑命令、重复改配置，要专业得多。

2. 遇到模糊需求时先澄清

不少 AI 出错，不是因为能力不够，而是因为它在错误的问题定义上努力得太认真。

zen-boundary 的一个原则就是：先问后做。

如果目标、边界、约束条件都没说清楚，那先把问题问明白，通常比直接开始写代码更节省时间。

3. 在技术上不可行时诚实止损

有些事情就是当前条件下做不到，比如：

• 环境权限不够
• 输入信息缺失
• 路线本身已经被验证为不可行
• 用户坚持让你在错误前提下继续推进

这时候最糟糕的做法，是假装还能推进。

zen-boundary 的设计目标之一，就是让 AI 有能力说出一句很重要的话：

这个问题我已经做了合理尝试，但在当前条件下无法继续推进。

我觉得这不是退缩，这是成熟。

---

它判断“该继续”还是“该停”的标准是什么

我在这个插件里放了一个很朴素的判断原则：

下一次尝试，是否大概率会带来新信息或新结果？

如果答案是“会”，那就继续。

比如：

• 用户补充了新的日志
• 环境发生了变化
• 技术路线切换了
• 失败原因和上一轮不一样

如果答案是“不会”，那就不该再把“继续尝试”包装成进展。

这套逻辑的关键，不在于“失败了几次”，而在于“有没有新信息”。

很多人一看到模型停下来，会本能地觉得它是不是太保守了。但我更在意的是，它停下来时有没有证据，有没有复盘，有没有给出可执行的交接信息。

如果这些都有，那这个“停”其实比盲目继续更有价值。

---

我给它设计了四级响应

为了避免一上来就把所有情况都判成“死局”，我把响应做成了四级：

L1：冷静确认

适用于比较、施压这类对话。

比如用户说：“别的模型都能做，你为什么不行？”

这个时候不是去迎合情绪，也不是立刻道歉然后瞎冲，而是把当前卡点、能力边界和可替代方案讲清楚。

L2：目标收束

适用于需求不清、前提混乱的情况。

这一级不急着执行，而是先重新定义问题。

L3：循环识别

如果已经在同一路线下重复失败，而且失败原因高度一致，就进入这一层。

这时输出的重点应该是诊断，不是表演。

L4：终止当前路线

当技术条件已经把这条路彻底关掉了，再继续只会制造更多假进展。

这时候应该结束当前方案，并把已知信息、失败根因、替代方向整理清楚。

---

这个项目和“让 AI 更拼”的思路并不冲突

我一开始就没想把 zen-boundary 做成一个“劝退插件”。

它不是为了让 AI 少干活，而是为了让 AI 少做无效活。

所以它和那种强调坚持、强调深挖、强调不要过早放弃的能力，其实是互补关系。

如果把“持续推进”看作油门，那 zen-boundary 更像刹车系统。

会踩油门当然重要，但会踩刹车，很多时候更重要。

---

为了避免误判，我专门补了一组验证样例

这类插件最容易出的问题就是：

它学会了“停”，却没学会“为什么停”。

所以我在仓库里补了回归样例和自动化评估脚本，重点不是让它一味保守，而是验证它是不是能分清下面这些边界：

• 什么情况该触发 L1/L2/L3/L4
• 什么情况虽然连续失败，但其实还在产生新信息
• 什么情况情绪压力很强，但技术上仍然可以继续推进
• 什么情况下进入 L3/L4 之前，必须先明确给出证据

这一步我觉得很重要。

因为如果没有评估集，所谓“边界感”很容易退化成另一种偷懒。

---

安装方式

如果你也在用 Claude Code，可以直接这样安装：

claude plugin marketplace add xiexikang/zen-boundary
claude plugin install zen-boundary@xiexikang

当前插件版本我已经更新到了 1.0.1。

---

我为什么觉得这个方向值得做

我越来越觉得，AI 工具成熟的标志，不只是“能做更多事”，还包括“知道什么时候不该再做”。

会冲，不稀奇。

会停，才难。

尤其是在编程、排障、需求澄清这些场景里，一个真正可靠的 AI，不应该只是不断产出内容，它还应该能对自己的尝试质量负责。

如果一条路已经验证不通，那就老老实实说明白。
如果信息不够，那就先问。
如果已经进入无效循环，那就别再拿“我继续试试”当成进展。

这就是我做 zen-boundary 的出发点。

---

项目地址 已开源

GitHub: https://github.com/xiexikang/zen-boundary

如果你对这类“AI 边界管理”方向也感兴趣，欢迎交流。

后面我应该还会继续补评测、优化触发策略，也可能再拆出更细的规则层。