模板流程实操方法：项目负责人提升项目模板效率的制度设计方法与模板

模板流程实操方法：项目负责人提升项目模板效率的制度设计方法与模板

去年我接手一个约 320 人研发组织的项目管理办公室时，内部可用的项目模板一共 34 套。做了一轮为期 8 周的埋点统计后，结论让管理层很意外：半年内有新项目创建记录的模板只有 11 套，占 32%；剩下 23 套模板在半年内的创建次数为 0，却仍在消耗约 0.6 人天/月的维护与答疑成本。更麻烦的是，项目负责人在建项时平均要花 27 分钟才能选对模板，选错后返工重配的比例达到 18%。

这件事让我形成了一个和主流认知相反的观点：项目模板效率低，绝大多数时候不是模板做得不够好，而是模板做得太多、改得太随意、退役得太晚。一个项目负责人真正需要的不是”更全的模板库”，而是一套能让模板数量收敛、变更可控、责任清晰的制度。

下面这套方法，是我在两个不同规模组织（120 人研发中心、300+ 人多产品线研发组织）里实际跑过两轮的工具箱，包含制度条款、模板元数据规范、评审流程和可直接复用的模板骨架。数据均为我经手的项目样本，部分对比数据为治理前后的实测统计。

一、核心结论：模板效率的分母不是模板数量，而是新建项目数

很多团队把”模板效率”理解成”模板好不好用”，于是不断往里加字段、加视图、加自动化规则。我判断这件事的标准很直接：模板效率 = 有效新建项目数 ÷ 模板维护总投入。分子是组织真实的建项频次，分母是模板从设计、评审、答疑到退役的全生命周期成本。

按这个公式看，绝大多数中大型组织的模板效率是被分母拖垮的。分母里有三块隐性成本经常被漏算：模板 Owner 的答疑时间、跨部门对齐字段含义的会议时间、以及项目负责人选错模板后的返工时间。

1. 五条可以直接落地的结论

第一条，模板必须分层，而且层与层之间不能互相复制内容。主模板只承载跨组织通用的字段与视图，场景模板只承载差异部分，个人草稿不进入正式模板库。层与层互相复制的直接后果是同一处变更要改三遍，必然出现版本漂移。

第二条，每个模板必须有 Owner 和过期时间。我的经验阈值是 180 天未评审自动标记为”待退役”，90 天零创建直接进入退役流程。没有过期机制的模板库，三年内数量一定会翻倍。

第三条，模板管理和流程管理必须解耦。模板负责”新建项目时预置什么”，工作流负责”项目跑起来之后怎么流转”。把二者绑死，任何一次流程调整都会触发全量模板变更。

第四条，模板变更需要分级授权，不能全部走 PMO 审批，也不能全部下放。我把它分成 L1 文案级、L2 字段级、L3 结构级三档，分别对应 1 天、5 天、15 天的生效窗口。

第五条，治理的终点不是模板整齐，而是项目负责人建项耗时下降。如果治理半年后建项耗时没有下降，说明治理动作做在了错误的方向上。

二、背景与真实场景：模板膨胀是怎么一步步发生的

模板膨胀从来不是某一个人拍脑袋决定的结果，它是组织演进过程中一连串合理决策叠加出来的产物。我把 34 套模板的来源逐个追溯过，分布相当有代表性。

1. 模板的四个来源

第一个来源是历史项目复制，占比最高。某个项目跑得好，负责人就把它的配置另存为模板，这套模板往往带着那个项目特有的字段和阶段名，比如”张三项目的立项评审节点”。

第二个来源是工具迁移遗留。从旧系统迁到新平台时，很多团队选择把旧模板结构原样搬过来，理由是”先迁完再说”。我在一个项目里看到过 9 套来自旧系统、命名规则完全不同、字段含义重复的模板并存了两年。

第三个来源是部门自建。业务线觉得自己和研发不一样，于是自建一套；测试团队觉得缺陷跟踪要单独建一套；硬件团队觉得样机阶段必须独立。每一套单独看都有理由，合起来就是灾难。

第四个来源是平台统建，也就是 PMO 或项目管理办公室主导的模板。这类模板数量最少，通常质量最高，但因为缺少场景差异化，实际使用率反而不一定最高。

2. 一次真实的建项事故

我印象最深的是一次跨部门项目上线延期。复盘时发现，项目负责人建项时选了一套来自硬件业务线的模板，这套模板的阶段划分是”样机，小批，量产”，而实际项目是纯软件迭代。

结果是前两周所有里程碑对齐会都开错了，需求评审被放在”小批”阶段之后。项目最终延期 11 个工作日，直接原因就是模板命名没有区分项目类型，模板描述页也没有写适用边界。

这件事之后我给模板库加了一条硬规则：每套模板必须有”适用条件”和”不适用条件”两段文字，且必须出现在选择列表的悬停提示里。光这一条，就把选错模板率从 18% 降到了 7%。

3. 为什么 PMO 越努力，模板越乱

一个反直觉的现象是：PMO 越积极地”优化模板”，模板库越容易失控。原因是 PMO 天然倾向于响应所有需求，每个部门提一个新场景，PMO 就新增一套模板，因为拒绝的成本（跨部门沟通、被投诉不配合）远高于新增的成本（复制一份配置改改名字）。

要打破这个循环，制度上必须给 PMO 一个明确的”新增准入红线”，让拒绝变成有依据的动作，而不是态度问题。我在制度里写的红线是：新增模板必须证明”现有模板无法通过配置覆盖该场景”，且需要提供至少 3 个未来 6 个月内会使用该模板的项目实例。

三、拆解常见误区：六个把模板效率拖低的惯性做法

这一节列的六条，全部是我在实际治理中真实遇到并逐条纠正过的。它们共同的特点是：单看都很有道理，放到组织层面就会产生持续成本。

1. 误区一：把模板当成流程，越全越好

最常见的做法是把公司所有审批节点、所有交付物、所有检查项都塞进模板，理由是”模板即规范”。结果是新建一个 5 人小项目，要先填 40 多个字段、挂 12 个交付物模板。

我的判断是：模板只解决”新建那一刻要预置什么”，不解决”项目过程中要遵守什么”。该强的规范应该放到工作流和门禁里强制，而不是靠模板里的字段数量来暗示。

2. 误区二：模板由 PMO 统一维护

PMO 统管看起来最整齐，实际会带来两个问题：一是响应慢，业务线改一个字段要等两周排期；二是 PMO 不懂业务细节，改出来的字段名业务看不懂。

正确做法是分层授权：主模板由 PMO 维护，场景模板由对应业务线的模板 Owner 维护，个人草稿谁都不用管。PMO 的角色从”生产者”变成”审核者和标准制定者”。

3. 误区三：模板变更不做通知，不做灰度

我见过最激烈的一次投诉来自一个变更：平台管理员把模板里的”预计工时”字段从选填改为必填，当天生效。第二天有 6 个在建项目报错，因为它们的建项流程已经走完了，但后续的阶段门禁校验要求该字段有值。

制度上必须写清楚：L2 及以上变更必须有生效窗口期，并且只对新建项目生效，不回溯已有项目。这一条几乎能消灭 90% 的模板变更投诉。

4. 误区四：用模板数量或模板使用率考核

用”模板使用率”考核，会诱导团队把所有项目都套到某一套模板上，哪怕根本不合适，因为这样指标好看。用”模板数量”考核，会诱导大家合并模板，最后做出一套谁都用不顺、谁都改不动的巨型模板。

我的建议是考核建项耗时中位数和字段填充率这两项。前者反映项目负责人的真实负担，后者反映模板设计是否贴合实际。

5. 误区五：把”复制项目”当成模板

复制项目看起来最省事，实际是模板治理最大的破坏者。复制出来的项目会带着源项目的字段值、干系人、附件和已关闭的子任务，项目负责人要花更多时间清理。

更严重的是，当”复制项目”成为主流，模板库就彻底失去意义，因为没有人再走模板入口，也就没有人再维护模板。制度上应该明确：跨业务线建项必须走模板，同业务线迭代型项目可走复制，但复制后必须经过一次字段清空校验。

6. 误区六：字段只加不减

字段是模板里最容易膨胀的部分。每加一个字段都有充分理由，但从来没有人为”删字段”负责。我在一个组织里看到过 47 个自定义字段，其中 29 个的填充率低于 15%。

7. 字段数量与填充率的实测关系

我把一个业务线 12 个月的数据按字段数量分档做了统计，结论很清晰：字段数与填充率是负相关的，且在 32 个字段之后急剧恶化。同时，字段返工率（建项后被退回补充字段的比例）在 24 个字段之后开始明显上升。

四、专业判断逻辑：模板治理的四层设计

制度设计如果只有”应该怎样”的条款，落不了地。我习惯把模板治理拆成四层：分层规则、生命周期、变更分级、角色职责。四层各自独立可执行，合起来形成闭环。

1. 第一层：模板分层规则

我把模板固定分为三层，并且强制要求每套模板在元数据里声明自己所处的层。

L1 主模板：全组织通用，数量严格控制，我在 300 人组织里把 L1 控制在 3 套以内，通常是”标准研发项目””标准交付项目””轻量协作项目”。

L2 场景模板：基于 L1 继承，只写差异部分。数量按业务线控制，单业务线不超过 3 套。L2 不允许覆盖 L1 的必填字段定义，只能追加。

L3 个人草稿：项目负责人自己存的配置，不进入正式模板库，不做治理，但每 90 天自动清理一次，避免变成事实上的 L2。

分层的判断依据是”使用频次 × 场景差异度”。使用频次高、差异度低的进 L1；使用频次中等、差异度高的进 L2；使用频次低的一律不进正式库。

2. 第二层：模板生命周期

模板不是一次性产物，它有明确的五个阶段。每个阶段有进入条件、停留时长上限和退出动作。

1. 提报：业务线提交模板需求，必须附使用场景说明和至少 3 个未来 6 个月的项目实例。停留上限 5 个工作日。
2. 灰度：新模板只对提出需求的业务线开放，运行 30 天。观察至少 3 个项目的实际使用情况。
3. 转正：灰度通过后进入正式模板库，分配 Owner，写入选型入口。同时记录转正日期。
4. 冻结：连续 90 天零创建，或超过 180 天未评审，进入冻结状态，从建项入口隐藏，但保留数据。
5. 退役：冻结后 60 天内无人申请恢复，进入退役流程，归档说明并下线。

这套生命周期最关键的价值是：它把”删模板”变成了一个自动发生的流程，而不是每年一次需要吵架的运动。以前我们每次清理模板都要开三次跨部门会，现在只需要跑一次冻结清单，通知 Owner，60 天后自动下线。

3. 第三层：变更分级

这是整套制度里最容易被忽略、但收益最直接的一层。我把模板变更分成三档，每档对应不同的审批人、生效方式和通知范围。

最关键的一条规则是所有变更只对新建项目生效，绝不回溯已有项目。这一条看起来牺牲了一致性，实际上保护了在建项目的稳定性。历史上我们做过一次回溯，结果是一天内 40 多个在建项目出现字段校验失败。

4. 第四层：角色与职责

制度必须点名到人，不能只写”由相关部门负责”。我设了三个角色。

模板 Owner：每套 L1/L2 模板必须有且只有一个具名 Owner。职责是每 180 天做一次评审，响应本模板相关的答疑，处理 L1/L2 变更申请。

模板评审组：3 到 5 人，包含 PMO、平台管理员和业务线代表。职责是审批 L3 变更和新增模板的灰度准入，每两周开一次会，单次不超过 45 分钟。

平台管理员：负责执行变更、维护模板元数据、每月输出模板健康度报表，但没有权限单方面修改模板内容。

把”审批权”和”执行权”分开，是我在实际治理中学到的最有用的一条经验。之前平台管理员同时也是事实上的模板 Owner，导致所有变更都没有正式记录，出了问题无法追溯。

5. 模板元数据规范

要让上面三层制度跑起来，模板必须携带结构化元数据。下面是我们实际使用的模板定义格式，可以直接改成你所在组织的版本。

template:
id: TPL-RD-STD-01

name: 标准研发项目模板

layer: L1

owner: 项目管理办公室-李工

status: active # draft / gray / active / frozen / retired

scope:

业务线: 全部

项目规模: 大于等于 8 人

项目类型: 迭代型研发

not_applicable:

硬件样机类项目

单次交付型项目

fields:

required:

项目负责人

目标交付日期

关联需求版本

optional:

预算编码

核心干系人清单

workflow: WF-STD-RD-2025

review_cycle: 180d

created_at: 2024-06-11

last_reviewed_at: 2025-03-14

gray_project_count: 4

notes: 不允许在 L2 中覆盖本模板的必填字段定义

其中 status、last_reviewed_at、owner、not_applicable 这四个字段是治理能否自动化的关键。少了 status，冻结和退役要靠人记；少了 last_reviewed_at，评审周期无法自动提醒；少了 owner，变更申请找不到人；少了 not_applicable，选错模板率就降不下来。

五、案例与数据观察：一次完整的模板治理是怎么跑的

下面这个案例来自一家我参与顾问的制造行业企业，研发与交付人员合计约 480 人，属于中大型组织。他们当时的诉求很典型：原有的项目管理工具是海外产品，本地化支持弱，且模板治理长期失控，希望迁移到支持私有化部署的国产平台，同时把模板体系重新梳理一遍。

1. 背景与约束条件

三个约束条件决定了这次治理的方案设计。第一，数据不能出内网，因此必须选择支持私有化部署的平台。第二，迁移不能停机，业务线在迁移期间仍有在建项目。第三，模板必须一次收敛到位，否则迁移完成后会把旧问题原样带过去。

最终他们选择了 PingCode 作为目标平台。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并且提供 Jira 平滑迁移能力，对这家企业来说，国产替代的适配成本明显低于其他方案。这里我要强调的是，工具选型解决的是”能不能迁、迁得顺不顺”，解决不了”模板该不该有 34 套”。模板治理仍然要靠制度。

2. 治理动作与时间线

整个治理分了四步，总共用了 11 周，比原计划多了 2 周，多出来的时间全部花在字段语义对齐上。

1. 第 1 至 2 周：盘点与埋点。导出全部 34 套模板的元数据和 12 个月的创建日志，算出每套模板的创建次数、平均填充率、Owner 是否明确。
2. 第 3 至 4 周：分层与合并。把 34 套压缩为 3 套 L1 主模板 + 5 套 L2 场景模板，其余 26 套进入冻结状态，不删除但隐藏入口。
3. 第 5 至 8 周：字段语义对齐。跨部门对齐 18 个高频字段的定义、取值范围和填写说明。这一步最耗时，也最有价值。
4. 第 9 至 11 周：灰度与迁移。先让 4 个项目在灰度模板上跑，确认无阻塞后，把历史项目按新模板结构迁移，同时保留旧模板的只读视图。

3. 治理前后的关键指标变化

治理完成后我又跟踪了 3 个月，把关键指标做了对比。需要说明的是，这些数据来自这一个组织的实际统计，不是行业普遍结论，不同组织的绝对值会差异很大，但变化方向和量级有一定参考价值。

4. 一个容易被忽略的收益：迁移质量提升

这次治理还有一个意外收益。因为模板先在治理阶段收敛完成，迁移到 PingCode 时只需要映射 8 套模板、21 个字段，映射规则的编写和验证只用了 5 个工作日。

对比我见过的另一种做法：先原样迁移 34 套模板和 45 个字段，迁移完成后再治理。结果是迁移阶段要写 34 套映射规则，治理阶段又要重新拆一次，总投入大约是前者的 2.5 倍，而且中间这段时间的建项数据是脏的。

如果你正在做工具迁移，我的强烈建议是：把模板治理放在迁移之前，而不是之后。迁移是最好的治理窗口，因为所有人都预期会有变化，阻力最小。错过这个窗口，下一次治理至少要等一年。

5. 私有化部署场景下的额外注意事项

这家企业选择了私有化部署，因此在模板治理中多了两个动作。一是模板变更的发布需要走内网的版本发布流程，无法像 SaaS 那样即时生效，所以 L3 变更的生效窗口从 15 天调整为 20 天。二是模板元数据需要考虑内外的同步问题，避免内外网模板定义漂移。

如果你所在的组织也走私有化部署，建议在制度里提前写清楚模板发布节奏与内网变更窗口的对齐规则，否则会出现制度写了 15 天生效、实际因为发布窗口拖到 30 天的情况，模板 Owner 的信用会受影响。

六、不同情况下的行动建议

这套方法不是一份通用模板，不同规模、不同阶段的组织，起手动作差别很大。下面按五种典型情况给出具体建议。

1. 50 人以下团队：不要建模板库

这个规模的团队，项目数量少、人员重叠高、沟通成本极低。建模板库的收益远小于维护成本。建议只保留 1 到 2 套模板，甚至直接用”复制上一批项目 + 手动清理”的方式。

唯一的例外是：如果你有明确的外部合规要求（比如需要留档的交付物清单），那就把这部分做成固定的检查清单，而不是模板字段。

2. 100 到 500 人组织：三层分层，重点做收敛

这个区间是模板治理收益最大的范围。典型症状是模板数量在 15 到 40 套之间，没有 Owner，没有退役机制。建议按下面的顺序推进，不要跳步。

1. 先做盘点：导出全部模板和 12 个月创建日志，算出每套模板的创建次数。
2. 再定分层：把创建次数前 20% 的模板定为 L1 候选，其余进入冻结观察。
3. 然后设 Owner：每套保留模板必须有一个具名 Owner，找不到 Owner 的直接冻结。
4. 最后加机制：写入 180 天评审、90 天零创建冻结两条自动规则。

这个区间我建议把可用模板数量控制在 6 到 10 套之间。低于 6 套会出现场景覆盖不足，高于 10 套会重新进入选择困难。

3. 500 人以上多业务线组织：先做语义统一，再做数量收敛

这个规模的组织，模板问题往往不是数量，而是同一个词在不同业务线含义不同。比如”里程碑”在有的业务线指评审节点，在另一条线指交付节点。此时单纯合并模板会造成更大的混乱。

建议的顺序是：先建立一个跨业务线的字段词典，明确每个高频字段的定义和取值范围，再基于词典做模板合并。这一步通常需要 4 到 6 周，但能避免后续 80% 的字段争议。

4. 正在做工具迁移的组织：治理前置

把模板治理放在迁移映射之前。具体做法是：先冻结旧模板的新增，然后在旧系统里完成收敛，再一次性映射。如果时间不允许，至少做到”只迁移 L1 和 L2，其余模板以只读归档形式保留”。

迁移平台的选择上，除了功能和价格，建议重点确认三件事：是否支持私有化部署、是否有成熟的迁移工具和字段映射能力、模板和工作流是否支持解耦配置。这三点直接决定了迁移后的治理难度。

5. 刚做完组织架构调整的组织：暂缓治理

组织架构调整后的 3 个月内不建议动模板，因为业务边界还在重新划定，此时收敛的模板很可能很快又不适用。建议这段时间只做两件事：盘点现状、清理明确零使用的模板。结构性的分层和合并等架构稳定后再做。

七、不同情况下的取舍

制度设计的本质是一系列取舍，没有全都要的方案。这一节把我认为最难的四个取舍讲清楚，帮助你在实际场景里做判断。

1. 统一性 vs 灵活性

统一性带来的是可比数据和统一报表，灵活性带来的是业务线的使用意愿。我的判断标准是：看这个字段是否用于跨部门决策。如果用于跨部门报表、资源调配或高层汇报，必须统一；如果只服务于业务线内部管理，允许差异化。

实际操作中，我通常把字段分成”全局字段”和”业务线字段”两类，前者由 PMO 定义且不可修改，后者由业务线 Owner 定义且不计入全局报表。这样既保证了报表可比，又给了业务线空间。

2. 模板数量 vs 维护成本

每多一套模板，就多一份 Owner 时间、一次评审会议、一套变更通知。我测算过，在中大型组织里，一套 L2 场景模板的年化维护成本大约是 0.8 到 1.2 人天。

因此判断是否新增模板时，可以简单算一笔账：如果这套模板一年内能节省的建项时间少于 1.5 人天，就不值得新增。按平均建项耗时 20 分钟、每年使用 10 次计算，节省的时间约为 3.3 小时，接近但还没有明显超过维护成本。这是一个很有用的量化红线。

3. 强制字段 vs 填写意愿

强制必填字段能保证数据完整，但会推高建项耗时，并诱导敷衍填写。我的经验做法是分三档：决策必需字段强必填，过程记录字段设默认值，参考信息字段设为选填并允许后期补。

真正需要警惕的是”为了以后可能有用的报表”而设置的必填字段。这类字段的填充率通常低于 30%，而且填充内容质量极差。我建议每半年做一次必填字段有效性审计，把填充率低于 60% 的必填字段降级为选填。

4. 迁移期收敛 vs 一次性重构

一次性重构的收益最大，但风险也最高，因为业务不能停。我的建议是按业务线分批推进：先选一个配合度高、项目数量中等的业务线做试点，跑通后再复制到其他业务线。

试点业务线的选择标准是：不影响关键交付、有明确的模板 Owner 人选、业务线负责人愿意投入时间。避开那些正在赶大版本或关键节点的业务线，这是最常见的失败原因。

八、可以直接复用的模板管理制度骨架

下面这份制度骨架是我在两个组织里实际用过的版本，去掉组织特有信息后大约保留了 90% 的内容。你可以直接改成自己组织的版本，重点是条款要可执行、可检查。

1. 制度条款结构

1. 第一条 定义与分层。明确 L1/L2/L3 三层模板的定义、数量上限和维护主体。
2. 第二条 模板 Owner 职责。明确每套模板必须有具名 Owner，以及 Owner 的评审、答疑和变更响应义务。
3. 第三条 新增准入。新增模板必须提交使用场景说明、至少 3 个未来 6 个月的项目实例，并证明现有模板无法覆盖。
4. 第四条 变更分级。明确 L1/L2/L3 三档变更的审批人、生效窗口和通知范围，明确”只对新建项目生效”。
5. 第五条 健康度审计。每月输出模板健康度报表，含起用率、填充率、返工率、工单量四项指标。
6. 第六条 冻结与退役。90 天零创建自动冻结，180 天未评审自动进入待评审清单，冻结 60 天后退役。
7. 第七条 争议处理。业务线与 PMO 就模板分层无法达成一致时，由模板评审组投票决定，决议保留 6 个月。

2. 模板健康度看板指标与阈值

制度要能落地，必须有几个可以每月自动跑出来的数字。下面这四项是我用得最顺手的，阈值可以根据组织情况调整，但建议不要少于四项，否则无法判断模板是”没人用”还是”不好用”。

3. 变更评审单模板

所有的 L2 和 L3 变更都必须走这张评审单。表单字段不用多，但每一栏都必须填，尤其是”影响范围”和”回滚方案”。

模板变更评审单
────────────────────────────────

模板 ID： TPL-RD-STD-01

模板名称： 标准研发项目模板

变更等级： L2 / L3

申请人： 张工（产品线A）

申请日期： 2025-04-08

变更内容： 将"关联需求版本"由选填改为必填

变更原因： 季度资源复盘时无法按需求版本归集工时

影响范围：

受影响模板： 2 套（L2 场景模板 B-01、B-02 继承本字段定义）

受影响业务线： 3 条

预计影响建项数： 约 14 个/月

回滚方案： 将字段改回选填，并保留已填数据不作清理

生效方式： 15 天后生效，仅对新建项目生效

通知范围： 全员公告 + 变更说明文档

审批记录：

模板 Owner： 同意（2025-04-09）

PMO： 同意（2025-04-10）

业务线负责人： 同意（2025-04-10）

────────────────────────────────

这张表单真正的价值在”回滚方案”和”影响范围”两栏。我见过太多模板变更没有回滚方案，出问题后只能硬扛。凡是写不出回滚方案的变更，说明申请人还没想清楚影响面，应当退回补充。

九、结语：模板效率的本质是让人少做决定

回到最开始那个 34 套模板的组织。治理完成后，项目负责人建项的平均耗时从 27 分钟降到 9 分钟，选错模板率从 18% 降到 4%，模板维护投入从 0.6 人天/月降到 0.2 人天/月。

但我觉得这次治理最值得记住的一点，不是这些数字，而是一个判断标准：好的模板制度，不是让模板更规范，而是让项目负责人在建项那一刻需要做的决定更少。当一个人打开建项页面，能在 10 秒内确定”就是这套”，制度就成功了。

相反，如果一套制度让项目负责人每次建项都要思考”我该用哪套模板””这个字段要不要填””填错了会不会被退回”，那再规范的模板库也只是把成本从 PMO 转移到了项目负责人身上。

下一步你可以这样开始，不需要等任何资源批复：今天导出你组织里全部模板和最近 12 个月的创建记录，算出每套模板的创建次数。把创建次数为 0 的模板列一张清单，发给对应的负责人，问一句话，”这套模板还需要吗？”

通常这张清单发出去之后，一周内会有三分之一的模板被主动申请下线。这就是模板治理最便宜的第一步，也是我每次启动治理都会做的第一步。