正文
获取原文件SKILL.md
把“它卖什么”推进到“为什么这个系统能够运转，以及什么会让它失效”。
工作模式
DECODE：拆解一个既有模式。COMPARE：比较多个模式的因果差异。DESIGN：为自有业务提出可验证的模式选项。EVOLVE：解释模式如何随时间变化。
核心问题
- 谁使用、受益、决定、影响和付款？
- 替代了什么流程、支出、延迟或风险？
- 价值通过什么产品、渠道、关系和能力交付？
- 收入在什么事件发生，以什么单位、频率和合同产生？
- 成本由什么驱动，哪些随规模下降或上升？
- 网络、数据、品牌、供给、切换成本或流程是否形成强化回路？
- 模式依赖哪些外部平台、监管、交叉补贴、资本或关键合作方？
- 哪些条件变化会令模式失效？
- 平台实际控制哪一个高频决策：发现、比较、路由、定价、结算、治理还是观测？
- 若发生并购，买方和标的分别掌握哪一层能力，组合后改变了谁的成本、收入、议价权和中立性？
工作流程
- 区分用户、买方、付款方、供应方和受益者，不能默认是同一主体。
- 映射价值流、资金流、数据流与风险流，并标出关键交易事件。
- 拆分收入逻辑、成本逻辑、交叉补贴和非货币交换。
- 区分用户看到的产品入口与平台实际掌握的控制点。说明它替谁做出什么选择、选择发生多频繁、依据什么数据、错误由谁承担。
- 绘制飞轮、负反馈、瓶颈与外部依赖；画布字段必须形成因果解释。市场信号只有在改善路由、成本、留存或议价权时，才算强化回路的一部分。
- 有并购或战略投资时，分别映射交易前后两套系统，解释互补能力、收入与成本协同、渠道变化、绑定风险和中立性损失。
- 分开陈述“模式是什么”“为何可能有效”“有何证据”“哪些部分可复制”。创始人的判断可解释产品取舍，不能代替机制证据。
DESIGN模式至少提出两个有明显取舍的选项，但不得虚构客户意愿或市场验证。- 创建
business-model-analysis.md，使用 references/output-template.md。 VISUAL_REPORT、EXECUTIVE_DECK或STORY_DECK必须创建visuals/business-model-system-map.png；只有强化回路有证据时才增加visuals/business-flywheel.png。具体契约见 references/visual-deliverables.md。
质量门槛
- 收入机制必须与价值和付款触发点对应。
- 护城河必须有行为、数据或结构证据，不能把功能列表当护城河。
- 平台定位必须落到可观察的控制动作和经济结果；“基础设施”“入口”“生态”本身不构成分析。
- 多边平台逐方检查参与动机、交易密度、供给中立性、绕开平台、自建与云厂商捆绑等替代路径。
- 并购协同要落到收入、成本、分发或控制权变化；不能只写产品互补和愿景一致。
- 外部企业的成功机制不能自动迁移到自己的业务；必须说明可复制、需适配与不可复制部分。
- 对因果链中的薄弱环节和替代解释使用明确的不确定性标签。
- “四流图”必须是真实可读的关系图，不能再用四组项目符号冒充；连接线需区分价值、资金、数据和风险。
表达方式
- 不从商业模式画布字段逐格念答案。围绕关键交易写清楚“谁为什么付钱、钱如何分、成本和风险落在哪里”。
- “飞轮”“平台”“生态”“数据护城河”只有在能指出具体行为和反馈机制时才使用；否则换成普通因果描述。
- 结论使用可证伪的句子，避免“打造闭环、赋能增长、形成生态”等营销表达。
- 面向大众解释时，先说场景和决策，再引入抽象概念；不要用“它不是 X，而是 Y”替代机制说明。
方法来源与改造边界见 references/methodology-basis.md。