使用 Tactic Remote 建立團隊工作流

Tactic Remote 最初為個人開發者設計，但越來越多的團隊開始採用它。本指南介紹如何為開發團隊設定 Tactic Remote，包括共享基礎設施、存取管理和工作流規範，讓每個人都能高效協作而不互相干擾。

團隊架構

個人開發者在自己的 Mac 上執行 Tactic Remote。團隊則有更多選擇：

方案 A：個人 Mac，獨立設定

每位開發者在自己的 Mac 上執行 Tactic Remote 伴侶應用，並從自己的 iPhone 連線。這是最簡單的設定，團隊成員之間完全隔離。

適合： 小型團隊（2-5 人），每個人都有效能足夠的 Mac，且主要在程式碼庫的不同部分工作。

優點： 零共享基礎設施，完全隱私，無協調開銷。 缺點： 無法共享工作階段可見性，每位開發者自行管理設定。

方案 B：共享開發伺服器

一台專用 Mac（Mac Mini、Mac Studio 或 Mac Pro）執行 Tactic Remote 伴侶應用，配置多個使用者帳號。每位開發者連線到共享機器上自己的使用者帳號。

適合： 5-15 人的團隊，希望集中管理基礎設施但不共享工作階段。

設定方法：

1. 在共享 Mac 上為每位開發者建立 macOS 使用者帳號。
2. 在每個使用者帳號中安裝 Claude Code 和 tmux。
3. 按使用者執行 Tactic Remote 伴侶應用（每人取得唯一連接埠）。
4. 設定 Cloudflare Tunnel，使用按開發者分配的子網域路由。

developer1.team.example.com → localhost:3001 (開發者 1 的伴侶應用)
developer2.team.example.com → localhost:3002 (開發者 2 的伴侶應用)
developer3.team.example.com → localhost:3003 (開發者 3 的伴侶應用)

每位開發者從自己的 iPhone 使用個人子網域連線。工作階段在開發者之間隔離，但基礎設施是集中管理的。

優點： 集中管理，環境一致，開發者不需要高效能的個人 Mac。 缺點： 共享機器資源競爭，單點故障。

方案 C：混合設定

資深開發者和技術負責人使用共享伺服器（保持一致性和團隊可見性），一般開發者使用個人 Mac。這在靈活性與協調性之間取得平衡。

團隊規範

技術設定是簡單的部分。團隊規範才是讓 AI 程式設計工具協作真正發揮作用的關鍵。

規範 1：工作階段命名標準

採用一致的工作階段命名格式。我們推薦：

{開發者縮寫}-{專案}-{工作重點}

範例：

• jk-api-auth-module
• ms-frontend-dashboard-redesign
• tc-infra-ci-pipeline

這讓每個工作階段的擁有者和工作內容一目瞭然。在共享伺服器上，當多個開發者的工作階段同時可見時，可以避免混淆。

規範 2：每工作階段一分支

每個 Claude Code 工作階段應在專用的 Git 分支上工作：

ai/{開發者}/{描述}

範例：

• ai/jkim/add-user-auth
• ai/msmith/refactor-payment-flow

這一規範的好處：

• 防止並行 AI 工作階段之間的合併衝突
• 使程式碼審查更清晰（每個 AI 工作階段對應一個 PR）
• 在 Git 歷史中清楚標識 AI 產生的變更
• 如果某個 AI 工作階段產出品質不佳，可以輕鬆回復

規範 3：審批升級

並非所有審批決策都應由單一開發者做出。定義團隊層級的審批類別：

自行審批（個人開發者）：

• 在工作階段專案範圍內讀寫檔案
• 執行測試
• 安裝開發依賴
• 程式碼格式化和 lint 修正

同儕審批（通知隊友）：

• 資料庫 schema 變更
• API 契約變更（介面簽章、回應格式）
• 涉及安全的程式碼修改
• 共享設定檔的變更

負責人審批（需要技術負責人簽核）：

• 生產環境部署命令
• 基礎設施變更
• 依賴主版本升級
• 認證或授權邏輯的變更

實施這一規範需要的是紀律而非工具（Tactic Remote 目前還不能強制執行團隊審批策略），但儘早建立規範可以防止代價高昂的失誤。

規範 4：每日 AI 站會

在每日站會中增加一個簡短的 AI 專題環節：

• 有哪些 AI 任務在夜間或上午完成了？
• 目前有哪些 AI 任務正在執行？
• 是否有需要團隊討論的審批請求？
• 有沒有 AI 產生的程式碼需要大量手動修正？

這讓團隊了解 AI 活動情況，及早發現品質問題。它還幫助團隊學習哪些類型的任務 AI 處理得好，哪些仍需要人工實作。

共享提示詞庫

在程式碼儲存庫中建立團隊層級的提示詞庫：

.claude-prompts/
├── code-review.md       # 標準程式碼審查提示詞
├── test-coverage.md     # 測試覆蓋率分析提示詞
├── security-audit.md    # 安全審查提示詞
├── pre-deploy.md        # 部署前檢查清單
├── dependency-update.md # 依賴更新流程
└── new-feature.md       # 功能實作範本

每個檔案包含團隊透過實際使用不斷完善的成熟提示詞。例如 code-review.md：

Review the diff for this branch against main. Evaluate:
 
1. Correctness: Does the code do what it claims?
2. Edge cases: What inputs or conditions could cause failure?
3. Security: Are there injection, auth, or data exposure risks?
4. Performance: Any O(n²) patterns, missing indexes, or memory leaks?
5. Maintainability: Would a new team member understand this code?
 
For each issue found, provide:
 
- Severity (critical / warning / suggestion)
- File and line reference
- Explanation of the problem
- Suggested fix
 
If the code looks good, say so — don't invent issues.

團隊成員從 Tactic Remote 參照這些提示詞：

Follow the code-review prompt in .claude-prompts/code-review.md
for the current branch.

這確保了無論哪位開發者在指導 AI，都能維持一致的品質標準。

監控團隊活動

在共享伺服器上，Mac 伴侶應用的狀態面板顯示所有開發者的活躍工作階段。技術負責人可以監控：

• 當前並行執行的 AI 工作階段數量
• 各工作階段的資源使用情況（CPU、記憶體）
• 工作階段時長和活動模式
• 審批回應時間

這種可見性有助於識別共享伺服器何時需要升級、某位開發者是否需要幫助（工作階段等待審批數小時）、以及團隊規範是否被遵守。

團隊安全

團隊使用放大了安全方面的考量：

API 金鑰管理： 每位開發者應擁有唯一的 API 金鑰。共享金鑰使稽核「誰做了什麼」變得不可能。將團隊 API 金鑰儲存在具有存取控制的密碼管理器中。

工作階段隔離： 在共享伺服器上，驗證開發者之間無法存取彼此的 tmux 工作階段。macOS 使用者帳號隔離提供了這一保障，但需要透過測試驗證。

程式碼存取範圍： 確保每位開發者的 Claude Code 工作階段只能存取其有權限工作的程式碼儲存庫。使用 macOS 檔案權限和 Git SSH 金鑰分離來實現。

離職處理： 當開發者離開團隊時，撤銷其 API 金鑰，終止其工作階段，並從共享伺服器上移除其使用者帳號。將此流程記錄在離職檢查清單中。

團隊採用入門

我們推薦分階段進行：

1. 第 1 週： 兩位開發者各自設定 Tactic Remote 實例，在一個迭代週期中使用。
2. 第 2 週： 分享經驗，建立命名規範和提示詞庫。
3. 第 3 週： 在文件化規範的基礎上推廣到整個團隊。
4. 第 4 週： 評估——什麼有效，什麼需要調整？

從小處著手，快速學習，審慎擴展。Tactic Remote 是一個強大的團隊工具，但它的效果既取決於技術本身，也同樣取決於圍繞它建立的規範。

如需個人設定，請參閱快速開始。如需連線選項，請參閱區域網路和 Cloudflare Tunnel。