product-ui-risk-review

产品 UI 风险审查

目的

使用这个 skill 审查资产、账户、授权、签名确认、交易提交、跨系统流转等产品 UI 流程是否足够清楚、可信、可恢复，并且适合交给真实用户使用。重点关注用户点按钮前是否理解后果、关键状态是否完整、失败后是否能恢复、风险文案是否具体，以及高风险操作是否容易误触或重复提交。

默认工作权限是只审查：输出发现和建议，NEVER 编辑文件，除非用户明确要求修复、实现或改写。 如果用户意图在「审查」和「完善/修复」之间模糊，MUST 默认走审查模式，并在输出中说明没有改文件。

这个 skill 主要做两件事：

• 审查模式：找出资产型、授权型、交易型产品 UI 在上线前会伤害用户决策、操作安全或恢复路径的问题。
• 完善模式：当用户明确说「完善」「修复」「按产品 UI 要求补齐」「直接改」时，把审查发现落成 PRD、文案、交互状态或代码修改。

工作流

CREATE A TODO LIST FOR THE TASKS BELOW:

1. 识别审查目标。如果用户提供 PRD、设计稿、截图、代码库、路由或线上 URL，就以该材料为目标；如果没有目标，要求用户补充材料并停止。
2. 归类产品流程：资产查看、资产兑换、领取、支付、授权、签名确认、交易提交、转账、账号安全、开通/关闭服务、审批、数据导入/导出、跨系统流转、异步任务、批量操作，或其他高风险流程。
3. 提取用户决策路径。记录主要用户、目标动作、前置条件、涉及对象、金额/数量/范围、目标账户或目标系统、费用/耗时/限制，以及成功后果。未知项必须显式标记。
4. 为每一步归类动作风险：只读、表单提交、授权、签名确认、支付、交易提交、转账、批量变更、不可逆操作、跨系统流转，或长时间异步操作。
5. 按下方清单审查产品。优先处理可能造成用户损失、误操作、重复提交、不可逆误解、恢复路径中断或上线混乱的问题。
6. 使用可用材料验证证据。对于代码，检查相关文件；对于可运行应用或线上 URL，在工具可用时做浏览器验证；对于截图或 PRD，不要声称做过运行时验证。
7. 按用户意图路由输出。如果用户只要求审查，输出 PRODUCT_UI_RISK_REVIEW_REPORT，先列阻塞问题，再列改进建议、验证记录和未解决假设，然后结束。
8. 如果用户明确要求完善或修复，先按「强制完善规则」修改可编辑目标，再输出改动文件、已运行验证、未验证项和 PRODUCT_UI_RISK_REVIEW_REPORT 摘要，然后结束。

失败路径：

• 如果目标不可用或不可读，报告 blocker，说明缺失的材料并停止。
• 如果用户、对象、金额/数量、目标系统、权限或操作后果未知，默认带着明确假设继续；只有当缺失值会改变风险判断时，才问一个简短问题。
• 如果用户要求法律合规、安全漏洞、投资建议、财务收益判断或底层系统正确性结论，说明本 skill 只覆盖产品 UI 风险，并询问是否继续做 UI 风险范围内的审查。
• 如果无法真实操作关键流程，就做静态审查，并把真实交互验证列为未验证。
• 如果用户要求修复但没有提供可编辑源文件，返回审查结果，并说明需要哪些文件或材料才能打补丁。

强制完善规则

进入完善模式后，MUST 优先修复 critical 和 high 问题；只有在高风险问题已经处理或明确不可编辑时，才处理 medium 和 low 打磨项。

必须补齐的信息

• 任何资产、账户、支付、授权、签名确认、交易提交、转账、批量变更或跨系统流转按钮附近，MUST 显示对象、范围、金额/数量、目标、费用/耗时、权限变化和完成后果中的相关项。
• 按钮文案 MUST 具体。使用「支付 128 元」「授权访问客户名单」「确认兑换 100 USDC」「提交交易」「转出 2.5 ETH」「导出全部订单」这类动作文案，不用只有「Confirm」「Submit」「OK」「继续」的泛化文案。
• 如果数据未知、加载中、过期或读取失败，MUST 阻断高风险操作或清楚标注状态，NEVER 让用户基于不完整数据提交高风险动作。

必须补齐的状态

• 未满足前置条件：说明缺什么、为什么需要，以及满足后能做什么。
• 权限不足：说明缺少哪类权限，并给出申请、切换账号或联系管理员路径。
• 数据为空或不完整：说明当前能否继续；高风险操作必须被阻断或降级。
• 用户取消或拒绝：页面保持可恢复，并说明用户可以重试或返回。
• 操作处理中：阻止重复提交，说明正在等待系统确认或任务执行。
• 操作成功：说明结果，并提供下一步、详情页、记录或返回路径。
• 操作失败：说明可能原因，提供重试、修改输入、联系支持或查看详情路径。

授权、签名确认和交易提交