模板复用管理方法大全：研发团队项目模板最佳实践落地清单

我见过最贵的一次模板事故，发生在一家 400 多人的研发组织：他们花了两周集中建设了 137 个项目模板，上线三个月后，PMO 做了一次全量盘点，发现其中 84 个模板从未被任何人使用过一次，而真正被反复复用的模板只有 6 个。更麻烦的是，团队为了绕开这些模板，私下复制出了 200 多个”野生模板”，字段命名、流程节点、状态机各说各话，半年后做跨团队数据汇总时，光是对齐字段口径就花了 3 人周。

这件事让我彻底改变了对”模板复用管理”的理解。模板复用管理的核心不是”把配置存下来”，而是”把约束沉淀下来并让它持续活下去”。前者是一个功能，后者是一套运营机制。市面上绝大多数讲模板的文章，都停留在”怎么建模板库”这一层，而真正的坑，几乎全部出现在”建完之后”。

这篇文章我会把自己在几十个研发组织里踩过的坑、验证过的方法、以及最终沉淀下来的落地清单，一次性讲清楚。它不是一份功能说明书，而是一份可以直接拿去执行、也可以拿去对照自查的施工图。

一、核心结论：先给判断，再讲论证

在展开所有细节之前，我先把结论放出来。如果你只读这一段，也应该能带走四个可以直接改变决策的判断。

1. 模板复用的本质是约束复用，不是配置复用

很多人把模板理解成”把一套工作项类型、字段、状态、流程打包存起来，下次一键生成”。这只是形式。真正被复用的，是团队对”一个项目应该长什么样”的共识，包括必须有哪几个阶段、每个阶段的准入门槛是什么、哪些字段是跨团队对齐的硬约束、哪些字段可以自由裁量。

如果你把模板当成配置快照，那它一定会随着配置变化而失效；如果你把它当成共识的载体，它就会随着共识演进被主动更新。这两种理解带来的维护行为完全不同。

2. 模板库的价值不在”有多少个”，在”有多少个被反复用”

我见过模板数量 200+ 但复用率不到 10% 的组织，也见过只有 9 个模板但复用率超过 70% 的组织。后者的跨团队协同效率明显更高。模板数量是一个虚荣指标，模板的”调用次数分布”才是健康度指标。

健康的分布应该接近幂律：前 5 个模板承载 60% 以上的项目创建量，长尾模板要么被合并，要么被淘汰。如果你的模板调用分布是一条平坦的直线，说明根本没有形成共识，只是把差异化包装成了”模板丰富”。

3. 模板必须配退役机制，否则三个月后必然腐烂

这是我最想强调的一条。绝大多数模板库的死亡，不是因为没人建，而是因为没人删。旧模板不会被主动清理，新模板又不断叠加，最终使用者面对一个 100+ 选项的下拉框，直接放弃选择，改为手工创建。

没有退役机制的模板库，生命周期通常在 3 到 6 个月。这不是团队不努力，而是机制缺失导致的必然结果。

4. 模板复用失败，九成不是工具问题，是”没有模板负责人”

我复盘过十几次失败案例，工具能力不足导致的失败占比不到 10%。真正的问题是没有一个明确的角色对模板的”内容质量 + 更新节奏 + 退役决策”负责。PMO 通常认为自己负责，但 PMO 的精力被项目跟踪占满，模板维护永远是排在最后的事。

所以落地清单的第一条不是”盘点模板”，而是先指定一个模板负责人（Template Owner），并给他每周固定的 2 小时。没有这个人和这段时间，后面所有方法都跑不起来。

二、真实场景：一个模板库是怎么在 12 个月里烂掉的

抽象的机制讨论不如一条真实的时间线。下面这条曲线，我在至少五个组织里见过几乎一样的版本。

1. 第 1 周：集中建设，声势浩大

通常是某个季度初，PMO 或研发效能团队发起”模板标准化专项”。拉上各业务线负责人开了三天会，把历史上用过的项目形态全部梳理一遍，最后沉淀出 100 多个模板。发布时还会配一份《模板使用规范》文档。

这个阶段的特点是：投入集中、产出可见、士气很高。所有人都会觉得”这事终于有人管了”。

2. 第 1 个月：使用率冲到峰值，然后开始下滑

因为刚被通知过，大家会主动去用。但很快出现第一批不适配：某个团队的项目比模板多了一个”安全评审”阶段，另一个团队的字段命名和模板不一致。这些人开始不走模板，改成手工创建或复制旧项目。

我在某组织看到的真实数据是：首个自然月模板调用率 41%，第二个自然月 33%，第三个自然月 22%。下滑不是线性的，而是每个月掉三到五分之一，这意味着第 6 个月就会跌到 10% 以下。

3. 第 3 个月：私有副本开始泛滥

这是最危险的阶段。使用者不再抱怨模板不合适，而是默默复制一个”最像自己的项目”作为模板使用。这些副本不进入模板库，不受任何治理约束，但它们实际上是活的模板。

更糟的是，这些副本还会被二次复制、三次复制，每复制一次就漂移一点。等你半年后再去盘点，会发现同一个业务场景存在十几种流程变体，而没有任何一份文档记录它们的差异来源。

4. 第 6 个月：模板库变成”垃圾抽屉”

此时模板库里有 150 多个条目，其中大量是过期的、重复的、命名混乱的。使用者打开下拉框要滚动很久才能找到疑似合适的那个，试错成本已经超过了手工创建成本。于是模板库彻底失去存在意义，但没有人正式宣布它失败。

5. 第 12 个月：清理时发现真相

年底做治理盘点，导出调用日志一看：62% 的模板调用次数为 0，前 5 个模板承担了 71% 的调用量。也就是说，当初两周的建设工作，真正产生价值的只有那 5 个模板，其余都是沉没成本。

而且更贵的成本在后面：为了清理这 150 多个模板、合并重复项、修复因字段漂移导致的报表断链，团队又花了接近 4 人周。建设成本是 2 人周，清理成本是 4 人周，这才是最真实的账。

三、七个误区拆解：为什么”照着最佳实践做”还是会失败

下面这七个误区，是我在实际复盘中反复见到的。它们的共同点是：看起来都对，但缺少一个前置条件或一个配套机制，就会从”最佳实践”变成”失败加速器”。

1. 误区一：把模板当成配置快照

表现是模板里塞满了具体字段值、具体负责人、具体迭代节奏。结果模板一旦被使用，团队第一件事就是改，改完就和模板脱钩了。

正确做法是把模板拆成”不可变约束 + 可变参数”两部分。不可变的是流程骨架、必填字段、状态机、跨团队对齐的枚举值；可变的是负责人、时间窗口、迭代长度、自定义标签。模板应该提供默认值，但必须明确标注哪些默认值鼓励修改。

2. 误区二：追求大而全的模板

一个模板覆盖”从需求到上线到运维”的全部环节，看起来专业，实际使用率极低。因为真实项目的起点和终点差异极大，一个全流程模板会让 80% 的团队觉得”至少三分之一跟我无关”。

我的经验是单个模板的活动类型不超过 12 种，状态不超过 8 个，必填字段不超过 10 个。超过这个量级，就应该拆分成多个可组合的模板模块。

3. 误区三：模板由 PMO 单向下发

PMO 从管理视角出发设计的模板，往往强调数据可汇总，而忽略执行者的录入负担。结果就是模板上线后，执行者在备注里写真实信息，在字段里填”其他”。

有效的做法是让模板的”首批使用者”参与设计，并给他们否决权。这不只是参与感问题，而是因为只有他们知道哪些字段是真正会填的。

4. 误区四：只做创建，不做治理

这是最普遍的。团队投入全部精力在”建多少个模板”，但没有定义谁负责更新、多久评审一次、什么条件下退役。模板库因此变成一个只进不出的容器。

5. 误区五：模板没有版本管理

模板被修改后，已经用旧版本创建的项目怎么办？是保持原样，还是批量同步？这个问题不回答，团队就不敢用模板，因为担心”模板一改，我的项目跟着乱”。

模板必须有版本号，并且默认”历史项目不回溯”，同时提供”手动升级”入口。让使用者自己决定是否同步，比强制同步带来的抵触小得多。

6. 误区六：忽略迁移成本

很多团队在更换项目管理平台时，只评估功能对比，不考虑已有模板、字段、工作流、历史数据的迁移路径。结果新平台上线后，模板体系要重建一遍，历史项目数据无法关联，跨年报表直接断档。

这一点的实操建议是：在选型阶段就把”模板与工作流能否结构化导出/导入”作为硬性门槛，而不是等到实施阶段才发现只能手工重建。

7. 误区七：用模板解决流程问题

团队明明存在的是”需求评审形同虚设”的问题，却指望通过加一个”评审必须通过才能进入开发”的状态门禁来解决。模板能约束形式，不能改变行为。流程问题要靠流程设计和管理动作解决，模板只是让流程变得可执行、可观测。

四、专业判断逻辑：什么样的模板才值得被复用

不是所有东西都值得做成模板。把不该模板化的东西模板化，会同时增加维护成本和执行负担。下面是我实际在用的判断逻辑。

1. 复用价值公式

我用一个简化公式做初筛：

模板复用净价值 = 单次节省时间 × 预期复用次数 + 一致性收益 − 维护成本 × 存续周期

这里最容易被低估的是”一致性收益”。它指的是因为字段、流程统一，使得跨团队报表可以自动汇总、度量口径可以横向对比所带来的价值。这部分价值在项目少的时候不明显，但当组织超过 200 人、并行项目超过 30 个时，往往超过前两项之和。

同样容易被低估的是”维护成本 × 存续周期”。一个模板只要存在，就需要被评审、更新、答疑，即使它一个月只被用一次。一个低频模板的维护成本，经常高于它节省的时间。

2. 四个判定问题

在把任何东西做成模板之前，我会先问四个问题：

1. 这个项目形态未来 6 个月会出现几次？少于 3 次的，先不要做模板。
2. 它的骨架是否稳定？如果每次的流程差异都超过 30%，说明还没有形成稳定模式。
3. 它是否涉及跨团队对齐？涉及对齐的，即使频次低也值得做，因为一致性收益高。
4. 谁来做维护？答不出具体人的，先不要做。

四个问题里有两个以上答不上来，就不应该进入模板库。宁可先手工创建三次，观察出稳定模式再沉淀。

3. 模板分层：四层架构

把所有模板放在一个层级里，是模板库失控的结构性原因。我通常把它拆成四层，每层的变更频率和治理方式都不同。

这个分层的价值在于：把治理成本集中投在 L1 和 L2，对 L3 只做备案不做审批，对 L4 完全放开。如果对 L3、L4 也做严格审批，治理成本会指数级上升，而收益几乎为零。

4. 分级的量化依据

判断一个模板应该放在 L2 还是 L3，我用的依据是”复用频次 × 变更成本”两个维度。高频次、低变更成本的，适合升到 L2 统一治理；低频次、高变更成本的，留在 L3 让团队自治；高频次但变更成本也很高的，说明流程本身还没稳定，应该先回到流程设计阶段，而不是急着模板化。

五、落地清单：从零搭建模板复用体系的六个步骤

下面这套清单我在多个组织里实际跑过，按顺序执行，通常 4 到 6 周可以完成第一轮闭环。每一步都给了可判断的完成标准，避免做成”看起来很完整但跑不起来”的方案。

1. 第一步：指定负责人并锁定时间

先解决”谁负责”。这个人不一定是专职，但必须有明确的职责描述和固定的时间预算。我的建议是每周不少于 2 小时，且写进绩效考核的次要项。

完成标准：能在组织内公开回答”模板找谁改”这个问题，并且这个人自己知道这件事是他的职责。

2. 第二步：盘点存量，做一次”归零式”清理

把所有现有模板导出来，做成一张表，字段包括：模板名称、创建时间、最近调用时间、累计调用次数、关联项目数、维护人。

然后做三件事：调用次数为 0 且创建超过 3 个月的，直接归档；最近 6 个月未调用的，标记为待淘汰；调用次数前 20% 的，进入重点治理名单。

这一步通常会让模板数量减少 50% 以上，而且几乎不会有人反对，因为那些模板本来也没人在用。

3. 第三步：定义组织级基线（L1）

L1 是整个体系的承重墙。它只包含三类内容：全局字段字典、状态机规范、跨团队对齐的枚举值。这三类内容必须由组织统一评审，不允许团队自行修改。

一个常见的错误是把太多东西放进 L1。判断标准很简单：如果某个约束不能让两个以上团队受益，就不应该放进 L1。

4. 第四步：用声明式方式定义模板

模板的定义方式决定了它能否被版本管理、能否迁移、能否评审。我强烈建议用声明式配置而不是界面点击来定义模板，因为前者可以进 Git、可以做 diff、可以走代码评审。

# template: delivery-project-v3.yaml
apiVersion: project-template/v1

meta:

name: 标准交付型项目

level: L2

owner: pm-office@example.com

version: 3.2.0

reviewCycle: quarterly

不可变约束：团队不得修改

constraints:

statuses:

{ key: todo,        name: 待启动,   category: planned }
{ key: planning,    name: 方案设计, category: planned }
{ key: developing,  name: 开发中,   category: started }
{ key: verifying,   name: 验证中,   category: started }
{ key: releasing,   name: 发布中,   category: started }
{ key: done,        name: 已完成,   category: completed }

requiredFields:

{ key: business_line, type: enum, source: L1.enum.business_line }

{ key: project_type, type: enum, source: L1.enum.project_type }

{ key: owner_dept, type: dept_ref, source: L1.org.departments }

gateRules:

{ from: developing, to: verifying, require: [code_review_passed] }

{ from: verifying, to: releasing, require: [test_report_attached] }

可变参数：允许团队在创建时调整

parameters:

iterationLength:

default: 2

unit: week

range: [1, 4]

editable: true

enableSecurityReview:

default: false

editable: true

可选模块：团队按需挂载

optionalModules:

key: security_review

name: 安全评审

states: [security_pending, security_approved]

owner: security-team

key: ops_readiness

name: 运维就绪检查

states: [ops_check]

退役规则

lifecycle:

reviewBy: 2026-03-31

archiveIf: { callsBelow: 3, withinMonths: 6 }

这段配置里最关键的是三个设计：constraints 不可改、parameters 可在范围内调、optionalModules 按需挂载。它同时解决了”约束必须统一”和”团队需要弹性”这对矛盾。

5. 第五步：建立分发与发现机制

模板做得再好，找不到等于没有。分发机制要解决三个问题：在什么位置出现、如何被搜索到、如何知道该选哪个。

我的做法是按项目创建入口的场景化引导：创建项目时先问”这是一个什么类型的项目”，根据回答只展示 3 个以内的候选模板，而不是丢一个包含 100 个选项的下拉框。选择后展示模板的流程预览和必填字段清单，让使用者在创建前就能判断是否合适。

6. 第六步：建立度量与退役闭环

没有度量的治理是盲治。下面这张表是我实际在用的模板健康度指标，每季度看一次，每次不超过 20 分钟。

这五个指标里，我最看重的是“创建后 2 周内改动率”。它是唯一能直接反映”模板是否真的贴合实际”的指标，比复用率更难被美化。

六、平台能力对照：模板复用对工具的真实要求

方法讲完了，接下来是工具层面。工具不能替代机制，但工具能力不足会让机制无法落地。我在选型和实施过程中，把模板复用对平台的要求归纳成五条硬性能力，并按不同平台的满足程度做了对照。

1. 五条硬性能力要求

1. 模板的结构化定义与导出：模板必须能完整导出为结构化文件，而不是只能通过界面点击复现。这是版本管理和迁移的前提。
2. 模板版本与历史项目隔离：模板更新后，历史项目默认不受影响，同时提供手动升级入口。
3. 字段级约束与继承：组织级字段字典能被模板继承，模板又能被团队变体继承，且继承链可追溯。
4. 工作流门禁能力：状态流转可以绑定准入条件，例如必须关联特定类型的记录才能进入下一状态。
5. 调用与使用数据可导出：能导出模板调用次数、调用时间、关联项目等数据，否则度量体系无法建立。

2. PingCode 在模板复用场景下的实际表现

我在给几家中大型企业做研发效能选型时，比较集中地测试过 PingCode。它的定位是服务中大型企业及 100 人以上组织，这个定位恰好覆盖了”模板复用真正开始产生收益”的规模区间，组织小于 100 人时，靠口头约定就能对齐，模板复用的边际收益并不明显。

在模板能力上，PingCode 让我比较认可的是工作项类型、字段、状态、工作流的组合配置可以按项目模板整体沉淀，并且支持在创建项目时按模板生成。字段可以设置为组织级统一，团队无法在项目内随意改写，这一点直接对应了前面讲的 L1 基线需求。

另一个在实际落地中很关键的能力是工作流状态流转的准入规则。前面那份 YAML 配置里写的 “从开发中流转到验证中必须代码评审通过”，在 PingCode 里可以通过流转条件直接配置，而不需要靠人在流程外做检查。这一点对于把模板从”形式约束”变成”执行约束”非常重要。

PingCode 支持私有化部署，这在金融、制造、政企类组织中往往是选型的硬门槛，因为项目模板里通常包含组织结构、业务线划分等敏感信息。同时它支持从 Jira 平滑迁移，包括工作项类型、字段、工作流、历史数据的结构化映射。这一点在模板复用场景下尤其重要：如果迁移过程中模板体系要重建，前面讲的 4 到 6 周落地周期就得重走一遍。

3. 能力对照表

4. 一个容易被忽略的取舍：平台迁移期怎么处理模板

我处理过的一次迁移中，团队有 60 多个在用模板，全部重建花了 3 周。后来总结出的做法是：迁移前先做一次归零式清理，只迁移调用次数排名前 20% 的模板，其余用”迁移期临时手工创建”过渡。这样迁移工作量能压缩到原来的三分之一，同时顺手完成了模板治理。

这也是为什么我把”结构化导出能力”放在优先级第一位，它决定了你在迁移时是选择”全部搬”还是”选择性搬”，而后者的成本优势非常明显。

七、不同规模团队的行动建议

“最佳实践”最大的问题是它默认了一个特定规模。50 人团队照搬 1000 人组织的模板治理体系，结果一定是治理成本压垮收益。下面按规模给建议。

1. 30 人以下：不做模板库，做”参照项目”

这个规模下，团队对彼此的工作方式有充分了解，模板库的收益很低。我建议只保留 2 到 3 个”参照项目”，新项目直接从参照项目复制，配一份一页纸的说明讲清楚哪些字段必须改。

不要建模板库，不要做评审流程，不要设模板负责人。这些动作在这个规模下都是负收益。

2. 30 到 200 人：从”参照项目”过渡到轻量模板

这个阶段开始出现跨团队协作，字段不一致的问题会暴露。建议先做 L1 基线（字段字典 + 状态机规范），模板数量控制在 5 个以内。

负责人可以是兼职（每周 1 小时），治理方式是”季度看一眼调用数据，把没人用的删掉”。这个阶段不要建立复杂的度量体系，只需要一个”僵尸模板清单”。

3. 200 到 1000 人：建立完整的分层体系

这是模板复用收益最明显的区间。跨团队报表、跨项目度量、多业务线对齐的需求同时出现。建议完整落地 L1，L4 四层架构，建立五个健康度指标，模板负责人按每周 2 小时投入。

这个阶段还要开始考虑工具能力。字段强制统一、工作流门禁、调用数据导出这三项必须满足，否则治理体系无法运转。

4. 1000 人以上：模板治理变成组织能力，需要平台化

这个规模下，模板的数量和变体已经超出人工管理能力。核心动作是把模板定义代码化、把评审流程化、把度量自动化。

具体来说：模板定义进 Git 走合并请求评审，健康度指标做成自动看板，超过阈值自动提醒；同时需要按业务线设置”模板子负责人”，形成分层治理网络，而不是靠一个中心角色硬扛。

这个规模的组织在选型时，通常还会把私有化部署、权限隔离、审计日志作为硬性要求，因为模板里沉淀的往往是组织级的流程资产。

八、五个必须做出的取舍

模板复用管理的难点不在于”做什么”，而在于”在哪一边停手”。下面五个取舍，是我在实际推进中反复要面对的。

1. 标准化程度 vs 团队灵活性

标准化的收益来自一致性，成本来自灵活性损失。我的判断方法是：只标准化那些”不一致会直接导致下游工作无法进行”的东西。字段命名不一致会导致报表断裂，所以要标准化；看板列顺序不一致不会导致任何问题，所以不要标准化。

这条线画错了，团队会开始用脚投票。

2. 集中治理 vs 团队自治

集中治理保证一致性但响应慢，团队自治响应快但容易发散。我的做法是分层：L1 集中治理，L2 集中评审，L3 备案自治，L4 完全放开。

关键是要明确告诉团队”L3 你可以自己改，但要在清单里登记”，这样既给了自由，又保留了可追溯性。

3. 模板数量 vs 查找成本

每增加一个模板，筛选成本就上升一点。当模板超过 20 个以后，使用者在下拉框里的决策时间会显著增加。我的经验阈值是 L2 模板不超过 12 个，超过就应该考虑合并或改成”骨架 + 模块”的组合方式。

4. 强制使用 vs 引导使用

强制使用短期数据好看，但会催生”表面合规”，字段填了但填的是”其他”。我的建议是：L1 约束强制，L2 模板强推荐，L3 完全自愿。

同时用”创建后 2 周内改动率”这个指标反向监控：如果强制使用后改动率飙升，说明模板确实不合适，应该改模板而不是加强管控。

5. 自建 vs 采购

自建在数据自主性和定制深度上有优势，但模板治理的很多能力（门禁、版本隔离、迁移、权限）需要持续投入开发资源维护。我的判断标准是：如果模板只是团队内部用、不超过 5 个，自建够用；一旦要跨团队、跨业务线，且涉及数据合规要求，就应该走采购路线。

因为跨团队场景下，模板治理需要的能力恰好是通用平台已经做过大量验证的部分，自建等于重走一遍别人的弯路。

九、度量与持续优化：让体系自己运转起来

前面所有动作，如果没有一个能自己运转的度量闭环，最终都会退化回”想起来才管一管”的状态。

1. 季度评审会的三个固定议题

1. 僵尸模板清理：列出 6 个月零调用的模板，当场决定归档还是重做。
2. 高改动率模板复盘：找出创建后 2 周内改动率超过 30% 的模板，访谈 3 个使用者，定位是哪个字段或哪个环节不匹配。
3. 新形态识别：查看是否有团队连续 3 次以上手工创建相似项目，如果有，说明缺少对应模板，进入下一轮设计。

三个议题控制在 60 分钟内，输出必须包含明确的责任人和时间点，否则会议就是浪费。

2. 版本更新的节奏控制

模板更新太频繁会让使用者无所适从，更新太慢又跟不上业务。我的做法是把 L2 模板固定为季度更新窗口，窗口外只处理”导致流程无法进行”的紧急修正。

同时每次更新都要在模板描述里写清楚变更内容，让使用者在选择模板时能看到”这一版改了什么”。这个细节能显著降低使用者的不信任感。

3. 一个反直觉的观察

我在多个组织里注意到一个现象：模板版本更新频率与复用率之间不是正相关，而是倒 U 型。完全不更新，复用率会因失配而下滑；每季度更新一次的组织复用率最高；而每月都在更新的组织，复用率反而下降，因为使用者疲于跟进变化，干脆手工创建。

这个观察让我把”更新频率”从”越高越好”改成了”有节奏地更新”。节奏本身就是一种治理能力。

十、下一步：从今天开始做的三件事

这篇文章的方法密度比较高，但落地不需要一次全做。如果你现在就想动手，我建议按下面的顺序推进，每一件都能在一周内看到结果。

1. 第一件事：导出模板调用数据，看分布

这是唯一一件不需要任何决策就能做的事。把模板的累计调用次数、最近调用时间导出来，排个序，看看 Top 5 占比多少、有多少个是零调用。

如果零调用的模板超过 30%，说明你的首要任务不是建新模板，而是清理旧模板。这一步通常只需要半小时，但它会直接告诉你后面该往哪投入。

2. 第二件事：为 Top 3 模板指定负责人

不要一上来就搞全面治理。先挑调用量最高的 3 个模板，给每个指定一个负责人，约定季度评审一次。把这 3 个模板的字段和流程打磨到”使用者创建后 2 周内几乎不需要改”的程度，再考虑扩展。

这三个模板会变成你的样板间，后面所有模板都参照它们的质量标准来做。

3. 第三件事：把”结构化管理”作为下一次选型的硬门槛

如果你正在或即将做平台选型、平台迁移，把”模板能否结构化导出、组织级字段能否强制统一、工作流能否配置流转门禁”这三条写成硬性要求。

这三条决定了你今天积累的模板治理成果，明年还在不在。我在多次迁移中见过太多团队，因为选型时没提这三条，导致几年的模板沉淀在换平台时归零，然后从”137 个模板、6 个有用”的原点重新开始。

模板复用管理的本质，是让组织关于”一个项目应该怎么跑”的共识，能被低成本地传递、被有节奏地更新、被明确地淘汰。它管的是共识，不是配置。想清楚这一点，前面所有的方法和清单，都会变得顺理成章。