product-structure-evolution

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 — 触发场景

1. 用户说产品功能越来越多、越来越乱。
2. 用户想把多个功能、模块或业务整合进一个产品。
3. 用户需要判断某个入口、Tab、模块是否破坏结构。
4. 用户想把若干需求抽象成一个更稳定的类型。

语言信号

• “功能太多了”
• “这个模块放哪里”
• “要不要加一个 Tab”
• “能不能抽象成平台”
• “怎么保持简单”
• “产品 DNA 是什么”

与相邻 skill 的区分

• 与 scenario-boundary-design 的区别: 后者处理单功能取舍，本 skill 处理产品系统结构。
• 与 natural-growth-judgment 的区别: 后者处理增长/导流/KPI，本 skill 处理结构是否能承载增长。

E — 可执行步骤

1. 画出现有骨架

   • 完成标准: 列出核心对象、核心入口、核心关系、可卸载/插件化模块和不可破坏规则。

2. 归类新需求

   • 完成标准: 判断新需求是新类型、已有类型的实例、边缘能力还是战略噪音。

3. 做抽象压缩

   • 完成标准: 尝试把多个功能请求压缩为更少的机制或平台接口。

4. 检查产品 DNA

   • 完成标准: 说明方案是否仍符合产品价值观、边界、主场景和用户感受。

5. 输出结构决策

   • 完成标准: 给出 纳入核心 / 插件化 / 隐藏 / 合并抽象 / 拒绝 / 延后演化。

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