从 Vibe Coding 到 TDD，但是还不够QAQ
- 内容介绍
- 文章标签
- 相关推荐
初始状态：探索与验证
去年十一月初次接触 Vibe Coding 时，我主要利用 Cursor 来快速实现和验证创意。那时的工作流非常直观，核心在于“AI 生成，人工兜底”。
我依然保持着细致的 Code Review 习惯，当时的开发闭环大致如下：
graph LR
A(提出想法) --> B[AI 编码]
B --> C[程序运行]
C --> D{发现 Bug?}
D -- 是 --> E[让 AI 修复]
E --> C
D -- 否 --> F(开发完成)
F --> G[人工 Code Review]
人到中年 遇到瓶颈，力不从心
随着项目深入，AI 生成的代码量呈指数级增长，完全碾压了我人工编写的速度。很快，我发现了一个严峻的问题：我甚至很难在有限时间内读完 AI 生成的代码
当时很多平台都有人遇到类似的问题，当时大家比较热衷使用 多 Agent 编排 来解这个问题。最初我尝试跟随主流方案，使用多个 Agent 甚至调用不同模型来交叉审阅代码，但是 效果不及预期。我觉得这还挺反直觉的：Token 消耗剧增，成本飙升，但代码质量的提升却非常有限。
现在的状态：回归 TDD 思维
现在我用类似 TDD 的思路来驾驭 AI，感觉效果暴增。
针对新项目或新创意，在让 AI 动手写代码之前，我强制自己先完成以下“前置思考”步骤：
- 明确目标： 先想清楚最终想要达到的效果是什么。
- 界定边界： 厘清各个功能之间的边界在哪里。
- 划分模块： 给各个功能划分出明确的物理或逻辑边界。
- 梳理关系： 明确各个功能模块之间的组织与依赖关系。
- AI 生成用例： 基于以上四点，让 AI 先生成一份测试用例文档。
- 人工修正： 针对 AI 生成的测试用例进行人工补充和修正，确保逻辑严密。
- 任务布置： 给 AI 布置具体任务，并设立硬性指标——每次生成的代码必须能跑通所有测试。
我不确定这种使用方式是否算某种局部最优解，但在实际体感上，这种 测试先行 的模式确实speed up了我日常的开发工作，大部分时候AI生成的代码可以稳定地run起来。
新的问题
除了项目开发以外，平时还会有一些模型训练的工作，在这个case下，我感觉这种TDD的思路有点拉闸——通过某些指标是可以judge一次训练是否是ok的，但是很难去juedge这一次生成的代码是否符合我想它验证的猜想。
举个例子：
我想验证在loss中加入某个指标是否能提升视频生成的一致性，直接让AI做了代码实现。整个过程都很正常，它会自己识别一些问题让我做选择，训练也正常run起来了，但是我发现指标一点变化都没有，我觉得很奇怪，最后发现 AI 竟然把这个指标加在了 no_grad 里…
Vibe Coding真是让我又爱又恨。。。期待各位佬能一起分享下使用经验，一起看看有没有更好的使用方法，让 工作 摸鱼效率更上一层楼
--【壹】--：
我也遇到类似的问题了，感觉暂时没有通用的比较好的解决方法
--【贰】--：
感谢实践经验的分享 让我脑中的想法有了更清晰的路径
--【叁】--：
补充一个点，让AI先根据需求生成方案，审阅之后让它持久化下来，在后续让它自己去和写下来的方案去做比较，看看是否有遗漏。
--【肆】--：
好好维护skill文档确实是个很好的思路，感谢分享
--【伍】--：
确实，感觉AI在模型训练和其它相关代码编写很容易胡编乱造，佬有想到什么办法约束吗
--【陆】--：
我的做法不太一样——没走多 Agent 审阅那条路，走的是给 AI 加「记忆」。
具体来说就是写 skill 文件，markdown 格式，告诉 AI 项目的架构规范、代码风格、已经踩过的坑。40 多个 skill 文件跑了大半年，现在 AI 生成的代码基本不会偏离项目规范，review 的时候只需要看业务逻辑对不对，不用再纠结格式和架构问题。
跟 TDD 的思路其实是互补的。TDD 管的是"代码行为对不对"，skill 文件管的是"AI 知不知道该怎么写"。一个管结果，一个管过程。
不过 skill 也有成本——前期写这些文件挺花时间的，而且要持续维护。但到了第 20、30 个文件的时候，复利效应就出来了，新项目启动基本不需要从零教 AI。
--【柒】--：
哎，是的啊，难啊
--【捌】--：
概述来说就是 好好构造提示词。
我现在日常使用是这样的：我先提出假设，让ai帮我做编码实现，然后我观察结果。每次给指令之前我都会好好编辑一下，尤其是第一次下比较overall的指令的时候，所以胡编乱造的case相对没这么多。
我看到有人用agent实现了，从假设提出到编码实现再到最后结果分析的一条龙，感觉还挺厉害的，但是我感觉这种case下会有胡编乱造的情况出来。而且我是偏工程侧的，不是纯做研究，所以很多“水论文”的点子不是很适合我
--【玖】--：
期待你的分享
--【拾】--：
- 用顶流模型。
- 让他写测试，这样才能验证，以及避免把代码写乱。
- 中途让他总结问题和不足，给出改进意见，再让他按照改进意见做。
- 要让他反思，模块是否清晰？代码是否专业？是否能可持续开发？是否可用于生产？是否是工业级？
--【拾壹】--：
感谢大佬分享!
--【拾贰】--：
现在有啥好用的tdd工作流吗请问
--【拾叁】--：
superpower有tdd的skill
--【拾肆】--：
向大佬学习
--【拾伍】--：
我这周用codex尝试了下这类agent科研，现在的主要感受就是AI在数据集跑出指标不满意时会更多倾向于对数据集进行特化的方法添加，即使多次人工干预也比较难得到一个满意的结果，感觉除非用特别多agent组成搜索树，不然很难解决
--【拾陆】--：
我目前倒是没有直接的工作流
--【拾柒】--：
感谢分享心得
--【拾捌】--：
Vibe Coding引入TDD，添加了很多复杂性。边界值和特殊值需要提供，甚至你还要检查AI是不是单独为了通过这个用例修改了外部引用的实现。
初始状态：探索与验证
去年十一月初次接触 Vibe Coding 时，我主要利用 Cursor 来快速实现和验证创意。那时的工作流非常直观，核心在于“AI 生成，人工兜底”。
我依然保持着细致的 Code Review 习惯，当时的开发闭环大致如下：
graph LR
A(提出想法) --> B[AI 编码]
B --> C[程序运行]
C --> D{发现 Bug?}
D -- 是 --> E[让 AI 修复]
E --> C
D -- 否 --> F(开发完成)
F --> G[人工 Code Review]
人到中年 遇到瓶颈，力不从心
随着项目深入，AI 生成的代码量呈指数级增长，完全碾压了我人工编写的速度。很快，我发现了一个严峻的问题：我甚至很难在有限时间内读完 AI 生成的代码
当时很多平台都有人遇到类似的问题，当时大家比较热衷使用 多 Agent 编排 来解这个问题。最初我尝试跟随主流方案，使用多个 Agent 甚至调用不同模型来交叉审阅代码，但是 效果不及预期。我觉得这还挺反直觉的：Token 消耗剧增，成本飙升，但代码质量的提升却非常有限。
现在的状态：回归 TDD 思维
现在我用类似 TDD 的思路来驾驭 AI，感觉效果暴增。
针对新项目或新创意，在让 AI 动手写代码之前，我强制自己先完成以下“前置思考”步骤：
- 明确目标： 先想清楚最终想要达到的效果是什么。
- 界定边界： 厘清各个功能之间的边界在哪里。
- 划分模块： 给各个功能划分出明确的物理或逻辑边界。
- 梳理关系： 明确各个功能模块之间的组织与依赖关系。
- AI 生成用例： 基于以上四点，让 AI 先生成一份测试用例文档。
- 人工修正： 针对 AI 生成的测试用例进行人工补充和修正，确保逻辑严密。
- 任务布置： 给 AI 布置具体任务，并设立硬性指标——每次生成的代码必须能跑通所有测试。
我不确定这种使用方式是否算某种局部最优解，但在实际体感上，这种 测试先行 的模式确实speed up了我日常的开发工作，大部分时候AI生成的代码可以稳定地run起来。
新的问题
除了项目开发以外，平时还会有一些模型训练的工作，在这个case下，我感觉这种TDD的思路有点拉闸——通过某些指标是可以judge一次训练是否是ok的，但是很难去juedge这一次生成的代码是否符合我想它验证的猜想。
举个例子：
我想验证在loss中加入某个指标是否能提升视频生成的一致性，直接让AI做了代码实现。整个过程都很正常，它会自己识别一些问题让我做选择，训练也正常run起来了，但是我发现指标一点变化都没有，我觉得很奇怪，最后发现 AI 竟然把这个指标加在了 no_grad 里…
Vibe Coding真是让我又爱又恨。。。期待各位佬能一起分享下使用经验，一起看看有没有更好的使用方法，让 工作 摸鱼效率更上一层楼
--【壹】--：
我也遇到类似的问题了，感觉暂时没有通用的比较好的解决方法
--【贰】--：
感谢实践经验的分享 让我脑中的想法有了更清晰的路径
--【叁】--：
补充一个点，让AI先根据需求生成方案，审阅之后让它持久化下来，在后续让它自己去和写下来的方案去做比较，看看是否有遗漏。
--【肆】--：
好好维护skill文档确实是个很好的思路，感谢分享
--【伍】--：
确实，感觉AI在模型训练和其它相关代码编写很容易胡编乱造，佬有想到什么办法约束吗
--【陆】--：
我的做法不太一样——没走多 Agent 审阅那条路，走的是给 AI 加「记忆」。
具体来说就是写 skill 文件，markdown 格式，告诉 AI 项目的架构规范、代码风格、已经踩过的坑。40 多个 skill 文件跑了大半年，现在 AI 生成的代码基本不会偏离项目规范，review 的时候只需要看业务逻辑对不对，不用再纠结格式和架构问题。
跟 TDD 的思路其实是互补的。TDD 管的是"代码行为对不对"，skill 文件管的是"AI 知不知道该怎么写"。一个管结果，一个管过程。
不过 skill 也有成本——前期写这些文件挺花时间的，而且要持续维护。但到了第 20、30 个文件的时候，复利效应就出来了，新项目启动基本不需要从零教 AI。
--【柒】--：
哎，是的啊，难啊
--【捌】--：
概述来说就是 好好构造提示词。
我现在日常使用是这样的：我先提出假设，让ai帮我做编码实现，然后我观察结果。每次给指令之前我都会好好编辑一下，尤其是第一次下比较overall的指令的时候，所以胡编乱造的case相对没这么多。
我看到有人用agent实现了，从假设提出到编码实现再到最后结果分析的一条龙，感觉还挺厉害的，但是我感觉这种case下会有胡编乱造的情况出来。而且我是偏工程侧的，不是纯做研究，所以很多“水论文”的点子不是很适合我
--【玖】--：
期待你的分享
--【拾】--：
- 用顶流模型。
- 让他写测试，这样才能验证，以及避免把代码写乱。
- 中途让他总结问题和不足，给出改进意见，再让他按照改进意见做。
- 要让他反思，模块是否清晰？代码是否专业？是否能可持续开发？是否可用于生产？是否是工业级？
--【拾壹】--：
感谢大佬分享!
--【拾贰】--：
现在有啥好用的tdd工作流吗请问
--【拾叁】--：
superpower有tdd的skill
--【拾肆】--：
向大佬学习
--【拾伍】--：
我这周用codex尝试了下这类agent科研，现在的主要感受就是AI在数据集跑出指标不满意时会更多倾向于对数据集进行特化的方法添加，即使多次人工干预也比较难得到一个满意的结果，感觉除非用特别多agent组成搜索树，不然很难解决
--【拾陆】--：
我目前倒是没有直接的工作流
--【拾柒】--：
感谢分享心得
--【拾捌】--：
Vibe Coding引入TDD，添加了很多复杂性。边界值和特殊值需要提供，甚至你还要检查AI是不是单独为了通过这个用例修改了外部引用的实现。