突然想通了一些事情。

有的時候，我們真正想要的到底是速度，還是打磨？

很多事情都是需要被打磨之後，才能夠量產的。

但在現在 AI 的世界中，大家都在追求速度，那誰來思考呢？

我覺得這其實是一個很有趣、也很需要自行體會的過程。

前幾天我的文章有提到一句話：你就應該當總經理。

因為 AI 是你的員工。

但問題是——到底有多少人真的想過，總經理要做什麼事？

總經理可以無腦可以當的嗎？

你真的準備好了嗎？

⸻

我們一直在幫別人思考

當我真正開始思考這個問題之後，才發現一件事：

原來我們一直在「幫別人思考」。

我們耳提面命小孩，要注意什麼，要學習，要有態度、要成為一個有成就的人，

但他們，為什麼要成為有成就的人，甚至 是要成為你期望中的成就的人？

其實很多時候，那只是我們自己的期待投射在他們身上。

而他們並沒有真正思考過，也沒有自已打磨過。

這種「打磨」本身是一種經驗的累積，

它是需要時間的。

如果沒有經過那個過程，他們其實是不會知道的。

⸻

管理 AI，其實是在學管理自己

最近透過 AI，我看到了團隊運作的更多可能性。

我也開始試著要求我的同事們，思維上要成為主管、成為有管理能力的人。

但就跟剛剛的問題一樣，準備好了嗎？

因為接下來，他們要開始管理的，其實是他們的 AI。

以前他們做的是單一職能的工作，

任務上依然有專業性與廣度，

但在整個合作鏈條的終點來看，

他們是在處理「單一交付」的事情。

他們對自己的時間負責，

而我對他們的產出、對整個團隊負責。

⸻

有沒有想過「共同目標」？

主管可能任務、目標、願景丟給他們，

希望他們能在有限的時間裡，把時間花在真正有價值的事情上。

但問題是——

他們有沒有想過我們的團隊共同的目標是什麼？

不一定。

這其實要看主管自己有沒有這樣的想法，有沒有真正去思考過這件事。

而這件事情，一樣會回到他們自己身上。

他們必須去思考：

自己到底能不能承擔這樣的責任？

⸻

從小孩、部門主管，到總經理

從小孩是這樣，

你的部屬是這樣，

那當你突然把自己放到「總經理」的位置時，也是如此。

當你從一個一般員工，一下子跳到總經理，

一下子你馬上就會體驗這個位置到底要做什麼？也有可能完全沒想法。

⸻

打磨，是不可跳過的過程

不論是從部屬走到管理部門，

擁有團隊的能量，

做出更好的產品，

或是負責更大的市場——

這些都需要時間。

小孩也是。

他們慢慢學習，成為一個在社會上有價值、有產出、能負責任的人，

這整個過程，本來就需要被打磨。

而在現在這個時代，

這個「打磨」，反而變得更重要。

⸻

我們真的想要無腦嗎？

我想多記錄這段思考的變化。

我們常常說把事情丟別人做就好了，

這樣丟出去做出來的事情，

真的有價值嗎？

如果一件事只是為了交代、為了應付，

你甚至不願意花比錢還貴的”時間”去打磨它，

那它是不是其實可以不用做？

因為時間本身，就是最貴的東西。

每個人都平等地擁有它，

而它最貴的地方，也正在這裡。

⸻

思考先記錄到這裡(語音記錄整理)。

謝謝。

當 AI 能寫代碼，團隊組織方式必須重新設計

---

1. 問題定義：傳統團隊組織在 AI 時代的困境

1.1 固定職位 vs 動態需求的矛盾

傳統的團隊組建方式：

1. 寫 JD (Job Description)
2. 招聘符合條件的人
3. 人到職後開始工作
4. 這個人從頭做到尾

假設：職位固定，需求穩定

現實：

• 專案初期需要快速建 prototype → 需要「會快速驗證想法」的能力
• 專案中期需要穩定架構 → 需要「擅長系統設計」的能力
• 專案後期需要優化效能 → 需要完全不同的專長

問題：同一個「Senior React Developer」無法在所有階段都是最適合的

1.2 AI 工具帶來的新挑戰

當 Claude Code、GitHub Copilot、Cursor 可以寫代碼時：

• 工程師的價值不再是「會寫代碼」
• 團隊需要的不是「會 React 的人」，而是「能調度 AI+人 來完成 Frontend 任務的角色」
• 資源配置從「招聘」變成「設計角色組合」

核心困境：

我們還在用工業時代的「固定職位」邏輯，組織 AI 時代的「動態資源」團隊

1.3 現有方案的不足

方案 A：增加人力

❌ 成本高（年薪 x N 人）
❌ 招聘慢（平均 2-3 個月）
❌ 不靈活（人到職後很難調整）

方案 B：外包

❌ 溝通成本高
❌ 品質難控管
❌ 知識無法留存

方案 C：全端工程師

⚠️ 要求過高（前端+後端+DevOps）
⚠️ 難招聘（薪資成本高）
⚠️ 效率未必最佳（什麼都會 ≠ 什麼都專精）

缺少的是什麼？
→ 一套能讓「人」與「AI」協作，且可版本控制、可模組化、可重用的團隊設計方法

---

2. 方案說明：團隊設計模式演進（v0 → v3）

2.1 設計思維轉變

從「找人」到「設計角色」：

傳統思維：我需要一個會 React 的人

新思維：Frontend 角色需要哪些能力模組？
  → UI 組件開發：AI 可以做 80%
  → 狀態管理設計：需要人來思考
  → 效能優化：人+AI 協作效果最好
  → Code Review：AI 先篩，人做最終把關

最終配置：
  1 個懂架構的人（負責設計與決策）
  + 2 個 AI coding agents（負責實作）
  + 1 個 AI review agent（負責品質把關）

關鍵洞察：

團隊設計就是軟體架構設計，只是運算單元從「函式」變成了「人或 AI」

---

2.2 v0: Single Human Dev（過去）

架構：

you/
├── brain/
│   ├── frontend-knowledge
│   ├── backend-knowledge
│   └── devops-knowledge
└── project/
    └── src/

特性：

• 所有技能都在腦袋裡
• 沒有外部配置
• 一個人，一個專案

適用場景：

• 個人 side project
• 早期 prototype
• 單人創業初期

優點：
✅ 自由、快速
✅ 沒有溝通成本
✅ 決策速度快

痛點：
❌ 無法規模化（你只有一個人）
❌ 知識無法傳承（離職就帶走了）
❌ 容易重複造輪子（每個專案都重新設計）
❌ 生病或休假時專案停擺

---

2.3 v1: Mono Repo（入門）

架構：

my-project/
├── src/
├── tests/
└── .claude/
    ├── agents/
    │   ├── frontend-dev.md
    │   └── backend-dev.md
    └── skills/
        ├── react-expert/
        └── api-design/

特性：

• AI 配置與專案程式碼在一起
• agents 和 skills 都在 .claude/ 目錄
• 用 markdown 定義 agent 職責

適用場景：

• 小團隊（< 5人）
• 單一專案
• 初次嘗試 AI 協作

優點：
✅ 簡單直接
✅ AI 配置與程式碼一起，容易管理
✅ 適合快速啟動

痛點：
❌ 專案變大後難以管理
❌ .claude/ 的配置無法在其他專案重用
❌ 多人協作時容易衝突（都改同一個 agent.md）
❌ 每個新專案都要重新配置

技術實作：

# .claude/agents/frontend-dev.md

## Responsibilities
- 實作 React 組件
- 狀態管理設計
- API 串接

## Skills
- react-expert
- api-design

## Workflow
1. 收到 UI 需求
2. 設計組件結構
3. 實作並測試
4. 提交 PR

---

2.4 v2: Sub-module（進階）

架構：

my-project/
├── src/
├── tests/
└── ai-plugins/  ← git submodule
    └── .claude/
        ├── agents/
        └── skills/

特性：

• 將 AI 配置作為 git submodule 引入
• 多個專案可以共用同一個 submodule
• 可以版本控制 AI 配置

適用場景：

• 中型團隊
• 需要跨專案重用 AI 配置
• 有專人維護 AI 配置

優點：
✅ AI 配置可重用（多個專案共用）
✅ 可以版本控制（更新 submodule 版本）
✅ 統一管理（一個地方更新，所有專案受益）

痛點：
❌ git submodule 管理複雜

• git submodule update --init
• git submodule sync
• 容易忘記 init
  ❌ submodule 更新需要手動 commit
  ❌ 新人容易踩坑（為什麼 .claude/ 是空的？）
  ❌ CI/CD 需要特別處理 submodule

技術實作：

# 1. 建立共用的 AI 配置 repo
git init ai-plugins

# 2. 在專案中加入 submodule
cd my-project
git submodule add https://github.com/company/ai-plugins.git

# 3. 更新 AI 配置
cd ai-plugins
git pull origin main
cd ..
git add ai-plugins
git commit -m "chore: update AI plugins"

# 4. 新人 clone 後需要
git clone --recurse-submodules <project-url>
# 或
git submodule update --init --recursive

常見問題：

問題	原因	解法
.claude/ 是空的	沒有 init submodule	git submodule update --init
submodule 版本不對	沒有更新 submodule	git submodule update --remote
CI 找不到 agents	CI 沒設定 submodule	加入 submodules: true

---

2.5 v3: Solutions (Multi-Repo)（推薦）

架構：

Solutions/
├── ProjectA/ (Web Frontend)
│   └── .claude/ (project-specific)
│       ├── agents/
│       └── skills/ (部分從 AIPlugins 複製)
│
├── ProjectB/ (API Backend)
│   └── .claude/ (project-specific)
│
├── ProjectC/ (Data Service)
│   └── .claude/ (project-specific)
│
└── AIPlugins/ (Shared Templates)
    ├── Templates/
    │   ├── .skills/
    │   │   ├── frontend-expert/
    │   │   ├── backend-expert/
    │   │   ├── process-manager/
    │   │   └── learning-agent/
    │   └── .teams/
    │       ├── dev-team/
    │       ├── qa-team/
    │       └── devops-team/
    │
    └── install.sh (安裝腳本)

特性：

• 每個專案有獨立的 .claude/
• AIPlugins 作為模板庫，不是 submodule
• 用安裝腳本將模板複製到專案

適用場景：

• 中大型團隊
• 多專案並行
• 需要標準化流程
• 專案間配置需要獨立演進

優點：
✅ 模組化：每個專案獨立，不互相影響
✅ 可重用：共用 templates，新專案快速啟動
✅ 版本控制：AI 配置也進 git，可追蹤演進
✅ 彈性：專案可以選擇性使用部分 templates
✅ 獨立更新：AIPlugins 更新，專案可以選擇是否同步
✅ 沒有 submodule 問題：複製過來就是專案的一部分

安裝方式：

cd ProjectA
../AIPlugins/install.sh --team=dev-team

# 自動將 template 複製到 ProjectA/.claude/
# 複製後可以自由修改，不影響其他專案

AIPlugins 的模組化設計：

Templates/
├── .skills/ (專業能力模組)
│   ├── frontend-expert/     ← React, Vue, Angular 專家
│   ├── backend-expert/      ← Node.js, .NET, Python 專家
│   ├── sre/                 ← 網站可靠性工程
│   └── dba/                 ← 資料庫管理
│
├── .teams/ (完整團隊模板)
│   ├── dev-team/            ← 開發團隊（含 agents + skills）
│   ├── qa-team/             ← 測試團隊
│   └── devops-team/         ← 維運團隊
│
└── .rules/ (規則與標準)
    ├── coding-style.md      ← 編碼規範
    ├── git-workflow.md      ← Git 流程
    └── testing.md           ← 測試標準

install.sh 原理：

#!/bin/bash
TEAM=$1
PROJECT_ROOT=$2

# 複製 team template
cp -r Templates/.teams/$TEAM/* $PROJECT_ROOT/.claude/

# 可選：複製共用 skills
cp -r Templates/.skills/common/* $PROJECT_ROOT/.claude/skills/

# 可選：複製 rules
cp -r Templates/.rules/* $PROJECT_ROOT/.claude/rules/

echo "✅ Installed $TEAM to $PROJECT_ROOT"

---

2.6 版本比較總表

特性	v0	v1	v2	v3
規模化	❌	⚠️	✅	✅
可重用	❌	❌	✅	✅
獨立演進	✅	✅	❌	✅
管理複雜度	簡單	簡單	複雜	中等
新人友善度	N/A	✅	❌	✅
適合團隊規模	1人	2-5人	5-20人	10人以上
適合專案數	1	1-2	3+	5+

---

2.7 從 v1 升級到 v3 的遷移路徑

Step 1: 建立 AIPlugins repo
  → 將現有的 .claude/ 提煉成 templates

Step 2: 寫安裝腳本
  → 支援選擇性安裝 team/skills

Step 3: 在新專案試驗
  → 驗證 template 是否通用

Step 4: 逐步遷移舊專案
  → 舊專案可以繼續用 v1，新專案用 v3

Step 5: 持續優化 templates
  → 根據實際使用反饋調整

注意事項：

• 不需要一次全部遷移
• v1 和 v3 可以共存
• 優先在新專案採用 v3

---

3. 驗證論述：為什麼這樣設計是合理的

本章節透過架構設計原理、邏輯推演、業界類比來驗證方案的有效性

---

3.1 架構設計原理

核心設計原則

這套演進路徑（v0 → v1 → v2 → v3）背後的設計原則：

1. 關注點分離 (Separation of Concerns)

v1: 程式碼 + AI 配置混在一起
  → 優點：簡單
  → 缺點：耦合度高

v3: 程式碼 vs AI Templates 分離
  → 優點：各自演進
  → 缺點：需要安裝腳本串接

軟體工程的經典原則：高內聚、低耦合。v3 將「團隊能力模板」與「專案程式碼」分離，符合這個原則。

2. DRY 原則 (Don’t Repeat Yourself)

v1: 每個專案重複配置 .claude/
  → 10 個專案 = 10 次配置
  → 改進一個配置需要手動同步 10 次

v3: 共用 AIPlugins templates
  → 10 個專案使用同一套 templates
  → 改進一次，所有專案受益

這就像程式碼中的「抽離共用函式」，而不是複製貼上。

3. 組合優於繼承 (Composition over Inheritance)

v2: 用 git submodule「繼承」AI 配置
  → 所有專案綁定同一個版本
  → 無法客製化

v3: 用「複製 + 組合」的方式
  → 專案可以選擇性使用部分 templates
  → 專案可以客製化後再組合

v3 讓每個專案保有彈性，不會被 submodule 綁死。

與軟體工程的類比

軟體工程概念	團隊設計類比
函式庫 (Library)	AIPlugins Templates
npm install	install.sh --team=dev-team
node_modules/	.claude/ (安裝後)
package.json	記錄使用了哪些 templates
升級套件	重新執行 install.sh
fork & modify	複製後客製化

v3 的設計思想就像 npm 生態系：

• 有一個「套件庫」（AIPlugins）
• 專案可以「安裝」需要的套件
• 安裝後可以「客製化」
• 套件庫可以「獨立演進」

---

3.2 邏輯推演：為什麼 v3 優於 v1/v2

推演 1：規模化時的成本曲線

假設一個團隊有 N 個專案：

v1 的成本：

• 初始配置成本：N × T （每個專案都要配置一次）
• 維護成本：N × M （每個專案都要獨立維護）
• 改進同步成本：N × S （改進要手動同步）

v3 的成本：

• 初始設置成本：T_setup （建立 AIPlugins，一次性）
• 專案配置成本：N × t （執行 install.sh，t << T）
• 維護成本：M_central （集中維護 templates）
• 改進同步成本：0 （專案自行決定是否同步）

交叉點分析：

當 N = 1-2 時：
  v1 成本 < v3 成本（v3 的初始設置成本 T_setup 太高）

當 N ≥ 3 時：
  v3 成本開始低於 v1
  隨著 N 增加，差距越來越大

結論：專案數量越多，v3 的優勢越明顯。

---

推演 2：團隊成長的適應性

情境：團隊從 5 人成長到 20 人

v1 的困境：

1. 每個新人都要重新學習每個專案的配置方式
2. 配置不一致導致協作困難
3. 新人貢獻的改進難以擴散到其他專案

v3 的優勢：

1. 新人只需學習一套標準 templates
2. 所有專案遵循同樣的配置邏輯
3. 改進可以提煉回 AIPlugins，所有專案受益

邏輯：

當團隊規模 ↑ 時，標準化 ↑ 的重要性也 ↑

v3 提供了「標準化」但不失「彈性」的平衡點。

---

推演 3：配置演進的速度

情境：AI 工具快速迭代（如 Claude Code 每月更新）

v1 的問題：

• 10 個專案 = 10 次手動更新
• 容易遺漏某些專案
• 更新策略不一致

v3 的優勢：

• AIPlugins 統一更新
• 專案可以選擇「立即同步」或「延後同步」
• 降低更新風險（先在 AIPlugins 測試，再推廣）

邏輯：

工具迭代速度 ↑ → 集中管理配置的價值 ↑

---

3.3 業界類比驗證

這套演進路徑並非憑空想像，而是參考業界成熟的模式：

類比 1：Monorepo vs Multi-Repo

模式	特性	對應版本
Monorepo	所有程式碼在一個 repo	v1 (Mono Repo)
Multi-Repo + Shared Library	程式碼分離 + 共用函式庫	v3 (Multi-Repo + AIPlugins)

業界趨勢：

• Google 用 Monorepo（適合超大團隊）
• Netflix 用 Multi-Repo（適合中大型團隊）
• v3 參考的是 Netflix 模式

類比 2：Infrastructure as Code

傳統方式	IaC 方式	對應版本
手動配置伺服器	Terraform / Ansible	v0 → v3
每台機器獨立配置	用模板批次部署	v1 → v3

v3 的 AIPlugins 就像 Terraform 的 modules：

• 定義可重用的基礎設施模板
• 不同專案使用不同組合
• 集中維護、分散使用

類比 3：Design System

設計系統概念	團隊設計類比
Component Library	AIPlugins Templates
Figma Shared Library	.claude/skills/
Design Tokens	.claude/rules/
專案使用 Library	install.sh

v3 把「團隊設計」當成「Design System」來管理，這是成熟組織的標準做法。

---

3.4 適用場景與限制分析（邏輯推論）

適用場景推論

基於架構設計原理，我們可以推論出各版本的適用場景：

推論邏輯：

• 當「重用價值」> 「管理成本」時，選 v3
• 當「專案數量」< 3 時，重用價值低，選 v1
• 當「團隊規模」> 10 時，標準化價值高，選 v3

推論結果：

場景	推薦版本	推論依據
個人 side project	v0 或 v1	無重用需求，簡單優先
新創公司（< 10人）	v1	專案數量少，快速啟動優先
成長期公司（10-50人）	v3	專案開始增加，標準化開始有價值
大型組織（> 50人）	v3	多專案並行，必須標準化
外包團隊	v1	專案獨立，客戶不同，難以重用
諮詢公司	v3	多客戶、多專案，templates 可重用
產品公司	v3	多產品線，統一團隊設計思維

限制分析（邏輯推論）

v3 的前置條件：

❌ 團隊太小（< 5人）

• 推論：5人以下的團隊，專案數量通常 < 3
• 結論：v3 的管理成本 > 收益
• 建議：用 v1 直到團隊擴大或專案增加

❌ 專案只有 1-2 個

• 推論：重用價值 = 專案數量 – 1
• 結論：1-2 個專案的重用價值接近 0
• 建議：用 v1，等專案數量 ≥ 3 再考慮 v3

❌ 沒有專人維護 AIPlugins

• 推論：templates 會過時 → 各專案自行修改 → 失去一致性
• 結論：v3 退化成 v1
• 建議：指定 Tech Lead 或 Architect 負責維護

❌ 團隊不熟悉 AI 協作

• 推論：連 v1 都不會用，直接跳 v3 會更困難
• 結論：學習曲線過陡
• 建議：先在 1-2 個專案試驗 v1，累積經驗後再升級

v3 的成功條件：

✅ 專案數量 ≥ 3
✅ 團隊規模 ≥ 10 人
✅ 有專人負責維護 AIPlugins（至少 20% 工作時間）
✅ 團隊已熟悉 AI 協作基本概念

決策公式（簡化）：

if (專案數量 >= 3 && 團隊規模 >= 10 && 有維護人力) {
  推薦 v3
} else if (專案數量 >= 2 || 團隊規模 >= 5) {
  可考慮 v3（但要評估維護成本）
} else {
  推薦 v1
}

---

3.5 理論驗證總結

透過以上的架構設計原理、邏輯推演、業界類比，我們可以得出：

v0 → v1 → v2 → v3 的演進是合理的，因為：

1. 符合軟體工程的經典原則

• 關注點分離、DRY、組合優於繼承

1. 成本曲線邏輯成立

• 專案數量越多，v3 的優勢越明顯

1. 業界有成功先例

• Multi-Repo + Shared Library（Netflix）
• Infrastructure as Code（Terraform）
• Design System（Figma）

1. 適用場景邏輯自洽

• 前置條件明確（專案數、團隊規模、維護人力）
• 決策邏輯可驗證

未來可驗證的點：

雖然本文基於理論分析與邏輯推演，但以下指標可在實際採用後驗證：

• [ ] 新專案啟動時間（v1 vs v3）
• [ ] 配置維護成本（人時/月）
• [ ] 團隊滿意度（問卷調查）
• [ ] 配置一致性（稽核通過率）
• [ ] 改進擴散速度（新 template 被採用的時間）

邀請讀者參與驗證：

如果你在團隊中實踐了這套方法，歡迎分享你的數據與經驗，讓這套理論得到實證支持

---

4. 應用指南

4.1 如何選擇適合的版本

決策樹

Q1: 你的團隊有幾個人？
├─ 1 人 → v0 或 v1
├─ 2-5 人 → v1
├─ 5-20 人 → v1 或 v3
└─ 20 人以上 → v3

Q2: 你有幾個專案？
├─ 1-2 個 → v1
├─ 3-5 個 → v1 或 v3
└─ 5 個以上 → v3

Q3: 你需要跨專案重用配置嗎？
├─ 不需要 → v1
└─ 需要 → v3

Q4: 你有專人維護 AI 配置嗎？
├─ 沒有 → v1
└─ 有 → v3

最終建議：
- 如果 Q2 ≥ 3 且 Q3 = 需要 → 強烈建議 v3
- 否則 → v1 即可

---

4.2 從 v1 升級到 v3 的步驟

Phase 1：建立 AIPlugins 基礎（Week 1）

# 1. 建立 AIPlugins repo
mkdir AIPlugins
cd AIPlugins
git init

# 2. 建立目錄結構
mkdir -p Templates/.skills
mkdir -p Templates/.teams
mkdir -p Templates/.rules

# 3. 將現有專案的 .claude/ 提煉成 template
# (選擇最成熟的專案作為基礎)
cp -r ../BestProject/.claude/* Templates/.teams/dev-team/

# 4. Commit 初版
git add .
git commit -m "feat: initial AIPlugins templates"

Phase 2：撰寫安裝腳本（Week 1）

# install.sh
#!/bin/bash

set -e

TEAM_NAME=$1
PROJECT_ROOT=${2:-.}

if [ -z "$TEAM_NAME" ]; then
  echo "Usage: ./install.sh <team-name> [project-root]"
  echo "Available teams:"
  ls -1 Templates/.teams/
  exit 1
fi

TEAM_PATH="Templates/.teams/$TEAM_NAME"

if [ ! -d "$TEAM_PATH" ]; then
  echo "Error: Team '$TEAM_NAME' not found"
  exit 1
fi

echo "Installing team: $TEAM_NAME to $PROJECT_ROOT/.claude/"

# 建立目錄
mkdir -p "$PROJECT_ROOT/.claude"

# 複製 team template
cp -r "$TEAM_PATH"/* "$PROJECT_ROOT/.claude/"

# 複製共用 skills (optional)
if [ -d "Templates/.skills/common" ]; then
  mkdir -p "$PROJECT_ROOT/.claude/skills"
  cp -r Templates/.skills/common/* "$PROJECT_ROOT/.claude/skills/"
fi

# 複製 rules (optional)
if [ -d "Templates/.rules" ]; then
  mkdir -p "$PROJECT_ROOT/.claude/rules"
  cp -r Templates/.rules/* "$PROJECT_ROOT/.claude/rules/"
fi

echo "✅ Installation completed!"
echo "📝 You can now customize .claude/ for this project"

Phase 3：在新專案試驗（Week 2）

# 1. 建立測試專案
mkdir TestProject
cd TestProject
git init

# 2. 安裝 dev-team
../AIPlugins/install.sh dev-team

# 3. 驗證
ls -la .claude/
# 應該看到：
# .claude/agents/
# .claude/skills/
# .claude/rules/

# 4. 測試 Claude Code 是否能正確讀取
# (啟動 Claude Code 並測試 agent 功能)

# 5. 記錄問題與改進

Phase 4：優化 Templates（Week 3）

根據試驗結果，優化 templates：

• 移除不必要的 agents
• 補充缺少的 skills
• 更新 rules 描述
• 改進安裝腳本

Phase 5：逐步遷移舊專案（Week 4+）

策略：不需要一次全部遷移

優先順序：
1. 新專案：直接用 v3
2. 活躍專案：有維護需求時遷移
3. 穩定專案：不急著遷移，等有需求再說
4. 遺留專案：保持 v1 即可

遷移檢查清單：

• [ ] 備份原有的 .claude/ 配置
• [ ] 執行 install.sh 安裝 team
• [ ] 對比新舊配置，確認沒有遺漏
• [ ] 測試 Claude Code 功能正常
• [ ] 更新文檔說明新的配置方式
• [ ] Commit 並推送

---

4.3 常見坑與注意事項

坑 1：Template 過時

現象：
AIPlugins 的 template 很久沒更新，新專案用的還是舊的配置

原因：
沒有專人維護 AIPlugins

解法：

• 指定專人（Tech Lead 或 Architect）負責維護
• 每季度 review 一次 templates
• 鼓勵團隊貢獻改進

坑 2：專案配置偏離標準

現象：
每個專案安裝後都自己改，最後又變得不一致

原因：
沒有規範哪些可以改，哪些應該保持一致

解法：

• 在 template 中標註 [CUSTOMIZABLE] 和 [STANDARD]
• 建立 Code Review 檢查機制
• 定期 audit 專案配置

坑 3：安裝腳本覆蓋客製化

現象：
重新執行 install.sh 會覆蓋專案的客製化配置

原因：
安裝腳本是強制覆蓋

解法：

• 安裝腳本加入 --force 參數（預設不覆蓋）
• 或改用 update.sh 只更新特定部分
• 用 git diff 檢查變更

坑 4：忘記提煉改進回 AIPlugins

現象：
專案中發現好的配置改進，但沒有回饋到 AIPlugins

原因：
沒有建立反饋機制

解法：

• 在 Sprint Retrospective 討論 AI 配置改進
• 建立 PR 流程讓團隊貢獻回 AIPlugins
• 定期 review 各專案的客製化，提煉共通部分

---

4.4 進階：梯隊化團隊設計

當專案複雜度提升，可以用「梯隊」來組織團隊：

梯隊 A（核心開發）：
  👤 Senior Dev + 🤖 Claude (Coding)
  👤 Tech Lead + 🤖 Claude (Review)

梯隊 B（測試品質）：
  🤖 Test Agent (Unit Test)
  🤖 QA Agent (Integration Test)
  👤 QA Lead (Final Approval)

梯隊 C（文檔維運）：
  🤖 Doc Agent (Auto-gen Docs)
  🤖 DevOps Agent (CI/CD)
  👤 Ops (Monitoring)

特性：

• 可動態生成：專案初期只啟動梯隊 A
• 可局部抽換：梯隊 B 的 AI 可升級到新模型
• 可版本控制：整個梯隊配置存在 .teams/

技術實作：
使用 Claude Code 的 TeamCreate、TaskCreate、SendMessage 工具來協調不同梯隊的工作

---

4.5 進階：文件設計（索引而非翻譯）

核心概念：

文件不是用來「翻譯程式碼」，而是用來「索引架構」

傳統文件的問題

// 程式碼
function calculateUserAge(birthDate) {
  return new Date().getFullYear() - birthDate.getFullYear();
}

// 文件（無腦翻譯）
/**
 * 計算使用者年齡
 * @param {Date} birthDate - 出生日期
 * @returns {number} 年齡
 */

這種文件只是翻譯，沒有增加任何資訊。

索引文件的做法

# 系統架構索引

## 核心流程
使用者註冊流程：
`UserController.register()` → `UserService.createUser()` → `UserRepository.save()`

檔案位置：
- Controller: `src/api/controllers/UserController.ts`
- Service: `src/services/UserService.ts`
- Repository: `src/data/UserRepository.ts`

## 關鍵決策點
- Email 驗證在哪裡？ → `UserService.validateEmail()` Line 45
- 密碼加密用什麼？ → `bcrypt`，設定在 `src/config/security.ts`
- 錯誤處理策略？ → 統一在 `middleware/errorHandler.ts`

差異：

• ❌ 抽象文件：告訴你「這是什麼」
• ✅ 索引文件：告訴你「在哪裡」

實踐建議

何時該寫文件：

• ✅ 寫索引：列出檔案路徑、關鍵決策點、資料流向
• ✅ 寫地圖：畫出模組關係、呼叫鏈、依賴圖
• ❌ 別寫翻譯：不要把程式碼翻譯成中文註解
• ❌ 別寫抽象：不要寫「本模組負責處理…」這種廢話

如何維護文件：

• 架構變了才更新索引（不常變）
• 程式碼細節不寫入文件（會常變）
• 用 docs/CODEMAPS/ 或 README.md 當索引入口

範例：

docs/
├── CODEMAPS/
│   ├── authentication.md   ← 認證流程的索引地圖
│   ├── payment.md          ← 支付流程的索引地圖
│   └── notification.md     ← 通知系統的索引地圖
└── README.md               ← 整體索引入口

這樣，AI 可以先讀索引，再去找對應的程式碼，而不需要把程式碼寫進文件。

---

4.6 延伸資源

官方資源

• Claude Code 文檔：https://docs.anthropic.com/claude-code
• Agent Teams 功能說明：[待補充]
• Task Coordination 教學：[待補充]

社群資源

• [待補充：GitHub repo 範例]
• [待補充：Medium 文章]
• [待補充：Discord 討論群]

進階主題

• 如何設計可測試的 agent
• 如何監控 AI token 使用量
• 如何建立 agent 的 CI/CD pipeline
• 如何處理 agent 之間的衝突

---

總結

核心洞察

1. 團隊設計就是軟體架構設計
   運算單元從「函式」變成「人或 AI」
2. 從固定職位到動態資源
   不是招聘一個「會 React 的人」，而是設計「Frontend 角色」的能力組合
3. 模組化、可重用、可版本控制
   團隊配置應該像程式碼一樣，可以 git 管理、可以跨專案重用

演進路徑

v0 (單人) → v1 (Mono Repo) → v2 (Sub-module) → v3 (Multi-Repo)

建議：
- 小團隊（< 5人）：v1 即可
- 中型團隊（5-20人）：考慮 v3
- 大型組織（> 20人）：強烈建議 v3

立即行動

如果你現在就想開始：

1. 盤點現有配置
   檢視你目前的 .claude/ 結構
2. 選擇適合的版本
   用本文的決策樹選擇 v1 或 v3
3. 試驗一個小專案
   不要一次全部改，先在一個專案試驗
4. 記錄經驗
   踩坑是必然的，記錄下來形成團隊知識
5. 持續優化
   團隊設計不是一次性的，要持續迭代

---

關於本文的驗證方法

本文採用「理論驗證」而非「實測驗證」

為什麼採用理論驗證？

這是一個新興領域，AI 團隊設計還沒有大規模的實測數據可供參考。因此本文採用：

1. 架構設計原理：參考軟體工程的經典原則
2. 邏輯推演：透過成本分析、規模分析推導結論
3. 業界類比：參考成熟領域的成功模式（Multi-Repo、IaC、Design System）

這樣的驗證方法是否可信？

部分可信，但需要實踐驗證。

可信的部分：

• 架構設計原則（如 DRY、關注點分離）是經過驗證的
• 業界類比（如 Terraform、Design System）有成功先例
• 邏輯推演的結構是自洽的

需要驗證的部分：

• 實際的成本數據（人力、時間、AI token）
• 團隊的接受度與滿意度
• 不同規模團隊的實際效果
• 長期維護的真實成本

邀請你參與驗證

如果你在團隊中實踐了這套方法，歡迎分享：

• ✅ 成功經驗（什麼情境下有效？）
• ❌ 失敗教訓（遇到什麼坑？）
• 📊 實測數據（成本、時間、滿意度）
• 💡 改進建議（哪些地方可以優化？）

這些實踐經驗將讓理論變得更扎實。

> 一個正在發生、但我們還沒完全理解的轉變

---

核心問題

「你不再是一個人，也不再只是一個人。」

看到這句話的時候，我愣了一下。

它像一個謎語，又像一句預言。這句話正在發生，但我們還沒完全理解它的意思。

你還記得最後一次在履歷上寫「Frontend Developer」是什麼時候嗎？那時候，角色是清楚的、邊界是明確的。你負責前端，別人負責後端，大家各司其職，像一支樂團裡的固定位置。

但現在呢？

打開專案，你發現自己不只在寫程式碼。你在定義協作流程、在配置 AI agents、在思考如何讓「人+AI」組合產生最大效益。你像是同時扮演著 Team Lead、Product Owner，甚至有點像 HR 在配置資源。

這不是工作量變多了。這是角色本身變模糊了。

也許你會問：「軟體開發的工作內容，到底變成什麼了？」

我也還在找答案。但我知道的是，這個轉變不是你一個人在經歷。所有寫程式碼的人，都站在同一個岔路口上。

這篇文章想探討的核心問題是：

> 當軟體成為副產品，工程師的價值還剩下什麼？

我不會給你標準答案，因為沒有人知道。但我想分享我的思考過程、我觀察到的變化、以及我還不確定的部分。

---

多角度探討

角度 1：角色邊界正在消融

從「職位」到「資源」的思維轉換

以前，我們習慣用職位來定義自己。Frontend Developer、Backend Engineer、DevOps，像是貼在身上的標籤。找工作時看 JD (Job Description)，上面寫著「需要熟悉 React、TypeScript」，你對照自己的技能清單，符合就投。

這個邏輯很簡單，也很安全。就像球隊裡的固定位置，王建民就是投手，只要把球投好就行了。

但 AI 時代，遊戲規則變了。

我們需要的不是「一個會 React 的人」，而是「能夠調度各種資源來完成 Frontend 任務的角色」。這個資源可能是你自己、可能是 AI、可能是「你+AI」的組合。

你要扛的不是工作，是責任感

「你要扛的比以前更多，不是工作，是責任感。」

這句話說得很準。

以前，Frontend 工程師的責任邊界是清楚的：把 UI 做好、API 串好、效能調好。其他的事情，有 PM 管產品、有 Team Lead 管流程、有 HR 管人。

但現在，當你可以用 Claude Code 的 Task tool 來調度多個 AI agents 時，你突然發現：你需要理解 Product 的視角（什麼功能該先做？）、需要理解 Management 的視角（如何分配任務？）、甚至需要理解 HR 的視角（這個任務該配置人還是 AI？）。

技術工具變強大了，但決策責任也變重了。

以前你只需要回答「這個功能怎麼實作？」，現在你需要回答「這個功能該由誰（或什麼）來做？怎麼做最有效率？」

三個身份的疊加

我觀察到工程師正在疊加三種身份：

Team Lead：你要設計協作機制。不是「大家一起開會討論」，而是「設計一個讓人和 AI 能無縫協作的 workflow」。

Product Owner：你要定義價值產出。不是「PM 說要做什麼就做什麼」，而是「理解為什麼要做，然後找到最有效的方式實現」。

HR/總經理：你要配置資源與人力。不是「等公司招聘新人」，而是「評估這個任務該用哪種資源組合，成本效益如何，能否即時調整」。

你不再是一個人，因為你要扮演多種角色。

你也不再只是一個人，因為你身後有一整個 AI agents 的團隊。

但這裡有個矛盾：

一方面，角色邊界消融讓我們變得更全能。

另一方面，當每個人都要懂一點 Product、一點 Management、一點 HR，我們還是專業的「工程師」嗎？

我還沒想清楚。

---

角度 2：能力定義正在改變

專業能力的進化

過去的專業能力：精通單一技術棧

• React + TypeScript
• C# + .NET
• Python + Django

你花三年精通一個框架，再花兩年成為專家。專業能力的證明是：你寫的程式碼品質高、效率快、bug 少。

現在的專業能力：調度 AI Agents

• 設計 .claude/skills/ 模組
• 配置 agent 職責分工
• 整合人與 AI 的協作

你的專業能力變成：知道什麼任務該讓 AI 做、什麼任務該自己做、怎麼把兩者組合起來產生最大效益。

技術工具：

• Claude Code（開發助手）
• GitHub Copilot（程式碼生成）
• Cursor（編輯器整合）

說穿了，專業能力不再是「你會什麼」，而是「你知道怎麼組合資源來完成任務」。

就像指揮家，不需要會彈所有樂器，但要知道什麼時候該讓小提琴進來。

管理能力的進化

過去的管理能力：溝通技巧、會議效率

• 如何清楚表達需求
• 如何協調不同意見
• 如何追蹤專案進度

管理能力的重點在「人」。你學習如何與人溝通、如何化解衝突、如何激勵團隊。

現在的管理能力：設計協作演算法

• 定義 agent 的 responsibilities
• 規劃 workflow 的協作邏輯
• 設計 message passing 與 task coordination

管理能力的重點變成「機制」。你要設計一個協作系統，讓人和 AI 在裡面能高效運作。

技術事實：Agent Teams 的 message passing 允許 agents 之間互相傳遞訊息，而 task coordination 確保任務不會重複或遺漏。

對比：

傳統 Scrum：

• Daily Standup（每天15分鐘）
• Sprint Planning（計畫會議）
• Retrospective（回顧會議）

AI-augmented workflow：

• 任務自動分配給最適合的 agent
• 進度自動更新在共享 task list
• 問題自動標註並通知相關成員

這不是取代 Scrum，而是讓協作的效率提升到另一個層次。

學習能力的進化

過去的學習能力：學新框架、新語言

• 讀文檔
• 上課程
• 做 side project

學習能力的展現是：你能多快掌握一個新技術。

現在的學習能力：學習「如何讓 AI 學習」

• Prompt engineering
• Agent configuration
• Skill design

學習能力變成：你能多快教會 AI 做你想要它做的事。

技術事實：在 Claude Code 中，你可以透過 .claude/agents/ 定義 agent 的職責，透過 .claude/skills/ 定義可重用的技能模組。這些都是「教 AI」的具體方式。

[此處可加入您學習 AI 工具的心得——第一次成功讓 AI 完成複雜任務時的感受]

這三個進化帶來的困惑

這三本柱的進化，也許讓我們變得更強大，也讓我們更依賴工具。兩者都是真的。

但我知道的是，當工具變強大時，我們的價值就不再是「會操作工具」，而是「知道該用工具做什麼」。

但這裡又有個問題：

如果工程師的價值是「知道該用工具做什麼」，那麼當 AI 也能學會「判斷該用什麼工具」時，我們還剩下什麼？

我還沒想清楚。

---

角度 3：團隊本質的重新思考

團隊是「人」的組成，還是「職位」的組成？

我們常說「我們是一個團隊」。

但仔細想想，這個「團隊」到底是什麼？

是「五個人」，還是「五個職位」？

靜態職務的困境

以前，組建團隊的方式很直接：

1. 寫一份 JD (Job Description)
2. 列出需要的技能
3. 招聘符合條件的人
4. 人到職後開始工作

這個模式有個假設：職位是固定的，需求是穩定的。

「我們需要一個 Senior React Developer」——這個需求在專案的一年內都不會變。所以我們找一個人，讓他從頭做到尾。

但問題來了：職位是固定的，但需求是動態的。

專案初期需要快速建立 prototype，這時候需要的是「會快速驗證想法」的人。專案中期需要穩定架構，需要的是「擅長系統設計」的人。專案後期需要優化效能，需要的又是另一種專長。

同一個「Senior React Developer」，能在所有階段都是最適合的人選嗎？

動態資源配置的新思維

「AI 時代，人是一種 agent，也是你的資源，你的花費變成算力，變成 token，還有時間，你有權抽換，有權調整。」

這句話剛開始聽起來有點冷血。

「人怎麼能說抽換就抽換？」

但換個角度想，這其實是一種解放。

以前，團隊組成是固定的。老闆說「這五個人就是你的團隊」，那就是這五個人。不管任務適不適合他們，你都得想辦法讓他們勝任。

現在，團隊組成可以是彈性的。

技術上，這已經可行了（Claude Code 的 subagent 機制允許動態生成與調度 agents）。

資源的衡量也變了：

• 傳統：月薪、年薪、福利
• 現在：算力（API calls）、token（使用量）、時間（執行時長）

更重要的是，你有權調整組成。

如果發現某個 AI agent 的能力不夠，你可以換一個更強的模型。如果發現某個任務需要人來做，你可以把它從 AI 手上拿回來。

這不是冷血，這是靈活。

從「找人」到「設計角色」

組建團隊的思維，從「找人」變成「設計角色」。

以前：「我需要一個會 React 的人」

現在：「Frontend 角色需要哪些能力模組？」

然後你發現：

• UI 組件開發 → AI 可以做 80%
• 狀態管理設計 → 需要人來思考
• 效能優化 → 人+AI 協作效果最好
• Code Review → AI 先篩一輪，人做最終把關

最後你配置的不是「一個 Frontend Developer」，而是：

• 1 個懂架構的人（負責設計與決策）
• 2 個 AI coding agents（負責實作）
• 1 個 AI review agent（負責品質把關）

這個組合的成本可能只有傳統「招聘兩個 Frontend」的 1/3，但效率可能是 1.5 倍。

也許有一天，當別人問「你的團隊有幾個人？」，你會回答：「2 個人，6 個 AI agents。」

這聽起來很科幻，但其實已經在發生了。

但這裡又有個倫理問題：

當人變成「可配置的資源」，當團隊組成變成「設計」而非「招聘」，人的尊嚴和價值怎麼辦？

我們會不會變成「可抽換的零件」？

我還沒想清楚。

---

角度 4：價值產出的翻轉

思維的翻轉

「我們以前是團隊的一員，是在創造產品；現在我們是一起在創造團隊的演算法。」

這句話的轉折，藏著一個深刻的洞察。

以前，我們的工作產出是什麼？

是軟體。是 Web Application、API Service、Data Pipeline。我們寫程式碼、做測試、部署上線，然後產品開始產生價值。

軟體是主要產出。團隊是手段。

但現在，這個關係翻轉了。

主產品：團隊設計思維 & 協作演算法

• 角色如何定義？
• 技能如何模組化？
• 協作如何流程化？
• 品質如何機制化？

副產品：軟體工具 & 專案產出

• Web Application
• API Service
• Data Pipeline

軟體變成了副產品。因為當你把團隊設計好了，軟體自然就會被高效地產出。

什麼是「團隊的演算法」？

聽起來很抽象，對吧？

讓我用技術語言解釋：

說白了，團隊設計就是軟體架構設計，只是運算單元從「函式」變成了「人或 AI」。

定義 agents 的 responsibilities

就像寫程式碼時定義函式的職責一樣，你要定義每個 agent 的職責範圍、輸入輸出、與其他 agent 的介面。

技術事實：在 .claude/agents/ 中，每個 agent 的 markdown 檔案就是在定義它的職責。

設計 skills 的可重用模組

就像寫程式碼時抽離共用邏輯一樣，你要把團隊的能力模組化、可重用、可組合。

技術事實：在 .claude/skills/ 中，你可以定義 frontend-expert、backend-expert、process-manager 等技能模組，然後在不同專案中重複使用。

規劃 workflow 的協作邏輯

就像寫程式碼時設計資料流一樣，你要規劃任務如何流動、誰在什麼時候接手、如何驗證完成。

技術事實：Claude Code 的 task coordination 機制允許你定義任務的依賴關係、執行順序、完成條件。

如果團隊是產品

如果團隊是產品，那我們該怎麼「開發」它？

模組化：將團隊能力模組化

• 把「Frontend 開發」拆成：UI 組件、狀態管理、API 串接、效能優化
• 每個模組可以獨立進化、獨立測試

可配置：將協作流程可配置

• 不同專案可以有不同的協作流程
• 透過 .claude/agents/ 的配置檔案來調整

版本控制：將團隊結構版本控制

• 團隊配置放進 git
• 可以追蹤演進、可以回溯、可以比較不同版本

當團隊可以像軟體一樣被設計、被測試、被迭代時，我們就真的在「創造團隊的演算法」了。

也許有一天，我們會像評估軟體品質一樣評估團隊品質——這個團隊的「可維護性」如何？能不能快速替換某個角色？當需求改變時，這個團隊的「擴展性」如何？

聽起來很瘋狂，但也許這就是未來。

但這裡又有個哲學問題：

如果團隊可以被「設計」、被「版本控制」、被「測試」，那麼團隊還是「人」的集合嗎？

還是變成了「機制」的集合？

我還沒想清楚。

---

我的個人立場

有時候我會想，如果有一天，寫程式這件事不再是我們的全部價值，那我們還剩下什麼？

我傾向相信的答案

我傾向相信：軟體確實正在成為副產品，團隊設計才是主產品。

不是因為我有完整的證據，而是因為我觀察到的趨勢：

1. 工具變強了，但問題沒有變簡單

• Claude Code 可以寫代碼，但誰來決定寫什麼？
• AI 可以優化效能，但誰來定義「好的效能」？
• 技術問題被解決得越來越快，但「該解決什麼問題」變得越來越難

2. 個人能力的天花板變低了，但組織能力的天花板變高了

• 一個人能做的事情，AI 很快就能做
• 但一個設計良好的「人+AI」團隊，能做到以前需要 10 倍人力才能做到的事

3. 可複製的技能變得不值錢，但不可複製的判斷變得更值錢

• 寫代碼 → 可複製 → AI 能做
• 判斷該寫什麼代碼 → 不可複製 → 還需要人
• 設計團隊協作機制 → 更不可複製 → 更需要人

我還不確定的部分

但我還有很多不確定：

1. 這個轉變的速度有多快？

是 2 年內每個工程師都要學會「團隊設計」？

還是 10 年才會真正普及？

2. 不是每個人都適合當「設計者」

有些人就是喜歡專注在技術細節，不想管協作、流程、資源配置。

當「工程師」這個角色強制要求你成為「設計者」時，那些不想轉型的人該怎麼辦？

3. 人的價值到底在哪裡？

如果 AI 能做代碼，未來也能做判斷，那麼人的不可取代性在哪裡？

「對人的理解、對混亂的包容、對不確定的勇氣」——這些聽起來很美，但真的是不可取代的嗎？

還是只是我們暫時還沒被 AI 取代的安慰？

4. 倫理問題

當人變成「可配置的資源」，當團隊變成「可設計的演算法」，我們會不會失去某些重要的東西？

團隊的溫度？人與人之間的信任？那些無法被量化的連結？

[此處可加入您的個人經歷——在導入 AI 協作時，是否有過這些困惑？你的團隊如何面對這些問題？]

為什麼我還是想試試看

即使有這麼多不確定，我還是想試試看。

不是因為我有答案，而是因為：

1. 這個轉變正在發生，不管我們準備好了沒有

與其被動接受，不如主動探索。

2. 早期探索的人會建立新的專業

就像 10 年前，「DevOps」還不是一個正式的職位。現在，DevOps 工程師是市場上最搶手的角色之一。

也許 5 年後，「Team Architect」（團隊架構師）會成為一個獨立的職位。

3. 這個過程很有趣

設計團隊就像設計軟體一樣，有架構、有模組、有版本控制。

對於喜歡「設計系統」的工程師來說，這是一個全新的遊樂場。

---

開放結尾

給讀者的問題

我不知道十年後，「工程師」這個職業會變成什麼樣子。

但我知道的是，那些能夠從「團隊的一員」轉變為「團隊的設計者」的人，會在這場轉型中找到自己的位置。

現在，我想把問題拋給你：

1. 你準備好從「團隊的一員」變成「團隊的設計者」了嗎？

如果不準備，為什麼？

如果準備，你缺少什麼？

2. 如果團隊可以版本控制，你會設計什麼樣的 v2.0？

你現在的團隊是 v1.0，有哪些痛點？

如果可以重新設計，你會怎麼改？

3. 當軟體成為副產品，你的主產品是什麼？

除了寫代碼，你還在創造什麼？

那些東西能不能被「版本控制」、「模組化」、「重用」？

4. 人的不可取代性在哪裡？

你相信有些東西 AI 永遠學不會嗎？

如果有，是什麼？

如果沒有，我們該怎麼辦？

我還在想的問題

我也還在想這些問題：

關於速度：這個轉變會比我們想像的快嗎？還是慢？

關於適應：不想轉型的人，還有生存空間嗎？

關於倫理：當團隊變成「可設計的演算法」，我們會失去什麼？

關於未來：5 年後，我們還會用「工程師」這個詞來形容自己嗎？

未來可能的變化

也許，未來會有這些變化：

新的職位：

• Team Architect（團隊架構師）
• Workflow Designer（協作流程設計師）
• Agent Coordinator（AI 協調者）

新的技能：

• 團隊設計模式（就像現在的軟體設計模式）
• Agent 配置與調度
• 人機協作的最佳實踐

新的價值觀：

• 從「個人貢獻」到「系統設計」
• 從「技術深度」到「資源協調」
• 從「寫代碼」到「創造機制」

但這些只是猜測。

真正的未來，要我們一起創造。

---

如果你想立即開始

不需要等到完全準備好。你現在就可以做三件事：

1. 盤點你的「技能模組」而非「職位標籤」

你不是「Frontend Developer」

你是擁有：

• UI 設計感知
• 狀態管理經驗
• API 串接能力
• 協作溝通技巧

把這些能力列出來，然後問自己：哪些可以交給 AI？哪些必須自己做？

2. 試著設計一個小型 AI 團隊

2 個人 + 3 個 AI agents

定義清楚的職責分工

實際跑一個小專案

看看會遇到什麼問題

3. 將一次協作流程寫成「可重用的 workflow」

記錄下你們是如何協作的

哪些步驟可以自動化？

哪些決策點需要人來判斷？

然後問自己：你的「主產品」是什麼？

---

最後的邀請

我還在想。但我想試試看。

你呢？

如果你有想法、有經驗、有困惑，歡迎與我討論。

這不是一個人的旅程，而是一整個世代的轉型。

我們一起探索。

當你的 AI 助手看不懂你的 Legacy Code 時

你有沒有想過，為什麼 AI 可以寫出漂亮的 Hello World，卻搞不定你那個跑了五年的舊專案?

不是 AI 不夠聰明。是因為你的 Legacy 專案裡,藏著十幾個離職工程師的靈魂、三種不同的架構風格、還有一堆「當時為什麼要這樣寫」的謎題。

這就像你請了一個新人,然後丟給他一個沒有文件的專案,說「去修 Bug」。他能做什麼?到處翻程式碼、猜測原始設計者的意圖、小心翼翼地改一點點東西,然後祈禱不要炸掉整個系統。

AI 也一樣。它需要 context。更精確地說,它需要專案特定的 context。

但這裡有個更深層的問題:假設你把所有 context 都給了 AI,它就能自己工作了嗎?不行。因為你還沒告訴它「什麼叫做品質」。

問題的根源:技能需要 Context,品質需要意識

Generic AI Agent 很強大,但它不知道你的專案「正常」長什麼樣。

假設你有一個電商網站的 Legacy 專案: – 訂單系統用 Stored Procedure – 庫存系統用 ORM – 支付系統直接寫 SQL – 三種風格並存,但都能動

Generic Agent 會怎麼做?它可能統一成一種風格——這聽起來很好,但你確定現在要重構整個資料存取層嗎?

第一個決策點:Generic Team vs Dedicated Team

類型	適用情境	優點	缺點
Generic Team	新專案、實驗性任務	快速啟動、不需準備	不懂專案特性
Dedicated Team	Legacy 專案、產品開發	理解專案脈絡	需要建置 context

對於 Legacy 專案,你幾乎必然需要 Dedicated Team——但這代表你要先教會 AI 你的專案。

而更關鍵的是:你還要教會 AI 什麼叫做「好」。

品質意識的三層世界

在傳統開發流程中,品質意識存在三個層次:

第一層:工程師的品質意識

第二層:PM 的品質意識

第三層:客戶的品質意識

三層之間常常衝突。工程師想重構,PM 想趕進度,客戶想省錢。

那麼 AI 呢?AI 的品質意識是什麼?

答案是:沒有。除非你教會它。

如何教 AI 品質意識:Workflow 文件化

假設你的團隊處理 Bug 的標準流程是:

1. 確認 Bug 可重現
2. 寫單元測試 cover 這個 Bug
3. 修改程式碼讓測試通過
4. 確認沒有 regression 5. Code Review 後才能 merge

這些在你腦中是常識,但 AI 不知道。它可能直接改程式碼、跳過測試、甚至製造新的 Bug。

所以你需要把品質意識寫進 Workflow:

## Bug 修復流程

### 前置條件
– 確認 Bug 在 staging 環境可重現
– 確認 Issue Tracker 有完整描述

### 執行步驟
1. 建立 feature branch (格式: bugfix/TICKET-123)
2. 新增測試案例 (失敗狀態)
3. 修改程式碼讓測試通過
4. 執行完整測試套件
5. 本地驗證修復結果
6. 提交 Pull Request 並標註 Reviewer

### 品質標準
– 測試覆蓋率 ≥ 80%
– 沒有 console.log 殘留
– 符合專案 Coding Style
– 沒有引入新的 dependency

### 禁止行為
– 直接改 production database
– 跳過測試
– 硬編碼敏感資訊

這不是寫給人看的文件。寫給 AI 的行為準則。

當你把這些寫清楚,AI 才知道「在這個專案裡,什麼叫做做得好」。

實作流程:從 Legacy Code 到 AI Team

基於 A-Team 專案(reference:參考一個製作團隊的團隊專案: A-Team Framework)的概念,以下是建立 AI 團隊的六步驟實作流程:

1. 盤點 Codebase 並產生 Documents

假設你有一個三年前的 .NET 專案,第一步是讓 AI 理解它:

# 生成專案結構文件
tree src/ > docs/structure.md

# 提取 API 端點清單
grep -r “Route\|HttpGet\|HttpPost” src/ > docs/api-endpoints.md

# 列出資料庫 Schema
# (從 Migration 檔案或實際 DB)

# 整理 README、Wiki、任何現有文件

你需要回答這些問題: – 這個專案的核心功能是什麼?
– 有哪些關鍵的技術決策?(例如為什麼用 Stored Procedure)
– 有哪些已知的坑?(例如某個 API 的 timeout 要設 60 秒)
– 測試策略是什麼?(有整合測試嗎?假資料怎麼處理?)

這些資訊會成為 AI Team 的「專案記憶」。

2. 需求/願景 → Skills + Context = Team

定義需求清單與對應 Skills:

需求清單: – 修 Bug – 重構某個模組 – 加新功能 X

對應 Skills:

skills:
  – name: legacy-bug-fixer
    description: 修復 Bug 並確保測試覆蓋
    context:
      – docs/structure.md
      – docs/known-issues.md
      – workflows/bug-fixing.md

  – name: module-refactor
    description: 重構特定模組並保持向下相容
    context:
      – docs/architecture.md
      – docs/refactor-guidelines.md

  – name: feature-developer
    description: 開發新功能並整合到現有系統
    context:
      – docs/api-design.md
      – docs/database-schema.md

每個 Skill 都綁定特定的 context。像你給不同的工程師分配任務,並附上相關文件。

3. 決策:這個專案適合 Generic Team 嗎?

檢查清單:
– [ ] 專案架構是否標準?(例如典型的 MVC)
– [ ] 程式碼風格是否一致?
– [ ] 測試是否完整?
– [ ] 文件是否充足?
– [ ] 部署流程是否自動化?

如果五個問題有三個以上答「否」,你需要 Dedicated Team。

為什麼?

因為 Generic Team 假設「最佳實踐」,但你的 Legacy 專案可能根本不是最佳實踐。它可能是: – 「當年我們人手不足,先求有再求好」 – 「這個 Workaround 是為了繞過某個 bug」 – 「這段程式碼不要動,動了會炸」

這些潛規則,只有 Dedicated Team(帶著專案特定的 context)才能理解。

4. 設計團隊:Generic vs Dedicated 的實際結構

Generic Team 範例 (適合新專案):

Team: web-app-generic
  ├── Coordinator (project-manager)
  ├── Backend Developer (generic)
  ├── Frontend Developer (generic)
  └── QA Engineer (generic)

Context: 無(依賴 AI 的預訓練知識)

Dedicated Team 範例 (適合 Legacy 專案):

Team: legacy-ecommerce-team
  ├── Coordinator (team-lead)
  ├── Order-System-Specialist
  │   └── Context: docs/order-system.md, workflows/order-bug-fix.md
  ├── Payment-Specialist
  │   └── Context: docs/payment-integration.md, docs/pci-compliance.md
  └── Inventory-Refactor
       └── Context: docs/inventory-schema.md, docs/refactor-plan.md

Context: 專案特定文件 + Workflows

Dedicated Team 的每個角色都有明確的職責範圍和context 邊界。Order-System-Specialist 不會去動 Payment 的程式碼,因為它的 context 裡沒有支付系統的資訊。

這種隔離很重要。它模擬了真實團隊中的「我不熟那塊,還是找負責的人來改」。

5. Workflow 文件化:定義品質標準

把「怎樣算做好」寫下來。

Bug 修復 Workflow:

## 輸入
– Bug Report (Jira Ticket)
– 重現步驟

## 輸出
– Fixed Code + Unit Test + Integration Test (if needed)
– Pull Request with description

## 品質標準
– 測試覆蓋率 ≥ 80%
– 沒有 console.log 或 Debug code
– 沒有引入新的 dependency (除非經過批准)
– Commit message 格式: “fix(module): description”

## 禁止行為
– 直接改 production database
– 跳過測試
– 硬編碼敏感資訊

Refactoring Workflow:

## 輸入
– 目標模組
– 重構目標 (可讀性/效能/架構)

## 輸出
– Refactored Code (保持 API 相容)
– 更新的測試
– 效能比較報告 (如果是效能重構)

## 品質標準
– 所有測試必須通過
– API 向下相容 (或提供 Migration Guide)
– 複雜度降低 (Cyclomatic Complexity < 10)
– 程式碼行數減少 ≥ 20% (如果可能)

## 禁止行為
– 改變公開 API 而不通知
– 刪除測試
– 引入 breaking change

這些 Workflow 會被嵌入到每個 Skill 的定義中。當 AI Agent 執行任務時,它會遵循這些規則。

6. 建立虛擬團隊 Retro 機制

就像真實團隊會開 Retrospective 會議,AI Team 也需要反饋迴圈。

建立 Retro Log:

## Retro: 2026-02-10

### 完成任務
– Fixed Bug #123 (Order calculation)
– Refactored Inventory module

### 遇到的問題
– Bug #123 的測試案例不足,花了額外時間補測試
– Inventory 重構時發現 undocumented dependency on Payment module

### 改善建議
– 更新 workflows/bug-fixing.md: 明確要求「每個 Bug 至少兩個測試案例」
– 更新 docs/inventory-schema.md: 加入與 Payment 的關聯說明

### Context 更新
– 新增 docs/cross-module-dependencies.md

這個 Retro Log 會被加回 context,讓 AI Team 下次遇到類似情況時更聰明。

真正的「學習」機制。

人類角色的轉變:從執行者到管理者

當你建立了 AI Team,你的角色會改變。

過去:你是工程師

現在:你是 Team Lead

但你必須更懂技術。

因為你要能判斷: – AI 產生的程式碼是否符合專案標準? – 這個重構是改善還是製造新問題? – 測試覆蓋是否充分? – 有沒有引入安全風險?

你從「寫程式碼的人」變成「教 AI 怎麼寫好程式碼的人」。

這個轉變不容易。有些人會覺得「我還是自己寫比較快」。也許在短期是這樣,但當你的 AI Team 建立起來、context 完善、workflows 明確之後,它可以處理的事情會越來越多。

而你可以專注在更高層次的問題: – 這個架構該往哪個方向演進? – 這個技術債要不要還? – 下一季的 Roadmap 是什麼?

你的選擇

所以,回到一開始的問題:當你的 AI 助手看不懂你的 Legacy Code 時,你要怎麼辦?

你有三個選擇:

1. 短期有效,長期累死
2. 硬做 — 可能做出來,但品質堪憂
3. 前期投資時間,後期加速開發

如果你選擇第三條路,你會發現:教 AI 理解你的專案,本質上是在強迫自己把隱性知識顯性化。

那些「只有資深工程師知道」的眉角、那些「不知道為什麼但就是要這樣做」的慣例、那些「文件上沒寫但大家都知道」的規則——你必須全部寫下來。

這個過程很痛苦,但也很有價值。

因為最後,你得到的不只是一個 AI Team。你還得到了一份完整的專案文件、一套明確的開發流程、一個可以傳承的知識體系。

即使哪天你決定不用 AI 了,這些東西還是有價值的。

---

參考一個製作團隊的團隊專案: A-Team Framework

標籤: #AI開發 #LegacyCode #團隊管理 #軟體工程 #技術管理

為什麼需要團隊？

一個專案，你一個人做要三個月。但如果有團隊——PM 規劃、工程師開發、設計師做介面、測試把關——一個月搞定。

差別不在人多，在於分工和協作。PM 想得通透、工程師寫得扎實、設計師做得好看、測試抓得仔細。每個人專注擅長的，拼起來就是完整產品。

這是團隊的價值：不是「多個人」，是「互補的專業 + 協作機制」。

---

AI 團隊是什麼？

AI 團隊，不是「一個很強的 AI」，是「多個專業 AI agents 的分工協作」。

寫一篇專業文章，單一 AI 可以幫你寫，但企劃不夠深、研究不夠透、文字不夠潤。

換成 AI 寫作團隊：

• 企劃 agent 定調、分析受眾、規劃大綱
• 研究 agent 蒐集資料、查證來源
• 主筆 agent 撰寫內容、運用風格
• 審稿 agent 潤飾文字、檢查邏輯
• 品質 agent 評分把關、確保達標

交付的不是「AI 寫的文章」，是「經過完整流程的作品」。

AI 團隊的本質：不是更強，是更完整。

---

什麼時候需要 AI 團隊？

關鍵在於複雜度和專業深度。

個人用途：學習、創作、決策輔助

• 學習：教練 agent 提問 + 解答 agent 講解 + 測驗 agent 檢驗
• 創作：企劃 + 撰寫 + 審稿完整流程
• 決策：分析師給數據 + 顧問給建議 + 魔鬼代言人挑戰盲點

專案用途：開發、生產、協作

• 軟體開發：架構師 + 前後端 + 測試 + DevOps
• 內容生產：企劃 + 研究 + 撰寫 + 設計 + 行銷
• 商業分析：市場研究 + 財務分析 + 策略規劃

差別是：個人用要「多個角度」，專案用要「多個專業」。

---

人的團隊 vs AI 團隊

人的團隊三個痛點：溝通成本高、時間受限、情緒干擾。

AI 團隊的優勢：24/7 待命、無情緒、成本可控。

但人的團隊仍有 AI 無法取代的：

• 創意：AI 組合，人類靈感
• 判斷：AI 給選項，人做決策
• 責任：AI 不負責，人要負責

AI 團隊不是取代人，是讓每個人都有「隨時待命的專業支援團」。

---

真正的變革

AI 團隊帶來的，不是工作被取代，是工作方式升級。

以前，只有公司養得起完整團隊。現在，一個人也能調度 AI 團隊。

以前，專案要等人有空。現在，你想做，團隊就在。

以前，品質看最弱成員。現在，每個 agent 都最佳狀態。

真正的問題不是「AI 團隊能做什麼」，是「你準備好調度團隊了嗎？」

未來競爭力，不只是你會什麼，是你能調動什麼資源、協調什麼專業、完成什麼價值。

AI 團隊，是你的第一個練習場。

最近一直在想，人跟 AI 之間到底是什麼關係。

不是取代。是一連串的學習。

AI 做得比人快，這已經是事實了。寫 code、整理資料、生成報告，速度跟品質都有一定水準了。但做得快不等於做得對。AI 做錯的時候，問題多半出在人——你沒教他什麼是對的，他當然沒有方向感。

這跟帶小孩很像。孩子犯錯，你不會說「算了他就是這樣」，你會教他。AI 也一樣。他做得不好，你調整 prompt、寫 skills、設規則，他就會進步。你在乎，他就會變好。你不在乎，他就停在那裡。

我自己有一個習慣。當我讓 AI 跟團隊成員 pair 完，我會去問那位 member：「我的 AI 到不到位？有沒有什麼要改的？」體驗不好，就是我的問題，我得想辦法讓他進步。跟你要求產品、要求部屬做出口碑是一樣的。AI 寫的 code，你仍然要負責。

---

我後來發現，工具的介面決定了你跟 AI 的關係。

Web 介面，你盯著一個對話框，一來一回，像在傳訊息。IDE 裡面裝 Copilot，你寫一行它補一行，像有個人在旁邊看你打字。但到了 CLI——Claude Code、Gemini CLI、Codex CLI 都算——整個感覺不一樣了。你下指令，他去跑，跑完回來報告，你再給下一個指令。

這比較像在帶人。

如果你是管理者，CLI 會比你想像中還適合。因為管理本來就不是自己動手做，是確保事情被做對。你的工作是看方向、給回饋、收尾。剛好 CLI 就是這個節奏。

---

有人問我 Pro 升 Max 值不值得。

我的想法是：那是執行力的底氣。跟股市本多終勝一樣——你有本，你就敢壓；你敢壓，才有機會贏。token 也是。你有 token，你就敢多試；多試，就有機會做出東西。

不做，只能一直想。做了，值得一直講。

多做不是多錯。無法承擔責任的人，本來就不會有大任。大家看的是目標跟結果。你過程浪費太多，可以檢討。但最有價值的，是那份願意往前走的信念。

當然，這在職場上有時是雙面刃。信念太強的人，不一定活得下來。

---

因為 AI，你能做的事變多了，事業變大了。但你的專注度沒有跟著變大。他解放了你的物理極限，但你的注意力還是有限的。取捨，反而比以前更重要。

黃仁勳說過：取代你的不是 AI，是有 AI 能力的人。

在軟體業，這件事會非常明顯。人類的需求會極少化。無人工廠、少人的辦公室——這不是預言，是正在發生的事。你的工作如果是電腦上的作業，全部遲早會被簡化、自動化，然後消失。流程裡面的人會先不見。剩下的價值只有兩種：物理世界搬不走的，跟面對客戶那一刻的情緒跟服務。

品質跟產出？人類已經比不了了。

---

回到創業的角度來看這件事。

分工為了什麼？擴張為了什麼？檢視之後會發現，資方跟勞方要的東西從來沒對齊過。人要一份工作、一個願景、一點使命感。公司要的只有成本跟收入。

這場仗會一直打。

我沒有答案。但我知道，站在哪一邊，會決定你怎麼看 AI。

---

所以到最後，AI 還是一個人性的議題。你是他的上限，也是他的下限。

AI 是乘法。你是 1，他讓你變 10。你是 0，乘多少都是 0。