快速找到所需文档，高效完成接入与排障

场景一：电商 / 导购 App —— 文本与图片两类能力并存

一款导购类 App 想在商品详情页加"问商品"入口，回答尺码、材质、发货这类高频咨询；同时希望运营侧能批量生成商品卖点文案，并为大促自动出一批海报底图。

需求勾选上，这个场景会选中「智能问答 / 客服对话」「文案 / 摘要 / 改写」「生成图片 / 海报」三项，平台把前两项映射到文本 / 对话生成，第三项映射到图片生成。策略可命名为"电商导购默认策略"，绑定导购 App 的 App Key。

这个场景需要特别注意接入方式的拆分。文本类的问商品与文案生成可以走 ADK，端侧不持有密钥；但图片生成当前仅支持 API 接入，且必须在调用时指定具体生成模型、不能用 model=auto。所以实际落地通常是两条链路：客户端问商品走 ADK，运营侧的文案与海报批量生成放在自建服务端走 API——批量生成任务本来也不适合放在端上跑。

平台在这里承担的是：问商品的对话请求在候选模型池中自动选路，某一家模型抖动或超时时自动切到备选，客户端不必为此写重试与降级逻辑；文本按 token、图片按张，统一在一个 credit 钱包里结算。

场景二：内容 / 社区 App —— 纯文本，适合 ADK 全托管

一款 UGC 社区想给发布链路加机器初审，同时给长帖自动生成摘要卡片、给帖子打标签用于推荐分发。

需求勾选「分类 / 打标 / 信息提取」和「文案 / 摘要 / 改写」两项，两者都映射到同一个基础能力——文本 / 对话生成。这里体现了一个容易被忽略的点：需求条目数不等于要对接的能力数，多个业务需求收敛到同一能力是常态，不会因为多勾一项就多一层接入成本。

因为全部是文本类能力，这个场景可以完整走 ADK：客户端只升级一次 SDK，以 App Key 加签名白名单换取凭证，动态 apiKey 由 SDK 自动刷新，端侧不存任何模型密钥。策略命名为"社区内容处理策略"并绑定 App Key 即可。

审核链路对可用性比较敏感——单一模型故障时若没有兜底，发布流程就会卡住。自动选路在这里的价值是让降级与熔断发生在云端：某个候选模型不可用时切换到池内其他模型，客户端无感知。

场景三：工具 / 办公 App —— 长文本为主，兼顾多端

一款文档工具想支持"上传合同 / 说明书后提问"，并对长报告做要点提炼；部分用户还会让它解释代码片段。

需求勾选「长文档 / 合同理解」和「复杂推理 / 代码」，分别映射到长文本理解与深度推理两类能力，各自对应不同的候选模型池——长文本侧重上下文长度，推理侧重逻辑与代码能力。这也正是"不用自己研究模型清单"的意义：同一个入口，平台按能力类型选路到相应的模型池。

这类产品通常不止 Android 一端。可行的做法是 Android 客户端走 ADK、Web 与桌面端由自建服务端走 API，两条链路共用同一个 credit 钱包结算。策略侧可以建两条：一条"文档助手 · 移动端"绑定 Android 的 App Key，一条留空 App Key 作为通用默认，供服务端链路命中。

还需要提醒成本结构：长文本类按 token 计费，单次请求的 token 消耗显著高于短对话。上线前建议先用小流量在「用量统计」核对真实消耗，再决定是否对输入长度做截断或分段处理。

场景选型速查