经过一年多对AI代理在安全关键系统中编写高质量软件的研究，作者总结出“短绳AI编码法”，旨在帮助专家级开发者在不牺牲质量的前提下提升效率。

以下是对原文主要内容的中文重述，保留了关键细节，删除了与主题无关的广告和捐赠呼吁等内容：

标题：击败Fable的“短绳”AI编码方法

本文总结了一年多来在安全关键系统中使用AI代理编写高质量软件的研究成果。作者从软件开发者、协议开发者及安全关键系统维护者的角度出发，深入探索了AI代理的极限、可靠性，并开发了与数十亿美元AI审查系统性能相当的内部审查工具。

当前方法的问题
使用AI代理时常见问题包括：初始想法被证明不理想、代理“偏离轨道”执行非预期操作。许多YouTuber推崇的“12个并行代理+编排器”的复杂系统，实际上只是“垃圾写垃圾”，开发者完全脱离编码过程。这种“氛围式”方法无法建立对代码库的理解，AI多次偏离轨道后，问题往往在软件实际使用时才暴露。对于不关心质量的场景或许可行，但若重视质量，则需要不同方法。即使Fable 5等前沿模型生成的代码，也可能效率低下且丑陋，尤其在训练数据不足的细分领域。

“短绳”AI编码方法
该方法仅适用于专业软件开发者，即使不使用前沿模型也能获得超越Fable的效果。核心原则包括： - 使用规划阶段研究任务并制定计划，借助任务技能追踪进度、分解大任务。 - 绝不使用“YOLO”模式（即“危险跳过权限”）。 - AI绝不“在你玩游戏时工作”。 - 使用能通过权限提示显示即将修改的差异（diff）的编码代理。 - 像20世纪的人一样，实际分析AI提议的更改。 - 始终保持对过程的参与，而非像YouTuber趋势那样抽身。 - 利用权限提示中的差异更新对代码库的理解，让AI“拴在短绳上”。 - 发现AI即将执行非预期操作时，拒绝权限。 - 频繁干预，防止AI“偏离轨道”。 - 每个子任务结束时提交，防止AI错误删除已完成工作。 - 最后进行审查。

如何进行AI审查
由人类和AI共同审查的PR比单独由一方审查的错误更少。AI可视为“代码检查工具”，快速捕捉常见错误；人类则负责高层次问题和方向性调整。审查要点： - 每个PR都应使用AI审查。 - AI必须获得充分上下文（问题、PR描述、代码库和更改）。 - 使用最新、最强大的模型进行审查。 - PR描述必须在“AI披露”标题下说明使用的具体模型，目的包括：告知维护者使用了AI、允许建议更优模型、表明开发者是“好人”而非“偷偷使用AI”。 - 最重要的是，如果PR使用了AI，PR“作者”必须亲自审查该PR。AI辅助的PR本质上是AI编写、人类辅助的PR，提交者必须理解提交内容，因此应像审查他人PR一样逐行审查自己的PR，确认无误后批准并请求维护者关注。这有助于建立和展示对代码库的理解。

结语
这就是okTurtles使用AI的方式。希望本文对您有所帮助。

AI披露：本文完全由人类大脑连接的人类手指撰写，发布前仅进行了AI风格的“拼写检查”。

以下是对评论内容的总结，涵盖主要观点、论据及不同立场的平衡呈现：

主要观点与论据

1. 支持“短绳”策略（严格监督AI） - 论据：AI仍会偏离轨道，需人工持续审查代码，避免后期发现严重问题。
- 引用：“The AI will have gone off the rails multiple times and you will only notice it later when you actually try to use the software.”（作者ed_mercer）
- 引用：“There has to be a human in the loop somewhere... by the time you start skipping permissions... you get a suboptimal solution and token waste.”（作者moezd）
- 认可度：部分评论者认为这是必要且务实的做法，尤其对复杂项目。

2. 反对“短绳”策略（主张信任AI） - 论据：强模型（如Fable）能自主处理复杂任务，过度监督浪费其能力；通过充分讨论和迭代可提升效果。
- 引用：“Hand-holding great models like Fable through implementation is a waste of time... You can have increasingly nuanced discussions with stronger models.”（作者sothatsit）
- 引用：“I’ve ran Claude from an isolated VM on yolo mode... Claude works on a feature up to a PR worthy point. I review the diff... and move on.”（作者fny）
- 认可度：部分评论者认为AI已接近中级工程师水平，可赋予更多自主权。

3. 对AI能力的质疑与边界讨论 - 论据：AI本质是“下一个词预测器”，无法真正理解代码；其输出受训练数据限制，且易产生“幻觉”。
- 引用：“LLMs are still next token predictors... just because you can give it more vague instructions... it doesn't mean it's intelligent.”（作者moezd）
- 引用：“Contrary to marketing statements... these models are not able to think beyond their training data.”（作者CamperBob2引用原文）
- 认可度：部分评论者认为AI在简单场景有效，但复杂任务仍需人工介入。

4. 对文章权威性的质疑 - 论据：作者经验不足，观点过于自信且缺乏可验证证据。
- 引用：“This post seems like some decent advice mixed in with a lot of overconfidence and unverifiable claims.”（作者WhitneyLand）
- 引用：“I love how everyone and their brother feels qualified to write advice... based on a couple months of experience.”（作者hungryhobbit）
- 认可度：多位评论者认为文章内容重复或缺乏新意。

5. 实用建议与替代方法 - 论据：通过精心设计上下文、分阶段迭代、使用不同模型审查代码等方式可提升效率。
- 引用：“The solution for that is pretty easy too... it's just iteration: you describe the exact problem... and ask them to provide a narrow fix.”（作者YuechenLi）
- 引用：“I have found a different model should be used to do the review - like if Claude did the code, Codex should review.”（作者agrippanux）
- 认可度：部分评论者强调“上下文管理”和“迭代”是关键。

平衡性总结

• 支持短绳：强调安全性和可控性，适合对代码质量要求高的场景。
• 反对短绳：主张信任AI能力，适合快速原型或低风险项目。
• 中立/质疑：指出AI局限性，呼吁更严谨的评估方法。
• 实用建议：聚焦具体技巧（如迭代、上下文管理、多模型协作），而非绝对立场。