嗨各位前辈大家好
相信现在大家在工作上使用ai 越来越多
甚至整个project 都靠ai生成
好奇大家对于程式码的品质还会一段一段review 不论是命名或是performance 等等的
还是说功能测试，检查一下unit test 是不是涵盖edge case而已
有时候看别人code review 也只是copy 程式码，把需求丢给ai 问他是不是match
那也有一些同事还是一行一行看对于ai 的naming 或是doc 很有意见
个人觉得ai生成代码太迅速，自己一天要细看全部设计还有naming 似乎有点吹毛求疵
当然关键逻辑设计还是会仔细review
好奇大家的公司有没有因为ai 改变工作流程或是review code 的方式
作者:
sarsman (DeNT15T♠)
2026-03-09 15:47:00两种方式不冲突阿，自己看的同时也叫AI看，加速自己理解但仍然至少全看过一遍理解整体逻辑才会给 approve原因很简单，AI不背锅
说到AI的code review呢, 我不知道是不是自家AI才有的问题, 不过AI在解bug时有很大的用condition掩埋bug的倾向 (也不意外啦, 毕竟人在没读懂code又有时程压力要解bug的情况下也会这样做), 结果那部份的code只会越来越长, 而且你会发现大量重复的variable出现在一大串
nested if中. 建议已经导入AI的公司看看已经吃了超过20张ticket的部份有没有出现这情况.
作者:
Suleika (Suleika)
2026-03-09 17:05:00还是要有人看的，交给AI忽略人工就会像win11 1月更新害某些用户电脑变砖头一起看应该是比较多人的跑法，功能单顾好商业跟交易逻辑风格靠开发时的文件给agent读，不放在review重点
作者:
wulouise (在线上!=在电脑前)
2026-03-09 17:10:00人眼漏看的ai反而容易找到
作者:
wulouise (在线上!=在电脑前)
2026-03-09 17:20:00var overshadowed, unused, copied nkr renamed var这种ai找很快
作者: jhjhs33504 ( ) 2026-03-09 18:03:00
推文总算脑袋清楚的又更多了点不然早先几篇AI抬杠很累
作者:
yamakazi (大安吴彦祖)
2026-03-09 18:45:00还要复制贴上给AI太落伍了，直接CLI开起来，/review PR#XXX 就好，
作者:
gino0717 (gino0717)
2026-03-09 20:33:00订三家互相review
作者: davidsmoon6 (davidsmoon) 2026-03-10 00:56:00
看薪资决定要不要人工 view
作者: ssteves (白熊) 2026-03-10 12:26:00
可以开CLI 用/review command，审查完先产出reviewreport，再把审查报告丢给实作的AI 确认合理性。
同问 ai review 时，假设framework颇大，要怎么把framework 喂给ai比较好？先请 ai 看过framework然后summaries成一个md档，之后要review时让ai自己去看吗
作者:
labbat (labbat)
2026-03-10 15:16:00不会 从来不review程式码的
还是会review一下 毕竟自然语言不像程式语言 总会有模糊空间 再来是review后对专案掌握度高 后续跟AI协作改扣会更精准+省token
作者:
ma721 (UndeadJ)
2026-03-10 17:50:00不用，直接测
刷code的奥林匹克选手不知道什么是review,都直接merge
作者:
tttkkk (学到。)
2026-03-12 23:16:00跟算法有关的code，AI看得比较完全。人脑的精力是有限，花好几天磨算法是要把自己逼疯
作者:
gino0717 (gino0717)
2026-03-12 23:29:00我给claude review他写的code抓出一整个列表的错误但是真的改下去又抓出一整个列表的误报 我都不知道要信谁
作者:
Homeparty (认命,知命,然后听天可也.)
2026-03-14 12:48:00太多他会压缩上下文，有时候要拆才能解决