這是一個 SasaDaily 假設商業案例。

不是 Anthropic 官方客戶，也不是已公開的真實導入成果。

假設一家 7 人企業軟體整合公司，團隊組成是：

  • 1 位老闆／技術主管
  • 1 位 Project Manager
  • 3 位軟體工程師
  • 1 位 Mobile Engineer
  • 1 位 QA

公司替中小企業串接 ERP、會員系統、付款、Web 與 Mobile App。

表面上看，工程師最花時間的是寫 Code。

但只要遇到一個跨系統改版，真正麻煩的常常是：

五個地方都要改，而且每個人都要知道其他人改了什麼。

假設今天客戶要淘汰舊 API

例如客戶準備停用原本的：

v1 Customer API

改成新的 v2。

這不是把一支 API 換掉就結束。

它可能同時牽涉：

  • Backend Service
  • Web 後台
  • Mobile App
  • Automated Tests
  • API Documentation
  • Deployment Order

以前團隊可能這樣做：

PM 先跟 Backend Engineer 說一次。

再跟 Web Engineer 說一次。

再重新解釋給 Mobile Engineer。

Backend 做到一半發現欄位改名，再回頭通知其他人。

Web 已經先按照舊規格寫完，又要重新修改。

等所有人做完，才開始問：

到底哪個 PR 要先 Merge？

Claude Code Projects 想改的，就是這段協調工作。

第一步：人先定 Goal，不先叫 AI 亂改

團隊建立一個 Claude Code Project。

先寫清楚：

目標：淘汰 v1 Customer API，讓 API、Web、Mobile 全部改用 v2。

同時放入：

  • API Repository
  • Web Repository
  • Mobile Repository
  • Migration 說明
  • Client Requirements
  • Project Instructions

但團隊另外寫三條不能省略的規則：

Production 不得自動 Deploy。

Database Migration 執行前一定停。

涉及 Auth、Payment 或客戶資料結構的修改一定由技術主管確認。

AI 可以幫忙做很多事，但決定權先畫清楚。

第二步：Coordinator 先拆工作

Anthropic 對新版 Projects 的設計，就是讓最上層 Claude 負責 Scope、Delegate 與協調 Threads。

在這個假設案例裡，Coordinator 可能把工作拆成：

Thread A

檢查 API Repository，找出所有 v1 Endpoint 與替代方式。

Thread B

修改 Web Repository 裡的 v1 Calls。

Thread C

修改 Mobile Repository。

Thread D

更新 Automated Tests。

Thread E

整理 Migration Documentation。

這幾條工作可以同時前進。

工程師不需要自己開五個 Claude Code Session，再一直切視窗看誰做到哪裡。

第三步：規格改變放進 Shared Memory

做到一半，API Engineer 發現：

原本文件裡的：

customer_total

最後決定改成：

lifetime_value

而且 Mobile App 舊版還需要兩週相容期。

這種資訊如果只留在某一條 Chat，後面很容易出事。

新版 Claude Code Projects 的每一條 Thread 都會使用，也能貢獻同一個 Shared Memory。

在這個假設 Workflow 裡，團隊可以把：

  • 欄位名稱變更
  • 相容期限
  • Release Date
  • 某功能取消原因
  • 哪個服務修改前一定要找誰

留在同一個 Project Context。

所以後面的 Thread 不必每次從頭重新交代。

但要注意：

Shared Memory 不等於 Code 自動同步。

每一條 Thread 還是在自己的 Branch 與 Repository Copy 工作。

第四步：每條 Thread 自己改、自己測

Anthropic 官方說明，連接 Repository 後，Thread 可以：

  • 修改 Code
  • 執行 Tests
  • 開 Pull Request

所以假設 Web Thread 完成後，可以先：

改 Code

→ 跑 Tests

→ 開 PR。

Mobile Thread 也可以在自己的 Branch 做同樣流程。

這時候真正省下來的，不一定只是打字速度。

而是原本：

「一個做完，下一個人才開始」

開始變成：

可以平行的工作同時往前。

第五步：Coordinator 整理，但不替人按 Production

假設最後五條 Threads 都完成。

Coordinator 可以協助整理：

  • 哪些 PR 已完成
  • Tests 是否通過
  • 哪些工作互相依賴
  • 哪一個 PR 應該先 Merge
  • 還有什麼未解問題

但團隊沒有把最後決策交出去。

Human Gate 仍然保留在：

① Architecture

新的 API 設計是否真的符合客戶需求。

② Merge

多個 Branch 最後是否能安全整合。

③ Database Migration

正式資料結構要不要變更。

④ Auth／Payment

涉及登入、權限、付款不能只看 AI 說「測試通過」。

⑤ Production Deploy

最後上線仍由技術主管批准。

這一點很重要。

因為 Anthropic 也明確說明：

如果兩條 Threads 修改到同一段 Code，還是可能產生正常的 Merge Conflict。

Coordinator 可以幫你管理 AI，

但不代表 Software Engineering 的風險因此消失。

假設 ROI 怎麼算？

這裡不用「AI 幫你省 80% 開發時間」這種沒有依據的數字。

只算一個比較容易量化的東西：

跨人員協調時間。

假設這家公司每週平均有 3 個跨 Repository 的 Change Requests。

原本每週花在：

  • 重新解釋 Context
  • 同步規格
  • 查各人進度
  • 整理 Handoff
  • 確認 Merge 順序

總共約：

6 小時／週。

導入這套 Workflow 後，假設降低到：

3.5 小時／週。

理論上少掉：

2.5 小時／週。

一個月以四週計算：

約 10 小時／月。

如果用假設內部綜合工程時間成本：

NT$900／小時

計算，

理論時間價值約：

NT$9,000／月。

但這不能直接理解成公司每月多賺 NT$9,000。

因為還要扣掉：

  • Claude 使用成本
  • 額外 QA
  • Code Review
  • Merge Conflict 處理
  • 導入與學習成本
  • AI 產生錯誤後的返工

所以真正該追蹤的 KPI 不是「開了幾個 Agent」。

而是：

Handoff 時間有沒有下降？

返工有沒有增加？

PR Lead Time 有沒有縮短？

Production Incident 有沒有上升？

這個案例真正改變的是什麼？

以前團隊的流程比較像：

人分工作

→ 人重複講 Context

→ 每個人各自做

→ 人追進度

→ 人重新整合。

Claude Code Projects 想把它改成：

人定目標與邊界

→ Coordinator 拆工作

→ 多 Threads 平行執行

→ Shared Memory 保留共同 Context

→ AI 整理結果

→ 人 Review

→ 人批准 Merge／Migration／Deploy。

AI 真正適合接手的，不一定是「整個軟體專案」。

反而可能是中間大量、重複的：

拆工作、搬 Context、追進度、整理結果。

最後真正會影響客戶、資料與 Production 的決定，仍然留在人手上。

如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」，我可以先幫你看看從哪一步開始。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀

AI 商業案例｜2026/09/11：6 人 SaaS 團隊怎麼用 Qodo？Coding Agent 改完先獨立 Review，Production 決策仍由人批准

AI 商業案例｜2026/09/07：5 人網站維護團隊怎麼用 Qwen Code？專案規則分開記、多個 Agent 分工，正式上線仍由人批准

AI 商業案例｜2026/08/24：6 人網站代營運團隊怎麼用 Slack Code？客戶小改版直接變 Plan、Preview 與 Review，上線仍由人批准