作為前端平台負責人和 8 人團隊的技術 leader，2024 年是技術決策密度最高的一年。不聊具體技術細節，聊聊技術管理層面的思考和實踐。
技術選型：什麼時候該用新技術
今年面臨的選擇：React 19 要不要上？Vue 3.5 還是等一等？Biome 替不替換 ESLint？Svelte 5 要不要試？
我們的決策框架：
項目重要性
高 低
技術成熟度 高 立即採用 下個迭代考慮
低 小範圍試用 先觀望
具體案例
Biome → 立即採用。成熟度高（1.0+），替換成本可控，收益明確（構建速度提升 20 倍）。團隊花了一週完成遷移。
React 19 → 小範圍試用。Beta/RC 階段在內部工具項目上試用，主產品等到穩定版。useActionState 確實好用，但 API 還在變化。
Svelte 5 → 觀望。雖然 Runes 概念優秀，但我們團隊沒有 Svelte 項目。只在技術分享中介紹，不投入項目。
AI 輔助開發 → 立即採用。GitHub Copilot + 自建 Code Review Bot，投入產出比極高。
團隊管理：技術債和新功能的平衡
每週 sprint 的時間分配：
新功能開發：40%
技術債償還：20%
Bug 修復：20%
技術探索：10%
Code Review + 分享：10%
技術債管理
建立技術債看板，每個技術債條目需要：
- 影響描述：不修復會怎樣
- 工作量評估：粗略估時
- 優先級標籤：P0（阻塞發佈）/ P1（影響性能）/ P2（影響體驗）
P0 納入當前迭代，P1 每迭代處理 1-2 個，P2 集中處理。
20% 時間制度
每週五下午是技術探索時間。今年從探索中落地的項目：
- AI Code Review Bot → 生產環境使用
- Biome 遷移 → 全團隊推廣
- RAG 內部知識庫 → 上線
探索不一定要落地，但落地的要有產出跟蹤。
AI 工具的團隊推廣
Copilot 推廣路徑
- 前兩週：自願試用，收集反饋
- 第三週：分享最佳實踐（什麼時候用、什麼時候不用）
- 第四周：全員標配，納入開發環境
使用規範
✅ 適合用 AI 的場景：
- 樣板代碼生成
- 單元測試編寫
- 類型定義推導
- 重複性重構
❌ 不適合用 AI 的場景：
- 核心業務邏輯
- 安全相關代碼
- 性能關鍵路徑
- 架構設計決策
架構演進節奏
不要一次性做太多改變。我們的策略是每個季度最多引入 1 個大的技術變更：
Q1：Biome 替換 ESLint + Prettier
Q2：RAG 知識庫上線
Q3：React 19 新特性試點
Q4：Next.js 15 遷移規劃
太多變更同時進行會讓團隊疲於奔命，也增加出 bug 的風險。
向上管理：技術價值的傳達
給 CTO/VP 彙報時，技術決策要翻譯成業務語言：
❌ "我們用了 Biome 替換 ESLint，Rust 寫的，速度快 20 倍"
✅ "構建速度提升 20 倍，CI 時間從 8 分鐘降到 30 秒，
每天為團隊節省約 1 小時等待時間"
❌ "我們做了 RAG 應用，用了向量數據庫和 embedding"
✅ "內部知識庫的文檔查找效率提升 3 倍，
新人上手時間從 2 周縮短到 1 周"
小結
- 技術選型用成熟度 × 項目重要性矩陣決策
- 每季度最多引入 1 個大的技術變更
- 技術債用看板管理，P0/P1/P2 分級處理
- AI 工具推廣需要漸進式 + 使用規範
- 技術價值要翻譯成業務語言向上彙報
- 20% 探索時間需要平衡自由度和產出追蹤