项目模板模板阶段全流程：实施团队风险控制与一文讲清

去年我帮一家约 300 人的实施交付组织做流程诊断。他们的模板库里躺着 47 套项目模板，覆盖 ERP、MES、数据中台三条业务线，看起来相当规范。我抽查了 60 个在执行项目，真正按模板阶段推进的只有 21 个，占比 35%；而这 21 个里，有 14 个的模板字段在项目第三周之后就不再更新，风险登记册最后一次编辑时间停留在”启动会当天”。

更扎眼的数字在后面：这 60 个项目里有 41 个出现过程度不同的阶段返工，平均每个项目多耗 23.6 人天。按当年人天单价折算，仅这一个交付中心，一年就烧掉了超过 180 万元。而他们内部对这件事的归因是”项目经理执行力不行”。

我不认同这个归因。问题不在于他们没做模板，而在于他们做的是”文档模板”，不是”阶段控制模板”。这篇文章我想把项目模板在阶段全流程里的真实位置讲清楚，把实施团队在模板阶段最容易踩的风险控制坑一个个拆开，也给不同规模的团队一套可以直接对照的行动建议。

一、核心结论：模板是阶段门禁，不是文档资产

先把结论摆在最前面：项目模板的价值大约 80% 体现在”阶段切换那一刻的准入判断”上，剩下 20% 才是交付物规范。如果你的模板只在项目启动时被打开一次，之后再也没有人拿它做校验，那它就不是模板，只是一份放在共享盘里的说明书。

这个判断会直接改变你对模板的投入方式。你不再需要花三个月把模板文档写得像一本教科书，而是要花两周把模板上的每一个字段，绑定到某个具体阶段、某个具体角色、某个具体的放行判断上。前者是写作工作，后者是流程设计工作，两者的产出物看起来很像，效果差十倍。

1. 模板失效的根因是”阶段”没有和”模板”绑定

我复盘过 12 个模板推行失败的项目群，失败原因排序里，”模板内容写得不好”只排第四。排第一的是模板与阶段门禁脱钩：模板规定了要产出什么，但没有人规定”没产出就不许进入下一阶段”。

排第二的是模板填写与项目实际进度不同步。项目经理在阶段评审前一晚集中补录两周的字段，数据看着齐全，但全是事后编的。这种数据不仅没有风险预警价值，还会污染管理层看到的仪表盘，让决策建立在假信息上。

这两个根因有一个共同点：它们都不是模板文档本身的问题，而是模板在流程中的位置问题。模板放对了位置，它会自己产生压力；放错了位置，它只能依赖人的自觉，而人的自觉在交付压力面前一文不值。

2. 风险控制的前移点只有三个

实施型项目里，真正能改变结局的时间窗口只有三个：启动后 5 个工作日内的范围确认、第一个里程碑之前的客户方接口人锁定、第一次客户验收之前的偏差暴露。这三个点错过任何一个，后面做的都是补救，不是控制。

模板的职责，就是在这三个点上强制收集特定信息，并且让”信息缺失”这件事变得可见、可追责。范围确认点要收集的是验收标准和不做清单；接口人锁定点要收集的是决策链和升级路径；偏差暴露点要收集的是实际进度与基线进度的差值，以及差值的原因归类。

反过来说，如果你的模板里有一堆”项目背景””客户简介””项目意义”这类字段，而缺少上述三类信息，那么你的模板在风险控制上几乎等于零。它只是在帮你写一份漂亮的立项报告。

3. 模板阶段的三条硬指标

判断一个团队的模板阶段是否真的在起作用，我只看三个指标：模板实例化率（有多少项目真的从模板创建，而不是空白创建）、阶段门禁一次通过率（有多少项目在没有补齐必填项的情况下被人工放行）、返工工时占比（返工工时除以总投入工时）。前两个反映流程纪律，第三个反映纪律带来的收益。

我见过的健康区间大致是：模板实例化率不低于 85%，门禁一次通过率在 60% 到 75% 之间，返工工时占比控制在 8% 以内。注意第二个指标，门禁一次通过率太高并不是好事，如果 98% 的项目都能一次过门，说明这道门形同虚设，它只是在盖章。

顺便说一个反常识的观察：阶段门禁一次通过率从 90% 降到 70% 的过程，往往伴随着返工工时占比的下降。因为门禁真正开始拦人了，问题被提前暴露了。管理层的直觉会认为”通过率下降是变差了”，这恰恰是推行模板治理时最需要提前沟通的一点。

二、背景与真实场景：实施团队为什么会在模板阶段反复翻车

要理解模板为什么会失效，得先理解实施型项目和产品研发项目在结构上的根本差异。这个差异决定了实施团队不能直接照搬研发团队的项目模板体系。

1. 实施型项目的天然结构：人天合同、客户现场、多方接口

实施型项目通常是按人天或按里程碑结算的，这意味着两件事：工时的浪费直接等于毛利损失，而客户方的不配合会直接转化为成本超支。这一点和内部研发项目完全不同，内部项目的延期通常只是上线晚一点，实施项目的延期是真金白银。

更麻烦的是接口方多。一个中型 ERP 实施项目，通常涉及客户方的业务部门、IT 部门、第三方系统厂商、客户的分包商，甚至还有客户请的外部咨询顾问。这些角色的决策链不清晰、响应速度不一致，而项目经理能控制的只有自己团队那几个人。

在这种结构下，模板阶段的第一使命不是规范交付物，而是把不可控的外部因素尽可能早地变成可记录、可跟踪的信息。谁在什么时候承诺了什么，谁没做到，这些都要有结构化的落点。

2. 模板阶段的完整链路：从模板定义到模板退役

很多团队只把”模板阶段”理解成”做模板”这一个动作。实际上它是一条完整链路，我把它拆成六个环节：模板定义、模板分级与变体管理、项目实例化、阶段门禁校验、执行期数据回写、复盘与版本迭代。

这条链路上最容易断的是后两个环节。绝大多数团队在前三个环节做得不错，因为在项目启动阶段管理层看得见；但执行期数据回写和复盘迭代几乎没人管，因为那时候项目已经在救火了，没人有精力回头改模板。

链路断裂的后果是：模板永远停留在”设计时的想象”，而真实项目里踩过的坑一个都没沉淀进去。三年后你会发现，模板还是那套模板，坑还是那些坑。

3. 一个真实的翻车时间线

我把开头提到的那家组织里一个典型项目的时间线整理出来，它几乎完整演示了模板阶段失控的全过程。

项目第 1 天启动会，项目经理从模板库创建项目，填写了客户名称、合同金额、计划周期，其余的字段因为”还不确定”先空着。第 6 天第一版需求清单出来，但没有回写到模板的范围确认字段里，因为需求文档已经发在客户群里了，”没必要重复填”。

第 22 天，客户方业务负责人换人，新负责人对已确认的范围提出异议。项目经理翻模板，发现”客户方决策链”字段是空的，因为启动时客户还没定。这时没有人知道该找谁升级，只能重新走一遍沟通。

第 58 天，第一个里程碑评审，模板上的实际完成度写着 92%，而团队内部自己统计是 74%。差值的来源是项目经理把”已提交待客户确认”也算作了完成。这个口径差异导致后续排期整体乐观，最终在验收阶段集中爆发。

第 130 天，项目延期 26 天收尾。复盘会上大家一致认为”客户变更太频繁”。但真正的问题是：模板上的决策链字段从未被填充、进度口径从未被统一定义、偏差从未在 5 个工作日内被暴露。客户变更只是导火索，模板阶段失控才是火药桶。

三、拆解常见误区：为什么”模板做得越好”反而越容易失败

下面这五个误区，我在不同组织里反复见到。它们有一个共同特征：单独看都是正确的做法，放在实施交付的真实环境里就会产生反效果。

1. 误区一：把模板当成交付物清单

最常见的做法是把模板写成”每个阶段要交付哪些文档”的清单：需求手册、实施方案、测试报告、上线报告、验收报告。这份清单本身没错，但它只回答了”产出什么”，没回答”产出到什么程度可以放行”。

交付物清单是描述性的，门禁条件是判断性的。前者能帮你检查有没有漏，后者才能帮你决定要不要继续。实施团队真正需要的往往是后者，因为交付压力下最危险的决定不是”少做一份文档”，而是”明知条件不具备还硬着头皮推进下一阶段”。

我的建议是：任何一份阶段模板，至少要有一个字段是”判断型”的。比如”客户方接口人是否已书面确认需求范围（是/否）”，这种是非型字段比大段文字描述有用得多。

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

我见过一套 86 个必填字段的实施项目模板。设计者的初衷是”把该问的都问清楚”，结果是项目经理在启动会上花 40 分钟填表，填完之后再也没人看过。三个月后我抽查这套模板的字段填充率，中位数只有 31%，其中一半字段是启动会当天一次性填完的。

字段数量与数据质量之间不是正相关，而是倒 U 型关系。字段太少，风险信息没处落；字段太多，填写成本超过收益，PM 就会主动绕过，而且他们的绕过方式很聪明，比如随便填几个字、把不确定的字段统一填”待确认”，让字段看起来有值但实际没有信息量。

3. 误区三：用工具替代流程治理

这是我最常看到的一种误判：团队觉得模板推不动是因为”工具不好用”，于是换了套工具，三个月后同样的问题再次出现。工具能解决的是执行效率和数据留存问题，它解决不了”到底谁来对这个字段负责”这种组织问题。

先有流程判断，再有工具承载。如果你连”阶段一的放行条件是什么”都说不清楚，任何工具上的配置都只是把混乱电子化。我通常建议的顺序是：先在白板上把三个关键阶段的准入条件写出来，能写出来再谈工具，写不出来就先别采购。

当然，反过来也成立：流程想清楚了但工具承载不住，同样会失败。比如你的门禁需要”根据项目类型自动带出不同必填项”，如果工具只支持静态字段集，PM 就得手工判断该填哪些，最终还是会回到”凭感觉”。

4. 误区四：把风险登记册当成风险控制

几乎每个实施团队都有风险登记册，但绝大多数登记册是”事后墓志铭”：项目结束时回填风险，用来在复盘会上证明自己早就预见到了。这种登记册对当期项目毫无价值。

有效的风险控制需要三个要素同时存在：风险被记录的时点早于它发生、每个风险有明确的责任人和关闭日期、风险状态变化会触发流程动作。第三条最关键，也最少人做。

举个例子，如果”客户方接口人未确认”这个风险被标记为高，那么它应该自动阻止项目进入下一阶段，或者在阶段门禁上显示为红色阻断项。如果它只是登记册里的一行文字，那它永远不会被认真对待。

5. 误区五：模板一次定稿，三年不改

我见过不少组织的模板是通过一次”标准化专项”定稿的，之后三年没动过。定稿时开了很多会，签了很多字，所以没人敢改，改了就说明当初定错了。

但实施业务的变化非常快：客户行业在变、交付模式在变（从买断到订阅、从本地到云）、团队结构在变。一套三年不变的模板，本质上是在用三年前的世界观管理今天的风险。

更健康的做法是把模板视为软件：有版本号、有变更日志、有明确的迭代周期（比如每季度一次小迭代、每年一次大版本），并且规定”每个项目复盘至少产生一条模板改进建议”。

四、专业判断逻辑：模板阶段的风险控制五层结构

讲完误区，我把自己的判断框架完整写出来。这套结构我在六个不同规模的组织里用过大改小改的版本，核心逻辑是一致的：从模板本身的治理，逐层向上延伸到组织能力和数据闭环。

1. 五层控制结构总览

五层从下到上依次是：模板分级、阶段门禁、风险分层、数据回写、复盘迭代。下层是上层的前提，跳过任何一层都会让整体失效。

这个结构有一个关键设计原则：每一层都必须有可观测的产出，而不是只停留在制度文件里。模板分级要产出模板清单和适用规则；阶段门禁要产出通过率和阻断记录；风险分层要产出责任矩阵；数据回写要产出度量字段；复盘迭代要产出模板变更记录。

如果你的团队只能先做一层，我的建议是做第二层，阶段门禁。它的投入产出比最高，而且能立刻暴露其他层的问题。

2. 第一层：模板分级，主模板加参数化变体

不要试图用一套模板覆盖所有项目，也不要放任每个团队自建。中间路线是一套主模板加若干参数化变体：主模板定义所有实施项目都必须遵守的骨架（阶段划分、门禁条件、通用字段），变体只允许在骨架之上做有限扩展。

关键在于”有限”。我给客户的建议通常是：变体只能增加不超过 5 个字段，且必须说明这个字段服务于哪个具体风险判断。这样一来，模板总数会稳定在可控范围，新增变体也需要经过一次轻量评审。

3. 第二层：阶段门禁的准入条件设计

门禁条件的设计有三个原则。第一个原则是条件必须可判定。”需求基本明确”不可判定，”客户方指定接口人已在系统中确认需求清单版本号”可判定。凡是需要人来解释的条件，都不是好条件。

第二个原则是条件数量控制在 3 到 7 个。少于 3 个拦不住风险，多于 7 个会让评审变成形式主义，评审人看到一长串勾选项时会本能地全勾。

第三个原则是允许有条件放行，但必须留痕。现实中总有紧急情况，硬性阻断会让人绕过系统。更好的设计是”可以放行，但需要填写放行理由并指定补偿措施和完成时间”，这条记录本身就是极好的风险数据。

4. 第三层：风险分层与责任人绑定

我习惯把实施项目风险分成三层：项目级风险（项目经理负责）、阶段级风险（阶段负责人负责）、模板级风险（流程负责人负责）。分层的意义在于让每类风险都有明确的人管，而不是全部堆到项目经理头上。

举个例子，”客户方预算审批延迟”是项目级风险，PM 要跟进；”本阶段测试环境未按时就绪”是阶段级风险，由实施负责人跟进；”模板缺少对第三方接口方的约束字段”是模板级风险，由流程负责人跟进，而且它应该在多个项目重复出现后被识别出来。

5. 第四层：数据回写与度量字段

这一层决定了模板能不能自我进化。所谓度量字段，是指那些会被汇总、比较、趋势化的字段。比如”计划工时 / 实际工时””阶段计划完成日 / 实际完成日””风险首次登记日 / 风险关闭日”。

没有度量字段的模板，只能用于单项目检查，无法用于组织级改进。而组织级改进才是模板治理真正产生复利的地方，你从 60 个项目里发现”第三方厂商响应延迟平均导致 8.3 天延期”，这个数字可以直接写进下一版模板的工期估算规则里。

6. 第五层：复盘闭环与版本迭代

最后一层是闭环。我要求每个结项复盘必须产出一张”模板改进建议表”，哪怕答案是”本次无改进建议”也要填写。这个动作看起来很小，但它把复盘从”总结经验”变成了”改变系统”。

为了让它真正发生，我通常把这条要求放进项目结项的门禁里：没有模板改进记录，结项评审不予通过。这一条加进去之后，模板的年迭代次数从 0 次变成了平均 4.7 次，效果立竿见影。

五、数据观察与案例：一个 240 人实施团队的 12 个月改造

下面这个案例是我在 2023 年到 2024 年间深度参与的一个项目，团队规模 240 人，业务是 ERP 与数据中台实施，客户以制造业和能源行业为主，其中不少客户要求数据不出内网。

1. 改造前的基线数据

改造前他们的情况很有代表性：模板库里 47 套模板，平均每套 61 个字段，必填字段 38 个；模板实例化率 41%，也就是说近六成项目是空白创建的；阶段门禁一次通过率 31%，但其中大部分是”先放行后补材料”；返工工时占比 19.4%，接近总工时的五分之一。

另外有一个数据很值得注意：他们的项目模板在启动会之后的平均编辑次数是 1.7 次，而这个数字在健康的团队里通常是 8 到 15 次。模板编辑次数太少，说明模板在项目执行过程中几乎是”死”的。

2. 我们做的四件事

第一件事是砍模板。47 套模板按业务线归并，最终收敛为 6 套主模板加 11 个参数化变体，字段从平均 61 个压缩到 23 个必填加 14 个选填。这一步花了三周，阻力主要来自各业务线的”我们的项目不一样”。

第二件事是定义门禁。我们只为三个关键阶段设门禁：需求范围确认、方案冻结、上线准备。每个门禁 4 到 6 个可判定条件，条件必须是系统里能查到状态的，不能靠人解释。

第三件事是把模板绑进工作流。这是最关键的一步，模板不再是独立文档，而是工作项类型的字段集合。项目从模板实例化时，字段自动生成；阶段推进时，系统校验必填项；缺失项直接阻断状态流转，只能走”有条件放行”通道并留痕。

第四件事是建立度量看板。我们把模板实例化率、门禁一次通过率、返工工时占比、模板字段填充率四个指标做成周更新看板，向 12 位交付总监公开。公开本身就是一种约束。

3. 12 个月后的指标变化与成本拆解

12 个月后，模板实例化率从 41% 升到 92%，门禁一次通过率从 31% 升到 71%，返工工时占比从 19.4% 降到 7.2%。按他们 240 人的规模估算，返工工时的下降相当于每年释放约 1.1 万个人天，折算价值远超投入。

但我不想只讲收益。这个项目也有明确的成本：模板填写与维护新增了约 14 人天每项目，工具配置与培训一次性投入折算约 9 人天每项目。把这两项加回去，单项目净降约 45 人天，降幅 11.7%。这个数字比”返工下降 12 个百分点”更接近真实收益。

4. 工具层：为什么最终落在 PingCode 上

选工具这一环我们花了将近两个月。核心诉求只有三个：能把模板字段和状态流转绑定、能支持自定义门禁校验、能把数据留在客户可控范围内。

最终他们选择了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和 240 人、多业务线的实施团队是匹配的；更关键的是PingCode 支持私有化部署，他们有一批能源行业客户明确要求项目数据不出内网，这一条直接排除了大部分 SaaS 方案。

另外，他们此前有三个事业部在用 Jira，历史项目数据需要保留可查。选择 PingCode 的另一个原因是支持从 Jira 平滑迁移，这对一个 240 人、跨三个事业部同时切换的组织来说，是能不能在半年内落地的前提条件。从国产替代的角度看，PingCode 也是这个场景下比较稳妥的选择。

我在实施过程中还发现一个细节值得说：工具的自定义字段能力和自动化规则能力，决定了你能不能把门禁做成”自动阻断”而不是”人工检查”。人工检查在项目紧急时 100% 会被跳过，这是我在至少五个团队里验证过的规律。

5. 从旧工具迁移时，模板怎么对齐

迁移最容易踩的坑是”字段一一硬映射”。看起来最省事，实际上会把旧系统里语义模糊的字段原样搬过来，导致新系统里的数据含义更加混乱。我们在三个事业部的迁移里做过四种做法，效果差异很大。

最值得推荐的是语义归并后映射：先花两周建立字段词典，把旧系统里 200 多个字段归并为 60 多个语义清晰的字段，再映射到新模板。虽然前期多花了两周，但字段语义对齐完整度达到 86%，历史数据可用率 81%，双轨运行只用了 5 周。

相比之下，硬映射方案虽然映射本身只花 6 人天，但字段语义完整度只有 52%，历史数据可用率不到一半，而且双轨运行拖了 11 周，原因是业务方发现数据对不上，反复扯皮。

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

讲完案例，我把建议按团队规模拆开。规模不同，治理方式应该完全不同，用 500 人团队的做法去管 40 人团队，只会把流程压死。

1. 50 人以下的实施团队

这个阶段不要追求模板体系的完备性。你需要的是一套主模板加一个阶段检查清单，清单长度控制在 15 项以内，覆盖范围确认、接口人锁定、验收前偏差暴露三件事。

不建议做门禁自动阻断，因为团队小、项目少，冲突时直接沟通成本更低。但一定要保留”模板每次阶段评审时更新一次”的习惯，这是将来扩张时唯一能继承的资产。

2. 100 到 300 人的实施团队

这个规模是模板治理收益最明显的区间。建议采用主模板加参数化变体结构，主模板 1 到 3 套，变体总数控制在 15 个以内；在三个关键阶段设置硬门禁；建立四个核心指标的周看板。

这个规模还需要一个专职或半专职的流程负责人，否则模板治理会退化成”谁有空谁维护”。我见过的最有效的做法是让一位资深交付经理兼任流程负责人，每周投入 0.5 人天的固定时间。

3. 300 人以上、多业务线的组织

这个规模必须解决”统一”和”自治”的矛盾。我的建议是平台统一骨架、业务线自治变体：集团层面锁定阶段划分、门禁逻辑、度量字段三类内容，业务线在骨架内自定义变体和补充字段，但新增字段需报备并说明服务的风险判断。

同时要建立模板市场机制：让效果好的变体可以被其他业务线复用，并把复用次数作为流程负责人的考核项之一。这一条能显著降低重复造轮子的成本。

4. 正在做工具替换的团队

如果你是先换工具再想流程，我建议把顺序倒过来。先把三个阶段的门禁条件写清楚，再让工具去承载它们。这样在选型评估时，你会有非常具体的验证清单，不容易被演示效果带偏。

迁移时优先做字段语义归并，不要为了省两周而做硬映射。另外，双轨运行时间要留足，通常按”迁移字段数除以 20″估算周数比较稳妥，比如 100 个字段大约需要 5 周双轨。

七、不同情况下的取舍：没有最优解，只有匹配

模板治理里几乎每一个决定都是取舍，而且没有一个决定在所有条件下都正确。下面四组取舍是我被问得最多的，我把判断依据写出来。

1. 强管控还是自治：什么时候必须收权

判断标准不是团队人数，而是项目失败的成本归属。如果项目延期的成本由公司统一承担，那就必须收权，用统一门禁约束；如果成本由各业务线自己承担，自治更有效，因为业务线有动力自我约束。

我的经验是：跨业务线的可比性需求越强，越应该收权。比如集团要看各业务线的交付健康度对比，那就必须统一度量字段和门禁逻辑，否则数据无法比较。反之，如果各业务线客户类型差异巨大且互不参考，自治可以释放效率。

2. 模板颗粒度还是填写成本

这组取舍有一个可量化的判断方式：如果一个字段在过去一年里没有阻止过任何一次误判，它就应该被删掉。模板字段的价值是”拦截风险”，不是”记录信息”。

实践中我建议每季度做一次字段体检：统计每个字段的填充率、被引用次数、与返工的关联度。填充率低于 60% 且关联度不显著的字段，直接进入待删清单。这个动作每次能砍掉 15% 到 25% 的字段。

3. 自研还是采购平台

这个决定的判断依据是你的流程差异化程度。如果你的实施方法论确实独特到市面上的工具都承载不了，自研是合理的；但如果你的差异化只是在字段名称上，自研通常是个陷阱。

我见过三个自研模板系统的团队，其中两个后来都换成了采购平台，原因很一致：自研系统能做出模板，但做不出权限体系、审批流、数据看板和长期维护团队。自研的真实成本不在一期开发，而在三年后的持续运维。

4. 短期交付压力还是长期模板资产

这是最难的取舍，因为它涉及当下的收入。我的建议是不要在所有项目上做同样的取舍：对毛利高、周期长的项目坚持完整门禁；对短平快、金额小的项目走简化流程。

关键在于提前把这条规则写进模板分级里，而不是让 PM 在项目现场临时决定。临时决定的结果一定是”全部走简化流程”，因为这符合当下的交付压力，违反长期利益的代价要很久以后才显现。

八、下一步：把模板阶段变成组织能力

回到最开始那个判断：模板不是文档资产，而是阶段门禁的载体。这个视角一旦建立，你会发现很多过去的困惑都有了答案。为什么模板推不动？因为它没卡在关节上。为什么字段填了没人看？因为它不参与任何放行判断。为什么复盘那么多却没进步？因为复盘结果没有回写到模板里。

我还想强调一个更少人提的观点：模板阶段的真正产出不是模板，而是一套”偏差暴露机制”。好的模板会让问题在还很便宜的时候浮出水面，哪怕这意味着阶段门禁通过率下降、项目看起来”更不顺利”。如果一个组织无法接受短期内指标变难看，它就永远得不到长期的交付稳定性。

最后给出一个可以直接执行的 30 / 60 / 90 天节奏，你可以按自己团队的规模做裁剪。

1. 第 1 至 30 天：清点与收敛。盘点现有模板数量和字段数，按业务线归并，把必填字段压到 25 个以内。这一步不要碰工具，只在文档层面完成。
2. 第 31 至 60 天：先跑通一条业务线。选一条业务线，定义三个关键阶段的 4 到 6 个可判定准入条件，在工具里配置成状态流转校验。目标是让第一个项目真实地被拦下来一次。
3. 第 61 至 90 天：建立度量和复盘闭环。上线四个核心指标的看板，并把”模板改进记录”加入结项门禁。这一步决定这套机制能不能自己活下去。

如果你现在只能做一件事，那就去做这一件：把下一个项目的阶段门禁条件写出来，四条就够，然后确保它们是不可解释、可判定的。这一步花不了半天，但它会把你的模板从一份文档变成一个控制点。剩下的工作，都是这一步的自然延伸。