AI API 在你不再把它视为一个通用集成、而是开始将其映射到某个具体漏斗决策时，最容易评估。用于认知研究的正确用例，与用于入门、转化、留存或运营的正确用例并不相同。每个阶段都需要不同的输入、模型选择、工具界面、预算护栏和成功指标。
本指南为团队提供一种按漏斗阶段选择 AI API 工作流的实用方法。当你在决定先构建什么、哪个 API 界面更重要，以及如何判断一个原型是否值得进入生产流量时，可以使用它。
快速答案
当某个工作流需要语言理解、内容生成、检索、分类、提取、图像或视频生成，或者在产品或运营流程中需要工具调用时，使用 AI API。不要从模型排行榜开始。先从漏斗问题开始：
| Funnel stage | Business question | Useful AI API workflow | Metric that matters |
|---|---|---|---|
| Awareness | What should we learn from the market? | Research synthesis, topic clustering, competitive signal extraction | Useful findings per source reviewed |
| Evaluation | Which model or workflow should we trust? | Prompt tests, model comparisons, multimodal trials | Accepted output rate at target latency and cost |
| Activation | Can new users reach value faster? | Onboarding copilots, docs Q&A, setup assistants | Time to first successful task |
| Conversion | Can we reduce buying friction? | Proposal drafting, ROI explainers, qualification summaries | Qualified conversion assist rate |
| Retention | Can we keep customers successful? | Support triage, account summaries, usage-risk detection | Resolved issue time and churn-risk coverage |
| Operations | Can we govern spend and reliability? | Usage logs, quota checks, fallback reviews, key controls | Cost per accepted task and incident recovery time |
稀缺的不是调用模型。稀缺的是把 AI API 调用连接到一个可衡量、特定于阶段的决策上。
什么算作 AI API 用例？
AI API 用例包含四个部分：
- 一个可重复的输入，例如提示、对话记录、支持工单、产品事件、文件、图片或客户记录。
- 一个模型或工具动作，例如生成、提取、分类、检索、网页搜索、丰富、图像生成或视频生成。
- 一个受控输出，例如 JSON、排序列表、草稿、摘要、评分、媒体资源或推荐的下一步。
- 一个能告诉你结果是否足够有用、值得保留的指标。
这一定义很重要，因为它能防止团队推出含糊不清的自动化。一个好的 AI API 用例会说：“对于这个漏斗阶段，我们将把这个输入转换为这个输出，并用这个指标来评判它。”
如果你仍在选择访问层，架构选择是独立的。对于单一稳定工作负载，直接使用提供商 API 就足够了。当你需要多个模型、一个兼容 OpenAI 的基础 URL、路由、共享计费或按请求级别的用量审核时，AI API 网关会更有用。
认知：将市场噪音转化为可搜索信号
漏斗上游团队通常信息原始数据过多，而综合提炼过少。产品发布、竞品页面、社交帖子、评论、社区讨论串以及销售笔记中，都可能包含弱信号。AI API 可以帮助把这些材料转化为主题簇和问题。
适合认知阶段的用例如下：
- 从客户访谈、通话记录、评论、社区讨论串和搜索查询中进行主题聚类。
- 竞品发布监测，提取主张、定位、目标用户、定价线索和证据点。
- 为 GTM、内容、销售或产品研究生成带来源支撑的简报。
- 在内容日历最终确定之前，对关键词和问题进行分组。
衡量指标不应是“生成了多少字”。更好的认知阶段指标包括：源覆盖率、每个已审阅来源带来的有用发现数、去重率、引用接受率，以及简报实际改变了多少决策。
在这一阶段，你通常对 AI API 工具的需求和对文本生成的需求一样多。模型可以总结你提供的内容，但在模型对来源集合进行推理之前，工作流可能还需要搜索、浏览器、补充丰富或数据 API。
评估：基于真实工作而非演示来比较模型
评估是许多团队浪费时间的地方。他们拿通用提示词来比较模型，然后发现生产流量的表现并不相同。更好的AI API 评估用例，应从一小组真实用户任务和一套评分标准开始。
有用的评估阶段工作流包括：
- 对候选文本模型运行同一组提示词。
- 测试 JSON、函数调用、标签和摘要等结构化输出的可靠性。
- 针对品牌、速度和可编辑性需求比较图像或视频模型。
- 衡量当首选模型缓慢、不可用或对任务而言过于昂贵时的回退行为。
重要指标包括：可接受输出率、重试率、p90 延迟、每个可接受输出的成本、人工编辑时间以及失败类别。AI 路由 API 指标这篇文章更深入地介绍了这些运维指标。
这也是统一的AI API可以减少迁移工作的地方。Flatkey 的文档描述了一个兼容 OpenAI 的 REST API，地址为 https://router.flatkey.ai/v1，其 OpenAI SDK 指南展示了如何仅通过更改基础 URL 和 API 密钥，就把同一段请求代码指向 Flatkey。这让你在不重写整个客户端的情况下更容易测试模型选择。
激活：帮助用户完成首个有价值的任务
激活阶段的用例应该保持窄聚焦。目标不是因为别人都有聊天机器人就加一个。目标是帮助新用户以更少阻力完成第一个有价值的任务。
强有力的激活AI API示例包括：
- 一个设置助手，它读取用户陈述的目标，并推荐正确的初始配置。
- 一个文档问答界面，用相关文档链接回答实现问题。
- 一个代码或提示模板生成器，使用用户选择的框架、模型或环境。
- 一个首次运行检查清单，将模糊目标转换为一系列步骤。
跟踪首次成功完成任务所需时间、完成率、支持分流质量、幻觉报告，以及在首次生成结果后继续使用的用户占比。如果助手生成了流畅但无法推动用户前进的回答，这就不算激活成功。
Flatkey 的快速入门文档为开发者列出了几个入口点：纯 REST API、OpenAI SDK、Flatkey CLI，以及 coding-agent 设置。这类源材料对激活助手很有帮助，因为它让助手能够推荐路径，而不会编造不受支持的设置步骤。
转化：让技术购买更容易解释
转化阶段的 AI API 用例应减少不确定性，而不是制造紧迫感。对于技术产品，买家通常需要帮助把工作流转化为业务语言：预期用量、运营风险、采购要求以及实施工作量。
实用的转化工作流包括：
- 将调研记录总结为特定用例的实施需求。
- 为潜在客户偏好的技术栈起草技术评估计划。
- 基于已批准的输入和当前用量假设生成 ROI 或工作负载叙述。
- 在演示、试用或支持线程之后生成销售工程交接说明。
衡量指标应是辅助转化质量：创建了多少合格的下一步、节省了多少销售工程时间、需求是否被澄清、证明材料是否被复用，以及来回沟通是否减少。避免让模型编造价格、承诺、合规声明或客户参考。将这些字段保持为模板化、已提供来源或留空。
如果成本是购买对话的一部分，请将该工作流与真实计算器或用量数据配对。按漏斗阶段划分的 LLM 成本计算器 是一个有用的配套内容，可用于决定哪些成本假设应归入认知、评估、激活、转化和留存阶段。
留存：在摩擦演变为流失之前发现它
留存用例需要更强的防护措施，因为它们往往会接触客户历史、支持数据和产品使用情况。AI API 应帮助团队更早发现摩擦并保持一致地响应。
有用的留存工作流包括：
- 支持工单分诊和建议路由。
- 基于产品事件、支持备注和近期用量生成账户摘要。
- 基于已批准信号而非隐藏猜测解释流失风险。
- 按客户细分或产品模块个性化发布说明。
- 从重复出现但未得到解答的问题中检测知识库缺口。
衡量指标应与客户结果相关：更快的首次响应时间、更少的升级、更短的解决时间、关键功能采用率更高，以及账户负责人交接更清晰。如果工作流无法解释它为什么标记了某个账户或问题，那么它对客户成功来说就是有风险的。
这也是使用可见性变得重要的地方。Flatkey 的使用文档说明，团队可以查看包含模型名称、token 数量、每次请求成本、时间戳、密钥筛选和导出的请求日志。当团队试图将产品问题与模型、提示词、路由或预算问题区分开来时，这正是留痕和运营团队所需要的证据。
运营：将支出、密钥和可靠性控制在可控范围内
运营是决定一个 AI API 试点能否承受生产流量的阶段。一旦使用分散到不同功能、代理、环境或团队中，负责人就需要回答一些实际问题：
- 是哪一个密钥、应用或环境产生了这笔成本？
- 选择了哪个模型，它是否成功了？
- 哪些请求失败了、重试了或进行了降级回退？
- 开发测试是否在消耗生产预算？
- 财务能否在不要求工程临时导出日志的情况下对使用情况进行对账？
适合运营阶段的用例包括使用日志审查、API 密钥分段、模型白名单、月度上限、故障回退事件摘要以及按请求级别的账本导出。Flatkey 的 API key 文档建议按环境分配独立密钥、使用具有描述性的密钥名称、环境变量、定期轮换，以及在密钥泄露时进行吊销。
关键指标是每个已接受任务的成本，而不是每次原始请求的成本。失败重试、低质量输出和人工清理都应纳入真实成本模型。更多细节请参见 AI API 配额限制 指南。
如何选择你的第一个 AI API 工作流
在编写代码之前，请使用这五步筛选法：
- 选择一个漏斗阶段。不要在同一个试点中混合认知研究、入门和留存。
- 为工作流应改进的决策命名。如果没有决策，就没有用例。
- 选择最小的 API 能力面。仅当工作流需要时，再开始使用 chat、responses、embeddings、images、video 或 tools。
- 在测试前定义验收指标。可使用已接受输出率、节省时间、延迟、每个已接受任务的成本或已验证的交接质量。
- 确定运行时护栏。上线前规划 API keys、环境、配额、日志、回退行为和人工审核。
此时也正是决定直接接入提供商还是使用网关的合适时机。当一个模型、一个团队和一张账单就足够时，直接访问更简单。当工作流需要多个模型、共享使用审查、跨环境共用一个密钥，或为兼容 OpenAI 的客户端提供更清晰的迁移路径时，统一的 AI API 就更实用。
Flatkey 的适用场景
当 AI API 用例跨越多个模型、团队、工具或运行约束时，Flatkey 就会变得相关。当前的 Flatkey 文档说明了：
- 一个与 OpenAI 兼容的 API，地址为
https://router.flatkey.ai/v1。 - 使用 Flatkey API keys 的 Bearer token 身份验证。
- chat、responses、embeddings、图像生成、视频生成和 model-list 端点。
- 通过更改 base URL 和 API key 来配置 OpenAI SDK。
- 用于模型名称、token 数量、请求成本、时间戳以及按密钥筛选的使用日志。
- 通过 groups 进行的 API key 管理，用于独立环境、吊销和配额。
对于一个正在选择首个 AI API 工作流的团队来说，这些细节很重要，因为它们将构建决策与运营连接起来。你可以从单个阶段开始，测试真实任务，并在扩展之前评估输出、延迟、成本和治理是否足够好。
常见问题
什么是最好的首个 AI API 用例？
最好的首个 AI API 用例，是输入可重复、输出清晰且决策可衡量的那一种。对许多团队而言，这意味着评估阶段的提示测试或激活阶段的设置协助，因为这两类都可以严格限定范围。
AI API 用例应该从一个模型开始还是多个模型开始？
如果任务范围窄且稳定，就从一个模型开始。当质量、延迟、多模态能力或成本可能影响决策时，再比较多个模型。如果评估本身需要更清晰的路由、共享计费或一个 OpenAI 兼容客户端，则使用网关。
AI API 工具与模型 API 有何不同？
模型 API 负责生成或转换内容。AI API 工具负责执行动作或获取数据，例如搜索、浏览、补充信息或媒体工作流。许多生产场景都需要两者：工具收集上下文或对上下文采取行动，模型则对其进行推理。
在扩展 AI API 工作流之前，我应该衡量什么？
衡量已接受输出率、p90 延迟、重试率、每个已接受任务的成本、人工编辑时间以及失败类别。对于面向客户的工作流，还要衡量用户完成率、支持升级率和质量投诉。
团队何时不应使用 AI API？
当确定性规则、静态内容或普通数据库查询能更可靠地解决问题时，不要使用 AI API。如果工作流涉及敏感数据，但缺少关键控制、保留策略清晰度、日志、配额或人工审查，也应暂停使用。
最终检查清单
在发布 AI API 工作流之前，请确认：
- 漏斗阶段是明确的。
- 输入和输出是可重复的。
- API 面是能够解决该任务的最小面。
- 成功指标是阶段特定的。
- 成本指标包含重试、回退和人工清理。
- 密钥、配额、日志和所有权都已定义。
- 生成内容中不包含不受支持的定价、合规和性能声明。
AI API 本身并不是一种策略。只有当它绑定到某个漏斗阶段、以真实指标衡量，并以足够的可见性运行以持续改进时，它才会变得有用。
