击败 Fable 的短牵绳 AI 编码方法

原文 ↗ Hacker News 讨论 ↗

对“短牵绳”方法的总体反应

  • 许多人认为这种工作流（密切监督、分步授权、人机协同）本质上就是谨慎的开发者已经在重要代码上使用 AI 的方式。
  • 也有人觉得这过于谨慎，属于“微管理”，相比让代理在沙盒里更自主地工作、只审查 diff/PR，会拖慢速度。

AI 编码中的自主性与监督

  • 强烈支持严格控制的一派：
    • 认为模型仍会产生幻觉、忽略指令，并引入细微的 bug 和安全问题（例如 IDOR、糟糕的并发、糟糕的数据库访问模式）。
    • 认为不可能“从人的角度”完全信任自主代理，尤其是在受监管或高风险系统中；责任仍由人承担。
    • 强调频繁审查有助于保持对代码库可操作的心智模型。
  • 强烈支持更长牵绳的一派：
    • 将代理运行在 VM/容器或带受限密钥的独立用户环境中，然后让它们在该边界内“yolo”。
    • 把 AI 看作一个非常快的初级到中级工程师：让它构建功能，然后由人来审查并调整结果。
    • 有些人表示，在大型生产代码库上，对于中等规模任务，完全自主处理也能取得不错结果。

脚手架、工具与安全模式

  • 常见模式：
    • 沙盒环境（容器、VM、专用用户、Nix shells）。
    • 工具白名单 / MCP，仅允许安全命令，或 bash 命令白名单加 hooks。
    • 自动模式 / 半自动工作流，以减少持续的授权提示。
  • 分歧：
    • 有人说在沙盒外“永远不要跳过权限”；也有人说，严格沙盒 + 完全自主，比无休止的审批更好。

代码质量、测试与审查

  • 普遍认同：
    • AI 生成的代码必须审查；测试和 CI 至关重要。
    • 多轮 AI 处理（规划、实现、审查、安全扫描）再加上人工审查，效果比一次性生成更好。
    • 用一个模型审查另一个模型的代码，能比自审发现更多问题。

模型能力与“智能”

  • 对能力的看法分裂：
    • 有些人认为当前前沿模型在许多任务上可与许多 staff 工程师媲美甚至更强；另一些人则发现它们在困难问题上很弱（复杂并发、大型多服务系统）。
  • 一段较长的哲学分支讨论：
    • “下一个 token 预测器” vs 真正的智能；人类与模型的推理；事后理由与“说谎”。
    • 没有共识；几位评论者指出，真正重要的是实际可靠性，而不是标签。

对软件实践的影响

  • 有些人担心未来人类将不再理解代码库，而由 AI 来“驾驶”它们；也有人认为在许多领域这不可避免，但对安全关键系统则未必如此。
  • 几位评论者强调，当人类专注于架构、规格和测试，让模型承担更多机械性的实现工作，并保持足够紧的审查以维持理解时，AI 的效果最好。