作者 qaqvvvvqaq (QAQ)標題 [討論] Ai 時代code review時間 Mon Mar 9 15:33:55 2026
嗨各位前輩大家好
相信現在大家在工作上使用ai 越來越多
甚至整個project 都靠ai生成
好奇大家對於程式碼的品質還會一段一段review 不論是命名或是performance 等等的
還是說功能測試,檢查一下unit test 是不是涵蓋edge case而已
有時候看別人code review 也只是copy 程式碼,把需求丟給ai 問他是不是match
那也有一些同事還是一行一行看對於ai 的naming 或是doc 很有意見
個人覺得ai生成代碼太迅速,自己一天要細看全部設計還有naming 似乎有點吹毛求疵
當然關鍵邏輯設計還是會仔細review
好奇大家的公司有沒有因為ai 改變工作流程或是review code 的方式
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.170.164.130 (日本)
※ 作者: qaqvvvvqaq 2026-03-09 15:33:55
※ 文章代碼(AID): #1fhdVbkR (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1773041637.A.B9B.html
推 sarsman: 兩種方式不衝突阿,自己看的同時也叫AI看,加速自己理解但仍然至少全看過一遍理解整體邏輯才會給 approve
原因很簡單,AI不背鍋1F 03/09 15:47
推 leicheong: 說到AI的code review呢, 我不知道是不是自家AI才有的問題, 不過AI在解bug時有很大的用condition掩埋bug的傾向 (也不意外啦, 畢竟人在沒讀懂code又有時程壓力要解bug的情況下也會這樣做), 結果那部份的code只會越來越長, 而且你會發現大量重複的variable出現在一大串4F 03/09 16:08
→ leicheong: nested if中. 建議已經導入AI的公司看看已經吃了超過20張ticket的部份有沒有出現這情況.10F 03/09 16:15
推 Suleika: 還是要有人看的,交給AI忽略人工就會像win11 1月更新
害某些用戶電腦變磚頭
一起看應該是比較多人的跑法,功能單顧好商業跟交易邏輯風格靠開發時的文件給agent讀,不放在review重點12F 03/09 17:05
推 wulouise: 人眼漏看的ai反而容易找到16F 03/09 17:10
推 wulouise: var overshadowed, unused, copied nkr renamed var這種ai找很快18F 03/09 17:20
推 jhjhs33504: 推文總算腦袋清楚的又更多了點不然早先幾篇AI抬槓很累20F 03/09 18:03
完全理解要自己也要review,但是以現在的產出來說review 的速度反而有些跟不上
我自己倒是覺得nested if 這種把判斷邏輯spec 寫好其實ai code 跟 test case 也寫的
蠻好的
這時候我都是去看他的test case 是不是cover 我的需求
有時候他甚至會找出一些edge case
※ 編輯: qaqvvvvqaq (210.170.164.130 日本), 03/09/2026 18:31:27
推 yamakazi: 還要複製貼上給AI太落伍了,直接CLI開起來,/review PR#XXX 就好,21F 03/09 18:45
推 s78513221: 掏出code review skill29F 03/10 10:21
推 ssteves: 可以開CLI 用/review command,審查完先產出review
report,再把審查報告丟給實作的AI 確認合理性。30F 03/10 12:26
推 handsome01: 同問 ai review 時,假設framework頗大,要怎麼把framework 餵給ai比較好?先請 ai 看過framework然後summaries成一個md檔,之後要review時讓ai自己去看嗎32F 03/10 12:33
推 labbat: 不會 從來不review程式碼的36F 03/10 15:16
推 papple23g: 還是會review一下 畢竟自然語言不像程式語言 總會有模糊空間 再來是review後對專案掌握度高 後續跟AI協作改扣會更精準+省token37F 03/10 15:56
→ ma721: 不用,直接測40F 03/10 17:50
推 sunsamy: 刷code的奧林匹克選手不知道什麼是review,都直接merge41F 03/10 20:36
--