项目立项书和项目章程常被当成同一份材料的两个名字，实际分处两个环节：立项书回答“这个项目值不值得批”，供决策层做准入判断；项目章程回答“批了之后按什么授权干”，交给项目经理和执行团队。本文按同一组内容维度对照两份文档的分工，说明从立项评审到章程签发的衔接动作，并给出小项目、强治理组织、多阶段项目下的取舍建议。
要点总览（TL;DR）
- 立项书服务准入决策，回答“这个项目值不值得批”；项目章程服务执行授权，回答“批了之后按什么授权干”，两者分处立项与启动两个环节。
- 内容分工遵循一条原则：商业论证、目标与成功标准、范围边界、投入估算和主要风险写在立项书；项目经理授权、高层级需求与交付物、里程碑、关键干系人、约束与假设写在章程。
- 衔接顺序是立项评审通过后，以立项结论作为章程输入，章程引用目标、范围与投入，补充授权与治理信息后由发起人签发。
- 小项目可合并为一份文档但保留“立项论证”和“执行授权”两段结构；强治理组织分开编制、分别审批；多阶段项目在阶段关口更新章程中的授权与里程碑。
- 常见错误集中在章程重复论证、立项书缺成功标准、授权范围不清和版本不同步，编制后按六项要点逐项核对即可。
立项书与项目章程的核心区别
立项书和项目章程的核心区别在于它们服务的决策不同。立项书服务于“准入决策”：在资源投入之前，用商业理由、目标与成功标准、范围边界、投入估算和主要风险，回答这个项目是否值得做、值得到什么程度。项目章程服务于“执行授权”：项目获批后，明确项目经理被授予什么权限、要交付什么、关键里程碑和干系人是谁，让执行团队知道按什么规则启动工作。
两份文档的使用对象也不同。立项书的主要读者是决策层和评审角色，他们关心投入产出与风险是否可接受；章程的主要读者是项目经理、执行团队和相关职能部门，他们关心职责边界、交付节奏和协作接口。生效时点同样不同：立项书在评审通过前是待决材料，评审通过后成为决策依据；章程在项目批准启动后由发起人签发，成为执行依据。
实际编制中有两类常见误解。一类是把章程当成立项材料，在章程里重新论证项目价值，导致评审依据和执行依据混在一起，后续变更时难以判断哪份文件为准。另一类是把立项书当成执行依据，项目启动后仍靠立项书里的粗略范围安排工作，缺少授权和治理信息，遇到跨部门协调时说不清谁有权决定。把两份文档的定位分开，是后续内容分工的前提。
| 对照项 | 项目立项书 | 项目章程 |
|---|---|---|
| 回答的问题 | 这个项目是否值得批准 | 批准后按什么授权执行 |
| 主要使用对象 | 决策层、评审角色 | 项目经理、执行团队、相关职能部门 |
| 生效时点 | 评审通过后作为决策依据 | 项目批准启动、发起人签发后作为执行依据 |
| 在项目中的位置 | 准入环节 | 启动环节 |
同口径内容分工对照
把两份文档放在同一组维度下对照，可以看清各自承担什么、写到什么颗粒度。总体原则是：论证性内容写在立项书，授权与治理性内容写在章程，两者共用的信息只在一处详写、另一处引用。
| 内容维度 | 立项书承担的内容 | 章程承担的内容 | 分工要点 |
|---|---|---|---|
| 文档目的 | 支撑一次准入决策 | 完成执行授权与治理约定 | 目的不同，不互相替代 |
| 商业论证 | 业务背景、预期收益、成本与投入估算、不做的后果 | 引用立项结论，不重新论证 | 只写一处，章程引用 |
| 目标与成功标准 | 给出项目目标与可衡量的成功标准 | 引用目标，转化为验收口径与里程碑 | 立项书定义，章程承接 |
| 范围 | 范围边界、主要不包含的内容 | 高层级需求与主要交付物 | 立项书写边界，章程写交付物 |
| 资源与投入 | 投入估算、资源需求依据 | 授权范围内的资源调用约定 | 估算在立项书，调用规则在章程 |
| 风险 | 主要风险及对决策的影响 | 约束与假设条件 | 决策相关风险在立项书，执行约束在章程 |
| 授权信息 | 不展开 | 项目经理任命与授权范围、关键干系人 | 章程独有内容 |
| 审批角色 | 决策层或立项评审角色 | 项目发起人签发，相关方知会 | 审批主体不同 |
| 生效与变更 | 评审通过即生效，重大变更需重新评审 | 签发后生效，授权或里程碑调整时更新 | 变更分别触发，保持对应 |
颗粒度上，立项书的商业论证和投入估算可以写得具体，因为决策层需要据此判断；章程的范围和需求写到高层级即可，详细需求留到后续规划文档。章程独有的内容是项目经理授权、关键干系人和约束假设，这些信息在立项书中通常不展开。反过来，立项书中的收益测算和方案比较也不必搬进章程，章程只需引用结论。
从立项到章程的衔接流程
两份文档在时间上前后衔接，在信息上单向传递为主、双向回写为辅。可按以下动作推进：
- 立项编制：由项目提议人或业务负责人编写立项书，写明商业理由、目标与成功标准、范围边界、投入估算和主要风险，提交评审。
- 立项评审：决策层或评审角色对项目是否准入作出结论，形成评审意见。评审通过是后续动作的前提。
- 章程编制：项目经理或发起人指定的人员以立项结论为输入编写章程，引用立项书中的目标、范围和投入，补充项目经理授权、高层级需求与交付物、里程碑、关键干系人、约束与假设。
- 章程签发：由项目发起人签发章程，向执行团队和相关职能部门知会，项目正式进入执行。
- 变更回写：项目执行中若目标、范围或投入发生重大调整，先评估是否触发立项重新评审，再同步更新章程中的授权与里程碑内容，保持两份文档的对应关系。
这条流程中，交接物是明确的：立项评审意见和立项书是章程的输入，签发的章程是执行的起点。评审记录、章程版本和变更痕迹需要可追溯，否则后续很难说清某次授权调整依据的是哪一版文件。在项目协作工具中承载这套流程时，可以用文档模板统一立项书和章程的结构，用版本记录保留评审与签发过程，用权限区分决策层、项目经理和执行团队的读写范围。ONES Wiki 支持页面模板库一键创建制式化文档，文档实时同步并记录页面版本、支持查看与回滚，并可为不同角色配置读写权限；页面组可关联项目，使文档与项目工作保持对应。这些能力用于承载文档编写、评审留痕和版本管理，立项审批与章程签发的具体规则仍由组织自行确定。
不同组织条件下的取舍与分工建议
两份文档的分工深浅取决于审批层级、干系人数量和外部约束，不必一律分开编制。可按以下条件取舍：
| 组织条件 | 建议做法 | 保留的关键内容 |
|---|---|---|
| 小项目、单一团队、审批层级少 | 合并为一份文档，内部分为“立项论证”和“执行授权”两段 | 两段结构保留，论证与授权信息不混写 |
| 强治理组织、多部门参与、审批要求明确 | 分开编制、分别审批，立项书走准入评审，章程由发起人签发 | 评审记录、签发记录、版本对应关系 |
| 多阶段项目、周期较长 | 立项书在项目整体准入时编制，章程在阶段关口更新授权、里程碑和干系人 | 阶段目标、授权调整依据、变更记录 |
| 存在外部合同或合规约束 | 分开编制，章程中的范围与交付物与合同条款对齐 | 合同约定的交付节点、验收口径 |
合并编制时，容易出现的退化是把两段写成一段叙述，论证和授权混在一起，评审时说不清批的是价值还是权限。保留两段结构、分别标注结论，可以在简化文档数量的同时维持分工。分开编制时，则要注意章程不重复论证，避免同一份商业理由出现两个版本。多阶段项目的章程更新应聚焦授权和里程碑的变化，不必每次重写全部内容。
常见分工错误与核对要点
实际编制中，以下错误最容易造成两份文档职责混乱：
- 章程重复抄写立项书的商业论证，导致项目价值出现两个表述，变更时不知以哪份为准。
- 立项书缺少可衡量的成功标准，章程无法据此设定验收口径和里程碑，执行阶段反复补定义。
- 章程未明确项目经理的授权范围，跨部门协调和资源调用时缺少依据。
- 两份文档版本不一致，立项结论调整后章程未同步，执行依据与决策依据脱节。
- 把章程当成立项材料提交评审，或把立项书直接当作执行依据下发，混淆了两个环节的使用对象。
编制完成后可按以下要点逐项核对：
- 立项书是否写清了商业理由、目标与成功标准、范围边界、投入估算和主要风险。
- 章程是否引用了立项结论，而非重新论证项目价值。
- 章程是否明确了项目经理任命、授权范围和关键干系人。
- 章程中的高层级需求、交付物和里程碑是否与立项书的目标和范围一致。
- 两份文档的版本号和变更记录是否对应，重大变更是否触发立项重新评审。
- 审批与签发记录是否完整，能否追溯到具体版本和责任人。
核对的目的在于让两份文档各司其职：立项书支撑一次准入判断，章程支撑一段执行授权，共用信息只写一处、另一处引用，变更时同步回写。做到这一点，立项材料既不重复也不遗漏。
常见问题
小项目把立项书和章程合并成一份文档，评审时怎么区分批的是价值还是权限？
合并编制时，在文档内部保留两个明确分段：前段写立项论证，包括商业理由、目标与成功标准、范围边界、投入估算和主要风险，结论是“建议批准”；后段写执行授权，包括项目经理任命与授权范围、高层级需求与交付物、里程碑、关键干系人和约束假设，结论是“授权执行”。两段分别标注结论和确认人，评审记录中对应到具体段落。这样文档数量减少，决策与授权的边界仍然清楚。
立项书评审通过后，章程还需要重新论证项目价值吗？
不需要。章程的作用是把立项结论转化为执行授权，商业论证以引用方式承接即可，例如写明“依据某次立项评审通过的结论”。重新论证会让项目价值出现两个表述，后续目标或投入调整时难以判断以哪份为准。章程需要补充的是立项书中通常不展开的内容：项目经理授权范围、关键干系人、约束与假设，以及把目标转化为里程碑和验收口径。
项目执行中目标或范围发生重大调整，两份文档应该怎么同步？
先判断调整是否超出原立项结论的授权边界。超出时，回到立项评审环节重新确认项目是否继续准入，形成新的评审意见；未超出时，由项目经理更新章程中的授权、里程碑和交付物内容。无论哪种情况，章程更新都应引用对应的立项结论版本，两份文档的版本号和变更记录保持对应。若组织使用文档工具承载，可借助页面版本记录保留每次调整的痕迹，便于追溯某次授权变更依据的是哪一版文件。
强治理组织要求分开审批，立项书和章程的审批角色如何划分？
立项书由决策层或立项评审角色审批，关注投入产出、风险是否可接受以及项目是否准入；章程由项目发起人签发，关注授权是否清晰、交付物和里程碑是否可执行，并向执行团队和相关职能部门知会。两个审批环节的记录分别留存，章程签发时引用立项评审结论。这样划分后，评审角色不必重复审阅执行细节，发起人对授权内容负责。
用文档工具承载立项书和章程，需要关注哪些能力？
主要看三点：一是能否用统一模板快速创建两份文档，保持结构一致；二是能否记录页面版本并支持查看与回滚，让评审和签发过程可追溯；三是能否按角色配置读写权限，区分决策层、项目经理和执行团队的访问范围。ONES Wiki 支持页面模板库创建制式化文档，文档实时同步并记录页面版本、支持查看与回滚，并可为不同角色配置读写权限；页面组还可关联项目，使文档与项目工作保持对应。具体的立项审批与章程签发规则仍由组织自行确定。
