如果 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)推荐做法更新design.md必要时更新 delta spec重新生成或修改tasks.md再继续/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)场景 4AI 设计质量很差很多 OpenSpec 用户的实践是先生成 proposal人工 Review proposal再生成 specs人工 Review specs再生成 design人工 Review design最后才让 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)