用 AI 開發久了會發現一件事：當 AI 無法做出預期的效果時，多半不是 AI 不夠強，而是你根本沒把需求裡的未知數講清楚。模型越來越聰明，一句話就能生出一整個功能，但它生得對不對，卡在你有沒有能力先搞清楚「這件事到底有哪些你還沒想到的地方」。這篇想談的不是又一個教你用 AI 寫程式的工具清單，而是動工前怎麼系統性地把這些未知數挖出來。
先給一個直接的答案：AI 開發翻車的真正原因，通常是你以為需求已經講完了，但實際上你只講出了自己想得到的部分，那些「你不知道自己不知道」的部分，AI 只能用猜的，猜錯了就整段重做。要少踩這種坑，重點不在提示詞寫得多漂亮，而在動工前先把盲點攤開。
好的師傅動工前，會先到現場勘查
你找室內設計師，跟他說「我想把這間隔成兩房、廚房要開放式」。這是你的需求。但這個需求能不能實現，其實取決於一堆你站在空屋裡看不出來的東西：那面牆是不是承重牆、水管電線怎麼走、管委會准不准動格局。你講的是你想像中的樣子，真正決定成敗的，是現場那些你沒注意到的條件。
AI 開發是一樣的邏輯，你給 AI 的需求是你腦中想像的成品，AI 真正要動的，是那間你未必完全熟悉的房子：現有的程式碼、資料表結構、既有的商業邏輯，需求描述得再仔細，也只是「你看得到的那一面」，牆裡的管線你沒提，AI 不會自己知道，它會照著你的需求很順地做下去，直到撞上那根你沒說出口的承重牆。
差的師傅拿了需求單就開工，做到一半才發現牆不能拆、只好打掉重做；好的師傅會先到現場勘查，把你沒注意到的限制一條一條先問清楚。跟 AI 協作的品質，差別就在這裡——你有沒有在動工前，先把「需求」和「現場」之間的落差找出來。這些落差，就是未知數。
未知數其實有四種，最貴的是第四種
未知數不是只有「知道」跟「不知道」兩種。把它拆成四格會清楚很多，我用接案常見的情境來對照：
| 類型 | 白話 | 接案例子（幫客戶做預約系統） |
|---|---|---|
| 你知道你知道的 | 講得出來的需求 | 「要能線上預約、選時段、發確認信」 |
| 你知道你不知道的 | 知道自己還得確認 | 「金流要串哪一家還沒定」 |
| 你不知道但其實你懂的 | 沒講、但一提就認得 | 「啊對，同一個時段不能被兩個人訂走」 |
| 你不知道你不知道的 | 完全沒想到的 | 「時區、夏令時間、客戶臨時改預約要不要退款」 |
前三種都還好處理，第一種你會寫進提示，第二種你會主動問，第三種只要有人提一句你馬上點頭。真正會讓專案在上線前一天爆炸的，是第四格——你不知道自己不知道的那些。你不會去問一個你根本沒意識到存在的問題。
有意思的是，這一格剛好是 AI 現在最能幫上忙的地方，它讀過的東西比你多，你進到一個陌生領域時，它反而能先幫你指出「這裡通常會有這些你沒想到的問題」。
動工前，先讓 AI 幫你找盲點
大部分人用 AI 開發的順序是：想到什麼 → 直接叫 AI 做 → 看結果不對 → 再改。這個迴圈的問題是，你是在「做完之後」才發現未知數，改起來最貴。比較好的做法是把發現未知數這件事，挪到動工之前。以下幾個動作是我實際在用的方法。
1. 盲點掃描：進陌生領域先問「我漏了什麼」
要進一個你不熟的領域時，不要急著叫它寫，先叫它幫你盤點你不知道的東西。直接把「盲點」「我沒想到的未知」這種詞講出來，它會很好地接住：
我要在這個網站加一個 LINE 登入功能，但我對這個專案的會員 API 不熟，先不要寫程式，幫我做一次盲點掃描，列出我可能沒意識到、但會影響架構的未知數。
它可能會回你：LINE 不一定給 email、同一個人用不同登入方式要不要合併帳號、既有會員怎麼綁定。這些如果等到寫完才發現，往往要動到資料表結構。這個階段也是可以適當提供它上下文的地方。譬如說，你知道你要做的這個功能有一個大概的方向，以開發來說，我就會先給它 API 文件，讓它直接透過 API 文件來探索這個陌生領域。
2. 原型測試：人是看到才知道要不要的動物
很多未知數不是用想的想得出來，是要「看到具體的東西」才會浮現。與其在腦中空想介面該長怎樣，不如叫 AI 先做幾個差很多的版本讓你挑：
幫我用單一個 HTML 檔，做四個風格不同的工具列設計，資料先用假的，我要看了之後才知道我要什麼。
你盯著四個版本看的當下，會突然冒出一堆「這個不行、因為我們的商品有變體」這類原本講不出來的條件。原型的價值不在成品，在它逼你把隱藏的偏好講出來，這也是 AI 開發最被低估的用法：不是拿它做最終產品，是拿它當「把未知數逼出來」的工具。
3. 逐題訪談：一次問一題，先問會改變架構的
一次丟一大包問題給你，你會累、會隨便答。好的訪談是一次一題，而且順序有講究——先問那些「答案不同、整個做法就會不同」的問題：
針對這個需求裡任何模糊的地方，一次問我一題，優先問那些我的答案會改變架構的問題。
這句提示很短，但改變很大。它把 AI 從「等你把需求講完美」變成「主動幫你把需求問完整」，而且不會用一堆無關緊要的細節淹沒你。這跟接案時做需求訪談是同一件事，只是對象換成 AI。關於怎麼問出客戶沒說出口的真實需求，其實跟這裡的邏輯完全一樣。
4. 給原始碼，不要給截圖
要 AI 參照某個東西時，能給原始碼就不要給截圖或文字描述。截圖只是外觀，是你看得到的那一面；原始碼才是它真正的行為，就像牆漆得再漂亮，管線怎麼走還是得拆開牆才看得到：
這個外掛的
class-scheduler.php裡的重複預約檢查邏輯，正是我要的行為。讀它、然後在我的專案用一樣的語意重做一遍。
給它看實際跑的程式碼，它重現出來的行為會準得多；給它看你的轉述，它只能還原你理解的版本，而你的理解本身可能就漏了東西。
5. 先產出實施計畫，確認了再動工
前面幾步做完，最後叫它把整理好的需求寫成一份實施計畫——要動哪些檔、分幾步、每步的預期結果。你看過、點頭了，才開始寫。這份計畫，就是一份把現場都勘查過、標好每根樑柱位置的施工圖。到這一步，大部分的未知數已經在動工前被攤開，剩下的才是真正該讓 AI 放手去做的部分。
動工中和動工後，各留一個小動作
動工前是重點，但有兩個小動作能讓後面更省事。
動工中留一份實施筆記，讓 AI 在做的過程中，把「遇到計畫沒寫到、需要你自己決定」的地方寫進一個臨時檔案，這樣事後你能一眼看到它在哪裡偏離了原本的想法、做了哪些你沒授權的判斷，而不是等出問題才回頭猜。
完工後叫它整理出一份文件，這聽起來有點反直覺，但很有用：
把這次的改動整理成一份文件，說明改了什麼、為什麼這樣改，最後附一份針對這次改動的小測驗，我要能答對才算真的懂。
AI 開發最大的風險，是你合併了一堆自己其實看不懂的程式碼。用文件逼自己看過一遍，看不太懂的話就代表是 AI 的知識不是你的，這一步是把「AI 幫我做完」變成「我真的掌握了」的分界線。
交給 AI 不是問題，全交給 AI 才是
AI 開發最容易被誤解的地方，是很多人以為它的精神是「都交給 AI、我不用懂」。實際上剛好相反：當寫程式這件事變便宜之後，值錢的部分從「會不會寫」移到了「能不能把要做的事想清楚」。而想清楚有很大一部分就是有沒有能力找出自己的未知數。
這跟我先前聊過的上下文工程是一體兩面：上下文工程是把「已知」餵對、餵準，找未知數則是把「還不知道的」先挖出來。兩件事做好，AI 才有辦法真的把你腦中的成品，蓋成現場立得起來的東西。我在告別 Elementor 那次改版最深的體會也是這個——真正花時間的從來不是叫 AI 寫，是先把「我到底要什麼」講清楚。
所以下次要開一個新任務、又覺得需求好像還有點模糊的時候，別急著叫 AI 開工。先花十分鐘，讓它幫你做一次盲點掃描、丟幾個原型、一題一題問你。這十分鐘挖出來的未知數，通常比你事後重做省下的時間多得多。