| name | product-structure-evolution |
| description | 当用户需要检查产品是否被功能堆砌拖垮，或需要做产品结构、分类、抽象、模块关系、产品 DNA、长期演化和复杂度治理判断时调用。
不适用于: 单个页面视觉微调、一次性活动页、无需长期结构承载的临时功能。
|
| source_book | 《微信背后的产品观》 张小龙 |
| source_chapter | 设计篇 |
| tags | ["product","structure","evolution"] |
| related_skills | ["scenario-boundary-design","natural-growth-judgment","product-spirit-expression"] |
产品结构与演化
R — 来源
原书依据见本节来源说明。
依据《设计篇》中“产品是进化出来的”、产品 DNA、结构优先、分类、抽象、有机联系和平台核心架构等论述。
I — 方法论骨架
复杂产品不能靠功能列表治理，而要靠结构、分类和抽象治理。
结构像骨骼，决定新功能能不能藏得住、接得上、长得出来。
产品 DNA 是长期价值观和认知，决定每次演化是否仍像同一个产品。
好的结构会把 100 个表层需求抽象成少数类型，让用户自己生成实例。
如果解决方案越来越复杂，可能不是技术差，而是问题定义和产品结构错了。
A1 — 书中的应用
案例: 四个 Tab
- 问题: 新功能越来越多，是否增加第五个 Tab。
- 方法论的使用: 作者用结构约束抵抗每次新增入口的诱惑。
- 结论: 入口数量是产品骨骼，不应被单次需求轻易打破。
- 结果: 朋友圈等功能没有直接破坏底层导航结构。
案例: 订阅平台抽象
- 问题: 名人、企业、媒体、餐饮等内容都有不同需求。
- 方法论的使用: 不为每类内容做一套系统，而抽象为统一账号和订阅机制。
- 结论: 抽象越好，系统越能容纳未来变化。
- 结果: 平台成为可扩展核心架构，而不是实例堆叠。
A2 — 触发场景
- 用户说产品功能越来越多、越来越乱。
- 用户想把多个功能、模块或业务整合进一个产品。
- 用户需要判断某个入口、Tab、模块是否破坏结构。
- 用户想把若干需求抽象成一个更稳定的类型。
语言信号
- “功能太多了”
- “这个模块放哪里”
- “要不要加一个 Tab”
- “能不能抽象成平台”
- “怎么保持简单”
- “产品 DNA 是什么”
与相邻 skill 的区分
- 与
scenario-boundary-design 的区别: 后者处理单功能取舍，本 skill 处理产品系统结构。
- 与
natural-growth-judgment 的区别: 后者处理增长/导流/KPI，本 skill 处理结构是否能承载增长。
E — 可执行步骤
-
画出现有骨架
- 完成标准: 列出核心对象、核心入口、核心关系、可卸载/插件化模块和不可破坏规则。
-
归类新需求
- 完成标准: 判断新需求是新类型、已有类型的实例、边缘能力还是战略噪音。
-
做抽象压缩
- 完成标准: 尝试把多个功能请求压缩为更少的机制或平台接口。
-
检查产品 DNA
- 完成标准: 说明方案是否仍符合产品价值观、边界、主场景和用户感受。
-
输出结构决策
- 完成标准: 给出
纳入核心 / 插件化 / 隐藏 / 合并抽象 / 拒绝 / 延后演化。
B — 边界
- 不适合只存在一天的一次性活动页。
- 不要为了抽象而抽象；过度平台化也会变成战略行为。
- 小团队早期产品可能先验证主场景，再做完整结构治理。
- 有些复杂性来自真实业务、合规或权限，不应被简单归咎于“问题错了”。
失败模式
- 功能像积木一样堆起来，模块之间没有有机联系。
- 为每个客户、每个内容类型、每个运营活动做一个实例。
- 为短期指标破坏长期入口结构。
- 集体妥协导致产品精神分裂。
相关 skills
- depends-on: {scenario-boundary-design}
- composes-with: {natural-growth-judgment, product-spirit-expression}
- contrasts-with: {feature-list-roadmap}
审计信息
- 源文件:
wechat-product-philosophy-skill/source/SOURCE.md
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待 darwin 运行
- 蒸馏时间: 2026-06-14
