模板权限最佳实践：实施团队项目模板实操方法，常见问题

我见过最贵的一次模板权限事故，代价是 3 个团队、17 个项目、连续两周的错误数据。起因只是一次看似无害的“另存为”：某业务线的项目经理把公司公共的“硬件研发项目模板”复制了一份，改掉了两个阶段名称，设成了自己团队的默认模板。三个月后，财务做研发投入分析时发现，同一套流程在全公司有三种叫法，报表口径彻底对不上，只能人工回溯两个月的工作项记录重新归类。

这件事让我彻底改变了对“模板权限”的理解。它从来不是一个“谁能看见模板、谁不能看见”的可见性问题，而是一个组织把“默认工作方式”的定义权交给谁的问题。模板权限配错了，轻则模板没人用，重则整个组织的数据口径被少数几个人悄悄改写，而你几个月后才会发现。

这篇文章不讲概念定义，只讲我在多个 100 人以上研发组织实施模板治理时踩过的坑、验证过的权限模型、以及可以直接照抄的配置步骤。全文围绕三条主线：模板权限必须“三层分离”、权限模型必须绑定模板生命周期、治理目标不是消灭影子模板而是给它一条受控通道。

一、核心结论：先把结论说清楚

如果你只读一节，请读这一节。下面四条结论，是我在至少 12 家 100 人以上组织做模板治理复盘后沉淀下来的判断，后面所有内容都是这四条的展开和论证。

1. 模板权限的本质是“组织默认工作方式的定义权”

大多数人配置模板权限时，脑子里想的是“这个模板要不要给别人看”。但实际上，模板一旦被设为默认，任何新建项目都会继承它携带的字段、工作流、状态机、自动化规则、看板视图、报表结构。这意味着模板编辑权约等于“可以单方面改变全公司新项目的默认行为”。

把模板编辑权当成普通的“查看/编辑”权限随手发出去，等价于把生产环境的配置权发给了不承担后果的人。这是所有模板事故的共同根因。

2. 必须把“可见、可实例化、可编辑”三件事拆成三个权限位

我调研过的多数项目管理平台默认只给模板一个“可见/不可见”的开关，或者把模板权限和项目创建权限绑死。这两做法都会出问题。

可见性（Discoverability）决定用户能不能在模板库里搜到这个模板，它影响的是“发现成本”。实例化权（Instantiation）决定用户能不能用这个模板创建项目，它影响的是“使用门槛”。编辑权（Definition）决定用户能不能修改模板本身，它影响的是“组织标准”。

这三件事的受众完全不同。可见性可以全公司开放，实例化权应该按团队授权，编辑权必须收敛到极少数人手里。把三者合成一个开关，你就只能在“所有人都能改”和“所有人都不能用”之间二选一。

3. 权限要绑定模板生命周期，而不是绑定人的角色

按角色配权限是最直觉的做法，也是最容易腐化的做法。因为角色会变、人会走、组织会重组，而“谁能改这个模板”应该跟着模板本身的成熟度走。

我推荐的模板生命周期是：草稿 → 候选 → 已发布 → 冻结 → 弃用 → 归档。草稿阶段允许创建者自由改，候选阶段只允许模板管理员改，已发布阶段任何人都不能直接改只能提变更申请，冻结阶段连模板管理员也要走审批，弃用阶段禁止新项目实例化但保留历史项目引用，归档阶段只读。

这套机制最大的好处是：权限不再是“一次性授予”，而是“随状态自动收窄”。你不需要在每次组织架构调整时重新盘一遍权限。

4. 治理目标不是消灭影子模板，而是给它一条受控通道

这是最反直觉的一条。很多 PMO 的第一反应是“禁止另存为模板”“禁止从旧项目复制”。我试过，结果是影子模板从平台里消失了，转到了共享盘、群文件、个人笔记里，你反而彻底失去了观测能力。

正确的做法是提供受控的派生通道：允许用户从已发布模板克隆出“个人草稿”，草稿仅自己可见、不能设为团队默认、不能超过 90 天未使用（到期自动提醒或回收）。用户想升级为团队模板，必须走提交审批。这样你既满足了灵活性，又保留了全部可见性。

下面是不同模板治理成熟度下，组织表现出的关键指标差异。我按“无治理 / 基础治理 / 成熟治理”三档做了样本推演，数据来自我对 12 家组织的复盘记录，属于示意性对比，不是精确统计。

二、背景与真实场景：模板权限为什么会失控

先把场景讲清楚。绝大多数模板权限问题不是某个人恶意造成的，而是在组织扩张、平台迁移、人员流动这三个节点上，权限逐步漂移的结果。下面三个场景我都亲身经历过。

1. 一次“另存为”引发的口径灾难

回到开头那个案例。那家组织的模板权限模型是这样的：项目创建权限和模板编辑权限绑在同一个“项目管理员”角色上，而这个角色为了推广便利，被授予了全部 12 个业务线的 PM。

问题链条是这样的：某 PM 觉得公共模板的阶段划分不符合自己业务线实际情况，于是克隆了一份。克隆时平台没有做“派生关系标记”，这份新模板在系统里看起来和公共模板毫无关系。他把它设为团队默认，后续 4 个新项目全部基于它创建。

两个月后，财务要做研发投入的阶段分布分析，发现同一套“需求-设计-开发-测试-发布”的流程，在系统里有三套不同的状态名和四套不同的阶段粒度。更麻烦的是，这些项目的燃尽图和周期时间基线无法横向比较，历史数据失去了统计意义。

修复成本是多少？3 个人花了 11 个工作日做数据回溯和状态映射，加上流程评审会议 6 次。如果当初在克隆时强制打一个“派生自 XXX 模板”的标记，并在报表层做状态映射，这件事的成本可以压到 2 个工作日以内。

2. 三类组织的模板治理现状对比

我把接触过的组织按模板治理状态分成三类，你可以对号入座。

第一类是“无治理型”，特征是模板数量少（10 个以内）但没有维护者，模板权限对所有项目管理员开放，谁都能改。这类组织的典型表现是模板建了就没再更新过，模板里的流程和实际干的活完全对不上，大家宁可从旧项目复制也不用模板。

第二类是“过度管控型”，特征是模板数量激增（30-80 个），但只有一个人有编辑权，所有变更都要排队。这类组织看起来规范，实际上模板迭代周期长达 2-3 个月，业务变化快于模板更新速度，结果和第一类一样，没人用。

第三类是“分层治理型”，特征是模板分三级（公共/业务线/团队），每级有不同的审批人和更新周期，模板使用率能稳定在 70% 以上。这类组织占比最低，但它们的权限模型其实并不复杂，关键在于把“谁能改”和“谁要批”分开。

3. 模板腐化曲线：为什么模板会自己变坏

模板不是建好就一劳永逸的资产，它会“腐化”。我跟踪过 6 个组织的 23 个公共模板，记录它们发布后每个月与真实流程的偏差情况，得到一条相当一致的曲线。

发布后第 1-2 个月，偏差率通常在 5% 以内；第 3-5 个月，偏差率爬到 12%-18%，主要来自新增字段需求和阶段调整；第 6-9 个月，偏差率突破 30%，此时模板已经开始误导新项目；超过 12 个月未更新的模板，偏差率普遍在 45% 以上，这个阶段的模板实际上是负资产，它比没有模板更糟，因为它让新项目从错误的起点出发。

4. 新项目从“选模板”到“上线的漏斗：卡在哪一步

模板用得少，很多时候不是权限问题，而是流程问题。我统计过一家 400 人组织中连续 60 个新项目的创建过程，发现流失点非常集中。

100 个需要创建项目的场景中，有 74 个会先尝试找模板；找到模板的有 58 个，剩下 16 个因为搜索不到或命名混乱而放弃；真正用模板创建的有 41 个，剩下 17 个在“模板预览”环节发现不匹配而退出；最终完整走完模板配置并上线的只有 33 个。从“想用模板”到“真的用上模板”，漏斗流失了 55%。

三、六个常见误区：每一条我都付过学费

下面六个误区，我几乎每一个都亲身经历过，有的还是我自己主导设计出来的。我把它们的表现、根因和纠正方式都写出来，你可以直接对照自查。

1. 误区一：把模板权限等同于项目创建权限

这是最普遍的误区。很多平台默认把“创建项目”和“选择模板”放在同一个权限里，实施团队为了图省事，就把两者一起授予业务线 PM。结果是任何能建项目的人，都能建一个新模板。

这个设计的隐含假设是“建项目的人最懂流程”，但现实恰恰相反，最懂流程的人通常不建项目，建项目的人最关心的是“怎么能快点开工”。让前者设计模板、后者使用模板，本身就是分工。

纠正方式很简单：在建角色时，把“项目创建权”和“模板编辑权”拆成两个独立权限组，哪怕平台把它们绑定在同一个开关上，也要通过“自定义角色 + 审批流”在流程层做二次隔离。

2. 误区二：权限粒度越细越好

我做过一次失败的设计：把模板权限拆成 9 个细项（查看、预览、实例化、克隆、编辑字段、编辑工作流、编辑自动化、发布、归档），结果 3 个月后产生 27 个自定义角色，没人能说清哪个角色该配哪几项。

权限粒度不是越细越好，而是要和“角色数量”匹配。经验阈值是：如果权限项数量超过角色数量的一半，说明粒度已经过细。实操建议是，权限项控制在 4-6 个，角色控制在 4-6 个，形成一张可被记住的矩阵。

3. 误区三：用文件夹管模板，用个人管权限

把模板放进“研发中心/移动端/Android/模板”这样的文件夹里，看起来很有条理，但文件夹是给人看的，权限是给系统执行的。文件夹层级一旦超过三层，权限继承关系就没人能理清。

更危险的是“用个人管权限”，比如把模板编辑权授予某个具体的员工账号，而不是角色或用户组。这个人一离职，你要么忘了回收，形成权限真空；要么直接删号，导致模板失去维护者。模板编辑权必须挂在“岗位角色”或“用户组”上，绝不能挂在个人账号上。

4. 误区四：只迁模板，不迁模板的依赖

这是平台迁移时最容易被忽略的问题。一个模板表面上是“阶段 + 任务清单”，实际上它背后挂着一堆依赖：自定义字段、字段的必填规则、工作流状态机、状态转换条件、自动化规则、看板与报表视图、通知模板。

我在一次迁移中只迁了模板主体，没迁字段的必填规则，结果新项目创建后 40% 的工作项缺少关键字段，报表直接失效。修复方式是：迁移前先做“模板依赖清单”，把每个模板依赖的字段、工作流、自动化逐项列出，按依赖顺序迁移，最后做一次端到端的实例化验证。

模板依赖清单（迁移前必须逐项打勾）
template: hardware-rd-standard-v3

├── custom_fields: [需求来源, 硬件版本, 合规等级, 供应商代码]

│ └── required_rules: 需求来源(必填), 合规等级(必填)

├── workflow: hw-rd-flow

│ ├── states: [需求, 方案, 打样, 验证, 试产, 量产, 关闭]

│ └── transitions: 18 条，其中 4 条带条件校验

├── automations: 7 条（含 2 条跨项目联动）

├── views: 看板 x3, 甘特 x1, 报表 x4

└── notifications: 5 个模板

验证：用该模板创建 1 个空项目，逐项确认字段/状态/自动化生效

5. 误区五：没有模板退场机制

模板腐化曲线告诉我们，超过 12 个月未更新的模板是负资产。但绝大多数组织的模板库里，躺着大量三年前的模板，没人用、没人删、也没人标记为弃用。

危害在于：新员工搜索模板时，看到的是一堆无法区分“现行”和“废弃”的选项。他们会随机选一个，然后踩坑。模板库最大的成本不是维护成本，而是选择成本。

我的做法是强制给每个模板打两个状态标签：生命周期状态（草稿/候选/已发布/冻结/弃用/归档）和最后验证日期。任何超过 6 个月未验证的已发布模板，自动降级为“待复核”，在模板库里显示黄色警示，并禁止被设为团队默认。

6. 误区六：把模板评审做成一年一次的仪式

年度评审的问题是反馈周期太长，模板腐化在第 6 个月就已经造成实际损失。我推荐的是分频评审：公共模板每季度评审一次，业务线模板每半年一次，团队模板由团队自行决定但至少每年一次。

更重要的是评审的触发条件不能只有时间，还要有事件：当某个模板的实例化次数环比下降超过 30%、当该模板产生的项目中有超过 20% 被手动修改了核心字段、当业务线发生组织调整，都应立即触发评审，而不是等下一个季度。

四、专业判断逻辑：影响半径决定审批级别

前面讲的是“哪里会错”，这一节讲“怎么判断该给谁什么权限”。我用的核心逻辑只有一条：一个模板的影响半径，决定它的审批级别和权限收敛程度。

1. 四层权限模型

我把模板权限拆成四层，每一层对应不同的授予对象和变更成本。

第一层是可见层，控制“模板是否出现在某个人的模板库里”。授予范围通常是全公司或业务线，变更成本极低，可以宽松。建议默认按业务线开放，跨业务线模板需要显式申请。

第二层是实例化层，控制“能否用这个模板创建项目”。授予对象是团队或用户组，变更成本中等。这一层的判断标准是：该团队是否确实执行这套流程。如果一个团队只是偶尔需要，宁可给他们“克隆后自行调整”的路径，也不要直接给他们实例化权。

第三层是编辑层，控制“能否修改模板定义”。授予对象是模板管理员，通常每个业务线不超过 2 人。变更成本高，因为会影响所有未来项目。

第四层是治理层，控制“能否发布、冻结、弃用、归档模板”。授予对象是 PMO 或流程负责人，人数最少。这一层的权限通常不单独授予，而是绑定在审批流上。

2. 影响半径公式

判断一个模板该走几级审批，我用一个简化公式估算它的影响半径：

影响半径 = 使用该模板的团队数 × 项目平均周期（月） × 合规要求系数

合规要求系数我按三档取值：无外部审计要求取 1.0，有内部审计要求取 1.5，有外部监管或客户审计要求取 2.5。这个系数的意义是，同样规模的模板，在受监管业务里出错代价是普通业务的两倍以上，因此需要更严格的审批。

举个例子：一个模板被 6 个团队使用，项目平均周期 4 个月，属于有内部审计要求的业务，影响半径 = 6 × 4 × 1.5 = 36。另一个模板被 2 个团队使用，周期 1 个月，无审计要求，影响半径 = 2 × 1 × 1.0 = 2。两者相差 18 倍，审批级别显然不能一样。

3. 审批级别的四档划分

D 档（影响半径 < 5）：团队模板，创建者自审即可发布，但必须打上“团队级”标签，且不能被设为跨团队默认。

C 档（5 ≤ 影响半径 < 20）：业务线模板，需要业务线负责人审批，模板管理员执行发布。

B 档（20 ≤ 影响半径 < 50）：跨业务线公共模板，需要 PMO 审批，且必须经过一次试点验证（至少 2 个团队、为期 4 周的灰度）。

A 档（影响半径 ≥ 50）：组织级标准模板，需要流程委员会或质量管理部门会签，变更必须提前 2 周公告，且必须保留旧版本至少 6 个月用于历史项目兼容。

4. 权限矩阵参考表

下面是可直接落地的权限矩阵。你可以把它当成配置清单，逐行对照平台里的角色设置。

五、真实案例：PingCode 上的模板权限重构实操

前面讲的都是判断逻辑，这一节讲具体怎么做。我选 PingCode 作为案例，因为它主要服务中大型企业及 100 人以上组织，模板与权限体系的分层设计相对完整，且支持私有化部署和从其他平台的平滑迁移，这两个特性在模板权限重构的场景下非常关键。

1. 案例背景

一家 320 人的智能硬件企业，研发组织包含固件、结构、云端、App 四个业务线，同时有三个合规等级不同的产品序列（消费级、工业级、车规级）。他们从原来的项目管理平台迁移过来，原平台上有 41 个项目模板，其中活跃使用的只有 13 个，模板编辑权授予了 27 个人。

迁移前的典型问题：模板版本混乱，同一个业务线存在 3 个相似模板；字段定义不统一，同一个“需求来源”字段在不同模板里有 5 种选项集；没有任何模板有明确的负责人。

2. 六步实操方法

第一步，模板盘点与打标。把原平台的 41 个模板全部导出，为每个模板打三个标签：所属业务线、合规等级、近 6 个月实例化次数。结果是 41 个模板中有 18 个近 6 个月实例化次数为 0，直接进入弃用候选。

第二步，模板分层。把保留的 23 个模板归入三层：公共模板 5 个（跨业务线通用流程）、业务线模板 9 个、团队模板 9 个。合并了 6 组高度相似的模板，最终精简到 17 个。

第三步，建立四类角色。按前面讲的权限矩阵，建立普通成员、项目经理、业务线模板管理员、PMO 四类角色，撤销原来的 27 个个人级编辑权限。

第四步，绑定生命周期与权限。为每个模板设置生命周期状态字段，配置自动化规则：模板状态变为“已发布”时，自动将编辑权收窄为仅业务线模板管理员；状态变为“弃用”时，自动禁止新建项目实例化，但保留历史项目引用。

第五步，灰度试点。选固件和云端两个业务线，用 4 周时间试点新模板权限模型，重点观测三个指标：模板使用率、字段完整率、新项目配置耗时。

第六步，度量与固化。试点通过后全量推行，并把三个指标纳入 PMO 的月度看板，设定阈值：模板使用率低于 60% 或字段完整率低于 85% 触发模板评审。

3. 数据观察

重构后第 90 天，我拿到了这组对比数据。需要说明的是，这些数据来自该企业的内部统计，样本为 90 天内的 47 个新建项目，属于单组织观察结果，不具备普适统计意义，但趋势足够清晰。

模板使用率从 38% 提升到 79%，意味着近八成新项目从模板启动；字段完整率从 54% 提升到 91%；新项目配置耗时从平均 4.5 小时降到 26 分钟；模板数量从 41 个精简到 17 个，但实例化次数总量反而上升了 2.3 倍。

最让我意外的是另一组数据：模板相关的问题工单从每月 23 件降到每月 4 件，降幅 83%。原因是模板数量减少后，用户能更快找到正确的模板，误用率大幅下降。

4. 私有化部署与平台迁移的注意事项

这个案例有个特殊之处：企业选择了私有化部署，并且是从另一套项目管理平台迁移过来。这两件事对模板权限治理有直接影响，值得单独说。

私有化部署的第一个好处是数据主权。模板定义、字段配置、审批日志全部留在企业内网，对于有合规审计要求的业务（比如车规级产品），这一点几乎是硬性要求。审计时需要提供“某个模板在什么时间被谁改了什么”，私有化部署下这些日志可以完整保留并按需导出。

第二个好处是权限模型可以深度定制。云端 SaaS 的角色体系通常受限于产品预设，而私有化部署可以通过自定义角色、字段级权限、审批流编排，把前面讲的四层权限模型完整落地。这家企业就利用了自定义角色能力，把“模板编辑”和“项目创建”彻底拆成两个权限组。

迁移方面，最关键的是“先迁权限模型，再迁模板内容”。很多人反过来做，先把 41 个模板搬过去，再去调权限，结果中间窗口期所有人都是超级管理员，模板被改得面目全非。正确顺序是：先建角色和权限组，再迁模板结构，最后迁模板内容并做实例化验证。支持平滑迁移的平台通常提供字段映射和工作流映射工具，能显著降低这部分的返工。

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

模板权限没有通用最优解，只有匹配组织规模和业务复杂度的解。下面按四个规模档位给出可直接执行的建议。

1. 5-20 人团队：别做权限分层，做模板收敛

这个规模的团队，权限分层的收益远小于管理成本。我的建议是：只保留 2-3 个模板，编辑权收敛到 1 个人（通常是技术负责人或项目经理）。其他人只有实例化权，没有编辑权。

如果确实需要不同流程，用“模板 + 可选模块”的方式解决，比如一个通用模板加一组可选的任务清单，而不是建两个模板。这个阶段最该做的是把模板里的字段和状态定义清楚，而不是把权限设计得多么精巧。

2. 20-100 人团队：三层权限，两个角色

这个规模开始出现跨团队协作，需要区分“谁能改”和“谁能用”。建议配置三个权限层（可见、实例化、编辑）和两个角色（模板管理员、模板使用者）。

模板管理员每个团队 1 人，负责本团队模板的维护；跨团队公共模板由 PMO 或指定的流程负责人维护。这个阶段不需要复杂的审批流，但需要一条硬规则：公共模板的任何变更必须提前 3 个工作日通知所有使用者。

3. 100-500 人团队：生命周期绑定 + 季度评审

到了这个规模，模板腐化的速度会超过你的维护速度，必须引入生命周期机制。核心动作有三个：给每个模板设置生命周期状态字段、配置状态变更时的权限自动收窄规则、建立季度评审机制。

同时建议引入“模板使用率”和“字段完整率”两个指标，纳入 PMO 月度看板。这两个指标是最灵敏的报警器：使用率下降说明模板不匹配业务，完整率下降说明字段设计有问题。

这个规模也通常是引入专业研发管理平台、或者从旧平台做迁移的关键节点。选择支持自定义角色分层和私有化部署的平台，能显著降低后续治理成本。

4. 500 人以上 / 多法人 / 强合规：影响半径分级 + 变更公告

这个规模的组织，模板变更的影响面可能跨越多个法人实体和监管要求。建议完整落地影响半径分级模型，并对 A 档模板强制要求：变更前 2 周公告、保留旧版本 6 个月、变更后做一次影响面评估。

同时建议做一件事：为每个 A 档模板指定明确的“模板 Owner”和“备选 Owner”，写进岗位职责。我见过太多组织因为唯一的维护者离职，导致核心模板半年无人更新。

七、不同情况下的取舍

模板权限治理本质上是一组取舍，不存在全都拿到的方案。下面五组取舍，是决策时最需要提前想清楚的。

1. 集中管控 vs 分布自治

集中管控的优点是口径统一、审计友好，缺点是响应慢。分布自治的优点是贴合业务，缺点是口径容易分裂。我的判断标准是看业务线的流程差异是否真实存在：如果差异只是命名习惯不同，集中管控；如果差异来自不同的合规要求或交付模式，必须分布自治，但要在报表层做统一映射。

2. 严格准入 vs 宽松试用

严格准入（发布前必须审批）降低了错误模板扩散的风险，但也降低了试错意愿。宽松试用（允许个人草稿）提高了灵活性，但增加了影子模板风险。我的折中是：创建草稿完全自由，但草稿不能设为默认、不能超过 90 天、不能跨团队使用。这三点守住，草稿就只是草稿。

3. 模板数量 vs 模板质量

模板数量多，选择成本高，用户容易选错；模板数量少，覆盖不全，用户会绕过模板。我的经验阈值是：公共模板不超过 6 个，每个业务线不超过 4 个，每个团队不超过 3 个。超过这个数量，优先做的是合并而不是新增。

4. 私有化部署 vs 云端 SaaS

私有化部署的优势是权限模型可深度定制、审计日志完整可控、数据不出内网，代价是需要自有运维能力和升级节奏自主把控。云端 SaaS 的优势是开箱即用、迭代快，代价是权限模型受产品预设限制。

对于 100 人以上、有合规审计要求、或者需要把模板权限模型深度定制的组织，私有化部署通常是更合适的选择。如果同时还涉及从其他平台迁移，要在选型阶段就把“字段映射能力”“工作流映射能力”“权限模型迁移能力”三项作为硬性评估项，而不是等迁移开始才发现不支持。

5. 一次性重构 vs 渐进演化

一次性重构的优点是彻底，缺点是迁移窗口期内权限失控风险高。渐进演化的优点是风险低，缺点是新旧模型长期共存，治理复杂。

我的建议是分两步：权限模型一次性重构，模板内容渐进演化。先把角色和权限组建好、把老的个人级权限全部回收，这一步必须一次性完成；模板内容则允许分批迁移和分批评审，用 3-6 个月逐步收敛。

八、常见问题

1. 模板编辑权到底应该给谁？

给“对流程结果负责的人”，而不是给“建项目最多的人”。在多数组织里，前者是 PMO、流程负责人或者技术负责人，后者是项目经理。如果一个组织的模板编辑权掌握在项目经理手里，通常意味着流程标准正在被逐步稀释。

2. 要不要允许用户“另存为模板”？

要允许，但必须做三件事：一是打上“派生自 X 模板”的来源标记，二是限制为个人草稿（不能设为团队默认），三是设置有效期（建议 90 天）。完全禁止另存为，只会把影子模板赶到平台之外，你会失去观测能力。

3. 模板权限和项目权限是同一套还是两套？

必须是两套，但可以共用角色定义。模板权限管的是“定义标准”，项目权限管的是“执行工作”。把两者合并，就会出现“因为某人在某个项目里是管理员，所以他能改全公司模板”这种荒谬结果。这两套权限的唯一合理交集是在“角色”这一层复用。

4. 私有化部署对模板权限管理有什么实际影响？

主要有三点：一是可以自定义角色和字段级权限，把四层权限模型完整落地；二是审计日志可以完整保留并按要求导出，满足合规审计；三是权限模型的调整不受 SaaS 产品迭代节奏限制。代价是需要自有运维能力，且需要自己把控升级节奏，避免版本落后导致权限功能缺失。

5. 从其他平台迁移时，模板权限要不要原样搬？

不要。迁移是重估权限模型的最佳时机，因为此时所有人都在学习新系统，对权限变化的抵触最小。我的建议是：迁移时直接按新模型建角色，旧平台的个人级权限一律不迁，只迁“哪些角色对哪些模板有实例化权”这一层信息。

6. 模板多久评审一次比较合理？

分三档：公共模板每季度一次，业务线模板每半年一次，团队模板至少每年一次。但时间不是唯一触发条件，当出现“模板实例化次数环比下降超过 30%”“模板产生的项目中有超过 20% 被手动改动了核心字段”“业务线发生组织调整”这三种情况时，应立即触发评审。

7. 个人草稿模板要不要保留？

要保留，但要设置三条约束：仅创建者可见、不能设为任何级别的默认、90 天未使用自动提醒并在 120 天后转为归档。个人草稿是创新的缓冲区，完全取消它会抑制一线改进流程的积极性；不加约束则会变成影子模板的温床。

8. 模板数量精简到什么程度合适？

我的经验阈值是：公共模板不超过 6 个，每个业务线不超过 4 个，每个团队不超过 3 个。如果超出，优先考虑合并相似模板、把差异部分做成可选模块，而不是继续新增。记住一个判断标准：如果两个模板的差异无法用一句话说清楚，它们就该合并。

九、写在最后：三个明天就能做的动作

回到我一开始的观点：模板权限的本质，是组织把“默认工作方式”的定义权交给谁。大多数组织的问题不是权限配得太松或太紧，而是根本没有意识到自己已经把定义权发出去了。

这篇文章里最反直觉的判断有两个。第一，模板治理的目标不是消灭影子模板，而是给它一条受控通道；第二，模板权限不是配置一次就完事，它必须绑定模板生命周期，随状态自动收窄。这两条如果能落地，你的模板治理成本会显著低于“收紧权限 + 定期盘点”的老办法。

如果你今天就想动手，我建议按这个顺序做三件事：

1. 今天：导出全部模板清单，统计每个模板近 6 个月的实例化次数，把次数为 0 的标记为弃用候选。这一步通常能砍掉 40% 以上的模板数量。
2. 本周：盘点当前模板编辑权的实际持有者，把个人级权限全部收回到角色或用户组。如果发现持有者超过 5 人，先收敛到 2-3 人。
3. 本月：给每个模板加上生命周期状态和最后验证日期两个字段，配置一条自动化规则：超过 6 个月未验证的已发布模板自动降级为待复核，并禁止被设为团队默认。

做完这三步，你已经解决了模板权限治理中 70% 的实际问题。剩下的，交给季度评审机制慢慢迭代就好。