现在有人用 TDD 测试驱动来配合 AI 开发吗

看语言吧，像 C 这样的特性简单的语言应该可行，测函数很好，没状态，输入输出是确定的。

但是 OOP 语言中的对象有内部状态，更复杂，写好测试也有挑战，大概代码量比业务代码还多。那还不如自己写，让 AI 生成测试。

我现在就是让 AI 生成测试。

私以为这就没有必要了吧。 本来就是相信 ai 写得更好的，既然它能写好我就没有必要花时间去写测试了吧

首先你得定位你的 AI 指的啥？ LLM 还是 Agent ，如果是 LLM ，有必要搞 TDD ？ LLM 是可以无限喂养，自我学习，答案都没有唯一的吧，搞 TDD 能行？如果是 Agent ，TDD 仅限于业务上下文的支撑，最终解释权还是 LLM 。我随口说说，莫要取笑！

我在做的是`文档驱动开发` 其中文档也是 AI 写的。
反驳一下楼上认为没必要的理由：
1. AI 健忘，所以必须有固定不会遗忘的参考点，例如文档或单元测试。
2. AI 会的太多，它不知道自己应该在编码员，还是主程还是架构师层面来帮你完成你的想法，所以你需要明确它应该怎么做，如果你让它完成这些测试用例的开发，那么它就是编码员，如果你用需求文档作为参考点，它就工作在架构师层面，如果你用 API 文档，它可能工作在主程层面。

对于复杂的功能点，我也选择用测试用例去固化接口行为，然后优化修改实现代码。虽然不太符合楼主说的 TDD ，但实践证明，测试用例在 AI 编程中具有现实意义。
（温馨提示：1AI 会在无法跑通用例时修改用例，2AI 有事会偷懒用 Mock 实现来跑通用例，所以监督开发在当前阶段还是必须项，这也是我们大部分程序员暂时还没失业的原因，偷着笑吧）

使用 AI 一定是有方法有策略的，绝不是一些人说的怎么用都一样，全靠大模型能力。

参考： https://zhuanlan.zhihu.com/p/29042557398

一句话总结: TDD 用于 AI 编程是有利无害的技巧。

我也在摸索一种测试方案来让 AI 开发的行为“可预期”。t/1119929
但直接 TDD 套过来，至少大型项目还是挺痛苦的，毕竟 TDD 对架构理解的要求其实挺高的，与此同时很多设计模式的抽象说白了是给人看的，对 LLM 来说其实没啥意义。
个人认为还是需要模式某种 TDG(Test-Driven Generate), 更贴近定义和管理需求，而不是约束实现。