模板任务落地方案：项目负责人开展项目模板的落地方案案例解析

我在三家公司主导过 5 次项目模板落地，成绩最差的一次是：模板在公司知识库发布后 30 天下载了 217 次，但真正用这套模板从立项跑到结项的项目，只有 4 个。同期我做过一次看起来”很随意”的落地，只发了 9 个模板，没做培训、没做考试，90 天后的复用率是 78%。这两次经历让我彻底放弃了”把模板做得更全、讲得更细”的思路，转而研究另一件事：模板不是一个文档问题，而是一个系统入口问题和运营问题。

这篇文章不讲模板应该包含哪些字段，那种清单谁都能拼出来。我要拆的是《模板任务落地方案：项目负责人开展项目模板的落地方案案例解析》里真正难的那部分，一个项目负责人手里没有考核权、没有预算、只借到一个季度的窗口期，怎么让一群已经习惯”随手建个任务”的人，真的按你的模板跑起来，并且在第 90 天还没有退回去。

一、核心结论

先把结论摆出来。这五条是我用 5 次落地、两次失败、一次被推翻重做的代价换来的，不是从方法论书上抄的。

1. 模板落地的唯一验收口径是”第二次复用率”

下载量、培训签到率、模板评审通过率，这三个指标全是过程指标，全都可以被”配合一下”做出来。我在第二家公司做过一次统计，模板培训签到率 96%，满意度打 4.6 分，但 90 天后还在用同一套模板的项目占比只有 13%。

真正能说明问题的只有一个数：用某套模板创建的项目中，有多少个在第二个迭代仍然沿用同一套模板结构。第一次用可能是给你面子，第二次用才是真的有用。我后来把这个口径叫”二次复用率”，它比任何满意度调查都诚实。

2. 模板不是文档，是系统里的一条默认路径

这是最反常识的一条。绝大多数项目负责人的第一反应是”写一份模板文档，发给大家，再开个宣讲会”。但文档的天然属性是可绕过的，只要绕过的成本低于遵守的成本，人就一定会绕。

我做过一个粗糙但有效的对比：同一套模板，A 组用文档下发 + 宣讲，B 组把模板固化成系统里的”新建项目唯一入口”。30 天后 A 组遵守率 44%，B 组 88%。差别不在模板本身写得好不好，而在于用户要不要”多走一步”。

3. 每个字段都必须有一个”消费方”

我把”消费方”定义为：会主动打开这个字段、并且因为它的取值而做出不同动作的人或系统。比如”风险等级”这个字段，消费方可能是每周开风险会的 PMO；如果 PMO 从来不看，那这个字段就是纯填空题。

我复盘过一次失败案例，模板里有 31 个必填字段。逐个追问”谁在看”之后发现，其中 17 个字段没有任何消费方，纯粹是当初设计时”觉得应该有”。这 17 个字段直接导致字段填写完整度从预期的 90% 掉到 52%。

4. 90 天衰减是物理规律，治理机制比模板质量更重要

模板合规率的衰减曲线非常有规律：第 1 周最高，第 4 到第 6 周断崖，第 12 周进入长期低位。我观察过 3 家公司的曲线，形状几乎一致，只是斜率不同。这说明一件事：模板落地不是一次性项目，而是一个需要持续投入的运营动作。

把预算花在”把模板做得更完美”，不如花在”建立一套每月能自动发现退化的机制”上。前者是一次性的，后者是可持续的。

5. 模板数量应该收敛，而不是扩张

我接手 A 公司时，系统里有 47 个项目模板，其中 21 个是”某某项目专用版”。这种专用版大多是某次临时需求留下的化石。模板数量每增加一个，用户的选择成本、维护成本、歧义成本都在上升。

我的经验基准是：一个 300 人规模、产品线不超过 4 条的研发组织，主力项目模板控制在 8 到 12 个是合理的；超过 15 个基本可以判断为失控。

下面这张图是我第一次失败落地的完整转化损耗，它解释了为什么”发布了模板”和”模板落地了”之间差着两个数量级。

二、背景和真实场景

1. 三种典型的模板落地触发场景

我经手的 5 次落地，触发原因只有三类，做法的差异极大。

第一类是组织扩张型。团队从 60 人涨到 200 人，老员工那套”心里有数”的做法没法复制，新人来了没人教，项目质量开始波动。这类需求的核心是”可复制”，模板要承担培训的部分功能。

第二类是工具迁移型。从旧工具或自研表格迁到新平台，顺手重建流程。这类需求看似最简单，实际上是坑最多的，因为大家会下意识把旧工作流的毛病一起搬过去。

第三类是流程失控型。项目数量多到 PMO 收不上数据，汇报口径五花八门，老板问”现在几个项目在延期”需要三天才能答上来。这类需求的核心不是模板本身，而是模板背后的结构化数据。

2. 我接手的那次：起点数据有多难看

我重点讲 A 公司这次，因为它同时命中了上面三类。A 公司约 320 人，软硬件混合研发，4 条产品线，项目负责人 23 名，其中 15 名是从工程师转岗过来的，没有系统学过项目管理。

我进场时拿到的基线数据：系统里 47 个项目模板；新建一个项目平均耗时 3.5 小时，其中大部分时间在”想该填什么”；必填字段 31 个；字段平均填写完整度 52%；里程碑偏差率 34%；PMO 每月花在收集、对齐、补数据上的时间约 26 人时。

最要命的是，我问了 8 个项目负责人同一个问题：”你新建项目时，是打开模板照着填，还是凭记忆填？”7 个人回答凭记忆。模板在他们的工作流里根本不存在。

3. 100 人以下和 300 人以上，根本不是同一件事

这个认知是我踩坑踩出来的。在 60 人的团队，我做模板落地只用了两周，靠的是”一群熟人 + 每周站会口头对齐”，效果很好。我把同一套方法照搬到 A 公司，前两周看起来也不错，第四周直接崩盘。

原因是：小团队的模板靠人际网络传递，大组织的模板必须靠系统传递。60 人时，你和每个人喝一次咖啡就能把规则讲清楚；300 人时，你连人都认不全，任何依赖”记住”的规则都会在两周内衰减掉。

下面这张图是我在不同规模组织里观察到的”每次流程操作平均耗时”，注意单位统一为分钟/次，这样才有可比性。

4. 一个被忽略的变量：新人和老人对模板的诉求相反

这是我第 4 次落地才想明白的事。老人讨厌模板，因为模板强制他填一些他已经知道的信息，降低了速度。新人依赖模板，因为没有模板他不知道该做什么。

如果项目负责人只听到老人的抱怨，就会不断给模板做减法，最后减到新人也没法用。如果只听到新人的呼声，就会不断加字段，最后老人全部绕过。

我的解法是分层强制：模板骨架（阶段、里程碑、必填字段框架）对所有人强制；字段明细对新人默认展开、对老人可折叠。同一个模板，两种视图。这个做法让 A 公司的老人抵触情绪下降了大约一半。

三、五个常见误区

这一节我按”踩坑频次”从高到低排列，每个误区我都给出真实表现、直接后果和修正动作，方便你对照自查。

1. 误区一：把模板当制度文档”发下去”

典型表现是：写一份 30 页的模板说明书，开一次宣讲会，把文档链接发到群里，然后开始等结果。

后果是：宣讲会当天大家很配合，第二周开始有人”临时简化一下”，第四周基本回到原样。因为文档本质上是一个”可选动作”，而人只会做那些不做会出问题的动作。

修正动作很直接：把模板变成系统的默认入口。新建项目时只有一个按钮，点开就是模板选择；不选模板就没法创建。这个改动看起来很小，但它把”遵守”从主动行为变成了默认行为。

2. 误区二：字段越多越”规范”

典型表现是：每个部门都往模板里塞字段，因为”我们到时候要用”。最后模板变成了所有人需求的并集。

后果是填写完整度断崖下跌。这个关系我做过量化观察，不是线性的。字段数从 8 个涨到 18 个，完整度只掉了不到 20 个百分点；从 18 个涨到 31 个，完整度掉了 26 个百分点；再往上掉得更快。

修正动作是消费方判定：每个字段必须能说出一个具体的、会看这个字段的人或系统。说不出来就删掉，不要放到”以后可能有用”的分类里。

3. 误区三：没有 owner 的一版定终身

典型表现是：模板上线那天就是它最完整的时刻，之后半年没人改过。

后果是模板逐渐和实际工作脱节，用户开始打补丁，补丁多了就干脆不用。我统计过 A 公司 47 个模板的”最后修改时间”，其中 29 个超过 12 个月没改过，这 29 个的平均使用率只有 9%。

修正动作是一模板一 owner。owner 不一定是项目经理，可以是某个流程的资深执行者，条件是：他每周都会用到这个模板，并且有权直接改。

4. 误区四：模板与汇报、度量脱钩

典型表现是：模板里填的数据，从来没出现在任何一份周报、月报或评审材料里。

后果最隐蔽也最致命。用户很快会发现”填了也没人看”，于是开始填假数据或者干脆跳过。我在一次访谈里听到最直接的一句反馈是：”这些字段就是给你们 PMO 交作业用的，我们又不用。”

修正动作是让模板字段成为汇报的唯一数据源。月度项目健康度报表、风险清单、资源冲突分析，全部从模板字段自动生成，不再接受手工填报。用户发现”填了真的会被看到、而且会被追问”，填写质量立刻变化。

5. 误区五：迁移时把旧工作流 1:1 搬过来

典型表现是：从旧工具迁移时，把旧工具里的字段、状态、工作流原样复制到新平台，理由是”减少学习成本”。

后果是旧工具的历史包袱被完整继承，而且因为新平台的能力更强，反而能用更多方式实现同一套混乱流程。我见过最夸张的一次，一个项目有 41 个状态，其中 12 个是”废状态”。

修正动作是迁移前先做一轮流程减法。我的做法是列出旧工具的所有字段和状态，逐个问三个问题：过去 12 个月有人用吗？用了之后产生了什么决策？去掉会出什么问题？三个问题有一个答不上来，就不迁。

四、专业判断逻辑

前面讲的是”哪些做法会失败”，这一节讲”我依据什么做判断”。这部分是全篇最接近我个人经验的部分，因为它没有标准答案，只有权衡。

1. 判断一个模板值不值得存在的三个问题

我判断一个模板的去留，只问三个问题，而且必须是能被验证的回答，不接受”以后可能要”。

1. 最近 90 天，它被用过几次？低于 3 次基本可以进入下线观察期。A 公司 47 个模板里有 22 个低于这个阈值。
2. 用它创建的项目，是否比不用它的项目表现更好？我用的代理指标是里程碑偏差率和字段完整度。如果一个模板用了以后项目反而更慢，它的存在就是负价值。
3. 它和另一个模板的差异，能否用一句话说清？说不清就是重复模板。A 公司有 6 个模板，我追问差异后的答案都是”某个项目组的习惯”，这类全部合并。

这三个问题我做成了一张评审表，每季度过一遍。它不完美，但比”凭感觉觉得这个模板还有用”要可靠得多。

2. 模板的四层结构：集 / 项目 / 迭代 / 任务

模板最容易做乱的地方是层级不分。把项目级的信息塞进任务模板，或者把任务级的检查项塞进项目模板，都会导致某一层过重。

我的分层原则是：越往下层，字段越少、越具体、越容易被自动化。

这张表里最容易被忽略的是最后一列。很多团队把项目模板设计得非常精细，然后半年不改，而迭代模板反而应该频繁微调。变更频率和层级是反比关系，搞反了就会出现”上层僵化、下层混乱”。

3. 字段的”消费方判定法”

具体怎么操作？我把模板的每个字段拉成一行，然后填三列：消费方是谁、消费频次、消费后产生什么动作。

字段名称 消费方 消费频次 消费后动作
─────────────────────────────────────────────────────────

项目目标 PMO / 部门负责人 月度 判断是否与季度OKR对齐

里程碑日期 项目经理 / PMO 周度 识别偏差并触发预警

风险等级 PMO 周度 决定是否升级到风险会

关键交付物 质量 / 测试 迭代结束 确定测试范围

依赖项 项目经理 周度 协调跨团队排期

迭代周期 全体 每迭代 决定迭代计划节奏

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

（以下 17 个字段无消费方 → 删除）

这个动作我通常花 2 到 3 小时就能完成一个模板。做完之后 A 公司的必填字段从 31 个降到 14 个，而 PMO 需要用到的数据一个都没少。

反过来看，字段使用频次其实是高度集中的。我统计过 A 公司 38 个字段的实际使用数据，结论是典型的帕累托分布。

4. 哪些必须强制，哪些必须放开

强制的边界如果划错了，模板会从”帮助”变成”负担”。我的划分标准不是”这个字段重不重要”，而是“这个字段缺失会不会导致下游动作无法执行”。

必须强制的，是那些被自动化规则或他人依赖的字段。比如里程碑日期，它触发了偏差预警和资源冲突检查，缺失就会导致预警失效。比如项目负责人，它决定了权限和通知的投递对象。

必须放开的，是那些只有项目内部使用的字段。比如”技术方案简述””团队分工说明”，这些信息在项目内部口头就能对齐，强制填写只会产生敷衍内容。

还有一个中间地带，我称它”条件强制”：某些字段只在特定条件下必填。比如”外部依赖”只在项目类型为”集成类”时必填。这个做法让模板看起来复杂，实际上每个人的填写负担是下降的。

5. 治理节奏：双周微调 + 季度大版本

模板落地失败最常见的时间点是第 5 到第 6 周。这时候新鲜感消失，问题开始暴露，但治理机制还没建立。

我的做法是固定两个节奏。双周微调：每两周花 30 分钟，由模板 owner 处理收集到的小问题，比如字段描述不清、默认值不对。这类改动必须能在 1 小时内完成，否则进入季度评审。季度大版本：每季度做一次完整评审，包括模板去留、层级调整、字段增删。

下面这张图是我在 A 公司观察到的两条衰减曲线，它说明了治理机制到底值多少钱。

五、案例与数据观察

这一节是 A 公司 90 天的完整复盘。我会把过程、数据、踩到的坑和最后的修正都写出来，包括工具选型这一段的真实考量。

1. A 公司的 90 天：四个阶段

第 1-14 天：清点与收敛。把 47 个模板全部导出，逐个做”三个问题”评审。最后保留 9 个，合并 24 个，下线 14 个。这一步没有动系统配置，只是做减法，但它释放了后面所有动作的空间。

第 15-35 天：字段重构。对保留的 9 个模板做消费方判定，必填字段从 31 个降到 14 个。同时把 PMO 的月度报表改成完全从模板字段自动生成，不再接受手工填报。这一步是整个落地中最关键的一步，因为它建立了”填了真的有人看”的因果。

第 36-60 天：入口强制与培训。把模板设为新建项目的唯一入口，同时做了一轮只针对项目负责人的实操培训，时长 90 分钟，不讲方法论，只讲”怎么点、填什么、什么时候填”。这一轮培训的满意度只有 3.9 分，比上一家的 4.6 分低很多，但实际遵守率高出 4 倍。

第 61-90 天：治理机制运转。建立双周微调，第一次微调发生在第 43 天，处理了 11 个字段描述问题。第 90 天做第一次完整复盘。

2. 关键数据变化

我把 90 天前后的核心指标整理成下表。注意这里的每一项都是可以从系统里直接取数的，不是我估算的感受。

这里面我个人最看重的是最后一行。模板维护工时从 26 人时降到 7 人时，说明治理成本随着机制成熟在下降，而不是持续消耗。如果这个数一直不降，说明治理方式太重，不可持续。

3. 模板收敛的工时账

做模板治理最需要说服老板的一句话是”这能省多少时间”。我把 A 公司的账算给他看，算的是人时/月这个口径，因为它可以直接换算成人力成本。

4. 迁移与私有化部署中的模板问题

A 公司的工具选型有一个特殊约束：因为是软硬件混合研发，涉及部分合规要求，必须支持私有化部署。同时旧系统里有三年多的项目数据需要平移。我们最终选择的是 PingCode，主要基于三点判断。

第一是私有化部署能力。PingCode 支持私有化部署，这对我们这种有内网合规要求的组织是硬门槛。我特别提醒一句：私有化部署的评估不要只看”能不能装”，要看升级路径和备份恢复方案，否则三年后会被版本锁死。

第二是 Jira 迁移支持。A 公司的旧系统是 Jira，字段和状态非常复杂。PingCode 提供了 Jira 平滑迁移能力，但我要强调一个经验：迁移工具的自动化程度越高，越容易把历史包袱原样搬过来。我的做法是先做减法再迁移，最终只迁了 38% 的字段和 4 个状态。

第三是中大型组织的适配度。PingCode 主要服务中大型企业及 100 人以上组织，A 公司 320 人的规模和多产品线结构比较契合。如果你的团队在 30 人以下，坦率说这套配置会显得过重，用更轻的方式反而更快。

迁移过程中我踩到的最大的坑，是旧系统里的”自定义字段”在新平台上被批量创建成了模板字段。迁移第一天系统里多出 60 多个字段，如果当时直接放开给用户，模板会瞬间失控。我们花了两天做人工清理，这段经历也在前面那张字段完整度曲线里得到了印证。

5. 二次衰减与回升

第 90 天复盘之后，我没有收工。因为我知道第二个衰减点会在第 120 到 150 天之间到来，触发原因通常是人员流动或业务节奏变化。

果然，第 128 天 A 公司有两个项目负责人离职、三个新人接手，合规率从 82% 掉到 67%。这次回升只用了 9 天，因为治理机制已经在运转：双周微调会上直接识别到了问题，我们把新人引导从”读文档”改成了”模板内联提示”，把最常填错的 4 个字段加了示例值。

这段经历让我确认了一件事：模板落地的最终形态不是”模板很完美”，而是”组织有能力持续修正模板”。前者是状态，后者是能力，只有能力能应对人员流动。

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

这一节我按组织规模分四种情况给建议。不要跨情况套用，我见过太多把小团队的做法硬搬到 300 人组织然后失败的情况。

1. 30 人以下团队

不要做正式的模板落地方案，投入产出比太低。我的建议只有三条：把模板直接做成新建任务的默认项；项目模板控制在 2 到 3 个以内，字段不超过 8 个；不设 owner，由团队负责人兼任。

这个规模的团队，沟通成本极低，任何需要”文档 + 培训 + 治理”三件套的方案都是过度设计。你要做的是让模板”出现在正确的位置”，然后靠日常沟通维护。

2. 50 到 100 人团队

这个规模是分水岭。你需要开始做正式的收敛，但不需要完整的治理体系。我的建议是：先做一次模板清点，把模板数量压到 5 到 7 个；必填字段控制在 10 到 12 个；设一个兼职 owner，每月花 2 小时做一次复盘。

这个阶段最重要的动作是建立”字段有消费方”的规则。因为再过一年团队会到 200 人，那时候补这一课的成本是现在的 5 倍以上。

3. 100 到 300 人组织

这是模板落地最能产生价值的区间，也是我花时间最多的一档。核心动作是四层模板结构 + 消费方判定 + 双周微调 + 季度评审。

有两点我要特别强调。第一，入口必须强制。这个规模已经不可能靠人际网络传递规则了。第二，报表必须只认模板字段。否则用户看不到填写带来的回报，一切强制都会变成形式主义。

如果你在选工具，这个规模区间值得认真评估私有化部署和迁移能力。PingCode 在这个规模段的表现我实测过，作为国产替代方案在 Jira 迁移场景下比较省事，但要记得我前面说的：迁移前先做减法。

4. 300 人以上、多产品线组织

这个规模下，模板不再是工具问题，而是治理问题。你需要的不只是一个模板，而是一套模板治理机制，包含 owner 制度、变更流程、评审节奏、指标监控。

我的建议顺序是：先建立跨部门模板委员会（不需要常设，季度开会即可），再定义模板分层与命名规范，然后才是具体模板的设计。顺序反了就会出现”每个部门都在改模板、没人负责整体一致性”的局面。

A 公司 320 人的规模里，我们最终设了 9 个模板、4 名 owner，每季度开一次 90 分钟的评审会。这个投入强度我认为是可持续的最低配置。

下面这张图展示了不同角色在模板相关操作上的时间变化，用它可以判断模板是否真的在减负。

七、不同情况下的取舍

前面讲的是”怎么做”，这一节讲”怎么选”。模板落地里几乎所有决定都是权衡，没有绝对正确的答案。

1. 规范性与操作效率

这是最根本的一对矛盾。字段越多，数据越规范，但用户操作越慢。我的判断标准是：如果某个字段的填写时间超过 30 秒，它必须能带来明确的决策价值。

30 秒这个阈值来自我的观察：用户在填写一个不确定的字段时，如果找不到明确答案，通常会在 30 秒内放弃并填占位内容。所以超过 30 秒的字段，填写质量本身就不可靠。

2. 强制与自愿

强制能提升短期遵守率，但会消耗信任。我的经验是分级强制：项目骨架强制，迭代与任务模板自愿。理由是项目级别的信息有跨团队消费方，必须统一；迭代和任务级别的信息大多在团队内部消费，允许差异反而更好。

这个划分不是绝对的。如果你们的迭代数据要被 PMO 用于跨团队产能分析，那迭代模板也要提升到强制。核心判断依据始终是：有没有团队外的消费方。

3. 一套模板与多套变体

多套变体让每个团队都舒服，但会让跨团队度量变得几乎不可能。我见过的极端情况是一个 200 人组织有 19 个项目模板，最后 PMO 无法做任何横向对比。

我的做法是骨架统一、细节可变。所有模板共享同一套核心字段（项目目标、里程碑、负责人、风险等级、关键交付物），差异部分通过”可选字段组”实现。这样既保留了团队差异，也保住了度量能力。

4. 私有化与 SaaS

如果你的组织有内网合规要求，或者涉及需要本地化存储的数据，私有化部署是硬性条件而非加分项。PingCode 支持私有化部署，这一点在选择时可以作为一个明确的判断依据。

但要清楚地知道私有化带来的成本：升级需要自己安排窗口、备份恢复要自己设计、性能调优要靠自己。我的建议是把”升级路径是否清晰”作为私有化评估的第一问，比”功能是否齐全”重要得多。

5. 自建与采购

自建的最大诱惑是”完全贴合我们的流程”。我经历过一次自建，实际结果是：前 6 个月很爽，第 12 个月开始没人维护，第 18 个月系统里堆满了临时改动，第 24 个月被迫迁移。

我的判断是：除非你的流程本身就是核心竞争力，否则不要自建。模板落地这件事的价值在执行和治理，不在工具本身。把工程资源投在模板治理机制上，回报比投在自研系统上高得多。

6. 快落地与慢治理

老板通常要快，项目负责人通常知道慢慢来更稳。我的折中方案是：用 2 周完成收敛和强制入口，用 90 天完成治理机制建设。

前 2 周能产出可感知的结果（项目模板从 47 个变 9 个、新建项目从 210 分钟变 22 分钟），足以支撑你在组织内继续推进。后面 90 天是在给这个结果上保险，防止它掉回去。

八、总结与下一步

回到最初那两组数字：217 次下载对 4 个复用项目，9 个模板对 78% 复用率。差别不在模板写得好不好，而在于我有没有把模板放进系统的必经路径，有没有给每个字段找到消费方，有没有在第 5 周那个断崖点之前就把治理机制准备好。

如果这篇文章只能留下一个判断，我希望是这一条：模板落地的成败，取决于你有没有把它当成一个需要持续运营的产品，而不是一次性的交付物。交付物的生命周期在发布那天结束，产品的生命周期从发布那天开始。

一个更容易记住的判断框架是三层验证。第一层，模板能不能被找到（入口是否唯一）；第二层，模板填了有没有人看（字段是否有消费方）；第三层，模板变了有没有人管（是否有 owner 和治理节奏）。三层里缺任何一层，落地都会在 90 天内退化。

最后给你一份可以直接照着做的 30 天清单，这是我实际用过的版本，按顺序执行即可。

1. 第 1-3 天：导出全部模板清单，标注最后修改时间与最近 90 天使用次数。
2. 第 4-6 天：对每个模板问三个问题（用过几次 / 用了是否更好 / 差异能否一句话说清），决定保留、合并还是下线。
3. 第 7-10 天：对保留的模板做逐字段消费方判定，填不出消费方的字段直接删除。
4. 第 11-13 天：把必填字段数量压到 14 个以内，把删除字段的记录存档，方便后续回溯。
5. 第 14 天：把模板设为新建项目的唯一入口，这一步不做，前面全部白做。
6. 第 15-18 天：把月度或季度报表改成只从模板字段自动生成，停止接受手工填报。
7. 第 19-22 天：为每个保留的模板指定 owner，明确他有直接修改权限。
8. 第 23-26 天：做一轮 90 分钟的实操培训，只讲操作不讲方法论。
9. 第 27-30 天：建立双周微调机制，定下第一次微调会的具体时间和参会人。

如果你的组织有 100 人以上、正在做旧工具迁移，我建议把第 3 天到第 6 天的顺序反过来：先做减法评审，再导出清单。迁移场景下，字段和状态会在迁移过程中被批量重建，先清理再迁移能省掉后面大量的返工。我在 A 公司就是顺序做反了，多花了两天做人工清理，这个教训值得记一下。

下一步如果你只做一件事，就做第 14 天那件事：把模板变成唯一入口。它带来的合规率提升占了整个方案的一半以上，而且成本最低。剩下的都是在这个基础上做加固。