## 任务目标
请审查需求是否具备进入研发或接受变更的条件。给出可操作的评审问题与责任建议。
以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
需求评审对象：
需求与关联资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 核对需求和设计材料的版本、日期与变更记录，检查是否误用旧资料评审新需求。
- 沿相关代码与接口追踪历史数据、统计、导入导出和租户权限的可能影响，区分已证实与待验证。
- 查设计、前后端任务、测试准备及依赖关系，找出无人承接或交付条件不一致的环节。
### 可采用的默认处理
- 默认只读评审，不推进工作项、不替他人签署意见，也不发送上线通知。
- 优先级先采用团队定义，缺少定义时按业务损失和返工影响给出带理由的建议。
- 责任用已知岗位表达，人员或时间不足时列待分配，不因材料不齐停止对已有需求逐项审查。
### 必须有依据的事项
- 同一核心业务规则、权限或数据口径存在互相冲突的正式材料时，不能替业务选定其中一版。
- 变更是否已经获准、适用版本或验收条件不明且影响研发准入时，只能给有条件评审建议，不能宣布已经批准。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 没有代码时完成需求、设计与接口材料的一致性审查，列明尚需实现证据确认的影响。
- 没有上一版本时完成当前需求完整性、问题表和关闭条件，不编造前后差异。
## 执行要求
评审内容和节点以团队现行规则为准，下面的检查维度用于补齐业务问题，不替代团队的决策流程。
1. 确认审查对象、版本、材料日期和本次变更范围，对比前后差异。材料不完整时列出实际已读内容，避免以旧版设计稿审查新版需求却不说明。
2. 检查目标、角色、输入、业务规则、状态、失败恢复和验收条件是否齐备。每个问题指出具体条目及会影响的用户操作，避免只有“建议完善”等泛泛意见。
3. 分析变更对历史记录、统计口径、接口兼容、导入导出、权限和跨组织数据的影响。分别列出已证实影响、需查代码或数据才能确定的影响。
4. 检查设计、接口、前后端任务与测试准备是否相互匹配，找出责任空白和依赖顺序。没有人员和工期证据时只写责任角色，不替团队承诺完成日期。
5. 按业务损失与返工范围确定问题优先级，区分必须明确后才能开发的问题、可并行补充的问题和优化建议。优先级定义优先使用团队既有规则。
6. 给出逐项处理建议、补充材料、责任角色和复核条件，并形成进入研发、补充后复核或暂不具备条件的建议。未获得真实评审意见时不能标注任何人已同意。
## 交付与验收
输出：评审范围与材料、变更摘要、问题表、影响关系、待办清单、评审建议及其条件。问题表含编号、依据位置、具体影响、优先级理由、责任角色、关闭条件。
验收：每条问题可定位和复核；重大规则与权限影响没有被界面细节掩盖；结论基于当前版本；建议与团队真实决策明确区分。
信息边界：只进行材料评审，不自动推进工作项状态、替他人签署意见或发出上线通知；未知事实应保留为问题，不能用行业惯例冒充已确认规则。
### 本条完成检查
- 问题均有具体材料位置、业务影响和复核条件，避免泛泛要求补充。
- 历史数据、统计、权限及接口兼容影响与界面问题分清轻重，已知与推测明确区分。
- 结论对应当前版本，并区分分析建议、团队决策和待确认条件。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [云效 Projex：需求评审](https://help.aliyun.com/zh/yunxiao/user-guide/requirements-review)
- [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)
