TL;DR
Greg Slepak（okTurtles 创始人）在安全关键系统的 AI 编码实践中总结出一套"短绳法"（Short Leash Method）：AI 永远不能脱离人的审查独自工作。本文拆解短绳法的核心原则、与主流 Vibe Coding 的关键区别，以及如何在 Claude Code 等工具中落地这套方法------包括审查流程、PR 规范和 AI 披露制度。
1. 背景：Vibe Coding 的问题出在哪？
2026 年 7 月 2 日，Greg Slepak 在 okTurtles 博客上发表了一篇引发 Hacker News 热议的文章《The Short Leash AI Coding Method For Beating Fable》。他花了一年多时间深入研究 AI Agent 在安全关键系统中的使用，得出了一个与 YouTube 上"躺平式 Vibe Coding"完全相反的结论。
先看看主流"Vibe 流"的典型画面：一个 YouTuber 坐在海滩上，12 个并行 Agent 在后台疯狂写代码，他偶尔瞟一眼手机。视频标题是"我靠 AI Agent 再也不用写代码了"。
Slepak 的评价很直接："用这种方式你不可能建立对代码库的真正理解。AI 会在你不知情的情况下多次偏离轨道，只有当你真正尝试使用这个软件时才会发现。"
更扎心的是，即使使用 Fable 5（Claude 当时最强的编码模型）写的代码，也经常"能跑但写得极其丑陋和低效"。Slepak 贴了一张截图：一段 Fable 写的代码，功能正确，但用了 30 行嵌套 if-else 和一个 O(n²) 的循环来做一个 O(n) 就能搞定的事。
2. 短绳法的核心原则
短绳法的名字本身就是一个比喻：AI 就像一条狗，你手里的绳子（leash）不能放太长。它不能自己跑到你看不见的地方去。具体来说：
绝不使用 YOLO 模式：在 Claude Code 中，"dangerously skip permissions" 模式等于把绳子完全松开。永远不要开。
AI 不能在你"打游戏的时候"工作：这不是效率问题，是认知问题。Slepak 写道："你要像 20 世纪的人一样坐在那里，真正分析 AI 提出的每一个变更。"这不是复古，这是你在维护自己对代码库的理解------如果你不看 AI 改了啥，一周后你对代码库的理解就完全过时了。
审查每一个 diff：这是短绳法的核心动作。使用一个能显示权限提示 diff 的编码 Agent（比如 Claude Code），在每次 AI 要改文件时，停下来看它要改什么。这个 diff 不是给你"瞟一眼就过"的，而是你保持对代码库理解的唯一窗口。
频繁拒绝：当 AI 要做你不想让它做的事，果断点 deny。Slepak 强调这不是浪费效率------每次拒绝都是一次"纠偏"，让 AI 回到正确的轨道上。比等它跑偏 200 行代码后再重写高效得多。
频繁提交：每完成一个子任务就 commit。Slepak 提到一个真实的坑：Opus 有时候会"发疯"，把之前做好的工作删掉。如果你只在最后 commit 一次，可能会丢掉大量工作。
AI + 人双重审查 ：一个人单独审查的 PR，或者一个 AI 单独审查的 PR，错误率都高于人和 AI 一起审查的 PR。AI 可以当 linter------快速发现常见错误，而人负责抓高层问题和方向性错误。
3. 短绳法 vs Vibe Coding 对比
用一个表格说清楚：
| 维度 | Vibe Coding | 短绳法 |
|---|---|---|
| 权限模式 | YOLO，跳过所有确认 | 每个 diff 都要人工确认 |
| 人的参与 | 写个 prompt 就走 | 全程在屏幕前审查 |
| 代码理解 | 三个月后没人知道代码怎么跑的 | 人在审查过程中持续建立理解 |
| 提交频率 | 最后一次性 commit | 每个子任务完成后 commit |
| 代码审查 | AI 自审或干脆不审 | AI 初审 + 人复审 |
| 错误处理 | 上线后发现再修 | 在 diff 阶段拦截 |
| 适用场景 | 原型、demo、不重要的工具 | 生产代码、安全关键系统 |
4. 落地配置：在 Claude Code 中实践短绳法
下面是一套可以在 Claude Code 中直接使用的短绳法工作流。
第一步：关掉 YOLO，打开 diff 审查
Claude Code 默认是交互模式，每次文件修改都会展示 diff 并要求确认。这是短绳法的基础设施------不要关掉它。
如果你之前开了 --dangerously-skip-permissions，现在关掉：
bash
# 永远不要加这个 flag
# claude --dangerously-skip-permissions # ❌
claude # ✅ 默认交互模式，每个 diff 都要确认第二步：拆解任务，逐个子任务 commit
创建一个任务文件 tasks.md：
markdown
# 短绳法任务拆解
## 子任务 1：实现用户注册 API
- 输入：用户名、密码、邮箱
- 输出：POST /api/register 端点
- 验收标准：能创建用户、密码 bcrypt 加密、返回 JWT
## 子任务 2：实现登录 API
- 输入：用户名、密码
- 输出：POST /api/login 端点
- 验收标准：验证密码、返回 JWT、错误次数限制然后逐个执行：
bash
# 子任务 1
claude "根据 tasks.md 中子任务 1 的要求，实现用户注册 API。
注意：每完成一个文件的修改，等待我确认 diff 后再继续。
完成后不要自己 commit，等我的指令。"
# 人工审查所有 diff，确认无误后：
git add -A
git commit -m "feat: 实现用户注册 API"
# 子任务 2
claude "根据 tasks.md 中子任务 2 的要求，实现登录 API。
参考刚才提交的注册 API 的代码风格和错误处理模式。
每完成一个文件的修改，等待我确认 diff 后再继续。"第三步：建立 AI 审查流程
短绳法的审查环节是 AI + 人双重审查。先让 AI 审一遍，过滤掉低级问题：
bash
# AI 初审
claude "审查当前分支相对于 main 的所有变更，检查：
1. 安全漏洞：SQL 注入、XSS、未校验的用户输入、敏感信息泄露
2. 逻辑错误：边界条件遗漏、空值处理缺失、并发问题
3. 代码风格：与项目现有代码的一致性
4. 性能问题：N+1 查询、不必要的循环嵌套
输出格式：
## 阻断问题（必须修复才能合入）
- [文件名:行号] 问题描述
## 建议改进（可选但推荐）
- [文件名:行号] 建议
## 审查通过项
- 列出没有问题的检查项
将审查结果写入 review-$(date +%F).md"然后人再审一遍，重点关注 AI 审查报告中的"阻断问题"是否真的需要阻断，以及 AI 可能漏掉的高层设计问题。
第四步：AI 披露制度
Slepak 在 okTurtles 的 CONTRIBUTING.md 中写了一条 AI Usage Policy。核心要求：任何使用了 AI 辅助的 PR，必须在描述中写明：
markdown
## AI Disclosure
- 代码生成：Claude Opus 4（模型名）
- 代码审查：Claude Fable 5（模型名）
- 人工审查：已完成（作者本人已逐行审查本 PR 的所有变更）这不是为了甩锅，而是为了透明度------让 reviewer 知道代码的来源，从而调整审查的仔细程度。而且"作者本人已审查"这一行不是走形式，Slepak 强调：AI 辅助的 PR，作者必须像审查别人的代码一样逐行审查自己的 PR。
5. 短绳法的边界：什么时候可以放长绳子？
短绳法不是教条。Slepak 承认，以下场景可以适当放松：
- 原型阶段：你要验证一个想法能不能跑通，代码将来会重写。这时候让 AI 撒欢跑一下是可以的。
- 非关键路径：一个内部管理后台的页面，出错也不会影响核心业务。
- 你比 AI 强得多的领域：如果你是这个领域的专家，一眼就能看出 AI 有没有跑偏，可以少盯一会儿。
但核心规则不变：代码进入生产之前，必须回到短绳模式。
6. 总结
短绳法本质上是在回答一个问题：你愿意用"看起来更快"换"真的更快"吗？
Vibe Coding 看起来很快------你发个 prompt 就去喝咖啡了。但 Slepak 的一年实践证明，那些"省下来"的时间，会以 debug、重构、理解代码的代价加倍还回来。
短绳法的每一步都不快------坐在屏幕前审 diff、频繁 commit、AI 审完人再审。但综合下来，总时间比"让 AI 撒欢跑完再花三倍时间修 bug"要短。
而且最关键的一点 Slepak 没有明说但隐含在整篇文章里：短绳法保护的不是代码质量，是你作为开发者的能力。如果你让 AI 替你写了所有代码而你从不理解它，一年后你不是"会写代码的人 + AI 助手"，而是"一个只会发 prompt 的人"。
参考资料
- Greg Slepak - The Short Leash AI Coding Method For Beating Fable (2026-07-02)
- okTurtles AI Usage Policy
- Addy Osmani - Comprehension Debt (2026-03-14)
- Addy Osmani - The Intent Debt (2026-06-05)