产品架构 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 步:六步法逆向推导

按顺序执行,不能跳步:

1. 体验:走一遍核心链路。能上手就上手,不能就看演示视频/官网截图。把核心场景在脑子里跑一遍。
2. 穷举:列出所有用户可见的功能。颗粒度按对话类/输入类/生成类/工具类拆分。漏一个可能漏一整个业务模块。
3. 归类:用"砍掉 A,B 是否受影响"测试,把功能合并成业务模块。形成 3-6 个场景层模块。
4. 反推能力:每个场景层模块依赖什么 AI/通用能力?(大模型对话、RAG、ASR/TTS、图像生成、工作流引擎…)同一能力被多个场景共用时只画一次。
5. 反推数据:每个能力消费什么数据?(企业存量文档、用户对话日志、互联网爬取、UGC、合成数据…)
6. 绘图:用 templates/architecture-template.html 生成可视化。

第 4 步:识别数据流转

四层骨架只是静态结构,箭头才是产品的"活"。至少标 1-2 条:

• 向下(蓝色 ↓):用户行为沉淀到数据层。例:对话记录 → 沉淀到数据层用于训练
• 向上(红色 ↑):数据回流被产品消费。例:UGC 智能体 → 回流到场景层广场
• 横向:同层模块之间的依赖(罕见,慎用)

第 5 步:生成输出

复制 templates/architecture-template.html → 当前工作目录,文件名 <产品名拼音或英文>-architecture.html。

按 assets/color-tokens.md 的配色规范替换内容。不要改变四层颜色对应(黄=触达/绿=场景/蓝=能力/紫=数据),保持视觉一致性。

完成后告诉用户:

• 文件路径
• 一句话总结这个产品的架构特点(例如:"豆包 是典型的 AI ToC 五层结构,生态层是它的增长引擎")
• 1-2 条值得注意的设计决策或空白点

关键原则

1. 拒绝凑数。如果某层只有 1 个东西,要么是漏穷举了,要么是这个产品本身就薄 — 后一种情况要明确告诉用户。
2. 不替代用户判断。架构是判断题不是计算题,同一个产品不同人画不同。输出后引导用户讨论:"你觉得我把 X 放在场景层还是能力层更合理?"
3. 不画 UI。如果你忍不住写"登录页/设置页/个人中心",停下,这是信息架构。问自己:"这个东西帮用户做什么业务?"
4. 保持视觉一致。配色规范已固定,不要自创色系。

常见误判

输出之后

引导用户做两件事:

• 深度研究路径:讨论这个产品为什么这么分层?反映了什么业务判断?
• 找差异化路径:哪一层最薄弱?哪类数据没沉淀?哪类场景没覆盖?那就是机会。