企业官网建设流程全解析

1. 整个事故的起因：我天真地以为慢的锅在模型

先说结果：一次批量内容处理任务，92 次请求，烧掉 1340 万 token，耗时一个晚上。事后复盘，我把这 92 次请求拆成了 91 次“有效”加 1 次“彻底翻车”，而这个 91 又能拆成 25+14+15+12+8+8+5+4 的诡异结构。这不是什么炫技的数学游戏，这是我验收流程里一道一道裂缝的真实投影。

如果你也在用 LLM 做批量处理，或者正在搭所谓“AI 自动化流水线”，我劝你花十分钟看完这篇复盘。因为我踩的坑，和你未来大概率会踩的坑，几乎是同一个。

先说结论级别的经验：慢的不是 AI，是验收流程。AI 生成内容本身只要几十秒，真正吃时间和 tokens 的，是我一版又一版的人工抽检、返工重跑、局部修复、参数微调。而所有这些动作，本质上都没有被设计成“低消耗模式”。

所谓 91=25+14+15+12+8+8+5+4，其实是我把整个验收过程按批次重跑的次数和对应 token 成本做的聚类。第一批 25 次是首轮全量验收，第二批 14 次是修复后复验，第三批 15 次是格式统一，第四批 12 次是边界 case 单独验证，剩下的三个 8、一个 5、一个 4 分别是字段补漏、上下文补齐、输出格式回退、以及最后人为“看着不对劲”的重复确认。

你可以把它看作一个失败项目的“病理切片”。下面我把切片一层层剖开，讲清楚每一步为什么会烧掉这么多 token，以及如果你不想重蹈覆辙，该怎么修正验收流程。

2. 为什么 token 会烧得这么快：三个隐形黑洞

在拆流程之前，先建立一个基础共识：token 是什么。简单说，token 是模型处理文本的最小单位，一个汉字的概率大约是 1 到 2 个 token，英文单词往往会被拆成多个 token。对话越长、上下文越多，每次新请求携带的“历史包袱”就越重，每次模型返回的内容也都要按 token 计费。

这就引出了第一个黑洞：上下文重复携带。假设你写了一个循环，每次请求都带上完整的系统提示词、历史摘要、上一次的返回结果，那么哪怕你只改了一个字段，也要为完整的千字上下文买单。92 次请求，如果每次平均带 2000 token 的历史，光这些就 18 万 token，还没算生成内容。我这次实际数字远高于此，说明后面还有更重的循环。

第二个黑洞是无效重试。比如某次生成结果格式不完全符合预期，你直接重跑同一个 prompt。看似只多了一次请求，但实际上你丢失了前一次可能正确的部分，又让模型在白纸上重新画了一遍。全量重试就是这种“推倒重来”的极致形态，token 翻倍只是起步。

第三个黑洞是人工抽检的“不确定感”。AI 输出质量有随机性，你抽检 10 条有 1 条不合格，你会担心另外 9 条里也有坏品。于是扩大抽检比例，再不行就全量返工。每一次“扩大抽检”背后，都对应着一次或多次修复性请求，而这些请求往往没有缓存、没有复用，全部按原价收费。

看到这里你应该明白了：token 消耗不是模型的问题，是你的流程在无限重复支付上下文费用和生成费用。

2.1 我的 92 次请求到底都花在哪

我用一个最直观的表来还原现场。这个表是我事后从调用日志里抠出来的，按批次聚类，每个批次代表一种类型的操作。

这个表只是示意，真实数字要比这个更复杂，但大致轮廓就是这样。你可以清楚看到：8 个批次里，前两批就占了接近一半 token，而真正的“有效成果”却只来自第一批的少数几条。

3. 核心问题根因拆解：验收流程缺了四道关

如果你只记住一句话，那就是：AI 项目失败的根因往往是流程设计问题，而不是模型能力问题。我把问题归结为四个关卡全失守。

3.1 第一道关：输出结构没有强约束

我第一次调用模型时，只写了很宽松的提示词，比如“生成一段产品描述”。模型当然会自由发挥，有的带标题，有的带换行，有的用列表，有的用段落，有的还会自行添加“注意事项”。

这导致了什么问题呢？后续想批量处理这些内容时，程序无法统一解析。比如我想提取所有标题，但有些标题在第二行，有些在第三行，有些还是加粗格式。于是我只能让模型“重新生成一份格式统一的版本”，这就毁掉了第一批的 15 次请求。

如果一开始就在 prompt 里定义 JSON 输出结构，或者规定必须使用 Markdown 的二级标题加正文，模型就不会跑偏。你给模型的自由，最终都会以 token 账单的形式回到你身上。

3.2 第二道关：缺少确定性规则校验

AI 生成的东西，必须经过“机器可判定的规则”校验，而不是靠人眼。比如字段 A 是否非空，字段 B 是否为数字，字段 C 是否在枚举值内。这些校验一秒钟就能完成，而且几乎不费 token。

但我的验收流程里，校验方式是“读一遍，凭感觉判断”。当内容数量一多，人眼疲劳之后，就会产生大量“模棱两可”的判断，你会怀疑、会犹豫、会反复请求模型确认。这比机器校验贵了一万倍。

正确的做法是：先写一套校验脚本，跑一遍，把不合格的内容列出来，再只看不合格的那部分。我这次如果早做这步，至少能省掉 30% 到 40% 的无效请求。

3.3 第三道关：修复逻辑没有局部化

当某一条生成结果不合格，我最初的修复方式是把这条数据连同完整上下文重新发给模型，然后说“请修改”。模型没有记忆，它对“修改”的理解是靠你新提供的对照信息。

这就有两个问题：第一，你重新发的完整上下文本身就是几千 token；第二，模型可能会连带改变原本正确的部分，产生新的不可控差异。修复一个字段，结果把另外三个字段也改了，这在我实际跑的过程中出现了不止一次。

更合理的修复方式是：只把“错误字段 + 标准格式要求”发给模型，让它输出一个新字段值，然后由代码替换原字段。这样上下文短、任务单一、正确率高，重复请求次数也会大幅下降。

3.4 第四道关：批处理没有暂停与Checkpoint机制

我这次最蠢的一个行为是：跑完 25 条内容之后，没有中断保存中间结果，而是继续往下跑。结果后续流程发现前面 25 条里有问题，需要返工。返工时，由于没有 checkpoint，我只能重跑整个流程，而不是只复跑有问题的那几条。

如果你的项目是多阶段流水线，一定要设计好 Checkpoint。比如每处理完一批，就把结果、以及当时的上下文摘要、校验报告全部落盘。这样下次修复时，就可以从失败节点继续，而不必从头来过。

4. 实操现场复盘：92 次请求的完整还原

为了让你能真正理解过程，我拿其中一个具体任务段做还原。假设要生成 20 条“产品卖点描述”，每条最终需包含三个字段：卖点标题、卖点正文、适用人群。

4.1 第一轮生成与验收（对应 25 次请求）

我一次性让模型生成 20 条内容，采用的是一个包含完整上下文的长 prompt。模型返回的是一大段 Markdown，里面有各种 H3 小标题和段落。

然后我开始人工核对，每条内容看一遍，把觉得不合适的标记为“需修改”。20 条内容里，我感觉有 8 条需要改，但其中有几条我不太确定，于是又让模型重新解释或者换一种写法，每条平均来回 1.5 次。

总计生成的请求：20 次初次生成 + 5 次人工复核请求 = 25 次。这 25 次请求的 token 成本很高，因为每次人工复核我都带上完整的历史对话和原来的生成内容。

注意：人工复核绝不能通过“附录完整上下文”的方式让模型自我检查。模型不具备稳定的自我纠错能力，你应该把复核工作交给脚本或规则，把调用机会留给确定性任务。

4.2 局部修复反而扩大问题（对应 14 次请求）

第一轮标记出 12 条问题内容，按道理只需要 12 次修复请求。但我在第二次修复时，给模型的 prompt 是“请根据以下原文、修改意见，重新生成完整内容”，导致模型常常把原本正确的内容也改了。

12 条修复中，有 8 条修复后格式跑偏，需要第三次再修，最终产生了 14 次请求。这 14 次里，真正有用的可能只有 6 到 8 次，其余的 6 次是“连带伤害”造成的重跑。

正确做法：把原字段值拆出来，使用“字段级修复 prompt”，例如“将以下正文修改为不超过 50 字，输出 JSON 格式”。这样模型只专注于一个目标，几乎不会碰其他字段。

4.3 格式统一与边界案例（对应 15+12 次请求）

格式统一阶段最坑。因为前两轮导致每条内容的标题层级、加粗方式、段落数量都不一样，而我后续要导入另一个系统，要求所有内容必须符合严格模板。

我尝试让模型统一转换格式，本质上是把“格式化”这个确定性问题交给概率模型处理，结果 15 次请求中有一半内容仍然偶尔跑偏。边界案例则更离谱，比如某条内容适用人群为空，或者卖点正文超过 300 字，这些本该在写入模板时自动修复或报错，但我却让模型来“看情况处理”，白白多花 12 次请求。

5. 修正后的验收流程：从 92 次压到 5 次以内

经过这次血泪教训，我重构了整套验收流程。核心思路是：让模型只做生成，让脚本做校验、做修复、做格式统一。

5.1 用 JSON Schema 锁定输出

第一步，强制模型返回 JSON。在 prompt 里直接写明输出的 JSON 结构，比如：

{ "list": [ { "title": "string", "body": "string", "audience": "string" } ] }

然后我在代码里用 JSON Schema 校验，格式错误直接抛出，完全不消耗额外 token。只有字段内容本身出问题，才进入后续修复流程。

这样做的好处是：程序可以直接解析、直接校验、直接入库。你再也不需要为了“提取标题”这种操作去消耗一次模型调用。

5.2 确定性校验脚本前置

我写了一个简易校验脚本，检查每个字段是否为空、长度是否合规、是否包含违禁词、枚举值是否合法。脚本一次运行跑完所有条目，成本几乎为零。

凡是脚本判定失败的，自动进入修复队列。修复队列只提交“问题字段”，不提交整条内容。这样修复请求的上下文长度降到原来的十分之一，成功率反而提高。

5.3 修复请求实现局部化

修复 prompt 的模板我改成了：

你需要修复以下字段，只输出修复后的字段，不要输出其他内容。 字段名：body 当前值：这里是原来有问题的正文 修复要求：正文必须控制在 100 字以内，且不得包含感叹号。 输出格式：{"body": "修复后的正文"}

因为不需要模型回忆全局内容，所以每次请求消耗的 token 极少。而且模型的任务非常单一，输出格式也被限制，基本一次就能修复成功。

5.4 Checkpoint 与断点续跑

每处理完 5 条，就把结果保存到本地 JSON 文件，同时保存一条简短的“后续处理状态”。如果程序中途崩溃，下次启动直接读取最近一次 checkpoint，从断点继续。

这个设计让你永远不需要全量重跑，也让你每次人工介入时能精确看到问题批次，而不是大海捞针。

6. 常见问题速查表与避坑手册

这次踩坑后，我总结出了几个高频问题。如果你已经在做类似项目，可以对照排查。

6.1 避坑点一：千万不要让模型自己审核自己

我试过让模型“检查一下上一条输出是否合规”，结果它不仅没查出问题，还把合规的部分改掉了。模型的自我一致性能力，远没有你想象中可靠。审核类任务必须走确定性规则，比如长度、格式、黑名单、字段非空。如果规则太复杂，也应该把它拆成可量化的子规则，而不是丢给模型。

6.2 避坑点二：上下文长度是最大的隐藏费用

很多时候你以为自己只是发了一个简短的修改请求，但其实框架会自动携带历史消息。如果你使用的是带对话记忆的接口，那么历史越长，每个 token 的计费基数越大。解决方式是在请求时手动裁剪历史，只保留最近一轮的“用户指令和模型回复”，而不要把全量历史带进去。

6.3 避坑点三：多批次汇总对比时必须保存“元信息”

项目后期我想对比修复前后的统计，但我发现没有保存每一次请求的 prompt、响应、耗时、token 用量。结果只能靠猜。后来我在每次请求后都写一行日志，记录时间、prompt 的 token 数、响应的 token 数、耗时。这个日志在复盘时简直是无价之宝。

7. 写在最后的实操心得

我个人在实际操作中最深刻的体会是：在一个 LLM 驱动的流程里，最贵的资源不是时间，也不是钱，而是“流程中未定义的不确定性”。每一次“顺便让模型看着办”，都会变成一次不可控的 token 消耗入口。

如果你现在正要搭自己的 AI 批处理流程，你可以直接抄这份作业：

第一，所有请求必须带结构化输出格式，最好统一为 JSON。第二，所有校验必须脚本化，不依赖人眼。第三，所有修复请求必须单字段化，且不带冗余上下文。第四，每处理一步必须落盘 checkpoint。第五，每次调用必须打日志，记录 prompt 字数、响应字数、耗时、费用。

按这个思路重做之后，我处理同样规模内容的 token 消耗，从 1340 万降到不到 200 万。类型差不多的任务，请求次数也从 92 次降到个位数。这个数据不是模型变强了，而是我的验收流程终于不再“花钱买返工”。

最后再分享一个小技巧：如果你预算有限，或想让流程更稳，可以给自己设一个“token 红线”。每次调用前估算 prompt 长度和输出长度，超过预期就终止任务，检查 prompt 是否有冗余。控制住上下文，就控制住了成本；控制住流程，就控制住了质量。这两件事，才是 AI 项目里真正值得花心思的地方。