项目章程的审批痕迹由三部分构成：评审记录、授权签署、版本留档。模板要把这三类信息固定在明确位置，用版本号把正文与记录绑定；签署只对已冻结的版本进行，签署后原文件不再改动，变更走新版本并重新签署。本文聚焦单项目立项场景，说明模板字段、操作步骤、角色分工与完整性检查；章程文档与评审、签署状态也可以在ONES中承载。
要点总览（TL;DR）
- 审批痕迹由评审记录、授权签署、版本留档三部分构成，模板要为它们预留固定位置，并用版本号把正文与记录绑定。
- 签署只对已冻结的待签署版进行，审批人签署前核对版本号；签署后原文件不再改动，变更生成新版本并重新评审与签署。
- 评审意见逐条记录处置结论（采纳、部分采纳、不采纳及理由）并由提出人确认，避免只留汇总结论。
- 归档时同时保存章程正文与全部过程记录，已失效版本保留可检索，历史签署链条完整。
- ONES Wiki 可用页面模板库固化章程模板，页面版本记录便于核对签署版本与正文是否一致，审批流与电子签署的具体配置需结合团队实际产品能力确定。
审批痕迹要留在章程的哪些位置
审批痕迹的完整性取决于模板是否预留了承载位置。建议把章程文件拆成“正文”和“记录”两个存放区：正文只放章程内容本身，记录区放评审意见、签署结论和版本变更信息。两者用同一个版本号关联，任何一次签署都能对应到唯一的正文版本。
评审记录区
评审记录区按轮次组织，每轮记录参与人、意见和处置结论。字段设计要让“谁提了什么、怎么处理、谁确认”三件事都能查到。
| 字段名 | 填写人 | 填写时点 |
|---|---|---|
| 评审轮次（如R1、R2） | 章程起草人 | 每轮评审发起时 |
| 评审日期与参与人 | 章程起草人 | 评审会结束当天 |
| 意见编号与意见内容 | 评审参与人提交，起草人汇总 | 评审过程中 |
| 处置结论（采纳/部分采纳/不采纳及理由） | 章程起草人 | 意见汇总后、下一版冻结前 |
| 意见提出人确认 | 评审参与人 | 处置记录完成后 |
授权签署区
签署区记录的是“谁对哪一版章程作出了什么结论”。字段要能独立回答审批角色、签署人、签署时间、签署版本号和结论五个问题，结论建议限定为批准、有条件批准、退回三种，避免模糊表述。
| 字段名 | 填写人 | 填写时点 |
|---|---|---|
| 审批角色（如项目发起人、业务负责人、财务代表） | 章程起草人预先列出 | 模板初始化时 |
| 签署人姓名 | 审批人本人 | 签署时 |
| 签署时间 | 审批人本人 | 签署时 |
| 签署版本号 | 审批人本人核对后填写 | 签署时 |
| 结论（批准/有条件批准/退回）及附加条件 | 审批人本人 | 签署时 |
版本与变更区
版本区记录每次修改的版本号、变更原因和生效状态。生效状态建议用“草稿、评审中、待签署、已生效、已失效”几个状态标识，让读者一眼看出当前哪一版是有效版本。签署后的修改必须生成新版本号，并在变更原因中写明触发修改的原因，例如范围调整或预算变化。
正文与记录分离存放的原则
正文与记录分开存放，目的是让签署对象保持稳定。正文一旦冻结进入签署，就不再插入批注或修改内容；评审意见、签署页、变更说明都放在记录区，通过版本号指向对应正文。这样即使记录区持续追加，已签署版本的正文内容也不会被覆盖。
从评审到授权签署的操作步骤
把评审与签署组织成一条有先后顺序的流程，每一步都有明确输入、动作、输出和完成标志，可以避免“会开完了但痕迹没留下”的情况。以下步骤适用于单项目立项，评审轮次可按项目复杂度增减。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、冻结评审版章程并编号 | 起草完成的章程初稿 | 停止内容修改，赋予版本号（如V0.9），在记录区登记冻结时间 | 带版本号的评审版章程 | 版本号已登记，正文进入只读状态 |
| 二、发起评审并逐条记录处置 | 评审版章程、评审参与人名单 | 发出评审通知，收集意见并编号，逐条填写处置结论，请提出人确认 | 评审记录表（含意见与处置） | 每条意见都有处置结论和确认记录 |
| 三、形成评审结论，修订并生成待签署版 | 评审记录表、评审结论 | 汇总评审结论，按采纳意见修订正文，生成新版本号（如V1.0），登记变更原因 | 待签署版章程及变更说明 | 新版本号已登记，修订内容与意见处置可对应 |
| 四、授权签署并记录签署信息 | 待签署版章程、审批角色清单 | 审批人核对版本号后签署，填写签署人、时间、版本号与结论 | 签署记录 | 所有审批角色均完成签署，结论明确 |
| 五、归档生效版本与全部过程记录 | 已签署章程、评审记录、签署记录、变更说明 | 将正文与记录一并归档，标记生效状态，通知项目相关方 | 完整立项档案 | 归档内容齐全，生效版本可被检索到 |
步骤三需要特别注意：评审结论形成后，修订动作只针对待签署版，评审版保持原样不动。这样评审记录中的意见指向的版本与修订后的待签署版之间，可以通过变更说明建立对应关系。步骤四中，审批人签署前应核对版本号，确认自己签署的是最新待签署版，避免签在过期版本上。
角色分工与各自交付物
痕迹责任不清通常表现为意见没人确认、签署页找不到对应版本、归档缺过程记录。把角色与交付物、交接时点固定下来，可以让每个环节都有明确的责任人。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 章程起草人 | 维护章程版本，汇总评审意见并记录处置结论 | 各版本章程正文、评审记录表、变更说明 | 评审版冻结时提交评审；待签署版形成后提交审批 |
| 评审参与人 | 提交评审意见，对处置结果确认 | 带编号的评审意见、确认记录 | 评审会结束前提交意见；处置记录完成后确认 |
| 审批/授权人 | 对冻结的待签署版作出签署结论 | 签署记录（签署人、时间、版本号、结论） | 收到待签署版后完成签署并交回起草人 |
| 归档或项目管理办公室角色 | 保管生效版本与全部过程记录，维护归档目录 | 立项档案（正文加记录）、归档登记 | 签署完成后接收全套材料并登记生效 |
起草人与归档角色之间应有明确的交接清单：正文、评审记录、签署记录、变更说明四项齐全才算完成交接。审批人只对冻结版本签署，不参与正文修改，这一分工可以让签署记录与版本号保持一一对应。
示例：一份带审批痕迹的章程记录
以下示例为单项目立项场景，项目名称为“客户门户改版”，用于展示痕迹如何落到具体字段。示例中的意见和结论为演示内容。
评审记录示例
| 轮次 | 意见编号 | 意见内容 | 处置结论 | 提出人确认 |
|---|---|---|---|---|
| R1 | R1-01 | 项目目标缺少可衡量的验收指标 | 采纳，补充上线后三个月内页面加载时间指标 | 已确认 |
| R1 | R1-02 | 建议增加二期范围预留 | 不采纳，本期章程只覆盖一期，二期另立章程 | 已确认 |
| R2 | R2-01 | 预算表中人力成本口径需与财务口径一致 | 部分采纳，按财务口径调整人力成本，保留原估算作为备注 | 已确认 |
签署记录示例
| 审批角色 | 签署人 | 签署时间 | 签署版本号 | 结论 |
|---|---|---|---|---|
| 项目发起人 | 示例：张明 | 2025-03-12 | V1.0 | 批准 |
| 业务负责人 | 示例：李华 | 2025-03-12 | V1.0 | 有条件批准：上线前完成安全评估 |
| 财务代表 | 示例：王芳 | 2025-03-13 | V1.0 | 批准 |
版本变更示例
V1.0签署生效后，项目范围新增一个外部系统对接，起草人将章程修订为V1.1，变更原因登记为“新增外部系统对接范围”，生效状态先标为“待签署”。V1.1重新走评审确认与授权签署，签署记录中版本号填写V1.1，V1.0标记为“已失效”但保留归档。这样签署后的修改没有覆盖原签署记录，新旧版本的审批链条都能查到。
完成检查：审批痕迹是否可追溯
归档前用以下清单逐项核对，可以判断审批痕迹是否完整。检查的对象是记录区与正文的对应关系，而不只是签字页是否存在。
- 每个签署结论都能对应到唯一版本号，签署记录中的版本号与正文版本一致。
- 每条评审意见都有处置结论，采纳、部分采纳、不采纳均写明理由，并有提出人确认记录。
- 签署后发生的修改都生成了新版本号，并重新完成评审确认与授权签署。
- 归档内容同时包含章程正文和全部过程记录：评审记录、签署记录、变更说明。
- 生效状态标记清晰，已失效版本仍可检索，历史签署链条完整。
常见缺口有三类：只保留签字页而缺少评审意见与处置记录；签署记录中的版本号与正文版本不一致，导致无法判断签的是哪一版；评审意见只有汇总结论，没有逐条处置和确认。出现其中任一情况，都应回到记录区补齐后再归档。
在ONES中承载这套做法时，可以用ONES Wiki的页面模板库建立制式化章程模板，把评审记录区、签署区、版本区固定为模板字段；页面版本记录支持查看与回滚，便于核对签署版本与正文是否一致；成员可以在线添加注释和评论，用于评审意见的提交与反馈；页面组可关联项目，让章程文档与项目工作项对应。审批流与电子签署的具体配置方式，需结合团队实际使用的产品能力确定，痕迹是否可追溯最终仍取决于版本号与签署记录能否一一对应。
常见问题
评审会上口头同意、会后没有书面确认，这种情况怎么补痕迹？
回到评审记录区补齐三件事：意见编号与内容、处置结论、提出人确认。补记时注明补记日期和补记人，并在变更说明中说明该轮评审记录为会后补录。若意见涉及正文修改，确认补记后再生成待签署版，避免签署版与评审记录脱节。
审批人签署后提出小范围文字修正，需要重新走完整评审吗？
只要已签署版本的正文发生改动，就应生成新版本号并重新签署，原签署记录保留并标记对应旧版本。修正是否重新组织完整评审，可按改动性质区分：涉及目标、范围、预算、验收标准的改动建议重新评审；纯文字表述修正可在变更说明中记录改动内容与确认人，再走签署。无论哪种情况，签署记录中的版本号都要与新版本一致。
有条件批准的结论在痕迹上要怎么处理才算闭环？
签署记录中写明附加条件，并在记录区为每个条件登记责任人和完成时点。条件完成情况可作为签署记录的后续条目追加，或附在归档材料中。条件未完成前，章程的生效状态可保持待确认，待条件满足后再标记生效，这样批准结论与条件落实能对应起来。
用文档工具承载章程时，怎么保证签署记录和正文版本对得上？
把章程正文与记录区分开存放，正文冻结后进入只读，签署记录单独维护并填写版本号。ONES Wiki 支持页面模板库创建制式化模板，页面版本记录支持查看与回滚，可用于核对签署版本与正文是否一致；成员可在线添加注释和评论，用于评审意见的提交与反馈。审批流与电子签署的具体配置方式，需结合团队实际使用的产品能力确定。
归档时哪些材料算“全部过程记录”，缺了会有什么影响？
至少包括章程正文、各轮评审记录（含意见与处置）、签署记录、变更说明四类。缺少评审记录会导致签署结论无法追溯到评审依据；缺少变更说明会让新旧版本之间无法建立对应关系；只留签字页则无法判断签的是哪一版。归档前按完整性清单逐项核对，缺项补齐后再登记生效。
