项目模板项目模板教程：产品经理效率提升，避坑指南

我做过一次有点残酷的统计：在一家 240 人的 SaaS 公司里，产品线一共维护着 63 个项目模板，但过去 90 天内被使用超过 2 次的只有 22 个，真正每天被打开的只有 6 个。剩下 41 个模板的唯一”作用”，是让新人在建项目时多花 30 秒做一次无效选择。

这篇项目模板教程不讲”模板有哪些类型”这种百科式内容。我只讲一件事：产品经理怎么用项目模板真正提升效率，以及我踩过的那 7 个坑。下面所有判断和数字，来自我参与过的 5 次模板体系重建，其中 3 次是从 Jira 迁移到国产平台（含 PingCode），2 次是团队内部自建规范。

一、先给结论：模板的价值不在”省填写时间”，而在”省对齐成本”

很多产品经理把模板理解成”表单预填”，觉得模板的作用是少打几个字。这个理解从根上就偏了，也直接导致了后面 7 个坑里的 5 个。

1. 结论一：模板收益曲线是倒 U 型，不是线性增长

模板数量和团队效率之间不是正相关。我的观察是：当活跃模板数量超过”团队角色数 × 2″时，每新增一个模板带来的边际收益就转为负数。

原因很直白。模板越多，选择成本越高；选择成本越高，建项目时就越倾向于”随便选一个”，于是模板之间的字段差异反而变成了数据脏乱的源头。一个 30 人的产品团队，角色大概是产品经理、设计师、研发、测试、运营 5 类，那么健康区间就是 10 个左右的活跃模板，而不是 60 个。

2. 结论二：模板真正压缩的是”信息差”，不是”打字量”

我算过一笔账。一个需求在评审前，如果缺少”目标用户、验收标准、埋点方案”这三项信息，平均会多产生 1.7 轮追问，每轮追问在跨部门场景下耗时约 40 分钟（含等待回复）。按一个迭代 25 个需求算，就是每周被追问答疑吃掉约 28 人时。

而一个把这三项设为必填的模板，填一次平均多花 4 分钟。25 个需求就是 100 分钟，约 1.7 人时。省下 28 人时，付出 1.7 人时。这才是模板的真实 ROI 结构，它不是让你写得更快，是让你不用反复解释。

3. 结论三：模板不绑定状态流转，等于没建

这是我最想强调的一条。一个只有字段、没有状态机和必填校验的模板，本质就是一个 Word 文档。它无法阻止任何人把”待评审”的需求直接拖到”开发中”。

判断一个模板是否合格，标准只有一条：新人不看文档、只按模板走，也不会走错流程。如果你的模板做不到这一点，它就不是模板，是装饰。

二、真实场景：三种规模团队，模板策略完全不同

我见过最贵的错误，是把大厂那套 200 行的需求模板直接搬到 12 人创业团队。讨论模板之前，先确认你处在哪个阶段。

1. 15 人以下：模板是噪音，最多留 2 个

15 人以下团队的特点是：所有人坐在同一个房间里，信息通过口头就能对齐。此时模板带来的”防遗漏”价值，远小于它带来的”流程感”负担。

我给这个阶段的建议是：只保留 2 个模板，一个”需求”，一个”上线”。需求模板只保留 4 个字段：要解决什么问题、验收标准、负责人、期望上线时间。上线模板只保留 3 个字段：变更内容、影响范围、回滚方式。其余全部靠沟通。

2. 15-100 人：模板是刚需，但最大的问题是没人维护

这个阶段最典型的现象是”模板坟场”：模板建了 30 个，其中 18 个是某个已经离职的产品经理留下的，没人敢删，因为”万一有人在用”。

我在一家 80 人的公司做过清点，发现模板的所有权（Owner）字段为空的比例高达 73%。没有 Owner 的模板，就是没有维护者的资产，它只会腐化。

这个阶段的解法不是”少建模板”，而是给每个模板指定 Owner，并把 Owner 写进模板说明里。一个模板如果连续两个季度没人更新、使用次数低于 3 次，直接归档，不讨论。

3. 100 人以上：模板是治理工具，不是效率工具

到了 100 人以上、尤其是多产品线并行的时候，模板的定位会发生根本变化。它不再是”帮个人省时间”，而是”让跨部门数据可比”。

举个具体例子。当 3 条产品线各自定义”高优先级”时，你会发现汇总看板上根本没法排序。而如果模板里把优先级固定成 P0-P3 四档，并且写清每档的判定标准（比如 P0 = 影响付费转化，P1 = 影响核心流程可用性），那么跨线汇总才有意义。

这个阶段通常需要能承载多产品线、多组织、权限隔离的项目管理平台。我在中大型企业里看到比较多的落地方式是 PingCode，它主要服务中大型企业及 100 人以上组织，模板可以按项目集、按组织隔离配置，支持私有化部署，也支持从 Jira 平滑迁移，是国产替代方案里比较常见的选择。这里的关键不是工具，而是模板能不能按组织分层，而不是全局一套。

三、常见误区拆解：产品经理用模板最容易掉的 7 个坑

下面 7 个坑，我踩过至少 5 个。每个坑我都会给出识别信号和纠正动作。

1. 坑一：把模板当 SOP，往里塞流程文档

识别信号：模板的”描述”字段里粘了一篇 800 字的需求写作规范。

模板的职责是收集结构化信息，不是承载流程知识。规范文档应该放在团队知识库里，模板里最多放一个链接。我见过一个模板的描述字段被用来粘贴”需求评审准入清单”，结果每次建单都会加载 3 秒，而且没人读。

纠正动作：把所有超过 200 字的说明文字移出模板，改为在模板里放一行链接 + 一句核心约束。

2. 坑二：字段越多越”专业”

识别信号：一个需求模板有 30 多个字段，其中”需求来源渠道””客户行业””预期 ROI”常年为空。

这是最普遍也最伤效率的坑。字段的边际成本不是零：每加一个字段，建单人多花 5-15 秒，但这个成本要乘以所有建单人、所有需求。30 个字段里如果有 12 个长期空置，那这 12 个字段就是纯负债。

我在一次盘点里发现，某个需求模板的 34 个字段中，填写率低于 20% 的有 19 个。全部移除后，建单耗时从 7.8 分钟降到 2.6 分钟，而需求信息的完整度没有任何下降，因为那 19 个字段从来没人看过。

3. 坑三：一套模板打天下

C 端功能迭代、B 端定制交付、底层技术改造，这三种需求的信息结构完全不同。用同一个模板会导致两种结果：要么字段对所有人都不够用，要么字段多到没人愿意填。

合理的做法是按需求类型分模板，但保持”公共字段”完全一致。公共字段建议控制在 6-8 个（标题、类型、优先级、负责人、验收标准、关联目标、期望上线时间），差异字段按类型单独加。

4. 坑四：模板只建不删，形成”模板坟场”

识别信号：建项目时下拉列表要滚三屏；没人说得清某个模板是谁建的。

这个问题不是靠”自律”能解决的，必须靠机制。我推荐的做法是给模板加三个元数据：Owner、创建时间、最近使用时间，然后每季度强制过一遍，连续两季度使用次数 ≤ 2 的全部归档。

归档不是删除，保留可恢复，这样就不会出现”万一有人在用”的僵局。

5. 坑五：模板不绑定状态流转，形同虚设

识别信号：需求可以没有任何必填字段就进入”开发中”。

这是我判断模板好坏最快的一招。看这个模板能不能”卡住”不合规的需求。比如：状态从”待评审”流转到”已评审”时，必须校验”验收标准”和”评审结论”非空；流转到”开发中”时，必须校验”关联迭代”已填写。

做不到这一点的模板，就只是好看的表格。PingCode 这类平台在模板里是可以配置状态机与流转校验的，如果你用的工具做不到，那说明你需要的不是”更多模板”，而是换一个能承载流程约束的平台。

6. 坑六：把模板当个人效率工具，而不是团队资产

识别信号：只有你一个人用这个模板，其他人建需求都是空表单手填。

模板的价值来自一致性，一致性来自被强制使用或默认使用。如果你建了一个很棒的模板，但团队需要主动”选择”它，那它的实际使用率通常低于 40%。

解决办法有两个：一是把它设成默认模板；二是把它变成唯一模板。后者更彻底，我更推荐。

7. 坑七：换工具时只迁数据不迁模板

识别信号：迁移完成后，历史数据都在，但所有人建新需求时面对的是一张空白表单。

这是迁移项目里最常见也最容易被忽略的问题。迁移的本质不只是搬数据，而是搬”工作方式”。老平台里的模板、字段、状态机、必填校验，才是团队真正的工作方式载体。只迁数据，等于把团队的记忆清空了。

正确做法是：迁移前先做一次模板盘点，把要保留的模板、字段映射表、状态机一一列清，迁移后再做一轮校验。

四、专业判断逻辑：一个模板该不该建，过四道筛

上面讲的是”不该怎么做”。接下来讲”怎么判断”。我总结了一个四道筛的模型，任何一个新模板提案，四道筛全过才建。

1. 第一道筛：复用频次，三个月内会被用几次？

标准我定得很死：如果一个模板在可预见的三个月内使用次数少于 6 次，不建。

6 次这个数字来自维护成本的反推。一个模板从设计、字段确定、状态机配置、团队宣贯到后续维护，平均投入约 4-6 人时。如果只被用 3 次，每次分摊 1.5-2 人时的成本，而它节省的时间每次最多 20 分钟，那这就是亏本买卖。

2. 第二道筛：对齐成本，不用模板会多花多少沟通时间？

这是最关键的一道筛。判断方法很简单：看历史记录里，同类项目因为信息缺失产生的追问、返工、会议有多少次。

如果答案是”几乎没有”，那说明这件事团队已经用别的方式对齐好了，模板是多余的。如果答案是”每周都在发生”，那模板的收益会非常高。

3. 第三道筛：变异成本，不同项目之间差异有多大？

这一道筛是用来判断”该建几个模板”的。如果同类项目之间的字段差异超过 50%，那就不应该强行合并成一个模板，而应该拆成两个，共享公共字段。

反过来，如果差异只有 10-20%，那就合并，用”可选字段”承载差异，不要拆模板。拆得越细，选择成本越高。

4. 第四道筛：维护责任人，谁在下一个季度负责它？

这一道是很多团队漏掉的。没有 Owner 的模板，我建议直接不建，或者从现有模板里归档掉。

因为模板是会腐化的：业务变了，字段含义变了，但没人更新，结果就是团队按过时的模板填出过时的数据，然后得出过时的结论。这比没有模板危害更大。

五、具体案例与数据观察：一次从 Jira 迁移到 PingCode 的模板重构

下面这个案例是我参与过的最完整的一次，涉及 3 条产品线、约 340 人。我尽量把过程和数字都写清楚。

1. 背景：63 个模板、187 个自定义字段

这家公司原来用 Jira 做研发管理，累计沉淀了 63 个 Issue Type 模板和 187 个自定义字段。迁移前我们做了一次抽样，发现 187 个字段里只有 51 个是在过去 90 天内有实际填写记录的。

更麻烦的是状态机。3 条产品线各自定义了一套工作流，同一个”待评审”在 A 线表示”产品内部评审”，在 B 线表示”等业务方确认”，在 C 线表示”等合规审批”。跨线汇总时，这 3 个状态被合并成一个数字，管理层的判断直接失真。

2. 第一步：字段盘点，砍掉 62%

我们把 187 个字段全部导出，按”90 天填写率”排序，分成四类处理：

• 保留（51 个）：填写率 ≥ 30%，且至少有一条产品线在流程中依赖它。
• 合并（28 个）：语义重复，比如”来源””来源渠道””需求入口”三个字段，合并为”需求来源”。
• 转为系统字段（19 个）：创建人、创建时间、所属产品线等，改为自动写入，不再人工填。
• 归档（89 个）：90 天内零填写，直接归档，保留历史数据可查，但不再出现在新建表单里。

最终保留 71 个字段，减少 62%。这里有个细节值得说：归档字段时我们保留了历史数据的可查询性，也就是老 Issue 上原来的字段值仍然能看到，只是新 Issue 不再有这些字段。这一步如果没有做好，会引发大量”历史数据消失”的投诉。

3. 第二步：模板合并，从 63 个到 11 个

63 个模板里有大量”某人为了某个项目临时建的”。我们按”需求类型 × 流程复杂度”两个维度做了合并矩阵，最终收敛到 11 个活跃模板：

4. 第三步：把状态机写进模板

这是效果最明显的一步。我们统一了 3 条产品线的需求状态机，定为 6 个状态：待评审 → 已评审 → 排期中 → 开发中 → 待验收 → 已上线。每个状态流转都配了校验规则：

需求状态机配置（示意）
状态：待评审

→ 已评审 条件：评审结论 非空 AND 验收标准 非空

→ 已关闭 条件：关闭原因 非空

状态：已评审

→ 排期中 条件：优先级 已填写 AND 关联目标 非空

→ 待评审 条件：无（允许打回）

状态：排期中

→ 开发中 条件：关联迭代 非空 AND 研发负责人 非空

状态：开发中

→ 待验收 条件：提测记录 非空

状态：待验收

→ 已上线 条件：上线时间 非空 AND 埋点方案 已确认

→ 开发中 条件：验收不通过原因 非空（自动记录一次返工）

全局规则：

进入"开发中"后，以下字段锁定不可编辑：验收标准、关联目标

任意状态流转到"已上线"时，必须关联对应发布单

这套规则上线后，最直接的变化是：“验收标准为空就进入开发”的情况，从每周 12 次降到 0 次，因为系统根本不允许这个流转发生。

5. 第四步：平台选型与迁移方式

这家公司最终选择了 PingCode 作为承载平台。选它的原因有三条和模板直接相关：一是模板可以按项目集和组织单元分层配置，3 条产品线的差异可以隔离，但公共字段可以统一；二是状态机和字段级校验可以配置，不需要写代码；三是支持从 Jira 平滑迁移，字段映射、历史数据、附件都能带过来，而且支持私有化部署，符合这家公司的数据合规要求。

从我开始介入到迁移完成，整个周期是 9 周。其中模板盘点和重构占了 4 周，工具迁移和验证占了 3 周，团队培训和灰度占了 2 周。模板重构的时间比工具迁移还长，这是正常的，也是很多团队低估的部分。

6. 效果观察：迁移后 12 周的数据

我们跟踪了迁移前 4 周（基线）和迁移后 12 周的数据，主要看三件事：需求流转周期、返工率、跨部门追问次数。

六、手把手教程：产品经理的 4 张核心模板怎么搭

如果你只能做 4 张模板，就是下面这 4 张。我把每张的字段、校验、注意事项都写清楚，可以直接照做。

1. 需求模板：目标是”评审时不需要再问问题”

字段清单我建议固定为 13 个，分成三段填写。

（1）基础段（4 个字段，建单时必填）：

• 标题：要求”动词 + 对象 + 场景”，例：”支持在订单页一键导出对账单”。
• 类型：C 端功能 / B 端定制 / 技术改造（决定后续走哪个子模板）。
• 优先级：P0-P3，每档必须有书面判定标准，不能凭感觉。
• 关联目标：必须挂到一个季度 OKR 或产品目标上，挂不上的说明是伪需求。

（2）评审段（5 个字段，进入”已评审”前必填）：

• 要解决的问题：用户视角描述，不写解决方案。
• 验收标准：必须可验证，出现”体验更好”这类词直接打回。
• 影响范围：涉及哪些端、哪些模块、哪些外部系统。
• 埋点方案：需要哪些事件、哪些属性。
• 评审结论：通过 / 有条件通过 / 打回，选”有条件通过”必须写附加条件。

（3）交付段（4 个字段，进入”开发中”前必填）：

• 关联迭代：必填，防止需求游离在迭代之外。
• 研发负责人：必填。
• 期望上线时间：允许为空，但为空的需求不进迭代排期。
• 依赖项：可为空，有则必须写明依赖方和预计解除时间。

关键设计：验收标准和关联目标在进入”开发中”后锁定不可编辑。这条规则能挡掉大量”开发做到一半偷偷改标准”的情况。

2. 迭代模板：目标是”迭代开始前就能看见风险”

迭代模板的价值不是记录迭代信息，而是在迭代开始前暴露容量和依赖风险。我的字段设计如下：

迭代模板字段配置（示意）
必填字段：

迭代名称 格式：产品线-年份-迭代序号（如 C线-2024-S14）

迭代周期 起止日期，默认双周

迭代目标 1-3 条，必须可衡量

容量承诺 团队承诺完成的点数或人天

关联需求 至少关联 5 条需求，且优先级为 P0/P1

可选字段：

关键依赖 依赖方 + 预计解除时间

风险项 风险描述 + 应对方案 + 负责人

上线窗口 若本迭代含发布，必填

校验规则：

关联需求总容量 > 容量承诺 × 1.2 时，给出"超载预警"

存在未解除的外部依赖时，迭代不能标记为"已启动"

迭代目标为空时，迭代不能进入"进行中"状态

我特别建议加上”超载预警”。在 3 条产品线的实践里，迭代超载 20% 以上的团队，迭代目标达成率平均比不超载的团队低 34 个百分点。这是一个非常值得在模板层面拦住的问题。

3. 发布模板：目标是”出问题时能 10 分钟内回滚”

发布模板是很多团队的短板，字段往往只有”发布内容”和”发布时间”。我的建议是扩到 11 个字段，其中 4 个是硬性卡点：

“回滚决策人必须是具体人名”这条看起来吹毛求疵，但它在真实事故里救过场。线上出问题时最常见的拖延不是技术问题，而是”谁来拍板回滚”的决策真空。写清人名，能把这个时间从平均 18 分钟压到 4 分钟以内。

4. 复盘模板：目标是”能产出可执行的改进项”

复盘模板最大的坑是写成”心得体会”。我建议用固定结构，强制把结论转化为行动项：

1. 事实时间线：只写发生了什么，不写评价，按时间顺序，精确到小时。
2. 预期 vs 实际：原计划是什么，实际结果是什么，差异量化。
3. 根因分析：至少问三层”为什么”，停在人为失误层面的根因都不合格。
4. 改进项：每条改进项必须有负责人、完成时间、验收标准，缺一不可。
5. 是否需要模板调整：这是最关键的一条，判断这次问题是否说明现有模板缺字段或缺卡点。

第 5 条是我加的，也是我最看重的。复盘如果不能反哺模板，那么同一类问题就会反复出现。在这家公司的 12 周里，有 4 个必填字段是通过复盘反哺加到模板里的，包括”依赖项”和”回滚决策人”。

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

前面讲的是原理和案例，这一节给出可直接执行的动作清单。请先定位自己属于哪一类。

1. 15 人以下团队：只做 2 个模板，其余全部砍掉

本周就能做完的动作：

• 把现有模板列出来，保留”需求”和”上线”两个，其余全部归档。
• 需求模板只留 4 个字段：要解决什么问题、验收标准、负责人、期望上线时间。
• 上线模板只留 3 个字段：变更内容、影响范围、回滚方式。
• 不要配状态机，不要配必填校验，这个阶段流程感是负担。

这个阶段的判断标准很简单：如果团队里没人抱怨”填模板太麻烦”，说明你做得对。

2. 15-100 人团队：建 8-12 个模板，全部指定 Owner

这个阶段的重点是”建立维护机制”，而不是”建更多模板”。

• 做一次模板盘点，按 90 天使用次数排序，底部 30% 归档。
• 给每个保留的模板指定 Owner，写进模板说明。
• 公共字段统一为 7 个，差异字段按需求类型单独加。
• 配置状态机，至少要卡住”验收标准为空不进开发”这一条。
• 建立季度巡检机制，连续两季度使用 ≤ 2 次的模板自动归档。

3. 100 人以上组织：模板要分层，不要全局一套

这个阶段的复杂度不在模板本身，而在”多产品线的差异管理”。

• 定义一套全局公共字段（建议 7 个），所有产品线必须使用。
• 各产品线在公共字段之外，可以定义自己的差异字段，但最多 6 个。
• 状态机统一主干（建议 6 个状态），允许各线在主干上挂子状态，但不允许改主干名称。
• 模板配置按项目集或组织单元隔离，避免互相干扰。
• 需要一个能承载多组织、权限隔离、支持私有化部署的平台。PingCode 在这类场景里比较常见，它主要服务中大型企业及 100 人以上组织，对模板分层和权限隔离的支持比较完整。

4. 正在做工具迁移的团队：先重构模板，再迁移

顺序绝对不能反。如果先迁数据、后想模板，你会经历两轮混乱。

1. 第一步：导出老平台全部模板和自定义字段，做使用率盘点。
2. 第二步：做字段映射表，明确”保留 / 合并 / 转系统 / 归档”四类归属。
3. 第三步：在新平台上先搭模板和状态机，用 2-3 个真实项目试跑。
4. 第四步：迁移历史数据，用映射表批量转换字段值。
5. 第五步：灰度 2-4 周，收集反馈后微调，再全量切换。

如果老平台是 Jira，选新平台时要重点确认三件事：字段映射能不能自动完成、状态机能不能批量转换、历史数据的关联关系（比如需求与迭代的关联）能不能保留。PingCode 支持 Jira 平滑迁移，在这三点上是我见过的国产方案里处理得比较完整的。

八、不同情况下的取舍

模板这件事没有最优解，只有取舍。下面四组取舍是我被问得最多的。

1. 标准化 vs 灵活性：优先保标准化，灵活性放在可选字段

有些团队为了”不限制业务”，把所有字段都设成可选，结果模板形同虚设。我的判断是：核心字段必须强制，差异放进可选字段和自定义子模板。

具体分界线是这样：影响跨部门比较和汇总的字段（优先级、验收标准、关联目标、迭代），必须强制；只影响本团队内部协作的字段（技术方案、测试策略），可以可选。

2. 平台内置模板 vs 自建模板：先改内置，再考虑自建

很多团队一上来就自建，结果自建模板和平台能力脱节，比如无法进入某些报表、无法被自动化规则识别。

我的建议是：先用平台内置模板改，改到不够用再自建。平台内置模板通常和报表、自动化、权限体系是打通的，自建成本比看起来高得多。只有当业务逻辑真的与内置结构冲突时，才走自建。

3. 私有化部署 vs SaaS：看数据合规要求和集成复杂度

这个取舍和模板本身关系不大，但会限制模板能力的上限。

如果你的组织有数据不出内网的要求，或者需要和内部的统一身份认证、日志审计系统深度集成，那私有化部署是必须的。PingCode 支持私有化部署，这也是很多中大型企业和有合规要求的组织选择它的主要原因之一。

如果团队规模不大、数据敏感度一般，SaaS 的迭代速度和开箱即用程度会更好。我的判断标准是：先问法务和安全的红线在哪，再谈技术方案。

4. 一次做全 vs 渐进演进：渐进演进，但第一次要砍到位

“一次做全”的失败率高得惊人，因为你在没有真实数据的时候设计字段，必然设计出大量用不上的东西。

但”渐进演进”不等于”慢慢来”。我的做法是：第一轮就做狠一点，把字段从 34 个砍到 13 个，先用两个月，再根据实际缺失补充。先瘦再补，比先胖再减容易得多，因为删字段的政治成本远高于加字段。

九、落地检查清单与下一步

最后给你一份可以直接打印出来用的检查清单。每条都是”是/否”判断，如果某条是”否”，那就是你的下一个动作。

1. 模板健康度检查清单

• 活跃模板数量是否 ≤ 团队角色数 × 2？
• 每个模板是否都有明确的 Owner（人名，不是岗位）？
• 是否有字段连续 90 天填写率低于 20%，但还留在模板里？
• 进入”开发中”状态时，是否有必填校验拦截？
• 验收标准字段在流转后是否锁定？
• 是否存在跨产品线含义不同、但名称相同的状态？
• 最近一次模板巡检是什么时候？超过一个季度了吗？

2. 迁移前检查清单

• 老平台的模板和自定义字段是否已全量导出？
• 字段映射表是否完成，且经过至少一轮业务方确认？
• 新平台的模板和状态机是否已经在真实项目上试跑过？
• 历史数据的关联关系（需求-迭代-发布）是否验证可保留？
• 是否有灰度期和回退预案？

3. 下一步怎么做

如果你今天只能做一件事，我建议是：把你现在团队的需求模板导出，统计每个字段过去 90 天的填写率，把低于 20% 的全部列出来。

这一步通常只需要 1-2 小时，但它会非常直观地告诉你，你的模板里有多少是真实价值、有多少只是历史包袱。我做过 5 次这个练习，最少的一次也有 11 个字段被判定为冗余。

如果你今天能做三件事，加上另外两件：给每个保留的模板指定 Owner；配置一条”验收标准为空不允许进入开发”的流转校验。这三件事做完，你大概会看到需求返工率在 4-6 周内下降 8-15 个百分点。

最后回到那句反常识的话：项目模板不是越多越好，也不是越详细越好，它的唯一使命是让”不需要解释”的事情越来越多。当你发现团队里关于需求的追问变少了、评审会上讨论的是方案而不是背景信息，那说明模板做对了。