项目活动清单是把WBS末端工作包拆成可执行活动的表格，字段是否齐全直接决定后续排期、分工和验收能否顺畅进行。本文提供一份可直接复制到电子表格或文档中的空白模板，逐字段说明填写口径，区分必填与选填，并给出活动定义的写法规则和一条完整填写示例，帮助你把“跟进一下”“处理问题”这类模糊表述改成可执行、可验收的活动记录。
要点总览（TL;DR）
- 活动清单模板至少保留活动编号、活动名称、活动定义、负责人、计划工期、完成标准六项，这六项支撑分工、排期和验收。
- 活动定义用“动词+对象+结果”写清动作、输入、输出和完成判据，一句话脱离上下文也能读懂、能被第三方核验。
- 前置与紧后活动成对检查，只记录真实存在的先后约束；习惯性顺序不必全部写成依赖。
- 活动数量超过二三十条或需要多人并行推进时，再补前置活动、紧后活动和状态字段。
- 模板复用到新项目时逐列检查编号规则、文档名称、依赖引用、负责人和完成标准，避免残留旧项目信息。
可复制空白活动清单模板
下面这张表可以直接复制到Excel、在线表格或文档中。表头保持一行，每行填写一条活动；活动定义栏单独留出较宽的列，便于写完整句子。如果使用文档形式，可把表格转为“字段名：内容”的条目式结构，字段顺序保持一致。
| 活动编号 | 活动名称 | 活动定义 | 所属工作包 | 前置活动 | 紧后活动 | 负责人 | 计划工期 | 所需资源 | 交付物 | 完成标准 | 假设与约束 | 状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
活动定义栏的空白填写框可按下面的结构落笔，写完后整句读一遍，确认脱离上下文也能看懂：
| 填写项 | 空白填写框 |
|---|---|
| 动作（动词） | |
| 对象（输入/处理对象） | |
| 结果（输出物） | |
| 完成判据 | |
| 合并成一句话 |
复制时注意两点：活动编号在项目内保持唯一，便于前置、紧后活动用编号引用；活动定义列不要合并单元格，一条活动一句话，避免多条活动挤在一格里。
每个字段填什么：字段说明
字段说明与上面的模板一一对应。填写时先保证活动定义写清楚，再补依赖、资源和完成标准，顺序上更省力。
| 字段 | 含义与填写口径 |
|---|---|
| 活动编号 | 项目内唯一的标识，如A-01、WP2-03。用于前置、紧后活动引用，也便于在工具中检索。 |
| 活动名称 | 简短标签，通常6–15字，如“接口联调”“用户验收测试准备”。名称用于快速识别，不承担完整说明职责。 |
| 活动定义 | 用一句话写清动作、对象、输出和完成判据，是活动清单中信息量最大的字段，写法见后文。 |
| 所属工作包 | 填写该活动在WBS中归属的工作包编号或名称，保证活动与分解结构对得上，不出现无归属活动。 |
| 前置活动 | 填写必须先完成的活动编号，多个用逗号分隔。没有前置的填“无”，不要留空，留空与“无”含义不同。 |
| 紧后活动 | 填写依赖本活动完成才能开始的活动编号。紧后活动可由前置关系反推，但显式填写便于检查依赖是否闭环。 |
| 负责人 | 填写对活动结果负责的一个人，写姓名或岗位，不写“团队”“相关同事”。多人协作时指定唯一责任人。 |
| 计划工期 | 填写完成该活动所需的工作时间，注明单位，如“3个工作日”。工期指净工作时间，与日历跨度区分开。 |
| 所需资源 | 填写人力角色、设备、环境、外部配合等必要投入，如“测试环境1套、后端工程师1人”。 |
| 交付物 | 填写活动完成后产出的具体物件，如“接口文档v1.0”“测试报告”。交付物应可被他人查看或接收。 |
| 完成标准 | 填写判定活动完成的客观条件，如“接口文档经评审通过并归档”。标准要能被第三方核验。 |
| 假设与约束 | 记录活动成立的前提和限制，如“依赖第三方接口按期开放”“仅在工作日执行”。前提变化时据此评估影响。 |
| 状态 | 填写活动当前进展，常用未开始、进行中、已完成、已阻塞。状态用于汇总进度，不替代完成标准。 |
前置与紧后字段的填写要成对检查：A的前置是B，则B的紧后应包含A。依赖关系只记录真实存在的先后约束，习惯性顺序不必全部写成依赖，否则后续调整排期时牵一发动全身。
必填与选填：最小可用字段集
字段齐全适合中大型项目或需要跨部门交接的场景；活动数量少、周期短的小项目可以裁剪，但裁剪要有依据，不能把验收相关的字段一并删掉。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 活动编号 | 必填 | 依赖引用和检索的基础，缺了无法建立前后置关系。 |
| 活动名称 | 必填 | 清单浏览和沟通时的主要识别信息。 |
| 活动定义 | 必填 | 决定活动是否可执行、可验收，是模板的核心字段。 |
| 负责人 | 必填 | 没有责任人的活动在推进中最容易悬空。 |
| 计划工期 | 必填 | 排期和资源安排的基本输入。 |
| 完成标准 | 必填 | 验收依据，缺少时完成与否只能靠口头判断。 |
| 所属工作包 | 选填 | 活动数量多、需要与WBS对照时填写；单层清单可省略。 |
| 前置活动 | 选填 | 存在真实先后约束时填写；独立活动可不填。 |
| 紧后活动 | 选填 | 依赖链较长、需要检查闭环时填写，可由前置关系反推。 |
| 所需资源 | 选填 | 涉及共享资源、设备或外部配合时填写，便于资源冲突检查。 |
| 交付物 | 选填 | 有明确产出物时填写；与完成标准配合使用效果更好。 |
| 假设与约束 | 选填 | 存在外部前提或硬性限制时填写，用于风险跟踪。 |
| 状态 | 选填 | 清单需要持续跟踪进展时填写；一次性规划文档可省略。 |
小项目的最小字段集可以只保留六项：活动编号、活动名称、活动定义、负责人、计划工期、完成标准。这六项能支撑分工、排期和验收三件事。活动数量超过二三十条、或需要多人并行推进时，再补上前置活动、紧后活动和状态，依赖和进度才看得清。
活动定义怎么写：要素与句式
活动定义要回答四个问题：做什么动作、处理什么对象、产出什么结果、怎样算完成。四个要素齐全，一条记录脱离上下文也能被独立理解，交接给他人时不需要额外解释。
- 动作：用明确的动词开头，如编制、评审、测试、部署、归档，避免“跟进”“处理”“推进”这类无法界定范围的动作。
- 输入：说明动作作用的对象或依据，如“依据需求规格说明书”“针对支付模块接口”。
- 输出：写清活动结束时的产出物，如“形成测试用例集”“输出评审纪要”。
- 完成判据：给出可核验的条件，如“用例覆盖全部一级功能点并经评审通过”。
推荐句式是“动词+对象+结果”，再补完成判据。例如“编制支付模块测试用例，覆盖全部一级功能点，经测试负责人评审通过后归档”。一句话包含动作、对象、输出和判据，读一遍即可判断是否完成。
| 常见错误写法 | 问题 | 改写方向 |
|---|---|---|
| 跟进接口进度 | 动作无边界，完成与否无法判断 | 每周收集接口联调记录，形成进度周报并同步给项目组 |
| 处理测试问题 | 对象和结果都不明确 | 修复测试提交的P1级缺陷，回归通过后关闭缺陷单 |
| 准备上线 | 范围过大，实际包含多个活动 | 拆为“编制上线检查清单”“执行上线演练”“完成上线审批”三条活动 |
| 参与需求评审 | 只写参与，没有产出 | 参加需求评审会，输出评审意见并确认需求基线 |
改写时把握一个尺度：一条活动对应一个可交付的结果。如果一句话里出现两个以上产出物，通常应拆成两条活动；如果一句话读完仍不知道谁验收、看什么验收，说明完成判据还没写进去。
填写示例：一条完整活动记录
下面用一条已填写的记录示范各字段如何配合。示例为演示情景，项目背景为某系统的支付模块改造。
| 字段 | 填写内容 |
|---|---|
| 活动编号 | A-07 |
| 活动名称 | 支付模块测试用例编制 |
| 活动定义 | 依据支付模块需求规格说明书编制测试用例，覆盖全部一级功能点，经测试负责人评审通过后归档至测试库。 |
| 所属工作包 | WP3 支付模块测试 |
| 前置活动 | A-05（需求规格说明书评审通过） |
| 紧后活动 | A-09（执行支付模块功能测试） |
| 负责人 | 测试工程师 李某 |
| 计划工期 | 3个工作日 |
| 所需资源 | 需求规格说明书v1.2、测试用例模板、测试负责人评审时间 |
| 交付物 | 支付模块测试用例集v1.0 |
| 完成标准 | 用例覆盖全部一级功能点，评审意见闭环，用例集归档至测试库 |
| 假设与约束 | 假设需求规格说明书在A-05完成后不再变更；约束为评审需在编制完成后2个工作日内安排 |
| 状态 | 未开始 |
逐项看这条记录的配合关系：活动定义中的“依据需求规格说明书”对应前置活动A-05，“归档至测试库”对应交付物和完成标准，“评审通过”在完成标准中再次明确为“评审意见闭环”。前置与紧后形成闭环，A-05的紧后应包含A-07，A-09的前置应包含A-07。假设与约束写明了需求不再变更这一前提，一旦需求变更，这条活动的工期和用例范围需要重新评估。状态字段留待执行阶段更新，规划阶段填“未开始”即可。
活动清单落到工作项管理工具中时，字段会转化为工作项的属性，依赖关系转化为任务的前后置关联。ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并为任务设置前后置依赖、用里程碑标记重要时间点，活动编号、负责人、工期、状态等字段可以在任务层级承载，进度自下而上反馈、自上而下监控。模板本身也可以放在ONES Wiki的页面模板库中，作为制式化文档复用，页面组关联项目后，文档与任务进度可以互相对应。
模板的调整与维护方法
模板不是一次定稿就固定不变。项目规模、依赖复杂度和交接要求变化时，字段和填写深度都要跟着调整。
按项目规模裁剪字段。活动在十条以内、单人主导的小项目，用六项最小字段集即可；跨两个以上角色协作时补上所需资源和交付物；存在外部依赖或硬性时间窗口时补上假设与约束；需要持续跟踪进展时再启用状态字段。裁剪的原则是保留能支撑分工和验收的字段，删掉当前阶段用不上的信息列。
明确更新时点与责任人。活动清单通常在三个时点更新：规划评审通过后建立基线；活动状态变化时由负责人更新状态和实际进展；范围或依赖变更时由项目负责人统一调整活动定义、工期和前后置关系，并通知受影响的活动负责人。更新动作集中在一处进行，避免多份清单各自修改后对不上。
复用到新项目时按清单检查：
- 活动编号规则是否沿用，避免与旧项目编号混淆；
- 活动定义中的对象和依据是否已替换为新项目的文档名称；
- 前置、紧后关系是否仍成立，删除已不存在的活动引用；
- 负责人、资源、工期是否已按新项目实际情况重填，不留旧项目信息；
- 完成标准是否仍可核验，验收方是否明确；
- 假设与约束是否更新为新项目的外部前提。
复用旧模板最常出现的问题是残留旧项目的负责人和文档名，检查时逐列过一遍比整体浏览更可靠。模板经过两三个项目使用后，可以把反复出现的字段填写口径沉淀为填表说明，附在模板下方，新成员拿到表就能按同一口径落笔。
常见问题
活动清单里的“前置活动”填“无”和留空有什么区别？
留空通常表示还没判断过依赖，填“无”表示已经确认这条活动没有前置约束。两者在后续排期和依赖检查中的含义不同：留空的记录需要回头补判断，填“无”的记录可以直接进入排期。建议在模板填写说明中明确这一口径，让填写人统一处理。
活动定义写多长合适，写短了怕说不清，写长了又难读？
一条活动定义通常一句话即可，包含动作、对象、输出和完成判据四个要素。判断标准是脱离上下文能否独立读懂、能否据此判断完成与否。如果一句话里出现两个以上产出物，说明范围偏大，应拆成两条活动；如果读完仍不知道谁验收、看什么验收，说明完成判据还没写进去。
小项目用最小字段集，后续活动变多时怎么补字段？
可以在原有表格上直接追加列，不必重建清单。活动数量超过二三十条、或需要多人并行推进时，优先补前置活动、紧后活动和状态三列，依赖关系和进度才看得清；涉及共享资源或外部配合时再补所需资源和假设与约束。追加字段后，对已有活动逐条回填，避免新列长期空白。
活动清单和WBS是什么关系，所属工作包字段一定要填吗？
活动清单是把WBS末端工作包继续拆成可执行活动后的结果，所属工作包字段用于标明每条活动归属哪个工作包。活动数量少、单层清单可以省略该字段；活动数量多、需要与WBS对照检查是否有遗漏时，建议填写，避免出现无归属活动。
活动清单落到工作项管理工具里，字段和依赖关系怎么对应？
活动编号、负责人、工期、状态等字段通常转化为工作项的属性，前置与紧后关系转化为任务之间的前后置关联。ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并为任务设置前后置依赖、用里程碑标记重要时间点，进度可自下而上反馈、自上而下监控；模板本身也可以放在ONES Wiki的页面模板库中作为制式化文档复用。具体字段配置以实际产品环境为准。
