企业官网建设流程全解析

上个月我把一个用 AI API 搭建的内容生成工具推上线，前三天一切正常，第四天报警和账单一起到了。这个工具本身不复杂，就是把用户丢来的关键词扩展成营销文案和摘要，我原本以为最难的部分是把 prompt 写明白，结果从选 API 到计费，几乎每个环节都踩了一遍坑。这篇文章就把这段真实经历完整记录下来，崩溃现场、排查链路、最终方案都在里面。想做或正在做类似内容生成工具的朋友，可以参考一下，少走几段弯路。

1. 选 API 时只对比生成效果，结果在计费和限流上栽了跟头

1.1 我最开始的选择标准：谁的样例输出漂亮就选谁

很多人在选 AI API 时和我一样，第一反应都是拿几个稍微复杂点的 prompt 去试各家服务，谁生成的文案更通顺、更有创意，就选谁。我当时把市面主流的几家都试了一遍，最后选了一家输出质量最让我满意的。这个决策方式放在普通软件集成上没有太大问题，但在 AI API 这里就是一个陷阱，因为生成效果只代表了模型能力的上限，而真正决定工具能不能跑下去的是计费结构、配额限制和接口稳定性。

等我把工具做出来压测的时候才发现，输出质量好只是入场门槛，后面的隐性成本完全没有体现在那一轮测试里。比如同样是生成一篇 800 字左右的商品介绍，A 家中文 token 计价明显更贵，B 家虽然单次价格低，但每分钟能消耗的 token 总量卡得非常死，批量跑 200 条数据，跑到一半就开始拒绝服务。这时候再换 API 已经不是改一行 base_url 那么简单了，要考虑 prompt 兼容性、参数差异、返回格式，等于要重做一遍适配层。

1.2 计费规则远比模型榜单复杂：token 计价与输入输出差异

AI API 的计费单位是 token，不是字数，也不是字符数。这个很多人有概念，但真正算起来就会出偏差。token 是模型处理文本的最小单位，英文里一个单词通常对应 1 到 2 个 token，中文里一个汉字大约对应 1 到 2 个 token。听起来不复杂，但问题在于不同服务的 tokenizer 词表不一样，同样一段中文，在 A 家的计费器里可能算 1200 token，在 B 家可能算 1800 token。我最初用第三方 token 估算工具算预算，自以为留了 20% 的余量，结果上线后实际消耗比预估高了将近一倍。

还有一个容易忽略的点：输入和输出往往按不同单价计费，有些服务输入便宜输出贵，有些反之。内容生成工具的特点是输入不会太小，因为你要把背景资料、参考案例、风格要求都塞进 prompt 里，输出反而可能只要几百字。如果选了一家对输出计费特别高的服务，成本模型就会完全失控。我后来养成了一个习惯：每种候选 API 都要用一个真实业务场景分别估算输入 token 和输出 token 的月消耗，分别计价后再对比，而不是看单次请求便宜就拍板。

1.3 限流阈值不是看 RPM 就够，TPM 才是隐藏杀手

限流这个坑我是在压测阶段踩到的。文档上写的是每分钟允许多少次请求（RPM），比如某家是 60 RPM，我心想一秒钟发一个请求，怎么都够用了。结果跑到第十分钟，接口开始返回 429 限流错误。查了日志才发现，每家服务不仅有 RPM 限制，还有每分钟 token 消耗限制（TPM），两个限制是同时生效的，哪个先触顶就拦哪个。

我的内容生成场景里有不少长文本请求，一个 prompt 带 3000 字背景资料，再加 500 字参考案例，一次请求消耗 6000 到 8000 token。表面看一分钟 60 次请求远没超，实际上每分钟 token 消耗早就顶到 TPM 上限了。更麻烦的是，有些 API 的 TPM 配额是按账号共享的，如果同一个 key 被多个服务共用，别人跑一批大任务，你的请求也会被一起限流。到这一步我才明白：选 API 时必须把"单个请求的平均 token 消耗 × 峰值请求数"和限流阈值对照着算一遍，只看 RPM 永远是纸上谈兵。

2. Prompt 参数调优踩坑：temperature、截断和上下文窗口的组合拳

2.1 temperature 与 top_p：不是所有场景都适合"有创造力"

参数配置这个坑，本质上是"对照别人的配置抄作业"导致的。我一开始从网上找了一组据说通用的参数：temperature 设为 0.7，top_p 设为 0.9。刚开始跑娱乐向的文案生成确实还行，语气活泼、用词多样，但等工具要输出结构化摘要时，问题立刻暴露了：同样的输入，两次生成的关键结论可能完全不一样，摘要的核心数据有时保留有时丢掉，运营同事直接吐槽"这工具看起来不太聪明"。

实际上 temperature 控制的是输出随机性：值越低，模型越倾向于选概率最高的 token，输出越稳定；值越高，越容易选到冷门的词，发挥空间大但跑题风险也高。top_p 控制的是候选词的概率累计范围，相当于在 temperature 之上再做一次截断筛选。对内容生成工具来说，如果你的目标是稳定产出可用的初稿或摘要，temperature 调到 0.2 到 0.3 就足够了；只有当工具定位是创意写作、广告语脑暴这类需要发散产物的场景，才适合把 temperature 抬高。我后来把结构化生成任务的 temperature 固定为 0.2，创造性任务保持在 0.6 左右，输出质量立刻稳定了一大截。

2.2 max_tokens 截断：JSON 输出被硬切导致解析失败

另一个让我印象深刻的坑是 max_tokens 参数。这个参数控制的是模型本次输出补全的最大长度，达到上限后输出会被直接截断，而不是智能地写到一句话结束。我的工具需要模型返回严格 JSON 结构，包含标题、摘要、正文建议和关键词列表。最早我把 max_tokens 设为 1000，估算输出大概 800 token 够用。结果实际返回的 JSON 经常在某个字符串中间断掉，json.loads 直接抛异常，整条请求白费，还照样扣费。

这个问题比想象中常见，因为模型输出的 JSON 里包含大量字段名、引号、逗号和缩进，再加上回复开头偶尔会带一段说明文字，实际有效 token 消耗远高于你肉眼看到的字数。我后来把 max_tokens 设为目标输出的 3 倍，同时在 prompt 里明确要求"不要输出任何解释，直接返回 JSON"，并且增加了一个前置校准步骤：拿 50 条真实样本先跑一遍，统计实际输出 token 的分布，再反推应该设置的上限。这样做之后，截断率从 12% 降到了 1% 以下。

2.3 上下文窗口：长文档被静默截断，模型却一本正经给出答案

上下文窗口指的是模型单次请求能"记住"的文本总量，包括输入和输出。这个参数在选型时很容易被忽略，因为大部分示例 demo 都是短文本问答。我的工具有一个功能：从运营提供的调研文档里提取核心观点，生成周报摘要。有些文档光正文就有 1.5 万字，我原本以为直接把全文塞进 prompt 就好，结果模型输出的摘要非常"想当然"，连文档里根本没提到的结论都编出来了。

后来排查时才发现问题：请求里的长文本超过了模型上下文窗口的可用空间，系统内部做了截断，模型实际上只看到了文档开头的一小段内容，后面全是"瞎猜"。更坑的是，这个截断是静默发生的，API 不会给你任何告警。这件事给我的教训是：在做长文本处理前，必须先确认上下文窗口能容纳完整输入加输出，如果不能，要么把文档切段后分批处理再合并，要么先让模型提取每段核心要点，最后再做一次全局综合。我最后选了分段提取方案，虽然请求次数变多，但至少每一条结论都有真实的输入依据。

3. 上线当日限流崩溃：并发、超时与重试的完整排查链

3.1 我的并发设计错误：把 API 当成普通数据库来压

工具上线前我做了一次简单的并发测试，开了 50 个线程同时打请求，结果不到 30 秒，大量请求开始报 429 限流错误。最初的排查方向完全错了，我以为是自己机器带宽不够，或者线程池配置有误，花了大半天检查网络和连接池。后来打开 API 控制台看配额监控，才发现问题根本不是本地：50 个线程虽然没超过 RPM 限制，但每个请求都带着长 prompt，合计 token 消耗瞬间冲破了 TPM 配额。

设计并发时不能把外部 AI API 当成普通接口去压，它的核心瓶颈不是连接数，而是 token 消耗速度。后来我改成了"全局信号量 + 配额预估"的双层方案：信号量控制最大并发不超过 10，发请求前先用预估函数算一下本次请求的 token 消耗，如果累计消耗接近 TPM 限额的 60%，就暂时阻塞新请求进入队列。这个方案相当于在代码里做了两套限流：一套管数量，一套管 token 预算，实测下来限流报错率从高峰期的 35% 降到了 2% 以内。

3.2 超时设置的两难：3 秒误杀和 30 秒雪崩

超时时间的设置，是这类工具里最容易忽略但影响最大的参数。第一次压测后我习惯性地把请求超时设为 3 秒，理由是"外部 API 就该快速响应，慢就是有问题"。这个判断在普通 HTTP 接口上勉强成立，但在 AI API 上完全行不通。内容生成是异步式计算，长文本生成本身就可能花 15 到 30 秒，3 秒超时导致大部分正常请求被误杀，前端大量报错，用户体验极差。

后来我把超时放宽到 30 秒，短暂恢复了正常，但紧接着又踩了第二个坑：当 API 服务端出现波动时，所有请求都在等待超时，线程池被慢请求占满，新的请求根本排不进去，形成雪崩效应。最后的方案是分级超时：连接超时设 5 秒，读超时设 30 秒，整体上限 45 秒，同时用超时队列和 CompletableFuture 的 orTimeout 机制做细粒度控制，再配合信号量保证线程池不被长请求占满。经历过这一轮后，我对"超时时间越长越好"这个直觉产生了免疫力：超时策略必须和并发策略联动设计，单独调其中任何一个都是在埋雷。

3.3 重试加重灾难：429 之后疯狂重试形成自我攻击

最离谱的一段经历发生在限流高峰期。当时有一个批处理任务，需要连续处理 200 条内容，跑到第 80 条时开始出现 429 限流错误。我当时的重试逻辑很简单：报错就立即重试，最多重试 5 次。结果 429 没有变少，反而越来越多，甚至开始出现 500 服务器错误。现在回头看，这个逻辑本质上是在被限流时还拼命往服务端加压，属于自我攻击型设计。

正确的做法是重试必须搭配退避策略。我后来实现了一套指数退避算法：第一次失败等待 1 秒、第二次等待 2 秒、第三次等待 4 秒，每次都加上一定随机抖动，连续失败超过 5 次就直接放弃这条请求，转入手工队列。加了这几行代码之后，限流报错率肉眼可见地降了下来。顺带提一句，HTTP 错误码也要关注：429 代表"你请求太多"，4xx 客户端错误重试没有意义；5xx 服务端错误才值得退避重试。如果不对错误码分类就盲目重试，等于把系统的不稳定因素放大到自己这边。

3.4 最终方案：信号量限流、指数退避与分优先级

经历了上面几轮崩溃后，我重新设计了调用层的完整架构，这套组合拳目前还在沿用。第一层是信号量限流，全局最多同时 10 个请求在途；第二层是 token 预算计数器，每次请求前估算消耗，接近配额上限时排队；第三层是分级超时，连接 5 秒、读取 30 秒、整体 45 秒；第四层是重试策略，对 429 和 5xx 做指数退避，限制最大重试次数。另外还加了一个不起眼但很管用的改动：把批处理任务拆成小批次，每批 20 条，批次之间休息 5 秒，给配额留出恢复时间。

这套方案听起来不复杂，但每一层都是真实踩坑换来的。如果你在做类似的 AI API 集成，我不建议直接照抄参数，因为不同服务商的配额规则差异很大，但建议一定把"限流层-超时层-重试层"拆成三个独立的模块来设计。三者一旦耦合在一起，排查问题时会非常痛苦，你会分不清到底是被限流了、超时了、还是重试机制把自己打挂了。

4. 输出质量不稳定：内容工具的隐形成本与校验兜底

4.1 同样的 prompt 出来的东西不一样：随机性管理的必要性

内容生成工具和传统软件最大的区别在于：同样的输入，输出天然具有随机性。即便把 temperature 调到非常低，也不能保证两次结果逐字一致。这个问题在 demo 阶段不明显，甚至看起来是"灵活"，但真实业务场景里会造成一连串麻烦：运营拿到两条不同版本的摘要，不知道该以哪条为准；自动化流程里，下游系统解析关键字段时，必须兼容字段时有时无的诡异情况。

我一开始天真地认为"模型生成了什么，就存什么"，后来发现这是对自己的不负责。应对随机性不能靠信任，只能靠约束：把 prompt 写得足够结构化，明确要求关键字段必须出现；准备好自动化测试样本集，每次调整 prompt 后跑一遍，对比字段完整率和语义准确率；条件允许时，固定随机种子可以让部分服务端输出变得更可复现，不过这个特性不是所有服务商都支持，需要查阅对应文档确认。内容生成工具的稳定性，本质上不是靠模型，而是靠外层机制去兜底。

4.2 模型不一定按约定返回：JSON 外衣下的脏数据

我在 prompt 里明确要求"只返回 JSON，不要解释"，但真实情况下模型还是会偶尔在 JSON 前面加一句"好的，这是你要的内容："，或者用 markdown 的代码块把 JSON 包起来。最开始我直接在返回结果上做 json.loads，遇到这种脏数据就抛异常，整个任务失败。后来我在解析层加了一个清洗函数：先把返回内容中的 markdown 代码块标记去掉，再找到第一个 { 和最后一个 } 之间的内容作为候选 JSON 字符串，然后才交给解析器。

这一步虽然只有十几行代码，但把失败率从 8% 降到了几乎为零。更进阶一点的做法是：把清洗后的结果再做一次字段校验，确保标题、正文、关键词这些核心字段都存在且类型正确。不要相信模型输出一定符合 schema，这是做 AI 应用最基本的心态。只要有一次生成结果带走了整条流程，你就会明白这层兜底到底有多值钱。

4.3 校验、重试与兜底模板：我最后悔没早做的一层

最开始我的流程是"调 API -> 拿到结果 -> 直接入库"，非常单纯，也非常脆弱。踩了几次脏数据之后，我加了一条完整的质量守护流水线：先做格式清洗，再做字段校验，然后做长度和敏感内容的基础检查，全部通过才入库。校验不通过时，先重试一次并稍微调整 prompt 措辞，比如在句尾强调"严格按 schema 返回"；如果重试还失败，就转到一个兜底模板，用规则拼一条结构完整但没有模型内容的默认输出，让流程可以继续跑下去。

这套机制上线之后，我的工具才第一次真正意义上"可用"。之前那种裸调 API 的方式，一旦遇到模型抽风，整个任务就卡住，永远拿不到结果。现在我宁愿让用户看到一条朴素的兜底内容，也不想让整条流水线因为一条脏数据瘫痪。内容生成工具最怕的不是模型能力不够，而是没有应对"模型发挥失常"的措施，这句话是我这段时间最深的体会。

4.4 引入人工确认机制：机器生成加人工修正

纯自动生成在内容类工具里并不总是最佳实践，至少在我的用例里不是。后来我把工具改成了"AI 生成初稿 -> 人工确认或修改 -> 发布"的流程，运营同事反馈反而更好用了。原因是：模型生成的内容经常在细节上需要微调，比如产品名词的准确度、价格信息、活动时间的表述，这些是模型最容易出错的地方。机器负责把 80% 的重复劳动做掉，人只需要处理剩下的 20% 决策和校对工作。

这一步调整虽然让工具看起来没那么"自动"，但实际业务价值反而更高。对内容生成工具来说，"全自动"不是目标，"让人更轻松地完成内容工作"才是。如果你也在做类似方向，强烈建议在设计产品流程时就把人工确认环节考虑进去，不要迷信全自动生成。人机配合的稳定性，远高于纯机器运转。

5. 账单失控与成本治理：token 认知偏差、缓存和降级

5.1 token 估算偏差：中文场景下预算翻倍的真相

上线的第十天，我看到了第一份完整账单，金额比我预估的高了快一倍。翻明细的时候人都是懵的，想不通明明每天跑的量不多，钱怎么烧得这么快。后来逐条对比才发现问题出在 token 估算上：我开发时用的在线 token 计算器针对英文场景比较准确，但中文文本在不同服务上的 token 消耗差异极大，有的服务中文字典对常用字合并得比较充分，有的服务一个字就要算两三个 token，乘以每月数百万字的处理量，误差立刻变成真金白银。

从那之后，我给自己定了一条规矩：每条 API 接入前，都必须拿真实的业务语料跑一轮计费测试，统计平均输入 token 数、平均输出 token 数和单条成本，然后再推算出全量运行的成本模型。这个步骤虽然要花几个小时，但远比事后看到账单再补救要靠谱。建议所有做内容生成工具的朋友，在上线前一定花时间做一次"单条成本乘以预估调用量"的计算，这一笔账算不清，后面毛利都是负数。

5.2 缓存策略：重复请求在白白烧钱

有一段时间我发现成本居高不下，但用户量并没有显著增长。看了日志才注意到一个哭笑不得的事实：运营人员在调试同一个商品文案时，同一个请求反复提交了将近 20 次，每次都完整调了一次 API，每次都产生了费用。这类问题在内容生成工具里太常见了，因为用户经常会微调一个词就重新生成一次，而大部分内容框架是完全一样的。

解决方案是引入缓存层。最基础的版本是以"用户 ID + 输入文本 + 主要参数"拼接哈希作为缓存键，完全相同或高度相似的请求直接返回历史结果，不再调 API。再进阶一点，可以做语义缓存，用文本向量相似度去匹配近似请求，相同主题的改写请求也能命中缓存。我目前只做了第一层精确缓存，费用已经下降了约 30%。如果你对成本敏感，这层投入的性价比极高，几乎是所有成本治理手段里见效最快的。

5.3 降级策略：不是所有需求都需要大模型

在使用 AI API 的过程中，我逐渐意识到一个反直觉的事实：不是所有内容请求都需要调用大模型。比如我的工具里有一个短标题生成功能，输出只有几个字，但如果每次生成都走大模型，单价和耗时都不划算。后来我把这部分需求拆出来，用一套简单的规则模板加同义词替换就能完成，只有标题确实需要创意突破时才升级去调大模型接口。

这套"分级降级"思路非常值得推广：在工具设计阶段，把需求分成简单规则可完成、中等复杂度适合小模型、高复杂度需要大模型三个档次，每个档次走不同的处理路径。这样既能保证效果，又能让成本结构变得更可控。我调整之后，低复杂度请求直接走规则引擎，大模型调用量下降了约四成，整体响应速度也变快了。成本治理从来不是靠压低模型质量，而是靠合理分配计算资源。

五段写下来，差不多把我这一个月踩的坑翻了个底朝天。最后再分享一点我的个人体会：AI API 本质上是一个能力很强但稳定性远不如传统接口的外部依赖，你必须用对待"高性能但偶尔抽风"的合作者的态度去设计你的系统。我最后悔的一件事，就是把全自动生成当成核心卖点，导致前期没有预留校验和人工确认环节。如果让我重新做一遍，我会优先把质量兜底、成本监控和降级路径做扎实，再考虑扩展更多生成能力。工具能稳定跑下去，永远比功能炫酷更重要。