AI需求约束核查清单模板：复核AI输出的检查表

这份清单用于在需求整理阶段复核AI输出的需求约束是否完整、可验证。按功能约束、非功能约束、合规与安全约束、依赖与验收条件四组逐项检查，每项给出通过标准、证据和负责人，并把缺失关键约束、无法验证的指标列为阻断项，未通过则退回补充后再进入评审。

要点总览（TL;DR）

• 这份清单在AI完成需求整理初稿后、正式评审前使用，由需求提出人、需求分析人员和评审人分工完成核查。
• 检查项分四组：功能约束看边界与范围外内容，非功能约束看指标能否量化验证，合规与安全约束看数据、权限与来源，依赖与验收条件看外部依赖与验收标准是否可判定。
• 阻断项只保留少量关键项：核心功能边界或范围外内容缺失、非功能指标无量化口径、合规要求无来源、数据分类未写明、验收标准不可判定。
• 清单通过需同时满足阻断项全部通过、待补项有责任人和期限、核查记录完整；未通过项按遗漏、材料缺失、AI推断三类分别回退复检。
• 复核时以原始需求为基准逐条比对，对AI新增内容单独标注，核查记录与需求条目关联留存，便于复检和评审追溯。

谁在什么时点用这份清单

这份清单服务于需求整理环节的约束复核，介入时点是AI完成需求整理初稿之后、正式评审之前。此时AI整理稿已经成形，但尚未进入评审流程，团队还有时间补充和退回，核查成本最低。清单不用于替代需求评审，也不用于判断需求价值，只回答一个问题：AI整理出的约束是否完整、可验证、有来源。

使用对象分为三类，各自承担不同动作。需求提出人负责确认原始业务意图和约束来源，判断AI整理稿是否偏离原意；需求分析人员负责逐项比对AI整理稿与原始材料，标记遗漏、含糊和不可验证项；评审人负责复核核查结论，对阻断项是否解除作出判断。三类角色可以由同一人兼任，但核查动作与放行判断建议分开，避免自查自放。

角色	介入时点	主要动作	产出
需求提出人	AI整理稿产出后	确认业务意图与约束来源，指出偏离项	约束来源确认意见
需求分析人员	核查执行阶段	逐项比对、标记遗漏与不可验证项	填写完整的核查清单
评审人	核查完成后、正式评审前	复核结论，判定阻断项是否解除	放行或退回决定

开始核查前需要准备三类前置输入：原始需求描述，作为比对基准；AI整理稿，作为被核查对象；约束来源材料，包括业务方说明、既有系统文档、合规要求文件等，用于判断AI整理稿中的约束是否有依据。缺少约束来源材料时，核查只能判断“是否写明”，无法判断“是否写对”，这类情况应在清单中标注为证据不足。

功能约束检查项

功能约束核查的重点是AI容易遗漏的边界与异常分支。AI整理需求时倾向于把主流程写顺，对输入异常、权限差异、范围外内容往往一笔带过或直接省略，这些正是复核时要逐条追问的地方。下表每项都给出可判定的通过标准，避免用“完善”“合理”这类无法核验的表述。

检查项	通过标准	证据	负责人	阻断
核心功能与输入输出	每个功能点写明输入来源、输出结果和触发条件，输入输出字段可对应到原始需求	AI整理稿功能段落、原始需求条目	需求分析人员	是
边界条件与异常分支	至少列出输入为空、超限、格式错误、重复提交等异常场景及对应处理说明	整理稿异常分支段落、来源材料中的业务规则	需求分析人员	否
角色与权限差异	不同角色的可见范围、可操作动作分别写明，权限差异有来源依据	角色清单、权限说明、来源材料	需求提出人	否
功能范围外内容	显式列出本期不做的功能或场景，与原始需求的范围约定一致	整理稿范围说明、原始需求范围条款	需求提出人	是

核查时对AI整理稿中新增、但原始材料没有的内容要单独标注。新增内容可能是合理补充，也可能是AI的推断，两种情况处理方式不同：合理补充经需求提出人确认后可保留，推断内容需回退到来源材料确认，确认前不计入通过。功能范围外内容列为阻断项，原因是范围不清会直接导致后续开发和验收口径分歧，必须在评审前解决。

非功能约束检查项

非功能约束是AI整理稿最容易写成空话的部分。“响应要快”“支持高并发”“兼容主流浏览器”这类表述在整理稿中常见，但无法测量，也无法验收。核查的标准是每个指标都能回答三个问题：数值是多少、在什么条件下测、由谁验证。

检查项	通过标准	证据	负责人	阻断
性能与响应时间	关键操作给出响应时间数值与单位，并注明统计口径（如平均、95分位）和测试条件	整理稿性能段落、来源材料中的性能要求	需求分析人员	是
容量与并发规模	用户量、数据量、并发数有数值和依据来源，注明是当前规模还是预期规模	业务量测算材料、来源材料	需求提出人	否
可用性要求	写明可用性目标或允许的中断时长，并说明统计周期	整理稿可用性段落、运维要求文件	需求分析人员	否
兼容范围	列出需支持的终端、浏览器、系统版本或对接系统版本，范围可核对	兼容性清单、现有环境说明	需求分析人员	否
指标可测量性	每个非功能指标都能对应到一种验证方式，如压测、监控采样、兼容性测试	验证方式说明	评审人	是

性能指标缺少量化口径列为阻断项，因为无法验证的指标进入开发后，验收阶段必然产生争议。容量与并发规模没有依据时，先记为待补项，由需求提出人补充业务量测算后再复检。兼容范围可以分批确认，但至少要写明本期必须覆盖的环境，避免开发完成后才发现目标环境遗漏。

合规与安全约束检查项

合规与安全约束在AI整理稿中常被简化成一句“符合相关安全要求”，这类表述既无法执行也无法审计。核查时要追问到具体的数据对象、权限动作和留痕要求，并确认每条要求都能追溯到来源文件。

检查项	通过标准	证据	负责人	阻断
数据分类与敏感信息处理	写明涉及的数据类型、敏感级别，以及脱敏、加密、留存期限等处理要求	数据分类说明、来源材料中的合规条款	需求分析人员	是
访问控制与权限最小化	每个角色只授予完成其职责所需的权限，越权访问有拦截说明	权限矩阵、角色说明	需求提出人	否
日志与审计留痕	写明需记录的操作类型、记录字段和留存期限，关键操作可追溯	审计要求文件、整理稿日志段落	需求分析人员	否
合规条款来源	每条合规要求标注适用条款或来源文件，无来源的要求单独列出待确认	合规文件、条款编号	评审人	是

合规要求没有来源列为阻断项。AI整理稿中出现的合规表述可能来自通用知识而非本项目的实际要求，未经来源确认就写入需求，会造成过度设计或遗漏真实义务两种风险。数据分类与敏感信息处理同样列为阻断项，因为它决定后续的权限设计和审计范围，属于其他约束的前置条件。日志字段和留存期限如来源材料未明确，可先记录待确认，不阻断流程，但需在评审时提出。

依赖与验收条件检查项

依赖与验收条件决定需求能否交付、能否判定完成。AI整理稿常把外部依赖写成一句“依赖某系统接口”，缺少接口状态、责任方和时间约定；验收标准则容易写成功能描述的重述，无法作为判定依据。核查时把依赖拆到可跟踪的程度，把验收标准改写成可判定的条件。

检查项	通过标准	证据	负责人	阻断
外部系统与接口依赖	列出依赖的系统、接口、当前可用状态和对接责任方，未就绪的注明计划时间	接口文档、依赖方确认记录	需求分析人员	否
前置条件与假设	每条假设写明内容、影响范围和验证方式，假设不成立时的应对有说明	整理稿假设段落、来源材料	需求提出人	否
验收标准可判定	每条验收标准对应一个可观察结果，能回答“通过或不通过”，避免复述功能描述	验收标准清单	评审人	是
未决问题跟踪	每个未决问题标注责任人和解决期限，期限不晚于评审日期或明确约定后续节点	未决问题列表	需求分析人员	否

验收标准不可判定列为阻断项。判定方法很简单：把每条标准交给未参与需求整理的人阅读，如果对方能给出明确的通过或不通过结论，标准合格；如果只能回答“看情况”，需要改写为具体条件加预期结果。外部依赖未就绪不阻断需求评审，但要在清单中记录状态和计划时间，作为后续排期依据。未决问题没有责任人和期限时，视为跟踪缺失，需补齐后再提交评审。

阻断项与完成条件

阻断项只保留少量关键项，目的是防止带着根本性缺口进入评审，同时避免清单变成事事卡关的工具。建议将以下情况列为阻断：核心功能边界或范围外内容缺失、非功能指标无量化口径或无法验证、合规要求无来源、数据分类与敏感信息处理未写明、验收标准不可判定。其余检查项未通过时记为待补项，记录责任人和补充期限，不阻断流程。

清单整体判定为通过需同时满足三个条件：全部阻断项通过；待补项均有责任人和补充期限，且期限经评审人确认；核查记录完整，每项都填写了结论和证据位置。三个条件缺一不可，仅有阻断项通过而待补项无人跟进的，判定为有条件通过，需在评审会上明确跟进安排。

未通过项的回退方式按问题类型区分。属于AI整理遗漏的，退回需求分析人员补充整理稿后复检对应检查项；属于来源材料缺失的，退回需求提出人补充材料，材料到位后复检；属于AI推断且无法确认的，从整理稿中移除或标注为待确认，不进入本期需求范围。复检只针对未通过项及其关联项，不要求全表重跑，但复检结论需更新到同一份核查记录中，保留首次核查与复检的时间。

如何用清单复核AI输出

复核动作按固定顺序执行，保证比对有基准、结论有记录、交接有状态。以下步骤以一份AI整理稿为单位，四组检查项依次过一遍。

1. 以原始需求描述为基准，逐条比对AI整理稿。先看整理稿是否覆盖原始需求的每个条目，再看整理稿新增了哪些原始材料没有的内容，新增内容单独列出。
2. 按功能、非功能、合规与安全、依赖与验收四组顺序逐项检查，每项填写通过、不通过或证据不足，并注明证据在整理稿或来源材料中的位置。
3. 对不通过项分类标记：遗漏、含糊、不可验证、无来源。分类决定回退方式，也便于统计AI整理稿的高频问题。
4. 汇总阻断项和待补项，填写责任人和期限，形成核查结论：通过、有条件通过或退回。
5. 把核查记录与需求条目关联留存，交接评审人复核。评审人确认后更新状态，退回的进入补充流程，通过的进入正式评审。

核查记录需要与需求条目保持关联，否则复检和评审追溯时找不到依据。在协作工具中承载这套流程时，可以把每个需求条目对应为一个工作项，核查清单作为工作项下的检查项或关联文档，结论和状态随工作项流转。ONES 的需求管理与 Wiki 页面可以承载这类记录：ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等工作上下文，围绕PRD质量检查和需求智能生成提炼待澄清问题与拆解建议，帮助团队完成需求澄清和录入；其AI能力基于ONES权限体系执行，输出过程可追踪、结果可审计。核查结论可保存为工作项或Wiki页面内容，与需求条目一起留存，便于复检时对照首次核查记录。具体承载形式和字段配置以实际环境为准。

复核完成后，建议把本次发现的AI整理高频问题记录下来，例如某类异常分支反复遗漏、某类指标反复缺少口径。这些记录可作为下一轮需求整理时给AI的补充提示，也可作为清单本身的修订依据，让清单随团队实际使用逐步收敛到最需要检查的项。

常见问题

AI整理稿里新增了原始需求没有的内容，应该直接删掉吗？

先分类再处理。新增内容可能是对原始需求的合理补充，也可能是AI基于通用知识的推断。核查时把新增内容单独列出，交由需求提出人确认：确认为合理补充的保留并注明来源；无法确认的从整理稿中移除或标注为待确认，不进入本期需求范围。直接删除会丢掉有价值的补充，直接保留则可能把推断当成需求写入。

来源材料不全时，清单还能用吗？

可以用，但要区分两种结论。有来源材料时，核查能判断约束“是否写对”；缺少来源材料时，只能判断“是否写明”，这类检查项在清单中标注为证据不足，并记录需要补充的材料和责任人。证据不足项不直接算通过，涉及阻断项的，需补齐材料后复检。

待补项和阻断项怎么区分，会不会所有问题都变成阻断？

阻断项只保留会导致评审无法继续的根本性缺口，例如核心功能边界或范围外内容缺失、非功能指标无量化口径、合规要求无来源、数据分类与敏感信息处理未写明、验收标准不可判定。其余问题记为待补项，填写责任人和补充期限即可。把阻断项控制在少量关键项，清单才不会变成事事卡关的工具。

复检时需要把整张清单重新过一遍吗？

不需要。复检只针对未通过项及其关联项，例如补充了性能指标口径后，复检性能与响应时间、指标可测量性两项即可。复检结论更新到同一份核查记录中，保留首次核查与复检的时间，便于评审时看到问题从提出到关闭的过程。

核查记录放在哪里，评审时才找得到？

关键是让记录与需求条目保持关联。可以在协作工具中把每个需求条目对应为一个工作项，核查清单作为工作项下的检查项或关联文档，结论和状态随工作项流转。ONES 的需求管理与 Wiki 页面可以承载这类记录，ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等工作上下文，围绕PRD质量检查和需求智能生成提炼待澄清问题与拆解建议，其AI能力基于ONES权限体系执行，输出过程可追踪、结果可审计。具体承载形式和字段配置以实际环境为准。