业务人员
当前需求属于哪个分支，需要提交哪些信息？
选择需求类型确认料号与产品填写条件字段检查附件与必填项保存并回填
围绕使用者的任务组织信息
评审人员
产品、性能、规格和附件能否支持本次判断？
填写者
为什么校验未通过，如何回到未完成的内容？
实际界面与跨端分工
关键设计判断
先确定业务分支
开发评审与客户需求评审采用相近视觉规则，但业务条件不同，不能简单复制同一张表。
分组表单随业务类型显隐，保留产品、性能、规格等核心对象。
按信息关系分组
把业务报价、需求单位和年需求放在相同上下文，减少字段之间的来回查找。
筛选用于定位历史单据，新增和详情用于完整记录，避免把两类任务混在一起。
把校验反馈落在字段附近
必填、附件和条件字段需要在提交前可解释。
指出缺少的内容，保留已填信息，让使用者可以补充后继续。
保存与回填构成完整体验
提交前往往需要多次核对。只展示成功弹窗无法说明信息是否保留。
提供保存与重新打开后的回填路径，明确原型匹配与审批的演示边界。
进入交互原型
本机保留字段及弹出逻辑工作表、两个评审原型和历史验收记录。案例用界面说明规则，不公开原始业务规格文件。
展示范围：开发评审和客户需求评审页面。字段规则来自工作表与设计原型；真实审批、上传及料号服务不在公开原型内。