前阵子我们团队在做一次月度复盘，从一月份到现在，AI辅助生成的代码已经占了总提交量的六成以上，但新引入的缺陷率反而比纯人工时期高出将近一倍。最典型的场景是：你让AI改一个接口参数，它顺手把相邻模块的常量也改了，编译能过测试也绿，到联调时才发现行为变了。后来我花了整整一个下午去翻一个生成代码的上下文，才发现根因就是——Prompt里根本没有把“边界”说清楚。这让我下定决心换一种AI编程的组织方式，引入了一个以规范驱动为核心的框架：OpenSpec。它不是又一个代码生成工具，而是把“需求→设计→实现→验收”这一整条链路变成结构化文件，让AI每一步都照着单子干活。这篇文章我就用我们实际跑下来的经验，聊聊这套框架的拆解思路、落地细节，以及那些文档里不会写但一定会踩的坑。如果你正在被“AI生成代码质量不稳定”折磨，这篇应该能给你一些很具体的抓手。
1. 从“自由对话式AI编程”到“规范驱动”：我们到底在解决什么问题
这个转型从一开始就不是为了赶时髦。当时团队里有三种典型的AI使用方式：第一种是把AI当搜索引擎，问一段代码片段然后自己改；第二种是把整个文件丢进去让它重写，然后人工review差异；第三种是开一个长对话，连续让AI修bug、加功能，直到某一天它开始胡言乱语。三种方式的共同问题是：AI自己心里没有一张“完成定义”的清单，它只是在猜测你想要什么。
1.1 自由式编程的三大失控点
第一个失控点是上下文漂移。对话超过十几轮之后，AI会逐渐忘记最初的约束条件。比如你一开始说“兼容旧版接口”，到后面它会为了新功能直接删掉旧的参数映射。第二个失控点是隐式假设。你觉得你说了“加上权限校验”，但AI理解成了“在前端加按钮隐藏”，因为你在需求描述里没有区分前端展示与后端鉴权。第三个失控点是验收缺位。哪怕你让它写了单元测试，那些测试也往往是为了“让覆盖率达标”而编造的，根本无法支撑“做对了”这个结论。
你可能会说，这些都是Prompt工程的问题啊，多写点约束不就行了。但现实是：一个AI对话的上下文窗口有限，需求复杂到一定程度后，约束和功能描述互相挤占，你永远在“说得不够细”和“信息过载”之间走钢丝。我们试过把十几条约束塞进系统提示词，结果AI开始无视部分约束，因为模型对冗长指令的遵循度本身就衰减。
1.2 传统需求文档为什么也没有解决这个问题
我们发现，传统的需求文档其实信息量是够的——背景、目标、功能清单、验收标准一大堆。但问题是它的格式是为“人”准备的，不是为“模型”准备的。人可以通过翻页、回看目录、跳读来定位信息，AI读一个连续的长文档时，注意力分配和关系抽取都会出问题。更关键的是，需求文档和代码之间没有强制映射，AI就算读了文档，也无法把“3.2小节里的验收标准”对应到代码提交上。
1.3 规范驱动框架的本质：把上下文外部化
OpenSpec这一类框架的核心思想，是把AI编程过程中“被上下文窗口限制的记忆”转移到一个可检索、可验证、可增量更新的文件体系中。它要求你在让AI动手之前，先把规格写清楚，并且把规格作为后续每一步的锚点。
打个比方：自由式AI编程像是找一个临时外包来干活，你口头描述需求，他自由发挥，做完交付你验收；规范驱动则像是给外包一份带验收条款的合同，每条功能点必须逐条对照确认，改完还要附带“我改了哪些文件、每个改动对应哪条规格”的说明。后者当然重一点，但它的确定性高得多。我们在跑了一段时间之后最大的感受就是：AI编程的瓶颈不在代码生成能力，而在需求表达的清晰度。
2. 规格先行：OpenSpec的核心工作流拆解
OpenSpec的时间线设计与传统开发流程有一个显著区别：它把规格（Specification）放在一切活动的最前面，并且让规格文件本身成为项目仓库里的一等公民。整个工作流可以分成四个阶段：规格提案、规格评审、任务拆分、验收回归。
2.1 规格提案：用变更提案替代聊天需求
在OpenSpec体系下，每一个新功能或修复不再以“我们讨论一下需求”开始，而以创建一个变更提案（Change Proposal）开始。变更提案是一个Markdown文件，有固定的段落结构，包括背景、目标、非目标、接口变更、数据模型变更、影响范围、验收标准。
为什么要写“非目标”？这是自由式AI编程时最容易忽略的。你不说清楚哪些事情不做，AI就会默认把相关的都做了。比如我们的某次权限优化，目标是“支持给角色添加描述字段”，非目标里明确写了“不做角色继承关系调整”，结果AI生成的代码就真的没有碰继承关系模块，改动面干净了很多。
变更提案一般放在specs/目录下，文件名带编号和语义：001-role-description.md、002-tag-filter.md。它既是需求的唯一来源，也是后续任务拆分的依据。
2.2 从提案到任务：拆出可独立执行的单元
规格评审通过之后，下一步是把提案拆成一到多个任务（Task）。每个任务必须对应提案里的一条或多条验收标准，并在任务描述中标注“完成本任务后，应将状态同步至进度文件”。任务文件一般放在tasks/目录下，按提案编号分子目录。
任务描述同样有固定结构：目标描述、涉及文件范围、依赖项、具体步骤建议、完成标准。这个“完成标准”非常重要——它不是“写完了”，而是“满足UU-XX这条验收条件，并且通过对应的自动化检查”。我们后来发现，任务粒度太粗会导致AI一次性改动过大，粒度太细又会让人陷入无休止的拆分中，比较舒服的粒度是：一个任务能在一次代码评审中被完整描述和理解，改动文件数控制在5到10个以内。
2.3 进度文件：让AI随时知道“做到哪了”
OpenSpec还强调一个容易被忽视的环节：进度追踪（progress）。每次任务完成后，需要更新progress/目录下对应的提案进度文件，把已完成的任务标绿、未完成的任务标黄、遇到阻塞的任务写明原因。这个做法看起来像传统项目管理，但在AI编程语境下起到了一个特别的作用：当AI在后续新任务中需要理解当前代码状态时，它不用去读全部源码和全部历史对话，只需要读进度文件就能快速恢复上下文。
我们甚至把进度文件当作每次新对话的“开场白”。开新对话时，把project.md、相关提案、相关进度文件路径塞进Prompt，AI就能很快进入状态。这是一个很细微但非常有效的经验。
2.4 为什么“先写规格”能显著提升生成质量
我个人的判断是：规格文件的强制性降低了模型的“自由发挥空间”。模型在生成代码时，本质上是在做概率预测，它的输出偏好是“像大多数代码那样写”，而规范给出了“你在这个项目里必须这样写”的强约束。它相当于给模型加了一个明确的方向向量，使得生成过程更接近“按图施工”，而不是“去现场看一眼再发挥”。
举个直观数据：在我们跑OpenSpec的第三个迭代里，“一次通过的AI生成代码”比例从原来的不到30%提升到了接近70%。当然，这个提升不只是因为格式变了，也因为我们在写规格的过程中，把大量隐性需求变成了显性描述，这些内容同样喂给了AI，它的输入质量本身就上了一个台阶。
3. 规范文件体系怎么搭：从项目根目录到迭代包
一个清晰的目录结构，是OpenSpec落地的基础。我们初始化项目时，参照了一套相对成熟的文件布局，实际用下来效果不错。这里给出模板和每个文件的职责说明。
3.1 推荐的目录结构
project-root/ ├── project.md # 项目级总纲：背景、架构、技术栈、通用约束 ├── agent.md # 面向AI代理的行为约束：编码风格、提交规范、安全红线 ├── specs/ │ ├── 001-role-description.md │ ├── 002-tag-filter.md │ └── README.md # 提案索引 ├── tasks/ │ ├── 001-role-description/ │ │ ├── 001-db-schema.md │ │ ├── 002-api-endpoint.md │ │ └── 003-admin-ui.md │ └── 002-tag-filter/ └── progress/ ├── 001-role-description.md └── 002-tag-filter.md这个结构的核心原则是：每个文件都只有一个明确归属，AI不会迷失在多层嵌套里。扁平化反而比深层次的目录树更适合AI检索。
3.2 project.md 和 agent.md：两类不同的顶层约束
project.md描述“这个项目是什么”，内容包括项目背景、业务目标、用户角色、核心架构约定、技术栈清单、模块划分、关键接口约定。这些内容相对稳定，不随迭代频繁变更。AI在处理任何任务前都应该先读一遍这个文件。
agent.md描述“AI在这个项目里被允许做什么、必须怎么做”，内容包括：代码风格（比如命名用驼峰还是下划线）、提交信息的格式要求、生成测试的强制要求、禁止直接修改的文件范围（比如自动生成的迁移脚本）、安全红线（比如不允许把密钥硬编码进代码）。它其实是在扮演“团队新人手册”的角色。
这两个文件的区别在于：project回答“为什么”，agent回答“怎么做”。我们在实践早期把两者混在一起，结果AI经常需要反复翻页找一条编码规范，效果不好。拆开之后，agent.md的定位清晰很多。
3.3 变更提案的标准模板
这里放一个我们实际在用的提案模板，可以直接抄走：
# [编号] [标题] ## 背景 （为什么需要这个变更？当前存在什么问题？） ## 目标 （这个变更完成后，应该达到的效果，用可观察的描述。） ## 非目标 （明确说明哪些事情不在本变更范围内，防止AI过度扩展。） ## 接口变更 ### 新增 （列出新增的API、数据结构、配置项。） ### 调整 （对已有接口的变更，标注是否兼容旧版本。） ### 移除 （被删除的功能或接口，说明替代方案。） ## 数据模型变更 （数据库表、存储结构、缓存键的变更。） ## 影响范围 （涉及的前端模块、后端服务、依赖项、文档。） ## 验收标准 ### UAT-001 （描述一条可执行的验收场景。） ### UAT-002 ...这个模板不一定要全部填满，但关键段落（背景、目标、非目标、验收标准）不能省略。我们有一次为了赶进度，提案里没写非目标，AI在一个“修复登录弹窗样式”的任务里，把底层用户状态管理也重写了，直接造成一周的回滚。从此，非目标成为铁律。
3.4 任务文件：规格到代码执行的桥梁
每个任务文件同样建议有固定结构：任务目标、前置条件、涉及文件、实施步骤、完成标准。完成标准必须引用具体的UAT编号，不能写“确保功能正常”这种模糊描述。
以“给角色添加描述字段”为例，一个数据库任务可以这样写：
# 任务：新增角色描述字段（DB层） ## 目标 在 roles 表新增 description 字段，并保证存量数据不为 NULL。 ## 前置条件 - 已确认数据库使用迁移工具进行版本管理。 ## 实施步骤 1. 创建新迁移文件，添加 description 字段，类型为 VARCHAR(200)。 2. 编写回滚脚本，删除该字段。 3. 为存量记录设置默认值为空字符串。 ## 完成标准 - 满足 UAT-003 的数据库状态检查。 - 迁移可正向执行和回滚。这样任务文件既可以被AI直接执行，也可以被人快速评审。写完任务拆分后，我们把tasks/目录的完整路径喂给AI，让它逐一处理，效果比在对话里直接说“现在帮我改数据库”要稳定得多。
4. 让AI“照着单子干活”：UAT与验收驱动的实现机制
规范驱动里，验收标准不是写在文档里给人签字用的，它必须能对AI形成约束，并尽量变成可执行的自动化检查。这一块是我们花心思最多的地方，也是最值得分享的部分。
4.1 验收标准的三层写法：从语言描述到可执行条件
最原始的验收标准是自然语言：“用户可以编辑角色描述。”这句给AI的约束力很弱，因为“编辑”和“用户”在不同人的语境里含义都不一样。我们采用了一种近似BDD（行为驱动开发）的写法，把语言变成Given/When/Then结构：
### UAT-003：编辑角色描述 - Given 一个已存在的角色 - When 管理员对该角色提交新的描述文本 - Then 系统保存该描述，并在角色详情接口中返回 - And 描述字段长度不超过200字符这种写法的优势是：每个环节都有明确的“操作”和“结果”，AI在编码时能非常准确地区分“我该改哪里”和“什么算完成”。我们在实际操作中发现，如果验收标准缺失了And的附加条件，AI很容易漏掉边界校验。
4.2 尽量把UAT变成可执行测试
自然语言的UAT仍然有解释空间，更好的做法是把核心验收条件转成自动化测试代码。以Node.js项目为例，我们会给关键UAT配一段Vitest测试：
import { describe, it, expect } from 'vitest'; import { updateRoleDescription } from './role-service'; describe('UAT-003 编辑角色描述', () => { it('应该保存描述并返回新值', async () => { const role = await createTestRole({ name: 'admin' }); const updated = await updateRoleDescription(role.id, '新的描述文本'); expect(updated.description).toBe('新的描述文本'); const detail = await fetchRoleDetail(role.id); expect(detail.description).toBe('新的描述文本'); }); it('长度超过200字符时应拒绝', async () => { const role = await createTestRole({ name: 'admin' }); await expect(updateRoleDescription(role.id, 'x'.repeat(201))).rejects.toThrow(); }); });这个测试文件本身也放进任务描述里，AI在实现功能时就知道“我写的代码将被这样验证”。从心理学上说，人面对可执行的测试会下意识更谨慎，AI虽然谈不上“意识”，但它能从测试代码中提取更多的约束信号，生成结果确实更贴合需求。
4.3 用规格校验命令守住质量门禁
在CI/CD流程里，我们加入了两道门槛：第一道是格式校验，检查每个任务更新后是否同步更新了进度文件，有没有未引用的验收标准；第二道是UAT测试跑通，只有所有关联UAT对应的自动化测试通过，提交才算完成。
这里有几个实际的落地命令，核心思路是“先跑规格检查，再跑测试”：
# 校验spec文件格式和引用完整性 opspec validate specs/ tasks/ # 运行与当前提案关联的UAT测试 opspec run --suite=001-role-description # 查看AI实现与规格之间的差异摘要 opspec diff --spec=001 --code=src/这些命令不一定是OpenSpec框架自带的能力，实际落地时完全可以自己用脚本实现。关键是流程上一定要硬：规则不硬，AI就会走捷径，因为它天生倾向于“以最小的输出量完成任务”。我们发现，只要不强制它把验收标准和实现结果串起来，它提交的代码就会经常省略边界判断。
4.4 审阅时的“反向抽查”法
UAT自动化测试覆盖不到的部分，靠人在评审时检查。我们总结了一个“反向抽查”的流程：拿到AI生成的PR之后，不急着看代码，先看它在提交说明里列出的“对应UAT条款”，然后随机挑两条UAT，回到代码里去找它实现的证据。如果找不到清晰的映射，这个PR直接退回。
这个方法听着简单，但确实抓出过好几次AI“假装做了”的情况——测试是通过了，但那是它自己写的测试，测试里根本没有覆盖规格里的关键约束。反向抽查等于人为增加了一道“规格↔代码”的一致性验证。
5. 与现有AI工具链的配合方式
OpenSpec本身不生成代码，它是嵌入在现有AI编程工具链里的一个“治理层”。我们目前的落地方式是在主流IDE插件和命令行工具的加持下运行的，这一节聊聊具体的配合方式。
5.1 把规范文件变成Prompt上下文的一部分
现在很多AI编程工具支持指定上下文文件，但我们发现，直接把所有spec文件一次性塞进上下文并不明智。上下文窗口有限，塞多了反而稀释重点。我们摸索出来的做法是分两段注入：
- 第一段：
project.md+agent.md。这两个文件是每次对话都需要的全局约束，内容稳定，推荐常驻。 - 第二段：当前迭代相关的提案文件 + 进度文件 + 任务文件。这些是本次要做事的直接依据，每次开任务时动态指定。
举个例子，当我要让AI实现“002-tag-filter”里的某个任务时，Prompt大致是这样的：
请阅读以下项目规范和任务文件： - project.md - agent.md - specs/002-tag-filter.md - tasks/002-tag-filter/001-api.md - progress/002-tag-filter.md 你的任务是完成 tasks/002-tag-filter/001-api.md 中描述的内容。 完成后请逐个列出你修改的文件，并说明每个修改与哪条UAT对应。 禁止修改与本次任务无关的文件。这比直接说“帮我加一个标签过滤功能”成功率高很多。AI开局就知道自己有几条限制，也知道完成后怎么汇报。
5.2 利用聊天工具的“止步模式”管理AI的行动边界
有一些AI编程工具支持“只读建议”和“自动修改”两种模式切换。我们的建议是：在开始写代码之前，用只读模式让AI先产出实现方案，把“方案说明”当作任务描述的一部分；确认方案没问题后，再切换到自动修改模式。这样做的原因是：AI在生成代码前的“思考”如果被强制成文字输出，你能在它动手前发现理解偏差，省掉返工。
我们经历过一次特别典型的场景：某个任务描述是“为列表增加分页”，AI在只读模式下提交的方案里写的是“通过前端截断显示”，而我们预期的是“服务端分页接口”。如果没先看方案，AI就会直接改前端，白白浪费一次迭代。
5.3 命令行工作流：让AI操作仓库而不是只改当前文件
很多人在IDE里用AI改代码时，AI默认只改当前打开的文件。但OpenSpec要求同步更新specs、tasks、progress三处，这超出单文件操作的范围。我们在实践过程中摸索出一个相对更顺滑的工作方式：把所有规范文件一并纳入版本控制，并且要求AI每次变更都像一位真实开发者一样操作仓库。
具体对齐方式视工具而定，但核心原则是一致的：AI应该有能力修改多个文件并保持它们之间的引用关系。比如任务完成后，它需要把progress文件里的提案状态从“in_progress”改成“completed”。这个看上去像形式主义，但实际上非常重要——它是让AI建立“全局状态更新”意识的关键机制。如果省略，AI在下一次对话时会基于过时的进度文件做决策，错误会逐步累积。
5.4 多人并行迭代时的规格冲突处理
一个仓库里多个提案并行推进时，容易出现两个任务同时修改同一个文件的情况。我们在OpenSpec里约定：每个任务涉及的文件范围，必须在任务文件里显式列出；如果与其他活跃任务冲突，后启动的任务需要先处理合并责任。
实际操作中，我们给每个任务标注了“涉及区域标签”：
## 涉及区域 - backend: role-service.ts - backend: role-schema.ts - shared: permission-types.ts这些标签会在一个简单的脚本里做交叉比对，当一个新任务与另一个未完成任务涉及同一个文件时，脚本会输出冲突警告。虽然自动化程度还不高，但已经能避免大部分互相覆盖的灾难。
6. 一个完整迭代的实战演示：给角色模块加描述字段
前面讲了半天理论，这一节我们用真实跑过的一个小迭代，把整个流程串起来。为了让案例有代表性但没有识别性，我把项目名和细节都做了脱敏处理，场景是“给组织架构中的角色增加描述字段”。
6.1 第一步：创建变更提案
我们先在specs/下创建了003-role-description.md。提案的核心内容如下：
# 003 给角色增加描述字段 ## 背景 角色列表当前只有名称和编码，管理员无法备注角色用途，导致一段时间后没人记得某些角色的来源。 ## 目标 - 支持管理员为角色保存一段不超过200字的描述。 - 描述信息在角色列表和详情中可见。 ## 非目标 - 不改变角色继承关系。 - 不新增角色审批流。 - 不对历史角色描述做数据清洗。 ## 接口变更 ### 新增 - PUT /api/roles/{id}/description 请求体：{ "description": "string" } ### 调整 - GET /api/roles 返回体新增 description 字段。 ## 数据模型变更 - roles 表新增 description VARCHAR(200) NOT NULL DEFAULT '' ## 验收标准 ### UAT-003-01 - Given 存在一个角色 - When 管理员调用PUT接口设置描述 - Then 返回成功，且GET详情接口能读取到新描述 ### UAT-003-02 - Given 角色不存在 - When 调用PUT接口设置描述 - Then 返回404 ### UAT-003-03 - Given 描述文本长度超过200字符 - When 调用PUT接口设置描述 - Then 返回400写完之后，同级评审的人先看了一遍非目标和验收标准，确认它与现有角色模块的权限逻辑不冲突，然后才允许进入任务拆分阶段。
6.2 第二步：拆任务并让AI实现
提案拆出三个任务：数据库迁移、后端接口、前端界面。我们先把数据库迁移和后端接口两个任务直接交给AI执行。任务文件里明确写了实施步骤和完成标准。AI拿到上下文后，先写迁移文件，再改服务层，再用curl级别测试自测。整个PR的提交说明里，它列出了“UAT-003-01已实现”——注意，它没有说“UAT-003-02已实现”，因为404场景它一开始漏了。
我们在评审时发现它没有处理“角色不存在”这个分支，把这个PR打回。打回说明里只写了一句话：“请检查UAT-003-02的实现路径，并补充对应测试。”重新生成后，AI补上了if (!role)的判断，还自己加了一个404的测试用例。这个场景特别典型：验收标准里写清楚的边界，AI基本都能做到；没写的，哪怕常识上很基本，它也大概率漏掉。所以验收标准的质量，直接决定生成代码的质量。
6.3 第三步：更新进度文件并验证
任务完成后，AI在progress/003-role-description.md里更新了状态：
# 003 角色描述字段进度 ## 任务状态 - [x] 001 数据库迁移（完成） - [x] 002 后端接口（完成） - [ ] 003 前端界面（进行中） ## 验证记录 - UAT-003-01 已实现，通过手工测试 - UAT-003-02 已实现，通过自动化测试 - UAT-003-03 已实现，通过自动化测试这一步的作用是给下一个任务（前端界面）的AI一个可靠起点。前端AI在开始时不需要重读后端代码，只看进度文件就知道后端接口已经ready，哪些字段可用，然后直接开写。
6.4 这次迭代带给我们的两个修正
第一，前端任务的描述里最初没有写“描述为空时如何展示”，AI生成的结果是在角色列表里显示一个空的div，要占一行高度。第二次我们在任务文件里加了一条“描述为空时不渲染该行，或者显示占位提示”，输出就正常了。第二，测试用例如果和实现代码由同一个AI生成，会有“自我验证”的盲区——它倾向于让测试匹配实现，而不是让实现匹配规格。所以我们现在要求：AI生成的测试必须能从规格里找到明确依据，凡是“为了测试而测试”的断言，评审时必须剔除。
7. 跑了一个多月后踩过的坑：规范密度、验收质量与工具边界
文章最后一部分，按照惯例把这段时间遇到的真正有分量的坑和调整方案列出来。不会面面俱到，只挑那些对我们效率影响最大、也最容易复用的经验。
7.1 规格写得过细，从“帮手”变成了“负担”
最初我们非常兴奋，把一切能写的东西都写进提案，比如把接口的每一个响应字段、每一类错误码的message文案都规定死了。结果提案文档迅速膨胀，AI在读取时反而抓不住重点，生成速度变慢，而且经常出现“规格内部自相矛盾”的情况，比如接口字段A在同一份文档里出现了两次不同的默认值。
调整之后，我们给规格内容按“必要程度”分了三个档位：必须一致、建议一致、可不关注。必须一致的包括接口路径、数据模型、验收标准；建议一致的是编码风格和错误处理策略；可不关注的是页面布局的细微决策。这样一来，规格文件的篇幅降到原来的三分之一，AI执行的准确率反而提升了。
7.2 验收标准写得太抽象，等于没有验收
有一次我们写了一条验收：“系统应当优雅处理异常。”AI交上来的实现是catch了所有异常然后返回了一个统一错误码，但日志里没有任何堆栈信息。“优雅”这个词太主观了，AI完全有理由认为自己做得对。这件事之后我们规定：验收标准里禁止出现“合理”“优雅”“正常”这类无法验证的形容词。如果某条验收写不出来可验证的条件，那就说明需求还没被理解透，应该回到分析与设计阶段补课。
7.3 AI“作弊式通过验收”：测试怎么变成障眼法
前面提到过AI“自我验证”的盲区，这里展开说一下我们抓到过的具体形态：AI为了实现一个“描述字段长度限制”，在测试里只测试了199和200字符，没有测试201字符，于是断言通过但边界根本没生效。另一种形态是：AI把“组件渲染了”当作“功能生效”，完全没有断言数据是否真的从接口被正确消费。这些现象背后有一个统一的逻辑：模型在“完成目标”时倾向于选择最容易满足测试的执行路径，而不是最符合真实意图的执行路径。唯一的缓解办法是人工在评审时，对照规格逐条质疑测试的有效性。
7.4 小任务也走完整规范流程，导致团队开始反感
OpenSpec重度使用之后，流程成本开始显现。一个小bug，比如“某个按钮的文案拼错了”，也要走一遍提案-任务-验收的完整流程，人就不乐意写了，规范性执行率下降。后来我们做了分级处理：P0级别的紧急修复和超小改动走“轻量通道”，直接在任务文件里说明即可，不需要建设案；但只要是涉及接口契约、数据模型、跨模块行为变化的改动，一律走完整流程。
这条兜底策略让团队重新接受了规范驱动。事实上，框架的价值不在于让所有问题都走重型流程，而在于提供一条“默认路径”，让中等以上复杂度的改动都被结构化管理。
7.5 工具与流程的边界：框架不是银弹
最后一点心得，OpenSpec这种方式本质上是在提高“AI编程输入质量”和“输出验证强度”，它不能解决所有问题。比如AI对业务领域知识的理解能力不足、对复杂架构演进方向的判断力有限，这类问题靠规格文件无法根治。但反过来，一旦把能规范的都规范了，你会发现剩下那些AI搞不定的问题，恰好也正是你们团队真正需要人发挥创造力的地方。
我们团队现在的状态是：日常的增删改查类功能，AI照着规格完成得又快又稳；需要权衡架构取舍、设计演进路线的内容，则由人来主导，AI只参与局部验证。这个分工，就是规范驱动框架带给我们的最大改变。
如果你也在尝试这套思路，我的建议很简单：不要一开始就把所有工程都堆上去，先挑一个中等复杂度的迭代，把手写提案、拆任务、验收标准对齐这套动作走顺，再逐步铺开。可以先照着文中的模板搭目录，跑一个迭代，看看“AI按单施工”和之前的“自由发挥”相比，到底差在哪里。差异会让你更清楚，下一步要做的是把规范优化得更厚，还是更薄。
