《Fable》通关指南：短绳AI编程法
阅读原文· blog.okturtles.org这篇是资深安全开发者一年的实战总结，提出的「短绳法」把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 风格的“拼写检查”。
捐赠 = 热爱！没有我们的支持者，我们无法做我们所做的事情。请花点时间支持我们的工作。