# 《Fable》通关指南：短绳AI编程法

- 来源：Hacker News 热门（buzzing.cc 中文翻译）
- 作者：Riseed
- 发布时间：2026-07-03 14:16
- AIHOT 分数：70
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmr4kiyka02nhsll5t8kmi285
- 原文链接：https://blog.okturtles.org/2026/07/short-leash-ai-method

## 精选理由

这篇是资深安全开发者一年的实战总结，提出的「短绳法」把AI代理栓紧，不是让开发者当甩手掌柜，而是逼你逐行审查，对代码质量死磕到底，比那些鼓吹全自动的大路货更有实操价值。

## AI 摘要

专业开发者经过一年多研究，总结出使用AI编码代理的“短绳方法”。该方法要求开发者全程参与：先规划并分解任务，从不使用YOLO模式，每次变更前审查差异并拒绝不想要的更改，每个子任务后提交以防止AI误操作（如Opus曾出现破坏性行为）。最终需进行人工与AI双重PR审查，PR须注明使用模型，提交者须亲自审查自己PR的代码。即便不用前沿模型，此法也能产出超越Fable 5的代码质量。

## 正文

本文是我一年多来研究如何正确使用 AI 智能体在安全关键系统中编写高质量软件的成果总结。

我将主要从软件开发者、协议开发者以及安全关键软件维护者的视角来撰写本文。

过去一年里，我深入研究了 AI 智能体。我探索了它们的极限，弄清了哪些事情可以依赖它们、哪些不能。我创建了自己的 AI 审查工具，其表现与价值数十亿美元的 AI 审查系统不相上下。我还维护了一个名为 Crush 的 AI 编码智能体的自定义分支。本文是我提炼出的最佳实践——如果你想用 AI 工具打造高质量软件，这就是我学到的方法。

有些人讨厌 AI。事实上，许多开发者应该讨厌 AI，因为它阻碍了他们自身学习软件开发的过程。本文不是为他们写的。本文是为那些技能已臻化境、在其专业领域超越所有"前沿 AI 模型"的少数专家级开发者而写。正是为了这些希望借助 AI 提升效率、同时不牺牲任何质量的专家级开发者，我才写下这篇文章。

当前方法存在的问题

如果你经常使用 AI 智能体，就会知道在会话过程中可能出现以下情况：

你发现最初的想法很蠢，存在更好的方案

你的智能体可能"偏离轨道"，开始做你不希望它做的事

我看过一些播放量数十万的视频，YouTuber 们讲解他们如何发明了由编排器管理的 12 个并行智能体组成的复杂系统，同时处理海量任务。他们声称自己不再需要参与编码过程。那不过是垃圾代码在审查垃圾代码，而 YouTuber 则坐在沙滩上、上厕所或毫无理由地啜饮咖啡。

如果采用这种“氛围式”方法，人类根本不可能建立起自己对代码库的理解。AI 会多次偏离正轨，而你只有在真正尝试使用软件时才会发现这些问题。在你不在乎质量的情况下，这种方法或许完全可行；但如果你在乎质量，就需要换一种方法。

问题在于，即使是 Fable 5 编写和/或审查的代码，也会很糟糕：

代码能运行，但效率极低且丑陋不堪。如果你在某个训练数据匮乏的细分领域工作，这种情况肯定会更频繁地发生。与某些 CEO 的营销声明相反，这些模型无法超越其训练数据进行思考。

AI 代码生成——“短绳”方法

这就引出了使用 AI 编码智能体的“短绳方法”。

这种方法并非人人都能使用。只有专业软件开发人员才能使用它。但它的优点在于，即使你没有使用前沿模型，也能获得超越 Fable 的效果。

在短绳方法中：

你使用一个规划阶段来研究任务并制定计划，同时配合类似我的“任务技能”来跟踪进度，并将大任务分解成小步骤（这是与许多“氛围工程”方法的共同点之一；该方法在以下要点中开始出现分歧）。

你绝不使用“YOLO”模式（又名“危险地跳过权限”）

AI 绝不会在你“打游戏的时候”工作

你使用一个能通过权限提示显示即将进行的更改差异的编码智能体

你像 20 世纪的某个狂热分子一样坐在那里，实际分析 AI 提议要做的更改

你始终让自己参与其中，而不是把自己排除在外（这是 YouTuber 们推崇的趋势）

你利用权限提示中的差异来保持自己对代码库的理解与时俱进，并让 AI 处于“短绳”控制之下

任何时候你看到 AI 要做你不希望它做的事情，你就拒绝授予权限

你根据需要频繁干预，以防止 AI“偏离正轨”

在任何时候，AI 都“被拴在一条短绳上”。

每个子任务结束时都会进行提交，以保护你免受 AI 搞砸并删除之前已完成工作的影响（这种情况确实可能发生，我见过 Opus 这么干）。

最后，我们会进行一次审查。

如何进行 AI 审查

仅由人类或仅由 AI 审查的 PR，其错误数量会比由人类和 AI 共同审查的 PR 更多。

AI 可以被当作一个代码检查工具。它能快速捕捉常见错误，而人类则负责发现更高级别的问题以及需要做出的方向性调整。

因此，在审查方面：

你应该使用 AI 来审查每一个 PR。

AI 必须能够访问足够的上下文（问题描述、PR 描述、代码库以及变更内容）。

你应该使用最新、最强大的可用模型来进行审查。

The PR description must disclose the precise models used (if any) in assisting with the creation of the PR under an “AI Disclosure” heading. This serves multiple purposes:

它告知维护者 AI 被使用了。

如果使用了较弱的模型，它允许他们建议更好的模型。

它表明你是一个“正派”的开发者，并没有试图“偷偷塞入 AI”。

最后，也是最重要的一点，如果 PR 使用了 AI，那么该 PR 必须由其“作者”进行审查。

最后这一点值得稍作展开。

AI 辅助的 PR 实际上是 AI 生成的 PR，人类只是辅助。因此，提交 PR 的人理应理解他们提交的内容，而如果他们自己没有审查过 AI 编写的代码，就无法做到这一点。

所以他们必须像审查别人的 PR 一样对待自己的 PR，逐行进行自我审查。完成后，他们可以确认自己批准该 PR，并请求维护者关注。这能建立并展示他们对代码库的理解。

完

这就是我们在 okTurtles 使用 AI 的方式。你可以阅读我们的官方 AI 使用政策。

我们希望这篇文章对你有帮助。

AI 声明：本文完全由连接着人类大脑的人类手指撰写。在发布前进行了最后一次 AI 风格的“拼写检查”。

捐赠 = 热爱！没有我们的支持者，我们无法做我们所做的事情。请花点时间支持我们的工作。