你在用 AI 改程式碼，還是完成任務？

最近帶同事用 Claude Code，發現大多數人用 AI 的方式都是：找到程式碼，叫 AI 改那幾行。當然這樣做也能完成任務，但限制了 AI 能做的事…

---

最近花幾天陪一個同事用 Claude Code 輔助開發，結果比我預期的好很多。帶同事改完一張票不用一小時。

同事不是不會用 AI，只是用法還停留在「改程式碼」，換個方式之後就起飛了。

心法：用 AI 完成任務，不是改程式碼

我們有一張票是簡單的排序需求，PM 截了一張圖，希望網頁上的分頁功能要有特定順序。

同事的做法是找到程式碼位置，把那幾行複製貼給 AI，最後跟 AI 說「幫我把 A、B、C、D 的順序改成 B、C、D、A」。

AI 幫同事把程式碼改好了，但我看了覺得有更快的做法。

我的想法是：「要讓 AI 幫忙做完這個任務，而不是改程式碼。」

如果是我來處理這個需求，我會把票的所有內容和檔案位置貼給 AI，再說我的目的「請幫我改成圖片的順序」。整個過程不會提及程式碼，讓 AI 自己去看檔案、理解需求。

這兩種方式最大的差別在於，我的出發點是：把需求描述給 AI，讓 AI 理解我的意圖，它才能像工程師一樣寫程式。

怎樣算是說清楚

最常見的問題不是 AI 不夠聰明，是給的 context 不夠。

「幫我 fix 這個 bug」是一種說法，但沒有 error message、沒有復現步驟，AI 只能猜。

「把這個功能改好」也是，改成什麼樣子？以什麼為準？這些問題沒回答，AI 給的結果通常不是你要的。

說清楚至少要有三個東西：你要達成什麼目的、相關的 context（截圖、error、檔案位置）、你期望的結果長什麼樣。

不需要幫 AI 解決問題，只需要讓它知道問題是什麼，剩下的讓它想。

AI 比我們更會使用開發工具

其實還有其他開發場景很適合全權交給 AI 處理，因為 AI 比我們更熟悉開發工具。

像是寫 commit message、MR description 以往都要想很久，現在使用 AI 搭配 skill 就能無腦搞定。

開發工具遇到問題也是一樣的做法。glab 沒有安裝、GitLab access token 不知道怎麼設定，這些不用自己先搞清楚，直接問 AI 怎麼處理，它會一步一步教你。

操作 git 分支也是。分支基底要怎麼切、想 rebase 到哪個 commit，說清楚你要的結果，AI 會幫你搞定。

更複雜的事情也能讓 AI 處理

複雜的功能需求也適用：

• 畫面很醜，跟 AI 說想要怎麼排版
• 想加互動功能，描述使用者的操作行為
• 做完之後發現哪裡用起來不順，繼續跟 AI 反饋修到好

我們可以把比較複雜的問題思考交給 AI，把心力放在「提供的資訊正不正確」、「AI 的成果是不是我們想要的」。

但，AI 也有做不到的事

AI 做不到的是：幫你想清楚你要什麼。

需求沒想清楚，給 AI 再多 context 也沒用，它只是把你的模糊放大。問題說不清楚，有時候是你自己還沒想好。

AI 做不到的另一件事是：幫你把關成果。

如果不懂 AI 做了什麼，就沒辦法確認結果對不對，這部分非常仰賴開發者的基本功。使用 AI 做軟體開發，基本功的意義不再只是用來寫程式，而是用來判斷 AI 做出來的東西有沒有正確、符合品質要求。

說清楚問題的前提，是你得先看得懂問題在哪。懂愈多，你描述問題的精準度就愈高，AI 給出的結果也愈接近你要的。

如果你完全看不懂 AI 做了什麼，你就只能選擇相信它。這樣你只是一個幫 AI 按確認的作業員。

換個角度用 AI

我用 AI 開發到目前為止也至少有三年了，從去年 2025 年下半年開始，我意識到開發者使用 AI 的方式需要改變了。

不要再要求 AI 照你的方式寫程式，你要養成新的習慣：

• Before：你還是在決定要改哪裡，AI 幫你改那幾行。
• After：你說清楚要解決什麼問題，AI 自己去找哪裡要改、怎麼改，你負責確認結果對不對。

以前你需要先把問題搞清楚，才能叫 AI 去做；現在你只需要說清楚問題是什麼，讓 AI 去想怎麼做。

註：內文提到的 AI 是指 Claude Code、Gemini CLI 這類 AI 開發工具。