免責聲明
此框架被精心設計為一個緊密結合的系統。部分採用可能產生非預期或適得其反的結果。
實踐範圍說明
本文牽涉的流程與提案只有部分在某產品經過實例驗證。與組織或其他產品相關的流程，撰文者團隊沒有權限作出改動，因此僅為理論性建議。
需要管理層決策
本白皮書指出 22 項需要高層管理者決定的事項。若管理層認為這些建議執行上有困難卻未向團隊諮詢如何做長期規劃，或單方面決定不實施這些變革而只是開通 AI 工具帳號，我們建議完全不要導入 AI 工作流程，維持現有做法反而更好。
管理決策概覽
以下決策在導入 AI 工作流程前需要管理層審視並規劃：
1. 流程變更（4 項決策）
2. 資源配置與投資（4 項決策）
3. 政策決策（3 項決策）
4. 培訓與技能發展（2 項決策）
5. 工具與基礎設施（6 項決策）
- 設計系統 - 採用 shadcn/ui 並整合 MCP
- 多產品規格管理 - 階層式規格系統
- 代理知識庫 - Git-based Markdown 知識系統
- 全域需求庫 - 以產品為中心的需求組織
- 技術雷達與路線圖 - 技術治理系統
- 通用語言 - 標準化術語
6. 文化變革（3 項決策）
- C3：最佳實踐對齊 - 採用既定模式
- C4：不重新發明標準 - 遵循權威來源
- C5：協調的 AI 回饋迴路 - 慷慨分享知識
最小可行採用指南
24 項不是 Day 1 全部要決定
這些決策分散在整個轉型過程中。以下指南幫助你理解何時需要做出哪些決策。如果無法完整採用，請先與團隊諮詢，共同評估哪些部分適合你的組織現況。
必要決策（8 項）
如果只能做 8 件事，以下是啟動 AI 工作流程的必要決策：
| # | 決策 | 決策者 | 時機 |
|---|---|---|---|
| 1 | 高層承諾 - 確認組織願意投入資源與時間進行轉型 | CEO/VP | Day 0 |
| 2 | 選定試點團隊 - 指定 1-2 個團隊進行首次試點 | VP Engineering | Day 0 |
| 3 | 配置學習時間 - 決定 Sprint 中用於學習的比例（建議 10-20%） | 部門主管 | Phase 1 |
| 4 | 建立 CLAUDE.md 標準 - 定義專案級 AI 指引文件的格式與維護責任 | Tech Lead | Phase 1 |
| 5 | 定義審查流程 - 建立 AI 生成程式碼的審查標準與流程 | Tech Lead | Phase 1 |
| 6 | 建立回饋收集機制 - 定期收集試點團隊的問題與改進建議 | 專案負責人 | Phase 1 |
| 7 | 選定設計系統方向 - 決定是否採用 shadcn/ui 或其他方案 | 前端負責人 | Phase 2 |
| 8 | 建立通用語言詞彙表 - 開始整理跨團隊的術語標準 | PM + Tech Lead | Phase 2 |
分階段決策時程
| 階段 | 時機 | 決策類別 | 決策數量 |
|---|---|---|---|
| Day 0 | 決定導入前 | 高層承諾、試點選定 | 2 項 |
| Phase 1 | Q1 基礎建設 | 培訓政策、審查流程、工具標準 | 4 項 |
| Phase 2 | Q2 試點期 | 設計系統、通用語言 | 2 項 |
| Phase 3 | Q3+ 擴展期 | 組織結構、角色轉型、文化變革 | 其餘 |
決策依賴關係
階段門檻檢查
在進入下一階段前，確認以下問題已有答案：
Day 0 → Phase 1：
- [ ] 高層是否明確承諾支持轉型？
- [ ] 試點團隊是否已選定且願意參與？
- [ ] 是否有專人負責推動此計畫？
Phase 1 → Phase 2：
- [ ] 團隊是否完成基礎培訓（脈絡工程、規格撰寫）？
- [ ] 審查流程是否已建立並運作？
- [ ] CLAUDE.md 標準是否已定義？
Phase 2 → Phase 3：
- [ ] 試點是否產出具體成果？
- [ ] 團隊回饋是否已收集並分析？
部分採用的風險
本白皮書中的提案和原則是刻意相互關聯的。它們處理同一個根本挑戰的不同面向：在軟體開發中實現有效的人機協作。採用孤立的片段而缺少其支撐元素，可能會製造新問題而非解決現有問題。
失敗情境
情境 1：採用 AI 工具但沒有治理機制
發生的情況： 團隊採用 AI 編程助手，但未建立指導原則或適當的審查機制。
結果：
- 品質不一致的 AI 生成程式碼進入生產環境
- 技術債累積速度比以前更快
- 團隊完全失去對 AI 工具的信任
情境 2：規格驅動開發但沒有脈絡工程
發生的情況： 組織強制要求規格文件，但未實施脈絡工程實踐或通用語言。
結果：
- 規格成為額外的行政負擔而非 AI 可消費的脈絡
- AI 代理無法有效使用結構不良的規格
- 團隊退回臨時溝通方式，規格變得過時
情境 3：組織扁平化但沒有流程變革
發生的情況： 管理層縮減組織層級，但沒有相應的工作流程框架。
結果：
- 少了中階主管但沒有替代機制，遇到問題不知道找誰決定
- 沒有橫向協調機制，知識孤島依然存在
- 團隊感到缺乏支援而非被賦能
情境 4：設計系統但沒有 AI 優化
發生的情況： 團隊按照傳統模式建構設計系統，而未考慮 AI 可發現性。
結果：
- AI 或人類繼續建立重複的元件
- 設計系統成為另一個 AI 找不到的文件
- 花了資源建設計系統，AI 生成的程式碼品質卻沒改善
警示信號
| 症狀 | 可能原因 |
|---|---|
| 「AI 讓事情變得更糟」 | 缺少品質控制或審查機制 |
| 「規格只是額外負擔」 | 缺少脈絡工程或 AI 友善格式 |
| 「沒人遵循流程」 | 缺少組織對齊或激勵機制 |
| 「AI 一直犯同樣的錯誤」 | 缺少持續脈絡清理或指引文件 |
| 「團隊比以前更加孤立」 | 缺少橫向協調結構 |
忽視決策的後果
如果組織只開通 AI 工具帳號而不處理這些決策：
- 脈絡污染加速 - AI 從散落的文件產生不一致的輸出
- 品質下降 - 缺乏適當審查的 AI 生成程式碼引入缺陷
- 技術債加速累積 - AI 產生程式碼的速度超過組織審查/維護的能力
- 角色混淆 - 當 AI 處理執行工作時，傳統職責變得不明確
- 團隊挫折 - 員工在缺乏適當培訓、支援和明確期望下掙扎
AI 工具本身不是轉型。組織變革才是。
結論
此框架反映撰文者多年的觀察，關於什麼能夠實現有效的人機協作。這些相互關聯不是偶然的——它們反映了透過實踐發現的真實依賴關係。
在認定任何元素為不必要之前，請問：
- 這個元素解決什麼問題？
- 哪些其他元素依賴於它？
- 如果我們跳過它，什麼會填補這個空缺？
部分採用是可能的，但必須是審慎且知情的。理解你選擇不採用的內容，並為你製造的空缺準備替代方案。
返回： 概述