Claude用戶3周后集體懵圈：代碼能跑，但沒人敢改

三個月前，一個后端工程師在Reddit發帖：「我花了4小時讓Claude寫了個支付模塊，上周要加退款功能，看了20分鐘沒看懂自己寫的代碼——哦不對，是Claude寫的?！?/p>

這條帖子24小時收獲3400贊。評論區像互助會現場，全是「我也是」「上周剛發生」「現在看見AI生成的代碼就PTSD」。

問題不在Claude。Anthropic的模型能力沒問題，問題出在人的工作流設計——或者說，根本沒有設計。

為什么代碼越跑越陌生

開發者對AI編程有個致命誤解：把每次對話當成獨立任務，而非持續工程的環節。

Claude在單輪對話里表現極佳。你描述需求，它輸出代碼，測試通過，部署上線。這個閉環流暢得讓人上癮。

但三周后你需要擴展功能，打開代碼庫的瞬間會陷入考古現場。變量命名邏輯、模塊拆分理由、某處異常處理的取舍——這些決策只存在于Claude的輸出里，不在任何你控制的系統中。

原文作者有個精準比喻：你不是在調試代碼，是在考古發掘。

具體崩壞場景通常三類：

架構漂移：Claude為當前任務優化的局部方案，與系統整體設計逐漸脫節

隱式依賴：某處實現依賴了Claude在對話早期生成的輔助函數，但這段關系沒有任何文檔

上下文截斷：長對話后期，Claude開始壓縮或遺忘早期決策，導致輸出與初衷偏離

這些不是Claude的bug。它按你要求的順序執行了你要求的任務。問題是你從未告訴它各模塊在系統層面的關聯——而單輪對話的上下文長度，根本不足以讓它自行推斷。

可持續AI編程的3個前置問題

能長期用Claude寫出可維護代碼的開發者，有個共同習慣：把每次對話當作「交接班」。

開始新對話前，他們會先回答三個問題：

第一，當前代碼庫的結構和約束是什么？不是讓Claude猜，是明確告知：「用戶模塊用Repository模式，支付模塊依賴Stripe SDK，不要引入新ORM?！?/p>

第二，這次改動與現有系統的交互點在哪？具體到函數名、接口定義、數據流向。

第三，完成后的驗證標準是什么？不只是「能跑」，而是「符合現有代碼風格」「不增加認知負擔」「測試覆蓋新增分支」。

聽起來像常識？但多數人直接跳進任務描述，假設Claude和自己有相同的全局視圖，然后不假思索地接受輸出。

最普遍的失敗模式：把「能運行」等同于「正確」。

AI生成的代碼通過編譯、跑通基礎測試，不代表它屬于這個系統。真正的驗收標準是：下次修改時，這段代碼讓工作變容易還是變困難？

這需要額外5分鐘審查：命名是否符合項目慣例？是否重復實現了已有工具函數？異常處理是否與其他模塊一致？是否引入了不必要的抽象層？

5分鐘換幾小時，這筆賬不難算。

對話長度是隱形殺手

另一個值得養成的習慣：控制單輪對話長度。

長對話會累積漂移。提示詞上下文逐漸填滿，Claude開始主動壓縮或總結早期內容，精度隨之流失。你可能在對話后半段發現，它給出的方案與最初架構設想已經南轅北轍。

短對話、窄范圍——「給這個模塊添加X功能，這是模塊當前職責和接口」——輸出更緊湊，驗證也更簡單。

對話結束時，給自己留一份交接筆記：做了什么、為什么這么做、什么變了。下次對話的開頭，把這份筆記喂給Claude。

這套方法不需要新工具或復雜系統。它是工作流設計，而大多數人跳過這一步，因為Claude讓「開始」變得太容易了。

原文作者正在整理一套免費入門資料「Ship With Claude」，核心是可維護AI輔助開發的模式，包括5個提示詞框架。他說自己系統性地思考這個問題，正是因為看到了太多「三周后懵圈」的案例。