如果 AI 生成的 design.md 有问题，OpenSpec 的推荐做法不是“硬着头皮继续实现”，而是直接回到设计工件进行迭代修改。

OpenSpec 的核心理念之一就是：

“update as you learn”（随着理解加深持续更新）(GitHub)

官方文档明确提到，proposal → specs → design → tasks → implement 只是依赖关系，不是锁死的阶段，你可以随时回到前面的工件进行调整。(GitHub)

场景 1：还没开始编码

这是最简单的情况。

直接让 AI 修改 design.md：

设计存在以下问题：

1. xxx
2. xxx
3. xxx

请更新 openspec/changes/my-feature/design.md
并同步调整相关 tasks.md

或者：

/opsx:continue

重新生成 design.md

然后审查新的设计即可。

---

场景 2：编码过程中发现设计错误

OpenSpec 官方把这种情况归类为：

Design tweaks based on implementation discoveries（实现过程中发现设计需要调整）(GitHub)

推荐做法：

1. 更新 design.md
2. 必要时更新 delta spec
3. 重新生成或修改 tasks.md
4. 再继续 /opsx:apply

例如：

实现过程中发现：

- 原设计使用事件驱动
- 实际项目架构更适合消息队列

请更新：

- design.md
- tasks.md

并说明受影响的任务

---

场景 3：需求本身变了

这时候先判断：

同一个目标，只是实现方式变了

继续修改当前 change。

例如：

目标：
实现 Dark Mode

原设计：
CSS Variables

新设计：
Tailwind Theme

=> 更新当前 change

官方文档明确建议这种情况直接 Update Existing Change。(GitHub)

---

目标已经变成另一件事

例如：

原需求：
增加 Dark Mode

后来变成：
支持完整 Theme System

这属于 Scope Explosion（范围扩张）。

官方建议：

archive 当前 change

新建一个 change

而不是不断补丁式修改原设计。(GitHub)

---

场景 4：AI 设计质量很差

很多 OpenSpec 用户的实践是：

1. 先生成 proposal
2. 人工 Review proposal
3. 再生成 specs
4. 人工 Review specs
5. 再生成 design
6. 人工 Review design
7. 最后才让 AI 编码

社区里不少人强调：

把精力放在 Review Spec，而不是 Review Code。好的 Spec 会显著提升后续代码质量。(Reddit)

一个比较实用的 Prompt：

请作为 Senior Architect Review 当前 design.md

重点检查：

- 是否满足 specs 中所有 Requirement
- 是否存在过度设计
- 是否遗漏边界场景
- 是否存在性能风险
- 是否与当前代码架构冲突

输出：

1. 问题列表
2. 风险等级
3. 修改建议
4. 更新后的 design.md

---

我自己使用 OpenSpec 时，一般会采用下面的循环：

proposal
   ↓ review
specs
   ↓ review
design
   ↓ review
tasks
   ↓ review
implement

如果 design 有问题，直接回到 design 重写，甚至回到 specs 修改都没关系。OpenSpec 本身就是为了支持这种迭代，而不是瀑布式“一旦进入下一阶段就不能回头”。(GitHub)