三个团队各写一套部署脚本，第四个人看不下去了，决定做平台。这个决定通常由"重复"这个直觉驱动：同样的东西写了三遍，合并成一遍当然更省。但它只算了一半的账。
内部平台的经济学是双向的：它把重复成本集中，同时把变更成本集中。以前三套脚本各自改各自的，改坏了只影响一个团队；现在一套平台，改一次影响三个团队，改坏了三个一起停。收益和风险同时被放大，倍数大致相同。
所以问题不是"要不要消除重复"，而是"这份重复的相似度够不够高、变化够不够慢"。相似度高、变化慢，集中划算；相似度低或者变化快，重复反而是分散风险的正确做法。
1. 四种形态，四种投入量级
平台不是一个东西，是一个梯度。跳级做平台，是内部平台项目最常见的失败方式。
| 形态 | 交付物 | 投入量级（按人月粗估） | 适用重复次数 |
|---|---|---|---|
| 脚本库 | 一批可复制的脚本 | 数人日 | 两三个团队，做法基本一致 |
| 模板 | 脚手架 + 约定目录 | 数人周 | 新项目频繁创建，结构需要统一 |
| 自助服务 | 带界面的申请与开通流程 | 一到数人月 | 请求量大，人工处理成为瓶颈 |
| 产品化平台 | 有 SLA、有版本、有支持渠道 | 数人年起 | 多团队长期依赖，成为事实标准 |
梯度不是成熟度阶梯，而是成本阶梯。多数场景停在模板层就够了；继续往上，等于用产品团队的成本去解决一个脚本能解决的问题。反过来，请求量已经排到两周后还在用脚本库硬撑，那也不是"朴素"，是欠账。
判断当前该停在哪一层，先算清重复的规模：
// 同一件事在各仓库的重复实现数（以部署脚本为例）
$ for r in repo-a repo-b repo-c; do
echo -n "$r: "; grep -rl 'deploy' $r/scripts 2>/dev/null | wc -l
done
// 每季度为重复维护花的小时数 ≈ 重复份数 × 单份改动小时 × 改动次数
// 低于"几天/季度"时，做平台的投入基本收不回
2. 三个判据：次数、相似度、变化速度
| 判据 | 该做平台 | 不该做 | 判据形态 |
|---|---|---|---|
| 重复次数 | 三个以上团队反复做同一件事 | 两个团队，且各有各的做法 | 可数，看仓库与工单 |
| 相似度 | 差异集中在参数，流程一致 | 流程本身不同，只是名字像 | 看差异点是配置还是分支 |
| 变化速度 | 需求半年内基本稳定 | 每季度都在改规则 | 看近两个季度的变更记录 |
三条里最容易被跳过的是相似度。"重复"不总是浪费：相似度低时，三套独立的实现比一套强行抽象的实现更便宜，因为抽象要在每个差异点上开一个开关，开关的组合最终会变成没人敢改的分支树。判断相似度有个便宜的办法：把三套实现并排放，看差异是"参数不同"还是"步骤不同"。参数不同 → 可以集中；步骤不同 → 集中会把两件事硬绑在一起。
相似度还有一层时间维度：今天的差异，可能半年后收敛。如果两个团队的做法差异来自临时约束，而这个约束正在消失，那么直接按未来的形态建平台是合理的；如果差异来自业务本质不同（一个对外、一个对内），它不会收敛，早点接受重复更省事。
变化速度决定平台的寿命。需求变化快的领域，平台每次都要跟着改，而平台的改动成本是乘了团队数的；这时候更划算的是给模板和约定，让各团队自己跟。
─── 平台化前的三问（任一为否，先别立项）───
1. 重复方 ≥ 3，且能在仓库里数出来？
2. 差异点主要是参数，而不是流程分支？
3. 近两个季度，这件事的规则改过几次？（> 2 次则缓）
4. 有没有现成开源方案能覆盖 80%？（能，就先评估再自建）
// 四个都过，再谈形态选哪一层
3. 第一批用户决定平台的命运
平台的第一批用户，应该选定制需求最少的团队。原因不是偏心，而是平台需要先长出稳定的主干：第一批用户提出的需求越接近主干，平台的核心就越快成型；反过来，如果第一批用户是需求最复杂的团队，平台会在第一个月就长满特例，主干永远没机会出现。
这件事的顺序很关键，而且不可逆。平台的第一版被特例塑形之后，后面每个团队接入时都要绕过那些特例，成本逐年累积。
权责边界要在立项时就写清楚，不写清楚必然在第三个月吵架：
─── 平台章程（立项时定，之后只增不改）───
谁定标准：平台团队定主干；业务团队可在自己仓库覆盖，但需登记
谁负责支持：平台团队负责主干与升级路径；业务侧负责自己的覆盖层
谁承担停机：平台故障由平台团队值班；覆盖层故障归业务团队
谁能提需求：任何团队；进 backlog 需说明影响几个团队
版本策略：主干向后兼容一个版本；破坏性变更提前一个季度公告
边界里最容易含糊的是"支持"。"平台团队负责支持"这句话听着清楚，实际会把所有业务问题吸到平台团队，最终平台团队变成一线支持组——这是平台失去产品属性的第一步。正确的写法是分层：主干问题平台担，用法问题文档担，覆盖层问题业务担。
采用率是唯一诚实的指标，功能数不是：
// 采用率：接入团队数 / 应接入团队数（按仓库依赖统计，不靠自报）
$ grep -rl 'platform-sdk' repos/*/pom.xml 2>/dev/null | cut -d/ -f2 | sort -u | wc -l
// 自助完成率：无人工介入完成的开通数 / 总开通数
// 特例比例：带例外的接入数 / 总接入数（> 30% 说明主干没长对）
4. 平台变成瓶颈的三个信号
| 信号 | 表现 | 机制层原因 |
|---|---|---|
| 排队 | 需求等平台排期，周期以周计 | 平台是唯一实现方，没有自助路径 |
| 特例增多 | 每个接入方都要开例外 | 主干抽象没覆盖真实差异 |
| 不懂业务 | 平台团队说不清谁在用、用来干什么 | 与业务脱节，只对接需求单 |
三个信号的共同根源是同一个：平台把"变更"集中了，却没有把"变更的通道"一起建起来。集中本身不是问题，单点才是。缓解方式不是加人，而是把一部分变更权还给业务侧——覆盖层、配置项、插件点，让业务能在不改主干的前提下解决自己的问题。
平台的成功判据只有一条：采用率上升，且特例比例不升。功能数增长而采用率不动，说明在做的是别人的需求，不是主干。这条判据要按季度看，不看单点。
"不做平台"也是合法决定，但要留下理由，否则半年后同样的问题会被重新提一遍：
─── 不做平台的决策记录（进 docs/decisions/）───
结论：本期不做内部平台，维持三套独立脚本
判据：重复方 2 个；差异点在流程分支；近两季度规则改过 4 次
代价：每季度重复维护约 X 人日；新人上手多一个路径
复查条件：重复方 ≥ 3，或规则变更降到每半年一次
复查时点：______
记录的重点不是结论，而是复查条件。没有复查条件的"不做"，等于把决定权交给下一次情绪。
能买就别造，这一条在平台领域尤其成立：CI、部署、配置管理、网关都有成熟的开源或商业方案，自建平台的合理理由通常是"现有方案的主流程与我们的约束冲突"，而不是"它们不够好看"。冲突点要能写成一句具体的话，写不出来就说明还没到自建的门槛。
5. 排错：平台做了但没人用
| 现象 | 真实原因 | 处置 |
|---|---|---|
| 接入率停在两三个团队 | 主干只覆盖了首批用户 | 让第二批用户参与需求排序 |
| 团队绕开平台自建 | 平台路径比自建更慢 | 先缩短开通路径，再谈规范 |
| 平台团队天天救火 | 支持边界没分层 | 把用法问题转文档，覆盖层归业务 |
| 功能越做越多，采用不涨 | 在做需求而不是主干 | 按采用率排优先级 |
| 平台改了，业务不敢升 | 破坏性变更没有预告期 | 兼容一个版本 + 提前一季度公告 |
第二条最值得警惕：绕开不是纪律问题，是路径成本问题。当平台的路径比自建更慢时，任何规范都拦不住绕开，因为绕开的人是在为交付负责。
6. 边界：投入很难收回的三种情形
| 情形 | 结论 | 理由 |
|---|---|---|
| 团队少于三个 | 不做平台 | 重复方不足，集中收益低于建设成本 |
| 重复工作每季度不足几天 | 不做平台 | 维护成本会超过节省的成本 |
| 需求变化极快（季度级改规则） | 只做模板与约定 | 平台改动成本乘以团队数 |
| 三个团队且流程高度一致 | 值得做，从模板层起 | 相似度高，抽象稳定 |
| 已成为事实标准且有多团队依赖 | 值得产品化 | 停机与兼容开始有真实成本 |
三种"不做"的情形有一个共同点：收益侧的量太小，而平台的建设成本是固定的。平台成本不会因为团队少而变少，它更像是先付一笔固定的基建费，再按团队数摊薄。团队数不够，摊不薄。
最后一条边界值得单独说：平台一旦成为事实标准，它就不再是"工具"，而是"基础设施"，评价标准也随之变化——从"好不好用"变成"停不停得起"。这时候该讨论的是值班、兼容与退出路径，而不是再加多少功能。
7. 自测
- 内部平台把哪两种成本同时集中了，为什么这两者倍数相近？
- 三个判据里最容易被跳过的是哪一个，跳过会付出什么代价？
- 为什么第一批用户要选定制需求最少的团队？
- 平台章程里"谁负责支持"为什么必须分层写？
- 平台变成瓶颈的三个信号，共同根源是什么？
- 哪三种情形下，平台化的投入很难收回？