ai-product-proposal

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 步:六步法正向推导

按顺序推导,输出方案前自查每一步:

1. 从用户痛点出发(对应问卷 Q3),确认目标用户和核心痛点
2. 穷举设想场景(对应问卷 Q4),如果用户给的少于 3 个,引导补齐
3. 归类成场景层模块(3-6 个,用"砍掉 A 影响 B"测试)
4. 反推能力层:每个场景需要什么 AI/通用能力?共用的只画一次
5. 反推数据层:每个能力消费什么数据?用业务语言不用技术语言
6. 设计数据流转:至少 1 条向下沉淀(产品 → 数据)+ 1 条向上回流(数据 → 产品)

第 4 步:生成输出

完整方案场景(立项/PRD):

• 复制 templates/proposal-full.md → 当前工作目录
• 文件名:<产品名>-proposal.md
• 填充所有占位符,标注待验证假设

面试草稿模式:

• 复制 templates/proposal-interview.md → 当前工作目录
• 文件名:<产品名>-interview-draft.md
• 简化版结构,只保留四层 + 1 条流转 + 一句话总结
• 明确标注哪些是基于公开信息的合理假设

第 5 步:输出后告诉用户

完成后告诉用户:

• 文件路径
• 一句话总结产品架构特点
• 1-2 条值得讨论的设计判断(为什么这么分层)
• 2-3 个待验证的关键假设(用 ⚠️ 标记的那些)
• 引导下一步:"哪一层你最想推翻重做?" 或 "哪个假设最不确定?"

关键原则

1. 不替用户决定。架构是判断题,你提供推理,用户做最终判断。生成后引导讨论。
2. 假设要明确。用户没说清的地方做合理假设,但用 ⚠️ 显式标出,不能糊弄过去。
3. 拒绝凑数。某层只有 1 个模块要么是漏穷举、要么是真的薄 — 如实告诉用户。
4. AI ToC 必问生态层。如果是 AI ToC 但用户没提社区/UGC/智能体广场,要主动问"有没有生态层?没有的话增长引擎在哪?"
5. ToB 必问 4A。如果是 ToB 但用户没提认证/授权/账户/审计,要主动问。
6. 数据层用业务语言。写"用户对话记录",不写"chat_logs 表"。

常见误判

现象	误判	纠正
把"语音输入"放在场景层	❌	它是能力层,场景层是"语音对话/语音笔记"这类业务
触达层只写"App"	❌ 太粗	拆"iOS App / Android App / Web 端 / 小程序"
数据层写"MySQL"	❌ 技术细节	写"用户对话记录 / 企业存量文档"
没有数据流转箭头	❌ 不完整	至少补 1 ↓ + 1 ↑
场景层 >7 个	⚠️ 颗粒度太细	用"砍掉 A 影响 B"测试合并
场景层 <3 个	⚠️ 颗粒度太粗或穷举不足	引导用户补充

输出之后

引导用户做两件事:

• 深度路径:讨论这个架构为什么这么分层?反映了什么业务判断?
• 空白路径:哪一层最薄弱?哪类数据没沉淀?哪类场景没覆盖?那就是优化方向。