Blog›Guides

Gauntlet Loop 与单次提示:实际变化是什么

同一模型,同一目标,输出却大相径庭。gauntlet 的优势在机制上源于何处,其代价是什么,以及何时使用各自的实用规则。

Gauntlet Loop 与单次提示:实际变化是什么

Gauntlet Loop 与单次提示:真正改变的是什么

你可以用一次提示让代理生成一个落地页,也可以对它进行 gauntlet 处理。相同的模型,相同的目标。输出质量的差异并不微妙,值得精确指出差异的来源。

单次提示能带来什么

模型对你意图的最佳猜测的一次通过。对于小而明确的任务(正则表达式、SQL 查询、一段文字),这通常足够了,gauntlet 会是浪费。当任务大到“看起来完成”和“确实很好”出现分歧时,单次提示就会失败:多区块页面、长文档、完整功能。模型没有外部压力,所以它停在看似合理的水平。

gauntlet 改变了什么

机制上,有三点:

  • 分解。 构建者承担产生可检查产物的狭窄部分。大任务不再是一个模糊的整体。
  • 外部判断。 一个独立的严厉批评者将每个产物与一个真实命名的标准进行盲比。“看似合理”不再足够,因为在并排比较中它会输。
  • 挣得的退出。 循环持续运行,直到工作赢得比较。时间,而不是令牌,成为预算:Claude of Duty 运行了几个小时,最终产出 55,000 行代码和 11 个子系统。
  • 诚实的成本核算

    Gauntlet 是昂贵的:许多子代理运行、许多比较、截图、重新运行。正确的思维模型是,你在用令牌换取人类编辑或艺术总监本会做的审查循环。如果输出很重要(公开页面、发布帖子、演示),这种交换显然值得。如果是可丢弃的,就单次提示并继续前进。

    实用的决策规则

    当以下三点全部成立时使用 gauntlet:输出足够大以存在质量差异,存在一个真实标准且可获取,并且你能负担得起运行。否则使用单次提示,也许加上一次手动审查。当你确实使用 gauntlet 时,从模板开始,并在按回车前检查失败模式,因为一个糟糕的 gauntlet 比一个糟糕的单次提示成本更高,回报更少。

    Tags
    gauntlet-loop·agent-loop·prompt-engineering·claude-code·builder-critic·agents