用 AI 编程好几个月了，期间几乎没有自己写过什么代码，用的越多焦虑越多，主要有以下几点：

1. 本以为自己成为了产品经理，带着一众国际精英劳力干活儿，但最后的结果是，我成了测试员，我不停的为 AI 写出来的代码测试运行，反馈错误，复制粘贴错误信息，不停的反复从第一个功能试到最后一个功能。能知道的是，无论你何时做这个整体测试，你总能发现问题，无论是之前测试没问题的功能，还是新增的功能。
2. 从开始的每一条 diff 都亲自审阅，到最后只是一味的点击 Accept All ，惊艳的部分是原本耗时耗力的效果和结构，AI 完成的非常棒，但仔细看细节，去发现不少无厘头和冗余的结构或字段，开始还对话几轮让 AI 改掉，后来也就懒得说了，能跑起来也就算。
3. 虽然效率很高，很短的时间就能完成原本要比较长时间的复杂项目，但随着项目越来越复杂，当你要真正线上发布的时候，你的心却空落落的没有底，你不清楚也不确定哪里会有问题，哪里会不会有问题，一直伴随着发布初期。项目越重要，用户越多，这种不确定性的焦虑就越重。
4. 时间焦虑，原本自己写，虽然慢，但时间是可控的，大概能评估到自己多久能完成什么功能。而用 AI 编程，虽然他能一天就把一个 ERP 前后端都给整出来，但会发现你后面测试调试点击每一个页面时，你不得不针对每一小块功能都跟他对话修复。你不知道他哪里会突然出错，也不知道背后的逻辑是不是严谨，数据有没有正确入库。为了一点小事，你不得不跟他对话到半夜，反复修复着同一个问题。逐个修好还好，最焦虑的是，你修好了一个功能另一个本来正常的功能也可能会有问题。时间变得非常不可控。

看来世界上目前急需一个为 vibe coding 提供测试的 AI tester 工具来完成测试工作，我愿意为这个 AI tester 付 30 美元/月。

然后再给 ai tester 出一个 ai tester-tester

vibe coding 就是让 AI 给你拉屎，然后你给 AI 擦屁股
传统 coding 就是同事给你拉屎，然后你给同事擦屁股
都是一样的

总之就是你应该要具备能 review AI 生成的代码的能力，如果不能 review ，一种情况是 AI 给你埋的坑 AI 有可能是能解决的，只要你指指方向，但是你不具备指方向的能力就抓瞎，还有一种是 AI 自己都搞不定的，需要人去修复，这就更难了，这种情况比较少，但是也会有，特别是比较创新超出 AI 已有知识范围的

还有就是生成代码的文件结构，模块划分，如果做得好，那问题出现的时候比较方便聚焦到局部进行解决，如果任由 AI 来规划结构，有可能不那么好

ai 是助手，你让助手主笔，还有啥好说的

换个角度想也许也是好事, AI 都全自主了,大家就基本都失业了

写代码需要天赋，但测试不需要，节约写代码的时间全部用于测试即可，同样的工作时间，但工作强度大大下降了

问题不大，个人觉得过几年就是这样，AI 写代码，人工测试就可以了。

你给人类做 PM 的时候难道不需要给他们时间去重构代码吗？
人类发的 PR 难道不需要你 review 吗？
不要一下子就二极管从全手动变成全自动，AI coding 也要遵循基本法的。

在卷 AI Coding ，咋不去卷 AI testing ？

ai 编程的问题就是会失去代码的控制，不再了解一个功能的细节，也不知道如何去进行拓展，ai 化越严重你就越离不开 ai

我和你感受一样，我以为不用碰代码了，不是的。随着项目越来越大，AI 的上下文是有限的（工具也会为了解决个问题，把整个项目代码作为上下文，而是按照你的提示，从你的当前代码文件，去找依赖的代码），它不可能从全局去看待问题，一定是在解决一个局部问题。那么最终就是为了解决这个问题，可能没有照顾到其他地方。

目前 AI 编码，在解决小问题，局部问题很棒，解决大问题，大需求，容易陷入困境。

最后，一定要懂代码，真遇到问题，还得自己上。

AI 准确率会逐渐提高的，直到完全接管开发

AI 生成的代码就是安全噩梦，需要人工审查才行，那既然这样不如手写。

1. 让 AI 写单元测试和集成测试

2. 一次性不要完成太多任务，每次只完成很小的一部分，然后你亲自 review 每一行代码
3. 给出你自己的技术方案和风格，让 AI 写代码遵循你的技术方案和风格，不能让他太自由发挥

以上是我最近一段时间使用 AI 开发的一些经验。

我始终觉得 ai 最适合做的有两种工作，
1.你脑子里有个图，代码不知道怎么写
2.你脑子里有代码，手懒得打字
1 是全新的模块，不存在 ai 堆屎，2 是需要你自己校对的

架构和模块化使自己心里一定要有的，AI 做具体的功能模块一般不会有问题。
现在 AI 也没法做到跨模块文件的上下文阅读，数据流导向去维护每个模块是我目前的策略

几个月来写了几十个 docker 了，深感觉两个能力很重要
一是架构能力，一开始就要想好自己到底要做什么，哪些地方可能扩展要预留，怎么分模块，确保每个位置在做什么都清晰可见，否则到后面就是一座屎山。
二是做减法的能力，AI 经常会给你原本不想要的功能，但你感觉似乎又还不错就留下了，但实际上这些代码永远会造成整体的臃肿。

分享我的一些小做法：

1. 小步快跑，每一步人来 review ，人来重构
2. 把重构写成规则，记录到.cursorrules
3. AI 做得越多，开发完代码后 的流程就要越规范。冒烟测试，接口自动化，人工测试三遍，一个不能少。这过程沉淀下来的问题，都积累到.cursorrules 中

也可以不写在.cursorrules

创建一个新的文件，团队间协作共享的。毕竟不是每次都要带上这个上下文。

大项目用 AI 主导？我超过 300 行的代码都不敢用，不然就是一坨乱麻

cline 不是自动监测运行错误 自动修复么？

逻辑页面上的修复不了，估计很快会出来