AI能修bug了，TDD还有意义吗？

当大模型能自动修复bug时，我们需要重新思考软件工程的本质。

一、一个真实的场景

我看到一个实验：

大模型在执行Python脚本时，抛出了一个语法错误。

正常人可能会：

1. 看错误信息
2. 定位问题
3. 手动修复
4. 重新运行

大模型做了什么？

直接自动修复，然后继续执行。

二、震惊之后的思考

那一刻，我突然想到一个问题：

过去几十年，我们花那么大力气搞TDD、DevOps、代码审查——如果AI能自己修bug，这些还有意义吗？

三、软件工程的本质是什么？

要回答这个问题，先要问：

软件工程的本质是什么？

表面答案

软件工程 = 写代码 + 测试 + 部署 + 运维

深入一层

软件工程 = 管理复杂度 + 保障质量 + 降低风险

再深入一层

软件工程 = 让不确定的事情变得确定

四、大模型能替代什么？

五、大模型不能替代的核心能力

大模型不能替代的，是那些需要"人"来做的部分：

1. 定义正确的问题

不是"怎么修这个bug"
而是"这个bug该不该修"

不是"怎么实现这个功能"
而是"这个功能值不值得做"

大模型只会执行任务，不会质疑任务。

2. 理解业务价值

一个bug：
- 可能影响10%的用户 → 必须修
- 可能只影响0.1%的用户 → 可以先放放

大模型知道这些吗？
不知道。

大模型不知道业务优先级。

3. 做出权衡取舍

性能 vs 可读性
速度 vs 质量
功能 vs 安全

这些权衡，永远需要人来做。

4. 承担最终责任

代码出问题了，谁负责？
大模型吗？大模型不背锅。
人类工程师？人类工程师说"是大模型写的"。

责任，永远是人来承担。

六、TDD的真正价值

TDD（测试驱动开发）表面上是：

• 先写测试
• 再写代码
• 用测试保证质量

但TDD的深层价值是：

定义行为边界

当你写一个测试，你实际上是在回答：

这个函数应该做什么？
不应该做什么？
边界条件是什么？

大模型能自动修bug，但它不知道你期望的行为是什么。

七、DevOps的真正价值

DevOps表面上是：

• 持续集成
• 持续部署
• 自动化流水线

但DevOps的深层价值是：

快速反馈，频繁交付

让你知道：

• 代码改对了没有？
• 用户用起来怎么样？
• 问题能快速发现吗？

大模型能修bug，但它不能帮你收集用户反馈。

八、一个新的范式

也许未来的软件工程是这样的：

人类：定义问题、权衡取舍、承担最终责任
AI：写代码、修bug、写测试、执行部署

人类做"决策层"
AI做"执行层"

九、软件工程的新重点

当大模型能替代大部分"执行层"工作时：

十、结论

TDD和DevOps不会消失，但它们的重点会变。

过去：

用流程和工具来保障代码质量

未来：

用人的判断力来定义什么是"正确"

大模型能修bug，但定义"正确"的是人。

你怎么看？TDD还有意义吗？留言说说你的观点！

<原文链接：https://mp.weixin.qq.com/s/_tjKIxvw8D27WbjN8JBGNQ