原型 Review 指导

用于审查 Axhub Make client 原型的业务完整性、项目对齐、逻辑连贯性、数据一致性、状态、异常、边界条件和恢复路径。

本规则关注“这个原型表达的业务是否成立”。视觉美观、品牌一致性、响应式和可访问性问题按 rules/ui-review-guide.md 处理。

审查入口

当用户说「原型评审」「需求评审」「业务逻辑评审」「看看缺漏」「检查状态和错误处理」「帮我从业务角度挑问题」时，读取本规则并输出 Markdown 评审结论。

不要输出 JSON，不要写 JSON 文件。

审查依据

审查依据按以下优先级使用：

用户当前说明、附件、链接、截图、需求文档、PRD、会议纪要、业务规则、字段表、数据样例等用户提供的信息源。用户提供的信息源权重最高。
src/prototypes/<prototype-id>/.spec/ 中最近的决策、规格或计划 Markdown。排除 ui-review.md、prototype-review.md 和其他 review 结果。
src/resources/ 中与当前原型相关的需求、业务资料、字段清单、流程记录和数据样例。
当前原型源码、canvas.excalidraw、annotation-source.json、路由、页面配置和局部状态实现。
.axhub/make/project.json 等 metadata 只作为项目资源、入口和命名关系证据。

如果用户提供的信息源与 .spec、src/resources/ 或原型实现冲突，以用户提供的信息源为准，并在评审中标记为「资料冲突/待确认」。不要用项目旧文件覆盖用户最新资料。

明确不审

不评价视觉美观、品牌一致性、响应式布局、可访问性细节或是否符合 DESIGN.md。
不把配色、圆角、间距、字体、图标风格作为原型 Review 问题。
只有当 UI 缺失直接导致业务状态、错误、流程或字段无法表达时，才作为业务完整性问题记录。

核心审查维度

原型完整性：核心用户、主流程、入口、出口、空/加载/成功/失败状态是否覆盖。
项目上下文一致性：是否与用户资料、最新 .spec 决策、资源文档、项目 metadata、已有原型命名和范围一致。
业务逻辑连贯性：流程顺序、状态迁移、角色权限、操作前置条件、数据生命周期是否自洽。
数据模型一致性：实体、字段名、枚举、状态值、单位、时间/金额/数量口径是否在用户资料、资源、规格和原型中一致。
Edge cases：输入校验、边界条件、系统/网络失败、权限失败、并发/重复操作、集成失败、恢复路径。

Markdown 模板

# Prototype Review

- 审查目标：src/prototypes/<prototype-id>
- 用户资料/参考资料：列出本次使用的用户资料、.spec、resources、源码或 metadata
- 生成时间：2026-05-22 00:00

## 总体点评

用 1-3 段总结原型在业务完整性、项目对齐、逻辑连贯性和风险覆盖上的整体质量。先说最影响业务成立的问题，再说可以保留的有效表达。

## P0-P3 优先级问题

### P1 - Finding title

- 证据：说明来自用户资料、.spec、resources、源码、画布或 metadata 的具体线索。
- 影响：说明对业务流程、数据口径、用户任务、状态理解或后续实现/测试的影响。
- 修复方向：给出可执行的需求、原型或资料补充建议。

## 完整性与项目对齐

说明核心用户、主流程、入口出口、范围边界、资料冲突、最新决策和项目资源是否对齐。

## 业务逻辑连贯性

说明流程顺序、状态迁移、角色权限、操作前置条件、数据生命周期和跨页面一致性。

## 状态、异常、边界与恢复

按输入校验、边界条件、错误状态、并发/重复操作、集成失败和恢复路径整理发现。没有明显问题时也要说明已检查。

## 证据与评估说明

- 用户资料优先级：说明是否存在用户资料，以及是否与项目内资料冲突。
- 读取范围：说明读取了哪些 .spec、resources、源码、画布或 metadata。
- 独立评估：full 或 degraded，并说明原因。

分组要求

前三组固定且顺序不可变：

总体点评
P0-P3 优先级问题，最多 5 条
完整性与项目对齐

可以追加额外分组，例如 业务逻辑连贯性、状态、异常、边界与恢复、证据与评估说明，但必须放在前三组之后。

优先级

P0：核心业务流程无法成立，或与用户提供的明确需求/最新决策冲突。
P1：主要流程、关键状态、权限或数据口径存在严重缺漏。
P2：明显业务摩擦或边界缺失，但存在可用绕行。
P3：低风险补充项，后续完善后会提升业务表达或测试覆盖。

不要使用 P4 或更低优先级。

子代理与独立评估

有子代理能力时，优先拆成两个独立评估：

业务完整性评估：只看用户资料、.spec、src/resources/ 和 metadata，先判断业务基线。
原型证据评估：看源码、画布、路由、状态和页面实现，判断原型是否表达了业务基线。

两个评估完成前不要互相暴露结论。没有子代理时，先完成业务完整性笔记，再看原型证据，并在 证据与评估说明 中标记独立评估为 degraded。

当审查 3 个以上独立页面或业务流程时，优先按流程或页面拆分并行审查，最后统一综合成 .spec/prototype-review.md。

交付说明

最终回复至少包含：

审查目标
写入的 .spec/prototype-review.md 路径
使用的用户资料和项目资料
P0-P3 数量
是否发现资料冲突/待确认项
独立评估是否完整

7.1 KiB Raw Blame History Unescape Escape