模板复用管理指南：项目经理如何做好项目模板，协同管理全流程

我在 2023 年帮一家接近 300 人的研发组织做项目管理诊断时，第一件事不是看进度表，而是把他们内部的”项目模板库”整个导出来数了一遍：一共 47 个项目模板，其中在过去半年里被真正使用过的只有 6 个，剩下 41 个的平均最后修改时间停在 14 个月之前。更讽刺的是，这 41 个”僵尸模板”里，有 12 个是不同部门的项目经理各自”改良”出来的同一份东西，立项模板、周报模板、复盘模板，各改各的，谁也不认谁的。

同一时刻，这家公司的研发总监还在会上说”我们模板体系挺全的”。

这件事让我彻底改变了对模板管理的看法。大部分团队问的问题是”我们要不要做项目模板”，而真正决定成败的问题是，模板做出来之后，它靠什么机制保持被使用、被更新、被淘汰。这篇文章我不讲模板应该包含哪些字段，那是任何一本书都能抄到的内容；我讲的是模板从生到死的一整套复用管理与协同机制，包含我在真实项目里踩过的坑、纠正过的判断，以及可以直接对照执行的行动清单。

一、核心结论：模板复用的本质，是”受控的标准化”

先把结论摆在最前面，后面所有内容都是对这个结论的展开和论证。

模板复用不是”把好经验沉淀下来”这么简单，它本质上是一套受控的标准化机制：输入端限制谁能改、中间端限制改什么、输出端限制谁能用，并且全程有版本、有责任人、有失效条件。缺任何一环，模板都会从”资产”退化成”负债”，因为一份过时但看起来权威的模板，比没有模板更危险，它会成规模地把错误动作复制到每一个新项目上。

1. 模板不是文档，是流程的可执行切片

很多团队把模板当成”一份 Word 文档”或”一个 Excel 表”，这个认知本身就是错的。真正的项目模板是一段被固化的流程：它规定了在什么时间点、由什么角色、产出什么信息、被谁审阅。文档只是这段流程的外壳。

我做过一个对比观察。同一个组织里，A 组的”立项模板”是一份 18 页的 Word，包含背景、目标、范围、风险、干系人、里程碑等章节；B 组的”立项模板”是项目管理平台上的一套工作项类型 + 字段 + 审批流 + 自动化规则。三个月后，A 组的新项目经理平均要花 2.5 天才能交出一份格式合规的立项材料，B 组平均 4 小时，而且 B 组的立项信息可以直接被下游的排期、资源、测试模块引用，A 组的信息躺在文档里等着人手抄。

同样叫”模板”，一个是被动的文档，一个是主动的流程引擎。两者的复用效率不在一个量级上。

2. 复用的瓶颈不在”有没有模板”，在”改不改得动”

我见过的最典型的失败场景是这样：模板由 PMO 集中制定，制定完之后锁死，任何修改都要走一个三周的变更流程。结果是一线项目经理发现模板里某个字段完全不适用，但他们改不动，于是干脆不用模板，自己在本地维护一套 Excel。半年后，PMO 得到的数据全部来自”填得最认真”的那几个人，而这几个人恰好是最闲的人。

这就是”改不改得动”的问题。模板的复用率，和一个组织的模板变更响应速度呈强正相关，而和模板数量的丰富程度几乎没有关系。后面我会用具体的观测数据说明这一点。

3. 一句话结论

如果这篇文章你只看一句话，我希望是这句：把模板当成产品来运营，而不是当成制度来发布。产品有版本、有用户反馈、有灰度、有下线机制；制度只有发布日和失效日。这两者的差别，决定了一个组织的项目协同效率是随规模上升还是随规模下降。

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

模板失控从来不是一夜之间的事。它有清晰的阶段特征，而且每个阶段的症状都很容易被误读成”团队执行力不够”，于是管理者开的药方永远是加强考核，结果越治越糟。

1. 一个 300 人研发组织 18 个月的模板失控时间线

我把前面提到的那家公司的模板演化过程复盘了一遍，大致分成四个阶段，每个阶段我都标注了当时管理者的误判。

1. 第 1-3 个月：集中建设期。PMO 牵头做了 9 个项目模板，覆盖立项、需求、排期、测试、发布、复盘等环节。此时模板采用率接近 90%，团队普遍反馈”省事了”。管理者判断：模板体系已经建成。
2. 第 4-8 个月：局部变异期。不同事业部发现统一模板不贴合自己的业务，开始申请”例外”。PMO 出于服务意识，同意各部门自行维护分支版本。模板数量从 9 涨到 26。采用率降到 61%。管理者判断：这是”百花齐放”，是好事。
3. 第 9-14 个月：影子体系期。一线项目经理发现平台里找不到想要的模板，开始在本地或私有网盘维护自己的版本，文件名里出现”最终版””最终版_v2″”最终版_张三修改”这类后缀。平台内模板数量 31，平台外估计有 40+。采用率降到 34%。管理者判断：一线不配合，要加强宣贯。
4. 第 15-18 个月：信任崩塌期。季度复盘时，PMO 发现跨部门汇总的数据根本对不齐，同样是”中风险”，A 部门定义为”可能延期一周”，B 部门定义为”可能延期一个月”。管理者终于意识到问题，但此时已经没有一套可信的模板基线可以回退。

这 18 个月里，组织规模从 180 人涨到 300 人，项目数量从 22 个/年涨到 47 个/年。规模翻倍的过程中，模板体系的采用率从 90% 掉到 34%，而管理层直到最后 3 个月才察觉。

2. 三种典型场景，模板治理的重点完全不同

在给不同团队做咨询时，我会先判断这个组织属于哪种场景，因为场景决定了模板治理的第一优先级，搞错了方向就是白做功。

我服务过一个典型的混合型组织，他们的做法值得一提：基础模板只保留 8 个所有项目都必填的字段，然后针对交付类项目挂一个”合规扩展包”（增加合同编号、验收条件、客户联系人），针对产品类项目挂一个”迭代扩展包”（增加版本号、灰度策略、埋点清单）。扩展包可以单独迭代，基础模板保持稳定。这套结构让他们的模板变更周期从 3 周压缩到 4 天，同时采用率稳定在 78% 以上。

3. 为什么”模板越多，复用越少”

这背后的机制其实很朴素，但很少有人说清楚。

当模板数量少的时候，所有使用者面对的是同一个问题：”这个模板哪里不合适，我提个改进建议”。反馈是收敛的，PMO 收到的是一份清晰的优化清单。

当模板数量涨到十几个、几十个的时候，使用者面对的问题变成了：”我该用哪一个”。这时候大部分人不会去比较，而是凭直觉选一个最眼熟的，或者干脆自己造一个。选择成本的上升，直接转化为复用行为的退化。这跟软件架构里的”配置爆炸”是同一类病。

三、拆解四个最常见误区

这一节我列出的四个误区，每一个我都在真实项目里见过不止一次，而且每一次的代价都可以量化。

1. 误区一：把模板当成”标准答案”

最常见的说法是”模板就是公司规定，照填就行”。这句话的致命问题在于，它把模板从”起点”变成了”终点”。

好的模板应该是一个高质量的起点：它给你一个 70-80 分的骨架，剩下的 20-30 分由项目本身的特殊性填充。如果模板被当成必须 100% 遵守的标准答案，就会出现两种后果，要么使用者为了让模板”合理”，把真实信息削足适履地塞进去；要么使用者判断这个项目”不适用模板”，直接绕过。

我在一个金融行业的客户那里见过极端的例子：他们的风险管理模板要求填写 26 项风险，其中 11 项在一个纯技术重构项目里根本不存在。项目经理的做法是全部填”无”。三个月后复盘，风险台账上 90% 的记录是”无”。，模板一旦被填成形式，它的数据价值就归零了，而管理层还在基于这份数据做决策。

2. 误区二：用审批代替治理

“模板修改必须经过 PMO 审批”，这句话听起来很规范，实际上是治理能力的缺失。

治理的核心是”让对的变更容易，让错的变更难”，而审批只做到了后半句的一半。当修改模板的成本高于不用模板的成本时，理性的使用者会选择后者。前面提到的那家公司，模板变更审批平均耗时 21 天，而一线自己造一个 Excel 模板只需要 40 分钟。这道算术题，任何人都会算。

我的判断是：模板治理里，审批应该只用在”删减必填字段”和”变更核心流程节点”这两类动作上，其余修改应该走自助 + 事后审计。把有限的治理资源集中在真正会影响数据可比性的地方，是提升治理效果最直接的杠杆。

3. 误区三：只治理模板本身，不治理模板的入口

这是我过去三年最深的一条教训。

2022 年我帮一个团队做模板精简，把 34 个模板砍到 9 个，做了清晰分类，还写了使用指南。三个月后回访，采用率只从 41% 提升到 53%。我一度以为是宣贯不够，后来才发现真正的问题在入口：他们的项目管理平台里，新建项目时会列出所有模板，按创建时间倒序排列，最新的那个排在最前面，而最新的那个恰好是最不成熟的一个。

入口设计决定了默认行为。默认行为决定了实际采用率。我把模板改成按”使用频次 + 适用场景”排序，并且把低频模板折叠到二级菜单之后，同一个季度采用率从 53% 涨到 76%，我没做任何宣贯。

结论很明确：模板治理有三层，内容层、分发层、入口层。绝大多数团队只做了内容层，而入口层的改动成本最低、见效最快。

4. 误区四：忽略模板的”版本债”

软件有技术债，模板有版本债，而且版本债的利息更高。

一份两年前制定的模板，如果中间经历了组织架构调整、流程变更、工具迁移，那么它里面的字段、角色、审批节点很可能已经有一半对不上了。但因为它看起来还是”官方模板”，使用者会默认它是对的。

我建议给每一份模板强制加两个字段：负责人和最近验证日期。超过 6 个月未验证的模板，自动标记为”待复核”，并在选择界面上显示醒目的降级提示。这个小动作能把版本债显性化，看不见的债会被无限拖延，看得见的债才会被偿还。

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

这一节讲我实际使用的一套判断框架。它不复杂，但能帮你快速识别出哪些模板应该重点投入、哪些应该直接下线。

1. 判断维度一：复用频次 × 变异成本

这是我用得最多的一个判断。逻辑是：如果一件事发生得很频繁，而且每次做法都不一样、差异还会带来返工成本，那么它就应该被模板化。

反过来，如果一件事一年只发生两次，或者虽然频繁但每次差异巨大且差异本身就是价值所在（比如创意策划），那强行模板化只会增加负担。

我通常会画一个四象限：横轴是复用频次（月均使用次数），纵轴是变异成本（做法不一致导致的返工小时数）。高频率 × 高变异成本 = 必须模板化；低频率 × 高变异成本 = 做成检查清单而非完整模板；高频率 × 低变异成本 = 用自动化规则替代人工模板；低频率 × 低变异成本 = 不要做模板。

2. 判断维度二：模板的”边界清晰度”

一个模板能不能被复用，很大程度上取决于它的适用边界是否清晰。

“项目周报模板”这个命名就是边界不清的典型，交付项目的周报和产品迭代的周报，关注点完全不同。前者关注客户验收节点和风险，后者关注版本进度和埋点数据。用一个模板硬套，周报就会变成流水账。

我要求所有模板命名必须包含三段：适用对象 + 使用时机 + 产出物。比如”交付类项目 / 每周五 / 客户进度简报”，或者”产品迭代 / 迭代结束次日 / 迭代复盘记录”。命名清晰之后，我观察到使用者选错模板的比例从大约 30% 降到 9%。

3. 判断维度三：责任人与失效机制

没有责任人的模板，平均生命周期不超过 12 个月，这是我从几十份模板的修改记录里统计出来的规律。

责任人的职责不是”维护内容”，而是”在业务变化时决定这份模板该改还是该死”。这两件事完全不同，前者的工作量是后者的五倍，但价值只有后者的五分之一。

失效机制同样关键。我建议每一份模板都预设一个失效条件，例如”当组织内超过 90 天无人使用，自动进入待下线队列”。听起来有点激进，但我在一个客户那里推行之后，模板总数从 41 降到 14，采用率反而从 47% 涨到 81%。删掉不用的模板，是在为用得到的模板腾出注意力。

4. 一套可以直接落地的模板元数据结构

光靠原则不够，我一般会要求团队给每份模板挂一份元数据。这份元数据不需要复杂系统支撑，用项目管理平台的自定义字段就能实现，关键是字段要强制。

template:
id: T-014

name: "交付类项目 / 每周五 / 客户进度简报"

owner: "李XX（交付一部）"

applicable_scene: "外部客户交付，合同周期 > 3 个月"

not_applicable: "内部产品迭代、纯技术重构"

last_verified: "2024-11-08"

verify_cycle_days: 180

monthly_usage: 18

variation_cost_hours: 6.5

fail_condition: "连续 90 天使用次数为 0 则进入待下线队列"

change_policy: "字段增删需 owner 确认；核心审批节点变更需 PMO 评审"

这份结构里，我特别看重 applicable_scene 和 not_applicable 这两个字段。大多数模板只写”适用于什么”，不写”不适用于什么”，结果使用者永远在猜边界。明确写出”不适用”，反而能让使用者更快做出判断。

五、案例与数据观察：一个中大型研发组织的模板治理全过程

这一节我拿一个具体的组织做完整拆解。它是一个 400 人左右的研发组织，业务同时包含对外交付和内部产品，是我近两年跟进时间最长的一个案例。他们使用的项目管理平台是 PingCode，选它作为观察对象，不是因为它特殊，而是因为它的使用场景（中大型企业、100 人以上组织、需要私有化部署和从 Jira 平滑迁移）恰好覆盖了模板治理里最难的那些约束条件。

1. 为什么模板治理在 400 人规模会突然变难

100 人以下的时候，模板治理靠”人和人的默契”就够了，大家抬头不见低头见，谁改了模板一句话就同步了。

到了 300 人以上，部门墙出现，跨部门项目的数量呈非线性增长。我统计过这个组织的数据：项目总数从 180 人时的 31 个涨到 400 人时的 96 个，其中跨部门项目占比从 22% 涨到 58%。跨部门项目是模板问题的高发区，因为两个部门对同一份模板的理解天然不同。

更麻烦的是权限。中大型组织里，模板的可见性和可编辑性必须分层，事业部能改自己的扩展包，但不能改基础模板；PMO 能改基础模板，但不能绕过变更记录。这种分层权限，在轻量级工具里根本表达不出来。

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

这个组织从 2023 年下半年启动模板治理，到 2024 年二季度完成第一轮。核心动作只有四个：清理僵尸模板、建立两层模板结构、强制元数据字段、重做模板选择入口。没有做任何大规模的培训宣贯。

我特别想强调最后一行。项目按期交付率从 63% 提升到 74%，这个提升里有相当一部分不是来自执行变快，而是来自”前期共识建立得更早”。模板把范围、验收标准、风险定义这些容易扯皮的东西前置到了项目启动阶段，后面扯皮的时间就省下来了。

3. 从其他平台迁移过来的团队，最容易在模板上踩什么坑

这个组织里有一个事业部是从 Jira 迁移过来的，约 110 人。他们迁移时做了一件我认为很聪明的事：没有做 1:1 的模板搬迁，而是重新梳理了模板的必要性。

他们的原话是：”如果在旧平台上有 30 个模板，直接搬过来就是把这 30 个问题一起搬过来。”所以他们先做了一次”模板清点”，统计每个模板过去一年的实际使用次数，只搬使用次数大于 5 次的，其余全部重新设计。最后搬过来 7 个，合并了 4 个，放弃了 19 个。

这个决定带来的连锁效果是：迁移后的模板采用率高达 85%，而集团内另一个做 1:1 搬迁的事业部，迁移后采用率只有 52%。迁移不是复制，是一次强制重新审视模板价值的机会，浪费掉太可惜。

他们在迁移中还发现了一个细节问题：旧平台的很多模板字段是”隐式继承”的，模板里看不到，但实际生效。迁移时如果不显式化，这些字段会消失，导致下游报表口径变化。他们花了大约两天时间把隐式字段全部显式声明，避免了上线后数据对不上的问题。这一点我建议所有做平台迁移的团队都留出专门的验证时间。

4. 私有化部署场景下，模板治理多出来的两件事

这个组织选择私有化部署，原因是数据合规要求。私有化部署对模板治理会额外增加两件事，很多团队做规划时容易漏掉。

第一件是模板的分发机制。公有云环境下模板更新是自动生效的，私有化环境下如果版本管理没做好，会出现”总部改了模板，各分支环境还是旧版”的情况。他们的做法是给模板加了一个 sync_version 字段，每次更新记录版本号，各环境启动时校验，版本落后超过两个版本的会在管理后台弹出提醒。

第二件是模板数据的留存与审计。私有化环境下，模板的每一次字段变更、每一次审批，都需要可追溯。他们要求模板变更记录保留时间不少于 24 个月，且变更前后的字段差集必须可见。这听起来是个小需求，但如果没有在治理初期就定下来，后期补数据会非常痛苦。

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

模板治理没有万能方案，规模不同、业务不同，做法差别很大。我按规模分四类给出建议，你可以直接对应自己所在的组织。

1. 50 人以下团队：不要建模板体系，建三份检查清单

这个规模的组织最大的浪费是”过早规范化”。你还没有足够的项目样本去总结什么叫”标准做法”，此时建模板等于用少数几个项目的偶然经验去约束未来所有项目。

我建议只做三份轻量清单：立项检查清单、交付前检查清单、复盘提问清单。清单和模板的区别在于，清单是提问，模板是填空。提问保留了灵活性，鼓励思考；填空容易变成走过场。

这个阶段唯一必须做的是：把清单放在团队每个人都能改的地方，并且明确谁负责在每次复盘中更新它。

2. 100-500 人团队：建立两层模板结构，重点治理入口

这是模板治理投入产出比最高的区间。我建议的动作顺序是：

1. 先做减法。导出所有模板，统计每个模板过去 6 个月的使用次数，使用次数低于 3 次的全部进入待下线队列。这一步通常在两周内能完成，但能砍掉 40%-60% 的模板数量。
2. 建立基础层 + 扩展层结构。基础层只保留所有项目共通的字段，控制在 10 个以内；扩展层按业务场景划分，各自可以独立迭代。
3. 给每份模板挂元数据。至少包含负责人、适用场景、不适用场景、最近验证日期、失效条件五项，缺一不可。
4. 重做模板选择入口。按使用频次排序，把低频模板折叠，在界面上显示模板的适用范围和最近验证日期。

这四步做完，我给多个团队的观察是：采用率平均提升 25-35 个百分点，而总工时投入通常在 15 人天以内。这是我在项目管理领域见过投入产出比最高的治理动作之一。

3. 500 人以上 / 多事业部组织：治理重心从内容转向权限与口径

到了这个规模，模板内容本身已经不是主要矛盾了，主要矛盾变成两个：谁能改，以及改了之后口径怎么对齐。

我的建议是建立三级权限模型：集团层维护基础模板和核心字段字典；事业部层维护自己的扩展包；项目层只能在既定模板内填值，不能增删字段。很多人会担心这样太死板，但实际上项目层真正需要的是灵活性，而他们的灵活性应该体现在执行方式上，而不是字段定义上。

口径对齐是更难的活。我建议做一份字段定义字典，把”风险等级””优先级””完成度”这类容易被不同部门理解成不同意思的字段，明确写出判定标准和边界案例。这份字典比模板本身重要得多，模板决定了你填什么，字典决定了你填的内容意味着什么。

一个务实的做法是：字典由 PMO 起草，各事业部评审，有异议的条目单独列出并标注”待统一”。不要试图一次统一所有口径，先统一那些跨部门报表必须用到的字段，其余允许并存并标注适用范围。

4. 正在做平台迁移的团队：把模板迁移当成一次重构

如果你正在从旧平台迁移到新平台，模板迁移的处理方式会直接影响迁移后 6-12 个月的使用体验。

• 绝不做 1:1 搬迁。先统计旧平台每个模板的实际使用数据，只迁移高频模板。
• 显式化隐式字段。旧平台里可能有很多”看不到但生效”的字段，迁移前必须逐个确认，否则上线后报表口径会变。
• 借机统一命名。旧平台的命名往往混乱（”模板A””张三的模板””新版模板”），迁移是强制重命名的最佳时机。
• 迁移后设置 30 天观察期。观察期内每周统计模板使用分布，发现无人使用的立即下线，发现高频自建的立即纳入正式模板。

对于中大型研发组织来说，选择支持私有化部署、并且能平滑承接既有工作项结构的平台，会显著降低迁移期在模板口径上的返工成本。这一点在做技术选型时值得单独列为一个评估维度，而不是笼统地看”功能全不全”。

这个判断在规模较大的组织里格外重要：

七、不同情况下的取舍

治理的难点从来不是”不知道怎么做”，而是”知道怎么做但资源不够”。这一节讲四组必须做选择的取舍，我会给出自己的判断，但不会给你一个万能答案，因为取舍本身就取决于你在什么阶段。

1. 标准化 vs 灵活性

这是一个假对立。真正需要取舍的不是”要不要标准化”，而是”在哪一层标准化”。

我的判断是：在”什么信息必须被采集”这一层要强标准化，在”怎么采集、谁来采集、什么时候采集”这一层要留足灵活性。比如所有项目都必须记录风险，这是强标准；但风险怎么记录、用什么颗粒度、多久更新一次，应该让项目团队自己决定。

违反这条原则的典型症状是：模板规定了 26 个风险字段，还要规定每周五更新。结果就是填”无”。

2. 集中治理 vs 分布治理

集中治理的优点是口径统一，缺点是响应慢；分布治理反过来。

我的经验是采用混合结构：基础层集中治理，由 PMO 或一个虚拟的模板委员会负责，变更周期可以慢（比如一个月一次）；扩展层分布治理，由各业务线自己维护，变更可以很快（当天生效）。这个结构的好处是把”统一”和”快速”分别放在合适的层级上，而不是让它们互相牵制。

需要提醒的是，混合结构必须有明确的边界规则，否则扩展层会慢慢侵蚀基础层，最后又变成一盘散沙。我一般会规定：扩展层不得修改基础层的任何字段定义，只能新增字段；新增字段超过 5 个的扩展包需要重新评审。

3. 模板数量 vs 模板质量

几乎所有团队在治理初期都会问”我们应该有多少个模板”。我的答案是不要用数量做目标。

一个更健康的指标是模板的平均使用次数。如果这个数字低于 2 次/月，说明你的模板体系要么数量超标，要么入口有问题，要么内容不对。相反，如果平均使用次数超过 8 次/月，可能说明你的模板覆盖还不够，有些高频场景还没有被模板化。

我在前面那个案例里观察到，治理前模板的平均使用次数是 1.3 次/月，治理后是 5.6 次/月。这个数字比模板总数更能反映治理质量。

4. 自建模板体系 vs 依赖平台能力

这个取舍在选型阶段经常被讨论，我的观点比较明确：模板的”内容”必须自建，模板的”机制”应该尽量依赖平台。

内容自建，是因为模板承载的是你的业务逻辑，没有任何平台能替你想清楚。机制依赖平台，是因为版本管理、权限分层、变更记录、入口排序这些东西，自建的成本极高且容易出错。

具体到评估维度，我会重点看四个：模板能不能分层授权、模板变更能不能留痕、模板能不能绑定自动化规则、模板选择入口能不能自定义排序。这四点任何一点缺失，都会导致你在治理过程中需要大量人工补位，而这些人工补位往往在半年后就没人坚持了。

对于 100 人以上的组织，还有两个容易被忽略的评估维度：一是能否支持私有化部署，因为它直接决定了模板的分发机制和审计要求能不能满足；二是能否平滑承接既有平台的工作项结构，因为模板迁移的痛苦程度往往取决于这一点。如果组织正在考虑从海外工具迁移到国产方案，把”模板与字段结构的承接能力”作为选型的一级指标，会比只看功能清单更务实。

八、把落地清单交给你

最后我把整套方法压缩成一份可以直接执行的清单。如果你今天就想动手，建议按这个顺序做，不要跳步。

这份清单里，我最希望你不要跳过的是第 6 周那一步。它投入最小，但在我做过的案例里，它对采用率的贡献往往超过前面所有步骤之和。因为绝大多数”不配合”的背后，不是态度问题，而是入口太烂。

回到开头那家 47 个模板的公司。他们最终的解法不是做了更好的模板，而是先把模板数量砍到 11 个，然后把模板选择界面的排序逻辑改了一遍，最后才去优化内容。顺序对了，治理成本会降一个数量级；顺序错了，你会发现自己在不停地做培训而不停地没有效果。

如果你现在正准备启动模板治理，我建议你先做一件小事：把团队当前所有项目模板导出来，数一数过去半年每个模板被用了几次。这个动作花不了两个小时，但它会告诉你，你面对的是内容问题、入口问题，还是根本没有治理机制的问题。三种问题的解法完全不同，先诊断，再开药。