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