核对交互流程与页面状态

这个场景能帮你做什么

设计稿展示了成功页面，却可能没有说明等待、失败、空数据或无权限时显示什么。WorkBuddy 可以根据流程和可读的页面说明整理状态表，检查交互是否闭合。

开始前需要准备什么

提供用户任务、流程、页面文字说明、角色权限和业务规则。可提供组件清单或前端代码；只有图片时先由设计人员补充文字，本流程不默认识别画面和点击界面。

具体怎么做

第一步：按用户任务列页面路径

将入口、操作、页面跳转、数据变化和退出放到同一条路径，保留规则依据。不同角色路径分别整理，不从一个演示页面推断所有权限。

第二步：补齐状态表

逐页检查初始、加载、空数据、成功、失败及权限限制。不是每页都需要全部状态，应说明哪些适用、依据是什么，避免机械增加无用页面。

第三步：检查前后状态与动作

核对点击后发生什么、重复操作如何处理、取消后回哪里、失败能否继续。外部动作状态未知时不能直接显示失败并允许重复提交。

第四步：输出设计补问与测试线索

将缺失状态、冲突规则、文案和需要产品确认的分支列出。确认后的状态可转成测试用例，仍需实际交互验证。

可以直接交给 WorkBuddy 的完整要求

依据附件流程与页面文字建立“页面—角色—前置状态—动作—结果状态”表。
检查加载、空数据、失败、无权限、取消和重复操作等适用分支，缺规则就补问，不自行决定业务逻辑。
核对返回、重试和退出是否闭合，列状态冲突及对应测试场景。只检查可读资料，不宣称已经操作原型或评估视觉效果。

完成后会得到什么

一张页面状态与转移表，以及产品、设计和测试需要补齐的问题。

结果应该怎么检查

按真实用户任务从入口走到结束，检查是否有无法离开或无法恢复的状态。逐项核对权限、提交结果和提示文案是否一致。

遇到这些情况怎么处理

只有成功演示时先列缺失问题。不同资料给出不同路径时确认版本。无法从文字判断视觉与可用性的问题交设计人员实际验证。

哪些必须人工决定

产品确认业务分支，设计确认交互体验，测试执行验证。AI 的状态表不能替代用户测试或实际页面验收。