先搞清楚：這些工具不一樣
很多人把「AI 寫程式」當成一個東西，但市面上的工具其實定位很不同。
GitHub Copilot
最早出現、最多人用的 AI 輔助工具。
定位是「自動補全的超級加強版」。你打幾個字，它猜你要寫什麼，按 Tab 接受。
優點：無縫整合到 IDE，幾乎不改變你的工作流程。 缺點：它只看你當前檔案和少量上下文，不懂整個專案。
Cursor
把 AI 深度整合進 IDE 的新產品。
定位是「AI-native 的開發環境」。不只自動補全，還能對話、重構、解釋程式碼。
優點：上下文理解比 Copilot 好，可以索引整個專案。 缺點：需要換編輯器，學習曲線較高。
Claude Code
Anthropic 的 CLI 工具，我現在就在用它寫這篇文章。
定位是「AI Agent」。不只是補全或對話，而是可以自主執行多步驟任務：讀檔案、寫程式、跑測試、commit。
優點：能處理複雜任務，真正的「交辦」而不只是「輔助」。 缺點：需要信任它操作你的專案，要習慣放手讓它做。
簡單總結：
| 工具 | 定位 | 互動方式 | 上下文理解 |
|---|---|---|---|
| Copilot | 智慧補全 | 打字 → 建議 → Tab | 單檔 + 少量 |
| Cursor | AI IDE | 對話 + 補全 | 專案級 |
| Claude Code | AI Agent | 交辦任務 | 專案級 + 可執行 |
選工具之前，先問自己：你要的是「打字快一點」還是「把任務交出去」？
AI 真的有幫助的場景
不管用哪個工具，AI 在這些場景確實能幫上忙：
場景 1：Boilerplate 程式碼
最明顯的效率提升。
寫 CRUD、寫 API endpoint、寫 React component 骨架、寫測試 setup… 這些重複性高、模式固定的程式碼，AI 寫得又快又好。
以前你可能要花 10 分鐘寫一個標準的 REST controller，現在 30 秒。
這不是「AI 比你厲害」，是「這種程式碼本來就不該花人類時間」。
場景 2：不熟悉的框架或語言
你是 Java 工程師，臨時要改一段 Python。 你第一次用 Next.js，不確定 routing 怎麼寫。 你要用一個從沒碰過的 library。
以前你要查文件、看範例、試錯。現在問 AI，它直接給你可用的程式碼。
注意：它給的不一定是「最佳實踐」，但至少能動。你再從能動的版本去調整。
場景 3：Debug 和錯誤訊息解讀
收到一個看不懂的錯誤訊息，貼給 AI，它通常能解釋原因和解法。
這省下的不只是時間，還有挫折感。特別是那種 Stack Overflow 找不到、Google 結果都過時的問題。
場景 4：程式碼重構
「把這個 class 拆成三個」「把這段 callback 改成 async/await」「加上 TypeScript 型別」
這種機械式但容易出錯的工作，AI 做得比人類更可靠。因為它不會漏改、不會打錯字。
場景 5：寫文件和註解
很多工程師討厭寫文件。AI 可以根據程式碼產生說明，你再修改調整。
從「空白頁」變成「修改草稿」，心理門檻低很多。
但問題來了
如果 AI 這麼好用，為什麼有人越用越慢？為什麼有人抱怨「AI 寫的 code 很爛」？
因為 AI 有兩個根本性的問題：
問題 1：AI 不懂你的專案規範
每個專案都有自己的 convention：
- 變數命名風格（camelCase? snake_case?）
- 檔案結構（service 放哪裡？utils 怎麼組織？）
- 錯誤處理方式（throw exception? return error object?）
- 測試寫法（mock 怎麼用？fixture 放哪裡？）
AI 不知道這些。它只知道「一般來說」程式怎麼寫。
所以它產生的程式碼，技術上正確，但風格跟你的專案格格不入。
你要嘛花時間改，要嘛接受專案風格越來越混亂。
兩個選擇都有成本。
問題 2：AI 不懂你的業務邏輯
這個更致命。
AI 可以幫你寫一個「標準的」購物車功能。但它不知道：
- 你們公司的折扣規則有 17 種例外情況
- 這個欄位在 legacy 系統裡有特殊意義
- 上次那個 bug 就是因為沒處理某個 edge case
- 這個 API 的命名是錯的，但改不了因為已經有 client 在用
這些 context 存在資深工程師的腦袋裡，不在任何文件裡，更不在 AI 的訓練資料裡。
AI 產生的程式碼，在「通用情境」下是對的，但在「你的專案」可能是錯的。
誰用得好，誰用不好
觀察下來，能把 AI 用好的人有幾個共同特徵：
特徵 1：對專案夠熟
他們知道專案的 convention，所以能快速判斷「AI 這段要改哪裡」。
他們知道業務邏輯的 edge case，所以能在 AI 產出後補上該補的處理。
他們知道哪些地方 AI 容易錯，所以會特別檢查那些部分。
特徵 2：會追蹤和驗證
他們不會直接用 AI 的輸出，而是：
- 看過一遍，確認邏輯對
- 跑測試，確認行為對
- 跟原本的程式碼比對，確認沒有 side effect
這個「驗證」步驟，很多人會跳過。跳過的結果就是 bug 埋進去，之後花更多時間修。
特徵 3：從 AI 輸出中學習
好的使用者會觀察 AI 怎麼寫，學到新的寫法或技巧。
「原來這個 library 有這個 method」「原來可以這樣處理 error」
AI 變成一個隨時可以問的資深工程師，而不只是打字機器。
相反地，用不好的人通常是：
狀況 1：對專案不熟，無法判斷
新人用 AI 寫程式，寫得很快，但 PR 被打回來一堆問題。
因為他不知道專案規範，也看不出 AI 哪裡寫錯。
結果：修改時間比自己寫還長。
狀況 2：太信任 AI，不驗證
「AI 寫的應該沒問題吧」，直接 commit，直接上線。
然後就 incident 了。
狀況 3：只是用 AI 加速，沒有思考
把 AI 當成「打字加速器」，而不是「思考夥伴」。
能打更多字，但產出的程式碼品質沒變好，甚至變差。
結論：關鍵是判斷力
AI 輔助開發工具，用得好是翻倍器，用不好是負擔。
差別不在工具本身，在於使用者有沒有判斷力：
- 判斷 AI 的輸出哪裡對、哪裡錯
- 判斷哪些地方要讓 AI 寫、哪些要自己寫
- 判斷什麼時候該信任 AI、什麼時候該質疑
這個判斷力，來自於：
- 對專案的熟悉度：你要知道規範才能判斷違規
- 對業務的理解度：你要知道需求才能判斷正確性
- 對技術的掌握度：你要懂原理才能判斷合理性
AI 不會給你這些。這些要靠時間累積、靠實際經驗、靠踩過的坑。
所以結論是：
AI 工具會讓強者更強，但不會讓弱者變強。
如果你本來就有判斷力，AI 讓你效率翻倍。 如果你本來就缺乏判斷力，AI 讓你更快產出更多有問題的程式碼。
工具是放大器。放大的是你本來就有的能力。
判斷力怎麼培養？這是另一個大題目。我會另外寫一篇來討論。
如果你對 AI 輔助測試感興趣，可以看這篇更技術的文章：