牵绳式AI编程法：如何写出超越Fable的高质量代码
作者：Greg Slepak ｜ 发布于：2026年7月2日
这篇文章凝聚了我一年多来的研究成果——如何在安全关键型系统中正确使用 AI Agent 来编写高质量的软件。
当前方法存在的问题
如果你用过 AI Agent，你一定经历过这样的场景：在会话过程中，你发现自己最初的想法很蠢，更好的方案就在眼前；或者 Agent 突然"脱缰"，开始做一些你根本不想让它做的事情。
很多 YouTuber 鼓吹由编排器管控 12 个并行 Agent 的复杂系统。说白了，这只是垃圾代码写垃圾代码、垃圾代码审垃圾代码，而 YouTuber 本人躺在沙滩上数钱。用这种"氛围编程"（Vibe Coding）的方式，你根本不可能真正建立起对自己代码库的理解。
即使是由 Fable 5 编写或审查的代码，也一样会臭：代码能跑，但效率低得吓人、丑得离谱。这些模型终究无法跳出训练数据的局限去思考。
"牵绳式"方法
这套方法并非谁都能用。只有专业的软件开发人员才能驾驭它。即使不使用前沿模型，它也能带来超越 Fable 的效果。
核心原则
- 使用规划阶段来调研任务并制定方案
- 永远不要使用"YOLO"模式（即"危险地跳过权限"）
- AI 工作时，你绝不能在打游戏
- 使用能在权限提示中展示 diff（变更差异）的编码 Agent
- 坐在那里，真正去分析 AI 建议的每一处更改
- 让自己始终处于开发循环之中
- 利用权限提示中的 diff 来保持自己对代码库的理解同步更新
- 任何时候 AI 要做你不希望它做的事，果断拒绝权限
- 频繁介入，防止 AI 脱轨
- 每个子任务结束时都做一个 commit（提交）
- 最后，做一次全面的 review（审查）
如何进行 AI 代码审查
只靠人审或只靠 AI 审的 PR，错误都比两者共同审查的多。AI 充当 linter（代码检查工具），捕获常见错误；而人则负责捕获更高层次的问题。
最佳实践
- 每个 PR 都用 AI 来审查
- AI 必须有足够的上下文（Issue、PR 描述、代码库、变更内容）
- 审查时要用最新、最强的模型
- PR 描述中必须在"AI 披露"（AI Disclosure）标题下明确注明使用的具体模型
- 如果 PR 使用了 AI，PR 的提交者必须亲自审查一遍
AI 辅助的 PR，本质上是带着人类辅助的 AI 提交的 PR。提交 PR 的人，必须真正理解自己提交的是什么。
原文出处：https://blog.okturtles.org/2026/07/short-leash-ai-method/
