原型页面和需求文档说法不同，Agent 怎样准备逐控件差异单

原型与PRD不一致时，Agent先要证明比较的是同一个控件、同一个用户动作和同一版设计，再逐项列差异。把两个文件各自总结一遍没有解决问题。交付应让产品人员直接看到原型标注、需求条款、差异含义和需要决定的事项。

先取可定位的材料

原型可以由设计人员导出页面和控件标注表，不假定任意截图都能读出隐藏交互。输入包括页面节点、控件标识、显示文字、限制值、动作去向和版本。PRD则保留条款编号与适用角色。页面中两个按钮都叫“确定”，需要依赖节点和上下文区分，不能只按文字配对。

先建立明确对应，再做内容比较。找不到对应条款的控件列为未映射；条款有要求而页面没有相应入口，也是一种独立缺口。未映射不必然是遗漏，它可能属于复用组件或另一个页面，但解释必须来自提供者。

官方机制说明1：工作项表达需求，Epic/Feature聚合场景；本文的切分与缺口检查是拟设计方法。；官方机制说明2：Rule、Given/When/Then、Scenario Outline与Examples可以表达规则和具体示例，不自动证明业务规则正确。

工作项和行为场景可以承载关系及预期，本文的逐控件对照是拟定制设计，不是平台自动识图结果。已有设计工具的链接仍可使用，额外工作聚焦于两份材料的语义对照和评审记录。

合成输入1。 原型预约人数上限8，PRD上限10，控件ID人数输入

预期处置：并列两值及定位，等待产品裁定

合成输入2。 原型有取消按钮，PRD仅描述新建预约

预期处置：标为缺失行为，不推断取消必然支持

合成输入3。 PRD要求取消原因必填，原型隐藏说明字段

预期处置：生成该控件缺口与待核验交互场景

人数8与10不仅是一个数字变动，它关系到用户能否提交9人的预约。取消按钮没有文字规格，则缺少动作前置、结果和例外；不能因为画了按钮就推断后台必然支持取消。原因字段的例子则需核对隐藏是始终隐藏，还是点击取消后再出现，输入材料未交代时保留这个区别。

如果页面标注写8，PRD写10，会议草稿也写8，不能简单以两票对一票确定8。产品负责人需要说明哪个决定对本次实现有效，并更新另一份设计。差异单保留原值和决定依据，避免原型团队改完以后再也看不到这次争议。

每个差异可附一个最小观察任务：输入9人、尝试取消、检查原因字段。这些是评审问题或测试草案，实际行为由后续验证填写。它们帮助业务理解影响，不把设计一致当成软件已经正确。

先从差异单打开原型节点和PRD条款，检查位置仍有效；再抽取一个未报差异的控件，确认不是因为漏映射才“没有问题”。已有复用组件若不在本次原型导出范围，应列出外部依赖，不用一个空格表示已核过。

定制前值得准备的是一小套同时含明确一致、具体冲突和无法对应的设计材料。若所有控件都有稳定编号，处理可以更多依赖规则；需要模型帮助的部分通常是动作含义和跨文档叫法差异。双方应按这个结构决定实现范围，而不是笼统采购一个“自动审原型”的功能。

人数限制争议关闭时，可记录决定采用8或10、决定所适用的页面与角色、原型和条款各自更新后的定位。采用值仍由产品填写，助手只检查两个表达是否都响应了同一个决定。取消按钮的缺口则可能要求补行为规格，而不是改按钮文字；原因字段可能只需补出现条件，两者不能统一处理成改UI。

这也决定了差异单的分类方式：数值不一致、动作缺说明和条件呈现不清分别交给不同窗口。开发接到材料后能知道要等哪项决定，而不必重新翻整份设计。附件中的实际结果、确认人及证据位置用于保留后续核对，当前没有在任何原型软件操作或读取隐藏交互。

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