AI需求约束检查表围绕五类约束展开：功能约束、非功能约束、合规与安全约束、依赖与集成约束、验收条件。每类拆成可判断“通过/不通过”的检查项，并配通过标准、证据和负责人。它用于复核AI整理出的需求初稿，检查约束是否写清、证据是否齐全，不负责文档排版与成稿质量。
要点总览（TL;DR）
- 检查表围绕五类约束组织：功能约束、非功能约束、合规与安全约束、依赖与集成约束、验收条件，每类拆成可判断通过/不通过的检查项。
- 每个检查项配通过标准、证据形式和负责人，判定时区分“写了”和“写清”，只写动作未写规则细节的判为不通过。
- 无法量化的非功能项标注“待确认”并写明确认人和时点，确认前不计为通过；合规条款以法务或安全团队结论为准。
- 阻断项包括安全与合规约束缺失、验收条件不可判断、核心计算口径缺失等，整体通过条件为阻断项清零且证据齐全。
- 复核AI输出按逐项比对、追问或补充、确认证据、回流评审、记录跟踪五步执行，需求变更后对变更部分重新核对。
谁在什么时点使用这张检查表
这张检查表服务于需求约束的复核环节，参与角色包括需求提出人、需求分析人、AI输出复核人，以及开发和测试代表。不同角色关注点不同：提出人确认业务规则与边界是否符合预期，分析人检查约束是否完整可执行，复核人负责逐项判定并记录结论，开发与测试代表从实现和验证角度指出含糊之处。
使用时点有三个：AI整理出需求初稿之后、需求评审会之前、需求变更之后。第一个时点用于发现AI省略或含糊的约束；第二个时点用于把复核结论带入评审，减少会上反复澄清；第三个时点用于确认变更没有破坏原有约束。检查范围限定为需求约束是否写清，文档排版、措辞风格和成稿质量不在检查表覆盖范围内。
| 角色 | 介入时点 | 主要动作 | 产出 |
|---|---|---|---|
| 需求提出人 | AI初稿后、评审前 | 确认业务规则、边界与优先级 | 规则确认意见 |
| 需求分析人 | AI初稿后、变更后 | 补全约束、消除含糊表述 | 修订后的需求约束 |
| AI输出复核人 | 评审前 | 逐项判定通过/不通过并记录证据 | 检查结论与待办 |
| 开发代表 | 评审前 | 检查约束是否可实现、依赖是否成立 | 实现风险意见 |
| 测试代表 | 评审前、变更后 | 检查验收条件是否可观察、可判断 | 验收条件意见 |
功能约束检查项：AI是否写清了系统必须做什么
功能约束回答“系统必须做什么”。AI生成的需求初稿常把主流程写得顺畅，却漏掉规则细节和分支。检查时逐项对照下表，每项都要能给出证据，不能只凭阅读印象打勾。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 业务规则与计算口径 | 每条规则写明触发条件、计算方式、取整或舍入规则；涉及金额、时长、比例的给出示例 | 规则条目及算例 | 需求提出人 |
| 输入输出与边界条件 | 每个输入写明来源、格式、必填性与取值范围；输出写明内容与去向；空值、超限、重复提交有明确处理 | 字段清单或输入输出说明 | 需求分析人 |
| 角色权限与操作范围 | 列出涉及的角色，每个角色可执行的操作和数据可见范围写清；越权操作的结果有说明 | 角色—操作对照表 | 需求分析人 |
| 异常与分支场景 | 主流程之外的失败、超时、并发冲突、部分成功等场景有处理规则，不出现“视情况处理”一类表述 | 场景清单及处理规则 | 开发代表 |
判定时注意区分“写了”和“写清”。例如“支持批量导入”只写了动作，没有写文件格式、单次条数上限、失败行如何反馈，应判为不通过并退回补充。功能约束的检查结论要落到具体条目，便于后续追问。
非功能约束检查项：性能、容量、可用性与易用性
非功能约束是AI输出最容易省略的部分，因为初稿通常围绕功能描述展开。检查时要求每项有量化目标或明确的待确认标注，避免用“较快”“稳定”“友好”这类无法验证的词。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 性能与响应时间 | 关键操作给出响应时间目标及统计口径（如平均、95分位），并说明在何种负载下成立 | 性能指标条目 | 需求提出人 |
| 容量与并发规模 | 数据量、用户数、并发数有数值或测算依据；增长预期有说明 | 容量测算或业务量数据 | 需求提出人 |
| 可用性与恢复要求 | 可用性目标、允许中断时长、故障恢复时间与数据恢复要求写明 | 可用性条款 | 开发代表 |
| 易用性与兼容性 | 支持的终端、浏览器或设备范围列出；关键操作步骤数、无障碍等要求如有则写明 | 兼容范围清单 | 测试代表 |
无法当场量化的项，标注为“待确认”并写明确认人和确认时点，不能留空通过。例如并发规模暂时没有业务数据，应记录“待运营提供上线首月预估并发，评审前确认”，该条在确认前不计为通过。
合规与安全约束检查项：数据、权限与审计
合规与安全约束涉及数据怎么用、谁能访问、留下什么记录。AI初稿往往只写功能层面的权限，缺少数据分类和审计要求。检查时按下表逐项核对，涉及法规条款的必须查证原文，不能凭AI表述直接采信。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 数据分类与敏感信息处理 | 需求涉及的数据按敏感程度分类；敏感信息的采集、展示、脱敏、留存期限有明确要求 | 数据分类清单 | 需求提出人 |
| 访问控制与最小权限 | 每个角色仅授予完成职责所需的最小权限；权限申请与回收流程写明 | 权限矩阵 | 需求分析人 |
| 日志与审计留痕 | 关键操作（登录、数据导出、权限变更、敏感数据访问）记录操作人、时间、对象与结果 | 日志字段清单 | 开发代表 |
| 外部依赖与第三方数据处理 | 涉及第三方接口或服务时，写明传输的数据范围、对方用途与责任边界 | 第三方数据处理说明 | 需求分析人 |
| 合规条款查证 | 引用法规、标准或认证要求的条目注明出处，并标注“待法务/安全确认” | 条款出处与确认记录 | 复核人 |
合规条款的查证事项单独标注，不与已确认项混在一起。AI给出的合规表述只能作为线索，最终以法务或安全团队的确认结论为准。
依赖与验收条件检查项：上下游与可验收性
依赖与验收条件决定需求能否落地、做完如何判定完成。AI初稿常把依赖写成一句“依赖相关系统”，验收条件写成“功能正常”。检查时要求依赖具体到系统、接口或数据，验收条件具体到可观察的结果。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 上下游系统与接口依赖 | 列出依赖的系统、接口名称、调用方向与联调时间；接口未就绪时有替代方案或排期说明 | 依赖清单 | 开发代表 |
| 前置数据与配置依赖 | 写明上线前需准备的数据、参数配置、环境要求及准备责任人 | 上线准备清单 | 需求分析人 |
| 验收条件可观察可判断 | 每条验收条件对应可执行的验证动作和预期结果，避免“体验良好”等主观表述 | 验收条件条目 | 测试代表 |
| 验收责任人与时点 | 每条或每组验收条件指定确认人和确认时点，明确在哪个环境验收 | 验收责任表 | 需求提出人 |
依赖尚未确认时，记录为“待确认”并写明对接人和确认期限，同时评估该依赖是否影响排期。未确认的依赖不阻断需求描述本身，但涉及关键路径时应升级为阻断项处理。
阻断项与完成条件：什么情况下不能通过
检查结果需要直接支撑放行决策，因此要区分阻断项和非阻断项。阻断项指缺失后会导致需求无法评审通过或无法安全上线的条目，典型包括：安全与合规约束缺失（如敏感数据处理要求、访问控制未写）、验收条件缺失或不可判断、关键业务规则与计算口径缺失、关键上下游依赖未确认且无替代方案。
阻断项的解除条件是补齐对应内容并附证据，由原复核人复检确认，复检结论记录在案。非阻断项如表述含糊、次要兼容性范围未列全，记录为待办并指定责任人和期限，跟踪至关闭，不阻塞本次评审。
| 类别 | 示例 | 处理方式 | 是否阻塞评审 |
|---|---|---|---|
| 阻断项 | 敏感数据处理要求缺失；验收条件不可判断；核心计算口径缺失 | 退回补充，复检通过后解除 | 是 |
| 非阻断项 | 个别术语不统一；次要终端兼容范围待补 | 登记待办，限期关闭 | 否 |
整体通过条件为：阻断项清零，且每个通过项都有对应证据。仅凭“看起来没问题”不能判定通过；证据可以是规则条目、指标数值、权限矩阵、依赖清单或确认记录。
用检查表复核AI输出的操作步骤
复核AI输出按以下步骤执行，每步都有明确产出，便于交接和追溯。
- 逐项比对。把AI输出的需求初稿对照五类检查项逐条核对，标记“缺失”“含糊”“已写清”三种状态，含糊项注明具体问题，如“只写了支持导出，未写导出范围与权限”。
- 追问或补充。对缺失和含糊项，先向AI追问具体约束，要求给出量化目标或规则细节；AI无法给出依据的，由需求提出人或分析人人工补充，并注明来源。
- 确认证据。复核人核对每项证据是否真实存在、是否对应当前需求版本，确认后在检查表中记录结论和证据位置。
- 回流评审。把检查结论、阻断项清单和待办带入需求评审，评审会上只讨论未通过项和争议项，通过项不再重复澄清。
- 记录与跟踪。复核结论和待办需要有承载位置，便于变更后复查。在ONES中，可将复核结论写入Wiki页面，把待补事项登记为工作项并指派负责人和期限；ONES Assistant可基于项目与Wiki上下文回答问题、提炼待澄清问题，并将结果保存为工作项或Wiki页面，减少重复录入。涉及权限范围内的知识问答与任务执行，其输出过程可追踪，便于后续复查。
需求变更后，用同一张检查表对变更部分重新核对，重点检查变更是否影响原有安全约束、依赖和验收条件，复检结论同样记录在案。
常见问题
AI给出的需求初稿看起来完整，还需要逐项对照检查表吗？
需要。AI初稿通常主流程顺畅，省略的往往是规则细节和分支场景，例如“支持批量导入”只写了动作，未写文件格式、条数上限和失败行反馈。逐项对照的价值在于把阅读印象转成可判断的结论：每项要么给出证据判为通过，要么标记缺失或含糊退回补充。只凭通读判断，容易把“写了”当成“写清”。
非功能约束暂时拿不到量化数据，这条算通过还是阻断？
既不算通过，也不一定阻断。处理方式是标注“待确认”，写明确认人和确认时点，例如“待运营提供上线首月预估并发，评审前确认”，确认前该条不计为通过。如果这项非功能约束位于关键路径、缺失会导致无法安全上线，则按阻断项处理；否则登记为待办，限期关闭，不阻塞本次评审。
复核结论和待补事项记在哪里，变更后怎么复查？
复核结论需要能对应到具体需求版本，待补事项要有责任人和期限。在ONES中，可以把复核结论写入Wiki页面，把待补事项登记为工作项并指派负责人和期限；ONES Assistant可基于项目与Wiki上下文回答问题、提炼待澄清问题，并将结果保存为工作项或Wiki页面，减少重复录入。需求变更后，用同一张检查表对变更部分重新核对，重点看变更是否影响原有安全约束、依赖和验收条件。
AI引用的法规条款可以直接写进需求吗？
不能直接采信。AI给出的合规表述只能作为线索，检查表中要求引用法规、标准或认证的条目注明出处，并标注“待法务/安全确认”，与已确认项分开记录。最终以法务或安全团队的确认结论为准，确认记录作为该检查项的证据留存。
检查表适用于哪些需求，哪些不在覆盖范围内？
检查表覆盖需求约束是否写清，适用于AI整理出需求初稿之后、需求评审会之前和需求变更之后三个时点。文档排版、措辞风格和成稿质量不在检查范围内；常规需求分析与澄清方法、AI文档成稿与报告生成也属于其他环节的工作。检查表的作用是让约束复核有统一口径，不替代评审会上的业务决策。
