## 为什么用 HTML 输出场景列表，并与原型联动

[English](../../en-US/theory/prototype-review.md) | [中文](../../zh-CN/theory/prototype-review.md) | [日本語](../../ja-JP/theory/prototype-review.md)

在多数团队里，“需求评审”的低效主要来自三类问题：

- 评审对象不一致：有人看 PRD，有人看原型，有人看口头描述，导致结论无法复用
- 无法快速定位：评审过程中提出的意见，难以落到具体的场景/页面/功能点，后续无法追踪
- 验证成本高：只靠文档很难验证“是否可用/是否可实现/是否可测试”，必须进入实现后才暴露问题

因此，visual-spec 把“评审入口”设计为一个 HTML 页面（场景列表/场景评审页），并与可运行原型联动。

### 为什么是 HTML（而不是纯 Markdown）

- 交互式导航更适合评审：可点击跳转、目录定位、跨文件链接、快速定位场景与页面
- 对非技术干系人更友好：浏览器打开即可，不依赖编辑器/Markdown 渲染一致性
- 更容易做“评审任务化”：用列表把评审拆成若干可勾选、可核对的项，降低认知负担

### 为什么要“场景列表 ↔ 原型联动”

- 场景是评审的最小有效单位：业务常以“一个流程如何走”来判断对错，而不是按页面/接口判断
- 场景能贯通角色与权限：同一页面在不同角色下展示不同内容/可执行不同操作，场景联动能直接验证 RBAC 与数据权限是否合理
- 场景能贯通数据口径：在原型里看到字段、状态、金额、时间等展示，能更早暴露口径冲突与缺失规则
- 场景能沉淀验收：场景评审通过后，可直接转化为 `/vspec:accept` 的验收用例，减少重复劳动

### 为什么这会更方便用户评审

- 把“意见”锚定到可追踪的对象：场景、页面、组件、交互点
- 降低“从文本想象系统”的成本：用可运行原型快速验证理解是否一致
- 缩短反馈回路：评审意见更容易在 `/vspec:refine` 中落地，并同步更新原型与下游产物
