适用场景
说明该交付物在什么场合被使用，例如现场执行、内部审阅或对外沟通。字段值写具体场合，不写“各类活动”这类无法核对的表述。
交付物目录：六项文件各自解决什么问题
04 — 交付物目录
一次资料协作结束后，客户方拿到的不是一堆散文件，而是六项各有明确用途的交付物。本页逐项说明它们的用途、形态和产生节点，并解释字段含义与修改约定，方便对接人在内部核对清单是否覆盖实际使用场景。
交付物清单表
六项交付物按产生顺序排列，前四项在结构定稿与内容填充阶段形成，后两项在资料校验与交付归档阶段补齐。清单表只交代用途与形态，字段的具体含义见下方说明区。
| 名称 | 用途 | 形态 | 产生节点 |
|---|---|---|---|
| 议程主表 | 按时间顺序排定议题、发言人与时长，供现场执行与内部审阅使用。 | 横向表格，含时间列、议题列、责任人列 | 结构定稿 |
| 议题分组说明 | 解释议题为何这样归类，供内部讨论与对外沟通时引用。 | 分段说明页，每组一段 | 结构定稿 |
| 命名索引 | 统一素材与交付文件的命名口径，避免同名覆盖与版本混淆。 | 对照表，左列原名、右列规范名 | 内容填充 |
| 现场流程表 | 把议程主表压缩成现场可直接对照的单页流程，标注衔接动作。 | 单页表，含环节、衔接人、备注 | 内容填充 |
| 版本记录页 | 记录每次修改的时间、范围与确认方，便于追溯。 | 纵向列表，一行一次修改 | 资料校验 |
| 归档清单 | 列出最终提交的全部文件及其存放位置，作为移交依据。 | 清单表，含文件名、位置、状态 | 交付归档 |
版本与修改约定
修改本身不是问题，问题在于修改之后没人知道改了哪一版。以下三条约定用于把改动落成可追溯的记录，三条都写进版本记录页，不在口头沟通里结束。
-
结构定稿后调整议题顺序
触发条件：议程主表已确认，客户方提出议题增删或顺序调整。处理方式：先更新议程主表并标注改动行，再同步修改议题分组说明与现场流程表，三份文件在同一次记录中登记。
-
素材替换导致命名变化
触发条件：客户方用新文件替换已提交的素材。处理方式：新文件按命名索引重新命名，旧文件不删除，在版本记录页注明替换关系，命名索引同步更新对照行。
-
交付后的小幅补充
触发条件：归档清单已提交，客户方需要补充说明类文件。处理方式：补充文件单独编号并追加到归档清单末尾，不覆盖原文件，版本记录页写明补充原因与确认方。
字段含义说明
交付物里反复出现的几个字段名，全站保持同一套叫法。理解这四个字段，基本就能判断一份交付物是否够用。
参与方
标注该交付物由谁确认、由谁使用。客户方对接人与内部审批人是两个不同角色，字段中分开列出，避免确认责任含糊。
产生节点
指出该交付物在哪个阶段形成，对应需求确认、结构定稿、内容填充、资料校验、交付归档五个节点的名称。字段值只写节点名，不写日期。
版本记录
记录每次修改的时间、范围与确认方。字段值要求可追溯，一条记录对应一次确认，不合并多次改动为一行。