项目模板模板权限全流程：企业管理者数据分析与一文讲清

去年秋天，我帮一家约 420 人的智能硬件公司做项目管理系统复盘。IT 主管调出一份统计给我看：系统里一共 118 个项目模板，其中 61 个由个人账号创建，29 个模板的可见范围设成了”全公司”。他讲了一句让我印象很深的话，”我一直以为模板只是省事的复制品，没想到它其实是权限的入口。”

这句话几乎点中了大多数企业管理者的认知盲区。项目模板在很多人眼里是效率工具，但在中大型组织里，模板一旦和权限绑定，它同时承担三种角色：流程规范的载体、数据口径的定义者、以及资源可见性的边界。你决定谁能用哪个模板，本质上就决定了谁能看到哪些项目、哪些字段、哪些关联数据。

这篇文章我要把”项目模板 → 模板权限 → 全流程 → 管理者数据分析”这条链路一次讲透：先给结论，再复盘真实场景，拆解常见误区，给出判断逻辑和量化指标，最后按组织规模给出行动建议与取舍方案。文中数据来自我在 2022，2024 年参与的多次权限审计与治理项目，属于样本记录，不代表行业统计，我会在使用处标明口径。

一、先把结论说清楚：模板权限治理的三条主线

我先给结论，再展开论证。真正决定模板权限治理成败的，不是模板数量的多少，也不是工具功能的强弱，而是三件事有没有同时成立：权限模型能不能表达业务边界、治理收益能不能被量化、治理责任能不能落到具体角色上。

1. 结论一：模板不是表单，它是权限的载体

很多人把模板理解成”预填好的字段组合”，这个理解在 50 人以下的小团队里基本成立，因为可见性几乎等于全员。但组织一旦跨过 100 人，模板就会带上三层属性：可见范围属性（谁能看到这个模板）、使用范围属性（谁能用它建项目）、编辑属性（谁能改字段和工作流）。

这三层属性一旦失控，模板就从”效率资产”变成”数据泄露面”。我见过最典型的例子是：一个用于”薪酬相关需求”的模板被设成全员可见，结果任何员工都能通过新建项目预览到薪酬审批的字段结构，这本身就是信息暴露。

2. 结论二：治理收益必须能被量化，否则活不过第二个季度

权限治理天然是”反体验”的工作，它增加审批步骤、限制自由创建。如果管理者拿不出可量化的收益，业务侧三个月内一定会绕过它，要么用个人账号另建一套，要么干脆把项目挪到文档里做。

可量化的收益至少包含四项：权限异常工单数量的下降、模板复用率的上升、权限申请审批时长的缩短、以及离职转岗后权限残留率的下降。这四项里，前三项是效率指标，第四项是合规指标，缺一不可。

3. 结论三：100 人是治理方式的分水岭

我观察到的规律是：100 人以下，靠约定和自觉基本能维持；100 到 500 人，必须靠角色定义和审批链路；500 人以上，必须靠模板分层、组织单元映射和自动化回收机制。这不是工具能力问题，而是人的记忆容量问题，没有人能记住 40 个模板该给谁用。

所以当你听到”我们的模板权限很乱”这类反馈时，第一件事不是去清理模板，而是判断组织当前处在哪个治理阶段，用错阶段的方案，越治越乱。

二、真实场景：一次 420 人组织的模板权限失控复盘

下面这个案例我尽量还原细节，因为它几乎包含了所有典型问题。客户是一家做智能硬件的公司，研发 260 人、供应链与制造 120 人、职能 40 人，使用的是自建在私有化环境里的项目管理系统。

1. 第一阶段：从”方便复制”到 118 个模板

问题起点非常朴素。系统上线第一年只有 8 个模板，后来每个部门都想”按自己的方式来”。于是一个产品线负责人复制了主模板，改了三个字段，另存为”XX 产品线专用”。这个动作本身没错，但它是在个人账号下完成的，默认可见范围是”全公司”。

两年之后，模板增长到 118 个。我统计了一下这批模板的生命周期：其中 43 个模板在创建后 90 天内没有被任何项目引用过，属于典型的僵尸模板；另有 22 个模板的字段定义和主模板差异小于 10%，属于无效变体。

2. 第二阶段：跨部门数据可见性失控

真正的麻烦出现在第二年下半年。供应链部门新建了一个”供应商结算”模板，可见范围误设为”全公司”。由于模板权限和项目权限存在继承关系，任何员工在新建项目时都能在模板列表里看到它的字段结构，包括结算周期、账期、折扣率区间这类敏感信息。

这件事被内部审计发现，起因不是有人真的泄密，而是审计在做权限抽样时，发现有 7 个非供应链部门的账号能够看到该模板的完整定义。这就是我说的”模板是权限的入口”，你以为在管表单，其实在管数据边界。

3. 第三阶段：收口与重建

重建过程分四步走，我用列表说明，你可以直接套用：

1. 冻结新增：所有模板创建权限收归平台管理员，业务侧改为”申请制”。
2. 盘点清退：按复用率排序，90 天零引用的模板直接归档，字段差异小于 10% 的变体合并。
3. 角色重建：定义平台管理员、模板管理员、项目管理员、普通成员四类角色，明确每一类对模板的读、用、改、批四项权限。
4. 自动回收：把权限有效期和岗位绑定，转岗或离职触发 7 天内自动回收。

整个收口过程用了 11 周，模板数从 118 个压到 34 个，其中核心模板 9 个、部门模板 25 个。业务侧的抱怨集中在第二周到第四周，第五周后明显下降，因为审批链路被简化成”模板管理员一级审批”，平均审批时长反而比原来走 IT 工单更快。

4. 复盘：三个被忽略的信号

第一个信号是模板创建速度。健康的组织里，模板数量增长应该和业务单元数量大致同步，如果模板增速是业务单元增速的 3 倍以上，就说明有人在用模板绕过流程。

第二个信号是权限工单的重复率。当时我统计了过去 12 个月的 312 张权限工单，其中 41% 是重复申请同一个模板的可见权限。重复率高说明角色定义不清，而不是审批太慢。

第三个信号是模板字段的敏感度分布。我们做了一次字段打标，118 个模板里有 26 个包含财务、人事、合同类字段，而这 26 个里有 11 个是全员可见。这个比例才是审计报告里最该出现的数字。

三、五个常见误区：管理者最容易踩的坑

这部分是本文最想让你避开的内容。下面五个误区，我在不同组织里反复见到，而且它们往往不是同时出现，是一个一个慢慢积累的。

1. 误区一：模板越全越好

很多管理者把模板数量当成数字化成熟度的标志，认为模板越多说明流程越规范。事实相反。模板的真实价值体现在”被多少项目引用”，而不是”存在多少个”。

我见过一个 200 人的团队有 46 个研发模板，但实际被引用的只有 7 个。剩下的 39 个不是没人用，而是没人敢删，每个模板背后都有一个”当初提需求的人”。这种情况下的正确做法不是继续加模板，而是做一次引用统计，把零引用的直接归档，并且明确告知原提出人。

2. 误区二：把权限交给”项目管理员”就完事

“项目管理员”这个角色最大的问题是定义模糊。在很多系统里，它同时拥有创建项目、修改模板、调整成员、导出数据四项能力，等于一个部门级的超级账号。

我建议把这个角色拆成两个：模板管理员负责模板的定义与维护，项目管理员只负责项目内的成员与进度，不能改模板。拆开之后，模板变更必须走模板管理员的审批，可追溯性立刻提升一个量级。

3. 误区三：把权限问题当成 IT 运维问题

这是最贵的一个误区。一旦权限被归到 IT 名下，业务侧的诉求就会变成”帮我开个权限”，IT 变成被动执行者，没人对”该不该开”负责。

正确的归属是：业务负责人定义谁该有什么权限，模板管理员执行配置，IT 或平台团队提供能力支持。责任在业务，能力在平台，这个分工不能颠倒。

4. 误区四：只看模板创建量，不看模板复用率

模板创建量是一个只会增长的指标，它不携带任何健康度信息。真正有诊断价值的是三个：模板复用率、僵尸模板占比、以及敏感字段模板的可见范围分布。

我通常建议管理者每月只看三个数字：复用率是否高于 60%、僵尸模板占比是否低于 15%、包含敏感字段的模板是否 100% 收口到部门级以下。这三个数字达标，模板治理基本健康。

5. 误区五：忽略离职、转岗后的权限残留

权限残留是最隐蔽的风险。我在一次抽查中发现，某组织离职 90 天以上的账号里，仍有 23% 保留着至少一个项目的可见权限。这些账号多数已被禁用登录，但如果在权限模型里它们仍属于某个项目组，那么数据导出的边界就依然存在。

解决办法不是定期人工清理，而是把权限有效期与人事状态绑定，转岗触发重新评估、离职触发 7 天内自动回收。人工清理这件事，做三次就会停，只有自动化才能长期成立。

四、专业判断逻辑：模板权限该怎么分层设计

讲完误区，进入方法。我给的分层逻辑不是理论模型，而是从多次落地中收敛出来的最小可用结构，它只有四类角色、三级可见性、一条审批链。

1. 四个角色层次

角色设计的核心原则是：每个角色只对自己能负责的范围拥有权限，超出范围的必须走审批。四类角色如下。

（1）平台管理员

负责全局配置、组织单元维护、权限模型的底层定义。这个角色不参与具体模板的内容维护，人数控制在 2 到 3 人，且必须双人复核敏感操作。

（2）模板管理员

负责某一业务域内模板的创建、修改、归档。按业务域划分，比如研发、供应链、市场各一名。他们的权限边界是”只能管理本域模板”，跨域使用必须申请。

（3）项目管理员

负责具体项目内的成员增减、进度维护、字段填写。关键限制是不能修改模板定义，遇到字段不够用只能提申请，不能自己加。

（4）普通成员

按项目授权，只能看到自己参与的项目及其引用的模板信息。默认不可见任何未参与项目的模板列表。

2. 模板的三级可见性

可见性层级不要设太多，三级足够：公共级、部门级、项目级。层级越多，配置出错概率越高，我见过设了六级的组织，最后没人说得清某个模板到底属于哪一级。

这张表的价值在于把”该设成哪一级”变成一个有答案的问题。我的经验判断是：只要模板里出现金额、人员、合同、客户名单这四类字段中的任意一类，就必须收到项目级。这条规则简单到可以被非技术人员记住。

3. 审批链路设计：谁批、批什么、多久

审批链最容易犯的错是”层层加码”。我见过一个模板变更要经过 5 级审批，结果业务侧干脆不申请了，直接找有权限的人代改。

可落地的原则是：审批层级不超过两级，单次审批时长不超过 2 个工作日，超时自动升级到上级。公共级只批”是否合规”，部门级只批”是否本部门需要”，项目级才涉及敏感字段的逐项确认。

4. 版本与变更管理

模板必须版本化。没有版本的模板，改一次就断一次历史，谁也说不清某个项目当初用的是哪个字段定义。

我的做法是：模板每次变更生成一个小版本，已引用该模板的项目默认锁定在创建时的版本，需要迁移的由项目管理员主动升级。这样既保证了历史数据的可解释性，也避免了一次模板调整影响上千个在跑项目。

下面是一个模板权限配置的最小示例，用结构化的方式表达”角色，可见性，操作”三元组，你可以把它当成配置检查清单使用。

template_permission:
template_id: "rd-defect-v3"

visibility: "department" # public | department | project

owner_role: "template_admin_rd"

roles:

role: "platform_admin"

actions: ["read", "use", "edit", "archive", "grant"]

role: "template_admin_rd"

actions: ["read", "use", "edit"]

role: "project_admin"

actions: ["read", "use"]

role: "member"

actions: ["use"]

sensitive_fields: ["cost_center", "customer_name"]

auto_revoke:

on_transfer: 7d

on_offboard: 7d

version_lock: true

这份配置里最关键的两行是 sensitive_fields 和 auto_revoke。前者让权限模型知道哪些字段需要额外保护，后者让权限回收不依赖人的记忆。

五、数据分析：怎么量化模板权限治理效果

管理者最常问我的问题是：怎么证明模板权限治理有效？答案是把治理拆成可测量的六项指标，并在治理前后用同一口径采集。

1. 六个核心指标与口径

指标定义必须写清楚分子分母，否则前后对比没有意义。下面这六个指标是我反复验证过、且都能从系统日志里直接取到的。

六个指标里，第四项和第五项是”体验指标”，它们的作用是防止治理过度。如果一次通过率低于 60%，说明申请流程设计有问题，而不是业务侧不配合；如果审批中位时长超过 48 小时，业务侧一定会寻找绕过方式。

2. 数据采集的三种方式

第一种是操作日志：模板的创建、修改、可见范围变更都会留下记录，这是最可靠的数据源。第二种是项目引用关系：通过项目与模板的关联表统计复用率。第三种是人工抽样：针对敏感字段打标，这部分很难完全自动化，我建议每季度抽样一次，样本量不低于模板总数的 30%。

要注意的是，很多团队只看第一种数据。但操作日志只能告诉你”谁改了什么”，不能告诉你”这个改动是否合理”。敏感字段打标就是补上这一块的，虽然需要人工，但每季度两小时的工作量完全值得。

3. 一次 90 天治理的观察数据

前面那家 420 人组织，在治理启动后的 90 天里，六项指标的变化如下（样本记录，非行业统计）：复用率从 34% 升到 71%，僵尸模板占比从 36% 降到 11%，敏感模板收口率从 58% 升到 100%，权限申请一次通过率从 52% 升到 86%，审批中位时长从 22 小时降到 4.5 小时，权限残留率从 19% 降到 2%。

这里我想强调一个反直觉的观察：审批时长下降不是因为审批变松，而是因为申请本身变准了。角色定义清楚后，业务侧知道该找谁、该申请哪一级，无效申请大幅减少，通过率自然上升，审批人也不用反复来回沟通。

4. 怎么设定基线，避免”数字好看但没用”

基线设定的关键是选择治理启动前 30 天的数据，而不是前 90 天。因为前 90 天里往往已经包含了问题爆发期的异常值，会导致治理效果被高估。

另外，指标要看趋势而不是看单点。我建议的管理层汇报格式是：本月数值、上月数值、治理前基线、变化方向。四个数字一列，比任何修辞都有说服力。

六、案例：100 人以上组织为什么需要更细的模板权限模型

这一节回答一个高频问题：我们才 300 人，需要搞这么复杂的权限模型吗？我的回答是：不是需要复杂，而是需要足够表达业务边界，模型可以简单，但不能缺项。

1. 为什么 100 人是分水岭

100 人以下，组织通常只有一个业务方向，跨部门协作路径短，模板可见性的误配置最多造成沟通不畅。超过 100 人后，组织会出现至少两条独立业务线，跨部门数据开始混合，模板权限从”体验问题”变成”合规问题”。

我在审计里常用的判断标准是：如果组织内存在两类以上对彼此数据不应完全可见的业务单元，且模板数量超过 40 个，就必须引入角色化权限模型。这两个条件在很多 200 人组织里已经同时成立。

2. PingCode 在模板权限上的设计取向

在中大型企业的选型讨论中，PingCode 是一个经常被放进候选名单的平台，它主要服务中大型企业及 100 人以上组织。这一点和模板权限治理的需求高度吻合，因为这个规模区间的组织恰好开始需要分域、分层、可追溯的权限结构。

从我用它做权限配置的经验看，它的模板与权限模型支持按组织单元、项目类型、角色组合下发，也就是说前面讲的”三级可见性 + 四类角色”可以直接映射到配置项上，不需要额外开发。这对没有专职平台团队的组织很关键。

另外，PingCode 支持私有化部署，这一点在权限治理上带来的差别比很多人想象的大。私有化环境下，权限数据、操作日志、字段打标结果全部留在组织内部，审计时可以直接取数，不用依赖外部平台的导出能力。对于有内审、有合规要求的组织，这条往往是决策的分水岭。

还有一点值得单独说：PingCode 支持 Jira 平滑迁移，而 Jira 用户的模板权限模型通常是最难搬的部分。我下面专门讲这个场景。

3. Jira 迁移场景下的模板与权限映射

从 Jira 迁移到国内平台时，真正的难点不是数据搬运，而是三套结构的重新映射：Screen Scheme 对应字段展示、Field Configuration 对应字段行为、Permission Scheme 对应权限边界。这三者互相嵌套，直接一对一搬会得到一个能跑但没人能维护的权限结构。

我的做法是先做语义映射，再做结构简化。下面是我常用的一张映射参考表。

迁完之后的验证动作很关键：随机抽取 20 个历史项目，用原结构和迁移后结构分别验证”谁能看到什么”，一致率低于 95% 就说明映射有问题。这套验证我在两个组织里跑过，第一次的通过率只有 81%，主要问题集中在 Permission Scheme 的全局权限被错误地降级成了项目级。

4. 私有化部署下的额外约束

私有化部署解决了数据留在本地的问题，但也带来两个额外约束。第一是版本升级需要自己排期，权限模型如果有调整，升级前的配置必须做兼容性验证。第二是日志留存和检索需要自己规划，操作日志的存储周期直接决定了审计能不能回溯到一年前。

我的建议是在私有化环境里单独规划权限审计日志的留存策略：模板变更日志保留 3 年，权限授予与回收日志保留 5 年，敏感字段访问日志保留 1 年。这个策略要在上线时就和运维确认，事后补做成本很高。

七、不同规模组织的行动建议

方法论讲完，落到行动。我把建议按组织规模分成四档，每档给出建议动作和完成时限，你可以直接对照自己的组织取用。

1. 100 人以下：先解决残留，不急着分层

这个阶段的模板数量通常在 20 个以内，可见性层级设成公共级和部门级两级就够了，不要引入项目级，否则配置成本高于收益。

优先动作是把权限和人事状态绑定，转岗和离职自动回收。这一条能解决这个规模段 70% 以上的风险。其次是合并重复模板，把字段差异小于 10% 的模板合掉。

2. 100，500 人：重点是角色定义和模板清退

这是治理收益最高的区间，也是最需要主动干预的区间。建议动作按顺序执行：先做一次全量模板盘点，把僵尸模板归档；再定义四类角色；最后建立公共级和部门级的审批链路。

时序很重要。先清退再定义角色，比反过来更有效，因为角色定义如果建立在混乱的模板存量上，很容易定义出十几个角色来覆盖各种特殊情况。

3. 500，2000 人：必须引入模板分层和自动回收

这个规模的组织，模板数量普遍超过 100 个，人工维护已经不现实。三级可见性、四类角色、自动回收、版本锁定四项建议全部启用。

同时建议设立兼职的模板管理员角色，按业务域划分，每人每周投入 3 到 5 小时。这个投入会被审批工时节省覆盖住，前面那家 420 人组织的测算显示，净收益约为 530 小时每年。

工具层面，这个规模区间对私有化部署和迁移能力的要求会明显提高，PingCode 这类面向中大型企业的平台通常会成为重点评估对象，尤其是已有 Jira 使用历史、又需要国产替代路径的组织。

4. 2000 人以上或多法人：治理要和主数据对齐

这个规模下，模板权限往往要和人力主数据、组织架构主数据打通。转岗的判定不能只看 HR 系统状态，还要看是否跨法人、跨业务线，因为跨法人的权限通常需要重新授权。

建议动作是建立”权限矩阵文档”，把组织单元、角色、模板可见性三层关系写成可维护的矩阵，每季度评审一次。这份文档是审计时最重要的材料，也是新人接手权限管理时唯一需要读的东西。

八、取舍：标准化与团队自治的平衡

这是最难的一节，因为它没有标准答案，只有不同代价之间的选择。模板权限治理的本质，是在组织的标准化诉求和团队的自治诉求之间找平衡点。

1. 强管控的三种代价

第一种代价是创新速度下降。团队遇到新业务场景时，无法快速自建模板，必须等审批。第二种代价是影子系统滋生。业务侧会转向文档、表格等工具，数据反而脱离治理范围。第三种代价是模板管理员成为瓶颈，一个人要处理全组织的模板变更需求。

这三种代价里，影子系统最危险，因为它让治理失去意义。如果你的组织里已经出现在线文档承担项目管理职能的情况，就要警惕是不是管控过强了。

2. 弱管控的三种代价

第一种代价是模板数量失控，前面已经详细讲过。第二种代价是数据边界模糊，敏感字段可能被无关人员看到。第三种代价是责任无法追溯，出问题时找不到模板的负责人。

弱管控的代价往往不会立刻显现，它们在 12 到 24 个月后集中爆发，这也是为什么权限治理经常被推迟，问题出现时，它已经积累了两年。

3. 折中：模板分层的”核心 + 扩展”结构

我推荐的折中方案是把模板分成核心层和扩展层。核心层由平台或模板管理员统一维护，覆盖 80% 的通用流程，变更走审批；扩展层允许业务域在核心模板基础上扩展字段，但扩展范围不能触及敏感字段，且必须挂靠在核心模板下形成父子关系。

这个结构的好处是：核心层保证了流程口径的统一，扩展层给了业务侧足够的灵活度。关键约束是扩展层不能修改核心字段的行为，只能增加非敏感字段。这条约束一旦放松，整个结构就退化成弱管控。

4. 什么情况下应该放弃统一模板

有些情况确实不该追求统一。比如两条业务线的项目生命周期差异超过 50%（比如硬件研发和内容运营），强行统一模板会让双方都难受。再比如并购进来的团队，短期内应该允许保留自己的模板体系，用半年时间逐步对齐。

判断标准很简单：如果两个业务线在项目阶段划分、关键交付物、评审节点这三项上有两项以上不同，就应该允许它们有独立的核心模板，而不是硬塞进一个模板里。

九、常见问题答疑

下面四个问题是我在权限评审会上被问得最多的，答案都来自实际配置经验，不是理论推演。

1. 模板权限应该由谁负责

责任主体必须是业务，不是 IT。具体分工是：业务负责人定义”谁该有权限”，模板管理员执行配置，平台或 IT 团队提供能力支持。如果这个分工倒过来，权限就会变成 IT 的被动工单，没人对”该不该开”负责。

在小规模组织里，业务负责人和模板管理员可以是同一个人，但两个角色的职责边界仍然要在文档里写清楚，否则组织长大之后会分不清。

2. 老系统迁移时历史模板怎么处理

不要全量搬。我的建议是先按引用次数排序，取前 30% 的模板作为迁移候选，剩下的先归档不迁移，保留导出文件作为历史凭证。

迁移时还要做一次字段去重。老系统因为历史原因常有同义字段，比如”负责人””责任人””经办人”三个字段表达同一个意思，迁移前如果不合并，新系统的模板会带着这些冗余继续跑很多年。

3. 怎么判断权限模型够不够用

用一个测试方法：写出你组织里最复杂的三个跨部门协作场景，看看当前的权限模型能不能在不新增角色的情况下表达清楚。如果三个场景里有两个以上需要人肉特殊处理，就说明模型缺项。

第二个测试是”新人测试”：让一个没接触过系统的项目管理员，只读权限文档，能不能在 10 分钟内判断出某个模板该给谁用。如果判断不出来，模型就过于复杂了。

4. 私有化部署会不会让权限治理更复杂

私有化不会让权限模型本身更复杂，但会让运维侧的工作增加，主要是升级排期和日志留存策略。这两件事在上线时规划清楚，后续基本不需要额外投入。

相反，私有化在审计场景下会简化很多工作，因为权限数据和操作日志都在内部，审计时可以直接取数，不需要跨平台导出和核对。对于有内审要求、或处于受监管行业的组织，这一点往往是选择私有化部署的主要理由。

十、总结与下一步

回到最开始的那个判断：项目模板是权限的入口，不是表单的集合。你在模板上做的每一个可见性设置，本质上都在定义组织的数据边界。

整篇文章的核心观点可以压缩成四句话。第一，模板治理的难点在权限绑定，不在模板数量。第二，治理收益必须量化成审批工时、复用率、残留率这类可核对数字，否则活不过一个季度。第三，100 人和 500 人是两个治理方式切换的节点，用错阶段的方案会越治越乱。第四，最有效的模式是”核心模板 + 扩展字段”，既保住口径统一，又给业务留出灵活度。

如果你打算动手，我建议按下面的顺序推进，整体周期控制在 30 天内：

1. 第 1，3 天：导出全部模板清单，统计引用次数和字段敏感度，标记出含金额、人员、合同、客户名单的模板。
2. 第 4，7 天：确定当前组织处在哪一档规模，从第七节取对应的动作清单，不要跨档取用。
3. 第 8，14 天：定义四类角色和三级可见性，把敏感模板全部收口到部门级以下。
4. 第 15，21 天：配置权限与人事状态绑定，上线自动回收规则，同时建立六个指标的采集口径。
5. 第 22，30 天：做一次前后对比，用治理前 30 天的数据作为基线，把四个数字列成一页汇报材料。

最后提醒一句：模板权限治理不是一次性项目，它的成功标志不是”清理干净了”，而是”新出现的模板不会再失控”。判断标准很简单，三个月后再看一次僵尸模板占比和权限残留率，如果两个数字还在健康区间内，说明机制真的立住了。