[AI 分享] AI程式設計的盲區管理

摘要 : 模型愈強，AI寫程式的瓶頸愈不在模型，而在於人是否說清需求與管理未知。

內容:

這兩天 Claude Code 團隊工程師 Tarek 發了一篇長文，談怎麼用 Fable5 做更好的 AI 程式設計。表面上看，這是一份工具使用指南，裡面有 prompt、原型、實施計劃，以及程式碼合併前的檢查方法；但更值得注意的，是它點出了 AI 程式設計正在出現的關鍵變化。

過去大家用 AI 寫程式時，常常是在測試模型能力，例如它能不能理解需求、找對檔案、修掉 bug、跑通測試，或像工程師一樣掌握專案上下文。但到了 Fable5 這類等級後，瓶頸開始改變：很多時候，影響工作品質的已經不是模型會不會做，而是人有沒有把那些沒說清楚的地方講明白。

這個判斷很重要。因為 AI 程式設計進入 Agent 階段後，它不只是幫你補幾行程式碼，而是會讀倉庫、改檔案、跑命令、處理跨檔案任務，也會在長時間任務中替你做很多中間決策。這時，Prompt 更像是一張地圖，但真正要進入的是程式碼庫、業務邏輯、歷史包袱、現實限制，以及團隊裡那些沒寫進文件的習慣。地圖再細，也不可能覆蓋所有細節；凡是沒交代清楚的地方，模型就只能自己猜。

也因此，很多人都會遇到一個熟悉的現象：小任務很驚艷，大任務開始發散。像是改一個函式、補一個測試、寫一個腳本，通常效果很好，因為邊界清楚、目標明確，模型不需要替你做太多判斷。但如果讓它做完整功能、改複雜模組，或搭一個產品頁面，它就會開始補完你沒說清楚的部分。它可能替你決定狀態結構、錯誤處理方式、服務層拆法，甚至加入一些看起來很專業、但專案其實不需要的抽象。這些選擇未必錯，真正的問題是：模型不是違背要求，而是在填補你沒說出口的空白。

文中把這些空白分成四類。第一類，是你已經知道，也已經寫出來的內容，例如明確告訴模型要在哪裡加按鈕、按下去要做什麼。第二類，是你知道自己還沒想清楚的地方，例如要不要支援行動裝置、失敗時怎麼提示、權限不足時要顯示什麼。第三類，是你心裡有標準，但平常不會寫下來的東西，例如頁面是不是順眼、互動是不是自然、文案語氣對不對。這些很難事前說清楚，但結果一出來，你通常一眼就知道對不對。第四類最麻煩，是你根本沒想到的問題：你不知道這個領域有哪些坑、不知道程式碼庫有哪些歷史約定、不知道以前的人為什麼這樣寫，也不知道這件事其實可以做到什麼程度。很多 AI 程式設計失敗，就發生在這一類。

這也是為什麼，真正厲害的 Agentic coder，不只是會寫 prompt，而是熟悉程式碼庫、懂模型特性，也清楚自己真正要什麼。他們知道哪些地方必須先問清楚，哪些地方可以交給模型發揮，哪些地方一定要保留回頭修正的空間。換句話說，AI 程式設計的核心能力，正在從「寫一個好 Prompt」，轉向「管理整段協作中的未知」。

Tarek 在文章裡提出了幾個很實用的方法。

第一個方法是 Blind Spot Pass，也就是盲區掃描。假設你要在陌生模組中加入新功能，例如接一個新的認證方式，但你對現有 Auth 模組並不熟。很多人會直接說「幫我接入這個 Provider」，但更好的起點是先請模型做盲區掃描，找出你現在還沒意識到的風險與問題，讓後續提問更準確。這一步的價值在於先承認自己不知道，讓模型先去翻程式碼庫、找既有模式、整理潛在風險，例如哪些權限處理不能忽略、哪些相容性不能漏、哪些地方看似簡單其實會牽動架構。這時 AI 的角色，就不只是執行者，而更像能幫你擴大視野的搭檔。

第二個方法是先做原型。特別是介面、設計、互動這類問題，很多標準不是靠語言就能講清楚。你說「高級一點」、「清爽一點」、「像某個產品一點」，模型未必真的懂，你自己也未必真的想清楚。這種情況下，不要急著直接改真實專案，可以先請模型做一個獨立的 HTML 頁面，用假資料產出幾個方向。等你看到實際畫面後，判斷會快很多：哪個太重、哪個太花、哪個版面對、哪個資訊層級不行。這看起來像繞路，但其實能大幅降低後面返工成本。因為在原型階段發現問題很便宜，等到真實程式碼已經接好狀態、介面、測試，再發現方向錯了，撤回就沒那麼輕鬆。

第三個方法，是讓模型反過來問你。當你有大致方向，但還有很多地方模糊時，不要只是一味把 Prompt 寫得更長，而是可以要求模型一次只問一個問題，而且優先問那些會改變架構的問題。這點非常關鍵，不是所有問題都值得同等對待。像按鈕名稱、顏色細節，之後都還能調；但資料模型、型別介面、權限邊界、使用者流程，這些一旦選錯，後面代價就很高。好的需求澄清，不是問題越多越好，而是能儘快把真正影響方向的問題提到前面。這其實很像一位可靠工程師接到需求後，先確認誰會用、失敗時怎麼辦、哪些輸入合法、哪些行為不能發生、上線後誰維護、舊資料怎麼處理。AI 沒有消滅這些問題，只是讓它們更快浮上檯面。

第四個方法，是給參考。很多時候你說不清自己想要什麼，不是因為表達能力差，而是因為有些東西本來就很難只靠文字描述清楚。你想要某個函式庫的重試策略、某個網站元件的互動、某個工具列的佈局，與其堆砌一堆形容詞，不如直接給參考。Tarek 特別強調，最好的參考往往是原始碼。截圖只能讓模型知道外觀，原始碼則能讓它理解結構、狀態、邊界與處理方式。對 AI 程式設計來說，真正重要的常常不是表面長相，而是實作語義。像是 Rate Limiter 如何處理重試、API Client 如何處理錯誤、元件如何拆分狀態，這些自然語言很容易漏細節，但程式碼反而更精確。

第五個方法，是先寫實施計劃。這不是為了增加流程感，而是為了把關鍵決策提前攤出來給人審視。文中的建議是，讓模型把最可能需要人調整的部分放在前面，例如資料模型、新型別介面、使用者可見流程；至於格式調整、搬移檔案、樣板程式碼這類機械性工作，可以放後面。這背後反映的是一個很現實的事：人的審查精力有限，不可能逐行檢查所有模型生成內容，但一定要盯住那些一旦決定就很難回頭的部分。模型幫你做重構或樣板碼，風險相對低；模型替你決定系統邊界，則必須先看。

此外，Tarek 也建議在實作過程中，讓模型維護一份 Implementation Notes.md，記錄它中途做了哪些決定、何時偏離原計劃、為什麼選了更保守的方案。這個做法看似樸素，但對長任務非常有效。因為長任務最怕的不是模型某一步做錯，而是它默默做了很多你不知道的決策，最後你只看到一個 diff，卻無法還原過程。有了這份實施筆記，至少能幫助你回頭理解：原本計劃哪裡不適用、程式碼裡出現了什麼邊界情況、模型為什麼沒有照原方案走。這樣你拿到的就不只是一堆程式碼，而是一段可被理解、可被追溯的決策過程。

整體來看，這篇文章真正重要的地方，不只是教你怎麼用某個工具，而是提醒我們：當模型能力越來越強，人類工作的重點就越不是下更華麗的指令，而是更誠實地面對自己不知道什麼、沒想清楚什麼，以及哪些決策不能交給模型默默完成。AI 程式設計的難題，正在從模型能力問題，轉向協作與未知管理問題。這可能才是下一階段最值得重視的能力。