很多人第一次接生成式 AI，是照着示例跑通了一个接口，然后就卡住了：效果忽好忽坏、成本算不清、换模型不知道改哪里。问题通常不在代码，而在于没分清这条链路里哪一段是「模型的活」、哪一段是「你的活」。这篇按工程顺序拆一遍：从一次生成到底发生了什么，到怎么定参数、怎么验证、怎么留退路，每一步都给可执行的动作和判断标准。
很多人第一次接生成式 AI，是照着示例跑通了一个接口，然后就卡住了：效果忽好忽坏、成本算不清、换模型不知道改哪里。问题通常不在代码，而在于没分清这条链路里哪一段是「模型的活」、哪一段是「你的活」。
这篇按工程顺序拆一遍：从一次生成到底发生了什么，到怎么定参数、怎么验证、怎么留退路，每一步都给可执行的动作和判断标准。看的时候可以对着你手上那条链路走一遍，哪里说不清楚，那大概率就是下次出问题的地方。
先搞清楚一次生成到底发生了什么
把一次调用拆成四段：输入被切成 token、模型按上下文逐词预测、采样策略决定挑哪个词、输出再拼回文本。这四段出问题的表现完全不一样——切分出问题是长文本被截断或语义断在奇怪的位置，预测段出问题是答非所问，采样段出问题是同一问题两种口径，拼回段出问题是格式乱、尾部残缺。排查时先定位是哪一段，再动手改。
- token 切分
- 输入先被切成模型认识的片段，长度限制按切分后的数量算，不是按字数算
- 逐词预测
- 模型每次只决定下一个片段，再把它拼回上下文继续预测
- 采样策略
- 从概率分布里挑哪个候选，决定结果的随机程度
- 上下文窗口
- 一次能带进模型的历史长度上限，超了要裁剪或摘要
预测是概率性的，所以「同样的输入结果不同」是默认行为，不是 bug。要稳定就得靠参数收紧、结构约束或后处理，而不是反复重试碰运气。上下文长度、温度、top-p 这些名词别凭印象用，到 /ai-dict/category/basics 和 /ai-dict/category/tech 对一遍定义再动手，很多「玄学问题」其实是名词理解偏了。
参数与提示词的调法：先定约束，再调手感
调参顺序建议：先固定输出格式与长度上限，再调温度类随机性参数，最后才动提示词措辞。顺序反了会一直归因错——你以为是措辞问题，其实是随机性太高，改十遍提示词也没用。
- 锁格式先规定必须返回什么结构（字段名、类型、是否允许空），用解析器验证一遍，跑不通就先别往下调
- 收随机性把随机性参数往下压，跑同一批输入看输出是否收敛；不收敛说明任务本身不适合强约束，得换思路
- 改措辞在前面两步稳定后再动提示词，每次只改一处，两版并排跑，别一次改五个地方
- 留对照集同一批输入跑两版配置，人看一眼差异；对照集别只用顺利的样例，要放几条边界输入
把「必须满足的条件」写成硬约束（字段、枚举、长度），把「风格偏好」留给提示词描述，两者混在一段话里最容易失控。硬约束能用代码校验的，就不要指望模型自觉。
成本、延迟与并发：把账算在动手之前
先量基线再优化。用 /tools/speed-test 测出你这条链路的首字延迟和整体耗时，否则优化方向全靠猜——很多时候用户感知的「慢」是首字延迟，不是总时长，优化点完全不同。
| 观察到的现象 | 优先怀疑 | 先做的动作 |
|---|---|---|
| 整体很慢但单次调用正常 | 链路里有串行步骤 | 画出调用时序，找出能并行的那一环 |
| 偶发超时、失败率不高 | 重试与排队叠加 | 看重试策略是不是放大了压力，加退避与上限 |
| 成本超预期 | 输入长度过大 | 统计输入片段长度分布，看能不能裁历史或摘要 |
| 并发上不去 | 外部依赖或限流 | 分清是模型侧限流还是你自己的下游卡住 |
成本按「输入长度乘次数加输出长度乘次数」估算，长上下文任务往往是输入那头在烧钱，别只盯输出。具体单价与档位随厂商调整，别记死数字，到 /official-api 和 /tools/model-cost-calculator 按当时的数字算，顺带看看 /price-watch 的价格变动记录。
- 先量基线：首字延迟和总耗时分开看，别混成一个数
- 再拆链路：找出串行步骤和重试放大的地方
- 最后算账：输入、输出、重试各占多少，按 /official-api 当时的数字核
- 换模型前先记一份当前配置的对照结果，不然换完说不清哪个更好
上线前后的验证与退路
上线前至少过三关：格式合规率、事实性抽检、异常输入不崩。三关各自留一份可复现的输入集，别人接手或者半年后回看，还能跑同样的验证。
| 关卡 | 看什么 | 不通过时怎么办 |
|---|---|---|
| 格式合规 | 结构化输出能否被解析器稳定吃下 | 先收随机性、再加校验与重试 |
| 事实性 | 抽检关键结论是否站得住 | 缩小模型职责，把事实来源换成检索或人工确认 |
| 异常输入 | 空值、超长、乱码会不会直接崩 | 在调用前加输入清洗与长度截断 |
| 成本与延迟 | 是否落在你能接受的范围内 | 按 /tools/model-cost-calculator 复算，再决定裁剪或换档 |
把模型调用包一层，记录输入摘要、耗时、返回状态。出问题时先看日志分布，再看单条案例，顺序不能反——先盯单条容易被个案带偏。
- 准备好降级路径：主模型不可用或超预算时切哪个备选，提前写进代码而不是临时改
- 确认切换后哪些输出格式会变，解析逻辑能不能兼容
- 准备人工兜底入口，模型给不出结果时用户不至于卡死
- 上线后定期回看失败样本，别只看成功率的数字
常见问题
不做微调，只靠提示词和检索能不能撑住一个业务场景？
多数场景能。判断标准是：错误是否集中在「模型没这类知识」还是「模型不听格式要求」。前者用检索补资料通常有效，后者靠提示词与输出校验解决。只有当同一类错误在大量样本上稳定复现、且补资料也没用时，再考虑微调。那条路的准备工作可以对照 /stacks/fine-tuning 里的服务商目录了解。
生成式任务效果不稳定，第一步该查什么？
先分清是输入分布变了还是输出采样在抖。做法是把同一批输入连跑几次，看结果差异是集中在个别样例还是普遍发散。普遍发散就收紧随机性参数；集中在个别样例，多半是那几条输入触发了上下文截断或格式冲突，回到输入那头处理。
怎么判断现在这套配置还值不值得继续优化？
设一个够用线：格式合规率和人工抽检通过率达到业务可接受的水平就停手。继续抠的收益通常小于把同样的时间花在补输入质量、加校验兜底上。真要看横向差异，到 /benchmarks 挑贴近你任务的榜单看，别拿通用排名当结论。
