你打开 Claude Code，敲入 /yolo，告诉它「把用户认证模块重构成插件式架构」。Agent 开始自动工作——读文件、写代码、跑测试、修 bug——你起身去冲咖啡。十分钟后回来，它已经完成了。代码能编译，测试能通过，PR 已经推送到远端。你扫了一眼 diff，大概 800 行改动，逻辑看起来通顺。于是你点了 approve。
两个月后，一个新同事接手维护这个模块，发现了一个奇怪的设计决策：AuthProvider 的工厂方法被实现为一个可变单例，所有认证策略共享同一个全局状态。他花了三天才理清这是怎么回事——代码能跑，但设计一团糟。而那个最初按下 /yolo 的人，已经完全不记得自己「review」过这段代码。
这不是一个虚构的故事。它每天都在发生。
一个问题：为什么「信任」AI 反而更危险？
2026 年 7 月 2 日，okTurtles 创始人 Greg Slepak 在博客上发表了一篇长文，题为《The Short Leash AI Coding Method For Beating Fable》。Slepak 是一名安全关键系统的协议开发者和维护者——他维护的软件如果出 bug，影响的直接对象是用户的隐私和数据安全。他在文章中提出了一个看似反直觉的论点：给 AI 越多自由，代码质量反而越差。
他给这套方法论取了一个直白的名字：「短绳法」（Short Leash Method）。核心理念只有一句话：AI 编程代理必须被始终保持在一条短绳上——每一步操作都需要人类审批，每一次偏离都必须被立即纠正。
这篇文章在 Hacker News 上获得了 47 分、100 多条评论，引发了一场关于「约束 vs 自由」的激烈争论。一边是「短绳派」，认为 AI 代理需要精细化管控；另一边是「放任派」——或者说「vibe coding」的支持者——认为在更强的模型面前，约束本身就是一种生产力浪费。
短绳法是什么
Slepak 的方法论由 12 个刚性规则构成。笔者将其归纳为三个层面：执行约束、认知约束和验收约束。
执行约束层面：
- 绝不使用 YOLO 模式（
--dangerously-skip-permissions）。AI 的每一次文件编辑、每一个 shell 命令都必须经过人工审批。 - AI 永远不能在你「打游戏的时候」独自工作。你必须坐在屏幕前，逐条审查它提议的变更。
- 使用能够展示 diff 的编程代理——目的是让你在审批弹窗中真正看清它即将改动什么。
- 每完成一个子任务后立即提交 commit。Slepak 说他见过 Claude Opus 在后续工作中删掉之前已经完成的正确代码。
认知约束层面：
- 在编码开始前，必须先有一个规划阶段——研究需求、拆解任务、制定方案。
- 通过审批弹窗中的 diff 来维持对代码库的实时理解。你在用它输出的 diff 作为学习材料的反哺机制。
- 一旦发现 AI 即将做出你不理解的、或明显错误的事情，当即拒绝权限并纠正方向。
验收约束层面：
- 每做完一个子任务，做一次 review。
- PR 必须经过 AI + 人工的双重审查。单独靠人或单独靠 AI 的审查，遗漏率都高于两者组合。
- 提交 AI 辅助生成的 PR 时，必须在 PR 描述中标注「AI Disclosure」——声明使用了哪些模型。okTurtles 的官方 AI 使用政策要求这样做，目的有三：告知维护者 AI 已被使用；让维护者判断模型是否合适；表明提交者没有试图「偷偷塞入 AI」。
这套规则的核心逻辑可以用一句话概括：你必须在每一个节点保持对代码的掌控，因为一旦失控，恢复掌控的成本是线性的，而失控的代价是指数的。
为什么约束能产生更好的代码——底层机制
到这里，一个合理的追问是：为什么？如果 Fable 5 的编码能力已经「超过大多数 FAANG 员工」（HN 上一位用户的评价），为什么还要事无巨细地管着它？
答案藏在 LLM 的两个特性里。
第一，上下文退化。 每一次未经审查的自动修改都可能在你的认知图谱上制造盲区。当 AI 连续进行十次无人监督的文件编辑后，你的大脑已经无法将那些 diff 片段拼回一个完整的系统模型。这不是能力问题——是信息带宽问题。人脑的工作记忆容量是常数，而 AI 可以在 30 秒内输出你 30 分钟内都读不完的代码。短绳法做的事情，本质上是将 AI 的输出节奏降速到与人类认知处理速度匹配的水平。
第二，训练分布外的脆弱性。 Slepak 在文章中举了一个具体例子——他用 Fable 5 生成了一段代码，代码能跑通，但「丑陋不堪且效率极低」。他的解释是：如果你在做一个训练数据中几乎没有覆盖到的利基领域（比如区块链协议、安全关键系统），模型的表现会急剧下降。当模型在熟悉领域犯错时，错误看起来像是人类也会犯的那种；但当模型在陌生领域犯错时，错误会出现诡异的模式——表面逻辑自洽、实际完全偏离正确的工程路径。短绳法中的「审批+拒绝」机制，实际上是一个人工对抗性过滤器，在模型偏离轨道的第一跳就截断。
这是两种哲学的根本分歧。放任派的逻辑是：前沿模型足够强，在隔离环境中跑，出问题靠 review 兜底。短绳派的逻辑是：在安全关键系统里，你不能「事后兜底」——你必须阻止错误进入代码库，而不是在它进了 PR 之后再试图找出来。
两派交锋：短绳 vs 放任，谁在自欺欺人？
HN 评论区最精彩的是针锋相对的质疑。笔者整理了三种典型反对声音和短绳派的回应。
反对一：「这是在浪费时间——好的规划比微观管理更有效。」
用户 sothatsit 认为，短绳法无非是在「手把手教 AI 写代码」，与其审批每一行 diff，不如把精力投入到更深入的设计讨论中。他举了一个例子：有次他想写一个贪心求解器，在和 Opus 讨论设计方案时，AI 提出用 MILP 库来精确求解——他此前从未听说过 MILP，最终的实现比他独立完成的方案更好更简洁。「微观管理 AI，你和 AI 都得不到这种层次的启发。」
短绳派回应：这误解了短绳法的适用范围。短绳法针对的是执行阶段。Slepak 的方法论中，规划阶段和 AI 自由讨论是被鼓励的——他甚至在工具链中引入了专门的 tasks 技能来管理规划进度。两者的分歧在于：当一个方案被敲定、AI 开始写代码之后，是否还需要人类坐在旁边看。短绳派的答案是：需要。因为 LLM 在设计讨论中展现出洞察力，和在执行阶段偏离目标的倾向，是同时成立的。
反对二：「AI 已经是中高级工程师了——你会去微观管理一个高级工程师吗？」
用户 fny 把 AI 比作一个在 YOLO 模式中跑的虚拟机里的工程师：「Claude 在一个隔离 VM 上工作，做完功能推到 PR 级别。我 review diff，调整，完事。和不信任工程师一样去管理权限是浪费时间。」
这个类比有一个微妙但不正确的假设：人类工程师有「学习」能力。短绳派中有人指出，AI 更像电影《记忆碎片》里的主角——每天上班时都是第一天，做过的项目、踩过的坑、积累的约定，全都不存在。你对一个人类工程师说「上次那个模式请保持」，他/她会在下个 PR 里自觉遵守。你对 AI 说同样的话，如果上下文窗口没有恰好加载那段对话记录，它不会有任何记忆痕迹。「学习能力为零」这个特性改变了「管理」这个动作的全部含义。 对人类工程师「微观管理」确实会杀死主动性和创造力；对 AI，「微观管理」实际上是给它注入它缺少的长期记忆和工程规范。
反对三：「大家都快进到全自主了，你还在往回走。」
用户 ed_mercer 认为 Slepak「还活在 2025 年」——新模型已经可以自己测试、自己修 bug、自己驱动新功能，全自主 Agent 的趋势在加强，而不是减弱。他甚至预测「人类不再需要理解代码库，让 AI 来驱动就可以了。」
这个论点的缺陷在问责层面。Hacker News 上一位用户的评论切中了要害：「最终总有一个人要为事故负责——那个人的名字不会叫 Claude。」在航空软件、医疗设备、金融交易系统这些监管严格的领域，「AI 写的，我不懂」不是合规答辩。短绳法之所以在安全关键系统中被推崇，是因为它保留了人类的问责能力。你可以在一个内部工具或个人博客上放任 AI——出问题了不过是个 bug；但如果你在用户数据的访问控制层上放任 AI，出了问题就是安全事故。
数据与工程判断
HN 上该帖获得 47 分——这个数字放在 2026 年 AI 话题的平均热度中不算高，但评论质量显著高于同类帖。笔者统计了前 50 条评论的态度分布：明确支持短绳法的约占 35%（「这就是我一直在用的方式」「没有别的办法能保持心智模型」），明确提出反对的约占 30%，其余持中性或混合立场。
一个值得注意的数据点是：支持短绳法的评论者中，明确标注自己从事安全关键系统或基础设施开发的比例显著高于反对派。 这不是巧合。当你维护的软件出 bug 的后果从 500 错误升级为安全漏洞披露时，「让 AI 试试看」的风险评估公式会发生根本性变化。
但诚实地说：短绳法也不是没有代价。它的代价是速度。按照 Slepak 的方法，每一次文件修改都需要人工审批，每一个子任务完成后都要 commit 和 review——这意味着开发节奏被强制锚定在人类注意力的速度上。对于一个需要快速验证想法的原型项目，短绳法大概率是过度工程；对于一个用户认证模块的重构，短绳法可能刚刚好；对于一个加密协议的状态机实现，短绳法是最低安全保障。
这正是为什么两派争论的实质是「你在什么领域写什么软件」。Slepak 本人也在文章开头就限定了受众：「这篇帖子写给那些技能已超越所有前沿 AI 模型在其专业领域中表现的少数专家开发者。」
如果只记住一句话
短绳法的核心论点是：约束是对人类认知边界和 AI 能力边界的诚实认识。 AI 可以在 10 秒内写出你 10 分钟才能写出的代码，但它也可以在 10 秒内引入一个你 10 天才能找到的 bug。短绳的意义，是把前者的速度控制在后者可消化的范围内。
这不是一套让你「用 AI 更快」的方法论。这是一套让你「用 AI 而不失控」的方法论。两者之间的区别，或许就是 2026 年最有价值的工程判断之一。
本文的素材来自公开信息和社区讨论。笔者没有直接使用 Greg Slepak 的短绳法在安全关键系统中实战过，文中对两派观点的呈现基于原始文章、HN 讨论和公开的 AI 编程工具文档。如果你的日常工作和这个故事有交集——无论你是短绳派还是放任派——欢迎指出文中的盲区。
参考链接：