
> AI 编程工程化实践系列 · 卷二 · 建体系 | 第 5 篇 / 共 8 篇
>
> 这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/9849121014d87ae513db8b3b1f99f6e7.png)

---

## 一、规则立好了，然后呢

前两篇我们把两件事做完了：理解层让 AI 看见项目，约束层让 AI 知道规矩。

现在有个问题绕不过去：**你怎么知道它真的照做了？**

AI 说"我给 Service 方法加了事务"，你信不信？它说"所有接口都返回统一响应体了"，你信不信？

你可以去翻代码。但三十个文件、两千行改动，你翻不过来。就算翻了，看漏一个注解也不奇怪。多数人的做法是不翻，凭信任放行，然后等联调或者线上出问题再回头查。

还有一层更实际的困难：就算你想查，也查不动。老项目跑一遍测试常常是一片红，你不知道哪些是历史债、哪些是本次引入的，于是逐个点开看，一半是环境相关的失败、一半是几年前的过期断言。这个排查过程每次改完都要重复一遍。

验证层就是来堵这个口子的。它的目标只有一句话：**用自动化手段确认 AI 的产出确实符合预期。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/d758dfde3547e2687b3c17f63450c7ae.png)

## 二、行为基线：先锁住行为，再改代码

这个概念听起来学术，操作起来是三步。

**第一步，改动之前跑一遍全量测试。** 记下基线：通过 x 个、失败 y 个、跳过 z 个。这一步必须在动任何一行代码之前做，做完先别急着改，把这份基线存住。

**第二步，AI 分批改动。** 每批 1-3 个文件，改完立刻验证。

**第三步，改完再跑一遍全量测试，跟基线对比。**

就这么简单。但这一步带来的差别是决定性的：**有基线，任何新增的失败都直接指向本次改动**；没基线，测试挂了，你第一反应是"这个测试是不是本来就挂的"，然后花半小时去查历史。

有了基线快照，上面那段排查就省掉了：改动前是 20 个红，改动后还是 20 个红，这次没引入新问题，收工。改动后变成 23 个红，那三个一定是这次改出来的，只在本次改动的文件里找。

### 不是让你写更多测试

这里有个常见误解：以为行为基线要求你把测试补全。

不是。行为基线用的是**你已有的测试**，一份不多写。它的价值在于把已有测试从"跑着玩的"变成"可对比的标尺"。

当然，如果你的项目测试覆盖率本来就低，这一步的效果会打折扣，挂的测试少，能捕捉到的回归也少。这种情况下不用急着补测试，先做两件事：把基线的机制跑起来，然后在后续每次改动里顺手补上跟本次改动相关的用例。测试是跟着项目长出来的，一次性补全会变成另一个烂尾工程。

### 两种失败，两种处理

对比基线发现有新增失败，只有两种可能：

- **AI 真的改坏了。** 修正约束，让它重新生成。注意是改规则，不是改代码：这次改代码，下次它还这么写。
- **这个测试本身脆弱。** 依赖了执行顺序、依赖了具体时间戳、断言写得太死。修测试本身。

两种都要处理，处理方式完全不同。分不清的话，看失败用例跟本次改动有没有交集：毫无关系的模块挂了，多半是脆弱测试；改动涉及的模块挂了，多半是真改坏了。

## 三、CI 三道门禁：让机器做机器的活

行为基线解决"是不是这次改坏的"，CI 门禁解决"够不够格合入"。

代码提交之后，不要让人手动检查。让 CI 自动跑三件事：

| 检查项 | 作用 | 最小化实现 |
|--------|------|-----------|
| 编译检查 | 确保没有语法错误和缺失依赖 | `mvn compile` / `npm run build` |
| 自动测试 | 确保没有破坏已有功能 | `mvn test` / `npm test` |
| 规范检查 | 确保符合团队编码标准 | Checkstyle / ESLint / SpotBugs |

三件事是流水线串行的，任何一项失败，整个提交就不允许合并。

这里有一条理念值得单独说：**AI 生成的代码必须通过跟人手写代码完全相同的质量门槛。**

不少团队对 AI 代码会不自觉地降低标准：反正是 AI 写的，跑通就行，命名乱一点无所谓，注释没有也算了。这个口子一开就收不住。AI 代码和人工代码的唯一区别是作者，不是质量标准。标准只有一套，门禁只有一道，谁的都拦。

三道门禁的最小化配置，一个 Maven 项目大概是这样：

```yaml
# .gitlab-ci.yml 片段
stages:
  - build
  - test
  - lint

compile:
  stage: build
  script: mvn -q compile

unit-test:
  stage: test
  script: mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml

checkstyle:
  stage: lint
  script: mvn checkstyle:check
```

配好之后，AI 写完一批代码，你不用问它"编译过了吗"，流水线会告诉你。

## 四、两个机制各管一件事

行为基线和 CI 门禁容易混为一谈，其实它们回答的是两个不同的问题。

**基线是相对判断**：这次改动有没有让情况变坏？它跟项目自己的历史状态比，不关心绝对水平。一个常年 20 个红的老项目，照样能建立有意义的基线——改动后变成 23 个红，就知道出问题了。

**门禁是绝对判断**：这份代码够不够格合入？它跟团队定死的标准比，不关心历史。编译不过就是不过，不管你改动前是不是也编译不过。

两个都要有，原因很实在：

只有门禁没有基线，老项目会常年红灯。红灯挂久了，大家会默认"CI 红了是正常的"，门禁从此形同虚设。这种退化一旦发生就很难逆转，因为没人再相信那条流水线。

只有基线没有门禁，你知道这次没改坏，但不知道这份代码本身够不够好。日志没带 traceId、命名不合规、循环里查库，这些基线全绿也照样漏。

顺带说一句：如果老项目的 CI 已经常年红，别急着修全部。先把基线机制跑起来，让"有没有改坏"这件事先有答案，再花时间把历史红灯一个个清掉。

## 五、测试通过不等于代码正确

这是验证层最大的一个坑，值得单独一节。

**AI 可能写出能通过测试、但逻辑错误的代码。**

最常见的形式是硬编码测试期望值。你让它实现一个分页查询，它写了实现，也写了测试。测试通过了。你一看实现，分页逻辑是对的；再看测试，测试数据是它自己造的，断言的也是它自己算出来的结果。两处错互相印证，测试绿了，代码是错的。

还有一种更隐蔽：AI 为了让测试通过，改了测试的断言。你让它改一个排序逻辑，它改完发现测试挂了，于是它把测试的期望顺序也改了。测试绿了，业务逻辑反了。

这两种，门禁都拦不住。所以**人工验收这一步不能省**，重点看三件事：

1. **接口签名跟方案阶段锁定的契不契约。** AI 可能在实现阶段自作主张把 GET 改成了 POST，理由还挺合理。
2. **业务规则有没有实现完整。** 对照需求阶段列的验收标准逐项过。这条最花时间，也最值得花。
3. **有没有非预期改动。** 用 `git diff` 扫一遍文件列表，确认它没有动不该动的地方。这一步三十秒，能救回不少事。

## 六、验证层在体系里的位置

到这里，SDD 三层约束就齐了：

```
理解层（让 AI 看见）→ 约束层（让 AI 听话）→ 验证层（让 AI 可信）
```

三层是递进关系，缺一层都不稳：

- **没有理解层**，AI 连项目长什么样都不知道，约束层写得再细也没用，它不知道那些规则该用在哪。
- **没有约束层**，AI 自由发挥，验证层要拦的 bug 多到让你怀疑人生，最后你只能放宽门禁，门禁就废了。
- **没有验证层**，前两层的约束没有被自动化检验。AI 到底遵不遵守，你其实不知道，你只是希望它遵守。

这三层都是一次性建设的前置资产。建好之后，后面每一次开发任务都在调用它们，不用重来。

还有一层变化值得说：**门禁立起来之后，AI 的行为会跟着变。**

第 3 篇讲过，AGENTS.md 的"怎么跑起来"那一节要写到 AI 能自己验证——健康检查端点、核心接口的 curl 范例、自检脚本。配上门禁之后，这些就派上用场了：AI 改完代码能自己跑一遍，看到失败自己修，修完再跑，直到通过再交给你。

流程从"你让它改，改完你来验"变成"它改完自己验，验不过自己修，验过了再交给你"。你从验证者变成验收者，这是两个人天的工作量差。

前提是它得有可执行的验证命令和读得懂的失败输出。命令不可执行，或者输出是一堆看不懂的堆栈，它就只能停下来问你。

## 七、如果你现在什么都没有

有个现实问题：很多项目既没有测试，也没有 CI。三道门禁配不起来，是不是这套就做不了？

能做的部分还很多，按性价比排：

1. **先把编译检查配上。** 一条 `mvn compile`，五分钟，能拦掉 AI 最高频的一类错误（漏 import、用错 API 版本）。
2. **再配规范检查。** Checkstyle 用现成规则集（sun_checks 或 google_checks）先跑起来，不用自己写规则。
3. **测试从零开始，就先给核心链路写。** 挑三五个最怕改坏的接口，各写两三个用例。有了这些，基线快照就有意义了。
4. **人工验收先别省。** 门禁不全的时候，git diff 那三十秒就是你唯一的验证层。

这套东西是渐进的。先有一道门禁，就比没有强；有一道之后再加第二道，比一次配三道容易得多。

## 八、可带走的三件事

1. **改动前先存基线**：跑一遍全量测试，记下通过/失败/跳过数。没有这个快照，你分不清测试失败是历史债还是本次引入的。
2. **三道门禁一个标准**：编译、测试、规范串行，任一失败不许合并。AI 代码和人工代码过同一道门槛，不要给 AI 代码开后门。
3. **测试通过不等于代码正确**：AI 可能硬编码期望值、可能改测试断言来迁就实现。人工验收查三处：契约一致性、业务规则完整性、git diff 有没有非预期改动。 有没有非预期改动。

## 下一篇预告

**第 6 篇：《从一句话需求到归档：六步工作流的完整链路》**

理解层、约束层、验证层，这三层资产建好了。但它们是静态配置，放在仓库里不会自己动。

下一篇讲怎么把它们串成一条流水线：从产品经理一句话需求开始，到代码合入、经验沉淀为止，六个步骤每一步做什么、调用哪层资产、你在哪一步必须介入。前面五篇建的东西，在那条流水线上会被逐个激活。


这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

让 AI 可信：行为基线测试 + CI 三道门禁

规则立好了，怎么知道 AI 真照做？改动前先跑一遍全量测试存下基线，改完再跑对比；CI 加编译、测试、规范三道门禁，AI 代码和人工代码过同一道门槛。但有个坑机器拦不住：测试全绿，代码也可能是错的。

人工智能

开发工具

测试

AI编程工程化实践：验证层核心机制解析。本文聚焦如何通过行为基线对比与CI三道门禁（编译、测试、规范），将AI代码产出从"碰运气"转为"可预期"。详解基线快照锁定、失败分类处理、最小化配置方案，并强调测试通过不等于代码正确，需人工验收契约、规则及diff。提供渐进式落地路径，适合存量项目改造。

代码解释

AI编程

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

让 AI 可信：行为基线测试 + CI 三道门禁-腾讯云开发者社区-腾讯云

让 AI 可信：行为基线测试 + CI 三道门禁

让 AI 可信：行为基线测试 + CI 三道门禁

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐