工程師用 AI：少 debug、少重工，讓身邊的人也會做小工具

工程師大概是最早天天用 AI 的職業，也是最常被 AI 搞得更累的職業。AI 寫的 code 跑得起來，上線卻出包；需求一週改三次；年紀到了三十五，開始擔心自己會不會被取代。這頁不教你怎麼叫 AI 寫更多 code，而是講工程師 AI 的三個用法：讓它先寫測試、把需求變成驗收條件、讓身邊的 PM 和主管自己動手做小工具。思路很精簡，少做重工，多做判斷。

工程師最常講的 3 句抱怨

根據主計總處人力資源調查（勞動部統計資料庫表 2-12），2025 年「出版影音及資通訊業」就業者平均約 29 萬人。104 人力銀行的《AI 人才趨勢報告》也指出，AI 需求人數最高的職缺類別，前三名仍是軟體工程、工程研發、操作／技術類（工商時報 2026 年 7 月轉述）。需求很多，但工程師自己講的是另一回事：

• 「debug AI 寫的 code 比自己寫還久。」它生得很快，邊界條件卻沒處理，錯在哪還要從頭讀。
• 「需求一直變。」會議上講好的東西，下週 PM 又說客戶要改，前面寫的白做。
• 「35 歲之後怎麼辦？」新人用 AI 也能寫出能跑的東西，自己的價值到底在哪。

AI 寫的 code 一直出包？先叫它寫測試

你是不是也習慣直接叫 AI「幫我寫這個功能」？這是工程師 AI 最容易踩的坑。它會給你一段看起來合理的 code，錯誤藏在你沒想到的情境。順序反過來比較穩：先寫測試，確認測試是對的，再請它寫實作讓測試通過。

1. 在 Claude Code 或你習慣的 AI 工具裡，先描述功能和邊界情況，請它只寫測試，不准寫實作。Claude Code 要 Claude Pro 以上方案或 API 帳號，免費版用不到；只想試試的話，用 ChatGPT 或 Claude 網頁版貼 code 也能做。
2. 你自己讀過測試，補上它漏掉的情境。這一步是你的價值所在。
3. 再請它寫實作，跑測試，失敗就把錯誤訊息貼回去。
4. 合併前看 diff，特別是它順手改到的其他檔案。

我要在 Node.js 專案裡加一個函式 calcShippingFee(order)。
規則：
1. 訂單金額滿 1,000 元免運
2. 未滿 1,000 元，本島運費 80 元，離島 150 元
3. 金額是負數或不是數字，要丟出錯誤
請先只寫 Jest 測試，涵蓋正常情況和邊界值（999、1000、0、負數、字串）。
先不要寫實作。寫完列出你認為我可能漏掉的情境。

最後一句是重點。讓 AI 反過來問你，常常會挖出規格沒寫清楚的地方。

需求一直變：把會議紀錄變成驗收條件

需求會變，這點工程師 AI 改不了。它能幫你的是讓每一次變更都留下清楚的版本，大家對「做完」的定義一樣。你可以把會議逐字稿、Slack 或 LINE 討論、舊版規格丟給 Claude 或 ChatGPT，請它整理成使用者故事和驗收條件，也列出還沒決定的事。

1. 會議錄音轉成文字，或直接複製討論串。客戶名稱和個資先拿掉。
2. 貼上下面的提示詞，請它輸出規格草稿。
3. 把「未決問題」那一段直接丟回給 PM，請他回答完才開工。
4. 需求再改時，把新舊兩版都貼給 AI，請它列出差異和影響到的功能。

以下是今天產品會議的逐字稿，主題是會員點數功能。
請整理成：
1. 使用者故事（格式：身為___，我想要___，以便___）
2. 每個故事的驗收條件，用 Given / When / Then 寫
3. 會議裡沒講清楚、需要 PM 決定的問題清單
4. 這次需求跟上一版（附在最後）的差異
只根據逐字稿內容，推測的部分要標「推測」。
逐字稿：
（貼上）
上一版規格：
（貼上）

規格文件、API 文件很多的話，可以全部放進 Gemini Notebook（2026 年 7 月由 NotebookLM 更名），免費帳號每個筆記本能放的來源有上限，但一般專案文件夠用。問答時它會標出出處，方便你回頭查證。

35 歲焦慮：讓 PM 和主管自己做小工具

很多人以為 AI 會先取代資深工程師。我們看到的比較像另一種情況：會寫 code 的人變多了，能判斷哪段 code 可以上線的人還是很少。工程師 AI 用得好的人，可以主動把簡單的內部工具交給身邊的 PM、主管用 Claude Code 自己做，你負責定規則和把關。

1. 挑一個需求小、不碰正式資料庫的工具，例如報表轉檔、內部查詢頁。
2. 幫他們開一個獨立的資料夾或 repo，寫好一份 CLAUDE.md，列出不能碰的東西和 coding 規則。
3. 讓 PM 用下面的提示詞開始，卡住再找你。
4. 上線前由你 review，安全和權限的部分不放手。

我是 PM，不太會寫程式。我想做一個小工具：
把業務每週匯出的 Excel 訂單表，轉成主管要看的週報（各區業績、前五名客戶、跟上週比較）。
請你：
1. 先問我 3 到 5 個問題，確認需求
2. 用最簡單的方式做（Python 就好，不要架網站）
3. 每一步做完告訴我做了什麼、我要怎麼測試
4. 不要讀取或修改這個資料夾以外的檔案

這樣做你不會被取代。團隊會記得，是你讓大家都用得起來。

要小心的地方

工程師 AI 的風險，多半出在你貼進去的東西和它生出來的東西：

• 原始碼與金鑰。.env、API key、資料庫連線字串不要貼給 AI。公司的程式碼能不能用外部 AI 處理，先看公司規定和合約。
• 客戶資料。測試用的資料庫匯出檔常有真實姓名、電話。給 AI 看之前先換成假資料，個人資料保護法的責任在公司。
• 它會編出不存在的東西。AI 偶爾會建議一個根本不存在的套件或 API 參數。裝套件前確認名稱、下載量和維護者，避免裝到同名的惡意套件。
• 授權與資安。它生出的 code 可能有 SQL injection、權限沒檢查這類問題，也可能跟某個開源專案高度相似。上線前的 review 不能省。

不過這些都是工程師本來就該做的事，AI 只是讓它更重要。

下一步

今天就做一件事，從最小的工程師 AI 習慣開始：下一個要寫的函式，先叫 AI 只寫測試，看它列出的「可能漏掉的情境」裡有沒有你沒想到的。

如果你想讓身邊的 PM、主管也會用 Claude Code 做自己的小工具，可以推薦他們上我們的實體課「Claude Code 入門課」，資訊在INNORA 實體課程。想看其他職位怎麼用 AI，可以到10 大職業 × AI 總覽，或看常跟工程師一起開會的行銷 AI 工具和行政 AI 工具。