大伙有没有觉得现在 review 代码的时间比写代码的时间还长

[nenseso]

用 AI 生成代码很快，但是每次都要 review 它写的会不会对以前的业务产生影响 IMG_1212.PNG

[zhengxiaowai]

本来 review 就是比写代码费时间，主要是理解“别人”成本过高

[sillydaddy]

看代码比写代码的时间还长？我是不信的。除非水平写的很差，低内聚高耦合那种，但目前的 AI 明显没有这么差。
多次的话，不能让它反复覆写以前的代码，那样相当于每次都要重新看。这确实需要一些技巧，一个技巧就是自己还是要统领全局，提前想清楚思路，或者逐步推进，不能指望一口吃个胖子。

[midsolo]

工作量不会消失，只会转移

[chendy]

思考需求和理解已有代码本来就比编写新代码要慢
现在有 AI 辅助拉屎之后差距更明显一些
但是 AI 辅助解释代码又一定程度缓解了这一点

[tf2]

我觉得要么就一个人+AI ，要么就别拿 AI 跟别人协作。

[nenseso]

@sillydaddy 我目前 agent 模式下基本是一个点一个点的推进，每次做完一个点，就 review 一下，看看有没有给我埋一些暗坑进去。plan 模式我感觉目前还是不太好用，它一次推进太多，我都看不过来。openspec 我最近也有用，感觉效果也差强人意，不知道你们的工作流是怎样的

[crysislinux]

要是项目里有几个人用 ai ，然后合并有冲突的时候才酸爽

[nenseso]

@chendy 要是有个 AI Reviewer ，它对业务的理解程度跟人类一样就好了，可以读取公司的产品文档之类的，充分理解需求，但是目前它既不能存那么多上下文来理解代码，也没有权限访问一些内网 prd 。

[sillydaddy]

@nenseso #6 一样的，也是一个点一个点推进。局部的可以不用理解，只要测试通过就行，全局的（比如大的架构、设计），自己必须清楚。

上次做自己的项目（ /t/113381 ），我给了 AI 一个长长的提示词，让它一键做一个复杂的界面切换（组件编辑器，切换到复合组件编辑器），看起来只是一个界面切换，但涉及到了功能的复用（编辑过程类似、画布也要复用）、状态的切换（ 2 个编辑器里面的数据内容需要切换）、数据的交换（需要从组件编辑中选取一些东西传递到复合组件编辑中）等等，结果它改好多次，总是顾此失彼。

最后只好自己定义好复用的框架、拆分大文件为小文件、添加打印信息，总之就是让自己能在 AI 的编码过程中，自己能理解每一步。最后重构完成了，自己也掉了一层皮。深刻的教训。

所以我觉得还是自己把握住度：局部的可以不用理解，只要测试通过就行，全局的或复杂的（比如大的架构、设计），自己必须清楚。

[xuanwu]

“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

[wu67]

我是 agent 模式一点点来, 尽可能用详细的描述去限定它干活, 不然他大概率会越界乱改. 很多时候就是在赌最后写的代码比我码关键字要长, 可以让我省点事...
不过让它生成逻辑倒是想对省事, 因为有很多乱七八糟的逻辑, 让我自己写可能要反复调试几次才得出最优解, 它自己就可以写出一两遍测试就通过的代码.

[woodfizky]

只有我看 V 站各位程序员用 AI 编程，然后看自己手写代码有种古法编程的感觉吗

其实写代码也不是说拿着功能需求就开始写了呀，也是要写设计文档，设计表，然后写代码之前再思考具体实现的代码是怎么样的。

如果你们 review 的时候发现需要很久，或者发现很多问题，那一定是写的时候没有好好想好应该怎么写，没有维持好良好的可读性，可扩展/维护性，无论代码是 AI 写的还是人写的。

甚至代码不说是不是 AI 或者人写的，自己写的代码过一段时间，自己回头 review 也会发现一些实现方式不对的地方的。

另外就我个人来说，我总结的经验，特别是接手其它代码质量差的同事的项目的时候，可维护性相当差，相当多的代码是复制粘贴而不是代码复用的，也很难从传递的对象中看出来具体干了什么事情的。这就是没好好写或者写之前没好好想的后果。
写之前不花时间好好想好好设计，代码质量低就会造成后面 review 或者维护起来困难，甚至花费的时间比在写之前前好好设计还要多很多。

[Leviathann]

正常 写代码是正向思维 看代码不光要理解代码的正向思维，还要发散的逆向思维

[nenseso]

@woodfizky
文档肯定是很重要的，不熟悉业务的人要了解业务需要看文档来对比实现，才能更好的理解。
不过大部分情况开发时间紧张，很多人的文档在功能开发完成后就不怎么维护了，导致实际实现和文档对不上。

[nenseso]

@Leviathann 有道理

[woodfizky]

@nenseso #14
其实人看文档和 AI 看提示词是一回事。

AI 能不能解读好文档，然后将整个项目工程的代码作为上下文去写代码，是个很大的问题。
这点人都不一定能做到。当然我没有实际用过 AI 去写大规模的工程，只写过脚本。
请问你使用 AI 去写稍微大一点规模的工程，有发现 AI 代码在应该用已有轮子的地方重复造轮子吗？或者应该重用代码的地方不重用而是复制粘贴？

[nenseso]

@woodfizky #16 Agents.md 里面会写一些基础的 prompts,告诉它项目中哪些位置放了基础的组件库，尽量让它模仿已有的代码风格去实现。

[qiubo]

不 review 了，cladue code 只查看 plan 是否有太大偏移，然后再测试验证有没有改对。代码直接就是黑盒，最终提交 git 才大概看一下

[lujiaosama]

@qiubo bro 这是直接拥抱氛围式编程了吗 😂

[Helsing]

没有 AI 之前也是这样子的

[Hilong]

@qiubo
@lujiaosama 我现在也差不多这样了。虽然用的 cursor ，但是很多代码也不看他怎么写的了。基本功能测试符合预期就提交了