agentsclimarketplace

Product architecture

Skill echoyu1025-a11y/ai-product-skills/product-architecture

一套面向 AI 产品经理的 Claude Code Skill:基于「四层骨架 + 数据流转」方法论,正向把想法推导成立项方案,逆向把已有产品拆解成可视化架构图。作者:芊羽

Install
npx -y skills add echoyu1025-a11y/ai-product-skills --skill product-architecture

Assembled 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

产品架构逆向拆解 — 用"四层骨架 + 数据流转"方法论分析任意产品的架构。当用户说"拆解 XX 产品的架构""分析 XX 是怎么搭的""帮我看看 XX 的产品架构""画出 XX 的架构图""用四层骨架分析""逆向 XX 的设计""XX 的能力分层"等触发。也覆盖："这个 AI 产品架构是什么""XX 和 YY 架构对比""产品分层设计"等场景。输出可视化 HTML 架构图,四层彩色色块 + 跨层数据流转箭头。不用于纯技术架构(后端微服务拓扑)或纯信息架构(页面层级)。

SKILL.md

5.4 KB, as published. Nobody here has run it

产品架构 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. 保持视觉一致。配色规范已固定,不要自创色系。

常见误判

现象误判纠正
把"语音输入"放在场景层❌它是能力层,场景层是"语音对话/语音笔记"这种业务
把"用户画像"放在数据层⚠️ 看情况如果是用于推荐的特征工程产物,属于数据层;如果是 ToB 客户管理界面,属于场景层
触达层只写"App"❌ 太粗应该写"iOS App / Android App / Web 端 / 小程序 / 公众号"
数据层写"MySQL"❌ 技术细节写"用户对话记录 / 企业存量文档 / 互联网爬取"

输出之后

引导用户做两件事:

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.