## 为什么 visual-spec 更擅长响应需求变更

需求变更的真正难点，不是“改一处文档”，而是保证变更不会在下游产生口径漂移：功能细节、数据模型、原型、验收用例、测试与实现输入要能一起同步更新。visual-spec 的设计目标，就是把这种同步从“靠人记住”变成“靠结构化产物联动”。

### 1) 以场景为主线，变更能被快速定位

需求往往以“某个场景怎么走”发生变化，而不是以“某一页怎么画”发生变化。visual-spec 用场景把角色、流程、规则、数据与页面串起来，使变更可以被锚定到具体场景与受影响的功能点，避免只改了 UI 或只改了文本却漏改规则与数据口径。

### 2) 产物是结构化的，适合做差异与回溯

相比把信息集中在一份长文档里，visual-spec 把内容拆成可复用的模块化产物（背景/术语/场景/功能/细节/模型/原型等）。模块化带来的直接收益是：

- 变更影响范围更清晰：哪几个功能、哪几个场景、哪几个字段受影响更容易判断
- 差异更可读：评审时可以聚焦于变更段落与关联产物，而不是“整份 PRD 重新通读”
- 结论更可追踪：意见能落到具体对象（场景、规则、字段、页面、交互点）并形成闭环

### 3) 变更是“同步更新”，而不是“补丁式追加”

`/vspec:refine` 的定位不是简单追加说明，而是把补充/澄清材料合并回现有口径，并同步更新受影响的细节与原型，从而减少“旧口径残留”导致的漂移。

### 4) 质量门禁让漂移可被发现

当需求发生变化时，最容易出现的是：规则改了、模型没改；页面改了、验收没改；或者术语改了、场景仍用旧词。通过 `/vspec:qc` 的规则化检查，可以把这类遗漏与矛盾显性化，降低变更后的隐性风险。

### 5) 原型与模型作为“可运行的验证载体”，缩短反馈回路

`/vspec:verify` 生成数据模型与可运行原型，评审不需要依赖想象即可验证变更后的行为是否正确。越早用可运行产物完成对齐，变更带来的返工成本越低。

相关说明：

- 变更与同步更新：[commands.md](../commands.md)
- Verification & Validation 理念：[verification_and_validation.md](verification_and_validation.md)
