我如何透過 Claude Code 成為 5 倍工程師

Lesswrong·

我透過將 Claude Code 視為結對編程的駕駛員,而我擔任導航員的角色,並專注於細緻的規劃、分階段執行與嚴格的程式碼審查,成功實現了 3 到 5 倍的生產力提升。藉由利用人工智慧處理編碼的繁重工作,同時由我提供業務背景與品質控管,我能在更短的時間內交付更高品質的成果。

Claude Code 徹底改變了我身為程式設計師的意義。它讓我變得更有生產力,我現在能在幾小時內完成以前需要幾天才能完成的工作。表面上看,就交付成果的時間而言,我的生產力可能只提升了約 1.5 倍,但考慮到在相同時間內我能寫出的代碼品質現在高得多——因為編碼代理(coding agents)降低了投入精力編寫高品質代碼的成本——如果你也認同高品質代碼是有價值的,那麼總體生產力輕易就能提升 3 到 5 倍。

自然會產生的問題是:「我是怎麼做到的?」以及「你也能做到嗎?」

讓我們依序探討這些問題。

5 倍速工程師的運作機制

可以說,我實現 5 倍程式開發生產力的方法非常簡單:我幾乎用 Claude Code 來做所有事情!

但現實情況更為複雜,因為很多人也嘗試用 Claude Code 做所有事,卻沒有看到類似的生產力提升。在 Claude 發布後的 6 個多月裡,我學到了很多關於如何與它高效協作的經驗。以下是我的做法:

  • 從高層次來看,我將自己視為與 Claude 進行「結對編程」(pair programming)。我是領航員(navigator),Claude 是駕駛員(driver),儘管偶爾我會請 Claude 協助領航(例如在規劃階段),而我有時也會親自駕駛,跳進去修改代碼中的微小細節。

我發現這種模式優於其他使用編碼代理的方式。特別是,我不喜歡讓代理自行運行並提交 PR(拉取請求)。即使 CI(持續整合)通過了,我也不信任這些更改是否真的有效,而且迭代時間更長。我不想讓注意力反覆被多個方向分散,我希望一次專注於一件事,完成它,然後繼續下一件,只是速度比沒有 LLM(大型語言模型)輔助時更快。

  • 我幾乎總是從計劃開始,也就是使用「規劃模式」(planning mode)。我會給 Claude 一些關於我想要什麼的模糊指令,讓它熟悉代碼庫。它會回饋一些內容,然後我會針對該計劃與它進行迭代,直到看起來基本正確為止。

我擁有而 Claude 沒有的最有價值的東西是「脈絡」(context)——關於業務、用戶、他們的需求、功能應如何運作的脈絡,以及在較小程度上關於我們工程文化的脈絡(它能從代碼中推斷出很多這方面的資訊!)。這是我在 Claude 規劃時需要告訴它的最重要資訊。

  • 如果我正在處理大型或複雜的任務,我會告訴 Claude 我想將工作拆分為多個階段,因為我想在每個階段結束後停止,以創建一系列堆疊的 PR(stacked PRs)。這有助於防止它因為試圖做太多事而迷失方向,而且因為我確實創建了堆疊 PR,這讓審核代碼時變得更輕鬆。

  • 有時我不確定 Claude 最初提出的計劃是否良好,所以我會提問。Claude 有時會過於急切地制定新計劃,但如果我持續追問,它會解釋其決策,如果我認為那些決策不好,我可以與 Claude 協作制定更好的計劃。

  • 說到這點,我經常不喜歡初始計劃。有時我心裡已經有了該怎麼做的想法,但我通常會裝作不知道,詢問 Claude 有沒有其他替代方案,以避免對它產生偏見。有時它會想出比我更好的主意,但通常它要麼想出和我一樣的主意,要麼提出一個能幫助我改進自己想法的建議(然後我會叫 Claude 修改計劃來執行那個想法)。

  • 計劃準備就緒後,我會讓 Claude 執行。在這個過程中,我通常會去做別的事。這可能是處理另一個編碼任務、處理郵件或其他訊息,或者如果我無法同時在腦中處理兩個複雜事物的脈絡,我就會去刷刷 Twitter

  • 當 Claude 完成後,我會仔細審查它的工作。我不信任任何東西。我會查看 diff(差異對比),確保我理解其中的每一部分。如果任何地方看起來很奇怪或我不理解,我會詢問 Claude 那部分代碼是怎麼回事。

Claude 傾向於採取行動,所以在提問時,我經常需要提醒它我只是在詢問,還沒叫它做任何事。我會說類似「先不要做任何更改,但為什麼 [代碼的某部分] 會是 [現在的樣子]?」

  • 我也會要求 Claude 在做出更改前先規劃更改。這有助於避免大量的重做,以及避免等待它做出我最終會撤銷的更改。有時我甚至會讓 Claude 回到規劃模式,但通常我只是在普通模式下通過明確的提示來進行規劃,例如:「先不要更改任何內容。看看 [代碼部分],並給我一些關於我們如何 [以某種特定方式改進它] 的選項。」

我將這個過程視為一個小型規劃會議,即使 Claude 不在規劃模式下。我會問很多問題,試圖理解權衡(tradeoffs),並在讓 Claude 寫更多代碼之前,對下一步該做什麼達成明確的結論。

  • 我有時也會親自進去編輯。即使在 CLAUDE.md 中使用了相當強勢的提示,我也無法始終讓 Claude 完全符合我的風格偏好,所以我會手動修正。不過,這些通常都是微小的改動。對於任何需要花費我超過幾分鐘的事情,我都會讓 Claude 來做。

當我進行編輯時,我一定會告訴 Claude 我做了這件事。否則,它很可能會撤銷我的更改。出於這個原因,我通常會嘗試將風格編輯留到最後,也就是在我預期不再需要 Claude 進行任何編輯之後。

  • 我發現隨時提交(commit)代碼很有用。這實際上給了我檢查點,以防 Claude 偏離軌道並做出一些難以恢復的奇怪舉動。我經常因為能夠執行快速的 git checkout . 而免於手動清理。

  • 雖然我通常在 Claude 工作時去做別的事,但有時我發現坐下來看著它很有用。當我對它能否做正確的事信心不足,或者當我看到它在更改代碼後浪費時間做額外步驟時,我發現這特別有用。這樣我就可以中斷它並修正方向,或者提前停止它並開始下一件事。

  • 我總是會測試 Claude 的更改,就像我自己直接更改代碼後會進行測試一樣。這應該是顯而易見的,但代碼的所有權屬於我,而不是 Claude,所以測試並確保它能運作是我的責任。

這並不代表我不能向 Claude 尋求幫助,特別是編寫自動化測試。我通常會給它一個關於我想要測試什麼以及我關心哪些案例的模糊描述,然後它會將它們編寫出來。

  • Claude 產出的測試並不完美,但編寫測試很乏味,否則我可能不會寫足夠的測試。Claude 降低了阻力,使我能在代碼中產生更多有用的測試,即使這些測試的品質標準可能不如我對應用程式代碼的要求。

  • 我也會進行實測。我會在開發環境和預發布(staging)環境中運行它。Claude 經常犯錯,我需要確保代碼確實按照我的想法運作。發現代碼看起來正確但執行起來與預期有細微差別,或者行為與我直到看到代碼運行才意識到的隱含預期相悖,這種情況並不罕見。

  • 我使用 Claude 來審核代碼。我會開啟一個新對話,並請它審核代碼。不要告訴 Claude 這些代碼是我在它的幫助下寫的,因為那會產生偏見。我只是請它審核更改。它可以查看提交中的 diff,閱讀更多代碼,並發現原始 Claude 實例遺漏的問題。

在實踐中,我也會使用作為 CI 一部分運行的其他自動化代碼審查工具,有時我會因此跳過本地的 Claude 審查。重點是,LLM 非常擅長發現人類經常遺漏的代碼機械性錯誤,我依賴一雙全新的 LLM 眼睛在這些錯誤進入生產環境前捕捉到它們。

  • 我使用 Claude 來重構它產出的代碼。最初的運行通常充滿了「代碼異味」(code smell)或暴露了潛在的異味,而這正是我生產力大幅提升的主要來源。我不再是在現有技術債之上交付更多技術債,而是能夠在每次 PR 中不斷償還債務,因為使用 Claude 進行重構的成本遠低於手動重構。

例如,代碼組織在錯誤的目錄結構中?手動修復很痛苦。Claude 可以在幾分鐘內完成,而我則去倒杯咖啡。

  • 有時我需要與 Claude 討論重構並進行規劃。過程看起來像這樣:

「嘿,這部分代碼對我來說看起來很奇怪。是怎麼回事?不要試圖修復它,只需向我解釋為什麼它是這樣的。」

  • Claude 回答

  • 「好,我們有哪些可以改進它的選項?」

  • Claude 提出一些解決方案

  • 「我們選選項 B,但修改一下以包含選項 C 的功能 2。或者其實我不喜歡這些,我們改做 [更好的方案]。」

  • 同樣地,如果我需要更多資訊來做決定,我會詢問。

我經常必須明確要求 Claude 查看文件或搜索網絡,以便獲取關於例如某個庫或 API 如何運作的正確資訊。這基本上總是值得花費時間的。

  • 最後,我從不對 Claude 生氣。有時它有點笨,或者包含了一個我直到審核者詢問我才注意到的更改,然後我看起來很蠢,因為我不知道它在那裡,但那是我的錯。如前所述,代碼的所有權屬於我,而不是 Claude,這意味著我對 Claude 的所作所為負有責任和義務。我發現這種心態對於有效使用 Claude Code 至關重要。

你能成為 5 倍速工程師嗎?

是的。大概吧。也許。如果你像我一樣使用 Claude,你得到的結果品質將很大程度上取決於你是一名多好的程式設計師。

從我與他人交談的情況來看,我能與 Claude 協作良好,是因為我有豐富的編程經驗——超過 30 年!我對高品質代碼的樣子有強烈的直覺,並且對哪些模式有效、哪些無效有清晰的想法。我可以引導 Claude 走向好的解決方案,因為我知道好的解決方案長什麼樣。沒有這項技能,我會迷失方向。

現在,我的直覺是通過多年手寫代碼、在風雪中背著打孔卡走上坡路(比喻艱苦的學習過程)換來的。如果你也處於這種情況,太好了,你可以像我一樣與 Claude Code 協作並取得良好效果。如果不是,你還能做什麼嗎?

我想是可以的。你可以通過與 Claude 交談並要求它向你解釋事情來學習。如果你掌握了一些基本動作,例如詢問權衡,以及請求幫助理解為什麼 Claude 認為某些更改是個好主意,你就可以利用它來自我提升,並迅速獲得大量經驗。這可能無法完全取代多年的經驗,但總比什麼都沒有好。而且現實地說,如果你剛起步並希望獲得足夠的生產力以獲得並保住工作,這就是你必須做的。

因為如果這篇文章有一件事是你應該記住的,那不是有很多種使用 Claude 或其他編碼代理來提高生產力的方法,而是你必須開始使用這些工具來變得更有生產力,以免被時代拋棄。

Lesswrong

相關文章

  1. 資深 C 程式設計師評測 AI 程式碼代理

    Hacker News · 3 個月前

  2. Claude 程式碼

    3 個月前

  3. 我如何利用 Claude Code 提高生產力

    Hacker News · 大約 1 個月前

  4. Feb 1, 2026ScienceLong-Running Claude for Scientific Research

    Anthropic Research · 3 個月前

  5. Claude 為我編寫了一個有 400 次提交的 RSS 閱讀器應用程式

    4 個月前