| name | product-architecture |
| author | 芊羽 |
| description | 产品架构逆向拆解 — 用"四层骨架 + 数据流转"方法论分析任意产品的架构。当用户说"拆解 XX 产品的架构""分析 XX 是怎么搭的""帮我看看 XX 的产品架构""画出 XX 的架构图""用四层骨架分析""逆向 XX 的设计""XX 的能力分层"等触发。也覆盖："这个 AI 产品架构是什么""XX 和 YY 架构对比""产品分层设计"等场景。输出可视化 HTML 架构图,四层彩色色块 + 跨层数据流转箭头。不用于纯技术架构(后端微服务拓扑)或纯信息架构(页面层级)。 |
产品架构 SKILL — 逆向拆解任意产品
这个 SKILL 是什么
把任意产品(微信、豆包、某 AI App、ToB 工具…)逆向拆解成产品经理视角的架构图:
- 四层骨架:触达层 / 场景层 / 能力层 / 数据层
- 数据流转:跨层箭头,标注沉淀和回流路径
- 可视化输出:HTML 文件,黄绿蓝紫四色分层 + 蓝/红双向箭头
不是技术架构(微服务、数据库选型),不是信息架构(页面结构),是产品架构 — 业务模块怎么切、模块之间什么关系、数据怎么流转。
触发后的工作流程
第 0 步:确认目标产品
如果用户没说清是哪个产品,先问:
- 你要拆解哪个产品?(名称 + 官网/截图/简介任一即可)
- 用户群是 ToC 还是 ToB?
- 你的拆解目的是:深度研究(看懂别人设计意图)还是 找空白点(找差异化机会)?
如果产品比较小众或用户没给信息,主动用 WebFetch / WebSearch 查官网了解。
第 1 步:阅读方法论
必读 references/methodology.md,这是整个 SKILL 的方法论核心。里面有:
- 四层骨架的层定义(触达/场景/能力/数据各是什么)
- 六步法(体验→穷举→归类→反推能力→反推数据→绘图)
- 粒度判断("能描述这功能帮用户做什么"就够了)
- 归类判断("砍掉 A 后 B 是否受影响"测试)
读完再继续。
第 2 步:参考案例
读 references/examples.md,里面有四个范例:
- 微信(传统 ToC)
- 豆包(AI ToC)
- 飞书 AI(AI ToB)
- AI 搜索(Agent 平台)
挑一个跟目标产品最相似的形态重点看,理解"该层应该写什么粒度的东西"。
第 3 步:六步法逆向推导
按顺序执行,不能跳步:
- 体验:走一遍核心链路。能上手就上手,不能就看演示视频/官网截图。把核心场景在脑子里跑一遍。
- 穷举:列出所有用户可见的功能。颗粒度按对话类/输入类/生成类/工具类拆分。漏一个可能漏一整个业务模块。
- 归类:用"砍掉 A,B 是否受影响"测试,把功能合并成业务模块。形成 3-6 个场景层模块。
- 反推能力:每个场景层模块依赖什么 AI/通用能力?(大模型对话、RAG、ASR/TTS、图像生成、工作流引擎…)同一能力被多个场景共用时只画一次。
- 反推数据:每个能力消费什么数据?(企业存量文档、用户对话日志、互联网爬取、UGC、合成数据…)
- 绘图:用
templates/architecture-template.html 生成可视化。
第 4 步:识别数据流转
四层骨架只是静态结构,箭头才是产品的"活"。至少标 1-2 条:
- 向下(蓝色 ↓):用户行为沉淀到数据层。例:对话记录 → 沉淀到数据层用于训练
- 向上(红色 ↑):数据回流被产品消费。例:UGC 智能体 → 回流到场景层广场
- 横向:同层模块之间的依赖(罕见,慎用)
第 5 步:生成输出
复制 templates/architecture-template.html → 当前工作目录,文件名 <产品名拼音或英文>-architecture.html。
按 assets/color-tokens.md 的配色规范替换内容。不要改变四层颜色对应(黄=触达/绿=场景/蓝=能力/紫=数据),保持视觉一致性。
完成后告诉用户:
- 文件路径
- 一句话总结这个产品的架构特点(例如:"豆包 是典型的 AI ToC 五层结构,生态层是它的增长引擎")
- 1-2 条值得注意的设计决策或空白点
关键原则
- 拒绝凑数。如果某层只有 1 个东西,要么是漏穷举了,要么是这个产品本身就薄 — 后一种情况要明确告诉用户。
- 不替代用户判断。架构是判断题不是计算题,同一个产品不同人画不同。输出后引导用户讨论:"你觉得我把 X 放在场景层还是能力层更合理?"
- 不画 UI。如果你忍不住写"登录页/设置页/个人中心",停下,这是信息架构。问自己:"这个东西帮用户做什么业务?"
- 保持视觉一致。配色规范已固定,不要自创色系。
常见误判
| 现象 | 误判 | 纠正 |
|---|
| 把"语音输入"放在场景层 | ❌ | 它是能力层,场景层是"语音对话/语音笔记"这种业务 |
| 把"用户画像"放在数据层 | ⚠️ 看情况 | 如果是用于推荐的特征工程产物,属于数据层;如果是 ToB 客户管理界面,属于场景层 |
| 触达层只写"App" | ❌ 太粗 | 应该写"iOS App / Android App / Web 端 / 小程序 / 公众号" |
| 数据层写"MySQL" | ❌ 技术细节 | 写"用户对话记录 / 企业存量文档 / 互联网爬取" |
输出之后
引导用户做两件事:
- 深度研究路径:讨论这个产品为什么这么分层?反映了什么业务判断?
- 找差异化路径:哪一层最薄弱?哪类数据没沉淀?哪类场景没覆盖?那就是机会。
