2024 年，AI 工具已經從"可選"變成"必要"了。整理一下我目前的 AI 輔助開發工作流。
工具矩陣
| 工具 | 用途 | 我的使用頻率 | | ----------------- | ---------------------- | ------------ | | GitHub Copilot | 代碼補全 | 每天 | | Claude 3.5 Sonnet | 複雜問題分析、架構討論 | 每天 | | ChatGPT-4o | 快速答疑、內容生成 | 每週 | | Cursor | AI 原生編輯器 | 新項目嘗試中 | | v0.dev | UI 原型生成 | 每月 |
代碼生成：從提示詞到可用代碼
提示詞質量決定輸出質量。
差的提示詞：
"幫我寫一個列表組件"
好的提示詞：
"用 React 18 + TypeScript 寫一個商品列表組件：
- Props：items: Product[]（Product 有 id, name, price, image, inStock 字段）
- 支持加載狀態（skeleton loading）
- 支持空狀態
- 每個 item 有'加入購物車'按鈕，inStock 為 false 時禁用
- 用 Tailwind CSS 樣式，響應式：1列→2列→4列
- 點擊卡片觸發 onSelect 回調"
用具體的類型、約束、交互要求，AI 才能給出接近可用的代碼。
我的日常工作流
1. 早晨規劃（5分鐘）
把今天的任務告訴 Claude，讓它幫我拆分任務、識別依賴、估時間。不是為了讓 AI 替我規劃，而是用對話的方式理清思路。
2. 寫代碼時（持續）
- 樣板代碼 → Copilot 自動補全
- 算法邏輯 → 先自己想，卡住了問 Claude
- 類型定義 → Copilot 補全 + 自己審查
- 正則表達式 → 直接讓 AI 生成
- SQL 查詢 → AI 草稿 + 自己優化
3. Code Review 前（每次提 PR）
把 diff 粘給 Claude，問：
- 有沒有潛在的安全問題？
- 有沒有明顯的性能問題？
- 有沒有邊界條件沒處理？
- 代碼可讀性如何？
不是讓 AI 替代 Review，而是先自檢
4. Debug（有時）
把錯誤棧和相關代碼給 AI，通常能快速定位方向。但 AI 有時會給出自信但錯誤的答案，要保持懷疑。
AI 的侷限：必須自己處理的
業務邏輯：AI 不瞭解你的產品需求，決策要自己做。
安全性：AI 生成的代碼可能有安全漏洞（SQL 注入、XSS、IDOR），必須自己審查。
typescript
// AI 可能生成這樣的代碼（SQL 注入！）
const query = `SELECT * FROM users WHERE name = '${name}'`;
// 正確的做法
const users = await db.query("SELECT * FROM users WHERE name = ?", [name]);
性能調優：AI 能給出理論建議，但真正的性能問題要用 Profiler 分析。
架構決策：選哪個方案、如何組織代碼，AI 的建議是參考，不是答案。
Cursor 的體驗
Cursor 是 VSCode fork，內置了 AI 功能：
最有用的：
- Cmd+K：在光標處生成/修改代碼（比 Copilot 更強）
- @file：在對話中引用當前文件
- Cmd+Shift+I：對整個代碼庫的對話
不適合的：
- 已有 VSCode 完整配置的項目（遷移成本）
- 需要特定 VSCode 擴展的工作流
還沒有完全從 VSCode 切到 Cursor，但新項目會優先用。
2024 年的感受
AI 工具讓我在"寫代碼"上省了 30-40% 的時間，但這個時間的大部分被轉移到了：
- 更多的 Code Review
- 更仔細的架構設計
- 更多的測試
- 理解 AI 生成的代碼（不能不理解就用）
整體輸出質量有提升，但不是"省了時間就能摸魚"，而是把時間用在了更有價值的事情上。
小結
- AI 工具 2024 年已經是必要的生產力工具
- 提示詞質量決定輸出質量：具體、有上下文、有約束條件
- AI 不能替代：業務判斷、安全審查、架構決策、性能調優
- AI 生成的代碼必須審查，保持批判性思維
- Cursor > GitHub Copilot（但遷移成本需要考慮）