## 为什么要先生成数据模型，再生成原型

在 `/vspec:verify` 阶段，visual-spec 会先产出 `/specs/models/*.md` 的数据模型，再基于模型生成 `/specs/prototypes/` 的可运行原型。这不是实现细节，而是为了把“口径与约束”前置为原型的硬边界。

### 核心原因：原型依赖“名词与状态”，而不是反过来

- 数据模型定义系统的名词：实体、字段、口径、枚举、状态、关联关系、生命周期
- 原型验证系统的动词：用户如何操作、状态如何流转、不同角色如何看到/做不同事情

如果名词与状态不稳定，原型的页面字段、列表筛选、表单校验、权限可见性都会变成“凭感觉画”，评审很容易陷入 UI 细节，而不是对齐业务口径。

### 为什么“模型优先”会显著减少返工

- 统一口径：字段命名、金额/时间口径、状态枚举、必填/可空约束在模型里先定下来，原型只做可视化验证
- 提前暴露矛盾：模型阶段就能发现“同一字段多种叫法”“状态缺口”“关联关系不完整”等问题，避免在原型里反复改 UI
- 让交互更可实现：表单校验、列表排序/筛选、分页、权限过滤等通常依赖字段类型与约束；模型明确后交互才有落点
- 让权限与数据权限更可验证：RBAC/数据权限经常落在“哪些字段可见、哪些记录可见、哪些状态可操作”，模型稳定后才能在原型里准确演示
- 让后续产物可复用：验收用例与自动化测试往往需要明确数据前置条件与期望结果；模型先定能减少后续补齐成本

### 反过来的典型代价（先画原型再补模型）

- 页面先画出来，但字段与状态后补导致大量 UI 重做（列表列、详情块、表单项、提示文案）
- 场景能跑通，但“为什么能跑通”不清楚（缺字段、缺状态、缺约束），实现阶段才暴露
- 评审结论难复用：对着原型提的意见无法落到可追踪的结构化对象（模型/字段/枚举/规则）

### 与目录产物的对应关系

- 数据模型：`/specs/models/`（通常由 `/vspec:verify` 输出）
- 可运行原型与评审入口：`/specs/prototypes/`（通常由 `/vspec:verify` 输出）

相关说明：

- 命令与输出：[commands.md](../commands.md)
- 目录结构：[directories.md](../directories.md)
