适合自研四类
能力构成核心竞争力、业务流程独特、团队有稳定编制、需要长期迭代。为什么：这四条同时成立，自研的投入才可能转化为差异。边界是缺一条都要慎重，尤其团队不稳定时，自研成果很快无人维护，变成负债。
适合采购四类
通用能力、需求变化快、团队规模小、需要厂商 SLA。怎么判断：若这项能力换谁做都差不多，采购更省。边界是采购后深度定制会滑向自研，责任却仍在厂商，出现问题时容易互相推诿，合同要写清定制范围。
混合模式边界
采购底座加自研上层，是常见折中。为什么有效：把稳定且通用的部分交给厂商，把差异化的模板、规则与接口留在内部。边界是集成层要有明确归属与文档，否则升级时两边互相等待，故障定位也会变慢。
开源二次开发
开源可以降低成本，但维护责任转到内部。怎么判断：看社区是否活跃、许可证是否允许商用、团队能否跟进漏洞。边界是把开源当免费产品用而不投入维护，风险会在半年后集中出现，届时替换成本更高。
适用与不适用
适合谁
- 正在划分自研与采购边界的业务负责人
- 已采购产品、准备评估是否自研替换的团队
不适合谁
- 需求尚未稳定、无法判断差异化的项目
- 没有工程与运维配置、只想快速上线的小团队
典型场景
某零售企业把能力分成三类：会员画像与推荐策略自研，客服工单与知识检索采购，支付与发票走开源加二次开发。三类分别写明维护责任人与升级节奏，一年后复盘时，只有自研部分需要扩编，采购部分按合同续费，边界基本稳定。
可执行步骤
- 把拟建能力逐项标注是否构成差异化、是否可被替代，并写明判断理由，并留档备查
- 盘清团队编制、招聘能力与流失风险，判断能否长期维护关键模块，同时指定负责人
- 对每项能力写下自研、采购或混合的选择与理由，形成一页纸结论并签认
- 在合同里写明定制范围、集成层归属与升级责任，避免升级时互相等待，逐项确认后归档
- 设定年度复盘节点与触发条件，评估边界是否需要调整，并指定负责人，注明依据与时间
常见坑
- 把能定制当成差异化，采购后不断加需求，最后变成事实上的自研，却没有相应团队接手维护，后续无人负责。
- 缺少集成层归属约定，升级时厂商与内部互相等待，故障定位时间被拉长，业务只能绕开系统走线下流程。
- 把开源当免费产品用，不投入维护，漏洞与版本问题集中爆发，替换成本比当初采购更高，追责也更难。
自检与验收清单
- 每项能力是否标注差异化与可替代性，并说明理由
- 团队编制与长期维护能力是否评估并留档备查，指定负责人
- 自研、采购或混合的选择是否写明理由与责任人，并复核
- 定制范围与集成层归属是否写入合同附件并签认
常见问题
什么能力一定不能自研？
没有绝对答案，但通用能力通常不值得自研：身份认证、消息通知、基础检索这些换谁做都差不多，自研只会占用团队时间。真正该自研的是与客户选择、报价或交付质量直接相关的环节。
混合模式会不会更复杂？
会更复杂，但复杂度可控。关键是划清集成层归属、接口标准与升级节奏，并指定一个负责人。若两边都以为对方负责，升级时就会互相等待，问题也会在故障时才暴露，代价更高。
开源方案怎么定责任？
维护责任在采用方。要在立项时写明谁跟版本、谁处理漏洞、多久评估一次升级，并核对许可证是否允许商用。没有维护人的开源方案，本质上是一次性投入，后续风险由业务承担，也很难追责。