[VibeCoding] AI Vibecoding 的地基（下）：五層架構的實作 Prompt
上篇談了為什麼要蓋這五層基礎建設、順序該怎麼排。這篇是實戰版——每一層實際該怎麼下
prompt，內容直接照抄可用（把 <...>
換成你專案的實際內容即可）。範例延用上篇的 NorthWind 情境。
這五層裡有些東西該不該進版控、要不要跟團隊共用、`.gitignore` 怎麼設——每個團隊的答案都不一樣， 跟公司規範、團隊人數、內容機敏程度都有關。這篇的 prompt 全部略過這一段， 執行前你要自己先想清楚這個決定。
1 Layer 1：靜態地圖產生器
最先做這個——地基，成本最低、最快看到效果。
這支 prompt 的目標不是要 AI「一次生出完美地圖」，是要它先跟你確認專案特性， 再幫你寫一支可重複執行的產生器（純程式掃描，不靠 AI 現場生成）。
我想幫這個專案（後端 <技術棧，例如 .NET 8> + 前端 <技術棧，例如 Vue 3 + Vite>） 建立一套「AI 可以按需查詢」的語意地圖，取代目前 AI 每次都要整包掃描原始碼的作法。 請先讀過專案結構，不要馬上動手寫程式，先跟我確認以下幾件事： 1. 後端的路由慣例、DI 註冊慣例、資料存取方式（ORM 還是手寫 SQL） 2. 前端是 SPA 還是 MPA、有沒有用到「元件自動全域註冊」這類框架魔法 3. 專案規模大約幾個檔案，決定要不要把反向索引拆成 JSON 確認過後，幫我寫一支可重複執行的產生器，輸出到 <你的路徑，例如 .ai/maps/> 底下， 至少要包含： - PROJECT_MAP：專案總覽 + 檢索指南（「你想做什麼事，該查哪一份」的對照表） - FEATURE_SLICES：以「功能」為單位，一次列出前後端所有相關檔案 - crossmap：前端函式 ↔ URL ↔ 後端 Controller/Action 對照表 - backend-di：Service 的生命週期與註冊位置 - backend-api：Controller 的完整路由與建構子相依 - backend-entities：資料表欄位對應到哪個 Entity 檔案 - 前端反向索引（JSON）：元件被誰用、模組被誰 import、Store/API 匯出了哪些函式 硬性規則： - 每份輸出檔開頭要帶上「產生時間 + 目前 commit/branch」當時間戳 - 全部檔案都要能重新產生、可以直接覆蓋重寫，不需要人工維護內容 - 依檔案預期大小分級：小檔案可以整份輸出成一份文件；反向索引筆數多的 （例如超過幾百筆），輸出成 JSON，用「查詢單一 key」的方式取用， 不要輸出成一份要整份讀的大文件
故意要求「先確認、不要馬上寫」，是因為每個專案的路由慣例、框架魔法都不一樣—— 讓 AI 先花一輪對話摸清楚你的專案，之後產出的規則才會準，不然很容易套用它自己 熟悉的另一種專案慣例。
2 Layer 0：閱讀紀律
地圖蓋好的當下就要寫，不要事後補，不然地圖越詳細越幫倒忙。
這支 prompt 要求 AI 去實際量測地圖檔案的大小，而不是憑感覺訂規則——這點很重要， 上篇提過的 40 倍 token 落差，就是靠這層紀律撐出來的。
地圖已經產生在 <你的路徑> 底下了。現在請幫我把「怎麼讀這些地圖」的規則寫進 <你的專案入口說明文件，例如 CLAUDE.md>，這份文件每次對話都會自動載入，規則要精簡。 請實際去看一下每份地圖檔案目前的大小，然後： 1. 訂一個大小門檻（例如 20KB），超過門檻的檔案，規則要求「先用關鍵字定位到行號， 再取那一段」，不要整份 Read；門檻以下的可以整份讀 2. JSON 類的反向索引，規則要求「一律用程式化查詢單一個 key，不要整包讀」 3. 挑一份體積最大的原始資料（如果有的話），直接寫「禁止讀取」 4. 幫我挑 2~3 個最常見的開發任務（例如「追一支 API 的前後端影響範圍」 「改共用元件前評估影響」），實際示範一次「該用哪些指令、依序查哪些檔案」， 寫成可以照抄的查詢配方 5. 額外提醒：如果搜尋沒有限定資料夾，可能會掃到建置產物（bin/obj/wwwroot/ node_modules 這些目錄底下的壓縮檔），規則裡要明講排除方式 最後幫我確認一次：這份文件本身長度會不會太長？它是每次都要載入的， 只放「每次都需要」的規則，細節留在地圖檔案裡就好。
最後那句「確認長度會不會太長」是刻意加的自我檢查——這份文件會被每次對話自動載入， 寫太多規則等於每次都在燒 token，跟整套機制的目的矛盾。讓 AI 自己審視一次， 比你事後才發現這份文件膨脹到失控好。
3 Layer 2：風格範本
等真的出現「這件事會重複做」的訊號才動手，不要預先猜測有哪些模式。
分兩支 prompt：先建立臨摹源，之後日常開發時照兩步驟模板走。
3-1 挑選並建立臨摹源
專案裡最近開始重複出現「<你觀察到的重複模式，例如新增一個標準查詢頁 + CRUD>」 這種功能，我想建立一份臨摹源，讓之後每次新增類似功能時，AI 可以照抄一個現成、 寫得最好的範例，而不是憑空生成。 請幫我： 1. 從 <你的功能列表 / FEATURE_SLICES 索引> 裡，找出「涵蓋面最廣、還在維護、 寫得最標準」的一個功能切片當候選，列出 2~3 個並說明各自優缺點 2. 針對我選定的切片，列出它前後端所有相關檔案的完整路徑 3. 寫一段「貼給實作端 AI 的句子」，內容包括：完全參考哪幾個檔案的三層調用鏈／ 命名習慣／錯誤處理寫法，不要引入新套件、不要改變既有寫法 4. 如果這個切片有已知的不標準之處（例如用了比較少見的變體寫法），要註明， 並指出「主流寫法」該參考哪一個切片替代
3-2 日常開發：兩步驟模板
這兩段是日常用的，不是設定用的——規劃跟實作分開下，交給同一個或不同的 AI 都行， 重點是分兩段跑，不要一次全包。
【Step 1・規劃】 請讀 <你的地圖索引檔>。 需求：<描述你要做什麼> 起點：前端 <頁面/模組名> / 後端 API <URL 或功能名> 請 trace 前後端調用路徑，輸出「要改哪些檔案（完整路徑）+ 每個檔案要改什麼」的 極簡實作步驟。 規則： - 不要貼完整程式碼，只要步驟 - 不要整包掃描資料庫層或功能層目錄，需要細節時用地圖定位到單一檔案再讀 - 新增 Service 要記得列出「回對應的註冊檔登記」這一步 - 新增 Repository 要遵守專案的自動註冊命名慣例 【Step 2・實作】 依照以下實作步驟修改： <貼上 Step 1 產出的步驟> 請完全參考 <你的臨摹源路徑> 的三層式調用鏈、命名習慣、錯誤處理寫法， 以及前端 <對應目錄> 的結構，來實作新的功能。 不要引入新套件、不要改變既有寫法、不要用相對路徑 import。
4 Layer 3：事實庫
永遠是事後累積——先建好格式規則，內容等真的踩雷才補。
4-1 建立三份檔案的格式規則（只做一次）
我想建立一份「人工驗證過的事實庫」，跟地圖不一樣——地圖是自動產生、可以隨時 重建的，這份是每一筆都要測試過才能寫的，遺失了要重新花代價才補得回來。 請在 <你的路徑，例如 .ai/knowledge/> 底下建立三份檔案： - ground-truth-backend-logic.md：某個欄位/數值實際的根源資料，記到 Repository 層為止 - ground-truth-backend-setting.md：某個判斷條件/數值實際定義在哪個設定檔的 哪個 key - ground-truth-frontend.md：某個欄位/清單在前端實際是從哪個 store state / API 回傳組出來的 每份檔案開頭寫清楚： 1. 只記錄「需要測試才能確定」的部分，不要記「現在誰在消費它」——後者隨時 可以重新查，寫死了會過期 2. 格式是「### 主題」+ 一行 `=>` 鏈路 + 路徑，只在真的有分支條件時才加 「例外：」，需要長篇解釋時用「詳見：」連到別的文件，不要整段塞進來 3. 需求文件寫的內容跟這裡衝突時，以這裡為準
4-2 日常開發：踩雷後隨手記一筆
我在開發 <你的任務> 時，發現 <某份需求文件/某個假設> 講的 「<欄位/數值>」來源可能是錯的。 請幫我實際 trace 一次，追出它真正的權威來源（哪張表、哪個 Repository 方法， 或哪個設定檔的哪個 key），追完之後： 1. 先跟我確認你追到的結論，不要自己假設 2. 確認無誤後，用固定格式幫我補一筆進 <對應的 ground-truth 檔案> 3. 只記錄追到的結論本身，不要寫「原本以為是什麼」這種對照敘述
4-2 這支 prompt 建議存成片語/snippet，之後每次真的踩雷就直接呼叫，不用重打。 這是整套機制裡使用頻率最高、但單次成本最低的一支。
5 Layer 4：深度研究筆記
出現得最晚、也最容易失控——先累積幾份文件，再回頭做索引與防發散設計。
5-1 請 AI 完整 trace 一個子系統
我想搞懂 <某個複雜子系統，例如「訂單狀態機與鎖定機制」> 到底是怎麼運作的， 之前沒人整理過，全靠讀程式碼現場拼湊。 請幫我完整 trace 一次，範圍包含：資料庫欄位、後端邏輯、前端呈現，以及你在過程中 發現的任何「防呆規則」或「反直覺的設計」。 追完之後，寫成一份研究筆記，存到 <你的外部知識庫路徑>/<日期>_<主題>/ 底下，格式不拘，但結尾要條列出「開發這個子系統時必須遵守的硬性規則」， 每一條附上為什麼。
5-2 建立索引檔＋防發散規則（累積幾份筆記後再做）
請幫我重新掃描 <你的深度研究筆記資料夾>，建立一份索引檔到
<主專案>/<你的路徑>/research-notes-index.md，裡面要包含：
1. 每個主題資料夾對應的確切文件路徑（精確到檔案，不是資料夾），以及檔案大小
2. 防發散規則，至少包含：
- 只開索引指定的那一份文件，讀完就停
- 就算文件內文提到其他主題名稱，除非任務明確需要，不要跟著點開
- 絕不直接開外部知識庫自己的總覽文件（那份可能過期，也可能一開就是
全系統概述）
- 單一任務最多開幾份文件，超過這個數字要先停下來確認範圍
3. 超過一個大小門檻的文件，要求先 grep 定位再取段落，不要整份讀
最後，也請你順便確認一下外部知識庫自己的總覽文件，索引是不是完整、
有沒有主題資料夾沒被列進去。
最後一段「順便確認總覽文件是不是完整」不是多餘的——上篇提過，這種索引檔很容易 被人忘記維護，讓 AI 順手核對一次，比等到哪天真的漏查才發現划算。
串起來：五支 prompt 的實際下法順序
- Layer 1 地圖產生器 prompt，跑完拿到一批可查詢的地圖檔
- Layer 0 閱讀紀律 prompt，把「怎麼讀」寫進專案入口文件
- 開始日常開發，先觀察，不急著做 Layer 2／3／4
- 重複模式出現 → Layer 2 的 3-1 建臨摹源，之後每次開發用 3-2 兩步驟
- 踩到資料來源的雷 → 隨手用 Layer 3 的 4-2 記一筆（4-1 的格式規則先設好，只做一次）
- 複雜子系統真的搞不懂 → Layer 4 的 5-1 請 AI trace 一次；累積幾份後再用 5-2 建索引
五支 prompt 都是起手式，不是一次到位——每一支跑完，實際看過產出、依你的專案微調用詞， 比照抄不改更重要。地圖跟閱讀紀律值得花時間調到順手，剩下三層則是每次用、每次都會 自然變得更貼合你的專案。
留言
張貼留言