使用生成式 AI 的底層邏輯
上個月我讓 AI 生成了一段程式碼。看起來很完美——格式工整、邏輯清晰、註解詳細。我興奮地跑測試，結果失敗了一堆。
那一刻我意識到：AI 不是魔法，是工具。 用對了是槓桿，用錯了是坑。過去半年我在專案裡大量使用 AI，踩過坑也找到了節奏。這篇文章想分享什麼時候 AI 真的有用，什麼時候只是在浪費時間。
AI 什麼時候是槓桿？
真正放大工程師價值的場景
過去半年用 AI 的經驗讓我發現，AI 是「放大器」，不是「替代品」。它能放大你的專業判斷，但無法取代思考。
1. 提升效率：自動化重複勞動
上個月我接到一個需求：兩天內補完 50 個 API 的文件。以前我會加班到天亮，這次讓 Cursor 的 Agent mode 生成初稿，自己負責審查調整。第一天下午就完成了，而且 AI 還發現了幾個我忽略的 edge cases。
- 生成 API 文件、單元測試
- 批量重構相似的程式碼模式
- 自動產生 boilerplate code
2. 擴展能力邊界：快速學習新領域
有次 PM 要我研究「賭博成癮者的多巴胺機制」來設計防沉迷功能。我用 Perplexity 查詢，兩小時就理解了核心概念：不只贏錢會產生快感，連「預期會贏」這個念頭都會產生多巴胺。這個知識直接用在設計「冷靜期」功能上。
AI 加速學習：
- 透過 Felo、Perplexity 等工具快速掌握跨領域知識
- 從「不懂」到「能應用」，縮短好幾天的學習曲線
3. 降低門檻：快速驗證想法
上週我想驗證「卡片滑動審查程式碼」的想法。用 v0 輸入描述，5 分鐘就有了可互動的原型。試了三個版本，15 分鐘內發現這個想法不適合。快速失敗比慢慢實作好。
快速驗證工具：
- v0、Bolt.new、Loveable 快速產生可互動原型
- 讓初學者也能產出可用成果
- 資深工程師更快完成概念驗證
關鍵是專業判斷： AI 生成初稿，人類把關品質。沒有 AI 做不到這麼快；沒有人類審查，產出不能用。
什麼時候 AI 變成負擔？
但不是每次都順利。兩個月前我讓 AI 重構一個舊模組，它重寫了大量程式碼，看起來很乾淨。我直接 commit 了。隔天測試報告：一堆失敗。
花了兩天 debug 才發現，AI 在「優化」時改變了邊界條件的處理。那些「醜陋」的舊程式碼其實處理了很多歷史問題。
常見的反模式：
1. 產出品質不佳
- AI 生成的程式碼充滿 bug 或技術債
- 反而花更多時間修正
2. 過度依賴失去思考
- 團隊有個實習生，任何功能都先問 AI
- 我問他「為什麼這裡要用 useMemo？」他答不出來
- 兩週後他寫的頁面超級卡，因為用錯了地方
3. 錯誤的應用場景
- 複雜架構設計不適合直接問 AI
- 需要深度理解業務邏輯的任務
4. 工具即答案的迷思
- 誤以為「有 AI 就能解決一切」
- 忽略專業判斷與流程設計
記住：你是 committer，要對程式碼負責。 AI 是輔助，不是替罪羊。
LLM 的本質：為什麼 AI 會瞎掰？
機率模型的特性
用了半年 AI，我理解了它的本質：機率模型，不是推理引擎。
想像你有個朋友，他記憶超強、讀過所有文件，但回答問題時會擲骰子。有時超準，有時一本正經地胡說八道。同一個問題，今天問是 A 答案，明天問是 B 答案。
更準確地說，LLM 每次生成時都從機率分佈中採樣。這個分佈受 prompt、temperature、訓練資料等因素影響。它沒有「知識庫」，只是根據統計規律預測「最可能的下一個詞」。
這導致兩個問題：
- 隨機性： 同一個 prompt，多次詢問可能得到不同答案
- 推理能力有限： 擅長模式擬合，遇到複雜問題容易出錯
Prompt 工程的現實
沒有給足夠的 context，AI 就像穿越來的金魚腦。有次我問：「把這個函數改成 async」。它生成了程式碼。我又問：「這樣會影響性能嗎？」它回：「什麼函數？」
實務建議：
- Prompt 不是萬能： 即使很明確，AI 也可能因知識盲點而答錯
- 迭代式互動： 與其追求「完美 prompt」，不如先簡單試探，根據回應逐步調整
- 模型差異： 不同 LLM 即使面對相同 prompt，也會因訓練資料不同而產生不同結果
開發上如何減少 AI 幻覺
1. 給 AI 高品質的資料來源
我們專案每個模組都有詳細的 README。一開始只是為了團隊協作，後來發現對 AI 超有用。
有次讓 AI 寫資料處理邏輯，第一次沒給 README，生成的程式碼完全沒考慮資料可能是 null。我在 README 補上「某些欄位可能為 null」，AI 再生成時主動加了檢查。
實務做法：
- 多寫 README： 讓 AI 有資料可查
- 結合 RAG 技術： 讓 LLM 參考企業內部資料、專業文件
- 要求引用來源： 問 AI「這個資訊來自哪裡？」
2. 明確設計 Prompt 和專案規範
我們在 .cursor/rules/ 放了規範檔案，描述：
- Coding style（用 functional component，不用 class）
- 常見陷阱（某個 API 有 rate limit）
- 專案架構（檔案組織方式）
有了這個，AI 生成的程式碼會自動符合規範，不用每次重複說明。
Prompt 技巧：
- 精確描述需求： 像 cursor rules 一樣，描述專案樣貌或開發習慣
- 限制回答範圍： 要求模型只根據提供資料回答，若無資料請回答不知道
- 指定格式： 要求 LLM 依照指定格式、欄位、步驟作答
3. 建立驗證與審查機制
團隊規定：任何 AI 生成超過 50 行的程式碼，都要 code review。
不是走形式，而是真的逐行檢查：
- 邏輯對嗎？
- 邊界條件考慮了嗎？
- 有安全問題嗎？
- 性能會不會有問題？
有時 review 發現 AI 用了 O(n²) 算法，其實 O(n) 就能解決。有時發現它把敏感資訊寫在前端了。
其他驗證方式：
- 多模型交叉驗證： 同一問題用不同 LLM 詢問，對比結果
- 自動化測試： 結合單元測試、Lint 工具等自動化檢查
4. 提升團隊 AI 素養
教育與培訓：
- 讓團隊了解 LLM 局限與幻覺風險
- 培養批判性思維
- 建立回饋機制
制定 working agreement：
- committer 就要對 code 負責，不要都推給 AI
- 明確定義 AI 角色：輔助建議，最終決策仍由人類把關
5. 技術性調整
- 限制模型自由度： 調整 temperature、top-p 等參數，降低隨機性
- 定期更新資料集： 確保訓練資料新穎且多元
選對模型與工具
不同模型的個性
最近用 Windsurf，他們團隊分享了對不同模型的看法，我很有共鳴。
Sonnet 3.7 - 積極的夥伴：
超級主動，你說重構一個函數，它會順便重構整個模組。一開始我覺得煩，後來發現：寧願一個需要拉住的夥伴，也不要一個需要催促的助手。但要小心它太積極時可能會做不想要的改動。
Gemini 2.5 Pro - 穩定的實用主義者：
不會亂發揮，你要什麼就給什麼。程式碼品質跟 Sonnet 差不多，但更穩定一致。
Sonnet 3.5 - 精準的執行者：
最適合除錯和範圍明確的重構。很少偏離主題，總能穩定維持在嚴格範圍內。
GPT-4o - 謹慎的規劃者：
它會先想再做。其他模型直接開始寫，邊寫邊說計畫。GPT-4o 會先生成計畫，問「這樣可以嗎？」確認後才執行。
Cascade Base - 快速的小幫手：
速度快，適合小型、獨立的編輯。當深度推理不是重點時特別理想，而且免費。
我的選擇策略
根據任務選模型：
| 情境 | 推薦模型 | 原因 |
|---|---|---|
| 快速迭代、探索新想法 | Sonnet 3.7 | 積極主動，自動做延伸 |
| 維護舊程式碼、bug fix | Gemini 2.5 Pro | 穩定可靠，不會亂改 |
| 精確範圍的重構 | Sonnet 3.5 | 精準把握範圍 |
| 複雜重構、架構改動 | GPT-4o | 先規劃再執行 |
| 小改動、快速測試 | Cascade Base | 免費又快 |
用對工具達到槓桿效果：
- 提升效率： Windsurf、Cursor 的 Agent mode 協助重構、測試、文件
- 擴展能力： Felo、Perplexity 快速學習新領域
- 快速驗證： v0、Bolt.new 快速 Vibe Coding
- 探討想法： Cursor 的 Chat mode 討論重構方向
我的使用心得
半年前開始用 AI 寫程式，我以為找到了「自動寫程式」的聖杯。
半年後發現，AI 沒有讓寫程式變簡單。它只是把「重複勞動」自動化了，讓我有更多時間思考「為什麼這樣設計」「有沒有更好的方案」。
現在用 AI，我會這樣做：
先自己想清楚思路
要解決什麼問題？可能的方案是什麼？給足夠的 context
貼程式碼、說明限制、提供範例分段讓 AI 做
不要一次丟太大任務，一步步來每一步都檢查
不要等全部做完才測試準備好 debug
AI 會出錯，這很正常
這樣下來，AI 能讓開發速度快 2-3 倍。但前提是：我知道我在做什麼。
結語
AI 幻覺是 LLM 應用無法完全避免的現象，但工程師可以透過「資料把關、精確 prompt、人工審查、團隊教育」等策略，大幅降低幻覺對品質的負面影響。
寫程式的核心還是思考。AI 只是讓思考的結果能更快被實現。
別期待它完美。把它當成一個很聰明但偶爾會出錯的助手。你還是要把關，還是要思考，還是要負責。
但這樣的夥伴，已經很好了。
你用 AI 開發的經驗如何？遇到過什麼坑嗎？歡迎留言分享。