腦補解法
腦補解法
定義
跳過問題描述、直接拿 AI 給的猜測解法當作需求交付給工程師（或任何專業執行者）的行為模式。是 [[創業痛點怎麼找|腦補需求]] 的鏡像版本——前者是生產端腦補消費者的痛點，後者是消費端腦補生產者需要的解法。
觸發機制
- AI 工具讓非工程師也能產出像樣的程式碼，門檻降低
- 客戶想「省工程師時間 / 自己先做功課」的善意
- AI 對任何問題都能給出看似完整的解法（[[AI 討好行為]] 的延伸）
- 缺乏「描述問題」這個動作的訓練——多數客戶不知道「現象 + 期望 vs 實際」比解法更值錢
典型樣態
客戶把 ChatGPT/Claude 的回答整段複製，附一句「這個你看一下對不對」，內容是：
- ✅ 程式碼具體實作（最常見）
- ✅ 設定檔片段
- ✅ AI 對某個方法的步驟說明
- ❌ 沒有問題描述
- ❌ 沒有截圖或錯誤訊息
- ❌ 沒有「我預期看到什麼 vs 實際看到什麼」
為什麼會讓開發變慢
工程師收到 AI 程式碼後要做的不是「檢查程式碼」，而是「逆向工程出問題本身」：
- 讀懂 AI 程式碼在做什麼（3 分鐘內可完成）
- 列出該程式碼背後的環境假設
- 一一向客戶確認假設是否成立
- 通常假設不成立 → 整段 AI 程式碼丟掉重做
比客戶直接給問題描述還慢，因為多了「剝除 AI 假設噪音」這一層。
鐵證——AI 假設與真實情境不符的案例
WooCommerce 客戶貼 ChatGPT 給的 add_action 掛 woocommerce_thankyou 的 50 行 PHP，問是否採用。背後問題：
- 你要的是訂單通知還是資料備份？（用途未定義）
- 為什麼不用既有 webhook 而要寫資料庫？（替代方案未檢視）
woocommerce_thankyou在綠界 ATM 等金流會延遲觸發（情境未驗證）- 自訂資料表有沒有跟其他系統串？（架構未確認）
- 需求是一次性還是會長出更多欄位？（時間軸未討論）
解方：把 AI 用在描述端不是解法端
| 用法 | 對工程師價值 |
|---|---|
| 貼 AI 寫好的程式碼 | 低（工程師要逆向挖問題） |
| 用 AI 整理問題說明、列出情境、釐清「期望 vs 現況」 | 高（工程師直接針對真實問題判斷） |
對應方法是「描述問題的三層素材」：文字描述問題本身、截圖目前畫面或錯誤訊息、描述「期望發生什麼」與「實際發生什麼」的落差。
前提與局限性
- 假設客戶不具備完整的環境視野（外掛、資料庫、現有 hook、未來金流）
- 若客戶是技術背景 PM 或本身寫 code，能把完整環境寫進 prompt，貼 AI 答案 + 原始 prompt 是高效做法
- 一次性低風險小修改情境下，採用 AI 程式碼成本可能比追問問題低
- 對極端定型的需求（標準 API 串接、廣告碼安裝），AI 假設可能足夠
衝突標記
無。
關聯概念
- [[創業痛點怎麼找|腦補需求]] — 鏡像版本：生產端腦補 vs 消費端腦補
- [[engineer-identity-crisis|工程師身份認同危機]] — 工程師從寫程式者轉為解決問題者，本概念是這個轉變在需求端的鏡射
- [[screenshot-driven-development|截圖驅動開發法]] — 截圖比文字精準的原則套用到需求溝通
- [[ai-people-pleasing|AI 討好行為]] — AI 給確定性解法的傾向是腦補解法的供給端源頭
- [[ai-as-amplifier|AI 是放大器]] — AI 需要真實情境作為被放大的內容
- [[ai-product-raw-material-model|AI 產品原料模型]] — 把 AI 當原料、人加工的模型對應「AI 用在描述端」
- [[behavioral-interview-method|行為訪談法]] — 訪談的「問現象不問意見」呼應接案的「描述現象不貼解法」