AI 開發前先找出未知數 | 五個動工前的需求盤點方法
AI 文章延伸
選擇平台後可直接帶入閱讀脈絡，快速整理重點、補齊盲點，並延伸到同站相關文章。
當 AI 開發做不出預期效果，我們的第一個判斷通常不是「換更強的模型」，而是回頭問一句：這次的需求，到底有多少未知數沒被講出來。做過幾十個案子之後，我們發現失敗的專案有個共同點——不是 AI 不會寫，是根本沒把要做的事想清楚就開工了。
隨著 AI 寫程式的門檻一路降低，值錢的部分也悄悄換了位置，以前值錢的是「會不會寫」，現在值錢的是「能不能把要做的事想清楚」，而想清楚的第一步，是先承認自己有一堆還不知道的未知數。
動工前的勘查：AI 開發的未知數藏在哪
找室內設計師裝潢，好的師傅不會一聽到「我想把客廳打通」就拆牆。他會先到現場走一圈，量尺寸、看管線、敲敲牆面，然後告訴你哪一面是承重牆不能動、哪裡的水電要繞路。這些限制屋主自己看不出來，卻決定了整個工程能不能做、要花多少錢。
AI 開發也一樣。一個看似簡單的需求，底下往往埋著現有程式碼結構、資料表關聯、既有商業邏輯這些隱藏條件。急著叫 AI 開工，就像沒勘查就開始拆牆，做到一半才發現卡在承重牆上。
問題是，AI 不會主動幫你勘查——除非你先知道要請它勘查什麼。
四種未知數：最危險的是你不知道你不知道的
要盤點需求，得先知道未知數長什麼樣子。我們把它分成四類，用一個線上預約系統當例子：
| 類型 | 定義 | 預約系統的例子 |
|---|---|---|
| 你知道你知道的 | 講得出來的需求 | 線上選時段、送出預約、發確認信 |
| 你知道你不知道的 | 知道自己還得確認 | 金流要串哪一家還沒決定 |
| 你不知道但其實你懂的 | 沒講，但一提就認得 | 同一個時段不能被重複預約 |
| 你不知道你不知道的 | 完全沒想到的 | 跨時區顯示、夏令時間、退款政策 |
前三類都還有救，因為它們遲早會浮出水面。真正會讓專案翻車的是第四類——那些你連「該問」都沒意識到的問題。等到客戶下訂之後才發現系統把日本客人的時段算錯一小時，重做的成本遠比動工前多花的功夫高。
有意思的是，第四類雖然最危險，卻剛好是 AI 最能幫上忙的地方。AI 讀過的案例比任何一個人都多，時區、夏令時間、退款這些坑它見過太多次。前提是，你得主動請它把這些未知數挖出來。
五個動工前的需求盤點方法
以下五個方法，是我們在動手叫 AI 寫程式之前會固定跑一遍的流程。它們不是要你寫出完美規格，而是要把藏著的未知數盡量逼到檯面上。
一、盲點掃描：先叫 AI 別寫程式
最直接的做法，是把需求丟給 AI，然後明確要求它先別動手：「先不要寫程式，幫我做一次盲點掃描，列出這個需求裡我可能漏掉、需要先確認的東西。」
AI 會回給你一串問題清單，裡面通常有一半是你原本沒想到的。這一步花不到五分鐘，卻常常能把第四類未知數裡最要命的那幾個提前撈出來。
二、原型測試：人是看到才知道要不要的動物
有些需求，用講的永遠講不清楚，要看到畫面才知道對不對。我們會請 AI 一次做出幾個風格差異大的原型，攤開來一起看。
看到具體的畫面，隱藏的需求會自己冒出來——「這個按鈕不該放這」「原來我還需要一個篩選功能」。這些在純文字討論階段死都想不到的東西，一看到原型就全部認出來了。
三、逐題訪談：一次只問一題
盤點需求跟訪談客戶其實是同一件事，差別在於，很多人習慣一次把十個問題全丟出去，結果對方挑三個好回答的回，剩下的石沉大海。
我們的做法是一次只問一題，而且優先問那些「答案會改變架構」的問題。先問「同時段要不要防重複預約」，再問「按鈕要圓角還是直角」——把會動搖地基的問題排前面，避免地基還沒定就開始糾結油漆顏色。
四、給原始碼，不要給截圖
要 AI 理解一個現有系統怎麼運作，給它實際的程式碼，比給截圖或文字描述有用得多。截圖只能告訴 AI「畫面長這樣」，程式碼才能讓它讀懂「行為邏輯是這樣」。
這裡要補一個常被搞混的地方：截圖不是沒用，而是看你要傳達什麼。要對齊 UI 設計、消除視覺歧義，截圖是最好的 source of truth；但要讓 AI 判斷一段功能的真實行為，就得把原始碼餵給它。搞錯這兩者，AI 就會拿著錯的素材腦補出錯的假設。
我們遇過一個真實案例：客戶把 ChatGPT 給的、掛在 woocommerce_thankyou 上的 50 行 PHP 貼過來問能不能用。光看程式碼沒問題，但它底下藏了五個沒人確認過的假設——這段要做訂單通知還是資料備份？為什麼不用既有 webhook？woocommerce_thankyou 在綠界 ATM 這類金流會延遲觸發，情境驗證過嗎？自訂資料表有沒有跟其他系統串？未來還會長出更多欄位嗎？把原始碼和真實情境一起攤開，這些未知數才藏不住。這也是我們一直強調別把 AI 回答原封不動貼給開發者的原因。
五、產出實施計畫再動工
前面四步挖出的東西，最後要收斂成一份實施計畫，就像施工圖標好每根樑柱的位置。這份計畫至少要講清楚三件事：整理好的需求、預計改動哪些檔案、分成哪幾個步驟做、每步預期的結果是什麼。
確認這份計畫之後才動工，AI 才知道自己在整張圖的哪個位置。這一步和我們先前談的用規劃 Agent 打好 AI 開發地基是同一個精神——差別只在於，那篇談的是怎麼用工具自動拆解，這篇談的是動工前你自己得先想清楚什麼。
動工中與動工後：讓 AI 記錄偏離與驗證理解
盤點做得再細，實作過程還是會出現計畫沒料到的狀況。我們會請 AI 在動工中隨手記下「這裡偏離了原本計畫，原因是什麼」，這份紀錄後面回頭檢視時特別有用。
動工結束也還沒完。我們會請 AI 整理一份文件，說明這次到底改了什麼、為什麼這樣改，然後給自己出幾道小測驗，確認我們是真的看懂了結果，而不是看著一片綠色的測試通過就以為沒事。畢竟這些方法適用於任何與 AI 合作開發的層級——不管你是全交給 AI 跑，還是逐行盯著改，動工前的盤點都是共用的前置關卡。
交給 AI 不是問題，全交給 AI 才是
要不要把工作交給 AI，從來不是問題。問題出在「全交給 AI、自己完全不用懂」的那個「全」字上。
我們的經驗是，AI 開發真正的精神是三件事：想清楚要做什麼（把未知數挖出來）、把需求說對（做好上下文工程）、真正掌握結果（用文件和測驗驗證）。這三件事，沒有一件是 AI 能替你完全接手的。
下次開一個新任務，先別急著叫 AI 開工。花十分鐘做盲點掃描、看幾個原型、逐題確認——這十分鐘挖出來的未知數，通常比事後重做省下的時間多得多。
常見問題
動工前盤點需求，會不會拖慢 AI 開發的速度？
短期看是多花了十幾分鐘，長期看是省時間。AI 開發最貴的成本不是寫程式，而是需求沒講清楚導致的整段返工。把未知數提前挖出來，等於用十分鐘的盤點換掉可能兩天的重做。
需求還很模糊的探索性專案，也要先寫實施計畫嗎？
不一定。實施計畫適合需求方向已經明確的專案；如果是連要做什麼都還在探索的階段，過度規格化反而是阻力，這種情況下，前四步（尤其是原型測試）的價值遠大於硬寫一份計畫。
盲點掃描和上下文工程有什麼不同？
盲點掃描是「找出你還不知道的需求」，上下文工程是「把你已知的資訊正確餵給 AI」，前者處理未知數，後者處理已知條件，兩者一前一後，都是動工前的功課。
小型、一次性的修改也要跑完這五個方法嗎？
不用。標準 API 串接、廣告碼安裝這類定型又低風險的小修改，AI 的預設假設通常就夠用，硬套完整流程反而累贅。這套方法真正的價值在「有隱藏條件、會長期維護」的專案上。
Google 偏好來源
喜歡我們的內容嗎？一鍵將我們設為偏好來源，未來在 Google 焦點新聞與 AI 概覽中就能優先看到我們的文章。