版本功能清单是一张按版本归集“做什么”的表：每行一个功能项，写清功能名称、所属模块、需求来源、优先级、目标用户与场景、验收口径、状态和负责人，再补版本号、计划窗口、依赖与不在本版本范围等版本级信息。清单只界定版本内容，发布准入、上线执行和回滚由研发交付管理承接。下面给出可直接复制的空白表格、逐字段填写口径、必填与选填对照、填写示例和维护规则。
要点总览（TL;DR）
- 版本功能清单按版本归集“做什么”：版本级写版本号、版本主题、计划窗口、清单负责人和更新时间，明细每行一个功能项。
- 功能明细至少包含功能名称、所属模块、需求来源、优先级、验收口径、状态和负责人；新功能版还需目标用户与场景、依赖项。
- 最低完整度看三类信息：定位（名称、模块）、判断（优先级、验收口径）、责任（状态、负责人），缺一类清单就只能当目录用。
- 清单要配套维护规则：新增补全必填字段，移出改状态并记入范围外记录，范围冻结后新增默认进入下一版本。
可复制空白模板：版本功能清单表
模板分三块：版本级信息区、功能明细表、不在本版本范围记录区。版本级信息只写一次，功能明细每行一个功能项，范围外记录用来挡住“这个版本顺便做一下”的口头需求。复制到文档或表格工具后，先填版本级信息，再逐行补明细。
版本级信息区
| 字段 | 填写内容 |
|---|---|
| 版本号 | |
| 版本主题 | |
| 计划窗口 | |
| 清单负责人 | |
| 更新时间 |
功能明细表
| 序号 | 功能名称 | 所属模块 | 需求来源 | 目标用户与场景 | 优先级 | 验收口径 | 依赖项 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 | |||||||||
| 4 | |||||||||
| 5 |
不在本版本范围记录区
| 序号 | 事项 | 不纳入原因 | 后续去向 | 记录人 |
|---|---|---|---|---|
| 1 | ||||
| 2 |
每个字段填什么：字段说明与填写口径
字段的价值在于让不同角色读到同一行时理解一致。功能名称回答“做什么”，验收口径回答“做到什么程度算完成”，状态回答“现在走到哪一步”。下面逐字段说明含义、写法和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 功能名称 | 本版本要交付的功能单元 | 用“动词＋对象”写成一个可交付结果，如“支持按标签筛选订单”；一个功能项只对应一个可验收结果 | 写成“优化体验”“完善后台”这类无法判断完成的口号；一行塞进多个功能 |
| 所属模块 | 功能在产品结构中的位置 | 沿用产品现有的模块划分，写模块名而非页面名；跨模块功能写主模块，并在依赖项注明关联模块 | 临时造模块名，导致与需求池、缺陷记录对不上 |
| 需求来源 | 这项功能为什么进入本版本 | 记录来源类型和可追溯标识，如客户反馈单号、内部规划议题、合规要求、线上问题编号 | 只写“用户需求”，无法回溯到具体记录 |
| 目标用户与场景 | 谁在什么情况下使用 | 写角色＋触发情境＋要完成的任务，如“仓库管理员在每日盘点时批量核对库存差异” | 写“所有用户”，等于没有目标；只写角色不写场景 |
| 优先级 | 本版本内的相对重要程度 | 用固定档位（如P0/P1/P2）并写明判断依据：阻塞发布、影响核心流程、影响体验、可延后 | 只标高低不写依据；所有项都标最高 |
| 验收口径 | 判断功能完成的客观标准 | 写到可观察、可判断：关键操作路径、边界条件、数据结果、性能或兼容要求；必要时附验收用例编号 | 写“功能正常”“体验良好”；只写开发完成，不写验收条件 |
| 依赖项 | 本功能推进所需的前置条件 | 写清依赖对象和依赖类型：其他功能项序号、外部系统接口、数据迁移、设计稿、第三方资质 | 依赖只写在聊天记录里，清单上看不到 |
| 状态 | 功能项当前进展 | 使用统一状态集，如待评审、已确认、开发中、待验收、已完成、已移出；状态变更时同步更新时间 | 各人自造状态词；完成后不更新，清单长期停留在旧状态 |
| 负责人 | 对该功能项交付负责的人 | 写具体人名，一个功能项一个主负责人；协作角色放在依赖项或备注中 | 写团队名或多人并列，出问题时无人认领 |
版本级字段同样需要口径。版本号沿用团队既有编号规则；版本主题用一句话概括本版本要解决的核心问题；计划窗口写计划开始与计划发布的时间范围，并注明是计划值；清单负责人是维护这张表的人，与各功能项负责人区分开；更新时间每次修改后刷新，便于判断清单是否过期。
必填与选填：哪些字段不能空
最低完整度标准是：任何人只看清单，就能判断这个版本包含什么、每项由谁负责、做到什么程度算完成。达不到这条标准的字段不能留空。选填字段用于提升可读性和协作效率，按版本类型取舍。
| 字段 | 新功能版 | 维护版 | 说明 |
|---|---|---|---|
| 版本号、版本主题、计划窗口、清单负责人、更新时间 | 必填 | 必填 | 版本级信息缺失，清单无法被引用和评审 |
| 功能名称、所属模块 | 必填 | 必填 | 定位功能项的基本坐标 |
| 需求来源 | 必填 | 必填 | 维护版可写问题单号或缺陷编号 |
| 目标用户与场景 | 必填 | 选填 | 维护版多为修复类事项，场景可由问题单承载；涉及体验调整时补填 |
| 优先级 | 必填 | 必填 | 维护版用于区分阻塞问题与一般问题 |
| 验收口径 | 必填 | 必填 | 修复类可写复现步骤与预期结果 |
| 依赖项 | 必填（无依赖写“无”） | 选填 | 写“无”与留空含义不同，前者表示已确认 |
| 状态、负责人 | 必填 | 必填 | 清单流转的基础 |
| 不在本版本范围记录 | 建议填写 | 选填 | 评审中被明确推迟的事项应记录，避免反复讨论 |
必填的理由可以归为三类：定位（名称、模块）、判断（优先级、验收口径）、责任（状态、负责人）。缺少任何一类，清单就只能当目录用，无法支撑评审和交接。新功能版涉及跨团队协作和对外承诺，目标用户与场景、依赖项应作为必填；维护版以修复和小幅调整为主，可适当精简，但验收口径不能省，否则无法判断问题是否真正关闭。
填写示例：一个版本的完整清单片段
以下为演示情景，版本号、功能名称和数据均为示意，用于说明字段如何组合填写，不代表真实项目。
示例版本信息区
| 字段 | 填写内容 |
|---|---|
| 版本号 | V2.4（演示） |
| 版本主题 | 订单处理效率提升 |
| 计划窗口 | 计划 3 月 10 日至 4 月 18 日，计划发布 4 月 18 日 |
| 清单负责人 | 产品经理 李某 |
| 更新时间 | 3 月 6 日 |
示例功能明细
| 序号 | 功能名称 | 所属模块 | 需求来源 | 目标用户与场景 | 优先级 | 验收口径 | 依赖项 | 状态 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 支持按标签批量筛选订单 | 订单管理 | 客户反馈单 FK-2317 | 仓库管理员在每日盘点时批量核对订单 | P0，阻塞核心流程 | 可按最多 5 个标签组合筛选，结果与单条件筛选一致，1000 条数据下响应不超过 2 秒 | 依赖序号 2 的标签数据接口 | 开发中 | 后端 王某 |
| 2 | 提供标签数据查询接口 | 基础数据 | 内部规划议题 PL-88 | 订单模块与报表模块调用 | P0，序号 1 的前置 | 接口返回标签列表与订单关联关系，字段文档评审通过，联调用例全部通过 | 无 | 待验收 | 后端 赵某 |
| 3 | 订单列表增加筛选条件记忆 | 订单管理 | 客户反馈单 FK-2290 | 客服在连续处理工单时减少重复设置筛选 | P2，影响体验可延后 | 同一用户再次进入列表时保留上次筛选条件，清除缓存后恢复默认 | 依赖序号 1 | 已确认 | 前端 陈某 |
| 4 | 修复导出文件缺少表头问题 | 报表 | 缺陷单 BUG-1042 | 财务人员在月度对账导出报表时使用 | P1，影响对账准确性 | 按缺陷单复现步骤验证，导出文件包含全部列名，历史数据导出结果一致 | 无 | 已完成 | 后端 周某 |
示例范围外记录
| 序号 | 事项 | 不纳入原因 | 后续去向 | 记录人 |
|---|---|---|---|---|
| 1 | 订单标签的自定义颜色 | 不影响筛选主流程，本版本排期不足 | 进入需求池，候选 V2.5 | 产品经理 李某 |
| 2 | 标签权限按角色细分 | 需先完成权限模型调整 | 挂到权限改造议题下 | 产品经理 李某 |
示例中每行都能对应到字段说明：功能名称是可交付结果，验收口径写到可判断的程度，依赖项指向具体序号，状态使用统一状态集。范围外记录写清原因和去向，评审时可以直接引用，不必重新讨论。
调整与维护：清单怎么改、谁来改、多久改
清单在版本周期内会持续变化，维护机制要解决三个问题：字段是否够用、范围变了怎么记、谁在什么节点确认。建议把清单当作版本范围的唯一记录，其他渠道讨论出的结论回写到清单，避免多份口径并存。
字段增删的判断标准
新增字段前先问：这个信息是否每行都需要、是否会影响范围判断或验收判断。只有多数功能项都需要的字段才进入主表，个别功能项的特殊信息放在备注或关联文档中。字段连续两个版本无人填写，可以考虑删除；删除前确认历史版本清单仍可读，必要时保留旧表结构不追溯修改。
版本范围变更时的更新规则
- 新增功能项：补全必填字段，注明来源和加入原因，由清单负责人确认后生效。
- 移出功能项：状态改为“已移出”，同时在范围外记录区写明原因和去向，不直接删除行。
- 验收口径调整：保留调整说明和调整时间，涉及对外承诺的变更需同步相关角色。
- 每次修改刷新更新时间，重大变更在变更记录中留一行摘要。
评审节点与责任人
常见节点包括版本启动时的范围评审、开发中期的范围冻结评审、发布前的完成情况核对。清单负责人负责组织和回写结论，各功能项负责人负责更新自己行的状态和验收结果。范围冻结后新增事项默认进入下一版本，确需插入的由清单负责人记录例外原因。
与需求池、发布计划的衔接边界
需求池回答“有哪些需求待评估”，版本功能清单回答“这个版本做哪些”，发布计划回答“什么时候上线、按什么条件放行”。三者的衔接方式是：清单中的需求来源字段指回需求池记录，清单确认的范围作为发布计划的输入；发布准入、上线执行和回滚不在清单内展开，由研发交付管理承接。
清单需要多人协作维护时，可以放在支持模板创建和版本记录的文档工具中。ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚，便于在范围变更后追溯清单的历史状态。把清单放在与项目关联的文档里，功能项负责人更新状态、评审结论回写都能留在同一处，减少清单与项目工作脱节的情况。
常见问题
版本功能清单和需求池是什么关系，两边都要维护吗？
两者回答的问题不同：需求池记录“有哪些需求待评估”，版本功能清单记录“这个版本做哪些”。日常做法是需求池保留全量候选，清单只放已确认进入本版本的功能项，并通过需求来源字段指回需求池记录。清单确认的范围作为发布计划的输入，发布准入、上线执行和回滚由研发交付管理承接，不在清单内展开。
维护版的功能项很少，字段可以精简到什么程度？
维护版以修复和小幅调整为主，可以精简目标用户与场景、依赖项等字段，但版本级信息、功能名称、所属模块、需求来源、优先级、验收口径、状态和负责人不能省。修复类事项的验收口径可以写成复现步骤加预期结果，这样问题是否真正关闭有客观判断依据。涉及体验调整时，再补回目标用户与场景。
范围冻结之后又插入了新功能，清单上怎么记录？
范围冻结后新增事项默认进入下一版本。确需插入的，由清单负责人补全必填字段，注明来源和插入原因，记录例外情况后生效，并刷新更新时间。被挤出的功能项状态改为“已移出”，同时在范围外记录区写明原因和去向，保留原行不直接删除，便于后续追溯和评审时引用。
清单放在文档工具里维护，和放在表格里有什么区别？
表格适合快速起步，字段和格式自由；文档工具的优势在于与项目工作保持关联。以 ONES Wiki 为例，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚，范围变更后可以追溯清单的历史状态。选择哪种载体，主要看清单是否需要多人协作更新、是否要频繁回写评审结论。
验收口径写到什么程度才算合格？
合格的标准是：不参与开发的评审人只看这一行，也能判断功能是否完成。写法上落到可观察、可判断的内容，包括关键操作路径、边界条件、数据结果，必要时加上性能或兼容要求。例如“可按最多 5 个标签组合筛选，1000 条数据下响应不超过 2 秒”，比“功能正常”更能支撑验收。修复类事项写复现步骤与预期结果即可。
