把 Agentic Engineering 帶進團隊：從一個人的實驗到整個 team 的文化轉變
這是「Agentic Engineering 實戰手冊」系列的第十三篇。上一篇：Agent 安全網設計
「你能不能幫全 Team 導入？」——我以為這是好事
我在公司用了六個月 agent coding，效率翻倍，bug rate 沒有上升。主管注意到了，問我：「你能不能幫全 team 都導入這套工作流？」
我以為這是好事。以為只要開個 workshop、分享我的 CLAUDE.md、讓大家裝好 Claude Code，就搞定了。
結果第一週，10 個人裡有 3 個完全沒碰。2 個試了一次就放棄（「它改出來的 code 不是我想要的」）。3 個有在用但每次都來問我很基礎的問題。只有 2 個真的上手了。
技術從來不是問題，人才是。
讓一個人用 agent 很簡單，你只需要說服自己。讓十個人都開始用，你得同時處理恐懼、習慣、標準、流程，有時候還有辦公室政治。
為什麼 Adoption 這麼難
不同角色的阻力來源
| 角色 | 最擔心什麼 | 表面行為 |
|---|---|---|
| Junior | 「我還沒學會基礎，agent 就要取代我了」 | 不敢用，怕被發現自己不懂 |
| Mid-level | 「我的 coding 速度是我的價值」 | 用了但不信任，手動 rewrite agent 的 code |
| Senior | 「我十年的經驗能被 AI 複製？」 | 聲稱不需要，或找到一個 agent 失敗的案例後拒絕 |
| Manager | 「怎麼衡量？會不會引入新風險？」 | 口頭支持但不給時間和預算 |
注意這些都不是「技術問題」，每一個都是心理層面和身份認同層面的挑戰。
Junior 的焦慮：「如果我都讓 agent 寫，我什麼時候才能自己學會？」這是合理的擔心。你可以這樣回：agent 不是取代你的練習，而是你的 pair programming partner。你寫 test、review code、做設計決策，這些才是真正建立能力的活動。Agent 幫你省掉的是 boilerplate，不是思考。
Mid-level 的焦慮：「我的價值就是寫 code 寫得快寫得好，agent 做得比我快怎麼辦？」這時候可以說：你的價值正在從「寫 code 的速度」轉變為「判斷什麼 code 該寫」。Post 2 聊過這個，在 new skill tree 裡，判斷力 > 打字速度。
Senior 的焦慮：「我的 expertise 會過時嗎？」這反而是最不需要擔心的群體，senior 的 judgment、architecture sense、domain knowledge 恰恰是 agent 最缺乏的。但 senior 通常也最固執。
挑選 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 %）、agent 非常擅長 |
| Documentation 更新 | 零風險、立竿見影、所有人都討厭手動寫文件 |
| 小型 refactor | 有 test 保護、scope 有限、容易 demo before/after |
千萬不要選的 Pilot
- Legacy codebase 的大型 migration
- 沒有 test 覆蓋的核心功能
- 跨團隊依賴的複雜 feature
- 需要大量 domain knowledge 的 business logic
核心原則是這樣：pilot 的目標是讓團隊對 agent 建立信心，不是展示 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這不是「揭發」，而是透明度。讓 reviewer 知道這個 PR 需要 特別注意的 review 重點（事實性檢查、hallucination patterns）。
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（用事實示範）
不要用數據說服，用體驗說服。讓同事親自體驗一次「10 分鐘寫 spec → agent 自動完成」的流程。
第一次體驗的 wow moment 比任何論據都有效。但前提是你要選對 demo task，找一個那位同事正在做的、痛點明確的任務來 demo，不是你精心準備的表演。
不同層級的對話策略
對 Junior：「Agent 是你的學習加速器。你寫 test、review code、做設計——這些才是真正的學習。Agent 幫你省掉的是打字時間。」
對 Mid-level：「你最大的價值不是手速，是你知道什麼 code 該寫、什麼不該寫。Agent 放大了這個價值。」
對 Senior：不要硬推。找到他們真正的痛點（通常是 code review 太多、tech debt 清不完），用那個痛點做切入。
衡量指標：導入期該量什麼
不要量的指標
- Code 行數 / commit 數量——agent 很容易產生大量 code，但量 ≠ 質
- 工時節省——前三個月可能不降反升（學習曲線）
建議量的指標
| 指標 | 為什麼重要 | 怎麼量 |
|---|---|---|
| PR review 品質 | Agent code 是否被 review 過 | PR 有沒有 AI disclosure 標注 |
| Bug rate | 品質有沒有下降 | Bug tickets per sprint |
| Dev satisfaction | 團隊對新工作流的感受 | 匿名問卷（每兩週一次） |
| Time-to-deploy | 從 ticket 到 production 的時間 | Jira / GitHub metrics |
| Agent adoption rate | 多少人在用 | 工具使用 analytics |
前三個月不要期待效率提升，學習曲線是真的。期望值應該擺在「品質沒下降 + 大家開始養成習慣」，而不是「效率翻倍」。效率翻倍是六個月後的事。
12 週導入計畫
Phase 1（Week 1-4）：個人探索
- 每個人選一個 AI coding 工具（Claude Code / Cursor / Copilot）
- 在自己的 task 上自由使用
- 不設標準、不給壓力
- 每週 15 分鐘 sharing session：分享 tips 和踩過的坑
Success criteria：50% 的團隊成員每週至少用了一次 agent
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：80% 的成員在日常工作中使用 agent，bug rate 沒有上升
Go / No-Go Decision
Phase 3 結束後，用數據做決策：
- Bug rate 上升了？→ 調整 review 流程，回到 Phase 2
- 大家不想用？→ 調查原因，可能是工具選擇問題或 pilot 選錯
- 效率持平但大家有正面感受？→ Go，效率會在接下來幾個月自然提升
向上管理：怎麼 Pitch 給主管
主管在乎三件事：ROI、Risk、Timeline。
不要說
「AI 會讓我們快 10 倍。」
這種承諾只會反噬。第一個月效率可能不升反降，主管就會質疑你的判斷。
要說
「我提議做一個 12 週的 pilot。目標是在 X 類任務上驗證 agent-assisted workflow 的效果。量化指標是 [PR 品質、bug rate、time-to-deploy]。如果 12 週後指標沒改善，我們 rollback，成本可控。」
重點就是低風險 + 可量化 + 有退場機制。
Shopify 的參考案例
Shopify CEO Tobi Lutke 在 2025 年要求團隊的一個原則值得學習：
在要求增加人力之前，先證明 AI 做不到這件事。
這不是要「用 AI 取代人」，而是把 AI 視為團隊能力的一部分。就像你不會在提案新 feature 的時候忽略 CI/CD pipeline 的效率一樣，你也不該在規劃 capacity 的時候忽略 AI agent 的能力。
Takeaway
-
團隊導入的最大挑戰是人，不是技術：不同角色有不同的恐懼和阻力。先 acknowledge 恐懼，再用體驗（不是數據）說服。一次好的 demo 勝過十頁 slide。
-
好的 pilot project 決定第一印象：選需求明確、有 test 覆蓋、低風險的任務。千萬不要用 legacy migration 當 demo，那是讓整個團隊對 agent 失去信心的最快方式。
-
12 週 phased rollout 比「下週一所有人開始用」有效 100 倍：Phase 1 個人探索、Phase 2 pair with agent、Phase 3 team standard。每個 phase 有明確的 success criteria 和 go/no-go 決策點。
上一篇：Agent 安全網設計 下一篇：Agentic Engineering 的下一步
