需求材料生成后，需要团队检查它是否准确表达了业务目标，并能指导后续实现。审阅时，先确认材料属于哪个需求项，再核对规则、页面行为和技术方案是否一致。
本篇覆盖两个阶段：提交 IT 准入前，审阅和调整提案、验收标准与原型；需求项通过准入后，审阅和提交技术设计。
业务人员主要确认目标、规则和使用体验，研发人员主要确认方案与工程约束。需要提交或确认时，由具备相应操作权限的成员完成。
找到对应材料
页面中的 “验收标准” 承载需求的业务规则与场景；技术设计会话中的 “系统设计” 展示当前详细设计文档。文档预览用于阅读，内容调整主要通过对应会话提出，再检查更新后的产物。
开始审阅前，核对工作空间、需求项名称和材料来源。如果同一需求包含多个需求项，应分别检查，避免把另一项的规则或原型当作当前材料。
审阅规格：检查行为是否明确
先阅读提案，确认业务目标和本期范围，再逐项查看验收标准。可以围绕以下问题检查：
- 使用者、业务对象和操作场景是否明确？
- 规则是否存在歧义，多个条件如何组合？
- 正常结果、空结果和异常处理是否都有说明？
- 关键边界是否清楚，例如日期范围、人数去重和权限范围？
- 每项结果能否用约定的样例数据或操作步骤检查？
沿用会员人群筛选示例，如果规格写着“查询失败时显示 0 人”，需要先确认这是否混淆了“成功统计但没有匹配会员”和“暂时无法统计”两种情况。
可以在尚未提交的需求会话中这样提出修改：
请修改“覆盖人数预估”的异常场景：只有统计成功且没有匹配会员时才显示 0 人。统计失败时，显示“暂时无法获取覆盖人数”，保留筛选条件并提供重试，本次人数显示为不可用。请同步更新相关规则和验收标准，并检查原型是否表达了这两种状态。
收到回复后，重新打开验收标准，确认修改已经体现在材料中。规则与场景的具体写法，可参考如何写清业务规则和验收标准。
审阅原型：按使用过程检查
打开 “原型”，按用户的操作顺序检查页面。存在多个原型时，先选中本次要审阅的原型，并确认它对应的需求项和场景。
以人群筛选为例，可以检查：
- 能否理解每个筛选条件的含义，默认状态是否符合规则。
- 用户如何发起筛选，修改条件后如何重新获取人数。
- 有匹配结果、无匹配结果和统计失败时，页面分别怎样展示。
- 提示是否说明下一步可采取的操作，已填写的条件是否按约定保留。
原型中已经实现的交互可以直接操作；缺少的状态，可以在需求会话中要求补充演示。原型中的示例人数用于说明交互，真实数据计算仍需在后续实现和验证中检查。
提出页面修改时，注明 位置、当前问题和期望行为。例如：
在“覆盖人数”区域，目前统计失败后仍显示上一次的人数。请增加失败状态，显示暂时无法获取人数及重试入口；保留上方筛选条件。请与当前验收标准保持一致。
修改后再次走一遍受影响的操作流程，并核对文字、按钮和状态展示。
调整支持配置的原型主题
部分原型提供 “主题配置”。在自己的需求草稿中，如果出现该入口，可以打开它，调整模板提供的颜色等选项，在预览中检查效果后点击 “确定” 保存。
点击 “重置” 会将配置恢复为模板默认值；确认要采用这些值时，仍需点击“确定”保存。“取消”会放弃本次未保存的调整。
主题配置只作用于当前选中的原型。页面结构、业务流程和交互规则的修改，需要在会话中说明。需求已经提交后，草稿原型的主题修改不可再保存，应结合当前需求状态处理后续变更。
审阅技术设计：对照需求和现有项目
技术设计以具体需求项为单位开展。具备交付权限的成员可以从首页 “技术设计” 入口选择当前工作空间中已准入、尚未进入交付批次的需求项，进入对应会话。
进入后，先核对提案、验收标准和原型，再查看 “系统设计”。如果设计尚未生成，可在会话中要求基于当前需求项和项目仓库生成设计，并保存到 design.md。
研发人员审阅时，重点检查：
技术设计中的 “文件” 页签可以查看关联仓库中的文件；在可继续输入的会话中，也可以把需要讨论的仓库文件加入会话引用，帮助定位具体实现上下文。
如果发现方案与规格不一致，应先明确需要调整哪一方。例如，已确认的业务规则要求按会员去重，而设计采用订单数统计，就需要修正实现方案。
可以在技术设计会话中提出：
当前设计按订单数统计覆盖人数，与已确认的按会员去重规则不一致。请结合当前仓库的数据模型和已有查询能力修正方案，说明会员唯一性的判断依据，并补充重复消费场景的验证方式。请将结果更新到 design.md。
设计更新后，在“系统设计”中重新检查对应段落，以及接口、数据处理和验证方案是否一起调整。
确认并提交当前技术设计
设计正文生成并保存后，页面会提示：“确认 design.md 后提交技术设计。”
完成审阅、解决影响实施的关键问题后，由具备交付权限的成员点击 “提交技术设计”。
提交成功后，可以从设计状态或页面提供的 “生产实施” 入口继续后续工作。是否可以纳入交付批次，还取决于需求项和项目的实际条件。
如果提交时出现 “设计已更新，已刷新最新内容，请重新提交。”，说明材料在你查看后发生了变化。应先审阅刷新后的内容，再提交当前设计。
设计正文再次更新并保存后，原有提交状态会重置，需要重新审阅和提交。 团队应根据当前页面状态判断是否已经完成确认。技术设计提交确认的是方案，代码实现、测试和业务验收在后续阶段继续进行。
每次修改后，核对受影响的材料
可以按以下顺序完成一轮修改：
- 定位问题：说明需求项、材料名称及具体段落或页面位置。
- 给出依据：指出已确认的规则、样例结果或项目约束。
- 明确目标：描述期望变化；涉及新增范围时，先与负责人确认。
- 检查更新：打开最新产物，核对修改内容及相关场景。
- 完成确认：按当前阶段执行需求提交或技术设计提交。
例如，日期范围从“包含结束日全天”调整为其他口径时，应同时检查规格中的日期规则、原型中的说明、技术设计中的时间处理，以及验收样例的预期结果。
需求提交 IT 准入后，原起草会话会转为只读。后续需要改变业务范围或规格时，先查看需求详情，与负责评审的成员确定处理方式。已经进入交付批次的工作，还需结合当前工作流阶段评估影响。
常见问题
AI 已经说修改完成，页面仍是旧内容。
先核对当前工作空间、需求项和产物，再等待本次处理结束并重新载入页面。如果仍未更新，在对应会话中指出未变化的段落，要求确认材料是否已保存；同时留意页面中的保存或加载错误。
原型中没有“主题配置”。
该入口取决于原型是否提供可配置的主题选项。需求仍在起草时，可以在会话中描述希望调整的外观或交互，再检查更新结果。
“提交技术设计”不可用。
检查“系统设计”是否已经生成并保存、当前设计是否已提交，以及账号是否具备相关权限。页面提示 design.md 尚未生成时，需要先在技术设计会话中完成生成和保存。
规格、原型和设计相互矛盾，应该以哪份为准？
先找出冲突的业务决定，由业务负责人和研发人员共同确认预期行为。随后在允许修改的阶段更新受影响材料，并重新完成相应确认。实际实现情况还应结合当前仓库、运行环境和验证结果检查。