当前位置：首页 > news >正文

AI 写代码又快又好？你可能少了最关键的一步

news 2026/6/23 11:14:20

AI 写代码又快又好？你可能少了最关键的一步

AI 10 分钟写完一个 CRUD 模块，编译通过，启动正常，上线一周后出了 bug——某个边界条件没人测过，AI 也没写测试。

AI-coding 的工程化问题

大多数人用 AI 写代码的流程是这样的：

把需求丢给 AI
AI 吐出一堆代码
自己跑一下，能启动就算成功
上线

这个流程最大的问题不是 AI 写得不好，而是是是没有质量关卡是是。AI 产出的代码碰巧能跑，但没人验证它在边界条件下是否正确，也没人确认它和其他模块拼在一起会不会炸。

我之前用 Claude Code 开发一个客户管理模块，10 个任务全部用子代理并行跑完，编译全过，看起来很顺利。结果部署时才发现：SQL 脚本的列数对不上、JAR 包没重新打包、一个字段忘了赋值。这些问题在编译通过的表象下藏了好几天。

这就是 AI-coding 的工程化问题：：：AI 能写代码，但不会替你做工程。：：

目前有两个工具在尝试解决这个问题：

OpenSpec ：规格驱动开发框架。核心理念是先想清楚再写代码——需求探索 -> 生成提案 -> 执行编码 -> 质量验证 -> 归档沉淀。它管的是做什么。
Superpowers ：Claude Code 的插件，把软件工程最佳实践固化成 AI 可遵循的工作流。核心理念是 Process over Prompt——流程大于提示词。它管的是怎么做。

两者都指向同一个被忽略的环节：：：测试：：。

测试全景：不只是找 Bug

很多人对测试的理解停留在找 Bug。但测试远不止于此——它是一门涉及质量评估、风险控制与成本管理的系统性工程。

测试金字塔

经典的测试策略遵循金字塔结构：

底层（60-70%）：单元测试。针对单个函数或方法，隔离外部依赖，运行速度极快（毫秒级）。数量最多，是基石。
中层（20%）：集成测试。验证模块之间的交互——API 调用、数据库读写、消息队列。会连接真实资源，速度较慢。
顶层（10%）：端到端测试（E2E）。模拟真实用户操作，成本最高、速度最慢、维护最贵。

对 AI-coding 来说，单元测试是第一道防线。AI 写的代码逻辑可能对，也可能不对，单元测试能在毫秒级告诉你答案。

单元测试 vs 集成测试

维度	单元测试	集成测试
测试对象	单个函数/方法/类	多个模块之间的接口与交互
外部依赖	全部模拟（Mock）	尽量真实，连接数据库/网络
运行速度	极快（毫秒级）	较慢（秒级甚至分钟级）
数量	数量庞大（成千上万）	数量较少（对应核心业务流程）
定位 Bug	精确，立刻知道哪个函数错了	模糊，只知交互失败，需排查两端

一个实用原则：如果 Bug 在集成测试中被发现，先补一个单元测试来复现它，修复后再跑集成测试。这能确保同一个 Bug 永不复发。

测试四原则

尽早测试（Shift-Left）：测试不应等编码结束才开始，需求分析阶段就能发现问题。越早修，成本越低。
杀虫剂悖论：总用相同的测试用例，系统会对这些 Bug 免疫。必须定期更新测试用例。
缺陷集群性：80% 的崩溃集中在 20% 的核心模块。测试资源应重点轰炸复杂度最高的区域。
上下文依赖：没有万能测试方案。银行支付系统的测试强度不能照搬企业内部 OA。

为什么 AI-coding 更需要测试

AI 不理解业务意图，只理解模式匹配。它会写出看起来正确但逻辑有漏洞的代码——因为它是在模仿训练数据中的模式，而不是在理解你的业务规则。

测试的作用不是验证 AI 写对了什么，而是是是告诉 AI 应该写什么是是。当你先写好测试用例，AI 的行为边界就被框死了：它必须产出能通过这些测试的代码。这就是 TDD 的核心价值。

TDD：先写测试，再写代码

TDD（Test-Driven Development，测试驱动开发）是一种测试先行的开发方法论。它的核心信条：：：在编写任何生产代码之前，先编写一个会失败的测试用例。：：

红-绿-重构

TDD 严格遵循一个极短循环：

红（Red）：先写一个测试，调用你尚未实现的函数。运行测试，它必然失败。目的：确认测试有效，同时明确当前任务边界。
绿（Green）：写刚好能让测试通过的代码。不要考虑优雅，唯一目标是让测试变绿。目的：尽快获得可工作的状态。
重构（Refactor）：测试通过后，放心优化代码结构。重构过程中时刻运行测试，改坏了立刻知道。

每次循环通常只持续 1-5 分钟，小步快跑。

TDD 在 AI-coding 中的价值

用 AI 写代码时，TDD 的意义变了。传统开发中，TDD 是为了驱动设计；在 AI-coding 中，TDD 是为了了了约束 AI 的行为边界了了。

想象一下：你让 AI 写一个客户导出功能。如果不先写测试，AI 可能给你一个能跑但缺少边界处理的实现——比如没考虑空数据、没考虑特殊字符、没考虑权限校验。你得自己一个个发现这些问题。

但如果你先写好测试：

导出空数据时应该返回空文件而不是报错
客户名称包含逗号时 CSV 应该正确转义
没有导出权限的用户应该被拒绝

AI 就必须产出能通过这些测试的代码。测试用例变成了 AI 的行为规范。

真实教训：TDD 缺失的代价

我在用 Superpowers 开发客户管理模块时，10 个任务全部跳过了 TDD——先写代码，后补测试。结果：

边界条件遗漏：测试没有驱动设计，某些异常路径根本没覆盖到
兼容性问题发现太晚：Spring Boot 4.0.6 移除了 @WebMvcTest 和 @MockBean，直到补测试时才发现
测试变成了验证而非定义：后补的测试只是在确认现有代码能跑，而不是定义代码应该怎样跑

事后补测试不等于 TDD。TDD 的精髓是测试先行——测试用例定义了期望行为，代码去满足这个期望。顺序反了，效果就完全不同。

SDD：两种含义，同一个目标

SDD 在 AI 编程领域至少有两个含义，它们指向同一个目标 : 让开发过程有章可循

Spec-Driven Development（规范驱动开发）

如果说 TDD 是用测试用例驱动开发，SDD 就是用规范文档驱动开发。它主张在写任何代码之前，先用结构化的自然语言把软件要做什么、为什么做清晰定义出来。

核心工作流：

指定（Specify）：定义用户故事、验收标准
计划（Plan）：确定技术架构和实现方法
任务（Task）：将计划拆解成具体的开发任务
实现（Implement）：根据规范和计划编写代码

OpenSpec 就是这个理念的工程化实现。它的 spec.md 文件用 SHALL/MUST 这样的正式语言定义系统行为，每个 Scenario 都是一个可验证的行为契约。

Subagent-Driven Development（子代理驱动开发）

这是 Superpowers 插件里的 SDD。它的工作方式是为计划中的每一个任务都启动一个全新的、独立的子代理去执行。每个任务在干净的环境中进行，避免不同任务间的上下文污染。

任务完成后还有两阶段评审：先检查是否符合规范，再检查代码质量。

SDD 和 TDD 的关系

它们不是互斥的，而是互补的：

SDD 管做什么：需求 -> 规格 -> 设计 -> 任务清单
TDD 管做对没：每个任务内部，RED -> GREEN -> REFACTOR

一个完整的开发流程应该是：先用 SDD 写好规范，再用 TDD 保证代码质量。

OpenSpec 的 spec.md 中每个 Scenario 可以直接映射成测试用例。比如 spec 里写了按筛选条件导出和无筛选条件导出两个场景，那就是两个测试用例的骨架。

OpenSpec 和 Superpowers 如何内建测试

OpenSpec 的测试集成

OpenSpec 在三个地方把测试嵌入了开发流程：

spec.md 的 Scenario ：每个需求下面的 Scenario 天然就是测试用例。写 spec 的时候就在写测试骨架。
tasks.md 的 TDD 阶段：任务清单的第一组任务就是 TDD Red Phase——先写失败测试。
Verify 阶段：编码完成后，跑测试验收。测试不过，不允许归档。

这种设计让测试不是一个独立的活动，而是开发流程的有机组成部分。

Superpowers 的测试集成

Superpowers 通过 test-driven-development skill 强制 AI 先写测试。如果 AI 在没有先编写测试的情况下就开始写实现代码，Superpowers 会直接打断并阻止它。

在子代理驱动开发流程中，每个任务应该遵循：RED（写失败测试）-> GREEN（写实现）-> REFACTOR（优化）-> 提交。审查子代理还会验证测试是否先于实现。

但实际执行时，这个流程经常被跳过。我在复盘中发现，所有 10 个实现任务都是先写代码后补测试，审查子代理也主要做逐行对比规范，没有深入检查测试覆盖。

两者对比

维度	OpenSpec	Superpowers
测试来源	spec.md 的 Scenario 自动映射	需要手动编写或由 TDD skill 驱动
强制程度	Verify 阶段卡关	TDD skill 可被跳过
测试范围	偏向验收级别（场景驱动）	偏向单元级别（代码驱动）
适用阶段	需求定义阶段就开始	编码执行阶段才介入