title: " AI写PRD | 从需求到验收标准"
category: 人工智能
tags:
- 大模型API中转站
- 4SAPI
- PRD
- 产品需求
- 验收标准
- Claude Fable 5
- 企业级大模型接入
description: "AI 不只是写代码，也适合把模糊需求整理成 PRD。本文讲如何用辅助模型采访需求、用 Fable 5 拆用户故事、边界、验收标准、埋点和风险，并通过 4SAPI 做权限和成本治理。"
AI 能干的一件大事：
很多团队的问题不是不会开发。
而是需求一开始就长这样：
text
做一个更智能的客服。
优化一下后台体验。
加一个数据看板。
让用户能自己管理模型 Key。
这些不是 PRD。
这些只是方向。
AI 最适合帮你把方向变成：
text
目标用户。
业务目标。
功能范围。
非目标。
用户故事。
验收标准。
异常场景。
埋点指标。
权限和合规边界。
1. 不要让 AI 直接写大而全 PRD
直接问：
通常会得到一篇漂亮废话。
更好的方式是：
text
辅助模型先采访。
Fable 5 做结构化 PRD。
复核模型检查矛盾和缺口。
通过 4SAPI 做分工时，我更建议按“价值”而不是按“文档长度”分。
需求采访、录音摘要、会议记录清洗，可以走低成本模型。
真正需要 Fable 5 的地方，是这些：
text
把冲突需求拆开。
把模糊目标改成可验收标准。
把权限、成本、日志和合规边界写清。
判断哪些功能本轮不做。
也就是说，Fable 5 不是 PRD 打字员。
它更像产品架构审查员。
2. PRD 采访问题
辅助模型可以先问：
text
1. 这个功能解决谁的什么问题？
2. 成功以后用什么指标判断？
3. 本轮必须做什么，不做什么？
4. 涉及哪些角色和权限？
5. 哪些动作有安全、成本或合规风险？
最多问 5 个。
不要无限追问。
如果信息足够，就生成任务书交给 Fable 5。
3. PRD 模板
text
# PRD
功能名称：
背景：
目标用户：
业务目标：
核心场景：
用户故事：
功能范围：
非目标：
流程说明：
权限规则：
异常场景：
数据和埋点：
验收标准：
上线风险：
灰度和回滚：
这套结构特别适合企业级大模型接入。
比如做“团队模型 Key 管理”：
text
谁能创建 Key。
谁能调用 Fable 5。
预算怎么限制。
日志谁能看。
Key 泄露怎么吊销。
这些必须写进 PRD。
4. 验收标准要可测试
差的验收：
好的验收：
text
普通成员不能创建生产 Key。
项目管理员可以设置单日预算。
超过预算后请求返回明确错误。
调用日志能按 project、model、user 筛选。
Fable 5 调用必须使用高权限 Key。
让 Fable 5 审查：
text
请把这份 PRD 里的模糊验收标准改成可测试条目。
每条都能被 QA、自动化测试或日志验证。
5. 非目标比目标更重要
PRD 里一定要写非目标。
尤其是 AI 功能。
比如你要做：
目标可能是：
非目标应该写：
text
本期不做自动扣费。
本期不做跨部门成本分摊。
本期不开放普通成员查看全公司日志。
本期不允许导出包含完整 Prompt 的敏感日志。
这些非目标能防止开发时范围失控。
也能防止 AI 生成过度方案。
Fable 5 很适合帮你补非目标：
text
请根据这个 PRD，补充本期应该明确排除的非目标。
重点看权限、成本、合规、数据隐私和上线风险。
6. 埋点和日志要写进 PRD
很多 AI 功能上线后才发现：
text
不知道用户有没有用。
不知道模型调用花了多少钱。
不知道失败在哪里。
不知道 Fable 5 是否被滥用。
所以 PRD 里要写日志字段。
例如：
text
project_id
user_id_hash
model
task_type
input_tokens
output_tokens
cost
status_code
latency_ms
fallback_model
这些字段可以从 4SAPI 或业务后端日志里来。
PRD 阶段就写清，后面研发不会漏。
7. AI Prompt
text
你是产品需求分析助手。
请根据我提供的模糊需求，先判断信息是否足够。
如果不足，最多问 5 个关键问题。
如果足够，请生成 PRD。
PRD 必须包含：
背景、目标用户、业务目标、用户故事、功能范围、非目标、权限规则、异常场景、埋点、验收标准、上线风险。
要求：
- 验收标准必须可测试。
- 涉及 4SAPI、API Key、模型调用、预算和日志时，必须写清权限和审计。
- 不要承诺无法验证的效果。
8. 示例：4SAPI 团队预算功能 PRD
原始需求：
AI 应该整理成：
text
功能名称：项目级模型预算管理
目标用户：
企业管理员、项目负责人、财务负责人。
业务目标：
控制不同项目的模型调用成本，防止单个项目异常消耗全部额度。
核心能力：
1. 按 project 设置日预算和月预算。
2. 按 Key 限制可调用模型。
3. 超预算后返回明确错误。
4. 管理员可查看预算使用率。
5. 支持预算告警。
非目标：
本期不做自动扣费。
本期不做部门成本分摊。
本期不允许普通成员查看全公司 Prompt 明细。
验收标准：
1. projectA 超过日预算后，继续调用返回 budget_exceeded。
2. 普通成员无法修改预算。
3. 管理员能按 project、model、key_group 查看成本。
4. Fable 5 调用可以单独设置上限。
这个例子里，AI 不是只写文档。
它帮你把“控制成本”变成了可开发的功能。
9. PRD 自检清单
写完以后，让 AI 自检：
text
目标用户是否明确？
非目标是否明确？
验收标准是否可测试？
权限是否清楚？
日志字段是否清楚？
是否有上线风险？
是否有灰度和回滚？
是否涉及敏感数据？
如果一份 PRD 过不了这张表，就不要急着开发。
10. 从 PRD 到研发任务
PRD 写完以后，不要直接丢给研发。
最好再让 AI 做一次任务拆解。
输出结构可以是：
text
功能模块：
后端任务：
前端任务：
数据库变更：
4SAPI 配置变更：
权限变更：
埋点和日志：
测试用例：
上线检查：
比如“项目级模型预算管理”，可以拆成：
text
后端：新增 project_budget 表。
后端：调用前检查预算余额。
前端：预算设置页。
4SAPI：按 key_group 记录预算消耗。
日志：记录 budget_check_result。
测试：预算未超、预算刚好超、预算已超、管理员/普通成员权限。
这一步特别适合 Fable 5。
因为它会从 PRD 里找出遗漏的工程动作。
比如很多产品文档会写：
但没写：
text
已经在队列里的任务怎么办？
失败返回给用户什么错误？
管理员是否收到告警？
是否允许临时提高预算？
日志里怎么证明是预算拦截？
这些都要在研发前讲清楚。
4SAPI 的中转层也应该从 PRD 阶段就参与。
否则最后会变成业务系统写了一套预算，4SAPI 又有一套日志，两个口径对不上。
11. PRD 反面样例
一个不好的需求是：
text
做一个智能模型调用看板，让管理员更好地了解使用情况。
这句话没有错，但没法验收。
Fable 5 应该把它追问成：
text
管理员是谁？
看哪些范围？
按项目、Key、用户还是模型看？
是否展示成本？
是否展示完整 Prompt？
普通成员能不能看？
数据延迟可以接受多久？
下载导出是否需要脱敏？
最后 PRD 里应该出现可验收条目：
text
管理员可以按 project、model、key_group 查看近 30 天成本。
普通成员只能查看自己发起的调用摘要。
默认不展示完整 Prompt，只展示脱敏摘要。
超过预算 80% 时发送告警。
所有导出动作记录 operator_id 和 export_id。
你会发现，AI 写 PRD 的关键不是“写得像文档”。
而是把一句模糊话变成一组权限、日志、预算和验收规则。
12. 总结
AI 写 PRD 的价值不是文笔。
而是：
text
把模糊需求变成可开发、可测试、可上线、可审计的规格。
低成本模型负责采访。
Fable 5 负责拆复杂边界。
4SAPI 负责管理模型调用、成本和权限。
一句话：
