做产品规划或接需求时，很容易把所有东西都叫成「上个 AI」：聊天窗口、文档问答、会调工具的助手、批量跑图的流水线，名字一样但工程量和花钱方式差得远。这篇把常见的大模型应用形态按交互方式和输出物分几类，每类讲清什么场景适用、什么情况下不适用、上手先确认哪几件事，最后给一份从需求到形态的对照表和排查顺序，不涉及具体报价，价格口径到站内页面核对。
做产品规划或接需求时，很容易把所有东西都叫成「上个 AI」：聊天窗口、文档问答、会调工具的助手、批量跑图的流水线，名字一样但工程量和花钱方式差得远。先分清形态，再谈选型，能省掉一半返工。
这篇按交互方式和输出物把常见形态分几类，每类讲清什么场景适用、什么情况下不适用、上手先确认哪几件事，最后给一份从需求到形态的对照表和排查顺序。不涉及具体报价，价格口径到站内页面核对当时的数字。
先把应用形态分成几类
最省事的分类维度是两个：用户是问一次拿结果，还是持续在同一上下文里来回；输出物是纯文字，还是带结构化字段或多媒体产物。这两个维度一交叉，大部分需求都能落到下面几类里，别急着上最复杂的那种。
- 任务型问答与文案生成
- 一次输入一次输出，不保留上下文，适合摘要、改写、分类、抽取字段
- 多轮对话助手
- 同一会话里带着历史来回，需要管会话状态和上下文长度
- 检索增强的知识问答
- 先查内部资料再让模型组织答案，适合文档库、客服知识库
- 会调工具的执行型助手
- 模型决定调用哪些外部接口，能查数据、下单、发消息
- 批处理流水线
- 离线批量翻译、打标、转写、出图，不追求实时交互
- 判断口径：先看用户是「问一次拿结果」还是「持续在同一上下文里来回」，前者优先按任务型接口设计，后者才考虑会话和记忆
- 输出物越复杂，验证和成本估算的难度越高；纯文字好抽检，图文音视频要单独定验收方式
- 不适用情形：只需固定规则就能完成的流程，用大模型反而增加不确定性和排查成本，别为了「有 AI」硬套
- 同一产品里可以混用多种形态，但建议一次只上线一种，否则出问题时分不清是哪层的锅
按预算和部署边界挑形态
形态不是按喜好挑的，是被约束筛出来的。先定三条硬约束：数据能不能出内网、延迟能忍多少、每天调用量级多大。三条里有一条卡死，可选形态会砍掉一大半，剩下的再谈体验。
| 硬约束 | 卡死时的优先形态 | 要确认的事 |
|---|---|---|
| 数据不能出内网 | 本地或私有化部署的检索问答、批处理 | 模型权重放哪、谁维护、更新频率 |
| 延迟要求苛刻 | 单次调用的任务型接口，少串链路 | 一次请求要串几次模型调用，能不能砍掉 |
| 调用量很大 | 批处理或缓存命中率高的形态 | 重复请求能不能复用结果，缓存策略谁来定 |
| 预算固定且有限 | 先用最小形态跑通，再决定是否加检索 | 到站内页面核对当时的单价和额度口径 |
延迟这条最容易被低估：客服、语音对话这类场景，用户等的是秒级反馈，一次请求里串三次模型调用就很难压住响应时间。把链路画出来，标上每步的耗时预期，再决定要不要合并步骤。
拿不准就把候选形态列成两列，到 开源模型比价（/inference） 与 官方 API 价格（/official-api） 页面按当时的数字核一遍再定。这两处的数字会变，看的是当时口径，不是记下来的旧值。
不同形态的成本结构差别在哪
成本通常来自三块：模型调用或算力、检索与存储、人工校验。三块的比例因形态而异，搞错重点会一直优化错的地方。批处理形态省在调用便宜，贵在结果没人看就得整批重跑。
- 长上下文和多轮对话会把每次请求的输入量放大，同一句话问第三遍时，账单和第一遍不是一个量级
- 会调工具的形态要多算一层：工具自身的调用次数、失败重试、超时兜底，往往比模型本身更影响总账
- 检索增强形态的隐性成本在索引维护，文档更新了索引没跟，答案错得还很自信
- 人工校验是很多团队漏算的一项，抽检工作量要提前排进人力，不然上线后没人管质量
- 具体单价和额度以站内当时数据为准，可到 模型成本计算器（/tools/model-cost-calculator） 和 价格变动追踪（/price-watch） 对照
一个常见误区是只盯模型单价。中转或私有化场景里，算力、存储、运维人力经常才是大头，模型单价只是其中一项。做预算时把这几项分开列，别合成一个总数糊过去。
从需求到上线的排查顺序
- 写清输入和期望输出包括失败时返回什么，别只写「要理解用户意思」。输出格式写不出来，说明需求还没想清。
- 选一个最小形态跑通端到端哪怕只是单轮问答调一次接口，先证明链路能通，再谈加检索、加工具。
- 补验证抽一批真实样本人工过一遍，确认可接受率，再决定是否加检索或换模型。
- 扩容和加功能同时定好回退方案，模型或形态换掉时旧流程还能兜住。
# 上线前自检顺序（照着问自己）
1. 输入输出的格式写清楚了吗？失败返回什么？
2. 最小链路跑通了吗？串了几次模型调用？
3. 抽检样本过了吗？可接受率够不够上线？
4. 成本三块（调用/检索/人工）谁占比最大？
5. 出问题时的回退路径是什么？谁负责切？这套顺序的好处是每一步都能独立验证，出问题时不至于全盘排查。小团队尤其别跳过第二步，直接奔着最复杂形态搭，后面改起来就是重做。
挑选型和上线后盯着数字时，中转可信度和价格变动也要留意，这些到 中转站导航（/sites） 和 可信度排行（/rankings） 看当时的结论，别用别人嘴里的旧印象。
下一步把候选形态按约束表过一遍，再到站内价格与可信度页面核对当时的数字，比在群里问「哪个便宜」靠谱得多。→常见问题
大模型应用是不是都得做成聊天窗口？
不是。聊天窗口只是交互外壳，很多场景用表单、按钮或定时任务更合适。判断标准是用户是否需要连续追问同一话题；如果每次任务相互独立，做成固定输入输出的任务型接口更省成本也更好排查。
小团队应该先做哪一类应用？
通常先从单轮、输出文字或结构化字段的任务起步，链路短、验证快。等这批任务的可接受率稳定了，再考虑加检索或工具调用。一上来就做会调多个工具的智能体，出问题时很难分清是模型、提示词还是工具环节的锅。
怎么判断某类应用适不适合接大模型？
看三件事：任务答案是否有多种可接受写法、错误代价高不高、有没有现成的校验手段。答案唯一且有严格规则的任务，用传统程序更稳；输出开放、错了人能一眼看出来并能改的，才适合交给模型。
