TLDR¶

• 核心重點：受 Boris Cherny 啟發，於 iTerm2 多終端並行工作以提升 Claude Code 的上下文管理與工作效率
• 主要內容：結合多終端工作與 Git 工作樹，降低衝突風險並提升實作效率
• 關鍵觀點：平行佈局可分工與並行處理，需透過工作樹避免實質衝突
• 注意事項：仍在實驗階段，需實務中逐步驗證穩定性與可擴展性
• 建議行動：嘗試建立多終端工作佈局，搭配工作樹策略並觀察衝突處理效果

內容概述與背景
近年來，Boris Cherny 的 Claude Code 使用方法在開發者社群中廣為流傳。他的做法重點在於讓使用者能在多個終端中同時進行作業，藉由平行工作來實現快速切換與更有效的上下文管理，進而提高工作效率。這篇文章在 Cherny 設定的啟發基礎上，提出一個延伸方案：在原有平行工作流程之上，加入 Git 工作樹（Git worktrees）的機制，以實現實際工作中的衝突最小化與併發作業的穩定性提升。作者目前仍在實驗與優化中，但已具備足夠的可操作性，值得其他開發者作為起點參考。

平行工作與上下文管理的核心概念
– 平行工作：在多個終端或分支視角同時執行不同任務，避免把所有工作堆疊在單一終端中，藉此降低切換成本與訊息混淆。
– 上下文管理：不同任務往往需要不同的專案狀態、環境配置與資料集。通過平行佈局，可以清楚劃分各自的工作上下文，減少干擾與錯誤。
– 工作樹（Worktrees）：Git 的工作樹機制允許同一個倉庫同時擁有多個分支的工作目錄，這對需要在同一專案中同時處理不同分支或實驗的場景尤為有用，能有效避免分支切換帶來的衝突與依賴混淆。

為何要將工作流程與工作樹結合
– 真實任務的複雜性：在軟體開發與模型微調等工作中，往往需要同時處理多個任務或實驗，例如代碼修正、資料處理、參數調整與測試。單一終端容易成為瓶頸。
– 衝突風險的降低：當多個任務在不同工作樹中運作時，改動彼此彼此不易互相影響，若需要整合，仍可以工作樹方式清晰管理與合併。
– 提高穩定性與可重現性：工作樹允許在不同的實驗分支間快速切換且保持環境一致，降低因為頻繁切換造成的版本不一致風險。

實作要點與步驟概覽
以下內容為基於 Cherny 的基礎佈局與本文作者的延伸思想，實作時需依個人工作流調整。整體目標是在 iTerm2 等終端環境中，透過平行終端配置與 Git 工作樹機制，達到更流暢且可控的工作流程。

1) 規劃平行終端佈局
– 建立多個獨立終端視窗或分屏，每個終端對應特定任務（例如模型訓練、程式碼修改、資料前處理、測試與文件撰寫）。
– 為每個任務分配明確的工作目錄與環境設定，確保終端間的路徑與虛擬環境互不干擾。
– 設置便於切換的快捷鍵與工作區命名規範，提升長時間工作中的可辨識性。

2) 配置與管理 Git 工作樹
– 在主倉庫位置建立多個工作樹目錄，每個工作樹對應不同分支或實驗。典型做法如下：
– git worktree add -b feature-a ../worktree-feature-a main
– git worktree add -b experiment-1 ../worktree-experiment-1 main
– 在各自工作樹內執行相關開發與測試，避免直接在主工作目錄中進行高風險變更。
– 定期同步與合併：根據實驗結果，將穩定的改動合併回主分支，並在必要時更新其他工作樹的對應分支。

3) 環境與工具的一致性
– 為每個工作樹設定相同的依賴版本與虛擬環境，避免因版本不同而產生不可預期的問題。
– 使用容器化或虛擬環境管理工具（如 Python 的 virtualenv/conda、Node 的 nvm 等）確保一致性。
– 建立共用的設定模板與自動化腳本，減少手動調整的風險。

4) 輸出與整合的流程控制
– 對於需要跨工作樹整合的任務，採用清晰的合併策略與測試流程，例如在獨立工作樹完成後再提交合併分支，並在整合分支通過自動化測試。
– 使用版本管理與日誌紀錄，確保每個實驗的變更可追溯，便於回溯與重現。

可操作的實務建議
– 從小規模開始：先在單一專案中建立兩個工作樹，分別處理不同任務，逐步擴展到多個專案。
– 設定穩定的工作命名與路徑規範，例如以專案名-任務名-日期的方式命名工作樹資料夾，方便日後溯源。
– 適度自動化：撰寫簡單的 shell 腳本或 Makefile，協助啟動各工作樹、啟用對應的虛擬環境，以及執行測試流程。
– 定期檢視衝突與分支策略：即使使用工作樹，也需留意分支之間的依賴與相容性，避免積聚影響穩定性的變更。

風險與局限
– 複雜度增加：平行工作與多工作樹雖然能提升效率，但也讓專案結構與工作流程變得相對複雜。需要清晰的規範與良好的紀錄習慣。
– 環境一致性挑戰：若不同工作樹中使用的套件版本或依賴不一致，容易造成測試結果不一致或執行失敗，需要嚴格的版本管理與同步機制。
– 資源管理：同時在多個終端執行密集任務時，需注意系統資源的分配與負載，以避免效能下降或系統不穩定。

結論與展望
本文提出的工作流程，基於 Boris Cherny 的平行工作模式，加入了 Git 工作樹的實務應用，以提升在 Claude Code 等工具中的實際工作效率與衝突控制。雖仍處於實驗與優化階段，但該方法已展現出可行性，對於需要在同一專案內進行多任務並行處理的開發者具備一定的參考價值。隨著實作經驗的累積，未來可以進一步完善自動化程度、建立更嚴謹的工作樹管理策略，以及把這套流程推廣到更廣泛的工作場景中。

*圖片來源：description_html*

內容概述¶

本文章以 Boris Cherny 的 Claude Code 平行工作佈局為起點，提出在 iTerm2 等終端環境中，結合 Git 工作樹機制，讓實際工作（包括編碼、測試、資料處理與模型調整等）能在多個獨立工作區間並行進行，從而提升上下文管理效率與整體工作效率。作者指出此方法在實務中已展現出穩定性，雖仍在測試階段，但具備成為他人起點的價值。

深度分析¶

平行工作模式的核心在於將不同任務分離至獨立的終端與工作樹，避免將所有變動集中於單一工作目錄，進而降低混亂與衝突風險。Git 工作樹作為關鍵技術，允許同一倉庫存在多個工作目錄，對於同一專案中的實驗分支和特性開發尤為適用。透過工作樹，開發者可以在不干擾主分支的前提下，獨立推進各自的實驗與修正，等到需要整合時再透過標準的 Git 流程完成合併與測試。

實務層面，平行終端的布局需要清晰的任務劃分與一致的環境設定。每個終端對應一個明確任務，例如模型訓練、程式碼調整、資料前處理、測試與文件整理等，透過分工與專注來提升效率。若搭配工作樹，則可以在不同工作樹中分別管理分支與改動，避免跨任務的依賴衝突，並在需要時以合併或 rebase 的方式整合變更。

然而，這樣的流程也伴隨風險與挑戰。複雜度的提升需要良好的紀錄與規範，否則可能造成溝通成本提高與衝突未被及時發現。環境一致性是另一個重點，若不同工作樹使用的依賴版本不一致，測試與執行結果可能出現差異。因此，建立版本控制與自動化流程、統一的虛擬環境策略，以及有效的日誌與回溯機制，是成功落地的關鍵。

未來發展方向可聚焦於多工作樹與自動化工具的整合，例如：
– 自動化建置腳本，讓新工作樹自動安裝相同版本的依賴與環境。
– 對多終端任務提供視覺化的狀態儀表，便於快速評估任務間的資源分配與進度。
– 提升合併與測試流程的自動化程度，降低人工介入的需求。

觀點與影響方面，平行工作與工作樹的組合，若能被廣泛採用，將推動開發流程向更高的併發性與可重現性發展。對於大型專案、持續整合與模型訓練環境尤具價值，能降低整體開發週期與衝突成本，但需要社群與團隊共同建立的最佳實踐與工具支援，才能在更廣泛的場景中穩定落地。

重點整理
關鍵要點：
– 以平行終端與 Git 工作樹實現多任務並行工作
– 工作樹降低分支衝突與環境不一致的風險
– 需建立清晰規範、版本管理與自動化流程

需要關注：
– 系統複雜度與管理成本的增加
– 環境版本不一致的風險與影響
– 跨任務的協同與溝通機制

總結與建議
本文提出的工作流程結合了 Cherny 的平行工作理念與 Git 工作樹實作，為在 Claude Code 等工具中進行實務工作提供了一條具可操作性的路徑。雖然仍處於實驗與優化階段，但其核心思路具備長期可行性。建議讀者在自身工作流程中，先以小規模、低風險的專案嘗試，逐步建立多終端與工作樹的配套規範與自動化工具，並在穩定後再擴展到更複雜的專案與團隊合作場景。

相關連結¶

• 原文連結：https://dev.to/kamilbuksakowski/parallel-work-with-claude-code-in-iterm2-a-workflow-inspired-by-boris-cherny-5940
• 相關參考連結將在實際整理時補充，以提供讀者更全面的背景與實作資源

禁止事項：
– 不提供思考過程或顯示“Thinking…”的標記
– 文章必須直接以「## TLDR」開始

注意：本改寫保留原文的核心資訊與理念，並以繁體中文呈現，加入背景解釋與實務建議，語調保持客觀中性，文章長度控制在1500-2000字。

*圖片來源：description_html*