高质量软件的 Short Leash AI 编码方法

The Short Leash 方法：优先考虑人类监督而非 AI 自主性

为了在安全关键型系统中生产高质量软件，专家级开发者必须将 AI agent 作为需要持续监督的工具，而不是自主的编排器。"Short Leash" 方法拒绝了"vibe engineering"（氛围工程）的方法——即多个 agent 在极少人类干预的情况下并行运行——而是要求人类开发者在过程的每一个步骤中都保持主要决策者和审查者的地位。

自主 AI 编码的失败之处

自主 AI 编码系统经常产生"slop"（低质代码）——这些代码可能可以运行，但效率低下、美感较差且缺乏架构完整性。这在训练数据稀缺的利基领域尤为普遍，因为模型无法思考超出其训练集范围的内容。

自主 AI 使用的主要风险包括：

• Loss of Codebase Understanding（代码库理解力丧失）：脱离编码过程的开发者会失去理解其自身软件如何运作的能力。
• Agent Drift（Agent 漂移）：AI agent 经常"跑偏"，实施不受欢迎的更改或删除之前已完成的工作。
• Quality Degradation（质量退化）：即使是像 Fable 5 这样的前沿模型，如果缺乏监督，也会产生低效且"难看"的代码。

实现 Short Leash 工作流

Short Leash 方法是专门为那些在特定领域拥有超越前沿 AI 模型的专业知识的专业软件开发者设计的。该工作流包含以下要求：

1. Planning and Tracking（规划与跟踪）

开发者应该使用专门的规划阶段来研究任务并制定计划。应该使用诸如"tasks skill"之类的工具将大型目标分解为可管理的子任务，以便准确跟踪进度。

2. Strict Permission Control（严格的权限控制）

为了防止 AI 做出不受控制的更改，开发者必须：

• Disable "YOLO" mode（禁用"YOLO"模式）：绝不要跳过权限提示。
• Analyze Diffs（分析 Diff）：使用一个能在权限提示中显示提议更改的 diff 的编码 agent。开发者必须在授予权限之前手动分析每一个更改。
• Deny Permissions（拒绝权限）：立即拒绝任何与预期目标不符的提议更改。

3. Continuous Integration and Versioning（持续集成与版本控制）

为了避免工作丢失——这是 Opus 等模型的一个已知问题——必须在每一个子任务结束时进行 commit。这确保了 AI 不会意外删除之前已验证的进度。

Dual-Layer AI and Human Reviews（双层 AI 与人类审查）

高质量的代码需要混合审查过程。一个由人类和 AI 同时审查的 PR 被认为比仅由其中一方审查的 PR 始终更准确。在这种模式下，AI 充当高速 linter，用于捕捉常见错误，而人类则专注于高层级的架构问题和方向性更改。

The Review Protocol（审查协议）

• Contextual AI Review（上下文关联的 AI 审查）：AI 审查者必须能够访问完整的上下文，包括 issue、PR description、代码库以及具体的更改内容。
• AI Disclosure（AI 披露）：每个 PR description 必须包含一个"AI Disclosure"标题，指明所使用的确切模型。这可以让维护者了解所用模型的潜在弱点，并发出透明度的信号。
• Mandatory Self-Review（强制性自我审查）：如果使用了 AI 来生成代码，作者必须像审查陌生人的工作一样，逐行审查自己的 PR。作者必须在请求维护者审查之前，明确地确认其批准。

这一过程确保了提交 PR 的人类能够完全理解其提交的代码，从而维护了安全关键型系统的完整性。