
用 AI 生成代码很快,但是每次都要 review 它写的会不会对以前的业务产生影响 IMG_1212.PNG 
1 zhengxiaowai 7 小时 24 分钟前 本来 review 就是比写代码费时间,主要是理解“别人”成本过高 |
2 sillydaddy 7 小时 14 分钟前 看代码比写代码的时间还长?我是不信的。除非水平写的很差,低内聚高耦合那种,但目前的 AI 明显没有这么差。 多次的话,不能让它反复覆写以前的代码,那样相当于每次都要重新看。这确实需要一些技巧,一个技巧就是自己还是要统领全局,提前想清楚思路,或者逐步推进,不能指望一口吃个胖子。 |
3 midsolo 7 小时 3 分钟前 工作量不会消失,只会转移 |
4 chendy 6 小时 55 分钟前 思考需求和理解已有代码本来就比编写新代码要慢 现在有 AI 辅助拉屎之后差距更明显一些 但是 AI 辅助解释代码又一定程度缓解了这一点 |
5 tf2 6 小时 45 分钟前 我觉得要么就一个人+AI ,要么就别拿 AI 跟别人协作。 |
6 nenseso OP @sillydaddy 我目前 agent 模式下基本是一个点一个点的推进,每次做完一个点,就 review 一下,看看有没有给我埋一些暗坑进去。plan 模式我感觉目前还是不太好用,它一次推进太多,我都看不过来。openspec 我最近也有用,感觉效果也差强人意,不知道你们的工作流是怎样的 |
7 crysislinux 6 小时 37 分钟前 via Android 要是项目里有几个人用 ai ,然后合并有冲突的时候才酸爽 |
8 nenseso OP @chendy 要是有个 AI Reviewer ,它对业务的理解程度跟人类一样就好了,可以读取公司的产品文档之类的,充分理解需求,但是目前它既不能存那么多上下文来理解代码,也没有权限访问一些内网 prd 。 |
9 sillydaddy 6 小时 14 分钟前 @nenseso #6 一样的,也是一个点一个点推进。局部的可以不用理解,只要测试通过就行,全局的(比如大的架构、设计),自己必须清楚。 上次做自己的项目( /t/113381 ),我给了 AI 一个长长的提示词,让它一键做一个复杂的界面切换(组件编辑器,切换到复合组件编辑器),看起来只是一个界面切换,但涉及到了功能的复用(编辑过程类似、画布也要复用)、状态的切换( 2 个编辑器里面的数据内容需要切换)、数据的交换(需要从组件编辑中选取一些东西传递到复合组件编辑中)等等,结果它改好多次,总是顾此失彼。 最后只好自己定义好复用的框架、拆分大文件为小文件、添加打印信息,总之就是让自己能在 AI 的编码过程中,自己能理解每一步。最后重构完成了,自己也掉了一层皮。深刻的教训。 所以我觉得还是自己把握住度:局部的可以不用理解,只要测试通过就行,全局的或复杂的(比如大的架构、设计),自己必须清楚。 |
10 xuanwu 6 小时 8 分钟前 “Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” — Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship |
11 wu67 5 小时 18 分钟前 我是 agent 模式一点点来, 尽可能用详细的描述去限定它干活, 不然他大概率会越界乱改. 很多时候就是在赌最后写的代码比我码关键字要长, 可以让我省点事... 不过让它生成逻辑倒是想对省事, 因为有很多乱七八糟的逻辑, 让我自己写可能要反复调试几次才得出最优解, 它自己就可以写出一两遍测试就通过的代码. |
12 woodfizky 4 小时 44 分钟前 只有我看 V 站各位程序员用 AI 编程,然后看自己手写代码有种古法编程的感觉吗 ![]() 其实写代码也不是说拿着功能需求就开始写了呀,也是要写设计文档,设计表,然后写代码之前再思考具体实现的代码是怎么样的。 如果你们 review 的时候发现需要很久,或者发现很多问题,那一定是写的时候没有好好想好应该怎么写,没有维持好良好的可读性,可扩展/维护性,无论代码是 AI 写的还是人写的。 甚至代码不说是不是 AI 或者人写的,自己写的代码过一段时间,自己回头 review 也会发现一些实现方式不对的地方的。 另外就我个人来说,我总结的经验,特别是接手其它代码质量差的同事的项目的时候,可维护性相当差,相当多的代码是复制粘贴而不是代码复用的,也很难从传递的对象中看出来具体干了什么事情的。这就是没好好写或者写之前没好好想的后果。 写之前不花时间好好想好好设计,代码质量低就会造成后面 review 或者维护起来困难,甚至花费的时间比在写之前前好好设计还要多很多。 |
13 Leviathann 4 小时 26 分钟前 正常 写代码是正向思维 看代码不光要理解代码的正向思维,还要发散的逆向思维 |
14 nenseso OP @woodfizky 文档肯定是很重要的,不熟悉业务的人要了解业务需要看文档来对比实现,才能更好的理解。 不过大部分情况开发时间紧张,很多人的文档在功能开发完成后就不怎么维护了,导致实际实现和文档对不上。 |
15 nenseso OP @Leviathann 有道理 |