跟大家讨论个问题：现在 AI 写代码之后...的全部评论

我不会全部 review，我的工作方式：AI 开发完成一个功能，我会仔细看 AI 的总结跟我的预期是否相符合，是否涵盖了我的需求。如果符合我就直接测试功能，中途有 bug 或者不合理地方，再单独找到那块代码 review，指挥让 AI 去精准修复。

感谢各位大佬的评论。 有些大佬提到的场景对我来说确实有点远了。对于我这种小厂开发来说，平时接触最多的还是 CRUD 和业务逻辑开发，说实话，基本也碰不到什么真正意义上的高并发场景。 作为一个毕业两年的开发，本身写代码的时间就不算长，结果刚工作没多久 AI 编程就发展起来了，所以受到的冲击也比较大。以前总觉得自己经验不够、代码写得不够多，现在又开始思考，在 AI 越来越强的情况下，开发者到底该怎么提升自己的价值。...

你这种反思特别珍贵！在AI浪潮里保持审慎和自省，本身就是最扎实的工程素养。

我对于review 的粒度不会特别细，更多是核心业务流程是否正常，是否涉及到架构变更，架构变更会影响那些模块，整体目标是风险不会冒泡到下游的。 效率更高的手段，是搭建一套自动测试用例，覆盖回归场景。每个新功能，先把黑盒用例写好，AI 写完直接跑一遍用例，确保没有回归问题，同时新功能的业务逻辑上结果是正确的，增加了上线信心。明确不会冒泡风险到下游，剩下的就是看AI是否写出了技术债，再调调就好了。

会，每次都只让ai写一部分代码，比如来了个新需求，可以先只写领域模型（或者在传统开发就先建表，entity），再去写openapi，然后再去实现 command（mvc 中就对应service），这样一步步实现，一个pr一个pr的提交，这样同事也能很清晰的看懂我们的想法

感觉聊不是问题，而是自己要引导大模型把一些点真正固化下来，就像有些模块的点，聊着聊着突然想到个边界问题，如果不记下来，后面一直聊下去，模型慢慢就不一定还记得这回事，或者就是原来有设置的一些规范什么的会因为你聊的一些题外话就开始偏了，就还是会需要我们在AI辅助下去逐条敲定该文档沉淀的规则，最后做完后再让他审查一遍。这样一般最后修改就不太容易遇到极可能整块都得重写的问题

我也不会全部review,主要是我会先按照功能写个需求描述，然后让AI跑完，然后根据AI完成后的结果描述，去review一下，其次才接受AI的结果，然后AI提测，不合理的地方单独#类 标注行数 让AI优化，并且符合某某规范，检查一下代码是否简介明了逻辑通顺

我会 review，算是半托管，就是图片里这样。因为是比较老的项目做运维，技术栈用的 hybirs，所以本身就存在很多的技术债，为了防止 ai 自行发挥一些有的没的，哪怕通过例如 skills 之类的手段做严格的约束，还是会做 review。（特别是领导还偶尔会问我：你这里为什么要这么写...）

其实我觉得分情况，如果真正掌握了AI编程，大部分场景不需要自己 review，如果你说那我代码为什么会有问题，那说明你没有把AI引导正确，没有会正确使用AI