| name | ai-product-proposal |
| description | AI 产品架构正向设计 — 基于"四层骨架 + 数据流转"方法论,把一个 AI 产品想法推导成完整的文字版产品架构方案。当用户说"帮我设计 XX 的产品架构""我想做 XX,帮我搭骨架""给 XX 写一份立项方案""帮我准备 PRD 前期架构""帮我把 XX 的产品方案理出来""帮我面试答题 XX 产品架构""设计一个 AI 产品方案"等触发。适用于产品立项、PRD 前期规划、AI 产品方案设计、面试案例分析。不用于逆向拆解已有产品的架构(那是 product-architecture skill)。 |
| author | 芊羽 |
AI 产品方案 SKILL — 从想法到完整方案
这个 SKILL 是什么
把"一个 AI 产品想法"通过结构化问卷推导成产品经理可交付的完整方案:
- 四层骨架文字版:触达 / 场景 / 能力 / 数据 各层有几个模块、每个模块做什么、为什么这么切
- 数据流转:至少 1 条向下沉淀 + 1 条向上回流的清晰描述
- 关键判断:为什么选这个层级粒度、哪些是核心假设、哪些是待验证空白点
- 输出 Markdown 文字方案(不是可视化图)
正向产出,不是逆向拆解。如果用户要拆解一个已有产品,转 product-architecture skill。
跟 product-architecture 的关系
| product-architecture | ai-product-proposal(本 skill) |
|---|
| 方向 | 逆向拆解 | 正向设计 |
| 输入 | 已有产品名 | 产品想法 + 问卷回答 |
| 输出 | HTML 可视化 | Markdown 文字方案 |
| 核心问 | "他怎么搭的?" | "我应该怎么搭?" |
两个 skill 共享同一套方法论(四层骨架 / 数据流转 / 粒度判断)。本 skill 不重写方法论,直接调用老 skill 的 references。
触发后的工作流程
第 0 步:确认场景与用途
如果用户给的信息不够,先问 5-7 个核心问题,信息齐了再生成。
问卷模板(按顺序问,可以一次性问完也可以分批):
| # | 问题 | 用途 |
|---|
| 1 | 产品名 + 一句话定位 | 锁定输出主体 |
| 2 | ToC 还是 ToB? | 决定是否需要 4A 体系/生态层 |
| 3 | 目标用户 + 核心痛点 | 撑起场景层的"为什么用" |
| 4 | 你设想的核心场景有哪些?(3-5 个) | 直接对应场景层模块 |
| 5 | 已知的能力/数据约束?(可选,留空我会推理) | 撑起能力层和数据层的现实性 |
| 6 | 输出用途:① 立项汇报 ② PRD 前期 ③ 面试案例 ④ 其他 | 决定输出形态(完整方案 vs 精简大纲) |
| 7 | 详细程度:精简大纲(快速看判断)/ 完整方案(可直接贴 PRD) | 用户没说就默认完整方案 |
关键判断:
- 如果第 6 题选了面试案例,跳到第 4 步:面试草稿模式。
- 如果用户提供的产品是他不熟悉的(常见于面试题),用最少假设 + 最常见的 AI 产品形态推理,明确标注哪些是假设。
第 1 步:阅读方法论
读同级目录下 ../product-architecture/references/methodology.md,这是四层骨架方法论的核心,跟本 skill 共享。重点掌握:
- 四层骨架定义(触达/场景/能力/数据各层是什么)
- 数据流转的颜色和方向语义(虽然本 skill 输出文字,但语义要对)
- 粒度判断("能描述功能帮用户做什么"就够了)
- 归类判断("砍掉 A 后 B 是否受影响"测试)
- ToB/ToC 差异(ToB 多 4A 体系,AI ToC 可能有生态层)
第 2 步:阅读正向推导示范
读本 skill 的 references/methodology.md(正向推导版本)和 references/examples.md(AI 客服完整方案示范)。
老 skill 的 examples.md 是"逆向拆解后的形态",本 skill 的 examples.md 是"从想法正向写到方案的形态",两者侧重点不同。
第 3 步:六步法正向推导
按顺序推导,输出方案前自查每一步:
- 从用户痛点出发(对应问卷 Q3),确认目标用户和核心痛点
- 穷举设想场景(对应问卷 Q4),如果用户给的少于 3 个,引导补齐
- 归类成场景层模块(3-6 个,用"砍掉 A 影响 B"测试)
- 反推能力层:每个场景需要什么 AI/通用能力?共用的只画一次
- 反推数据层:每个能力消费什么数据?用业务语言不用技术语言
- 设计数据流转:至少 1 条向下沉淀(产品 → 数据)+ 1 条向上回流(数据 → 产品)
第 4 步:生成输出
完整方案场景(立项/PRD):
- 复制
templates/proposal-full.md → 当前工作目录
- 文件名:
<产品名>-proposal.md
- 填充所有占位符,标注待验证假设
面试草稿模式:
- 复制
templates/proposal-interview.md → 当前工作目录
- 文件名:
<产品名>-interview-draft.md
- 简化版结构,只保留四层 + 1 条流转 + 一句话总结
- 明确标注哪些是基于公开信息的合理假设
第 5 步:输出后告诉用户
完成后告诉用户:
- 文件路径
- 一句话总结产品架构特点
- 1-2 条值得讨论的设计判断(为什么这么分层)
- 2-3 个待验证的关键假设(用 ⚠️ 标记的那些)
- 引导下一步:"哪一层你最想推翻重做?" 或 "哪个假设最不确定?"
关键原则
- 不替用户决定。架构是判断题,你提供推理,用户做最终判断。生成后引导讨论。
- 假设要明确。用户没说清的地方做合理假设,但用 ⚠️ 显式标出,不能糊弄过去。
- 拒绝凑数。某层只有 1 个模块要么是漏穷举、要么是真的薄 — 如实告诉用户。
- AI ToC 必问生态层。如果是 AI ToC 但用户没提社区/UGC/智能体广场,要主动问"有没有生态层?没有的话增长引擎在哪?"
- ToB 必问 4A。如果是 ToB 但用户没提认证/授权/账户/审计,要主动问。
- 数据层用业务语言。写"用户对话记录",不写"chat_logs 表"。
常见误判
| 现象 | 误判 | 纠正 |
|---|
| 把"语音输入"放在场景层 | ❌ | 它是能力层,场景层是"语音对话/语音笔记"这类业务 |
| 触达层只写"App" | ❌ 太粗 | 拆"iOS App / Android App / Web 端 / 小程序" |
| 数据层写"MySQL" | ❌ 技术细节 | 写"用户对话记录 / 企业存量文档" |
| 没有数据流转箭头 | ❌ 不完整 | 至少补 1 ↓ + 1 ↑ |
| 场景层 >7 个 | ⚠️ 颗粒度太细 | 用"砍掉 A 影响 B"测试合并 |
| 场景层 <3 个 | ⚠️ 颗粒度太粗或穷举不足 | 引导用户补充 |
输出之后
引导用户做两件事:
- 深度路径:讨论这个架构为什么这么分层?反映了什么业务判断?
- 空白路径:哪一层最薄弱?哪类数据没沉淀?哪类场景没覆盖?那就是优化方向。
