你是否曾經盯著一個空白的程式碼編輯器，感覺整個下午即將被吞噬在無盡的除錯迴圈裡？或者，你是否聽過 Claude Code——Anthropic 推出的終端機程式設計代理——卻將其視為另一個會產生一堆垃圾程式碼、需要你花更多時間清理的玩具？
如果答案是肯定的，那你並不孤單。多數人對 AI 程式設計的認知，仍停留在「問它一個問題，複製貼上程式碼，祈禱它編譯通過」的階段。這種用法不僅效率低下，還充滿了不確定性。
但這一切，在 Peter Yang 與 Thariq Shihipar 的這場 40 分鐘對談中，被徹底顛覆了。Thariq 並非一般的開發者，他是 Anthropic 的早期員工，親手參與了 Claude 模型的訓練與開發。他分享的，不是理論，而是他每天在真實專案中，如何將 Claude Code 當作一個「高階協作者」，系統性地規劃、構建和迭代程式碼。
這不僅僅是一場訪談，這是一份關於「如何與 AI 共事」的全新操作手冊。本文將從中提煉出 7 個最反直覺、最具衝擊力的核心要點，並將其轉化為你可以立即應用的行動指南。準備好顛覆你對程式設計的想像了嗎？
1. 別再問「怎麼做」，先問「做什麼」：從戰術執行到戰略規劃的思維躍遷
多數開發者使用 AI 程式設計工具的方式，就像在命令一個超級聰明但極度缺乏常識的實習生：「幫我寫一個 Python 函數來抓取這個網站的資料。」這是一種戰術性的提問，你已經預設了解決方案，只是希望 AI 幫你完成苦工。
Thariq 的做法完全相反。他將 Claude Code 視為一個戰略合作夥伴。在他的工作流程中，第一件事不是寫程式碼，而是規劃。他會先建立一個名為 CLAUDE.md 的檔案，這個檔案不是程式碼，而是專案的「憲法」與「設計文件」。
核心洞察：真正的生產力飛躍，不是來自於 AI 幫你寫程式碼，而是來自於 AI 幫你思考如何寫程式碼。
Thariq 在訪談中強調，他會花大量時間與 Claude Code 進行「對話式規劃」。他會描述一個高層次的目標，例如：「我想建立一個系統，能夠追蹤我的閱讀習慣，並自動產生摘要。」然後，他不會要求 Claude 立刻寫程式碼，而是要求它：
- 提出 2–3 個不同的技術方案。
- 分析每個方案的優缺點。
- 推薦一個最適合當前專案規模的方案。
- 定義出核心的資料模型與 API 介面。
這個過程，本質上是在進行一次「AI 驅動的系統設計」。Claude Code 不僅能理解你的意圖，還能基於其龐大的知識庫（包含無數開源專案、最佳實踐和設計模式），提供你從未想過的解決方案。
為什麼這很重要？ 因為寫程式碼的成本正在急遽下降。真正昂貴的，是做出錯誤的決策。一個錯誤的資料庫 schema 選擇、一個不合適的框架，可能會導致後續數週的重工。透過讓 AI 參與早期的規劃階段，你實際上是在用極低的成本，進行一次高品質的「設計審查」。
如何應用？
下次你開始一個新功能或專案時，不要急著打開編輯器。先打開終端機，輸入 claude，然後告訴它：「我有一個想法，想聽聽你的建議。這是我的目標……你覺得我該怎麼做？」你會驚訝地發現，這個簡單的步驟，能為你節省多少後續的麻煩。
2. 「慢思考」與「快執行」：用元提示 (Meta-Prompt) 為 AI 注入思考紀律
AI 程式設計代理最大的問題之一，就是「過於急躁」。當你問一個複雜問題時，它傾向於直接拋出一個看起來最合理的答案，但這個答案往往忽略了邊界情況、錯誤處理或長期的可維護性。
Thariq 揭露了一個關鍵技巧：強迫 Claude Code 進行「慢思考」。他使用了一個被他稱為「元提示」的系統，這個提示會引導 Claude 在行動前先進行深入的推理。
這個元提示的威力在於，它要求 Claude 在輸出任何程式碼之前，先回答一系列問題：
- 這個問題的核心挑戰是什麼？
- 有哪些潛在的陷阱或邊界情況需要考慮？
- 現有程式碼庫中有哪些部分可以重用或需要修改？
- 我的解決方案是否與專案整體的設計哲學一致？
這就像是在 Claude 的「大腦」中建立了一個檢查清單。它強迫 AI 從「快速模式」切換到「深度模式」。Thariq 甚至將這個元提示設定為 Claude Code 的系統提示，讓這個思考框架成為每次互動的預設行為。
「如果你不告訴 Claude 放慢腳步思考，它就會直接開始輸出程式碼。而這些程式碼，十之八九會忽略你真正在乎的事情。」—— Thariq Shihipar
為什麼這很反直覺？ 我們通常認為 AI 的優勢在於「快」。但 Thariq 的經驗告訴我們，對於複雜任務，「慢」才是真正的「快」。讓 Claude 花 30 秒思考一個問題，可以避免你花 30 分鐘去除錯它所產生的程式碼。
具體做法：
你可以在你的 CLAUDE.md 檔案中，或是在每次對話的開頭，加入類似這樣的提示：
「在回答任何問題或產生程式碼之前，請先分析問題的核心。列出你的假設、潛在的挑戰和邊界情況。然後，提出至少兩種解決方案，並解釋你為何選擇其中一種。最後，才開始撰寫程式碼。」
這個簡單的動作，就能將 Claude Code 從一個「程式碼產生器」升級為一個「深思熟慮的工程師」。
3. 迭代的藝術：不是「一次寫好」，而是「快速循環」
傳統的程式設計流程是：規劃 -> 撰寫程式碼 -> 測試 -> 除錯 -> 重複。這個循環可能很長，尤其是在處理複雜功能時。
Thariq 的工作流程將這個循環壓縮到了極致。他描述了一個「內循環」與「外循環」的概念。
- 外循環：高層次的規劃、架構設計、程式碼審查。這通常需要人類的主導。
- 內循環：具體的函數實作、單元測試、除錯。這完全交給 Claude Code 自主運作。
他會給 Claude Code 一個明確的任務，例如：「為這個使用者認證模組，新增 Google OAuth 登入功能。」然後，他不會在一旁監看每一行程式碼的產生。相反地，他會讓 Claude Code 自主地進行一個又一個的「迭代循環」：
- 讀取：Claude 會先讀取相關的檔案，理解現有的程式碼結構。
- 規劃：它會根據任務描述和專案規範，提出具體的實作步驟。
- 撰寫：它會開始撰寫程式碼，並在過程中自動執行 linting 和靜態分析工具。
- 測試：它會撰寫並執行單元測試，確保新程式碼的正確性。
- 除錯：如果測試失敗，它會分析錯誤訊息，修改程式碼，然後再次測試。
- 提交：當所有測試通過後，它會將變更提交到 Git，並撰寫有意義的 commit message。
這個過程完全自主，Thariq 只需要在「外循環」的層面進行監督和審查。這就像是一位經理，將一個完整的任務交給一位能幹的工程師，然後只在關鍵的里程碑處進行檢查。
為什麼這很強大？ 因為它解放了開發者的大腦。你不再需要同時處理多個層次的抽象——從高層的設計到低層的語法錯誤。你可以將注意力完全集中在「做什麼」和「為什麼」上，而將「怎麼做」的繁瑣細節，交給 Claude Code 這個不知疲倦的夥伴。
數據佐證： Thariq 提到，透過這種方式，他能夠在數小時內，完成過去需要數天甚至數週才能完成的原型開發。這不是誇大，而是當你將「除錯循環」從「人類手動」轉為「AI 自主」時，必然會產生的效率飛躍。
4. 給 AI 一個「家」：CLAUDE.md 不是選項，是必需品
這可能是 Thariq 分享的最重要、也是最容易被忽略的實戰技巧。他反覆強調 CLAUDE.md 檔案的重要性。這不是一個可有可無的裝飾品，而是整個 AI 協作工作流程的基石。
CLAUDE.md 是什麼？它是一個位於專案根目錄的 Markdown 檔案，作為 Claude Code 的「長期記憶」和「行為指南」。它告訴 Claude：
- 專案背景：這個專案是做什麼的？目標用戶是誰？
- 技術棧：我們使用什麼語言、框架、資料庫？
- 程式碼規範：我們偏好什麼樣的命名慣例、程式碼風格、測試覆蓋率？
- 架構原則：我們遵循什麼樣的設計模式（如 MVC、Clean Architecture）？
- 關鍵決策：為什麼選擇這個資料庫？為什麼不使用某個套件？
- 常見陷阱：這個專案有哪些容易出錯的地方？過去發生過什麼問題？
為什麼它如此關鍵？ 因為沒有這個檔案，Claude Code 每次啟動時，都像是一個失憶的員工，需要從零開始理解你的專案。它可能會提出與你設計理念完全相悖的建議，或者產生風格不一致的程式碼。
Thariq 的做法是，將 CLAUDE.md 視為一個動態的文件。他會隨著專案的演進，不斷地更新它。當他做出一個重要的架構決策時，他會要求 Claude 將這個決策記錄到 CLAUDE.md 中。當他發現一個反覆出現的問題時，他會將其加入「常見陷阱」清單。
「CLAUDE.md 是我們與 AI 之間的合約。它確保我們每次對話，都能從同一個基準點開始，而不會浪費時間在重複解釋上。」
具體案例：
假設你正在開發一個 React 專案，你決定使用 styled-components 來進行樣式管理。你可以在 CLAUDE.md 中寫明：
框架: React 18樣式方案: styled-components狀態管理: Zustand測試: Vitest + React Testing Library
當你之後要求 Claude Code 「新增一個用戶資料頁面」時，它會自動使用 styled-components 來撰寫樣式，使用 Zustand 來管理狀態，並使用 Vitest 來撰寫測試。這一切都不需要你再次指示。
5. 重構不再是惡夢：AI 驅動的程式碼演化
對於任何一個中大型專案，重構都是開發者心中永遠的痛。害怕改壞東西、害怕遺漏關聯的檔案、害怕引入新的 bug——這些恐懼使得許多程式碼庫逐漸腐化，最終變得難以維護。
Thariq 展示了 Claude Code 如何將重構從一個高風險的活動，轉變為一個常規的、甚至有些無聊的任務。關鍵在於，Claude Code 能夠全面地理解程式碼庫的依賴關係。
當 Thariq 想要重構一個核心模組時，他不會自己動手。他會對 Claude Code 下達一個高層次的指令，例如：「將 UserService 類別中的資料庫查詢邏輯，遷移到一個新的 UserRepository 類別中，並更新所有引用。」
Claude Code 會執行以下操作：
- 分析依賴圖：它會掃描整個程式碼庫，找出所有直接或間接引用
UserService的地方。 - 建立新檔案：它會根據最佳實踐，創建
UserRepository類別，並將相關邏輯遷移過去。 - 修改舊檔案：它會修改
UserService，使其依賴於新的UserRepository，而不是直接操作資料庫。 - 更新所有引用：它會遍歷所有受影響的檔案，逐一更新 import 語句和函數呼叫，以符合新的架構。
- 執行測試：它會執行整個測試套件，確保所有變更沒有破壞任何現有功能。
- 提交變更：它會將所有變更分門別類，提交到 Git，並撰寫清晰的 commit message。
這對你意味著什麼？ 這意味著你可以更頻繁地進行重構。不再需要等到「有時間」或「有勇氣」才去清理技術債。你可以將重構視為開發流程的一部分，就像寫測試一樣自然。這使得程式碼庫能夠持續地演化，保持健康和可維護性。
一個值得深思的點： 當重構的成本趨近於零時，程式設計師的價值將不再體現在「如何寫出不會壞的程式碼」，而是體現在「如何設計出能夠被輕易重構的架構」。這是一個微妙的，但至關重要的轉變。
6. 終結「上下文切換」：讓 AI 成為你的第二螢幕
每個開發者都熟悉「上下文切換」的痛苦。當你正在深入思考一個演算法時，突然需要去檢查 Slack 訊息、回覆 Email、或查看一個錯誤報告。等你回過神來，可能已經過了 15 分鐘，而你完全忘記自己剛才在想什麼。
Thariq 提出了一個極具想像力的用法：將 Claude Code 當作你的「第二螢幕」或「副駕駛」，來處理那些會打斷你心流的工作。
例如，當他在撰寫一個複雜的商業邏輯時，突然想到：「我應該為這個函數寫一個測試。」在過去，他必須停下手邊的工作，切換到測試檔案，寫下測試案例，然後再切換回來。這個過程會打斷他的思路。
現在，他會直接對 Claude Code 說：「幫我為 calculateRevenue 這個函數寫一個測試，覆蓋正常情況、邊界情況和錯誤輸入。」然後，他繼續撰寫他的商業邏輯。幾秒鐘後，Claude Code 就會在背景完成測試的撰寫，並將其加入到適當的測試檔案中。
這不僅僅是「多工」，這是「平行運算」。人類的大腦擅長創造性的、高層次的思考，而 AI 擅長執行明確的、重複性的任務。透過將這兩者結合，你可以讓自己的大腦專注於它最擅長的事情，同時讓 AI 處理那些會造成干擾的瑣事。
其他應用場景：
- 撰寫文件： 在完成一個 API 端點後，直接要求 Claude Code 為其撰寫 API 文件。
- 產生測試資料： 需要一些測試用的 JSON 資料？直接告訴 Claude Code 你需要的結構和數量。
- 格式化程式碼： 覺得程式碼排版很亂？讓 Claude Code 幫你執行 linter 和 formatter。
- 除錯日誌： 當你看到一個奇怪的錯誤日誌時，直接貼給 Claude Code，讓它幫你分析可能的原因。
這個技巧的核心在於，將「打斷」轉變為「委派」。你不是在停止工作，而是在將一個子任務委派給一個高效的代理人。這極大地保護了你的心流狀態，從而顯著提升整體生產力。
7. 信任，但要驗證：建立 AI 時代的程式碼審查流程
最後，也是最重要的一點：不要盲目信任 AI。Thariq 雖然對 Claude Code 的能力讚不絕口，但他也反覆強調，人類開發者仍然是最終的負責人。AI 產生的程式碼，必須經過嚴格的審查。
但他的審查方式，也與傳統方式截然不同。他不會一行一行地檢查程式碼，因為那太耗時，也違背了使用 AI 的初衷。相反地，他採用了一種更高層次的審查策略：
- 要求 Claude Code 解釋其決策：在審查程式碼之前，他會先要求 Claude Code 解釋它為什麼選擇某種實作方式。這能幫助他快速理解程式碼的意圖，並判斷其合理性。
- 審查邊界情況：他會特別關注程式碼是否處理了所有預期的邊界情況，例如空值、錯誤輸入、並發問題等。
- 檢查一致性：他會檢查新程式碼是否符合
CLAUDE.md中定義的專案規範和架構原則。 - 執行整合測試：除了 Claude Code 自動執行的單元測試，他還會手動執行一些關鍵的整合測試或端到端測試，確保新功能與系統的其他部分能夠正常協作。
「AI 就像一位非常聰明、但偶爾會產生幻覺的初級工程師。你必須審查它的工作，但你的審查方式應該是『指導』，而不是『代勞』。」
建立一個可複用的審查流程： 你可以要求 Claude Code 在每次提交程式碼時，同時產生一個「程式碼審查摘要」，內容包括：
- 本次變更的目標。
- 實作的核心邏輯。
- 測試覆蓋情況。
- 任何已知的風險或限制。
這樣，你在審查程式碼時，就能夠快速掌握重點，將精力集中在那些真正需要人類判斷力的地方。
一個重要的提醒： 永遠不要將包含敏感資訊（如 API 金鑰、資料庫密碼）的程式碼，未經審查就提交到版本控制系統。雖然 Claude Code 不會主動洩漏這些資訊，但確保程式碼的安全性，始終是人類開發者的責任。
核心觀點總匯
| 要點 | 核心概念 | 為什麼重要 | 如何應用 |
|---|---|---|---|
| 戰略規劃 | 從問「怎麼做」轉為問「做什麼」 | 避免因錯誤決策而浪費時間 | 使用 CLAUDE.md 進行高層次規劃 |
| 慢思考 | 使用元提示強迫 AI 進行深度推理 | 顯著減少除錯時間，提升程式碼品質 | 在系統提示中加入思考框架 |
| 快速迭代 | 建立 AI 自主的「內循環」 | 將開發者從繁瑣的除錯循環中解放 | 將完整任務委派給 Claude Code |
| 專案憲法 | CLAUDE.md 是 AI 的長期記憶 | 確保 AI 行為與專案目標一致 | 持續更新 CLAUDE.md |
| 無痛重構 | AI 全面理解程式碼依賴關係 | 降低重構風險，鼓勵持續程式碼演化 | 直接下達高層次重構指令 |
| 平行運算 | 將打斷轉變為委派 | 保護開發者的心流狀態 | 將子任務（如寫測試）委派給 AI |
| 信任驗證 | 建立 AI 時代的程式碼審查流程 | 確保最終產品的品質與安全性 | 要求 AI 解釋決策，並檢查邊界情況 |
總結：程式設計的未來，是對話，不是打字
Thariq Shihipar 的這場訪談，不僅僅是關於一個工具的使用技巧。它揭示了程式設計本質的轉變：我們正從一個「打字員」的時代，進入一個「指揮官」的時代。
未來的開發者，其核心競爭力不再是記憶語法或撰寫演算法的速度，而是：
- 定義問題的能力：能否將一個模糊的想法，轉化為清晰、可執行的任務。
- 系統設計的能力：能否設計出優雅、可擴展的架構，讓 AI 能夠在其上高效工作。
- 審查與批判的能力：能否判斷 AI 產出的程式碼是否真的符合需求，並在必要時給予正確的指導。
Claude Code 不是來取代你的，它是一個放大器。它放大了你的思考能力，讓你能夠將更多的精力放在創造性的工作上，而不是被重複性的勞動所淹沒。
留給你一個值得深思的問題：
如果你的程式碼可以被 AI 寫得又快又好，那麼你作為一個開發者，你獨一無二的價值究竟在哪裡？是你能寫出 AI 寫不出來的程式碼，還是你能看到 AI 看不到的商業價值與使用者需求？
這個問題的答案，將定義你在未來十年職業生涯的高度。