这份核查清单用于复核AI整理出的需求约束是否完整、可验证。清单按功能约束、非功能约束、合规与安全约束、依赖与验收条件四类组织，每项写明通过标准、证据形式和负责人；任一项缺失或无法给出证据即判为阻断，退回补充后再进入评审。适用于AI输出需求初稿后、需求评审前以及变更后的复核场景。
要点总览（TL;DR）
- 清单按功能约束、非功能约束、合规与安全约束、依赖与验收条件四类组织，每项写明检查项、通过标准、证据形式、负责人和阻断标记。
- 通过标准要写成可直接判断的表述，例如给出指标口径、判定方式或可指认的证据材料，避免“响应及时”“做好数据保护”这类无法核验的措辞。
- 复核AI输出时逐条回到原始需求材料找约束出处，把问题分为缺失、含糊、冲突三类，再按阻断与非阻断分级处理。
- 阻断项处理完毕并经复核确认、带条件放行项已登记、核查表完成签署，才算通过；变更后按受影响类别重新核查。
谁在什么时点使用这份核查清单
这份清单的定位是评审前的自检工具，参与角色和介入时点需要事先约定，否则容易出现“谁都在看、没人签字”的情况。建议在需求流程中固定三个使用时点，并明确每个时点的主责角色。
| 使用角色 | 介入时点 | 主要动作 | 产出 |
|---|---|---|---|
| 需求提出人 | AI输出需求初稿后 | 核对约束是否与原始业务意图一致，补充AI未覆盖的背景条件 | 约束来源说明、补充条目 |
| 需求分析人 | 初稿整理完成、提交评审前 | 逐条对照清单检查四类约束，标注缺失、含糊、冲突项 | 填写完整的核查表、问题清单 |
| 评审人（产品/技术负责人） | 需求评审会上 | 复核阻断项处理情况，判断能否通过或带条件放行 | 评审结论与签署记录 |
| 测试角色 | 评审前预检、验收条件确认时 | 检查验收条件与判定方式是否可执行、验收数据与环境是否明确 | 验收条件确认意见 |
| 合规与安全相关角色 | 涉及敏感数据、外部依赖时 | 核对数据分类、权限、审计与合规依据 | 合规核查意见 |
前置输入包括三类材料：原始需求材料（访谈记录、用户反馈、业务文档）、AI整理稿、约束来源说明。缺少来源说明时，复核人无法判断某条约束是原文已有还是AI推断，应视为证据不足。需求发生变更后，只需重走受影响条目，但变更涉及的类别必须整类复查。
功能约束检查项与通过标准
功能约束是AI整理稿最容易“看起来完整”的部分：主流程通常写得顺，分支、边界和角色差异常被压缩。检查时重点看这些被压缩的地方，每项都要能指出原文出处或明确标注为待确认。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 核心流程与分支完整性 | 主流程每一步有输入、处理、输出；每个判断节点列出全部分支，包括默认分支 | 流程图或步骤清单，与原始材料逐条对应 | 需求分析人 | 阻断 |
| 输入输出与字段规则 | 每个输入项写明类型、必填性、长度或取值范围、校验规则；输出写明格式与去向 | 字段规则表 | 需求分析人 | 阻断 |
| 边界条件与异常处理 | 列出空值、超限、重复提交、超时、失败重试等情形及期望行为 | 异常场景清单，标注来源 | 需求分析人、测试角色 | 阻断 |
| 例外与特殊场景 | 业务上的特批、临时规则、历史数据兼容等例外有明确说明和处理口径 | 例外条目及业务方确认记录 | 需求提出人 | 阻断 |
| 权限与角色差异 | 每个角色可见范围、可操作动作、数据范围分别说明，不合并为“按权限控制” | 角色—权限对照表 | 需求分析人 | 阻断 |
通过标准的写法要能直接判断“过或不过”。例如“支持导出”不合格，应写成“支持按筛选条件导出当前列表，导出字段包含A、B、C，单次上限X条，超出时提示分批”。证据形式优先选择可指认的材料：原始访谈记录页码、业务方确认消息、字段规则表版本号。负责人一栏填具体姓名或岗位，不填“相关同事”。
非功能约束检查项与通过标准
性能、容量、可用性这类约束在AI整理稿中常被写成“响应及时”“高可用”等无法验证的表述。复核时要求每条指标带口径：在什么条件下、测什么、达到什么值。指标值来自业务方或技术负责人确认，复核人负责检查口径是否齐全，不替业务方定指标。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 性能与响应时间 | 关键操作给出响应时间指标及统计口径（如P95、并发条件下的平均值），区分前后端或接口级 | 性能指标表，注明来源与确认人 | 技术负责人 | 阻断 |
| 容量与并发规模 | 给出用户量、并发数、数据量级及增长预期，说明峰值场景 | 容量估算说明 | 技术负责人、业务方 | 阻断 |
| 可用性与恢复要求 | 明确可用性目标、允许中断时长、故障恢复方式与数据恢复点 | 可用性要求条目 | 技术负责人 | 阻断 |
| 兼容环境与终端范围 | 列出浏览器及版本、操作系统、移动端机型或分辨率范围，说明降级策略 | 兼容性矩阵 | 需求分析人、测试角色 | 非阻断（可带条件放行） |
| 可维护性与可观测性 | 说明日志、监控指标、告警要求及配置项管理方式 | 可观测性要求清单 | 技术负责人 | 非阻断 |
兼容范围这类条目在评审前未完全确认时，可标注“待确认”并带条件放行，但必须在评审记录中写明确认时限和责任人。性能与容量指标缺失则属于阻断：没有指标，测试无法设计验收用例，开发也无法判断实现是否达标。
合规与安全约束检查项与通过标准
合规与安全条目要落到可核验的动作上。AI整理稿常出现“符合相关法规”“做好数据保护”这类表述，复核时要求补出具体的数据对象、控制措施和依据文件。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 数据分类与敏感信息处理 | 列出需求涉及的数据对象并标注分类；敏感信息的采集、存储、展示、脱敏方式逐项说明 | 数据分类清单、脱敏规则说明 | 合规角色、需求分析人 | 阻断 |
| 访问控制与权限最小化 | 每个角色仅授予完成职责所需的最小权限，越权访问有拦截说明 | 权限设计说明 | 技术负责人 | 阻断 |
| 日志与审计留痕 | 明确记录哪些操作、保留多久、谁能查看，关键操作可追溯到人 | 审计日志需求条目 | 技术负责人、合规角色 | 阻断 |
| 外部依赖与数据出境 | 涉及第三方服务或跨境传输时，说明数据类型、传输路径与合规依据；不涉及则明确标注 | 第三方依赖说明、合规评估记录 | 合规角色 | 阻断 |
| 合规依据来源与责任人 | 每条合规要求注明依据文件或内部制度名称及版本，指定责任人 | 依据清单 | 合规角色 | 阻断 |
“不涉及”也是一种有效结论，但必须写明判断人和判断依据，不能留空。合规条目缺少依据来源时，复核人无法区分是硬性要求还是经验推断，应按阻断处理。
依赖与验收条件检查项与通过标准
依赖与验收条件决定需求能否被独立执行和判定完成。AI整理稿往往把依赖写成一句“依赖上游系统”，验收写成“功能正常”，这两类都需要展开。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断标记 |
|---|---|---|---|---|
| 上下游系统与接口依赖 | 列出依赖系统、接口名称、调用方向、数据内容及联调时间点 | 依赖清单、接口文档链接或版本 | 技术负责人 | 阻断 |
| 第三方服务与版本前提 | 写明第三方服务名称、所需版本或能力前提、到期或变更风险 | 第三方服务说明 | 技术负责人 | 阻断 |
| 验收条件与判定方式 | 每条验收条件可观察、可判定，写明判定人和判定方式（演示、测试用例、数据核对） | 验收条件表 | 需求提出人、测试角色 | 阻断 |
| 验收数据与环境准备 | 说明验收所需数据来源、脱敏要求、环境准备责任人与就绪时间 | 验收准备清单 | 测试角色 | 非阻断（可带条件放行） |
| 未确认依赖的标注方式 | 未确认的依赖统一标注“待确认”，写明确认人、确认时限及对排期的影响 | 待确认事项列表 | 需求分析人 | 阻断（未标注时） |
验收条件与功能约束要能对上：功能检查表里列出的每个分支和异常场景，验收条件中应有对应的判定方式。对不上的地方，要么补验收条件，要么说明该场景不在本期范围。
如何用清单复核AI输出：操作步骤
复核按固定顺序执行，保证每条结论都能回溯到原文。以下五步适用于单份需求整理稿，多份稿件可并行但需分别记录。
- 逐条对照原文找约束出处。打开原始需求材料和AI整理稿，对清单每一检查项在整理稿中定位对应表述，再回到原始材料确认出处。找不到出处的条目记为“来源不明”。
- 标注三类问题。缺失：清单要求的内容整理稿完全没有；含糊：有表述但无法判断，如“较快”“适当控制”；冲突：整理稿内部或与原始材料矛盾，如两处写了不同的权限范围。每类问题记录条目编号和原文摘录。
- 按阻断与非阻断分级。对照各表的阻断标记，把问题分为必须解决和可带条件放行两组。分级结果直接决定下一步是退回还是进入评审。
- 退回补充与二次复核。阻断项连同问题说明退回给需求分析人补充，补充完成后只复核修改条目及其关联条目，并在记录中注明复核轮次。
- 记录复核结论。结论写明通过、带条件通过或不通过，附问题清单、处理结果和签署人。结论与问题项建议在项目工作项或知识库文档中留痕，便于追溯和变更后复查。
问题标注示例：某整理稿写“管理员可查看全部订单，普通用户按权限查看”。复核标注为“含糊——普通用户的具体数据范围未说明，无法设计权限测试用例”，分级为阻断，退回补充后二次复核确认范围。
复核记录需要多人协作和长期追溯时，可以把每个阻断项登记为项目中的工作项，把核查表与结论保存在知识库文档中，使问题状态、负责人和处理结果在同一处可查。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，其输出过程可追踪、结果可审计（以ONES权限体系配置为前提）；在需求澄清环节，它可提炼待澄清问题与拆解建议，这些输出正好作为本清单的复核对象。将复核结论与问题项落到工作项和文档中，能让退回补充和二次复核有据可查。
阻断项与完成条件
阻断项的判定规则只有一条：该项缺失、含糊或冲突，且会导致开发无法实现、测试无法设计用例或合规无法确认。满足这条即阻断，与问题大小无关。按此规则，四类检查表中的阻断标记汇总如下。
| 类别 | 典型阻断项 | 可带条件放行的情形 |
|---|---|---|
| 功能约束 | 分支不全、字段规则缺失、权限差异未说明、异常处理未列出 | 例外场景已标注待确认且有确认人和时限 |
| 非功能约束 | 性能、容量、可用性指标缺失或口径不明 | 兼容范围、可观测性细节待确认，不影响本期开发启动 |
| 合规与安全 | 数据分类缺失、权限最小化未说明、审计要求缺失、合规依据无来源 | 无；合规条目原则上不放行 |
| 依赖与验收 | 依赖系统或接口未列明、验收条件不可判定、未确认依赖未标注 | 验收数据与环境准备未就绪，但已指定责任人和就绪时间 |
带条件放行的条目须在评审记录中写明条件内容、责任人和完成时限，到期未完成则自动转为阻断。完成条件为：全部阻断项已处理并经复核确认，带条件放行项已登记，核查表由需求分析人和评审人签署。签署方式可采用评审会记录加电子确认，复核记录随需求文档一并留存，变更后按受影响类别重新核查并追加记录。
常见问题
AI整理稿里写了“按权限控制”，还需要在清单里展开到角色级别吗？
需要。权限与角色差异属于功能约束的阻断项，通过标准要求每个角色的可见范围、可操作动作和数据范围分别说明。只写“按权限控制”属于含糊问题，测试无法据此设计越权访问用例，开发也无法判断实现边界。复核时把它标注为含糊并退回补充，补充后二次复核确认具体范围。
性能指标业务方一时给不出，能不能先通过评审再补？
性能与容量指标缺失属于阻断项，不建议先通过。没有指标口径，测试无法设计验收用例，开发也无法判断实现是否达标。可行的做法是让技术负责人和业务方在评审前给出初版指标及统计口径，例如关键操作的响应时间指标和并发条件；确实需要后续校准的，在评审记录中写明校准责任人和时限，并按带条件放行登记。
合规条目写“不涉及数据出境”，还需要提供什么？
“不涉及”是有效结论，但要写明判断人和判断依据，不能留空。复核时检查该结论是否有对应的数据对象梳理支撑，例如需求涉及的数据类型、是否调用第三方服务、传输路径是否跨境。缺少判断依据的“不涉及”按阻断处理，因为复核人无法区分这是核实后的结论还是经验推断。
需求变更后，整份清单要重新走一遍吗？
不需要整份重走，但变更涉及的类别必须整类复查。例如变更调整了数据字段，功能约束中的字段规则和合规约束中的数据分类都要重新核查；只调整了界面文案，则重点复查功能约束中受影响的条目。复查结果作为追加记录随原核查表留存，并注明变更内容和复核轮次。
复核结论和问题项怎么留痕，方便后续追溯？
常见做法是把每个阻断项登记为项目中的工作项，把核查表与评审结论保存在知识库文档中，使问题状态、负责人和处理结果在同一处可查。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，其输出过程可追踪、结果可审计（以 ONES 权限体系配置为前提）；在需求澄清环节，它可提炼待澄清问题与拆解建议，这些输出正好作为本清单的复核对象。
