当开发者产品考虑开放为平台时，判断是否开放、开放到哪一级…

在决定是否让外部开发者在你的产品上构建扩展、集成或应用时，用需求计数、就绪门槛和六级开放阶梯做出可执行、可撤回的承诺决策。

适用场景

解决思路

1. 先明确交付物：一个带义务的承诺决策、一个种子计划、以及终止标准；不要交付 API 规范、市场设计或合作伙伴合同，这些属于下游执行。
2. 通过访谈收集关键信息：产品与日常用户、客户请求但你不构建的补充功能（列出最近五个请求及背后客户）、是否已有非官方构建（脚本、爬虫、内部胶水、非支持包装器）、现有公开 API/webhook/厂商集成/扩展点、构建者类型（客户内部团队、代理与集成商、独立软件供应商）、你卖什么以及补充功能丰富免费后什么会更有价值、哪个更大平台可能捆绑你的品类、每季度可持续投入的工程与审查能力、哪些选项不可行、十二个月的成功指标、首个结果的截止日期及驱动因素、以及你想要一次性胜利还是复利资产。
3. 根据答案 11 到 13 重新排列阶梯：临近日期提升厂商构建集成（唯一你控制交付的层级）；复利使命提升合作伙伴构建集成；无常设团队则删除可安装应用和运行时平台；不愿签署不可撤回义务则删除文档化 API 以上的所有层级。
4. 记录答案：补充功能需求列表、所选层级、接受的义务、拒绝的选项；如有持久记忆则存储，供下游集成、市场和合作伙伴决策复用。
5. 用一句话陈述生态假设，格式为：因为我们的客户需要[补充功能]而我们不会构建，[构建者类型]将在[表面]上构建它，赚取[他们的回报]，这通过[机制]使我们的产品对[买家]更有价值；任何空白模糊（模糊的构建者、模糊的回报、模糊的机制）则退回重写。
6. 命名你故意商品化的补充功能：生态系统的目标是将其价格推向零；如果它创造的丰富性反而商品化了你，则停止，答案是“不”，这是本技能的有效结果。
7. 在设计任何东西之前运行就绪门槛并报告每个门槛为通过、失败或未知；未知不算通过，需说明解决方法和所需时间。门槛包括：计数需求、架构就绪、补充者供给、人员配置、包络威胁。
8. 重点检查两个决定性门槛：计数需求（附有客户的命名请求补充功能列表，被拒绝的请求是最好的证据，客户已构建的非支持胶水更好；没有这些意味着生态没有市场，再多的开发者营销也创造不出来）；可外部化接口（所有服务接口必须从底层设计为可外部化；对发布的表面进行 dogfood，特权内部路径保证公开路径保持二等公民）。
9. 明确进入头脑风暴模式并说明；开放性是一个阶梯而非开关，六个层级按效率、价值、努力和合规成本排序；只对通过步骤 2 的层级进行排名，门槛失败的层级不是更便宜的选择，而是不可用。
10. 按效率排序：合作伙伴构建集成 > 文档化 API > 厂商构建集成 > 扩展点 > 可安装应用 > 运行时平台；按价值排序：运行时平台 > 可安装应用 > 扩展点 > 合作伙伴构建集成 > 文档化 API > 厂商构建集成；按努力排序：运行时平台 > 可安装应用 > 扩展点 > 合作伙伴构建集成 > 厂商构建集成 > 文档化 API；按合规成本排序：运行时平台 > 可安装应用 > 扩展点 > 合作伙伴构建集成 > 文档化 API == 厂商构建集成。
11. 理解每个层级的含义：1) 合作伙伴构建集成（由你列出）——外部工程换取审查队列、列表标准和升级路径，阶梯上最佳比例，第一个无法撤回的层级，因为另一家公司的收入依赖你的表面；2) 文档化公开 API 和 webhook——一周文档、版本控制和速率限制，然后少量持续成本，可通知后撤回，接纳客户内部团队这一最便宜的补充者供给；3) 厂商构建集成——你构建每个连接器并永久维护以应对其他供应商的 API 变化，杠杆轴为零，努力随连接器增长，但最便宜地发现客户实际采用哪些补充功能，且仍是可放弃的路线图项目；4) 产品内扩展点——每个点有稳定契约加安全边界，每个点永久冻结内部接缝，买到集成无法买到的东西：在产品内部改变行为而非在产品间移动数据；5) 可安装第三方应用——需要常设团队处理同意与范围、安全审查、撤销、租户隔离、他人 bug 的事件处理及开发者支持，买到本身即为产品的补充功能，不可逆；6) 运行时平台——多租户隔离、资源治理、计量、工具链和 SLA，实质是第二个产品配永久团队，买到阶梯上最深的补充者价值，关闭是每个补充者的迁移事件。
12. 合规轴区分层级：层级 4 到 6 在你的边界内运行第三方代码或配置，触发安全审查、同意与撤销模型及数据处理审查，添加容易移除难；层级 3 触发合作伙伴合同和列表条款；层级 1 和 2 平局，都不发布第三方客户依赖的东西，唯一条款是你自己的，无需外部批准。
13. 注意这个顺序会饿死运行时平台：它创造最多补充者价值但承担最大永久义务，因此在效率上总是输；仅当三个条件全部满足时才提升它：客户请求的补充功能确实无法在你的执行上下文外运行；专门平台团队无限期资助而非借用；你确实愿意运行你签署的关闭迁移；缺少任何一个，推荐你能配备人员的最高层级，并将提升条件写为可观察事件。
14. 删除被答案排除的层级而非列在推荐下方，并说明删除了哪些：无安全审查功能删除可安装应用和运行时平台；无法暴露稳定接口的架构删除厂商构建集成以上的所有层级；停在底部作为“第二阶段”的层级会重新出现为范围。
15. 根据已知情况重新排名：已有非官方构建者发布包装器则预支付了合作伙伴构建集成的需求和供给；已为另一产品运行安全审查功能的公司预支付了层级 5 的大部分常设成本；答案 11 到 13 再次移动排名。
16. 遍历每个层级并标记为“有证据支持”、“过早”或“无法配备人员”；然后按效率顺序呈现两到三个候选层级（绝不是一个），每个涵盖：谁构建、他们得到什么、你必须运营什么、它排除了什么、以及它正在起作用的最早信号；以你的推荐和理由结束，让用户在你进一步详述之前选择。
17. 测试补充者经济学和价值分享：为每个你依赖的构建者原型填写工作表，四个输入决定结果：可触达需求（你的多少客户可能想要此补充功能，而非你有多少客户）、他们的回报（许可收入、实施小时、交易流或避免的内部成本）、构建和维护成本（包括你将迫使他们进行的每次迁移）、他们的替代方案（在更大平台上构建同样东西，或根本不构建）。
18. 价值分享直接来自该算术：构建者仅当留在他们一侧的剩余超过其替代方案时才构建，在流动性存在之前施加的抽成恰好吃掉该剩余，因此在有值得征税的市场之前保持抽成为零；这是本技能自己的设计规则，从算术推理而非测量，明确争论而非视为定论；费率、计费和列表机制属于下游。
19. 按原型区分报价：独立软件供应商需要足够大以资助产品线的市场，以及可预测性多于慷慨；代理和集成商通过小时变现，因此提供推荐流和认证而非收入分享；客户内部团队完全不需要商业案例，只需低摩擦，是最便宜的第一供给。
20. 用一个问题筛选每个潜在构建者：如果我们不做这个，你会有什么变化？“我们失去需要的认证”是构建的理由；“没什么真正改变”意味着你有一个 logo，而非补充者；对自己应用镜像测试：如果双方都能零成本离开，这是握手而非生态。
21. 设计飞轮和第一圈：将循环写为因果，然后诚实说明它是自行转动还是你每季度推动——合作伙伴计划是合法答案，只是不同；种子不是可选的慷慨，要么自己制造关键补充功能，要么给第三方公司激励来创造它们；两者都不做就是发布表面保持空置的原因。
22. 种子计划：补贴更价格敏感的一侧，向需求随另一侧增长而增长最多的一侧收费（双边市场定价规则）；在开发者工具生态中，价格敏感侧几乎总是补充者——免费工具、免费沙箱租户、免费列表；手工招募创始 cohort，选择覆盖客户最常请求的补充功能而非 logo 价值；自己构建第一批补充功能以证明表面并设定模式，然后移交或退役；将你自己的分发路由到他们——产品内放置、入门、文档、销售对话；定义最小可信池：低于该数量和品类覆盖，客户浏览生态会认为已废弃。
23. 列出赌注依赖但你无法控制的事项，并为每项标注日期；补充功能就绪是真实风险而非细节。
24. 为签署的义务定价：命名所选层级产生的永久职责，并在承诺前指定负责人：表面稳定性和弃用政策（已发布接口存活多久、破坏性变更提前多久通知）；路线图边界（你自己构建在哪里停止；将补充功能吸收进核心有时正确，但未经宣布这样做会教其他人投资你不安全；发布界线，承诺越线前通知，承认界线可移动而非假装不然）；支持和升级（第三方的 bug 作为你的故障到达）；审查和安全（安全审查、范围和同意、撤销，在需要的层级）；关闭条款（通知期、迁移路径、数据导出，趁便宜时现在写好）。
25. 将每个已发布扩展点添加到责任登记册；该登记册而非架构图告诉你下一次重构是否负担得起。
26. 逐节编写备忘录并逐节验证：假设（步骤 1 的一句话声明）、证据（计数需求，附客户名称）、门槛（每个门槛：通过/失败/未知，未知的解决者）、层级（所选层级、被拒绝的层级及原因）、补充者案例（每个构建者原型的算术及价值分享原则）、飞轮（循环、补贴侧、创始 cohort、最小池）、义务（我们永久欠外部什么，附负责人）、测量（指标、今日基线、目标及日期）、终止标准（什么让我们停止、降级或关闭，附日期）；呈现每一节并在写下一节前达成一致；构建者原型判断错误会使下面一切无效，在第五个标题而非第九个发现要便宜得多。
27. 当门槛失败时写拒绝备忘录：一份带重新开放条件的文档化“不”就是交付物，跳过它正是同一个市场问题每两个季度回来的原因。
28. 在备忘录最终确定前，对照生态总是有的两类受众检查每一节：组织（你的产品买家及大多数补充者的雇主）需要消除风险——稳定性保证、可向审计师展示的安全审查、第三方应用损坏时的支持路径、三年后仍在的供应商；他们正是步骤 6 的义务成为真正产品的原因；个人开发者（内部构建者、独立补充者、爱好者）提供早期流动性和可信度，需要消除摩擦而非签署合同——几分钟内获得沙箱、诚实的文档、首次构建无守门；他们对任何读起来像陷阱的东西惩罚最重，一次未宣布的破坏性变更会损失多年善意；对两者同样有效的一件事：只有当构建者自己的算术成立时补充功能才会被构建；对个人也运行步骤 4，他们的货币是时间而非金钱，同样有限。
29. 在备忘录最终确定前将决策保持在此阈值并迭代直到通过：假设句子没有模糊空白且命名了商品化的补充功能；计数需求列出至少五个附有客户的请求补充功能而非人物角色（五个是本技能默认值，账户数千的产品提高它，仅在书面理由下降低）；每个门槛是通过或失败，每个剩余未知有解决者和日期；恰好选择一个层级且其所需的常设团队已命名并可用；被答案排除的层级从备忘录中删除而非列出，每个幸存未选层级有明确的阻塞原因；为每个原型写出补充者算术并至少一个产生正回报；步骤 6 的每个义务有指定负责人；每个指标今天存在基线值，目标带日期；终止标准包括至少一个带阈值和日期的失败条件。
30. 根据你自己的基线而非跨行业数字衡量运行中的计划：补充功能供给（每季度净新增补充功能及需求列表覆盖）；补充者激活（注册构建者中发布任何东西的比例及首次工作补充功能的时间）；客户采用（至少有一个活跃补充功能的账户比例，以及相对于没有的账户的保留和扩展差异——这是资助计划的数字）；集中度（前五补充功能占生态使用的比例，高意味着你有五个合作伙伴关系而非生态）；成本（被扩展点兼容性挟持的工程小时及第三方代码引起的支持工单）。
31. 避免常见失败模式：无需求的表面（扩展点发布无人构建，团队责怪开发者营销，原因几乎总是没人先计数需求）；Sherlocking 自己的补充者（发布使第三方补充功能变得无意义的特性，有时正确但绝不未经宣布）；来自隔壁的包络（邻近供应商将你的能力捆绑进其平台并吸收市场，在赌之前命名可能这样做的平台）；冻结架构（足够多已发布扩展点后产品无法重构，发布需求证明的最小表面，从第一天起版本化）；治理债务（审查队列、安全升级、弃用沟通和合作伙伴支持同时到达且无人配备，拒绝你无法配备的层级）；生态剧场（合作伙伴 logo 墙和无人安装的目录，报告每账户活跃补充功能而非宣布的合作伙伴）；补充者太瘦无法生存（拥挤品类、小可触达需求或过早施加的抽成——补充功能腐烂，客户遇到损坏的集成）；无退出标准（没人关闭生态计划因为撤回令人尴尬，在决策仍便宜时写终止标准）。

适用边界 · 注意事项

• 不适用于市场运营或 API 设计。
• 不适用于收入模型——应使用 samber/developer-relations-skills@devtools-business-model。
• 当生态创造的丰富性反而会商品化你自己时，答案是“不”，不应继续。
• 当门槛失败时（如无计数需求、无可外部化接口、无安全审查功能、无常设团队、不愿签署不可撤回义务），不应推荐更高层级。