从"AI 生成"到"AI 交付"：码道规范驱动开发模式详解

AI 能写代码，但能写"能 merge 的代码"吗？这是很多技术负责人在引入 AI 编码工具时最担心的问题。码道的规范驱动开发模式，就是冲着这个问题来的。

问题：AI 写的代码敢不敢直接 merge？

如果你在团队里推过 AI 编码工具，一定遇到过这个场景：

开发者用 AI 生成了一个功能模块的代码，提交了 PR。你 Review 的时候发现：

• 代码风格不统一，有的用驼峰有的用下划线
• 没有写单元测试，或者测试只是占位
• 异常处理不一致，有的 try-catch 有的直接 throw
• 引入了项目里没有的依赖
• 分层混乱，业务逻辑写在了 Controller 里

你打回了 PR，开发者手动改了一轮再提交。来回两三次，AI 节省的时间又在 Review 和返工中消耗掉了。

这不是 AI 模型不够强的问题——模型生成的代码语法是对的、逻辑也是对的。问题是它不知道你团队的"规矩"。AI 编码工具如果不懂规范，它节省的是"写"的时间，浪费的是"改"的时间。

码道的规范驱动开发模式（Spec-Driven Development），就是要把这个"改"的时间也省掉。

什么是规范驱动开发

规范驱动开发是码道在 2026 年 2 月公测版中推出的开发模式。它的核心思想是：以明确的规范为约束，驱动 AI 生成符合工程标准的代码。

和"探索模式"不同，规范模式不是"你描述需求，AI 自由生成"，而是"你描述需求 + 配置规范，AI 在规范约束下生成"。

规范模式的工作流程

1. 配置规范：在项目中定义编码规范（可以是 Google Java Style、团队自定义规范、架构约定等）
2. 描述需求：用自然语言描述要开发的功能
3. AI 分析：码道读取规范配置 + 通过 Codebase 理解项目结构
4. 生成代码：在规范约束下生成代码，复用已有组件，遵循已有架构
5. 自动校验：对生成的代码做规范检查、安全检查
6. 生成测试：自动生成单元测试用例
7. 交付：代码 + 测试 + 校验结果一起输出

这个流程和探索模式的关键区别在第 1、4、5、6 步——规范模式不是"生成完就完了"，而是"生成 + 校验 + 测试"的闭环。

四重质量防护体系

规范模式的核心是四重智能防护，这是码道"工程化"定位的具体体现：

第一重：代码生成符合规范

AI 在生成代码时，会读取项目配置的编码规范，包括：

• 代码风格：命名约定、缩进、注释格式
• 架构约定：分层规则（Controller 不写业务逻辑、Service 不直接操作数据库等）
• 依赖约定：能用哪些库、不能用哪些库
• 异常处理约定：统一的异常处理方式

实测体验：我在项目里配置了"Service 层方法必须抛出 BusinessException，不能直接 throw RuntimeException"这条规范。之后让码道生成一个新的 Service 方法，它确实用了 throw new BusinessException("xxx") 而不是 throw new RuntimeException("xxx")。这个细节看起来小，但在 Code Review 时省了很多来回。

第二重：单元测试全面覆盖

规范模式下，码道会自动为生成的代码生成单元测试。它不是简单地"每个方法生成一个测试方法"，而是：

• 分析方法的输入输出和边界条件
• 生成正常流程的测试用例
• 生成异常流程的测试用例（非法参数、空值、越界等）
• 生成边界值测试用例
• 检查测试覆盖率

实测体验：我让码道为一个有 5 个 public 方法的 Service 类生成单元测试。它生成了 23 个测试用例，覆盖了正常流程、异常参数、边界值。跑了一遍测试，22 个通过，1 个失败——失败的那个是因为码道假设了一个 Mock 行为，但实际 Mock 对象的配置和假设不一致。手动修正后全部通过。

覆盖率从原来的 32% 提升到了 76%。剩下的 24% 主要是私有方法和一些复杂条件分支，需要手动补充。

不足：对于涉及数据库事务的方法，生成的测试有时会遗漏事务回滚场景。对于多线程相关的方法，测试生成质量明显下降——这是 AI 编码工具的普遍短板，不是码道独有的。

第三重：端云协同智能检查

码道不只是本地生成代码，还会和云端模型协同做代码审查：

• 本地检查：快速检查代码风格、规范符合性
• 云端检查：利用云端大模型做更深层的逻辑检查、安全检查
• 协同：本地和云端检查结果合并，给出完整的检查报告

这种端云协同的设计是为了平衡速度和深度——本地检查快但能力有限，云端检查深但需要网络往返。两者协同既保证了响应速度，又保证了检查质量。

实测体验：码道在一次代码生成后给出了一个检查报告，其中标记了一个潜在问题："这个方法在循环中调用了外部 API，建议加批量处理或缓存。"这个检查是对的——我确实在循环里调了远程接口，在大数据量时会有性能问题。这个级别的检查超出了简单的 lint 规则，是需要理解代码语义才能发现的。

第四重：问题修复自愈闭环

如果在前三重防护中发现了问题，码道会尝试自动修复：

1. 发现问题 → 分析原因 → 生成修复代码 → 重新校验
2. 如果修复后仍有问题，继续循环
3. 如果多次修复未果，停止并报告给开发者

这个"自愈"能力是规范模式的加分项。它不是万能的——复杂的问题仍然需要人工介入——但对于一些常见问题（如缺少空指针检查、资源未关闭等），自动修复确实能省不少事。

实测体验：码道生成的一段代码里有一个未关闭的 FileInputStream。它在自检中发现了这个问题，自动加了 try-with-resources，重新校验通过后给出了最终代码。整个过程不需要我介入。

但也有"自愈"失败的情况：一次生成的代码有一个并发修改的问题（在遍历 List 的同时修改了它），码道尝试修复了两次但方案都不对，最终停止并把这个问题标记给我手动处理。这个行为是合理的——它知道自己修不了，而不是给一个"看起来修了但没修对"的方案。

怎么配置和使用规范模式

配置规范

码道支持多种规范配置方式：

1. 内置规范：选择 Google Java Style、阿里巴巴 Java 开发手册等内置规范
2. 自定义规范文件：在项目中放置规范配置文件，定义命名约定、架构约定、异常处理约定等
3. 从已有代码推断：码道分析项目已有代码，自动推断规范（适合没有显式规范配置的老项目）

使用规范模式

1. 在码道 IDE 中切换到"规范模式"
2. 确认规范配置（内置或自定义）
3. 用自然语言描述需求
4. 码道在规范约束下生成代码 + 测试 + 检查报告
5. Review 生成结果，确认后应用

Skills 机制

规范模式的另一个重要组成部分是 Skills。码道内置了一系列研发场景的 Skill：

• 需求管理、系统设计、软件开发
• 编译构建、测试验证、发布部署
• 开源与漏洞管理

你可以把团队的 Best Practice 封装成自定义 Skill。比如"我们团队的接口返回格式统一用 Result<T> 包装"——把这个约定做成 Skill，以后 AI 生成的所有接口代码都会自动用这个格式。

规范模式 vs 探索模式：什么时候用哪个

我的使用策略是：写原型用探索模式，写生产代码用规范模式。 探索模式追求"快速验证想法"，规范模式追求"一次写对，能直接交付"。

实测总结

好的方面：

• 规范约束确实有效，生成的代码风格和项目已有代码一致
• 自动生成的单元测试质量不错，覆盖率提升明显
• 端云协同检查能发现一些非简单 lint 能发现的问题
• 自愈闭环对常见小问题有效，减少了手动修正的工作量

不足的方面：

• 规范配置本身有一定工作量，需要把团队的隐性约定显式化
• 对于复杂业务逻辑，规范模式生成的代码有时过于"模板化"，缺乏灵活性
• 自愈闭环对复杂问题（如并发问题）的处理能力有限
• 规范模式的生成速度比探索模式慢约 30-40%，因为多了校验环节

总体评价：规范模式是码道"工程化"定位的核心体现。它不是让 AI 写"更好的代码"，而是让 AI 写"能 merge 的代码"。如果你的团队正在被"AI 代码 Review 返工"困扰，规范模式值得一试。前期配置规范的成本，会在后续减少返工中收回。