表单有条件显示和必填要求，Agent 怎样核对 PRD 是否说完整

动态表单不能只看选中某个选项时截图对不对。Agent应将字段显示、允许输入、必填和旧值处置分别展开，检查用户来回切换选项后，提交数据还表达什么。结果是一份字段联动规格，帮助产品、设计和开发讨论同一条分支。

四种规则不要共用一个勾选

显示回答用户能不能看到；可编辑回答用户能不能改变；必填回答什么条件下必须提供；隐藏残值回答已经填过的内容后来怎么办。四者可能不同。例如邮寄地址在自取时隐藏，但它是否保留在草稿、是否参与提交、是否继续出现在导出里，属于不同问题。

为每个字段登记稳定标识和业务含义，再列触发字段、取值条件、目标规则及转换后的处理。界面名称可以变化，规则仍需指向同一字段。条件不完整时写明缺少哪一个取值，而不是把所有未描述选项都当默认分支。

官方机制说明1：dependentRequired不是双向依赖；if/then/else可表达条件约束，条件本身仍须业务确认。

结构约束可帮助表达一部分条件，但不会替产品决定隐藏后的数据是否仍有效。尤其不能把“有说明就允许附件”误写成“有说明就必须上传附件”。依赖方向应有明确来源。

合成输入1。 选邮寄时地址必填，改自取后PRD没说旧地址是否保留

预期处置：标记残值处置待定，不擅自删除

合成输入2。 勾选需投影仪后设备数量必填，却允许数量0

预期处置：指出条件与数量语义需联合评审

合成输入3。 有附件就要求说明，但有说明不强制附件

预期处置：明确单向依赖，生成正反方向样例

邮寄改自取的预期是暴露待决定事项，未批准前不能擅自清空，也不能默认继续发送地址。投影仪数量说明显示与数值含义要联合检查：若0表示取消设备，界面选中状态如何解释；若不允许0，应回到已有规则，而不是模型临时增设下限。第三例专门检验依赖是否被错误反向化。

产品确认数据的含义，设计确认提示与输入路径，开发确认提交内容和服务端规则。工作表可以一行表示一条条件规则，再用场景表表示选项切换顺序，避免把所有步骤塞进一个复杂公式。原值、变更后的选择和期望提交字段分别记录，人工才看得出数据是否被悄悄丢掉。

如果现有表单工具已提供条件显示，定制项目不必重写它。助手可先读取获准导出的字段规则与产品说明，生成二者的差异和未定项。仅靠界面截图很难知道隐藏数据的提交行为，缺少配置或接口约定时应标为证据不足。

按附件先填邮寄地址、再切自取，核对工作表是否保留了这段历史和待定处置；再从自取开始，检查它不会错误要求地址。两条路径最终选择相同，历史输入却不同，这正是联动规格需要交代的地方。正式观察由授权测试人员填写，不用静态规则表代替运行结果。

关闭一条缺口时，需要同时指向更新后的需求和相应字段规则。只在评审会上说“这个按常规处理”，接手开发的人仍无法判断提交该保留什么。定制交付应让这种常规变成可以核对的明确决定。

评审者可在工作表中画出“邮寄→填地址→自取”的顺序，分别记录界面可见值、草稿保存值和拟提交值。三列不要求永远相同，但差异必须有业务解释。若只保存最终截图，就看不到地址从哪里来，也无法确认它是否会跟随自取申请进入后续材料。

投影仪分支同样需要把选中含义与数量含义并排。规格暂缺时，助手输出的问题应指向这两个变量，而不是笼统说表单有错。单向附件依赖则用有说明无附件的输入核反方向，确认候选规则没有多加义务。附件保存的预期是这些审阅动作，用户填写真实观察后才能关闭对应缺口。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。