vibe coding 目前的焦虑

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

1. 本以为自己成为了产品经理,带着一众国际精英劳力干活儿,但最后的结果是,我成了测试员,我不停的为 AI 写出来的代码测试运行,反馈错误,复制粘贴错误信息,不停的反复从第一个功能试到最后一个功能。能知道的是,无论你何时做这个整体测试,你总能发现问题,无论是之前测试没问题的功能,还是新增的功能。

2. 从开始的每一条 diff 都亲自审阅,到最后只是一味的点击 Accept All ,惊艳的部分是原本耗时耗力的效果和结构,AI 完成的非常棒,但仔细看细节,去发现不少无厘头和冗余的结构或字段,开始还对话几轮让 AI 改掉,后来也就懒得说了,能跑起来也就算。

3. 虽然效率很高,很短的时间就能完成原本要比较长时间的复杂项目,但随着项目越来越复杂,当你要真正线上发布的时候,你的心却空落落的没有底,你不清楚也不确定哪里会有问题,哪里会不会有问题,一直伴随着发布初期。项目越重要,用户越多,这种不确定性的焦虑就越重。

4. 时间焦虑,原本自己写,虽然慢,但时间是可控的,大概能评估到自己多久能完成什么功能。而用 AI 编程,虽然他能一天就把一个 ERP 前后端都给整出来,但会发现你后面测试调试点击每一个页面时,你不得不针对每一小块功能都跟他对话修复。你不知道他哪里会突然出错,也不知道背后的逻辑是不是严谨,数据有没有正确入库。为了一点小事,你不得不跟他对话到半夜,反复修复着同一个问题。逐个修好还好,最焦虑的是,你修好了一个功能另一个本来正常的功能也可能会有问题。时间变得非常不可控。


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


3944 次点击
所在节点    程序员
28 条回复
pweng286
141 天前
然后再给 ai tester 出一个 ai tester-tester
ehnap
141 天前
vibe coding 就是让 AI 给你拉屎,然后你给 AI 擦屁股
传统 coding 就是同事给你拉屎,然后你给同事擦屁股
都是一样的
clino
141 天前
总之就是你应该要具备能 review AI 生成的代码的能力,如果不能 review ,一种情况是 AI 给你埋的坑 AI 有可能是能解决的,只要你指指方向,但是你不具备指方向的能力就抓瞎,还有一种是 AI 自己都搞不定的,需要人去修复,这就更难了,这种情况比较少,但是也会有,特别是比较创新超出 AI 已有知识范围的

还有就是生成代码的文件结构,模块划分,如果做得好,那问题出现的时候比较方便聚焦到局部进行解决,如果任由 AI 来规划结构,有可能不那么好
fyxtc
141 天前
ai 是助手,你让助手主笔,还有啥好说的
iLoveSS
141 天前
换个角度想也许也是好事, AI 都全自主了,大家就基本都失业了
mumbler
141 天前
写代码需要天赋,但测试不需要,节约写代码的时间全部用于测试即可,同样的工作时间,但工作强度大大下降了
ZSeptember
141 天前
问题不大,个人觉得过几年就是这样,AI 写代码,人工测试就可以了。
msg7086
141 天前
你给人类做 PM 的时候难道不需要给他们时间去重构代码吗?
人类发的 PR 难道不需要你 review 吗?
不要一下子就二极管从全手动变成全自动,AI coding 也要遵循基本法的。
Gress
141 天前
在卷 AI Coding ,咋不去卷 AI testing ?
renmu
141 天前
ai 编程的问题就是会失去代码的控制,不再了解一个功能的细节,也不知道如何去进行拓展,ai 化越严重你就越离不开 ai
PaulSamuelson
141 天前
我和你感受一样,我以为不用碰代码了,不是的。随着项目越来越大,AI 的上下文是有限的(工具也会为了解决个问题,把整个项目代码作为上下文,而是按照你的提示,从你的当前代码文件,去找依赖的代码),它不可能从全局去看待问题,一定是在解决一个局部问题。那么最终就是为了解决这个问题,可能没有照顾到其他地方。

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

最后,一定要懂代码,真遇到问题,还得自己上。
jonsmith
141 天前
AI 准确率会逐渐提高的,直到完全接管开发
Lshl56B4vDqdixwK
141 天前
AI 生成的代码就是安全噩梦,需要人工审查才行,那既然这样不如手写。
javalaw2010
141 天前
1. 让 AI 写单元测试和集成测试
2. 一次性不要完成太多任务,每次只完成很小的一部分,然后你亲自 review 每一行代码
3. 给出你自己的技术方案和风格,让 AI 写代码遵循你的技术方案和风格,不能让他太自由发挥

以上是我最近一段时间使用 AI 开发的一些经验。
foolishcrab
141 天前
我始终觉得 ai 最适合做的有两种工作,
1.你脑子里有个图,代码不知道怎么写
2.你脑子里有代码,手懒得打字
1 是全新的模块,不存在 ai 堆屎,2 是需要你自己校对的
wenjor
140 天前
架构和模块化使自己心里一定要有的,AI 做具体的功能模块一般不会有问题。
现在 AI 也没法做到跨模块文件的上下文阅读,数据流导向去维护每个模块是我目前的策略
su3sl3h06
140 天前
几个月来写了几十个 docker 了,深感觉两个能力很重要
一是架构能力,一开始就要想好自己到底要做什么,哪些地方可能扩展要预留,怎么分模块,确保每个位置在做什么都清晰可见,否则到后面就是一座屎山。
二是做减法的能力,AI 经常会给你原本不想要的功能,但你感觉似乎又还不错就留下了,但实际上这些代码永远会造成整体的臃肿。
sing1ee
140 天前
分享我的一些小做法:
1. 小步快跑,每一步人来 review ,人来重构
2. 把重构写成规则,记录到.cursorrules
3. AI 做得越多,开发完代码后 的流程就要越规范。冒烟测试,接口自动化,人工测试三遍,一个不能少。这过程沉淀下来的问题,都积累到.cursorrules 中

也可以不写在.cursorrules
sing1ee
140 天前
@sing1ee 创建一个新的文件,团队间协作共享的。毕竟不是每次都要带上这个上下文。
uiosun
140 天前
大项目用 AI 主导?我超过 300 行的代码都不敢用,不然就是一坨乱麻

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1126384

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX