[methodology] AI 工具選型與工作流

cover

AI 工具選型與工作流

流程概覽

flowchart LR
    A[需求理解<br/>Human] --> B[方案設計<br/>Human + AI]
    B --> C[AI 生成<br/>Code / Test / Doc]
    C --> D[人工審查<br/>Human Review]
    D -->|需要修改| C
    D -->|通過| E[整合測試<br/>Iterate]
    E --> F[部署上線<br/>Ship]

    style A fill:#4CAF50,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#FF9800,color:#fff
    style D fill:#F44336,color:#fff
    style E fill:#9C27B0,color:#fff
    style F fill:#009688,color:#fff

文章概覽

在本篇文章中，您將學習到：

為什麼 AI 是力量放大器而非替代品，以及「垃圾進、垃圾出」的現實
AI 工具的四個層級分類與各自的適用場景
選擇 AI 工具時應該考量的五個維度
如何將 AI 整合進日常開發工作流
Prompt 設計與 Skills / Instructions 的實務方法
為什麼基礎知識是有效使用 AI 的不可替代前提
團隊層面的 AI 策略與常見風險

前言：AI 不是魔法

讓我先說一個不受歡迎的觀點：AI 不會讓你變強，它只會讓你「更像你自己」。

如果你是一個有 5 年經驗的後端工程師，AI 會幫你把原本需要 2 小時的 CRUD boilerplate 壓縮到 15 分鐘。你的產出是「加速了 5 年經驗」的結果——因為你知道要加 input validation、要處理 race condition、要考慮 idempotency、要寫 migration 而不是直接改 schema。

但如果你是一個剛入門的人，AI 會幫你用 15 分鐘產出一坨看起來能跑的 code——沒有 error handling、SQL injection 門戶大開、密碼用明文存在資料庫裡、API 沒有 rate limiting。你不知道自己不知道這些事，而 AI 不會主動告訴你。

這就是力量放大器的意思：放大的是你已有的能力，不是你沒有的能力。

垃圾進、垃圾出的現實

LLM（大型語言模型）的核心機制是「根據上下文預測下一個最可能的 token」。它不「理解」你的需求，它只是在統計上找到最可能的回應。這意味著：

你的 prompt 越模糊，回應越通用——通用通常意味著不適用於你的具體情境
你不給 context，它就自己編造——這不是 bug，這是 LLM 的運作方式
你不指出錯誤，它就假設一切正確——它沒有自我修正的機制

來看一個真實的例子：

// 糟糕的 prompt
「幫我寫一個登入 API」

// AI 可能的產出
app.post('/login', (req, res) => {
  const user = db.query(`SELECT * FROM users WHERE email = '${req.body.email}'`);
  if (user.password === req.body.password) {
    res.json({ token: jwt.sign({ id: user.id }, 'secret123') });
  }
});

這段 code 能跑嗎？能。它能上 production 嗎？絕對不行。 問題包括：

SQL injection（字串拼接 query）
明文比較密碼（沒有 bcrypt）
JWT secret 硬編碼
沒有 input validation
沒有 rate limiting
沒有 error handling
沒有 logging

一個有經驗的工程師看到這段 code 會立刻知道問題在哪。但一個新手會覺得「AI 寫的應該沒問題吧」，然後直接部署。

// 有經驗的工程師的 prompt
「寫一個 Express login endpoint，需要：
- 使用 parameterized query 防 SQL injection
- 用 bcrypt 比較 hashed password
- JWT secret 從環境變數讀取
- 加上 express-validator 驗證 email 格式和密碼長度
- 加上 rate limiter (express-rate-limit)
- 錯誤時回 standardized error response
- 記錄 login attempt（成功和失敗都要）」

差異不在 AI 的能力，在於你知不知道要問什麼。

AI 失敗的真實案例

以下是我觀察到的、沒有領域知識就使用 AI 所造成的真實失敗：

情境	發生了什麼	根本原因
用 AI 寫 Terraform	產出的 security group 開了 0.0.0.0/0 inbound	使用者不懂 networking
用 AI 設計 DB schema	所有資料塞在一張表，沒有 normalization	使用者不懂資料庫設計
用 AI 寫前端元件	完全沒有 keyboard navigation 和 ARIA 標籤	使用者不懂 accessibility
用 AI 寫效能優化	加了 useMemo 在不需要的地方，反而更慢	使用者不懂 React rendering
用 AI 寫單元測試	只測 happy path，coverage 數字好看但毫無意義	使用者不懂測試策略

每一個案例的共同點：AI 產出了表面上合理的結果，但實際上是錯的或不完整的，而使用者缺乏判斷能力。

AI 工具分類

不是所有 AI 工具都一樣。它們在「自主程度」和「風險等級」上有根本差異。我把目前主流的 AI 開發工具分為四個層級：

Level 1：自動補全（Autocomplete）

代表工具： GitHub Copilot, Cursor Tab, Codeium, Supermaven

這是門檻最低、風險最低的 AI 輔助方式。它的運作模式是：你在寫 code，AI 根據上下文預測你接下來「可能」要打的內容，顯示為灰色建議文字，你按 Tab 接受或忽略。

為什麼風險最低：

你仍然在逐行寫 code，AI 只是加速打字
每一行建議你都會看到，天然形成 review
拒絕建議的成本是零（不按 Tab 就好）
你保持完整的控制權

適合的使用者： 所有程度的開發者。即使是初學者，因為 review 成本極低，風險可控。

典型加速場景：

# 你打了函式名稱和參數，AI 幫你補完函式體
def calculate_shipping_cost(weight: float, distance: float, is_express: bool) -> float:
    # Copilot 會根據函式名和參數猜測實作
    base_rate = 5.0
    weight_rate = 0.5 * weight
    distance_rate = 0.1 * distance
    express_multiplier = 1.5 if is_express else 1.0
    return (base_rate + weight_rate + distance_rate) * express_multiplier

局限：

只能處理短小的、模式化的 code
對於需要全局理解的邏輯，預測準確率下降
容易讓你養成「不思考就按 Tab」的習慣

Level 2：對話助手（Chat Assistant）

代表工具： ChatGPT, Claude, Gemini, 各 IDE 內建的 Chat Panel

這個層級從「自動補全」跳到「互動對話」。你可以用自然語言問問題、請它解釋概念、幫你 debug、寫文檔、brainstorm 架構方案。

為什麼風險提高了：

AI 產出的是完整的段落或程式碼區塊，不是一行一行的建議
你需要整段閱讀並判斷正確性
AI 的回答「聽起來很有道理」，但可能完全是錯的（hallucination）
你可能會因為懶得驗證而直接複製貼上

適合的使用者： 有一定經驗的開發者——至少要能判斷 AI 回答的品質。

最佳使用場景：

解釋概念： 「解釋 React 的 useEffect cleanup function 的用途和常見陷阱」
Debug 輔助： 把 error message 和相關 code 貼上去，問可能的原因
寫文檔： 給它 code，讓它產出 JSDoc 或 README
Brainstorm： 「設計一個 notification system，需要支援 email, push, SMS，列出幾種架構方案的 trade-offs」
學習新技術： 「我熟悉 Express，幫我比較 Express 和 Fastify 的差異」

錯誤使用方式：

// 不要這樣做
「幫我寫一個完整的電商系統」
// AI 會產出一大段 code，你不知道它做了哪些假設、省略了什麼

// 應該這樣做
「我在設計一個電商系統的購物車功能。
目前的技術棧是 Next.js + PostgreSQL + Redis。
購物車需要支援未登入用戶（用 session）和已登入用戶（存 DB）。
請列出主要的資料模型和 API endpoint 設計，
以及 session cart 和 DB cart 合併的策略。」

差異在於：後者提供了足夠的 context，限縮了回答範圍，讓你更容易驗證。

Level 3：程式碼代理（Code Agent）

代表工具： Claude Code, Cursor Agent Mode, Windsurf, Cline, Aider

這是一個質的飛躍。Code Agent 不只是回答問題，它可以：

讀取你的檔案系統
修改多個檔案
執行 shell 命令
運行測試
提交 git commit
多步驟完成複雜任務

為什麼風險大幅提高：

Agent 可能修改你沒有預期它修改的檔案
多步驟操作中的任何一步出錯，可能影響整個 codebase
你需要 review 的不是一段 code，而是一個完整的 PR（可能涉及十幾個檔案）
Agent 可能「自信地」做出錯誤的架構決策

適合的使用者： Senior 開發者。你需要能 review 一個完整 PR 的能力，包括架構合理性、邊界條件、安全性、效能影響。

最佳使用場景：

Boilerplate 生成： 建立新的 service / module 的基本結構
重構： 把某個 pattern 統一替換（例如把所有 callback 改成 async/await）
測試補齊： 為現有 code 補寫測試
Bug 修復： 給它 issue 描述，讓它找到問題並修復
文檔更新： 根據 code 變更更新相關文檔

使用 Code Agent 的安全守則：

1. 永遠在 git branch 上操作，不要在 main 上讓 agent 直接改
2. 設定明確的 scope：告訴它只能改哪些檔案/目錄
3. 每次任務後都 review diff，不要盲目 commit
4. 對於 infrastructure/security 相關的變更，手動做
5. 使用 .clinerules / CLAUDE.md / .cursorrules 約束行為
6. 建立 instructions/skills 標準化重複性任務

Level 4：工作流自動化（Workflow Automation）

代表工具： n8n, LangChain, LlamaIndex, Custom agents, Dify

這個層級不是「用 AI 寫 code」，而是「把 AI 嵌入業務流程」。例如：

自動分析客服工單，分類後派給對應團隊
監控 PR，自動生成 code review 摘要
從文件中擷取結構化資料，存入資料庫
自動將 Figma 設計稿轉換為前端元件

為什麼這是最高風險：

自動化意味著沒有人即時 review
一個錯誤的決策會被自動執行並放大
涉及真實資料和業務邏輯
Debug 難度最高（要理解 AI 的決策鏈）

適合的使用者： 架構師等級。你需要理解整個系統架構、AI 的能力邊界、failsafe 機制的設計。

設計原則：

1. Human-in-the-loop：關鍵決策必須有人確認
2. Graceful degradation：AI 失敗時要有 fallback
3. Audit trail：記錄每一個 AI 的決策和依據
4. Confidence threshold：只在信心度高於閾值時自動執行
5. Circuit breaker：錯誤率過高時自動停止

四個層級的綜合比較

維度	Level 1 自動補全	Level 2 對話助手	Level 3 程式碼代理	Level 4 工作流自動化
風險等級	低	中	高	極高
需要的經驗	初級以上	中級以上	資深以上	架構師
生產力提升	10-30%	20-50%	50-200%	視場景而定
Review 成本	極低（逐行）	中（逐段）	高（整個 PR）	極高（系統行為）
失敗模式	接受錯誤的一行	採用錯誤的方案	產出有缺陷的整個功能	自動執行錯誤決策
回滾難度	低（undo）	中（重寫）	高（多檔案）	極高（影響真實資料）

我的建議：從 Level 1 開始，逐步提升。 每個層級都需要你先具備對應的 review 能力，才能安全使用。跳級使用不會讓你更有生產力，只會讓你更有效率地製造問題。

工具選型原則

市面上的 AI 工具多如牛毛，每個月都有新工具冒出來宣稱「革命性的 AI 開發體驗」。在這種噪音中，你需要一套穩定的選型框架。

1. 先問「解決什麼問題」

最常見的錯誤是「因為工具很酷所以要用」。正確的思考方式是：

我現在的瓶頸是什麼？
→ 瓶頸在寫 boilerplate？用 autocomplete
→ 瓶頸在理解新技術？用 chat assistant
→ 瓶頸在重複性的多檔案修改？用 code agent
→ 瓶頸在手動處理大量資料？用 workflow automation
→ 瓶頸在架構設計？AI 幫不了你，去找 senior 討論

Decision Framework：手動做 → 模板/Snippet → AI 輔助 → AI Agent

在引入 AI 之前，先問自己：

這個任務能用模板或 snippet 解決嗎？（如果可以，不需要 AI）
這個任務有標準答案嗎？（如果有，查文件比問 AI 更可靠）
這個任務需要創造性判斷嗎？（如果需要，AI 只能提供選項，不能替你決定）
這個任務的錯誤成本是什麼？（錯誤成本越高，越不應該完全依賴 AI）

2. 評估 AI 工具的 5 個維度

當你確定需要 AI 工具後，用這五個維度評估：

維度	核心問題	如何評估
準確性	在你的領域，它的正確率有多高？	用你已知答案的問題測試，看它錯幾題
可控性	你能限制它的行為範圍嗎？	能不能設定它只改特定檔案？能不能禁止它執行某些命令？
整合性	能融入現有工作流嗎？	能不能在你的 IDE 裡用？需不需要額外切換視窗？
成本	真正的總成本是多少？	訂閱費 + token 費 + context switching 的時間成本
資安	你的 code 和 data 傳到哪裡了？	它是 cloud-based 還是可以 on-premise？有沒有 data retention policy？

準確性評估方法：

## AI 工具準確性測試清單
 
1. 準備 10 個你領域內的問題，你已經知道正確答案
2. 混合難度：3 個簡單、4 個中等、3 個困難
3. 包含至少 2 個有「常見錯誤答案」的問題
4. 記錄每個問題的回答品質（正確/部分正確/錯誤/hallucination）
5. 特別關注它在「不知道」時的行為：是承認不確定，還是自信地給出錯誤答案？

如果一個 AI 工具在你的領域裡面錯誤率超過 20%，或者在它「不知道」的時候不會承認，那就要非常謹慎使用。

3. 隱藏成本

人們在評估 AI 工具時通常只看訂閱費用。但真正的成本遠不止於此：

Context Switching Cost（上下文切換成本）：

每次你從 coding 模式切換到「跟 AI 對話」模式，再切換回來，都會損失專注力。研究顯示，一次 context switch 的恢復時間約為 10-15 分鐘。如果你每小時切換 4 次，你可能因此損失 40-60 分鐘的深度工作時間。

Review Time（審查時間）：

AI 寫得越多，你需要 review 的就越多。而且 review AI 生成的 code 比 review 人類寫的 code 更難——因為 AI 的 code 缺乏「思考脈絡」，你不知道它為什麼做這個決定，你需要自己推理每一個設計選擇背後的原因。

一個經驗法則：
AI 生成 100 行 code，你至少需要 15-20 分鐘仔細 review。
如果 review 時間 > 你自己寫的時間，那 AI 在這個場景就不划算。

Debugging AI-generated Code（除錯 AI 生成的程式碼）：

AI 生成的 code 有一個特殊的 debug 困難：它看起來「正確」，但隱藏的 bug 可能在邊界條件中。因為 AI 傾向於生成 happy path 的 code，邊界處理往往不完整。

Over-reliance Risk（過度依賴風險）：

持續使用 AI 生成 code 會導致一個隱形的成本：你的基礎能力可能退化。如果你總是讓 AI 幫你寫 SQL，你的 SQL 能力會慢慢下降。這在短期看不出來，但在你需要在沒有 AI 的環境下（面試、production 緊急修復、網路斷線時的 on-call）工作時，問題就會暴露。

工作流整合實務

知道有哪些工具和怎麼選還不夠。關鍵是怎麼把 AI 融入你的日常開發流程，而不是讓它打斷你的流程。

日常開發流程中的 AI 定位

一個健康的 AI 輔助開發流程應該長這樣：

需求理解 [人] → 方案設計 [人+AI] → 核心邏輯 [人] → 樣板程式碼 [AI] → 測試 [AI+人] → 文檔 [AI+人] → Review [人]

讓我解釋每個階段：

需求理解 [人]：

AI 不應該參與需求理解。因為需求涉及業務邏輯、stakeholder 的隱含期待、組織政治、歷史 context——這些都不是 AI 能處理的。你可以用 AI 幫你整理需求文件的格式，但理解本身必須是你做的。

方案設計 [人 + AI]：

你可以用 AI 作為 brainstorming 的夥伴。但注意：

## 正確的用法
「我在設計一個 rate limiter，目前考慮三種方案：
1. Token bucket
2. Sliding window counter
3. Fixed window
使用場景是 API gateway，需要支援每用戶限速。
幫我列出每個方案的 trade-offs。」
 
## 錯誤的用法
「幫我設計一個 rate limiter」
→ AI 會給你一個通用方案，不考慮你的具體約束

核心邏輯 [人]：

你系統中最重要、最複雜的邏輯，應該自己寫。理由很簡單：

這是你最需要深度理解的部分
出 bug 的影響最大
AI 最容易在邊界條件上犯錯
你需要能夠在凌晨三點被叫起來時立刻理解這段 code

樣板程式碼 [AI]：

CRUD endpoint、migration file、config boilerplate、DTO/VO 定義——這些模式化的 code 非常適合讓 AI 生成。因為：

模式固定，AI 正確率高
Review 成本低（你知道正確的 pattern 是什麼）
手動寫的價值低（不需要深度思考）

測試 [AI + 人]：

AI 很擅長生成測試的基本結構和 happy path，但你需要人工補充：

邊界條件
錯誤路徑
併發場景
業務邏輯的特殊規則

// AI 生成的測試（通常只有 happy path）
test('should create user', async () => {
  const result = await createUser({ name: 'John', email: 'john@test.com' });
  expect(result.name).toBe('John');
});
 
// 你需要手動補充的測試
test('should reject duplicate email', async () => { /* ... */ });
test('should handle concurrent creation with same email', async () => { /* ... */ });
test('should validate email format', async () => { /* ... */ });
test('should enforce name length limits', async () => { /* ... */ });
test('should sanitize XSS in name field', async () => { /* ... */ });

文檔 [AI + 人]：

AI 很適合根據 code 生成初版文檔，但你需要：

確認描述的準確性
補充「為什麼」的部分（AI 只能描述「是什麼」）
加入使用範例和注意事項

Review [人]：

Code review 在 AI 時代不是變得不重要，而是變得更重要。因為 AI 生成的 code 可能通過所有表面的檢查（語法正確、格式統一、測試通過）但在架構合理性或安全性上有問題。

The “AI Sandwich” 模式

這是我在日常開發中使用 AI 的核心模式：

Human Decision → AI Execution → Human Review
  （人做決策）     （AI 執行）      （人做審查）

具體來說：

你決定要做什麼、為什麼做、怎麼做
AI 執行機械性的部分——寫 code、跑測試、生成文檔
你審查結果是否正確、是否符合預期

永遠不要反過來——讓 AI 做決策、人做執行。那樣你就只是 AI 的打字員。

Prompt 設計原則

Prompt engineering 不是什麼神秘的技能。它就是清楚地表達你的需求。如果你在職場上能寫出清楚的技術 spec，你就能寫出好的 prompt。

原則一：給 Context，不要只給指令

## 差的 prompt
「寫一個 React component 顯示用戶列表」
 
## 好的 prompt
「在我們的 Next.js 14 專案中（使用 App Router），
寫一個 Server Component 用來顯示用戶列表。
我們使用 Tailwind CSS，UI 元件庫是 shadcn/ui。
資料來源是 Prisma ORM 的 User model。
需要支援分頁（每頁 20 筆）和按 name 搜尋。
現有類似元件可以參考：src/components/ProductList.tsx」

第二個 prompt 為什麼好？因為它提供了：

技術棧 context（Next.js 14, App Router, Server Component）
設計規範（Tailwind, shadcn/ui）
資料來源（Prisma User model）
功能需求（分頁、搜尋）
參考範本（現有的 ProductList）

原則二：告訴它「我們在做什麼」而不是「你是什麼」

許多 prompt guide 建議「tell the AI its role」，例如「你是一個資深 React 開發者」。這不是沒用，但有更好的方法：

## 一般的做法
「你是一個資深前端工程師，請幫我 review 這段 code」
 
## 更好的做法
「我們團隊正在重構 legacy jQuery 前端到 React 18。
目前在處理表單驗證的遷移。
以下是原本的 jQuery 表單驗證邏輯和新寫的 React 版本。
請比較兩者，確認新版本沒有遺漏任何驗證規則，
並指出新版本可能的改進方向。
[貼上兩段 code]」

為什麼第二種更好？因為它給了 AI 足夠的 context 去理解「什麼算好」。光說「你是資深工程師」，AI 不知道你的 context 是什麼——是 startup 的快速迭代，還是銀行的嚴謹規範？

原則三：迭代式 Prompting

不要嘗試一次 prompt 就得到完美結果。正確的方式是迭代：

第一輪：給大方向，看 AI 的理解是否正確
→ 「我想在 API gateway 加一個 request validation middleware」

第二輪：根據 AI 的回答修正方向
→ 「方向對了，但我們用的是 Fastify，不是 Express。
     而且 validation schema 需要從 OpenAPI spec 自動生成」

第三輪：細化需求
→ 「validation 失敗時需要回傳 RFC 7807 Problem Details 格式。
     另外 schema 需要支援 custom format validator。
     幫我完善 error handling 的部分」

第四輪：請求特定改進
→ 「把 validation 邏輯抽成獨立模組，加上單元測試。
     測試需要覆蓋以下邊界條件：[列出]」

每一輪你都在根據 AI 的產出調整方向。這比一次性寫一個超長 prompt 更有效，因為你可以及時修正偏差。

原則四：Prompt 模板化

如果你發現自己反覆寫類似的 prompt，就應該模板化：

## Code Review Prompt Template
我需要你 review 以下 code：
- **語言/框架：** [填入]
- **功能描述：** [填入]
- **重點關注：** [效能 / 安全 / 可讀性 / 正確性]
- **Context：** [相關的業務邏輯或限制]
 
請從以下角度 review：
1. 邏輯正確性（是否有邊界條件未處理）
2. 安全性（是否有注入、未授權存取等風險）
3. 效能（是否有 N+1, 不必要的計算, 記憶體洩漏）
4. 可維護性（命名是否清楚, 是否過度複雜）
5. 測試建議（哪些場景需要測試）
 
[貼上 code]

把這些模板存在你的筆記系統裡，需要時直接套用。

Skills / Instructions 設計

現代的 AI coding 工具（如 Claude Code 的 CLAUDE.md、Cursor 的 .cursorrules、Cline 的 .clinerules）支援一種叫做「instructions」或「skills」的機制。這些是預先定義好的指令集，讓 AI 在每次對話中都自動遵循。

什麼是 Skills / Instructions

簡單來說，它們是「AI 的行為規範檔案」。你可以在專案根目錄放一個設定檔，告訴 AI：

我們的 coding style 是什麼
我們使用哪些技術棧
有哪些禁止的做法
錯誤處理的標準格式是什麼
測試的要求是什麼

# CLAUDE.md 範例
 
## 專案資訊
- 這是一個 Next.js 14 專案，使用 App Router
- 語言：TypeScript (strict mode)
- 套件管理：pnpm
- 測試框架：Vitest + Testing Library
- CSS：Tailwind CSS + shadcn/ui
 
## Coding Standards
- 使用 functional components，不使用 class components
- 所有元件使用 named export，不使用 default export
- 錯誤處理使用 Result pattern（不使用 try-catch 作為流程控制）
- API 回應使用 standardized response format（見 src/lib/api-response.ts）
 
## 禁止事項
- 不要使用 any type
- 不要使用 console.log（使用 src/lib/logger.ts）
- 不要直接存取 process.env（使用 src/config/env.ts）
- 不要使用 relative import path（使用 @/ alias）
 
## 測試要求
- 每個功能都要有測試
- 最少覆蓋：happy path、error path、邊界條件
- Mock 只 mock 外部相依，不 mock 內部模組

如何寫有效的 Instructions

好的 instruction 有以下特徵：

具體而非抽象： 「使用 camelCase」而非「使用合適的命名規範」
有範例： 附上正確和錯誤的例子
可驗證： AI 和 reviewer 都能檢查是否遵循
有理由： 解釋為什麼有這個規則（AI 理解 why 後更容易正確遵循）

## 差的 instruction
「寫好的 code」
 
## 好的 instruction
「所有的 async function 呼叫必須有 error handling。
使用 Result<T, E> pattern，不要使用 try-catch 作為流程控制。
 
✅ 正確：
const result = await getUserById(id);
if (result.isErr()) {
  return ApiResponse.error(result.error);
}
const user = result.value;
 
❌ 錯誤：
try {
  const user = await getUserById(id);
} catch (e) {
  // ...
}
 
原因：Result pattern 讓錯誤處理變成 type-safe 的，
compiler 會強制你處理所有錯誤路徑。」

Instructions 的版本控制

Instructions 和 skills 應該跟 code 一起版本控制：

project-root/
├── CLAUDE.md              # AI 行為規範
├── .cursorrules            # Cursor 專用規則
├── .github/
│   └── copilot/
│       └── instructions.md # Copilot 專用指令
├── prompts/                # 可重用的 prompt 模板
│   ├── code-review.md
│   ├── bug-fix.md
│   └── new-feature.md
└── ...

這樣做的好處：

團隊共享同一套標準
變更有 history 可追蹤
新成員加入時自動套用
可以在 PR 中 review instruction 的變更

團隊層級的 Prompt 標準

在團隊中推行 AI 工具時，建議建立以下標準：

## 團隊 AI 使用規範
 
### 必須
- 所有 AI 生成的 code 必須經過人工 review
- 涉及安全相關的 code（auth, 加密, 權限）不得使用 AI 生成
- AI 生成的測試必須人工確認覆蓋了所有邊界條件
 
### 建議
- 使用共享的 instructions 檔案確保一致性
- 重要的 prompt 記錄在團隊知識庫中
- 定期分享 AI 使用的心得和陷阱
 
### 禁止
- 不得將包含客戶資料的 code 傳給雲端 AI
- 不得讓 AI 直接操作 production 環境
- 不得跳過 code review 直接 merge AI 生成的 PR

為什麼基礎知識不可或缺

這是本文最重要的部分。我在前言已經說過結論，現在讓我深入解釋。

AI 不會告訴你的事

LLM 有一個根本性的問題：它不知道自己不知道什麼。

當你問它一個超出它訓練資料的問題，它不會說「我不知道」。它會生成一個「看起來合理」的答案——因為它的目標函數就是生成「聽起來最像正確答案」的文字。這就是 hallucination。

而且，hallucination 不是 bug，它是 LLM 運作方式的必然結果。

LLM 的工作方式（極度簡化版）：
1. 收到輸入
2. 在它見過的所有文本中找到「最相關的模式」
3. 根據這些模式生成「最可能的下一個 token」
4. 重複步驟 3 直到產出完成

它沒有一個內部機制去判斷「我正在生成的東西是否正確」。
它只是在做統計上的模式匹配。

這意味著什麼？

AI 優化的是「聽起來對」，不是「真的對」。

這在你有專業知識時沒什麼問題——你可以輕鬆分辨「聽起來對但其實錯」的回答。但如果你沒有專業知識，你就無法分辨。

你需要什麼知識才能有效使用 AI

以下是一個具體的對照表：

任務	你需要的背景知識	沒有這些知識時 AI 會犯的錯
AI 寫 REST API	HTTP 方法語義、認證機制、錯誤處理標準、版本策略	所有操作都用 POST、token 放 URL、錯誤回 200 但 body 裡寫 error
AI 寫 SQL	Normalization、索引策略、N+1 問題、transaction isolation	單一巨表、沒有 index、SELECT * everywhere、no transaction
AI 寫測試	測試金字塔、邊界條件、mock 策略、test isolation	只測 happy path、過度 mock、測試間互相依賴、false positive
AI 做 Infra	網路架構、安全群組、IAM、成本優化	開放所有 port、用 root access key、選最貴的 instance type
AI 做 Design	UX 原則、accessibility、responsive design	好看但無法使用、沒有 keyboard support、手機上排版爆掉
AI 寫效能優化	Profiling、Big O、瀏覽器渲染管線	在錯誤的地方優化、premature optimization、cache 但沒有 invalidation strategy

The Dunning-Kruger Problem with AI

Dunning-Kruger 效應指的是：能力越低的人，越傾向高估自己的能力。AI 把這個問題放大了十倍。

在沒有 AI 的時代，一個初學者寫出有問題的 code 至少會意識到「我可能寫得不太對」——因為寫的過程中他感到困難和不確定。

但有了 AI，同一個初學者會在 30 秒內得到一段「看起來完美」的 code。他沒有經歷困難和不確定的過程，所以他更傾向於相信這段 code 是正確的。AI 消除了「不確定感」這個重要的安全閥。

沒有 AI 的初學者：
「我不太確定這樣寫對不對...讓我查一下文件...問一下同事...」
→ 至少有機會在上線前發現問題

有 AI 的初學者：
「AI 寫的欸，應該沒問題吧」→ 直接部署 → production 出事

這不是假設性的場景。這是每天都在發生的事情。

知識是一個 spectrum，不是 binary

我不是說你需要成為每個領域的專家才能用 AI。我是說你需要足夠的知識來判斷 AI 產出的品質。

這個「足夠」的定義取決於風險：

寫一個內部工具的 UI → 你只需要知道基本的 React，
                      AI 搞錯了也不會有太大影響

寫一個金流系統的核心邏輯 → 你需要深度理解支付流程、
                          雙重支付防護、對帳機制、退款處理
                          AI 搞錯了可能損失真金白銀

風險越高的任務，你需要越深的領域知識。

團隊層面的 AI 策略

AI 工具的導入不只是個人決定，在團隊層面更需要策略思維。

AI 工具標準化 vs 個人自由

這是一個常見的辯論：團隊應該統一使用相同的 AI 工具，還是讓每個人自由選擇？

我的建議是標準化基線，自由選擇加強：

## 標準化（團隊必須統一）
- Instructions / rules 檔案（CLAUDE.md, .cursorrules 等）
- Code review 標準（AI 生成的 code 的 review checklist）
- 安全政策（什麼可以傳給 cloud AI，什麼不行）
- 測試要求（AI 生成的 code 需要多少測試覆蓋）
 
## 自由選擇（個人偏好）
- 用 Copilot 還是 Cursor 還是 Codeium
- 用 ChatGPT 還是 Claude
- IDE 設定和快捷鍵
- 個人的 prompt 風格

為什麼？因為 instructions 和安全政策影響的是團隊的 code quality baseline，必須統一。但具體用什麼工具、怎麼跟 AI 互動，是個人工作習慣，不需要也不應該統一。

Code Review 在 AI 時代的重要性

我要說一個可能違反直覺的觀點：AI 時代的 code review 應該比以前更嚴格，而不是更寬鬆。

原因：

AI 生成的 code 數量更多——一個工程師一天可能產出比以前多 3-5 倍的 code。review 不能因為量大就馬虎。
AI 生成的 code 更隱蔽——它語法正確、格式工整、命名合理，表面上看起來沒問題。問題往往藏在邏輯層面，需要更深入的 review。
AI 不理解業務 context——它可能生成了一個技術上正確但業務上錯誤的實作。只有理解業務的人才能發現這種問題。
AI 不考慮全局——它可能在這個 function 裡做了正確的事，但跟其他模組的互動方式不一致，或者引入了不必要的耦合。

建議的 review checklist：

## AI-Generated Code Review Checklist
 
### 基本檢查
- [ ] 是否有安全漏洞（injection, auth bypass, data leak）
- [ ] 錯誤處理是否完整
- [ ] 邊界條件是否有處理
 
### 架構檢查
- [ ] 是否符合專案的架構 pattern
- [ ] 是否引入了不必要的依賴
- [ ] 是否跟現有 code 風格一致
 
### 業務邏輯檢查
- [ ] 是否正確實作了需求
- [ ] 是否有遺漏的 edge case（從業務角度）
- [ ] 是否考慮了 backward compatibility
 
### 測試檢查
- [ ] 測試是否覆蓋了核心邏輯
- [ ] 測試是否包含 error path
- [ ] 測試是否有 false positive 的風險
 
### 效能檢查
- [ ] 是否有 N+1 query
- [ ] 是否有不必要的重複計算
- [ ] 是否有記憶體洩漏風險

知識傳承的挑戰

AI 加速了程式碼的產出，但也加速了一個問題：工程師不理解自己程式碼庫中的 code。

在 AI 之前，一段 code 是某個工程師寫的，他理解為什麼這樣寫。當他離職或轉調時，知識可以通過 code review、pair programming、文檔來傳承。

在 AI 之後，一段 code 可能是 AI 生成、人類 approve 的。approve 的人可能理解也可能只是粗略看了一眼。當他離職後，下一個人面對的是一段「沒有人真正理解的 code」。

應對策略：

1. AI 生成的 code 必須附上設計決策的註解（不是「what」而是「why」）
2. 複雜邏輯需要有 ADR（Architecture Decision Record）
3. 定期的 code walkthrough——team member 輪流講解自己負責的模組
4. 鼓勵 pair programming，尤其是使用 AI 工具時
5. 新人 onboarding 不能只是「AI 幫你生成就好」

教團隊「如何使用 AI」

最後，引入 AI 工具時，不要只教「用什麼工具」，要教「怎麼用」：

## AI 工具培訓內容
 
### 基礎（所有成員）
- AI 的能力與侷限（什麼能做，什麼不能做）
- Hallucination 的識別與防範
- 資安意識（什麼可以傳給 AI，什麼不行）
- 基本的 prompt 技巧
 
### 進階（中級以上成員）
- Instructions / Skills 的撰寫與維護
- Code agent 的安全使用
- AI 輔助 code review 的方法
- AI 輔助測試的策略
 
### 高級（資深成員）
- AI workflow 自動化的設計
- 評估新 AI 工具的框架
- 團隊 AI 策略的制定
- AI 相關風險的管理

我的工具推薦（2024-2025）

以下是我個人目前的工具選擇，按使用場景分類。注意：AI 工具變化極快，這些推薦可能在你閱讀時已經過時。重要的是背後的選型邏輯，而不是具體的工具名稱。

程式碼補全

工具	優點	缺點	推薦場景
GitHub Copilot	生態系最成熟、VS Code 整合最好	有時建議不夠精準	日常開發、大多數語言
Cursor Tab	在 Cursor IDE 中體驗最好	綁定 Cursor IDE	如果你用 Cursor
Supermaven	速度快、延遲低	生態系較小	對延遲敏感的場景

對話助手

工具	優點	缺點	推薦場景
Claude	長文理解力強、code review 品質高、回答結構化	有時過於謹慎	Code review、架構討論、寫文檔
ChatGPT	通用能力強、插件生態豐富	Code 品質不如 Claude 穩定	通用問答、brainstorm
Gemini	Google 生態整合	相對較新	Google Cloud 相關開發

程式碼代理

工具	優點	缺點	推薦場景
Claude Code	終端介面、強大的 code 理解力	需要 API key	重構、多檔案修改
Cursor Agent	IDE 內建、操作直覺	有時範圍控制不佳	日常開發中的 agent 任務

工作流自動化

工具	優點	缺點	推薦場景
n8n	開源、self-hosted、視覺化流程	學習曲線	業務流程自動化
LangChain	彈性高、社群活躍	過度工程化的風險	自訂 AI pipeline

寫作

工具	優點	缺點	推薦場景
Claude	中文品質高、理解能力強	有時太冗長	技術文件、部落格、文檔

聲明： 以上推薦基於我的個人經驗和使用場景。每個人的需求不同，建議用前面提到的「5 個維度評估法」自行評估。工具選型沒有標準答案，只有最適合你的答案。

常見問題與風險

Over-reliance（過度依賴）

問題： 太依賴 AI 導致基礎能力退化。

徵兆：

不查文件，直接問 AI
不思考解法，直接讓 AI 生成
離開 AI 就不知道怎麼寫 code
無法在白板上徒手設計系統架構

應對：

1. 定期進行「無 AI 日」——一個月至少一天不用任何 AI 工具
2. 核心邏輯手動寫，AI 只用在 boilerplate
3. 持續學習基礎（資料結構、演算法、設計模式、系統設計）
4. 參加 code review 時不借助 AI，用自己的判斷力

Security（安全性）

問題： 將機密 code 或資料傳送給雲端 AI 服務。

風險等級：

低風險：開源程式碼、通用技術問題
中風險：內部業務邏輯、API 設計
高風險：認證/授權邏輯、加密實作
極高風險：客戶資料、密碼、API key、production config

應對：

1. 建立分類標準：什麼可以傳、什麼不行
2. 使用有 data retention policy 的工具
3. 考慮 self-hosted / on-premise 方案
4. 永遠不要傳 .env、credentials、certificate
5. 使用前檢查工具的 Terms of Service

License Concerns（授權疑慮）

問題： AI 模型訓練於 GPL / AGPL 等 copyleft 授權的程式碼，生成的 code 是否構成衍生作品？

現狀：

法律上尚無定論
GitHub Copilot 曾因此被集體訴訟
部分企業因此禁止使用某些 AI 工具

應對：

1. 了解你的公司的法務立場
2. 對 AI 生成的 code 做 originality check（如果有工具的話）
3. 避免讓 AI 直接複製大段開源程式碼
4. 將 AI 視為「啟發」而非「來源」——理解邏輯後自己重寫

Cost Management（成本管理）

問題： AI 工具的成本可能超出預期，尤其是 API-based 的按量計費模式。

## 成本控管建議
 
1. 設定每月預算上限
2. 追蹤 token 使用量——了解哪些任務消耗最多
3. 使用合適的模型等級：
   - 簡單任務用便宜的模型（GPT-4o-mini, Claude Haiku）
   - 複雜任務用強力的模型（GPT-4o, Claude Opus）
4. 避免不必要的 context（每次送太多 code 給 AI 會增加 token 消耗）
5. 團隊共享帳號 vs 個人帳號的利弊分析

結語：AI 是工具，你是工程師

回到本文的核心觀點：

AI 是力量放大器，不是替代品。

你的領域知識決定了 AI 能幫你做什麼
你的判斷力決定了 AI 的產出品質
你的經驗決定了你能從 AI 中獲得多少價值

不要因為 AI 很強就跳過學習基礎的過程。基礎知識不會因為 AI 的存在而變得不重要——相反，它變得更重要了，因為它是你有效使用 AI 的前提。

一個知道「正確答案長什麼樣子」的人，加上 AI，是無敵的。一個不知道「正確答案長什麼樣子」的人，加上 AI，是災難的。

投資在你自己的知識上。AI 工具會持續進化、持續更換，但你的專業知識和判斷力，才是真正不可替代的資產。

Proto 實踐對照

AI 工具在 Proto 開發中的應用：使用 Claude Code / Cursor 加速 boilerplate 生成和 test writing，但核心架構決策仍由人類做出。AI 最適合處理 Proto 中重複性高的工作（如 CRUD 範例生成、測試案例撰寫、文件更新）。詳見 AI 工具比較和 AI 輔助開發工具。

Terry Yao's Blog

分類

目錄

[methodology] AI 工具選型與工作流

AI 工具選型與工作流

文章概覽

前言：AI 不是魔法

垃圾進、垃圾出的現實

AI 失敗的真實案例

AI 工具分類

Level 1：自動補全（Autocomplete）

Level 2：對話助手（Chat Assistant）

Level 3：程式碼代理（Code Agent）

Level 4：工作流自動化（Workflow Automation）

四個層級的綜合比較

工具選型原則

1. 先問「解決什麼問題」

2. 評估 AI 工具的 5 個維度

3. 隱藏成本

工作流整合實務

日常開發流程中的 AI 定位

The “AI Sandwich” 模式

Prompt 設計原則

原則一：給 Context，不要只給指令

原則二：告訴它「我們在做什麼」而不是「你是什麼」

原則三：迭代式 Prompting

原則四：Prompt 模板化

Skills / Instructions 設計

什麼是 Skills / Instructions

如何寫有效的 Instructions

Instructions 的版本控制

團隊層級的 Prompt 標準

為什麼基礎知識不可或缺

AI 不會告訴你的事

你需要什麼知識才能有效使用 AI

The Dunning-Kruger Problem with AI

知識是一個 spectrum，不是 binary

團隊層面的 AI 策略

AI 工具標準化 vs 個人自由

Code Review 在 AI 時代的重要性

知識傳承的挑戰

教團隊「如何使用 AI」

我的工具推薦（2024-2025）

程式碼補全

對話助手

程式碼代理

工作流自動化

寫作

常見問題與風險

Over-reliance（過度依賴）

Security（安全性）

License Concerns（授權疑慮）

Cost Management（成本管理）

結語：AI 是工具，你是工程師

Proto 實踐對照

延伸閱讀

關係圖譜

反向連結