AI需求约束检查表包含哪些检查项

AI需求约束检查表围绕五类检查项组织：功能约束、非功能约束、合规与安全约束、依赖与外部条件、验收条件。每项都要写明通过标准、证据来源、负责人和检查时点，并标出阻断项。它适合在AI生成需求初稿后、需求评审前和变更确认时使用，用来判断哪些内容可以直接通过、哪些需要退回补充。本文给出可直接套用的检查表结构，并说明复核AI输出时的判定与关闭规则。

要点总览（TL;DR）

• AI需求约束检查表按五类组织：功能约束、非功能约束、合规与安全约束、依赖与外部条件、验收条件，每项写明通过标准、证据来源、负责人和检查时点。
• 功能约束重点查核心操作的输入输出、边界与异常分支、角色权限差异、状态流转规则；非功能约束要求性能、可用性、兼容性等指标有量化口径。
• 合规与安全约束判定要保守：AI输出未提及某项要求时判为待补，由合规对接人确认是否适用，并写清查证对象和期限。
• 复核按逐项判定、退回补充、复检关闭、进入评审四步执行，判定结论分为通过、不通过、待补三种，并留下证据位置记录。
• 合规安全缺失、验收条件不可判定、关键依赖未确认属于阻断项，未关闭前不进入评审或开发；整表完成需五类检查项均有结论、阻断项关闭、非阻断项有责任人。

谁在什么时点使用这份检查表

这份检查表解决的是“AI写出来的需求稿能不能进入下一环节”的问题，使用对象包括三类角色：需求提出人负责确认业务意图和约束来源，AI输出复核人负责逐项比对与记录判定，评审人负责确认阻断项已关闭并决定是否放行。三类角色可以由同一人兼任，但判定记录要能区分是谁在什么时点做出的判断。

使用时点有三个。第一是AI生成需求初稿之后，此时检查表用于发现遗漏和含糊表述；第二是需求评审之前，用于确认进入评审的材料已经补齐；第三是需求变更确认时，用于检查变更是否引入新的约束缺口。三个时点共用同一张表，区别在于检查范围和判定严格程度：初稿阶段允许较多“待补”，评审前要求阻断项全部关闭。

使用前需要准备三类输入：原始需求描述（业务方提供的背景、目标与已知限制）、AI输出稿（待复核的需求文本）、已有约束清单（组织内的安全规范、接口规范、历史遗留限制等）。缺少原始需求描述时，复核人无法判断AI输出是遗漏还是合理省略，应先补齐再开始检查。

角色	介入时点	主要动作	产出
需求提出人	AI生成初稿后	确认业务意图、补充原始约束	约束来源说明
AI输出复核人	初稿后、评审前、变更时	逐项判定并记录证据	判定记录表
评审人	评审前	确认阻断项关闭、签署放行	评审结论

功能约束检查项：AI是否漏掉必须做的事

功能约束检查的目标是确认AI输出把“系统必须完成什么”写清楚了。AI常见的问题是描述主流程流畅、遗漏分支和角色差异，因此检查项要围绕可验证的完整性设计，而不是看文字是否通顺。

检查项	通过标准	证据来源	负责人	检查时点
核心操作与输入输出	每个核心操作都写明触发方式、输入字段、输出结果和处理后状态	原始需求描述、业务流程说明	需求提出人	初稿后
边界条件与异常分支	空值、超限、重复提交、失败重试等情形有明确处理方式，或标注“待确认”并说明原因	历史问题记录、业务方补充说明	复核人	初稿后
权限与角色差异	每个操作标明可执行角色，不同角色的可见范围和操作范围有区分	权限矩阵、组织角色定义	复核人	评审前
状态流转与业务规则	关键对象的状态、流转条件、回退规则完整，规则之间无冲突	状态机说明、业务规则文档	需求提出人	评审前

判定时逐项对照证据来源。例如AI输出写了“提交后进入审核”，但没有说明审核不通过时回到哪个状态、由谁修改，这一项就判为“不通过”，退回补充状态回退规则。若AI输出对某条规则写了“具体阈值待业务确认”，可判为“待补”，并记录补充责任人和期限。

非功能约束检查项：性能、可用性与可维护性

AI生成的需求稿容易把篇幅集中在功能描述上，质量属性往往只剩一句“性能良好”或完全缺失。非功能约束检查项要求把这类表述转成有口径、可验证的条件，无法量化的要明确标注待确认，不能以模糊形容词通过。

检查项	通过标准	证据来源	负责人	检查时点
性能与容量指标	响应时间、并发量、数据量等有数值和统计口径（如峰值、平均值、统计时段）	业务量预估、现有系统监控数据	需求提出人	评审前
可用性与容错要求	写明可接受的中断时长、降级方式、故障恢复要求	运维规范、服务等级约定	复核人	评审前
可维护性与可扩展性	对配置化、扩展点、日志与监控有明确要求，或说明本期不涉及并记录理由	技术方案、架构约束	复核人	评审前
兼容性与运行环境	支持的终端、浏览器、操作系统版本、部署环境有明确范围	现有用户环境统计、部署规范	需求提出人	评审前

通过标准的关键是“可测量”。AI输出写“页面加载要快”，判为不通过；改写为“在现有用户网络条件下，首屏加载时间不超过约定阈值，阈值由业务方确认”可判为待补，阈值确认后转为通过。可用性要求同理，需要写明统计周期和计算方式，否则无法在验收阶段判定。

合规与安全约束检查项

合规与安全约束是AI输出最容易整段缺失的部分，因为原始需求描述里往往只提业务目标。检查时要把数据流向、权限边界和审计要求逐项对照组织规范，无法确认的合规条款标注待查证，由对应责任人给出结论。

检查项	通过标准	证据来源	负责人	检查时点
数据采集、存储与使用范围	写明采集哪些字段、存储位置与期限、使用目的和共享对象	数据清单、隐私政策	需求提出人	评审前
敏感信息与权限控制	敏感字段有脱敏、加密或访问限制要求，权限按最小必要原则描述	安全规范、权限矩阵	复核人	评审前
审计日志与可追溯	关键操作记录操作人、时间、对象和结果，日志保留期限明确	审计要求、运维规范	复核人	评审前
行业或组织合规要求	相关条款已列出并标注适用性，未确认的标注“待查证”及责任人	合规部门意见、行业规范	合规对接人	评审前

这一类的判定要保守：AI输出没有提到某项合规要求，不能直接认定不适用，应判为“待补”，由合规对接人确认是否需要纳入。标注“待查证”的条目要写清查证对象和截止时间，避免在评审时仍处于悬空状态。

依赖与验收条件检查项

AI输出常把需求写成孤立的功能描述，上下游接口、第三方服务和验收方式被省略。这一节检查的是需求能否被独立理解和独立验收：依赖写不清，开发排期无法确定；验收条件写不清，交付时无法判断是否完成。

检查项	通过标准	证据来源	负责人	检查时点
上下游系统与接口依赖	列出依赖系统、接口方向、数据格式和联调时间要求	接口文档、系统清单	需求提出人	评审前
第三方服务与数据来源	写明服务提供方、使用方式、数据来源的合法性与稳定性说明	采购记录、服务协议	复核人	评审前
验收条件可判定	每条验收条件有明确输入、预期结果和判定方式，可被第三方复现	测试用例草案、业务确认记录	需求提出人	评审前
未确认依赖标注	尚未确认的依赖标注“待补”，写明责任人和确认期限	依赖清单、会议记录	复核人	每次复核

验收条件的写法可以直接检验：把条件交给未参与需求讨论的人，对方能否据此判断通过与否。若条件写成“操作流畅、体验良好”，判为不通过；若写成“提交成功后列表在约定时间内显示新记录，字段值与输入一致”，则可判为通过。

如何用这张表复核AI输出

复核按“逐项判定—退回补充—复检关闭—进入评审”四步执行，每一步都留下记录，避免同一问题反复讨论。

1. 逐项判定。复核人按五类检查表逐条对照AI输出稿，给出“通过／不通过／待补”三种结论之一。判“通过”必须写明证据位置（如原文第几节、引用的规范条款）；判“不通过”写明缺失内容；判“待补”写明补充责任人和期限。
2. 退回补充。不通过项汇总后退回给AI输出责任人修改，或由需求提出人补充原始信息后重新生成。退回时附上判定记录，说明具体缺什么，避免笼统要求“再完善一下”。
3. 复检与关闭。补充完成后由原复核人复检，只复核未通过项及其关联项，确认后把状态改为“通过”并记录关闭时间。复检发现新问题的，重新进入退回流程。
4. 进入评审。阻断项全部关闭、非阻断项有明确跟踪责任人的，检查表随需求稿一并提交评审。评审人查看判定记录即可了解哪些内容已核实、哪些仍待跟踪。

判定记录建议采用固定格式：检查项编号、判定结论、证据位置、问题描述、责任人、期限、关闭时间。这份记录与需求稿放在同一处管理，后续变更时可以对照历史判定快速定位受影响项。在ONES中，需求可作为工作项承载，检查表作为关联文档随工作项流转，判定结论对应到工作项状态或检查项记录，评审人从工作项视图即可看到阻断项是否关闭、待补项由谁负责，减少在多个渠道之间核对状态的成本。

阻断项与完成条件

并非所有未通过项都需要停止推进，但以下三类必须作为阻断项处理，未关闭前不进入评审或开发：合规与安全约束中数据范围、敏感信息控制、审计要求缺失的；验收条件无法判定、无法被第三方复现的；关键上下游依赖或第三方服务未确认的。这三类问题一旦带入开发，返工成本高，且可能在交付阶段才暴露。

类别	阻断条件	关闭要求
合规与安全	数据范围未界定、敏感信息控制缺失、审计要求未覆盖	合规对接人给出书面结论并记录
验收条件	存在无法判定或无法复现的验收条件	改写为可测量条件并经需求提出人确认
关键依赖	核心上下游接口或第三方服务未确认	依赖方确认接口或服务可用性，记录确认时间

非阻断项包括表述不够精炼、次要分支待细化、非关键环境兼容性待确认等，记录后由责任人跟踪，可以随需求进入评审，但要在评审结论中列明跟踪人和期限。非阻断项不能在无人负责的情况下默认关闭。

整表完成的判定条件是：五类检查项全部有判定结论；阻断项全部关闭并有证据记录；非阻断项均有责任人和期限；需求提出人、复核人、评审人完成签署；检查表与需求稿一并归档。签署和归档保证后续变更时有据可查，也便于在复盘时统计哪类检查项最常出现问题，反过来改进AI生成需求时的提示内容和人工复核重点。

常见问题

AI输出看起来写得比较完整，还需要逐项对照检查表吗？

需要。AI生成的需求稿通常主流程描述流畅，遗漏往往出现在分支条件、角色差异和合规要求上，仅凭通读难以发现。逐项对照的价值在于把“看起来完整”转成可核验的判断：每个检查项都要指出证据位置，找不到证据的判为待补。复核人可以先快速通读一遍，再按五类检查表逐条定位，重点看异常分支、权限边界和数据范围这几类容易被省略的内容。

检查项判为“待补”时，需求稿能不能先进入评审？

取决于待补项是否属于阻断项。合规与安全约束缺失、验收条件不可判定、关键依赖未确认这三类属于阻断项，未关闭前不进入评审或开发。其他待补项，例如次要分支待细化、非关键环境兼容性待确认，可以随需求进入评审，但要在评审结论中写明跟踪人和期限，不能默认关闭。判定记录里要区分阻断与非阻断，避免评审时把两类问题混在一起讨论。

原始需求描述本身就不完整，检查表还能用吗？

可以先补齐原始输入再开始检查。缺少原始需求描述时，复核人无法判断AI输出是遗漏还是合理省略，容易把合理省略误判为不通过。实际操作中，可以先由需求提出人补充业务背景、目标和已知限制，形成约束来源说明，再对照AI输出稿逐项判定。确实无法补齐的部分，在对应检查项上标注待补并写明责任人和期限，作为待补项跟踪，不直接判为通过。

非功能约束里的指标，业务方给不出具体数值怎么办？

可以判为待补，但要写清补充口径和责任人。通过标准的关键是可测量，例如响应时间需要数值和统计口径（峰值、平均值、统计时段），可用性需要统计周期和计算方式。业务方暂时给不出数值时，复核人应记录需要确认的指标项、参考依据（如现有系统监控数据、业务量预估）和确认期限，待数值确认后转为通过。把“性能良好”这类表述直接判为通过，会在验收阶段造成无法判定的问题。

检查表记录和需求稿分开管理，会不会导致状态对不上？

分开管理时容易出现判定结论与需求状态不同步的问题，尤其是变更后历史判定难以对照。较稳妥的做法是让检查表与需求稿放在同一处管理，判定记录包含检查项编号、结论、证据位置、责任人、期限和关闭时间。在ONES中，需求可作为工作项承载，检查表作为关联文档随工作项流转，判定结论对应到工作项状态或检查项记录，评审人从工作项视图即可看到阻断项是否关闭、待补项由谁负责。