项目立项书与项目章程的衔接，关键在把“要不要做”的论证结论，转成“批了之后按什么规则做”的执行基线。立项书承担决策输入，章程承担授权与执行约束；章程应逐项承接立项书已批准的结论，并明确哪些数字在立项阶段只是估算、进入章程后需要正式确认。本文围绕单项目立项材料内部的分工与承接展开，给出字段对照、操作步骤和检查清单。
要点总览（TL;DR）
- 立项书回答“要不要做、值不值得批”，章程回答“批了之后按什么规则做”；前者是决策输入，后者是授权与执行基线。
- 字段分工的原则是论证性内容留在立项书、约束性内容进入章程：方案比选、投入产出估算详写于立项书，范围基线、验收标准、里程碑、治理角色与变更规则进入章程。
- 衔接的核心动作是把立项书已批准的结论逐项提取，将估算值转为标注“已确认/待确认”的基线项，并补充治理与变更流程，最终形成可追溯的立项—章程对应表。
- 项目经理是交接责任人，交接时点在立项评审通过后、章程编写启动前；编写、评审、批准三类角色应分开。
- 判断衔接是否完成，看章程的每条范围、目标、里程碑能否追溯到立项书结论，估算与承诺是否区分标注，批准记录与版本是否可查。
两份文件各回答什么问题
立项书回答“要不要做、值不值得批”。它面向决策者，核心任务是论证：问题是否真实存在，备选方案各有什么代价，投入与预期回报是否匹配，主要风险是否可接受。立项书的结论通常是“批准立项”“有条件批准”或“不批准”，它是一份决策输入文件。
项目章程回答“批了之后按什么规则做”。它面向执行团队和治理层，核心任务是授权与定基线：项目目标是什么、范围边界在哪里、验收标准如何判定、里程碑如何设置、谁对什么负责、变更走什么流程。章程一旦确认，就成为后续计划、执行和考核的参照基准。
两者在时间顺序上前后衔接，在决策节点上分工明确。立项书对应立项评审节点，章程对应项目启动节点。立项评审通过后，项目经理才有依据编写章程；章程经关键干系人确认后，项目才进入正式执行。这个顺序意味着章程不能脱离立项书凭空编写，立项书也不能替代章程承担执行授权。
常见误区是把章程写成立项书的复制件：背景、方案、投入估算原样搬过去，只改一个标题。这样做的后果是执行阶段缺少可判定的范围边界和验收标准，变更时找不到基线，治理角色也没有正式授权。判断两份文件是否重复，可以看章程中是否出现了立项书没有的新信息——范围基线、验收判定方式、变更规则、角色授权，这些是章程应当补充的内容。
按字段拆分：哪些内容写进立项书，哪些进入章程
字段分工的原则是：论证性内容留在立项书，约束性内容进入章程。同一主题在两份文件中可以都出现，但详略和用途不同。下表给出常见字段的归属与写法差异。
| 字段 | 立项书 | 项目章程 | 衔接要点 |
|---|---|---|---|
| 背景与问题 | 详写：问题现状、影响范围、不做的后果 | 简述：一段话交代项目由来 | 章程引用立项书结论，不重复论证 |
| 方案比选 | 详写：至少两个备选方案及取舍理由 | 不展开，只写选定方案 | 章程注明“方案依据立项书第X节” |
| 投入产出估算 | 详写：人力、费用、周期估算及假设 | 转为预算基线，标注“估算/承诺” | 估算值进入章程前需财务或业务方确认 |
| 项目目标 | 写预期收益和成功条件 | 写可判定的目标与验收标准 | 目标从“预期”转为“可验收” |
| 范围 | 写方案覆盖的大致边界 | 写范围基线：包含项、排除项 | 章程明确列出不做什么 |
| 里程碑 | 可给粗略阶段划分 | 写正式里程碑及交付物 | 里程碑日期在章程中确认 |
| 治理与角色 | 写发起人和主要评审方 | 写治理结构、角色职责、决策权限 | 章程完成正式授权 |
| 变更规则 | 一般不写 | 写变更申请、评审、批准流程 | 章程新增内容，立项书不承担 |
| 假设与约束 | 写论证所依赖的假设 | 写执行必须遵守的约束条件 | 逐条传递，标注哪些已变化 |
估算值与承诺值的区分是衔接中最容易出问题的地方。立项书中的投入数字通常带有假设条件，例如“按现有团队规模、不新增外部采购测算”。进入章程时，这些数字要么被确认成为预算基线，要么被调整并说明原因。建议在章程中为每个关键数字标注来源：来自立项书估算、经评审确认、或启动阶段重新测算。标注方式可以简单到在数字后加括号说明，但必须让执行团队知道哪些数字可以依赖、哪些还需要验证。
从立项书到章程的承接步骤
承接不是重写一遍，而是有选择地提取、确认和补充。以下步骤按顺序执行，每步说明输入、动作、输出和完成标志。
第一步：提取立项书已批准的结论。输入是经批准的立项书及评审记录。动作是列出立项书中所有已获批准的结论，包括选定方案、批准的目标、附带条件。输出是一份“立项结论清单”。完成标志是清单中的每条结论都能对应到立项书的具体章节和评审意见。
第二步：将估算项转为需确认的基线项。输入是立项书中的投入、周期和资源估算。动作是逐项判断：哪些可以直接作为基线，哪些需要财务、业务或技术方重新确认。输出是一份“估算转基线对照表”，标明每项的确认状态和确认人。完成标志是所有关键数字都有明确的确认状态，没有悬空的估算值。
第三步：补充治理结构、角色职责与变更流程。输入是组织的治理惯例和立项书中的发起人、评审方信息。动作是确定项目治理层、项目经理的授权范围、变更申请的审批路径。输出是章程中的治理与变更章节。完成标志是每个角色都有明确的职责描述，变更流程可以按步骤走通。
第四步：组织章程评审并取得关键干系人确认。输入是章程草稿和立项结论清单。动作是组织发起人、业务方、财务或相关评审方进行评审，记录意见并修订。输出是经确认的章程版本和评审记录。完成标志是关键干系人签字或书面确认，评审意见已闭环。
第五步：记录立项结论与章程基线的对应关系。输入是立项结论清单和最终章程。动作是建立一份对应表，逐条标明立项书结论在章程中的落点，以及哪些内容在章程阶段做了调整。输出是“立项—章程对应表”。完成标志是任意一条章程基线都能追溯到立项书结论或说明新增理由。
这五步完成后，两份文件之间形成可查证的链条。后续执行中若出现范围或目标争议，可以回到对应表确认原始批准依据。文档的版本记录和评审意见需要可追溯，ONES Wiki 支持记录页面版本并随时查看与回滚，页面组可关联项目，便于把立项书、章程和评审记录放在同一项目空间内管理；其页面模板库也可用于统一两份文件的编写格式。具体模板字段需结合组织制度自行设计。
角色分工与各阶段交付物
衔接责任需要落到具体角色，避免“大家都觉得对方会接”。下表给出常见分工，组织可根据自身治理结构裁剪。
| 角色 | 立项阶段职责 | 章程阶段职责 | 交接责任 |
|---|---|---|---|
| 发起人 | 提出立项需求，确认业务价值 | 批准章程，授权项目经理 | 在立项评审通过后书面确认进入章程编写 |
| 项目经理 | 参与立项书编写或审阅，了解论证假设 | 编写章程，组织评审 | 承接立项结论清单，负责对应表编制 |
| 财务或业务评审方 | 评审投入产出估算，给出意见 | 确认预算基线，参与章程评审 | 在估算转基线对照表上确认关键数字 |
| 治理层 | 做出立项批准决定 | 确认治理结构、变更审批权限 | 批准章程，明确授权边界 |
编写人、评审人和批准人需要分开。立项书通常由业务发起方或项目经理起草，评审方包括财务、技术和业务代表，批准人是发起人或治理层。章程通常由项目经理编写，评审方包括发起人和关键干系人，批准人是发起人或治理层。交接责任人是项目经理，交接时点是立项评审通过后、章程编写启动前。交接的实质动作是项目经理拿到立项结论清单和评审意见，并确认哪些估算需要重新确认。
示例：一个系统上线项目的衔接写法
以下为演示性情景，用于说明写法，不对应真实项目。
某业务部门提出上线一套合同管理系统。立项书中写明：当前合同审批平均耗时较长，人工台账存在遗漏风险；备选方案包括采购成熟产品、自研和维持现状，经比选建议采购成熟产品并做少量配置；投入估算为一次性采购与实施费用若干、内部人力若干人月，假设业务方能在实施期投入足够的测试人员；预期收益是审批周期缩短和台账准确率提升。立项评审结论为“批准，但需在章程中明确验收指标和数据迁移责任”。
进入章程阶段，项目经理逐项承接。范围基线写为：包含合同模板配置、审批流配置、历史数据迁移和用户培训；排除与财务系统的深度集成，该部分另行立项。目标与验收标准写为：审批平均耗时不超过约定天数、历史合同迁移完整率达到约定比例、关键用户通过操作考核。里程碑写为：需求确认、配置完成、迁移验证、试运行、正式上线五个节点及对应交付物。立项书中的投入估算，采购费用经财务确认成为预算基线，内部人力估算因测试人员投入时间未定，标注为“待启动会确认”。立项评审提出的数据迁移责任，在章程中明确由业务方指定数据负责人、项目经理协调资源。假设条件“业务方投入足够测试人员”原样传递，并增加约束“上线窗口需避开业务高峰期”。
这个示例的要点是：章程没有重复论证为什么采购，而是把已批准的选择转成范围、验收和里程碑；估算数字被逐项确认或标注待确认；评审意见在章程中有明确落点。
衔接完成检查
用以下清单逐项核对，判断两份文件是否真正衔接。每项都应有明确答案，而不是“大致有”。
- 章程中的范围包含项和排除项，能否逐条追溯到立项书的选定方案或评审意见？
- 章程中的每个目标是否有可判定的验收标准，且与立项书的预期收益对应？
- 章程中的里程碑是否覆盖立项书提到的关键阶段，日期是否经过确认？
- 立项书中的投入估算，在章程中是否逐项标注了“已确认基线”或“待确认”，并写明确认人？
- 立项书中的假设与约束，是否在章程中逐条传递，变化项是否说明原因？
- 章程是否包含变更申请、评审和批准的完整路径，治理角色是否有明确授权？
- 是否存在“立项—章程对应表”，任意一条章程基线都能找到来源？
- 立项书和章程的批准记录、版本号、评审意见是否可查，交接时点是否有记录？
清单中若有任何一项无法回答，说明衔接存在缺口，应回到对应步骤补齐后再进入执行。两份文件的衔接质量，最终体现在执行阶段遇到范围或目标争议时，团队能否快速找到批准依据并判断变更该走什么流程。
常见问题
立项评审给了“有条件批准”，章程里怎么处理这些附加条件？
把附加条件当作立项结论的一部分，逐条列入“立项结论清单”，并在章程中为每条条件指定落点。常见做法是：与范围相关的条件写进范围基线或排除项，与验收相关的条件写进目标与验收标准，与责任相关的条件写进治理与角色章节。章程评审时逐条核对条件是否已有对应条款，未落地的条件不能默认关闭。
立项书里的预算估算和章程里的预算基线不一致，以哪个为准？
以章程中经确认的基线为准，同时保留差异说明。立项书的数字通常附带假设条件，属于决策阶段的估算；进入章程时由财务或业务评审方确认后转为基线。若确认过程中调整了数字，应在章程中注明调整原因和确认人，并在立项—章程对应表中记录差异，便于后续追溯批准依据。
项目已经启动，章程还没正式批准，这种情况怎么处理？
可以先明确当前执行所依据的临时授权范围和有效期，由发起人书面确认，避免执行团队在范围和变更上无据可依。章程批准前，范围扩大、预算追加和里程碑调整应走临时审批路径，并约定章程正式批准的时限。章程批准后，把临时授权期间做出的决定补记进对应表，保持链条完整。
小项目是否可以把立项书和章程合并成一份文件？
可以合并，但要保留两类内容的区分。建议在同一份文件中分设“立项论证”和“执行基线”两个部分，前者保留方案比选与投入估算，后者写明范围基线、验收标准、里程碑、治理角色和变更规则，并标注哪些数字是估算、哪些已确认。合并后仍需在立项评审和启动确认两个节点分别取得批准，避免论证与授权混在一次审批中。
用文档工具管理立项书和章程，需要关注哪些能力？
重点看三件事：版本是否可追溯、权限是否按角色区分、文档能否与项目关联。以 ONES Wiki 为例，其文档实时同步并记录所有页面版本，支持随时查看与回滚；可为不同角色配置不同的读写权限；页面组可关联项目，便于把立项书、章程和评审记录放在同一项目空间内管理，页面模板库也可用于统一两份文件的编写格式。具体模板字段和评审流转方式需结合组织制度确认。
