領域知識不可或缺、團隊策略與風險管理
一句話總結：AI 不知道自己不知道什麼。你的領域知識決定了 AI 能幫你做什麼。團隊導入 AI 要標準化基線、自由選擇工具。
結論先講：一個知道「正確答案長什麼樣子」的人加上 AI 是無敵的。一個不知道的人加上 AI 是災難的。投資在你自己的知識上——AI 工具會持續更換，但你的專業知識才是真正不可替代的資產。
AI 不會告訴你的事
LLM 有一個根本性的問題：它不知道自己不知道什麼。
當你問它超出訓練資料的問題，它不會說「我不知道」。它會生成一個「看起來合理」的答案——因為它的目標是生成「聽起來最像正確答案」的文字。Hallucination 不是 bug，是 LLM 運作方式的必然結果。
AI 優化的是「聽起來對」，不是「真的對」。
你有專業知識時，可以輕鬆分辨「聽起來對但其實錯」的回答。沒有專業知識？你無法分辨。
你需要什麼知識才能有效使用 AI
| 任務 | 需要的背景知識 | 沒有這些知識時 AI 會犯的錯 |
|---|---|---|
| 寫 REST API | HTTP 方法語義、認證、錯誤處理 | 所有操作用 POST、token 放 URL |
| 寫 SQL | Normalization、索引、N+1 | 單一巨表、沒 index、SELECT * |
| 寫測試 | 測試金字塔、邊界條件、mock 策略 | 只測 happy path、過度 mock |
| 做 Infra | 網路架構、安全群組、IAM | 開放所有 port、用 root key |
| 做效能優化 | Profiling、Big O、渲染管線 | 在錯誤的地方優化 |
Dunning-Kruger + AI = 災難
Dunning-Kruger 效應：能力越低的人越傾向高估自己的能力。AI 把這個問題放大了十倍。
沒有 AI 的初學者寫有問題的 code 時，至少會意識到「我可能寫得不太對」——因為寫的過程中感到困難和不確定。有了 AI，同一個初學者 30 秒得到一段「看起來完美」的 code，沒有經歷困難和不確定的過程，更傾向相信 code 是正確的。
AI 消除了「不確定感」這個重要的安全閥。
風險越高的任務，你需要越深的領域知識。寫內部工具 UI？基本的 React 就夠了，搞錯影響不大。寫金流系統核心？你需要深度理解支付流程、雙重支付防護、對帳機制——AI 搞錯可能損失真金白銀。
團隊 AI 策略
標準化基線，自由選擇加強：
| 標準化（團隊統一） | 自由選擇（個人偏好） |
|---|---|
| Instructions 檔案（CLAUDE.md 等） | 用 Copilot 還是 Cursor |
| Code review 標準 | 用 ChatGPT 還是 Claude |
| 安全政策（什麼可以傳給 AI） | IDE 設定和快捷鍵 |
| 測試要求 | 個人 prompt 風格 |
為什麼？Instructions 和安全政策影響團隊的 code quality baseline，必須統一。具體工具和互動方式是個人工作習慣，不需要也不應該統一。
AI 時代的 Code Review 更嚴格
一個可能違反直覺的觀點：AI 時代的 code review 應該更嚴格，不是更寬鬆。
- AI 生成的 code 量更多——review 不能因為量大就馬虎
- AI 的 code 更隱蔽——語法正確、格式工整，問題藏在邏輯層
- AI 不理解業務 context——技術正確但業務錯誤
- AI 不考慮全局——function 內正確但跟其他模組互動不一致
知識傳承的挑戰
AI 加速了 code 產出，也加速了一個問題：工程師不理解自己程式碼庫中的 code。
以前，一段 code 是某個工程師寫的，他理解為什麼這樣寫。離職時知識可以通過 review、pair programming、文檔傳承。
AI 時代，一段 code 可能是 AI 生成、人類 approve 的。approve 的人可能只是粗略看了一眼。他離職後，下一個人面對的是一段「沒有人真正理解的 code」。
應對：AI 生成的 code 要附設計決策註解（why not what）、複雜邏輯要 ADR、定期 code walkthrough、鼓勵 pair programming。
四大風險
Over-reliance（過度依賴）： 徵兆是不查文件直接問 AI、離開 AI 不會寫 code、無法在白板上設計架構。每月至少一天「無 AI 日」。
Security（安全性）： 低風險是開源程式碼和通用問題。高風險是認證/加密邏輯。極高風險是客戶資料、密碼、API key。建立分類標準，永遠不傳 .env 和 credentials。
License（授權）： AI 模型訓練於 GPL/AGPL code，生成的 code 是否構成衍生作品？法律上尚無定論。了解公司法務立場，將 AI 視為「啟發」而非「來源」。
Cost（成本）： 設每月預算上限。簡單任務用便宜模型，複雜任務用強力模型。避免不必要的 context（送太多 code 增加 token 消耗）。
系列總結
AI 是力量放大器，不是替代品。你的領域知識決定了 AI 能幫你做什麼。AI Sandwich（人決策 → AI 執行 → 人審查）是正確的使用模式。Prompt 和 Instructions 就是清楚表達需求。團隊策略標準化基線、自由選擇工具。
投資在你自己的知識上。AI 工具會持續進化、持續更換，但你的專業知識和判斷力，才是真正不可替代的資產。
系列文章：
- AI 工具選型（一）：AI 是力量放大器
- AI 工具選型（二）：Code Agent 與工具選型
- AI 工具選型（三）：工作流整合實務
- AI 工具選型（四）：Prompt 與 Instructions 設計
- 你在這裡 → AI 工具選型（五）：領域知識、團隊策略與風險
延伸閱讀：
「AI 時代最值錢的不是會用 AI 的人，是知道 AI 什麼時候在唬爛的人。」