AI 時代怎麼跟工程師提需求 | 別把 AI 回答原封不動貼給開發者
AI 文章延伸
選擇平台後可直接帶入閱讀脈絡，快速整理重點、補齊盲點，並延伸到同站相關文章。
這陣子我們開始收到一種新型態的錯誤回報：客戶把 ChatGPT 或 Claude 的回答整段複製過來，附上一句「這個你看一下對不對」，沒有問題描述、沒有截圖、沒有情境，就是一段 AI 生出來的程式碼。
這種訊息的數量今年開始明顯變多，這篇想直接講：為什麼這樣做反而會讓開發變慢，以及一個更有效的提需求方式。
客戶為什麼會貼 AI 回答給我們
先講結論再倒推回去，客戶會貼 AI 回答過來，通常是出於善意，他們想：
- 「我先用 AI 試一下，省你的時間」
- 「我自己先做功課，不要兩手空空就找你」
- 「這個 AI 給的看起來很完整，你只要確認就好」
我們看得到這份心意，這幾年 AI 工具讓非工程師也能寫出像樣的 PHP 或 JavaScript 片段，門檻降低之後，業主主動參與技術討論變成一件好事，問題出在「貼過來的東西」本身。
我們收到的內容幾乎都是同一種：程式碼具體實作的部分。例如客戶貼一段 50 行的 PHP，告訴我們這是 AI 給他的解法，問我們要不要採用。
程式碼我們看得懂，但問題我們看不到
這段程式碼能不能跑？我們花三分鐘讀完就能判斷，語法有沒有錯、邏輯通不通、會不會踩到 WordPress 的 hook 順序，這些都是我們的本業。
但讀完之後我們會卡住，卡在一個更基本的問題上：這段程式碼到底是要解決什麼？
舉一個前陣子的例子。某位 WooCommerce 客戶貼了一段 ChatGPT 給的 add_action 程式碼過來，掛在 woocommerce_thankyou 上，內容是把訂單資料寫到自訂資料表，我們讀完知道這段在做什麼，但下一秒就一堆問題冒出來：
- 你要的是訂單通知，還是資料備份？
woocommerce_thankyou在某些金流（像綠界 ATM）會延遲觸發，這是你要的行為嗎？- 那張自訂資料表有沒有跟其他系統串？
- 這個需求是一次性的，還是會持續長出更多欄位？
這些問題沒有一個能從那段程式碼看出來，我們只看到 AI 對「某個我們不知道的問題」給出的猜測解法，而真正需要解決的問題從來沒被描述過。
從「腦補需求」到「腦補解法」
這個現象很像我們之前在 創業痛點怎麼找 那篇講的：痛點不是腦補出來的，是要真實看見的，把 AI 回答貼過來其實是同一件事的鏡像版本——腦補解法。
腦補解法的問題在於 AI 給的是「對某個假設情境的最佳解」，但真實的工作情境永遠比假設複雜，AI 不知道你後台有沒有裝過某個外掛、不知道你資料庫的編碼是 utf8 還是 utf8mb4、不知道你之前那位工程師留下的奇怪 hook 還在跑、更不知道你下個月要接的金流會不會跟這段程式碼打架。
我們知道，因為我們看過你的環境。
所以當客戶貼一段 AI 程式碼過來問「對不對」，我們真正要做的不是檢查程式碼，而是回頭問你上述問題，把那段程式碼背後沒講清楚的情境挖出來，然後重新評估這個解法到底對不對，往往挖完之後，原本那段 AI 程式碼會被整段丟掉，因為真正的需求根本不在 AI 假設的方向上。
這比客戶直接給我們一段問題描述還慢，因為我們還得先把「AI 假設的問題」這層噪音排除掉。
一個更有效的方式：描述問題本身，附截圖
我們不是要客戶不要用 AI，這幾年我們自己也大量使用 AI 開發，這是 AI 時代的開發新常態，我們想說的是，貼出來的東西要對齊你想解決的問題，而不是 AI 猜測的解法。
具體一點，比起貼一段 AI 程式碼，下面三種素材對工程師更有用：
1. 文字描述問題本身
不需要寫得像 spec，直接用日常語言講一遍：「客人在後台下完訂單後，店家手機沒收到通知，我希望每筆訂單成立時 LINE 都能推一則訊息給我」，這 30 秒就能寫完，但提供的資訊比 50 行 AI 程式碼還多。
2. 截圖目前看到的畫面或錯誤訊息
如果是 bug，截圖是最快的溝通方式，畫面上的錯誤訊息、URL 路徑、後台的設定值，這些對我們來說都是線索，我們去年寫過 截圖驅動開發法，講的就是視覺資訊比文字描述精準的原因，同樣的原則套在問題回報上也成立。
3. 描述「你期望發生什麼」跟「實際發生什麼」
這兩句話拆開講，比講一個具體的解法有用十倍：
❌「我覺得應該要在 functions.php 加一個 add_filter 處理」
✅「結帳時運費應該按照購物車總金額分級，現在不管金額多少都收 100 元」
第一種是解法（而且通常是 AI 給的），第二種是現象，現象描述清楚之後，解法是我們的工作，那才是客戶付錢請我們做的事。
AI 時代提需求的心態調整
回到一開始那個問題：客戶會貼 AI 回答過來是出於善意，那要怎麼把這份善意用在對的地方？
我們的建議是：把 AI 用在問題描述端，而不是解法端。
例如把你想做的事描述給 AI 聽，讓 AI 幫你整理成一段比較完整的問題說明、列出幾個關鍵情境、甚至幫你想清楚「期望結果」跟「現況差異」，把這些整理過的東西貼給工程師，會比貼一段 AI 寫的程式碼有用太多。
換個角度想，客戶付錢請我們做的不是「打字產出程式碼」這件事，AI 已經能做這件事，你付的是我們對你業務的理解、對技術選擇的判斷、對未來維運的預估，這些東西需要的不是 AI 寫好的程式碼，是你那邊真實的情境跟需求。
工程師這個角色在 AI 時代正在從「寫程式的人」變成「解決問題的人」，但這個轉變只有在我們拿得到真實的問題時才會發生，我們最怕的不是客戶用 AI，而是 AI 變成中間一層噪音，把問題本身糊掉了。
延伸思考
這篇文章的觀點建立在幾個前提上，值得進一步思考：
- 假設客戶不具備完整的環境視野——但若客戶是技術背景 PM、本身寫過 code、或是長期合作熟悉系統的業主，他們可能已把資料庫狀態、外掛清單、現有 hook 全寫進 prompt 了，此時貼 AI 答案 + 原始 prompt 其實是高效溝通，不算腦補。
- 不是所有需求都需要挖問題——對於極端定型的需求（標準金流串接、廣告追蹤碼安裝、現成外掛的設定調整），AI 的假設情境可能足夠，這時候 AI 程式碼直接當參考起點是合理的。
其他領域也有類似的現象：
- 病人 Google 自診後直接點藥單——醫師需要的是症狀、發作時間、過去病史，而不是「我覺得我要某某藥」。AI 寫程式 ≈ 病人自診後跳過問診環節。
- 裝潢屋主貼一張別人家的照片說「我要這樣」——對方家的格局、樑柱、管線都不同，看現場（截圖）才有意義。同樣的原則延伸到設計接案、文案外包、律師諮詢都成立。
- 科學論文的 raw data vs interpretation——投稿者只給 conclusion 不給 raw data，審稿人無法判斷推論是否合理。AI 程式碼是「conclusion 沒有 raw data」的工程版本。
關鍵概念：腦補解法、問題描述三層素材、工程師身份認同危機、截圖驅動開發法
常見問題
客戶用 AI 先做研究是不是壞事？
完全不是壞事，AI 讓非工程師也能參與技術討論這件事我們很歡迎，重點是貼出來的內容要是「對齊你問題的研究」，而不是「AI 對某個假設情境的解法」，把 AI 當成幫你整理問題的助手，比把它當成寫程式的代理更有價值。
那我可以貼 AI 回答給工程師當參考嗎？
可以，但要附上脈絡，同樣是貼 AI 程式碼，前面加一句「我目前遇到 X 問題、我問了 ChatGPT 給了這個解法、想知道在我們的系統下適不適用」，這樣的訊息我們就能精準回答，差別在於你給了我們判斷的前提，而不是要我們從程式碼倒推情境。
為什麼附截圖比文字描述問題還有用？
因為截圖會帶出你自己沒注意到的線索，例如你看到的錯誤訊息、瀏覽器 console 的紅字、後台某個設定的當前值，這些對工程師都是判斷依據，文字描述容易遺漏，截圖則是直接給出現場狀態。
我不懂程式，怎麼描述問題才不會講不清楚？
不需要懂程式，反而是越用日常語言越好，把「我做了什麼動作」、「我預期看到什麼」、「實際看到什麼」這三件事講清楚就夠了，技術判斷是工程師的工作，客戶的工作是描述使用情境。
Google 偏好來源
喜歡我們的內容嗎？一鍵將我們設為偏好來源，未來在 Google 焦點新聞與 AI 概覽中就能優先看到我們的文章。