摘要
随着大语言模型和 Coding Agent 的快速发展，软件开发正在从“程序员手工编写代码”的模式，逐步转向“人定义目标、AI理解任务并执行代码修改、自动化系统持续验证”的新型协作模式。
这一变化带来的最大问题，并不是 AI 是否能够生成代码，而是：
当代码生成速度远远超过人工审查速度之后，传统的软件开发工作流是否仍然适用？
传统开发流程通常以代码编写为中心：
需求 → 设计 → 编码 → 编译 → 测试 → 调试 → 发布
而在 AI Coding Agent 参与以后，代码编写本身已经不再是最主要的瓶颈。新的瓶颈逐渐转向：
-
需求理解是否准确；
-
AI 是否理解现有系统；
-
修改范围是否合理；
-
AI 是否改变了原有行为；
-
测试是否真正覆盖需求；
-
AI 是否能够根据测试结果自主修复；
-
修改是否引入新的回归问题；
-
人类是否能够有效审查 AI 的大量代码变更。
因此，需要重新设计开发工作流。
本文从软件开发生命周期出发，提出 Behavior-Driven AI-TDD（行为驱动的 AI 测试开发） 工作流，将传统的需求、设计、编码、测试、Code Review、CI/CD 等阶段重新组织为一个以“行为”为核心、以 AI Agent 为执行主体、以自动化测试为验证机制的闭环系统：
需求 → 行为定义 → 上下文构建 → 测试设计 → AI实施 → 自动编译 → 自动测试 → AI修复 → 回归验证 → 人工审查 → 提交 → 行为资产沉淀
其核心目标不是让 AI 替代开发人员，而是将开发人员从大量机械编码和调试工作中解放出来，将更多精力集中到需求、架构、行为边界和工程决策上。
一、开发工作流正在发生变化
传统软件开发的工作流具有非常明显的人工驱动特征。
┌──────────┐
│ 需求 │
└────┬─────┘
↓
┌──────────┐
│ 设计 │
└────┬─────┘
↓
┌──────────┐
│ 编码 │
└────┬─────┘
↓
┌──────────┐
│ 编译 │
└────┬─────┘
↓
┌──────────┐
│ 测试 │
└────┬─────┘
↓
┌──────────┐
│ 调试 │
└────┬─────┘
↓
┌──────────┐
│ CodeReview│
└────┬─────┘
↓
Git提交
这个流程有一个隐含假设：
程序员是主要的代码生产者。
因此：
程序员时间
=
需求理解
+
代码编写
+
调试
+
测试
+
维护
但是 AI Coding Agent 出现以后：
代码编写成本 ↓↓↓
例如，一个 Agent 可以一次完成：
搜索代码
→ 理解调用关系
→ 修改多个文件
→ 添加测试
→ 编译
→ 分析错误
→ 修复
→ 再测试
于是传统流程的核心瓶颈开始发生变化。
二、AI 时代真正的瓶颈从“写代码”转向“控制变化”
这是理解 Behavior-Driven AI-TDD 的关键。
传统开发最担心：
“代码写不出来。”
AI 开发更需要担心：
“AI 修改了太多代码，而且不知道修改是否真正正确。”
例如开发人员提出：
“修复共享边界不一致的问题。”
AI 可能修改：
BoundaryGenerator.cpp
GeometryUtils.cpp
VertexRegistry.cpp
GISConverter.cpp
甚至进一步修改：
10个文件
代码可能能够编译。
但是：
原有行为
↓
发生变化
问题可能直到几天甚至几周以后才被发现。
因此 AI 开发需要增加一个新的核心概念：
Change Control
即：
控制 AI 产生的软件变化。
而控制变化最有效的方法之一就是：
行为定义 + 自动化测试。
三、开发工作流需要增加“行为层”
传统流程：
需求
↓
设计
↓
编码
↓
测试
Behavior-Driven AI-TDD：
需求
↓
行为定义
↓
验收标准
↓
测试
↓
AI实施
↓
自动验证
这里增加了一个关键中间层：
Requirement
↓
Behavior
↓
Implementation
为什么需要 Behavior？
因为：
需求描述的是“我要什么”，代码描述的是“怎么实现”，而 Behavior 描述的是“系统应该如何表现”。
例如：
需求
增加 GDB 字段读取功能。
行为
打开GDB
↓
遍历Layer
↓
读取Field
↓
获取名称、类型、宽度、精度
↓
返回字段信息
测试
Layer数量正确
Field数量正确
Field名称正确
Field类型正确
Field属性正确
于是 AI 就有了清晰的执行边界。
四、Behavior-Driven AI-TDD 的完整开发工作流
整体工作流可以设计成：
┌─────────────┐
│ 开发需求 │
└──────┬──────┘
↓
┌─────────────┐
│ 需求澄清 │
└──────┬──────┘
↓
┌─────────────┐
│ 行为定义 │
└──────┬──────┘
↓
┌─────────────┐
│ 测试设计 │
└──────┬──────┘
↓
┌─────────────┐
│ AI代码实施 │
└──────┬──────┘
↓
┌─────────────┐
│ 自动编译 │
└──────┬──────┘
↓
┌─────────────┐
│ 自动测试 │
└──────┬──────┘
↓
┌─────────────┐
│ 结果分析 │
└──────┬──────┘
↓
┌────┴────┐
│ │
FAIL PASS
│ │
↓ ↓
AI自动修复 人工审查
│ │
└────┬────┘
↓
Git提交
↓
行为资产沉淀
这个流程可以分成 10 个阶段。
五、阶段一：需求进入
开发人员首先提出自然语言需求。
例如：
修改 DOM 镶嵌边界生成模块，使相邻 DOM 的公共边界完全一致。
传统方式下，程序员可能直接打开：
BoundaryGenerator.cpp
开始修改。
AI-TDD 不应该这么做。
第一步应该是：
理解需求，而不是立即修改代码。
六、阶段二：需求澄清
AI Agent 首先分析：
需求是什么？
涉及哪些模块？
现有代码在哪里？
已有行为是什么？
有哪些约束？
是否存在已有测试？
例如：
需求：
共享边界一致
涉及：
BoundaryGenerator
VertexRegistry
GEOS Intersection
Voronoi
约束：
不能改变现有接口
不能修改第三方库
不能影响已有DOM边界
这一步可以称为：
Requirement Understanding
其结果不是代码，而是：
Requirement Specification
七、阶段三：行为定义
接下来把自然语言需求转换成行为。
例如：
行为ID：
DOM-BOUNDARY-001
行为：
相邻DOM共享边界一致
输入：
两个具有空间重叠或相邻关系的DOM
预期：
两者共享边界具有相同的坐标序列
允许误差：
1e-10
异常：
无效Geometry必须被拒绝
进一步可以定义：
正常行为
边界行为
异常行为
拓扑行为
数值行为
最终形成：
Behavior Specification
八、阶段四：建立验收标准
Behavior 不能停留在自然语言。
必须进一步转化成：
Acceptance Criteria
例如：
AC-001
共享边界顶点数量一致。
AC-002
共享边界坐标一致。
AC-003
允许的浮点误差不超过1e-10。
AC-004
Polygon必须有效。
AC-005
不能产生新的重叠区域。
AC-006
原有非共享边界不能发生变化。
此时开发人员实际上已经回答了：
什么情况下可以认为这个任务完成？
九、阶段五：测试设计
接下来 AI 可以根据 Behavior 自动生成测试。
例如：
Test-001
正常共享边
Test-002
反向共享边
Test-003
多个共享节点
Test-004
重复节点
Test-005
浮点误差
Test-006
空Geometry
Test-007
无效Polygon
Test-008
三个Polygon共节点
这里非常重要：
测试是在 AI 编写业务代码之前确定的。
这就是 TDD 的核心思想。
十、阶段六：AI 建立代码上下文
测试定义之后，AI 才开始进入代码库。
此时 Agent 不应该简单读取整个项目。
应该建立：
Task Context
例如：
任务：
DOM共享边界修复
相关代码：
BoundaryGenerator.cpp
BoundaryGenerator.h
VertexRegistry.cpp
GeometryUtils.cpp
相关测试：
BoundaryTest.cpp
依赖：
GEOS
CGAL
相关Behavior：
DOM-BOUNDARY-001
这比把整个代码仓库一次性塞进大模型上下文更加有效。
十一、为什么“上下文工程”是 AI-TDD 的重要组成部分
AI 生成代码的质量高度依赖上下文。
上下文至少包括：
源代码
+
调用关系
+
接口
+
行为
+
测试
+
历史Bug
+
编译环境
+
第三方依赖
因此：
AI-TDD 本质上也是 Context Engineering。
可以把 AI Agent 的输入理解成：
AI Context
=
Code Context
+
Behavior Context
+
Test Context
+
Environment Context
+
History Context
十二、阶段七：AI 实施代码
现在才允许 AI 修改代码。
但是必须遵守：
原则一：最小修改
原则二：保持已有 API
原则三：不修改无关模块
原则四：不得删除已有测试来获得 PASS
原则五：行为变化必须明确记录
例如 Agent 提交：
Files changed: 3
BoundaryGenerator.cpp
VertexRegistry.cpp
BoundaryTest.cpp
而不是：
Files changed: 27
如果修改范围明显扩大，应该要求 Agent 重新解释原因。
十三、阶段八：自动编译
代码修改完成后：
AI
↓
Build
对于 C++ 项目，这一步尤其重要。
因为 C++ 存在大量 AI 单纯文本分析难以发现的问题：
模板错误
链接错误
ABI错误
Runtime Library冲突
DLL依赖
头文件依赖
Qt MOC/UIC
GDAL版本
GEOS版本
CGAL模板
因此：
编译器本身就是 AI-TDD 的第一层验证器。
十四、阶段九：自动测试
编译成功以后：
Unit Test
↓
Integration Test
↓
Behavior Test
↓
Regression Test
例如：
Build
PASS
Unit
42/42 PASS
Boundary
8/8 PASS
GIS Integration
16/16 PASS
Regression
281/281 PASS
此时才认为：
Implementation
↓
满足当前Behavior
十五、阶段十：AI 自动修复
如果测试失败：
Test
↓
FAIL
不要立即让开发人员人工处理。
可以先让 AI Agent 分析：
失败测试
↓
错误日志
↓
Stack Trace
↓
Diff
↓
相关Behavior
↓
定位代码
↓
提出修复方案
例如：
Failure:
SharedEdgeTest::ThreePolygonNode
Expected:
3 unique vertices
Actual:
4 vertices
Analysis:
VertexRegistry未对交点进行统一量化。
Repair:
统一使用snapEps进行顶点归一化。
然后：
AI修复
↓
Build
↓
Test
形成：
自动修复循环
┌───────────┐
│ AI Modify │
└─────┬─────┘
↓
Build
↓
Test
↓
FAIL
↓
AI Analyze
↓
AI Repair
↓
└────────→ Build
十六、什么时候停止 AI 自动修复
不能让 Agent 无限循环。
建议定义：
最大修复次数：3～5次
例如：
Attempt 1 → FAIL
Attempt 2 → FAIL
Attempt 3 → PASS
如果：
Attempt 5 → FAIL
则：
STOP
↓
Human Review
同时生成：
AI Failure Report
包括：
失败行为
失败测试
尝试过的修改
失败原因
当前代码状态
建议人工处理方向
十七、阶段十一：人工 Code Review
AI-TDD 并不是取消 Code Review。
而是改变 Code Review 的重点。
传统 Review：
这一行代码写得对不对？
AI-TDD Review：
行为定义对不对？
测试覆盖够不够？
AI修改范围是否合理？
是否引入隐藏行为变化？
架构是否受到影响？
也就是说：
人从“逐行检查代码”逐渐转向“检查行为、设计和风险”。
十八、AI Code Review 应该关注什么
可以让第二个 AI Agent 或独立 Review Agent 检查：
1. API是否发生变化？
2. 是否修改无关文件？
3. 是否删除测试？
4. 是否降低测试标准？
5. 是否扩大容差？
6. 是否增加不必要依赖？
7. 是否改变错误处理？
8. 是否改变线程模型？
9. 是否改变资源生命周期？
10. 是否破坏已有行为？
特别是：
不能允许 AI 通过降低测试标准来让测试通过。
例如：
原来：
epsilon = 1e-10;
AI 修改成：
epsilon = 1e-3;
测试通过了。
但实际上：
Test PASS
Behavior FAIL
因此必须把关键参数纳入 Behavior Specification。
十九、阶段十二：Git 提交
通过：
Build
+
Test
+
Regression
+
Review
之后才能提交。
Commit 信息也可以由 AI 自动生成：
fix: ensure shared DOM boundaries are consistent
Behavior:
DOM-BOUNDARY-001
Tests:
8 added
Regression:
281 passed
API:
unchanged
Dependencies:
unchanged
这样 Git Commit 就不再只是：
fix bug
而是：
一个经过行为验证的软件变更记录。
二十、阶段十三：行为资产沉淀
传统开发完成之后：
代码进入Git
AI-TDD 完成之后：
代码
+
Behavior
+
Test
+
Result
+
Bug
+
修复历史
全部进入项目知识体系。
例如：
DOM-BOUNDARY-001
│
├── Test-001
├── Test-002
├── Test-003
│
├── BoundaryGenerator.cpp
│
├── Bug-2026-001
│
└── Commit-a82f31
下一次 AI 再修改这个模块时，就可以自动获得历史经验。
二十一、这样就形成了真正的研发闭环
整个生命周期变成：
┌──────────────────┐
│ Requirement │
└────────┬─────────┘
↓
┌──────────────────┐
│ Behavior │
└────────┬─────────┘
↓
┌──────────────────┐
│ Tests │
└────────┬─────────┘
↓
┌──────────────────┐
│ AI Coding │
└────────┬─────────┘
↓
┌──────────────────┐
│ Build │
└────────┬─────────┘
↓
┌──────────────────┐
│ Test │
└────────┬─────────┘
↓
PASS / FAIL
/ \
/ \
FAIL PASS
↓ ↓
AI Diagnosis Human Review
↓ ↓
AI Repair Git Commit
│ ↓
└──────→ Behavior Repository
二十二、这实际上改变了开发人员的工作内容
传统开发人员：
30% 需求
50% 编码
20% 测试调试
AI 辅助以后，比例会发生变化。
未来更加合理的工作分配可能是：
需求理解
↓
行为设计
↓
架构设计
↓
AI任务拆解
↓
AI实施
↓
验证
↓
Review
也就是说：
程序员的核心能力将从“写代码”逐渐向“定义正确的软件行为、约束 AI、判断工程风险”转移。
二十三、对于大型存量项目意义尤其明显
对于新项目：
AI-TDD
比较容易实施。
但是对于大型老项目，它的价值可能更大。
例如一个十年以上的 C++ 项目：
100万行代码
+
大量历史模块
+
Qt
+
GDAL
+
GEOS
+
CGAL
+
OpenCV
+
Visual Studio
开发人员通常不敢轻易修改。
因为：
不知道谁调用
不知道影响谁
不知道为什么这么写
不知道哪里有隐含依赖
不知道以前修过什么Bug
AI 也同样存在这个问题。
因此老项目更需要：
Behavior Discovery
也就是：
先从现有代码和测试中反向提取系统行为。
二十四、Legacy Code 的 AI-TDD 工作流
可以采用：
旧代码
↓
AI分析
↓
识别已有行为
↓
生成Characterization Tests
↓
测试当前版本
↓
建立行为基线
↓
AI开始修改
↓
Regression
这里的关键技术是：
Characterization Test
即：
先记录系统现在实际表现出来的行为。
不一定判断当前行为是否优秀。
首先回答：
“现在系统到底是怎么工作的？”
然后再逐步改进。
二十五、这对 C++/Qt/GDAL 项目非常适合
例如一个旧的：
GDBHandler::loadGDB()
首先不要让 AI 直接重写。
可以让 AI：
1. 分析函数
2. 找出调用方
3. 找出返回值
4. 找出异常处理
5. 找出UI依赖
6. 找出GDAL依赖
7. 生成Characterization Test
建立当前行为：
Behavior:
GDB-LOAD-BASELINE
然后再提出：
新需求：
读取全部字段
于是：
旧行为
+
新行为
+
回归测试
共同约束 AI。
二十六、从“需求驱动开发”转向“行为驱动开发”
传统：
Requirement
↓
Code
AI时代：
Requirement
↓
Behavior
↓
Test
↓
AI
↓
Code
这意味着：
Behavior 成为 AI 与软件工程之间的接口。
人类不需要告诉 AI 每一行怎么写。
人只需要明确：
系统应该做什么
不能做什么
什么情况下算成功
什么情况下必须失败
哪些旧行为绝对不能改变
剩下的实现可以交给 Agent。
二十七、最终可以形成“AI 软件工厂”
如果进一步自动化，可以形成：
Requirement
│
▼
┌───────────────┐
│ Behavior Agent│
└───────┬───────┘
↓
Behavior Store
│
┌─────────┴─────────┐
↓ ↓
Test Generator Context Builder
│ │
└─────────┬─────────┘
↓
Coding Agent
│
↓
Builder
│
↓
Test Runner
│
┌───────┴───────┐
↓ ↓
FAIL PASS
↓ ↓
Repair Agent Review Agent
│ │
└───────┬───────┘
↓
Git Agent
│
↓
Knowledge Store
这已经不再是简单的：
AI Coding Tool
而是：
AI Software Engineering System
二十八、开发工作流的核心变化
可以把传统开发与 Behavior-Driven AI-TDD 做一个对比。
| 开发环节 | 传统开发 | AI-TDD |
|---|---|---|
| 需求 | 人理解 | 人+AI分析 |
| 设计 | 人完成 | 人定义架构，AI辅助 |
| 行为 | 隐含在代码中 | 显式定义 |
| 测试 | 编码后测试 | 行为定义后测试 |
| 编码 | 人为主 | AI为主、人监督 |
| 编译 | 人工/CI | Agent自动执行 |
| 调试 | 人工为主 | AI+自动测试 |
| 回归 | CI | AI Agent+CI |
| Review | 逐行检查 | 行为+风险+Diff |
| Git | 保存代码 | 保存代码+行为历史 |
| 知识 | 文档/代码 | Behavior+Test+Code+History |
二十九、最终形成新的软件开发循环
传统：
Think
↓
Code
↓
Debug
AI时代：
Define
↓
Specify
↓
Test
↓
Generate
↓
Execute
↓
Verify
↓
Repair
↓
Review
↓
Learn
其中最关键的变化是：
Code 不再是开发流程的中心。Behavior 才是中心。
三十、结论
Behavior-Driven AI-TDD 并不是简单地将 TDD 和大语言模型拼接在一起。
它真正改变的是：
软件开发工作流本身。
传统软件工程的核心流程是：
需求
↓
设计
↓
编码
↓
测试
↓
发布
而大模型时代可以进一步演变为：
需求
↓
行为定义
↓
验收标准
↓
测试设计
↓
AI上下文构建
↓
AI实施
↓
自动编译
↓
自动测试
↓
AI诊断
↓
AI修复
↓
回归测试
↓
人工审查
↓
Git提交
↓
行为知识沉淀
这个变化的本质不是：
“让 AI 替程序员写代码。”
而是：
“重新设计人、AI、代码、测试和工程系统之间的协作关系。”
在这个体系中：
人
负责目标、需求、架构和边界
AI
负责分析、实现、调试和重复性工程工作
Behavior
负责定义系统应该表现出的行为
Test
负责验证行为
Compiler
负责验证代码能否被正确构建
CI/CD
负责持续执行验证
Git
负责记录变化
Knowledge Base
负责沉淀历史行为和工程经验
最终形成：
人
│
定义目标
↓
Behavior
↓
Test
↓
AI
↓
Implementation
↓
Verification
↓
┌──────┴──────┐
↓ ↓
FAIL PASS
↓ ↓
AI修复 Review
│ ↓
└──────→ Git
↓
Knowledge Base
│
└────→ 下一次开发
因此，Behavior-Driven AI-TDD 最重要的价值不是提高代码生成速度，而是建立一个能够约束、验证、追踪和持续学习的 AI 软件开发闭环。
对于 C++、Qt、GIS、遥感、点云、计算机视觉以及其他拥有复杂历史代码和大量第三方依赖的工程系统，这种工作流尤其具有价值。
它最终追求的不是：
AI 写更多代码。
而是：
AI 在明确的软件行为和自动化验证体系中，以更小的修改成本、更低的回归风险和更高的可追溯性完成软件工程任务。
这可能是大模型从 AI Coding Assistant 走向真正 AI Software Engineer / Software Engineering Agent 的一个重要发展方向。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/llhllq2015/article/details/166589267
