Prompt 到 API

3.1 Demo 的价值是验证可能性，上线的要求是验证稳定性#

很多团队第一次做大模型功能时，最容易被 Demo 误导。产品经理写一个 Prompt，把用户输入粘进去，模型生成了一段看起来不错的内容，于是团队会觉得“这个功能可以做”。这个判断只完成了第一步：证明模型在某些样本上有可能给出有价值的结果。

但真实上线要求完全不同。上线不是问“模型能不能答对这一题”，而是问：

• 它在 1000 个真实用户问题里能稳定答对多少？

• 它在边界问题、脏数据、缺失数据、恶意输入下会怎样？

• 它回答错时，业务损失是什么？

• 它能不能给出可解释的依据？

• 它的成本是否低于业务收益？

• 它的延迟是否符合当前页面体验？

• 它能不能被监控、回滚、灰度和复盘？

• 它的 Prompt、模型、知识库、规则更新后能不能回归测试？

如果这些问题没有答案，Demo 就不能直接进核心链路。它可以进入内部试用、运营辅助、人工审核前置、低风险灰度，但不应该直接承担高风险决策。

从项目管理看，AI 功能的复杂度不在“调接口”，而在不确定性治理。传统规则系统失败时通常比较可解释：规则没覆盖、数据没同步、接口异常。大模型失败时更复杂：可能是 Prompt 不清楚，可能是模型能力不足，可能是上下文太长导致关键信息被稀释，可能是检索召回错了，可能是输出格式不稳定，可能是用户问题本身缺信息，也可能是模型在没有依据时编造了答案。

所以，产品负责人需要把 AI 功能从“单点能力”拆成一条完整链路：

1
业务目标
2
-> 用户场景
3
-> 输入来源
4
-> Prompt 结构
5
-> 模型选型
6
-> API 编排
7
-> 工具 / 数据依赖
8
-> 输出格式
9
-> 评估集
10
-> 风控和降级
11
-> 监控和日志
12
-> 成本预算
13
-> 灰度上线
14
-> 持续迭代

这条链路任何一环缺失，都会在上线后变成问题。Prompt 写得好但没有评估集，改一次就不知道质量是否下降；模型能力强但没有成本归因，增长一放量就超预算；API 能返回答案但没有错误码和日志，线上问题无法定位；输出很漂亮但没有业务指标，团队无法判断是否值得继续投入。

3.2 Prompt 不是文案，而是 AI 功能的行为协议#

第 2 周最重要的认知之一，是不要把 Prompt 当成“给模型看的文案”。Prompt 更像一份轻量行为协议，它定义了模型在某个场景下应该扮演什么角色、使用什么信息、完成什么任务、遵守什么边界、输出什么格式、遇到异常时如何处理。

一个可上线 Prompt 至少要回答 8 个问题：

这会改变产品和研发的协作方式。以前产品可能只写“系统自动生成客服回复”。现在必须写清楚：什么情况下生成，生成前需要哪些字段，是否允许引用优惠承诺，是否必须给出政策来源，是否需要输出置信度，是否能直接发给用户，低置信度是否进入人工审核。

Prompt 进入工程系统后，还必须版本化。一个 Prompt 的变化可能像代码变更一样影响线上行为。比如客服 Prompt 中把“语气友好”改成“尽量安抚用户”，模型可能更容易给出额外补偿承诺；把“回答必须基于政策”删掉，模型可能开始编造流程；把输出格式从自然语言改成 JSON，前端解析就会依赖字段稳定性。

因此，Prompt 的管理至少要有：

• 版本号：例如 customer_refund_reply_v1.3。

• 适用场景：退款政策解释、物流催促、发票问题。

• 输入字段定义：字段名、类型、是否必填、来源系统。

• 输出结构定义：字段、类型、枚举值、最大长度。

• 测试集：覆盖正常、边界、异常、高风险样本。

• 发布记录：谁修改、为什么修改、影响范围。

• 回滚机制：新版本失败时回到旧版本。

这就是为什么 Prompt 工程不是“写得聪明”，而是“写得可维护、可复测、可协作”。

3.3 模型选型不是排行榜决策，而是业务约束决策#

很多团队选模型时会问“哪个模型最强”。这个问题不够准确。真实项目里要问的是：在这个业务场景、这个成本预算、这个延迟要求、这个合规约束下，哪个模型最合适。

例如：

• 商品标题生成要求低成本、高并发、格式稳定，不一定需要最强推理模型。

• 合同风险摘要要求长文档理解、引用准确、风险谨慎，不能只看生成流畅度。

• 客服回复要求中文口语、政策忠实、情绪处理、低延迟和人工接管。

• BI 经营分析要求结构化数据理解、计算准确、解释清晰，必要时要工具调用。

• 企业内部知识问答要求权限隔离、引用资料、拒答能力和私有化部署可能性。

模型选型要进入产品方案，而不是只留给技术团队。因为模型选择直接影响用户体验、成本结构、商业模式和上线节奏。

一个实用的选型矩阵应包含：

产品负责人需要推动“多模型策略”而不是“一把梭”。简单任务用规则、缓存或小模型；复杂任务用强模型；高风险任务用模型辅助加人工确认；供应商异常时有备用模型；成本超阈值时有降级策略。

这不是过度设计。只要 AI 功能进入增长入口或核心业务链路，模型不可用、成本上涨、延迟波动都会变成业务风险。模型选型不是一次性采购决策，而是持续运营决策。

3.4 API 产品化让 AI 能力从个人实验变成组织资产#

Day 12 的重点是 API 产品化。它解决的问题是：当多个业务都想用 AI 时，不能让每个团队各自写 Prompt、各自调模型、各自处理错误、各自记录日志。

没有 API 产品化时，组织里会出现很多小型 AI 烟囱：

• 商品团队一套文案生成 Prompt。

• 客服团队一套回复 Prompt。

• 运营团队一套活动文案 Prompt。

• 销售团队一套客户跟进 Prompt。

• 数据团队一套经营分析 Prompt。

短期看很快，长期看不可治理。没有统一的鉴权、限流、日志、成本归因、错误码、Prompt 版本、模型路由和安全策略，任何一个业务放量都可能打穿预算，任何一个 Prompt 修改都可能影响线上质量，任何一个模型异常都可能让业务团队无法定位责任。

AI API 产品化的核心是建立 AI 编排层：

1
业务系统
2
  |
3
AI API 网关
4
  |-- 鉴权
5
  |-- 限流
6
  |-- 成本归因
7
  |-- 日志追踪
8
  |
9
AI 编排层
10
  |-- Prompt 版本
11
  |-- 模型路由
12
  |-- 上下文组装
13
  |-- 工具调用
14
  |-- 输出校验
15
  |-- 风控拦截
16
  |-- 降级策略
17
  |
18
模型和数据层
19
  |-- 大模型 API
20
  |-- 小模型
21
  |-- 知识库
22
  |-- 业务系统

这套结构的商业价值很明确：它把 AI 能力从一次性项目变成可复用平台。客服、商品、运营、销售、知识库都可以复用同一套鉴权、日志、模型路由、成本看板和评估框架。团队的后续创新速度会变快，同时风险可控。

对项目负责人来说，API 产品化也能降低跨团队沟通成本。业务团队只需要说明场景、输入、输出、指标和风险；AI 平台团队负责统一能力；数据团队提供字段和权限；运营团队维护知识和话术；风控法务定义边界。每个团队职责更清楚，项目不容易陷入“模型不行”“业务没说清”“研发没做完”的互相归因。

3.5 成本和性能是产品策略，不是后端参数#

Day 13 讨论了 API 成本与性能。这里最容易被忽略的一点是：成本和性能会反过来决定产品形态。

如果一个功能必须 1 秒内返回，就不能默认塞入十几页上下文再用强模型生成长答案；如果一个功能每天会被免费用户调用 50 万次，就不能用高成本模型生成低价值内容；如果一个功能用于后台报告，用户不一定需要同步等待，就可以设计成异步任务、预计算和通知。

AI 产品常见性能策略：

成本策略同样要写进 PRD：

• 单次平均成本上限是多少？

• 每日预算是多少？

• 哪些用户有免费额度？

• 哪些场景允许调用强模型？

• 哪些结果可以缓存？

• 哪些请求必须拒绝或转人工？

• 成本超过 70%、90%、100% 时如何告警？

• 成本增长是否带来转化、留存、满意度或人工节省？

增长团队尤其需要关注这个问题。AI 功能很容易在早期提升点击率和使用率，但如果每次使用都产生边际成本，增长策略必须计算 ROI。免费试用、活动入口、裂变奖励、批量生成都可能带来成本放大。没有预算控制的 AI 增长不是增长，是不受控消耗。

3.6 评估集是 AI 项目的质量地基#

Prompt、模型、API、缓存、降级都需要评估集。没有评估集，团队只能凭感觉判断模型好不好。

一个最小可用的 Prompt 回归测试集应包含 30 条样本，覆盖：

• 常规成功样本：业务最常见问题。

• 边界样本：信息缺失、字段冲突、问法模糊。

• 高风险样本：退款、赔付、医疗、金融、法律、隐私、权限。

• 恶意样本：诱导越权、提示注入、要求泄露系统规则。

• 格式样本：要求 JSON、表格、标签、枚举值稳定输出。

• 业务指标样本：是否能提升转化、减少人工、缩短处理时间。

评估不是只看“答得对不对”。至少要包括：

对产品负责人来说，评估集的价值不只是测试，而是统一团队对“好答案”的定义。客服运营、产品、算法、研发、法务如果不共同看样本，就很容易各自用不同标准评价 AI。评估集把抽象争论变成具体样本讨论。

4.1 业务背景#

某国内在线教育机构希望在小程序和 App 中上线 AI 课程咨询助手，帮助用户了解课程适合人群、价格、课时、老师、学习路径和报名优惠。初版 Demo 由运营同学手写 Prompt，把课程介绍、常见问题和用户问题一起粘给大模型，模型能生成比较自然的回复。

Demo 在内部演示中效果不错，但准备上线时，产品负责人发现几个问题：课程价格和优惠经常变化，老师排期来自教务系统，不同用户可见的优惠不同，销售顾问担心 AI 乱承诺低价，增长团队希望在投放落地页使用 AI 咨询但又担心成本失控。

4.2 相关角色#

4.3 原始流程#

1
用户进入课程页
2
-> 点击 AI 咨询
3
-> 前端把用户问题发给后端
4
-> 后端拼接一段固定课程介绍和 Prompt
5
-> 调用强模型
6
-> 返回一段自然语言答案

原流程存在的问题：

• 课程价格和优惠写在 Prompt 中，更新不及时。

• 老师排期、剩余名额、班级时间没有实时查询。

• 所有问题都调用强模型，投放高峰成本不可控。

• 没有 Prompt 版本和评估集，运营改话术后无法回归。

• 用户问“能不能保证提分”“最低多少钱”等问题时，模型可能过度承诺。

• 咨询线索没有结构化沉淀，销售无法判断用户意向。

4.4 AI 改造流程#

改造目标不是让模型自由回答，而是让 AI 咨询助手成为“课程信息查询 + 咨询意图识别 + 合规话术生成 + 线索结构化”的 API 能力。

1
用户问题
2
-> 输入校验和用户身份识别
3
-> 意图分类：课程介绍 / 价格 / 排期 / 优惠 / 学习建议 / 投诉 / 高风险承诺
4
-> 查询课程系统、排期系统、优惠系统
5
-> 选择处理路径：
6
   - 标准 FAQ：缓存或模板
7
   - 个性化学习建议：中模型生成
8
   - 价格优惠：查系统后模板化回答
9
   - 高风险承诺：拒绝绝对化承诺并转顾问
10
-> 输出质检：合规、价格、格式、引导动作
11
-> 返回答案并沉淀线索标签

4.5 数据 / 系统依赖#

4.6 方案架构#

1
App / 小程序 / 投放落地页
2
  |
3
课程咨询业务后端
4
  |
5
AI 咨询 API
6
  |-- 用户身份和渠道识别
7
  |-- 意图分类
8
  |-- 课程 / 排期 / 优惠查询
9
  |-- Prompt 版本选择
10
  |-- 模型路由
11
  |-- 合规质检
12
  |-- 线索标签生成
13
  |
14
模型层
15
  |-- 小模型：意图分类、字段抽取
16
  |-- 中模型：学习建议、咨询回复
17
  |-- 强模型：复杂多轮咨询总结
18
  |
19
CRM / 运营看板 / 质检后台

4.7 关键指标#

4.8 主要风险#

4.9 复盘结论#

这个案例说明，教育咨询类 AI 不能只靠一个“会聊天”的 Prompt。上线方案必须连接课程、排期、优惠、CRM 和合规规则。模型负责表达和归纳，事实信息必须来自业务系统，高风险承诺必须被拦截。

从增长角度看，AI 咨询可以提升落地页互动和线索转化，但只有在成本可控、线索可追踪、话术合规的前提下才值得放量。否则短期咨询量上升，长期可能带来投诉、销售返工和品牌风险。

5.1 业务背景#

一家 B2B SaaS 公司销售团队每天需要查看客户 CRM、会议纪要、邮件沟通和工单记录，再判断客户是否有续约风险或增购机会。某销售主管先用大模型手工总结客户信息：把客户近三个月沟通记录复制进 Prompt，让模型输出“客户现状、风险、机会、下一步建议”。

Demo 对单个客户有效，但规模化后出现问题：不同销售复制的数据格式不一致，模型有时忽略关键工单，敏感客户信息进入外部模型，报告生成时间长，管理层也无法比较不同团队的使用效果。

5.2 相关角色#

5.3 原始流程#

1
销售手工打开 CRM
2
-> 复制客户信息、会议纪要、工单记录
3
-> 粘贴到 Prompt
4
-> 大模型生成客户总结
5
-> 销售自行判断是否采纳

原流程的问题：

• 数据输入不标准，不同销售生成结果不可比。

• 权限不可控，可能把无权限客户数据复制给模型。

• 没有统一 Prompt 版本，结果质量不稳定。

• 没有日志，无法知道 AI 建议是否被采纳。

• 没有成本归因，无法判断哪个团队使用最多。

• 不能和 CRM 流程结合，报告无法沉淀为组织知识。

5.4 AI 改造流程#

改造成销售辅助 API 后，系统不允许销售自由粘贴大段客户资料，而是由后端在权限过滤后自动组装上下文。

1
销售打开客户详情页
2
-> 点击生成 AI 客户摘要
3
-> 后端校验销售是否有客户权限
4
-> 聚合 CRM、会议、邮件、工单摘要
5
-> 检查数据新鲜度和缺失字段
6
-> 调用客户摘要 Prompt v2
7
-> 输出结构化报告：
8
   - 当前状态
9
   - 主要风险
10
   - 扩容机会
11
   - 推荐动作
12
   - 需要人工确认的信息
13
-> 写入 CRM 时间线
14
-> 记录销售是否采纳建议

5.5 数据 / 系统依赖#

5.6 方案架构#

1
CRM 客户详情页
2
  |
3
销售辅助服务
4
  |-- 权限校验
5
  |-- 数据聚合
6
  |-- 数据缺失检测
7
  |-- Prompt 版本管理
8
  |-- 模型调用
9
  |-- 输出结构校验
10
  |-- 写回 CRM
11
  |
12
数据源
13
  |-- CRM
14
  |-- 会议纪要
15
  |-- 邮件摘要
16
  |-- 工单
17
  |
18
运营和管理看板
19
  |-- 使用量
20
  |-- 采纳率
21
  |-- 续约影响
22
  |-- 成本

5.7 关键指标#

5.8 主要风险#

5.9 复盘结论#

销售辅助场景的关键不是让模型“自由分析”，而是让模型在权限、数据结构、报告模板和业务指标约束下辅助判断。AI 的输出必须进入 CRM 工作流，否则它只是一个旁路工具，无法沉淀组织能力。

这个案例也说明 API 产品化的组织价值：同一个 Prompt Demo 只有做成受控 API，才能让销售团队规模化使用，让管理层看见数据，让安全团队放心，让增长团队评估续约和扩容影响。

任务：做一个 30 条样本的 Prompt 回归测试#

选择一个你已经设计过的 AI 功能，例如智能客服回复、商品文案生成、课程咨询、客户摘要、合同摘要、经营分析。为它设计 30 条测试样本，并完成回归测试表。

你需要产出：

1. 功能说明：AI 功能解决什么业务问题。

2. Prompt 版本：写明当前版本号和核心约束。

3. 模型选择：当前模型和备用模型。

4. 30 条测试样本：覆盖常规、边界、高风险、恶意输入、格式要求。

5. 评分标准：至少包含准确性、格式合规、安全性、一致性、成本。

6. 回归结论：是否允许上线、灰度还是需要继续修改。

7. 上线评审清单：列出还缺哪些工程、数据、运营和风控能力。

验收标准#

7.1 理解题#

题 1：为什么不能把一个效果不错的 Prompt Demo 直接上线？

参考答案： Demo 只证明模型在少量样本上可能有效，不能证明它在真实流量、边界输入、高风险问题、异常系统、成本约束和延迟要求下稳定可靠。上线还需要评估集、日志、限流、错误码、降级、Prompt 版本、模型路由、成本监控和灰度机制。

题 2：Prompt 版本管理为什么重要？

参考答案： Prompt 改动会直接影响模型行为，类似代码变更。没有版本管理，就无法追踪谁改了什么、为什么改、影响哪些场景，也无法在质量下降时回滚。Prompt 版本还应绑定测试集、模型版本和上线记录。

题 3：模型选型为什么不能只看能力排行榜？

参考答案： 真实业务要综合任务类型、中文能力、延迟、成本、稳定性、合规、生态和可替换性。最强模型不一定适合所有场景，简单分类或 FAQ 用强模型会造成成本浪费，核心业务还要考虑私有化、日志和供应商风险。

题 4：AI API 产品化最少应包含哪些能力？

参考答案： 至少应包含鉴权、限流、日志、错误码、重试、Prompt 版本、模型路由、成本归因、输出校验、风控拦截、降级策略和监控看板。否则 AI 能力无法稳定复用，也无法在多业务场景中治理。

7.2 应用题#

题 5：如果一个客服 Prompt 回归测试通过率只有 70%，但业务很想上线，你会怎么处理？

参考答案： 不能直接全量上线。应先分析失败样本类型：如果高风险样本失败，必须阻塞上线；如果是低风险表达问题，可以进入小流量灰度并人工审核。应补充 Prompt 约束、缓存标准答案、增加转人工规则、降低自动发送范围，并设定灰度指标和回滚条件。

题 6：一个 AI 商品文案功能上线后成本超预算，你会如何复盘？

参考答案： 先拆成本来源：调用量、输入 Token、输出 Token、模型单价、重试率、重复生成率、强模型占比。再看业务收益：点击率、转化率、运营节省时间。优化方向包括缩短 Prompt、限制输出长度、结果缓存、批处理、小模型路由、失败重试上限和按用户/商品设置额度。

题 7：如何判断一个 AI 功能是否适合进入核心链路？

参考答案： 要看业务收益是否明确，错误成本是否可控，评估集是否通过，异常是否有降级，日志是否可追踪，人工接管是否可用，成本是否可承受，延迟是否满足体验，合规和权限是否明确。只要高风险错误不可控，就不应直接进入核心链路。

8.1 30 条样本 Prompt 回归测试表#

8.2 从 Demo 到可上线 API 能力评审清单#

1
一、业务目标
2
- 目标用户是否明确：
3
- 核心业务指标是否明确：
4
- AI 比原流程提升在哪里：
5
- 错误成本是否可接受：
6

7
二、Prompt 与模型
8
- Prompt 是否有版本号：
9
- Prompt 是否定义输入、输出、边界：
10
- 是否有 30 条以上测试样本：
11
- 模型选型是否有矩阵：
12
- 是否有备用模型或降级模型：
13

14
三、API 与工程
15
- 是否有鉴权：
16
- 是否有限流：
17
- 是否有统一错误码：
18
- 是否有重试上限：
19
- 是否记录输入输出、Prompt 版本、模型版本：
20
- 是否支持灰度和回滚：
21

22
四、成本与性能
23
- 首字延迟目标：
24
- 完整响应目标：
25
- 单次成本上限：
26
- 日 / 月预算：
27
- 缓存策略：
28
- 小模型路由策略：
29

30
五、风险与合规
31
- 高风险问题清单：
32
- 拒答和转人工规则：
33
- 隐私和权限校验：
34
- 日志脱敏策略：
35
- 人审范围：
36

37
六、运营与增长
38
- 是否有质检后台：
39
- 是否有用户反馈入口：
40
- 是否能统计采纳率 / 满意度：
41
- 是否能按渠道统计成本：
42
- 是否定义放量条件：
43

44
评审结论：
45
- 允许上线：
46
- 仅允许灰度：
47
- 需修改后复审：
48
- 暂停：

8.3 第 2 周作品集目录#

1
第 2 周作品集：Prompt、模型选型、API 产品化
2

3
1. Prompt 基础模板
4
   - 角色、任务、输入、输出、约束、异常处理
5

6
2. Prompt 进阶模板
7
   - Few-shot、分步任务、结构化输出、自检
8

9
3. Prompt 评估表
10
   - 样本、期望输出、实际输出、评分、结论
11

12
4. 模型选型矩阵
13
   - 能力、中文、成本、延迟、合规、生态、可替换性
14

15
5. API 产品架构草图
16
   - 业务系统 -> AI 编排层 -> 模型 API
17

18
6. 成本优化方案
19
   - 缓存、降级、小模型路由、预算、监控
20

21
7. 30 条样本回归测试表
22
   - 常规、边界、高风险、恶意、格式、成本、一致性
23

24
8. 上线评审清单
25
   - 业务、Prompt、模型、API、成本、风险、运营、增长

9.1 本周你应该已经建立的核心判断#

本周最重要的进展，是从“我会写 Prompt”升级到“我能设计一个可上线的 AI 能力”。这两者差距很大。

会写 Prompt 的人，通常关注表达技巧：角色设定、示例、格式、语气。能设计 AI 能力的人，必须同时关注业务目标、模型边界、工程架构、评估方法、成本性能和组织协作。

你现在应该能做出以下判断：

9.2 本周常见误区#

9.3 下周学习衔接#

第 3 周会进入 AI 产品设计、评估和护栏。也就是说，我们会从“能力怎么接入”继续推进到“产品怎么设计得可靠”。

下周你需要带着三个问题继续学：

1. AI 产品和传统产品在用户体验上有什么根本差异？

2. 概率性输出如何进入稳定业务流程？

3. 如何设计指标、PRD、护栏和人机协同，让 AI 功能真正可控？