為什么用AI寫代碼，我反而感覺越來越累了？

為什么用AI寫代碼之后，人反而越來越累了？同事們都反應，用了claude code 等AI agent寫代碼之后，工作反而越來越累了。

無論誰寫的代碼，最終都需要跑通，需要運行起來，簡單的代碼還好說，復雜的代碼在寫完經過測試人員開測之前，至少他們能跑起來，如果沒有跑起來的話？其實這個工作量還是非常大的！

這就像讓一個修馬路的人成為馬路即將通車的道路檢察官，要保障萬無一失，要保障不出錯，于是他們需要仔細檢查，遇見問題還需要人工修復，關鍵是他們并不一定能完全檢查出問題，但還是需要檢查，檢查的時候還要全神貫注，還需要一絲不茍，非常耗費精氣神！

檢測的時候好比找茬游戲，需要眼睛要細致觀察，需要不斷的去發現存在的問題。

以前寫代碼是 “從 0 到 1 搭房子”，現在更像 “對著 AI 搭好的毛坯房，要拿著放大鏡找所有松動的磚、沒抹勻的灰，還要預判哪塊墻可能塌”—— 這種 “看似有了半成品，卻要為所有潛在漏洞兜底” 的責任壓力，才是最累的。

我們從實際工作內容和時間精力分配來看。以前程序員可能 80% 的時間用來自己寫代碼，20% 時間調試。現在用 AI 后，寫代碼的時間可能壓縮到 20%，但調試和驗證的時間會飆升到 60% 以上。

而且以前調試的是自己寫的代碼，邏輯思路自己清楚，哪里容易出錯心里有數。現在 AI 生成的代碼，表面看功能實現了，但深層邏輯可能很繞，甚至有隱藏的性能問題或邊界錯誤。你得先花時間理解 AI 的代碼思路，再一步步排查，這個過程比調試自己的代碼更耗神。

還有，AI 可能會自信地生成錯誤的解決方案，比如在處理特定數據格式或第三方庫調用時，看似代碼結構完整，實際參數傳遞有細微偏差。這種 “看起來對，實際不對” 的情況，比明顯的語法錯誤更難發現，往往需要反復測試不同場景才能暴露。

我們把這個場景具體化。比如一個習慣用基礎 Java 語法的程序員，AI 突然生成了一段用函數式編程思想寫的復雜代碼，還嵌套了多層設計模式。他首先得花 2-3 小時查資料、看文檔，搞懂 AI 用的這些高級語法和設計思路，這個學習過程本身就消耗大量精力。

而如果 AI 生成的代碼水平很低，比如用最基礎的循環嵌套實現了一個本可以用現成算法庫解決的功能，還存在大量冗余代碼。程序員就得像改一篇邏輯混亂的作文一樣，逐行梳理，刪掉重復代碼，替換低效邏輯，最后重構出來的代碼可能和自己從頭寫一遍差不多，但還多了一步 “理解垃圾代碼” 的過程。

更麻煩的是，AI 代碼的質量可能忽高忽低。上一段還在用優雅的遞歸解決問題，下一段就犯了變量命名混亂的低級錯誤。這種質量的不穩定性，讓程序員始終處于 “警惕模式”，沒辦法形成穩定的工作節奏，精神一直緊繃著。

AI 這玩意兒，你根本沒法給它定個準譜。咱們人類干活，能力高低一眼就能看明白，可 AI 不是。它上一秒還能寫出專家級的代碼，下一秒又可能犯些入門級的低級錯誤。這種忽高忽低、完全沒規律的表現，真的讓跟它打交道的人特別崩潰。

這就像你組隊打游戲，隊友一會兒是職業選手水準，一會兒又像剛上手的新手，你永遠不知道下一秒他會打出神操作還是送人頭。這種不確定性讓合作變得非常累，因為你沒辦法建立穩定的協作預期，只能時刻緊繃神經去兜底。

雖然AI號稱有記憶，可以成長，但AI卻會降智，會亂入，會對話突然和上下文沒有關聯完全失去記憶了，這些因素就會讓我們用AI越來越累，不管是寫代碼，還有寫文章等等方面都有這樣的問題。

目前只能用一些 “土辦法” 應對。比如每次和 AI 對話時，把核心需求、技術約束、已確定的框架這些關鍵信息，整理成固定的提示詞模板，每次提問都帶上，相當于強制給它 “復習重點”。

還有就是把大任務拆成小步驟，每一步只讓 AI 處理單一功能模塊，確認它輸出的代碼沒問題后，再進行下一步。這樣即使它中途 “降智”，影響范圍也能控制在小模塊里，不用全盤重來。

另外很多程序員會準備一個 “AI 錯誤案例庫”，把之前遇到的 AI 低級錯誤、邏輯漏洞記錄下來，下次讓 AI 寫代碼前，先拿類似案例提醒它避開，有點像 “考前劃易錯點”。那如何控制這樣的問題呢？

現在很多程序員都調侃，自己快成 “AI 行為管理專家” 了，每天一半時間寫代碼，一半時間研究怎么 “調教” AI 穩定輸出。那你說這種情況，人能不累嗎？對此大家是怎么看的，歡迎關注我“創業者李孟”和我一起交流！