目标与实际使用回看
检查真实任务能否完成，而不是确认产物是否像某份文档。核心路径可用时即可进行，不必等所有技术检查结束；有数据损坏或外部副作用风险时，优先使用隔离环境，涉及真实扣款、生产写入或用户服务变更的验证先核查明确授权。
回到原始问题
从共同任务上下文读取用户目标、范围与当前决定，必要时回看用户原始请求。不要只读取最后一份设计或测试清单。
选择一个代表性任务，说明输入从哪里来、用户要作什么判断、最终拿到什么结果。任务包含的准备、导入、操作、结果使用与恢复都应纳入观察，不能只测其中最好演示的一小段。
例如，副本核对工具不仅要解析清单，还要让使用者取得清单、辨认异常、找到待处理文件。解析测试全绿，并不能证明整条核对路径比原方法更可用。
观察使用，而不是提示答案
Agent 可以执行可观察的操作，检查业务结果和明显的体验障碍，不把“是否有用”的全部责任推到最后由人兜底。涉及真实工作习惯、审美取舍或长期价值时，需要使用者反馈；没有反馈就明确未知。
让目标使用者尝试任务时，避免逐步告诉他该点哪里。关注：
- 能否找到入口、理解信息、完成主要动作并正确识别结果。
- 是否还需绕路、重复劳动或借助未说明的外部步骤。
- 与本次相关的错误发生后，能否保留必要信息并恢复。
- 原有阻碍是否减少；有基线时比较实际耗时、误操作或结果质量。
这些是观察方向，不是必须逐项提问的问卷。只观察一次、不具备真实数据或用户未实际操作时，保留相应结论边界。“挺好”“可以”可以表达接受意愿，但不能替代实际使用证据。
区分偏差、缺陷与新需求
- 不满足已同意的要求，或主路径出现真实障碍：说明影响，修正后复核受影响部分。
- 要求本身错误或互相矛盾：在共同位置修正有效决定；改变重要业务取舍前请用户确认，不让各域留下不同裁决。
- 原范围外的新偏好或新功能：作为建议说明，不临时增加拒收条件。
- 非阻塞限制：说明具体影响与规避成本，由有权接受风险的人决定，不默认把所有瑕疵拖到下一轮，也不要求无缺点才能交付。
给出有边界的结论
把实际完成的任务、支撑证据、仍有的限制整合到共同位置，不另写一份“业务验收报告”。代码测试通过、用户愿意接受、实际使用价值成立是不同结论，应分别表达。
需要修正时按问题调用产品、体验或工程能力，修复后针对变化复核；不要求重走全部 Skill。验收通过不自动合并、部署或发布。持续使用的价值判断可使用 product-design，但不强制所有任务进入固定观察期或搭建漏斗系统。