給不會寫程式、但要指揮 AI 蓋出一個真實系統的人的一組追問。它們出自條條大路通財神那次盲點掃描的結論：
| 詞 | 問的事 |
|---|---|
| Scope | 這次做多少 |
| Source | 資料哪裡來 |
| Schema | 資料怎麼存 |
| Logic | 結果怎麼算 |
| State | 哪些東西要保存 |
| Failure | 壞掉時怎麼辦 |
| Security | 怎麼防濫用 |
| Ownership | 三個月後誰看得懂 |
原文的說法是，只要任何功能都逼自己回答這八個問題，就已經不是在用「完全不懂建站的人」的方式指揮 AI，而是在做技術 Product Owner 該做的工作。
順序才是真正的內容
八個詞本身不難記，難的是它們有先後。盲點檢查列出的決策順序是：
產品目標 → MVP 範圍 → 資料來源 → 資料模型 → 計算規則 → URL 與 SEO 架構 → 技術架構 → UI → 程式 → 測試 → 部署 → 監控。
新手最自然的順序幾乎完全相反——先叫 AI 畫首頁、加動畫、做地圖、接 AI，然後發現沒有資料、發現資料不能用、重寫資料庫、發現 SEO 不行、再重寫 framework。
這條順序與動手之前先想清楚收攏的框架群同構，但它處理的不是思考而是建造，而且把最貴的返工點標了出來：資料模型與計算規則一旦錯了，UI 與程式全部要重來。
Ownership 是最容易被跳過的一個
前七個詞多少會被想到，第八個不會。盲點檢查把它單獨拉出來當成 vibe coding 最嚴重的風險，理由不是 AI 寫的程式不好：
AI 每一次修 bug，都順便把架構改一點。
三個月後的症狀被寫成一串問答：為什麼這個 API 在這？不知道。為什麼有 KV 又有 D1？不知道。這個 table 誰建立的？不知道。刪掉會怎樣？不知道。
對策是要求 AI 維護工程文件，尤其是 DECISIONS.md——用 Architecture Decision Record 的格式，一條記一個決定、原因與影響。原文給了這個作法一個很準的定位：
它其實是給未來 AI 的記憶。
這句話讓它與LLM Wiki變成同一件事的兩個場合。那座 wiki 解的是「模型下次進來時，怎麼知道之前想過什麼」；ADR 解的是「模型下次進來時，怎麼知道之前為什麼這樣蓋」。兩者都不是寫給人看的文件，是寫給下一次的上下文。
把指令變成固定格式
盲點檢查不接受「幫我做財神地圖」這種指令，要求每次大型指令固定提供十項：Goal、User story、Scope、Data source、Architecture、Privacy、Security、SEO、Acceptance criteria、Documentation。
其中 Acceptance criteria 被特別標明極重要——不能說「做好」，要寫成可逐項檢查的條件，例如 localhost 可運行、production 可部署、手機 Safari 正常、空資料不 crash、API fail 有 fallback、migration 可重新執行。
另有一段十二點的常駐前綴，要求 AI 擔任的角色是 Senior Full-stack Engineer 而非單純寫程式，並明令：不要假設使用者知道隱含的技術決策、修改前先檢查現有架構、不得因完成單一功能而任意改變整體架構、不得把 secrets 寫進 repository、不得捏造資料、schema 修改必須走 migration、若需求會製造明顯技術債要先指出。
原文的評語是這一段比「請幫我寫得專業一點」有效得多。
四個成熟度
同一份文件把成品分成四級，並指出多數 vibe coding 專案停在第一級：
| 級別 | 長什麼樣 |
|---|---|
| Level 0 Demo | 漂亮 UI、假資料、幾個按鈕 |
| Level 1 MVP | 真實資料、真實計算、基本 SEO、手機正常、有錯誤處理 |
| Level 2 Production | 自動更新、migration、backup、rate limiting、logs、監控、隱私政策、來源紀錄 |
| Level 3 | 資料庫、知識圖譜、地圖、匿名資料、自動化實驗、SEO entity pages、內容 CMS、資料血統 |
判斷品質也不看「有沒有 bug」，而是七個維度：使用者知道下一步做什麼、每個結果能追溯來源、算法可重現、手機能用、重要頁面能被搜尋、API 不可被濫用、出錯時知道哪裡錯。
三個具體的坑
公開資料不等於自由使用。 看得到不代表是 Open Data，不同來源要分開確認授權。作法是每一種資料來源都帶上 source、source_url、license、retrieved_at、last_updated_at、attribution_required 六個欄位，這叫資料血統。
能不存，就不存。 個資的第一設計原則是 data minimization——八字用瀏覽器算完直接顯示、不送到 server；夢境這種高隱私內容只抽匿名關鍵字入庫，不保存整篇。它同時降低法律風險、資安風險、資料庫複雜度與開發成本。
指數不是 UI，是方法論。 一個「財神駐紮指數」如果沒有定義權重與公式，只是「加了好看 CSS 的亂數產生器」。任何指數都要先定義用哪些資料、每項權重、計算公式、缺值怎麼處理、版本編號，並且把版本顯示出來，因為公式未來一定會改。
AI 在系統裡的位置
盲點檢查對 AI 功能給了一組分辨：每次讓 AI 自由回答，娛樂性可以，但同樣的輸入明天會得到不同答案，資料系統無法研究；先建立規則再讓 AI 解釋，AI 的工作變成理解自然語言、找到對應符號、寫出說明，結果可以重現。
這個作法叫 deterministic core + generative interface，而條條大路通財神第一版就是照它實作的：規則先算完，AI 只負責把算出來的東西寫得有趣。
另有一項成本盲點：AI endpoint 如果沒有 rate limiting、驗證與每日上限，被 bot 打的時候「你網站沒壞，你的信用卡先壞」。這不是紅了以後再處理的事，是上線第一天就要有的。
這一組與其他框架的關係
它是未知四象限的產物而不是替代品。四象限提供的是「怎麼找出自己不知道該問什麼」的程序，八個追問是那次掃描在建站這個場域上的具體結果——換一個場域，掃描會長出另一組詞。
它與繼續轉向或放下分屬兩端。那七道關卡問的是「這件事還值不值得做」，這八個詞問的是「要做的話，什麼必須先想清楚」。前者管砍，後者管建。
相關原始筆記
條條大路通財神/02 條條大路通財神 盲點檢查.md— 八個詞、決策順序、十項指令格式、十二點常駐前綴、四個成熟度、十五個坑的出處條條大路通財神/04《條條大路通財神》第一版執行計畫 v0.2.md— 把順序落實成十二道 Gate 的版本