Ai product proposal
一套面向 AI 产品经理的 Claude Code Skill:基于「四层骨架 + 数据流转」方法论,正向把想法推导成立项方案,逆向把已有产品拆解成可视化架构图。作者:芊羽
npx -y skills add echoyu1025-a11y/ai-product-skills --skill ai-product-proposalAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
AI 产品架构正向设计 — 基于"四层骨架 + 数据流转"方法论,把一个 AI 产品想法推导成完整的文字版产品架构方案。当用户说"帮我设计 XX 的产品架构""我想做 XX,帮我搭骨架""给 XX 写一份立项方案""帮我准备 PRD 前期架构""帮我把 XX 的产品方案理出来""帮我面试答题 XX 产品架构""设计一个 AI 产品方案"等触发。适用于产品立项、PRD 前期规划、AI 产品方案设计、面试案例分析。不用于逆向拆解已有产品的架构(那是 product-architecture skill)。
SKILL.md
6.6 KB, as published. Nobody here has run it
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 个 | ⚠️ 颗粒度太粗或穷举不足 | 引导用户补充 |
输出之后
引导用户做两件事:
- 深度路径:讨论这个架构为什么这么分层?反映了什么业务判断?
- 空白路径:哪一层最薄弱?哪类数据没沉淀?哪类场景没覆盖?那就是优化方向。