把 Agentic Engineering 帶進團隊：從一個人的實驗到整個 team 的文化轉變
這是「Agentic Engineering 實戰手冊」系列的第十三篇。上一篇：Agent 安全網設計
「你能不能幫全 Team 導入？」——我以為這是好事
我在公司用了六個月 agent coding。自己的任務速度明顯變快，當時追蹤到的 bug rate 也沒有上升。這是我的工作紀錄，不是經過控制的「效率翻倍」實驗，但已經足以讓主管問：「你能不能幫全 team 都導入這套工作流？」
我以為這是好事。以為只要開個 workshop、分享我的 CLAUDE.md、讓大家裝好 Claude Code，就搞定了。
結果第一週，10 個人裡有 3 個完全沒碰。2 個試了一次就放棄（「它改出來的 code 不是我想要的」）。3 個有在用但每次都來問我很基礎的問題。只有 2 個真的上手了。
我原本以為問題在安裝與 prompt，結果真正花時間的是信任、學習方式與團隊流程。
讓一個人用 agent 很簡單，你只需要說服自己。讓十個人都開始用，你得同時處理恐懼、習慣、標準、流程，有時候還有辦公室政治。
為什麼 Adoption 這麼難
阻力和年資沒有固定對照表
| 常見顧慮 | 可能出現在誰身上 | 導入時要回答什麼 |
|---|---|---|
| 基礎能力會不會被掏空 | 新手或正在轉技術棧的人 | 哪些練習保留手作，怎麼檢查自己真的理解 |
| 專業價值被重新定義 | 任何把實作速度視為核心價值的人 | 新流程如何評估判斷、設計與 review |
| 既有系統風險太高 | 熟悉 legacy／production 的工程師 | 權限、資料邊界、回滾與責任歸屬 |
| ROI 與治理不清楚 | Manager、資安、法務與採購 | 怎麼試點、量什麼、何時停 |
注意這些都不是「技術問題」，每一個都是心理層面和身份認同層面的挑戰。
Junior 的焦慮：「如果我都讓 agent 寫，我什麼時候才能自己學會？」這是合理的擔心。你可以這樣回：agent 不是取代你的練習，而是你的 pair programming partner。你寫 test、review code、做設計決策，這些才是真正建立能力的活動。Agent 幫你省掉的是 boilerplate，不是思考。
Mid-level 的焦慮：「我的價值就是寫 code 寫得快寫得好，agent 做得比我快怎麼辦？」這時候可以說：你的價值正在從「寫 code 的速度」轉變為「判斷什麼 code 該寫」。Post 2 聊過這個，在 new skill tree 裡，判斷力 > 打字速度。
資深工程師的顧慮不一定是固執。很多時候，他們只是比其他人更清楚 production 的歷史包袱與失敗成本。這些警告應被納入 pilot 設計，而不是被當成「抗拒改變」。
挑選 Pilot Project 的標準
第一印象決定一切。選錯 pilot project，可能讓導入倒退六個月。
好的 Pilot 特徵
- 需求明確：有清楚的 spec 或 ticket，不需要大量 clarification
- 有測試覆蓋：agent 可以用 test 自我驗證，降低出錯風險
- 成果可量化：能具體比較 before/after（時間、code 品質、bug count）
- 風險低：不是 critical path，搞砸了不會影響 sprint delivery
- 有代表性：是團隊日常會做的任務類型，不是 edge case
推薦的 Pilot 類型
| Pilot 類型 | 為什麼好 |
|---|---|
| 新的 CRUD feature | 需求明確、pattern 成熟、容易比較 |
| Test coverage 補全 | 容易驗收，但要人工確認不是只追 coverage 數字的無效測試 |
| Documentation 更新 | 影響通常較低，但錯誤文件仍會誤導人與 agent，必須由 owner 查核 |
| 小型 refactor | 有 test 保護、scope 有限、容易 demo before/after |
千萬不要選的 Pilot
- Legacy codebase 的大型 migration
- 沒有 test 覆蓋的核心功能
- 跨團隊依賴的複雜 feature
- 需要大量 domain knowledge 的 business logic
核心原則是：pilot 要有代表性、可驗收、可回滾。目標是收集可信證據，不是刻意挑一個只會成功的 demo，也不是展示 agent 的極限能力。
共享 CLAUDE.md 與團隊規範
從個人的 CLAUDE.md 到團隊的 CLAUDE.md，需要一個規範化的過程。
團隊 CLAUDE.md 該有什麼
# Team CLAUDE.md
## 技術棧（必填）
- 框架、語言、主要 dependency
## Build & Test（必填）
- 指令列表
## Coding Conventions（必填）
- 命名規則、檔案結構、設計模式
## Agent 使用規範（團隊新增）
- 哪些操作需要人工確認
- PR 上標注 AI-generated 的規則
- Agent-generated code 的 review 標準PR 標注規範
建議的做法是讓 agent 產生的 PR 在 description 裡加上標注：
## AI Disclosure
- 🤖 This PR was primarily generated by AI agent (Claude Code)
- 👤 Human reviewed: architecture, security, business logic
- ✅ Verification: all existing tests pass + 3 new tests added是否要求 AI disclosure 是團隊治理選擇，不是所有 repo 的通用義務。若採用，目的應是交代產生與驗證流程，而不是降低 reviewer 對人寫 code 的標準；任何 PR 都需要事實、行為與安全檢查。
CLAUDE.md 的版本控制
團隊的 CLAUDE.md 應該跟 code 一樣被 version control：
- 修改需要 PR review
- 重大改動需要 team 討論
- 每個月 review 一次是否需要更新
處理「AI 會取代我嗎」的焦慮
這不是理性問題。你不能用「根據統計，AI 導入後公司裁員率沒有上升」來說服一個害怕失業的人。
Acknowledge → Reframe → Demonstrate
Step 1: Acknowledge（承認恐懼是合理的）
「我理解你的擔心。AI 的確改變了工程師的工作內容。說不擔心是假的。」
不要立刻反駁。讓對方知道你理解他們的感受。
Step 2: Reframe（重新框架問題）
「Agent 不是取代你，是把你從低價值的工作中解放出來。你以前花 60% 的時間在寫 boilerplate、copy-paste、做重複的工作。Agent 做了這些，你可以把時間花在需要判斷力的事，像是架構設計、需求分析、code review。」
Step 3: Demonstrate（用事實示範）
不要只丟一張產業統計，也不要只靠一次 wow demo。讓同事親自跑一個真實任務，再把時間、返工、品質與主觀感受一起記下來。
第一次體驗會影響很大，所以最好找那位同事正在做、痛點明確又可回滾的任務，而不是你精心準備、只會成功的表演。
不同層級的對話策略
對 Junior：「Agent 是你的學習加速器。你寫 test、review code、做設計——這些才是真正的學習。Agent 幫你省掉的是打字時間。」
對 Mid-level：「你最大的價值不是手速，是你知道什麼 code 該寫、什麼不該寫。Agent 放大了這個價值。」
對 Senior：不要硬推。找到他們真正的痛點（通常是 code review 太多、tech debt 清不完），用那個痛點做切入。
衡量指標：導入期該量什麼
不要量的指標
- Code 行數 / commit 數量——agent 很容易產生大量 code，但量 ≠ 質
- 工時節省——前三個月可能不降反升（學習曲線）
建議量的指標
| 指標 | 為什麼重要 | 怎麼量 |
|---|---|---|
| PR review 品質 | 變更是否被真正理解與查核 | review 後返工、漏網缺陷、關鍵風險是否被指出 |
| Bug rate | 品質有沒有下降 | Bug tickets per sprint |
| Dev satisfaction | 團隊對新工作流的感受 | 匿名問卷（每兩週一次） |
| Time-to-deploy | 從 ticket 到 production 的時間 | Jira / GitHub metrics |
| Agent adoption rate | 多少人在自願且有效地使用 | 匿名問卷或經同意的工具統計；先處理隱私與監控政策 |
前三個月可能先看到學習成本，也可能很快在特定任務受益。不要承諾六個月後自然翻倍；期望值應放在「品質與安全不退步，且至少一類常見任務有可重複改善」。
12 週導入計畫
Phase 1（Week 1-4）：個人探索
- 每個人選一個 AI coding 工具（Claude Code / Cursor / Copilot）
- 在自己的 task 上自由使用
- 不設標準、不給壓力
- 每週 15 分鐘 sharing session：分享 tips 和踩過的坑
Success criteria（範例）：至少一半成員完成一個自選試驗，並記錄成功、失敗與未採用原因
Phase 2（Week 5-8）：Pair with Agent
- 每個 sprint 至少一個 task 用 agent 完成
- Agent-generated PR 需要額外的 reviewer tag
- 開始建立共享的 CLAUDE.md
- 兩週一次 retrospective：什麼有用、什麼沒用
Success criteria：團隊共識「agent 在 X 類任務上有幫助」
Phase 3（Week 9-12）：Team Standard
- 正式版 team CLAUDE.md commit 進 repo
- Agent code review 標準定義好
- Metrics dashboard 上線
- 結案 retrospective：go / no-go / adjust
Success criteria（範例）：至少一類常見任務的 lead time 或返工有改善，bug／incident 指標沒有超過事先設定的容忍範圍
Go / No-Go Decision
Phase 3 結束後，用數據做決策：
- Bug rate 上升了？→ 調整 review 流程，回到 Phase 2
- 大家不想用？→ 調查原因，可能是工具選擇問題或 pilot 選錯
- 效率持平但大家有正面感受？→ 先確認是否有學習、品質或滿意度等可持續收益，再決定延長或縮小範圍；不要預設效率之後一定自然提升
把三個 Phase 串起來看會更清楚：這不是一條走到底就結束的時間軸，Go/No-Go 那一步才是真正的關卡。
flowchart TD
P1["Phase 1（Week 1-4）<br/>個人探索"] -->|"至少一半成員完成<br/>自選試驗並記錄成敗"| P2["Phase 2（Week 5-8）<br/>Pair with Agent"]
P2 -->|"團隊共識：agent<br/>在某類任務有幫助"| P3["Phase 3（Week 9-12）<br/>Team Standard"]
P3 -->|"lead time／返工改善<br/>bug 指標未超標"| D{"Go / No-Go<br/>Decision"}
D -->|"Bug rate 上升"| P2
D -->|"大家不想用"| INV["調查原因<br/>工具或 pilot 選錯"]
D -->|"效率持平<br/>但感受正面"| EXT["視情況延長<br/>或縮小範圍"]
畫出來我才真正看清楚：這張圖不是甘特圖，是一個有退路的迴圈。Bug rate 一旦上升，整個計畫不是硬著頭皮往 Phase 3 衝，而是直接被送回 Phase 2 重新磨合——那條往回指的邊，才是這套 12 週計畫真正的安全網。另外兩條分支（沒人想用、效率持平但感受正面）也都不是終點，而是要求你先查清楚原因，再決定要延長還是縮小範圍。
向上管理：怎麼 Pitch 給主管
主管在乎三件事：ROI、Risk、Timeline。
不要說
「AI 會讓我們快 10 倍。」
這種承諾只會反噬。第一個月效率可能不升反降，主管就會質疑你的判斷。
要說
「我提議做一個 12 週的 pilot。目標是在 X 類任務上驗證 agent-assisted workflow 的效果。量化指標是 [PR 品質、bug rate、time-to-deploy]。如果 12 週後指標沒改善，我們 rollback，成本可控。」
重點就是低風險 + 可量化 + 有退場機制。
Shopify 的參考案例
Shopify CEO Tobi Lütke 在 2025 年 4 月公開一封內部 memo，其中一條要求是：
在要求增加人力之前，先證明 AI 做不到這件事。
這是 Shopify 的政策選擇，不能直接解讀成所有團隊都該「先證明 AI 不行才准招人」。它值得討論的部分，是資源規劃應把 AI 能力與限制一起納入；同時也要防止團隊為了符合政策，隱藏品質、工時與心理安全成本。
Takeaway
-
團隊導入同時是人、流程與技術問題：先理解個別顧慮，再用真實任務、數據與使用者感受一起判斷，不靠一次 demo 下結論。
-
好的 pilot 要有代表性、可驗收、可回滾：避開一開始就押上核心 migration，也別挑只有文件補字這種無法代表日常工作的安全題。
-
分階段 rollout 的價值在可調整：12 週只是範例，不是標準答案。每一階段先定 success criteria、資料蒐集方式與 go／no-go，再依團隊規模與風險調整長度。
上一篇：Agent 安全網設計 下一篇：Agentic Engineering 的下一步
