项目章程模板可以同时承担两个作用：作为立项评审的评审底稿，以及作为启动授权的签署载体。前提是先把目标、范围、里程碑、资源、预算、风险和验收标准填成可评审的版本，再按角色组织结构化评审，逐条记录意见并完成修改闭环，最后由授权人依据评审结论在冻结版本上签署。本文按单项目立项场景展开，说明从填模板到完成签署、留下审批痕迹的完整做法。
要点总览（TL;DR）
- 把项目章程模板同时当作评审底稿和签署载体：先填成可评审版本，再组织评审、闭环修改，最后在冻结版本上签署。
- 章程中的目标与成功标准、范围与不做什么、里程碑、资源、预算、风险、验收标准，分别对应评审判断和授权边界，签署区需写明签署人、角色、日期、版本号和授权结论。
- 起草人负责填写与修改闭环，业务、技术、财务、法务按需评审，授权人依据评审通过的版本签署，归档责任人保证签署版本与评审记录成对保存。
- 审批痕迹靠证据链核验：从签署版本反查评审记录，从评审意见反查修改版本，每条必改意见都有闭环结论；授权后变更需追加版本和批准记录。
- 评审与签署结束后，用字段完整性、意见闭环、签署人授权匹配、版本对应和归档齐全五项检查确认是否到位。
核心步骤：从填模板到完成授权签署
把章程模板用起来的关键，是让每一步都有明确的输入、动作、输出和完成标志。以下五步构成一条端到端主线，适用于已有可复用章程模板、授权层级基本清晰的组织。若授权层级尚不明确，应先确定谁有权批准启动，再进入评审。
第一步：准备模板填写所需输入
输入包括业务需求说明、初步范围描述、资源与预算口径、关键干系人名单。动作是把这些材料归集到起草人手中，并确认预算口径（人力成本是否计入、费用上限如何表述）与资源口径（内部调配还是外部采购）在组织内一致。输出是一份输入清单。完成标志是起草人确认材料齐备、口径无歧义，可以开始填写。
第二步：按评审视角组织章程内容
填写时不要按“写作文”的顺序推进，而应按评审人关心的顺序组织：先写目标与成功标准，再写范围与不做什么，然后写里程碑、资源、预算、风险，最后写验收标准与授权签署区。动作是把每项内容写成可判断的表述，例如成功标准写成可观测的结果而非“提升效率”这类泛化描述。输出是章程初稿。完成标志是初稿中每个评审字段都有实质内容，没有留空或写“待定”的关键项。
第三步：组织评审会并记录意见
输入是章程初稿和评审角色名单。动作是提前把初稿发给评审人，会上按字段逐项过，业务方看目标与范围，技术方看里程碑与可行性，财务看预算口径，法务按需看合规约束。每条意见记录意见编号、提出人、提出日期、对应章程条款、意见类型（必改、建议、待定）和处理结论。输出是评审意见记录表。完成标志是所有必改意见都有明确处理方向，待定项有责任人和期限。
第四步：修改闭环与版本冻结
动作是起草人按意见逐条修改章程，必改项必须改，建议项说明采纳或不采纳的理由，待定项在期限内补充结论。修改完成后形成新版本，并在版本说明中标注对应了哪些意见编号。输出是修改后的章程版本和闭环说明。完成标志是每条必改意见都能在修改版本中找到对应改动，评审记录中的意见状态全部更新为已闭环或有明确结论。
第五步：授权签署与归档
输入是冻结版本的章程和评审结论。动作是授权人核对评审结论与章程版本一致后，在签署区填写签署人、角色、日期、所签版本号和授权结论（批准启动、有条件启动或不启动）。有条件启动时，附加条件写入签署记录并指定复核节点。输出是签署完成的章程版本。完成标志是签署版本与评审记录一并归档，且能从签署版本反查到对应评审记录。
章程模板中支撑评审与授权的关键字段
模板字段的价值在于让评审有判断依据、让签署有明确对象。下表把关键字段与它在评审、签署两个环节的用途对应起来，填写时可据此检查字段是否真正发挥作用。
| 字段 | 评审用途 | 签署用途 |
|---|---|---|
| 目标与成功标准 | 判断项目是否值得启动、成功是否可衡量 | 作为授权范围的上位依据，签署即认可该目标 |
| 范围与不做什么 | 识别边界争议、防止范围蔓延 | 明确授权覆盖的边界，超出范围需另行审批 |
| 里程碑 | 评估节奏是否可行、关键节点是否可检查 | 作为启动后跟踪的基准 |
| 资源 | 核对人力、设备等投入是否落实 | 确认授权调用的资源规模 |
| 预算 | 核对口径与金额、判断投入产出 | 确认授权使用的预算上限 |
| 风险 | 识别重大风险及应对是否充分 | 有条件启动时，风险应对可作为附加条件 |
| 验收标准 | 判断交付是否可验收 | 作为启动后验收的依据 |
| 授权签署区 | 确认签署人是否有对应授权层级 | 记录签署人、角色、日期、版本号、授权结论 |
其中“不做什么”这一栏常被忽略，但它是评审时最有效的边界工具：把明确排除的内容写出来，评审人才能判断范围是否合理，签署人才能界定授权边界。签署区则应至少包含签署人姓名与角色、签署日期、所签版本号、授权结论及附加条件，缺一项都会削弱后续追溯能力。
角色分工与各环节交付物
评审与签署能否顺利推进，取决于每个环节是否有人对交付物负责。下表按角色列出其在各环节的职责与产出，实际组织中一人可兼多个角色，但职责要写清。
| 角色 | 主要环节 | 交付物 |
|---|---|---|
| 章程起草人 | 输入准备、填写初稿、修改闭环 | 输入清单、章程初稿、修改后版本及闭环说明 |
| 业务评审人 | 评审会 | 目标、范围、验收标准方面的评审意见 |
| 技术评审人 | 评审会 | 里程碑可行性、技术风险方面的评审意见 |
| 财务评审人 | 评审会 | 预算口径与金额的评审意见 |
| 法务评审人（按需） | 评审会 | 合规约束方面的评审意见 |
| 授权签署人 | 签署环节 | 签署结论、附加条件及复核节点 |
| 归档与版本管理责任人 | 归档环节 | 签署版本、评审记录及版本对应关系 |
授权签署人的签署依据应是评审通过的章程版本，而非口头结论；签署前需核对版本号与评审记录一致。归档责任人则要保证签署版本与评审记录成对保存，并维护版本对应关系，使后续任何人能从签署版本找到评审依据。评审参与角色按项目实际需要设置，不必每个项目都配齐全部角色。
示例：一次立项评审与签署的完整走查
以下为演示情景，用于说明模板如何贯穿全过程，不对应真实项目。
某团队计划上线一套内部数据看板，章程初稿写明目标为“三个月内上线，覆盖三个业务部门的日报需求”，范围包括数据接入与看板配置，里程碑设为需求确认、数据接入、试运行、正式上线四个节点，预算按人力投入估算，风险列出数据源不稳定一项。初稿的“不做什么”一栏为空。
评审会上，业务评审人提出必改意见：成功标准应写明“三个部门日报可在看板中自动生成”，而非仅写“覆盖需求”；技术评审人提出数据源稳定性风险需要补充应对方案和责任人；财务评审人指出预算未说明是否含外部数据服务费用。三条意见均记录编号、提出人和对应条款。
起草人修改后形成第二版：补充成功标准的可观测表述，为数据源风险增加备选方案与责任人，预算中单列外部服务费用并注明口径，同时在“不做什么”中写明本期不含移动端。评审记录中三条意见状态更新为已闭环。授权人核对第二版与评审结论一致后签署，授权结论为“有条件启动”，附加条件为试运行阶段需提交数据源稳定性报告，复核节点设在试运行结束。签署版本与评审记录一并归档。
审批痕迹如何保留与核验
审批痕迹的核心是一条可反查的证据链：从签署版本能找到评审记录，从评审意见能找到修改版本，每条必改意见都有闭环结论。要做到这一点，评审意见记录至少包含意见编号、提出人、提出日期、对应章程条款、意见类型、处理结论、修改后版本号和闭环确认人。
版本与签署的对应关系要写进签署区：签署人签的是哪个版本号，就应能在版本记录中找到该版本，并确认它晚于评审记录、包含全部必改项的修改。归档位置应统一，检索方式可按项目名称加版本号定位，确保签署版本与评审记录成对存放。
授权后的变更同样需要追加痕迹：范围、预算或里程碑发生调整时，应形成新版本并记录变更原因、批准人和与原签署结论的关系；若变更超出原授权范围，需重新走签署。工具层面，ONES Wiki 支持记录页面版本并随时查看与回滚，成员可在线添加注释和评论进行反馈，页面组可关联项目，这些能力可用于承载评审意见、版本留存与文档归档；签署与审批流是否支持，需以实际产品能力为准。
完成检查：立项评审与授权是否到位
以下清单用于在评审与签署结束后逐项核对，全部满足才可认为本次立项评审与启动授权到位。
- 章程字段完整性：目标、成功标准、范围与不做什么、里程碑、资源、预算、风险、验收标准、签署区均有实质内容，无关键项留空。
- 字段一致性：成功标准与验收标准相互对应，预算口径与资源口径一致，里程碑与范围匹配。
- 评审意见闭环：每条必改意见都有对应修改和闭环确认，待定项有结论或明确期限，建议项有采纳或不采纳说明。
- 签署人与授权范围匹配：签署人具备对应授权层级，签署结论覆盖的预算与资源在原授权范围内。
- 版本对应：签署版本号可在版本记录中查到，且晚于评审记录、包含全部必改项修改。
- 归档证据齐全：签署版本与评审记录成对归档，可从签署版本反查评审记录，从评审意见反查修改版本。
- 有条件启动的附加条件已写入签署记录，并指定了复核节点和责任人。
核对中发现缺项时，应回到对应环节补齐再归档，避免签署版本与评审记录脱节。多个项目之间的准入比较与优先级排序属于项目提案与准入管理范畴，不在本文范围内。
常见问题
评审会上出现无法当场结论的争议项，应该怎么处理？
把争议项标记为“待定”，在评审记录中写明争议焦点、各方观点、责任人和补充结论的期限。章程中对应条款暂不冻结，待责任人补充材料后再确认。待定项未闭环前，不建议进入签署环节；若业务时间压力大，可由授权人决定是否以“有条件启动”方式处理，并把待定项作为附加条件写入签署记录，指定复核节点。
授权人签署后，项目范围发生调整，原签署还有效吗？
取决于调整是否超出原授权范围。范围、预算或里程碑在签署授权边界内的小幅调整，可形成新版本并记录变更原因和批准人，与原签署版本建立对应关系；超出原授权范围的调整，需要重新走评审和签署。无论哪种情况，都应在版本说明中标注与原签署结论的关系，避免签署版本与执行版本脱节。
章程模板中的“不做什么”一栏，评审时应该怎么用？
这一栏的作用是让评审人判断范围是否合理、让签署人界定授权边界。填写时把明确排除的内容写出来，例如本期不含哪些渠道、哪些功能、哪些业务线。评审时逐条确认排除项是否被各方接受，有争议的排除项应记录意见并修改。签署后，超出该边界的需求需另行审批，不能直接纳入本期执行。
用文档工具承载评审记录和签署版本时，需要关注哪些能力？
重点看三件事：版本是否可追溯、权限是否可区分、记录是否可关联。以 ONES Wiki 为例，它支持记录页面版本并随时查看与回滚，支持为不同角色配置读写权限，成员可在线添加注释和评论进行反馈，页面组可关联项目。这些能力可用于承载评审意见、版本留存和文档归档。签署与审批流是否支持，需以实际产品能力为准，选型时应另行确认。
小团队没有专职财务和法务，评审角色可以简化吗？
可以按项目实际需要设置评审角色，不必每个项目都配齐全部角色。预算规模小、不涉及外部采购的项目，财务评审可由授权人一并核对预算口径；不涉及合规敏感内容的项目，法务评审可按需省略。简化的是参与角色，保留的是评审记录：谁评了什么、意见如何处理，仍需逐条记录并闭环，否则签署依据不完整。
