AI 時代怎麼跟工程師提需求 | 別把 AI 回答原封不動貼給開發者

編譯摘要

編譯摘要

第一步：濃縮

核心結論

  1. 客戶貼 AI 程式碼過來請工程師檢查，本質上是「腦補解法」 — 工程師需要的是真實情境，但收到的是 AI 對假設情境的最佳解

    • 證據：WooCommerce 客戶貼 add_action 掛 woocommerce_thankyou 的 50 行 PHP，背後十個問題（要通知還是備份？綠界 ATM 延遲觸發是不是預期行為？資料表有沒有跟其他系統串？）都沒被描述

  2. 比起貼 AI 程式碼，「文字描述 + 截圖 + 期望 vs 實際」的三層素材資訊密度更高

    • 證據：30 秒寫的「店家手機沒收到訂單通知，希望每筆訂單成立時 LINE 推訊息」比 50 行 AI PHP 提供更多開發判斷依據
    • 證據：「結帳運費應按金額分級，現在不管金額多少都收 100 元」（現象）比「在 functions.php 加 add_filter」（解法）有用十倍

  3. AI 應該用在「問題描述端」而非「解法端」 — 工程師的價值在業務理解、技術選擇判斷、維運預估，這些需要真實情境作為輸入

    • 證據：AI 不知道客戶的後台外掛組合、資料庫編碼（utf8 vs utf8mb4）、舊工程師留下的 hook、下個月要接的金流，這些只有看過客戶環境的工程師知道

第二步：質疑

前提假設

  1. 假設客戶不具備完整技術環境視野 — 但若客戶是技術背景 PM 或自己也寫過 code 的業主，他們可能已把環境因素納入 prompt，此時貼 AI 程式碼 + 原始 prompt 反而是最佳實踐
  2. 假設工程師有時間「回頭問十個問題」 — 接案壓力大的情境下，採用 AI 程式碼比挖問題快，雖然品質風險高
  3. 假設真實情境「永遠比 AI 假設複雜」 — 對於極端定型的需求（標準 API 串接、廣告追蹤碼安裝），AI 假設可能足夠
  4. 「AI 是中間噪音」的比喻有反例 — AI 程式碼有時可當成「客戶心智模型的可視化」，看方向反推客戶在想什麼，反而比客戶自己描述更精準

邊界條件

  • 客戶能把完整環境寫進 prompt（含外掛清單、資料庫狀態、現有 hook）的情境下，貼 AI 答案是高效溝通
  • 一次性、低風險小修改採用 AI 程式碼成本可能比追問問題低
  • 客戶與工程師長期合作、信任度高的環境，問題挖掘成本低，AI 程式碼可作為起點

資料來源可靠性

  • 樣本：作者過去半年（2025 下半年至 2026 春）接案經驗，未量化（沒給「N 件案子中 X 件出現此模式」的數據）
  • 適用範圍：B2B 接案開發（特別是 WordPress / WooCommerce 訂製），其他情境（純技術顧問、駐點開發、SaaS 客服）未必適用

第三步：對標

跨域類比

  1. 醫師看診 vs 病人 Google 自診 — 病人應該描述症狀（發作時間、過去病史）而非說「我要某某藥」。AI 寫程式 ≈ Google 自診後直接點藥單
  2. 裝潢設計 — 屋主貼一張別人家的照片說「我要這樣」，但對方家的格局、樑柱、管線都不同。看現場（截圖）才有意義
  3. 法律諮詢 — 客戶丟一份契約範本說「依這個改」，比描述「我想保障什麼權益」更難給建議
  4. 科學論文的 raw data vs interpretation — 投稿者直接給 conclusion 不給 raw data，審稿人無法判斷推論是否合理
  5. 與「腦補需求」的鏡像對稱 — 創業者腦補「客戶痛點」（生產端腦補）↔ 客戶腦補「工程師要的程式碼」（消費端腦補）。兩者都跳過了真實情境的觀察

可遷移場景

  • 設計師接案：客戶貼一張 Figma 作品說「我要這個」 vs 描述使用情境與品牌調性
  • 文案外包：客戶貼 ChatGPT 寫好的文案說「改一改」 vs 描述讀者與行為目標
  • 律師諮詢：客戶丟模板契約 vs 描述商業風險與訴求
  • 產品 PM 提需求給內部工程師：直接給 user story 解法 vs 描述使用者痛點
  • 醫療影像 AI：放射師收到醫師「給 AI 看後再給我看」的影像 vs 直接看原始影像 + 病史

與既有概念的關聯

  • [[engineer-identity-crisis]] — 工程師從「寫程式的人」變成「解決問題的人」，本文是這個轉變在客戶溝通端的具體體現
  • [[screenshot-driven-development]] — 截圖比文字精準的原則，從開發協作延伸到需求溝通
  • [[ai-people-pleasing]] / [[ai-discoulary-behavior]] — AI 給確定性解法的傾向，正是「腦補解法」的源頭
  • [[ai-as-amplifier]] — AI 是放大器，但需要真實情境作為被放大的內容
  • [[ai-product-raw-material-model]] — 「AI 當原料、人加工」的模型對應「AI 用在描述端、人做判斷」
  • [[painkiller-vs-vitamin]] — 創業端「痛點要看見不能腦補」↔ 接案端「問題要描述不能用 AI 解法代替」
  • [[behavioral-interview-method]] — 訪談技巧的「問現象不問意見」對應接案的「描述現象不貼解法」

衝突標記

無重大衝突。本文與 [[engineer-identity-crisis]] 略有張力——後者描述工程師面對 AI 的焦慮，本文則描述客戶用 AI 後反向出現的協作問題。兩者可整合為「AI 時代協作雙向調整」：工程師端要從寫程式轉為解決問題，客戶端要從貼解法轉為描述問題。