要学会 Fast-Fail，否则 Token 不知不覺就没了

很多人做 AI 项目落地，失败时第一反应是“再教它一次”：把 Prompt 写更长、加更多约束、堆更多 repair 回路。

但如果你的系统经常遇到这种情况：

• 模型先自言自语分析 2000 字，真正的 JSON/结论放在最后
• 输出被截断（finish_reason=length），关键结构化结果没出来
• 明明要求 JSON/FILE，它却回一段“解释我为什么这么做”

那你缺的往往不是“更长的 Prompt”，而是一个成本工程策略：Fast-Fail。

Fast-Fail 的核心很简单：

一旦确认“大模型返回输出的形态不对”，立刻止损，马上重试。不要等它把话说完，更不要指望它“后面会乖乖吐结构化结果”。

1) Fast-Fail 是什么

Fast-Fail 是一种面向成本的生成策略：用“更早的失败判定”换“更小的总成本”。

它不是：

• 情绪化地判模型“垃圾”
• 对模型苛刻
• 为了追求一次输出 100% 完美

它是大模型产出工程止损：

把最浪费 Token 的部分（长篇胡说 + 截断 + 多轮修复）砍掉。

2) 为什么它是“最省钱策略”

你花钱买的不是“模型说话时间”，而是大模型“可交付输出”。

当模型进入“长篇解释模式”，会发生三种典型浪费：

• Token 浪费：解释性文字吞掉预算，结构化输出被挤到后半段
• 时间浪费：你等它讲完才发现没用，或者最后被截断
• 修复浪费：repair 链越长，越容易把错误变成新错误

Fast-Fail 把这三种浪费压成一句话：错了就立刻重来。

3) 什么情况下应该 Fast-Fail（可判定的信号）

Fast-Fail 必须是“机器可判定”的，不靠感觉。

3.1 结构化输出（JSON）

• 要求 JSON object：输出在前 N 个字符内没有出现 {
• 要求 JSON array：输出在前 N 个字符内没有出现 [
• 输出前缀明显是解释性文字（“我需要先分析…”、“首先…”、“下面我将…”）

3.2 文件式输出（FILE:）

• 要求 FILE: 前缀，但输出不含 FILE: 或者前缀位置过靠后

3.3 明确的截断信号

• finish_reason=length
• 或者 Raw Output 明显缺括号/缺引号/未闭合

这些信号出现时，最贵的错误是：继续等它“可能会在后面给你正确格式”。

3.4 真实样本

下面这些片段来自项目跑链路时保存下来的 Raw Output。它们的共同点是：

模型当下的输出形态已经错了，继续等下去只会更贵。

样本 A：Phase 1 前缀不是 JSON，模型开始“解释任务”

===== Phase 1 Fast-Fail（前綴非 JSON，將直接重試） @ 2026-08-16 01:53:14.306 =====
我们需要回答用户要求：仅输出一段合法 JSON 物件，不要解释文字，不要包 code fence。
我们需要解析需求文档：这是一个【某金融业务流程】（已脱敏）...

这时候最省钱的动作不是“等它讲完”，而是立刻重试，让它回到 JSON-only 的交付模式。

样本 B：Phase 2 要求 JSON array，但开头不是 [

===== Phase 2 Fast-Fail（前綴非 JSON 陣列，將直接重試） @ 2026-08-16 03:28:56.770 =====
We need answer with JSON only. Need parse task. We need only expand whitelist modules...

这种输出往往会把“该吐数组”的预算消耗在解释里，等到它想起要吐 [ 时，已经接近截断线了。

样本 C：同样是 Phase 1，模型一上来先做“业务方案复述”

===== Phase 1 Fast-Fail（前綴非 JSON，將直接重試） @ 2026-08-16 06:03:11.398 =====
我们需要输出一个 JSON 对象。我们需要根据需求文档规划 modules。需求文档是【某业务方案】（已脱敏）...

你想要的不是“它复述得对不对”，而是“它有没有按约定把结构先吐出来”。Fast-Fail 处理的就是这个优先级：先交付形态，再谈内容质量。

4) Fast-Fail 的正确搭配：保留 Raw Output（不要黑箱）

Fast-Fail 不是“看一眼就扔掉”，它必须配一件事：保留 Raw Output。

理由很现实：你需要区分三种情况：

• 模型根本没按要求输出结构
• 模型输出了结构，但被解释文字包住
• 模型输出被截断，结构没闭合

不留 Raw Output，你会把所有失败都归因成“模型不行”，然后开始堆 Prompt、堆 repair，成本只会更高。

5) 设计一个“温和但坚定”的重试策略

Fast-Fail 的关键在："果断重来给它一个更容易成功的第二次机会”。

一个实用的顺序是：

• 第一次：正常 Prompt（带 Harness 约束）- Fast-Fail：若前缀信号不对，立刻重试
• 第二次：更短、更硬的 Prompt（把输出形态写死，禁止解释）
• 仍失败：再进入 repair（只在必要时）

这背后的原则是：优先用更强约束的重试，把模型从“解释模式”拉回“交付模式”。

6) 最小实现（MVP）：三件事就够

现在最小可用版本只要做下面三件事：

6.1 前缀信号检测

• JSON object：在前 200–500 字符内是否出现 {
• JSON array：在前 200–500 字符内是否出现 [
• FILE：在前 200–500 字符内是否出现 FILE:

6.2 Raw Output 记录

每次调用至少记录输出下面格式：

• 时间戳、model、finish_reason、latency
• 本次任务标签（Phase/模块/目标输出类型）
• Raw Output 原文

6.3 失败归因标签

要求整理失败状态最小集合：

• NON_JSON_TEXT
• LENGTH_TRUNCATED
• INVALID_JSON / SCHEMA_MISMATCH
• NETWORK_ERROR（注意：很多网络错误属于 doubtful state）

7) 有些人的对Fast-Fail 意见

7.1 “Fast-Fail 会不会把正确答案错杀？”

会。但工程上你要优化的不是“单次最优”，而是“总体交付成本”。

当你要的是结构化输出时，“偶尔错杀”通常比“每次都等它长篇胡说到最后再截断”便宜得多。

7.2 “为什么不直接让模型别解释？”

你当然可以写，但你控制不了它每次都听话。

Fast-Fail 的价值在于：不管它听不听话，你都能把成本锁死。

8) 一句话收尾

Fast-Fail 是一种工程态度：把“可能会成功的长等待”换成“可控的短重试”。当你开始用它，你会发现很多所谓的 Loop，本质只是没有止损机制。