他們會這樣考你

Vibe Coding 方法論 · 30 道靈魂拷問

用 AI 寫程式碼這件事，最不缺的就是質疑。這 30 個問題來自三個真實場景：面試官在驗證深度，老闆在追問責任，技術同事在試探邊界。先自己開口回答，再看框架。

怎麼用這一頁
每道題都標註了提問者。他們盯著同一套 AI 協作規範，想聽的東西卻不一樣。
🎙 面試官想驗證你是真用過，還是只看過幾篇公眾號
👔 老闆擔心的是品質、責任和事故
🛠 技術同事在試探你懂不懂工程，值不值得放權
每題給出三層：對方在考察什麼 → 答題框架 → 加分點。答不上來的環節，點末尾的課程頁回去補。
Q1面試官
「你履歷上寫熟悉 Vibe Coding。都讓 AI 寫程式碼了，你還立一堆規矩，圖什麼？」
🎯 對方在考察什麼
開場定調題。考的是你能不能用事故說話。只會說「規範很重要」的人在背套話；真踩過坑的人，張口就是具體事故和對應的規則。答「AI 偶爾會出錯所以要小心」這種正確的廢話，基本就露餡了。
🧭 答題框架
  1. 先說清 Vibe Coding 是什麼：靠自然語言讓 AI 直接產出程式碼的開發方式。它的問題從來出在品質，寫得快只是放大了搞砸的速度。
  2. 甩出四類典型事故：理解偏差返工（改了 7 個檔案才發現思路錯了）、選型漂移（今天 Express 明天 Fastify）、善意破壞（重構時清理掉有用的程式碼）、永久技術債（簡版登入再也沒升級過）。
  3. 點破共同根源：四類事故根源是同一件事，約束沒有進入上下文。AI 每輪對話都可能忘掉你交代過的事。
  4. 給出解法：把約束寫進 Rule 檔案，每輪對話開始前自動載入。對話裡交代會被截斷擠出視窗，寫在文件裡 AI 未必去讀，只有 Rule 是結構上最穩的注入渠道。
⭐ 加分點補一句方法論的生成邏輯：AI 每反覆犯一次錯，就把它變成一條規則。規則的價值在於每條都解決一個真實問題，堆砌條款沒有意義。這句話能證明你理解的是方法，可以直接背下來。
用這些課程頁組織答案 → 為什麼要給 AI 立規矩 規則的價值：每條解決一個真實問題
Q2老闆
「都用 AI 寫程式碼了，出了 bug 算誰的？AI 的鍋還是你的鍋？你敢對品質負責嗎？」
🎯 對方在考察什麼
老闆要的是責任歸屬和品質機制。答「AI 生成的我們都會檢查」等於什麼機制都沒有；把鍋甩給 AI 更不行，那等於承認這套流程不可控。老闆想聽到的是：責任在人，而且有具體的關卡保證人負得起這個責。
🧭 答題框架
  1. 先接住責任：bug 永遠算人的，AI 是工具。這套規範的目的就是讓人在每個關鍵節點都有拍板的機會，出了問題能追溯到具體哪一關放過去的。
  2. 給事前關卡：斷點設在動手之前。AI 寫程式碼前必須複述需求、產出 PRD、拿到明確許可；改超過 3 個檔案先交修改計劃。理解偏差在寫第一行程式碼之前就被攔下。
  3. 給交付底線：兩道硬性檢查。涉及 AI 介面的功能必須真實呼叫過，禁止 Mock 繞過；核心邏輯單元測試不過，不得交付。
  4. 給出事後的修法：真出了 bug，禁止猜測性修復。先加 Log 定位根因，修復前回答三個問題（完整業務流程、影響哪些模組、有沒有同類問題），修完宣告影響範圍，明確該回歸測試哪裡。
⭐ 加分點主動報資料對比：猜測性修復三輪改 47 行 bug 還在，先 Log 一輪定位根因就修乾淨。加 Log 的 2 分鐘，買斷的是猜錯三輪的返工。老闆聽得懂這筆帳。
用這些課程頁組織答案 → 除錯鐵律：先 Log 再改碼 四步流程：複述、PRD、確認、編碼 為什麼要給 AI 立規矩
Q3技術同事
「AI 生成的程式碼你們 PM 也敢直接合？一次改十幾個檔案，誰看得過來？」
🎯 對方在考察什麼
技術同事在試探你有沒有流程意識。他真正怕的是失控的大範圍改動。答「AI 現在很強的，基本不會錯」，他從此不會再放心讓你碰倉庫；答出具體的斷點機制，他會開始把你當同行。
🧭 答題框架
  1. 先糾正前提：不存在直接合。AI 動手前要走四步流程：先思考提問、用自己的理解複述需求、寫出 PRD、拿到明確許可才開始編碼。人不點批准，程式碼不會產生。
  2. 正面回應大改動：修改超過 3 個檔案必須先交修改計劃，寫清三件事：改哪些檔案、每個檔案改什麼、改動之間的依賴關係。審的是計劃，量再大也看得過來。
  3. 補上防擴散的細則：新增功能前先搜尋專案裡有沒有類似實現，防止重複造輪子；新元件先在 PlayGround 做獨立 demo，調好了再整合進主工程。
  4. 說清為什麼規則要寫死：「請先確認理解後再編碼」這種模糊表述沒用，AI 會自己判斷「我理解了」然後直接動手。寫明「寫 PRD、等待許可」這類具體動作，斷點才真的存在。
⭐ 加分點說出閾值的工程判斷：3 個檔案是經驗值，謹慎的專案調成 1，快速原型放寬到 5。簡單的一行改動 AI 自行判斷跳過 PRD，規矩攔的是返工成本最高的多檔案變更。懂得閾值可調，說明你真在專案裡用過。
用這些課程頁組織答案 → 四步流程：複述、PRD、確認、編碼 PlayGround：元件的試衣間
Q4老闆
「AI 說先上個簡版，兩天就能看到東西，我覺得還滿務實的。你為什麼非要攔著？」
🎯 對方在考察什麼
老闆站在了 AI 那邊，你要說服的是人。這題考你能不能把技術債翻譯成老闆聽得懂的成本帳。順著說「好的那就先上簡版」，你就成了技術債的共犯；只會說「有技術債」又太空，老闆要的是數字。
🧭 答題框架
  1. 先戳穿動機：AI 提「先做簡版」往往與複雜度無關，它想快速給你一個能跑的東西換正回饋。「先用臨時方案」「暫時 Mock」「簡單處理一下」背後是同一個模式。
  2. 給成本帳：簡版上線當天補全只要 0.5 倍成本；第 30 天，4 個模組依賴了簡版介面，補全成本升到 3 倍；第 90 天，9 個模組耦合長死，8 倍成本超過重寫。「後續再優化」的後續永遠不會來。
  3. 給規則：禁止以任何理由簡化實現，也禁止 AI 主動規劃分期和 MVP。每次實現都必須是完整、正確、沒有程式碼債的方案。
  4. 把選擇權還給老闆：功能確實太複雜時，正確動作是讓 AI 給出完整方案、真實工作量和前置決策清單，由人決定要不要拆、怎麼拆。拆分是人的決策，降級是 AI 的自作主張。
⭐ 加分點點破一個反直覺的現象：打破「先做簡版」的模式後，AI 反而會更認真地分析完整方案。這條觀察來自真實使用，能說出來就贏了大多數人。
用這些課程頁組織答案 → 不接受分期交付 四步流程：複述、PRD、確認、編碼
Q5技術同事
「上個月那個功能為什麼改成現在這樣，你還說得清嗎？AI 對話一關，決策不就全丟了？」
🎯 對方在考察什麼
這是對 Vibe Coding 可維護性的致命一問。對話式開發的決策預設鎖死在聊天記錄裡，三個月後翻遍 git log 也找不回來。答「我翻一下歷史對話」等於承認沒有沉澱機制；能答出文件體系，才算真把 AI 協作當工程在做。
🧭 答題框架
  1. 承認問題、給出機制：決策確實不能靠對話留存，所以讓 AI 按嚴格模板維護文件，決策跨越對話和時間存活。
  2. 報出三份文件的分工：FEATURES 回答「這個功能怎麼來的」，帶狀態流轉和歷史沿革，方案變更及原因都記檔；CHANGELOG 回答「這次改了什麼」，記根因和影響面；RELEASE_NOTES 回答「使用者得到了什麼」。
  3. 再加一份沉澱品味的：METHODOLOGY.md 記產品原則、設計決策、體驗偏好和反模式。使用者否決過彈窗方案，AI 記進反模式，之後新對話自動繼承，同一個方案不會被提第二次。
  4. 說清為什麼放倉庫裡：決策寫在 Notion 或飛書裡 AI 讀不到。放在專案倉庫內的 Markdown 檔案，才能讓 AI 每次自動取得上下文。
⭐ 加分點補兩條容易被忽略的細則：寫 CHANGELOG 前必須讀系統時間，禁止憑記憶填時間戳、禁止積壓補寫；程式碼註釋要求三要素（背景、設計意圖、關鍵約束），註釋也是給下一輪對話的 AI 看的。
用這些課程頁組織答案 → 三份文件與方法論沉澱 註釋三要素與程式碼保護
Q6老闆
「我刷到過 AI 刪庫的新聞。我們這樣搞，萬一哪天 AI 把生產資料庫弄掛了怎麼辦？」
🎯 對方在考察什麼
老闆在要安全感。答「AI 不會亂來的」是最差答案，因為 AI 確實會：善意的清理、混進發版的臨時改動，都是真實發生過的事故。正確姿勢是承認風險存在，然後把閘門一道一道擺出來。
🧭 答題框架
  1. 先給總原則：不可逆操作的安全感來自閘門。資料庫、配置、部署這類操作，閘全部設在執行之前。
  2. 報出三道閘：第一道備份，未備份不得執行任何 migrate、drop、alter、delete，備份帶時間戳放 backups/ 目錄，成本是一行命令，賭的是整庫資料；第二道回退，動手前說清如何恢復、需要哪些備份、預計恢復耗時；第三道審查，發版前讓 SubAgent 比對實際 diff 和 Release Notes，混進無關改動就暫停發版。
  3. 補上釋出紀律：釋出必須走 GitHub，伺服器透過 git pull 或 CI/CD 拉程式碼。使用者明確確認之前，打 tag、push、部署全部禁止，AI 沒有自行發版的權限。
  4. 順帶把憑證也管住：所有 Key 走環境變數或 secrets，禁止硬編碼。Key 一旦進入 git 歷史等於永久洩露，只能作廢重發。
⭐ 加分點說清 diff 審查的設計意圖：正規團隊靠 CI/CD 加 PR review 攔帶病發版，獨立開發者往往跳過 review 直接 push，讓 SubAgent 充當 reviewer 就是補上這一環。能講出這層，說明你理解規則背後的工程直覺。
用這些課程頁組織答案 → 破壞性操作的三道閘 把環境事實寫進 Rule
Q7面試官
「你說把規矩寫進 Rule 檔案。這檔案到底長什麼樣？我明天新開一個專案，第一步該做什麼？」
🎯 對方在考察什麼
考的是你有沒有真的動手配置過。只會講理念、說不出檔案結構和目錄位置的人，基本是看文章學的。能報出 frontmatter 欄位和三個檔案的分工，才算真落過地。
🧭 答題框架
  1. 先說檔案結構：Rule 檔案帶 frontmatter，alwaysApply: true 用於全域編碼規範，所有對話自動生效；設 false 的用於寫作規範這類按需引用的檔案，避免汙染編碼對話的上下文。
  2. 報出三個檔案：xs_vibe_rules 一共三份。rule-opensource.mdc 是主開發規範，14 個章節覆蓋全流程；writing-style.mdc 管中文寫作風格，按需手動引用；secrets.mdc 是 API Key 與憑證模板，佔位符形式。
  3. 給實作三步：把 .mdc 檔案放進專案的 .cursor/rules/ 目錄，Cursor 自動識別；配置每個檔案的 alwaysApply；把模型配置、技術棧、埠規則換成自己的選型。
  4. 把安全交代掉：secrets 檔案填佔位符並排除出 git。Key 一旦進入 git 歷史等於永久洩露，只能作廢重發。
⭐ 加分點補一句起手式：這套倉庫是 MIT License 開源的，正確姿勢是 Fork 一份、按自己技術棧刪改，改出來的就是你的第一版 AI 協作規範，起點比從零寫高得多。
用這些課程頁組織答案 → 為什麼要給 AI 立規矩 規則的價值：每條解決一個真實問題
Q8技術同事
「你們聊天框的 bug 我看了：中文輸入法一按回車，半截拼音直接發出去了。AI 寫的吧？怎麼保證它下次不再犯？」
🎯 對方在考察什麼
考你對 AI 盲區的認知深度。能說出 isComposing 這個具體 API、並解釋為什麼 AI 必踩這個坑的人，是真的在一線修過 AI 寫的前端。只會說「讓 AI 改一下」的人，下個專案還會踩。
🧭 答題框架
  1. 先給根因：中文輸入法確認候選詞時也會觸發 Enter。程式碼只判斷了 e.key === 'Enter'，沒檢查 isComposing，選詞的回車就被當成了傳送。
  2. 給標準寫法：Enter、非 Shift、!e.nativeEvent.isComposing 三個條件同時滿足才傳送。isComposing 為 true 表示輸入法正在組合中，這時回車只確認候選詞，不觸發傳送。
  3. 解釋 AI 為什麼會犯：AI 訓練資料裡 isComposing 覆蓋率不高，不寫進 Rule 就一定會忘。規則原文寫得很死：禁止只判斷 e.key === 'Enter' 而不檢查 isComposing。
  4. 上升到修法：這個 bug 本身也是「先 Log 再改碼」的教科書案例。加一行 Log 列印 e.key 和 isComposing，一輪定位根因，4 行修乾淨；瞎猜的路線三輪改了 47 行還沒修好。
⭐ 加分點順嘴提一句 !e.shiftKey：標準寫法把 Shift 加回車留給換行，這種細節 AI 也常漏。能背出完整判斷條件的人，一聽就是修過這個坑的。
用這些課程頁組織答案 → 把環境事實寫進 Rule 除錯鐵律：先 Log 再改碼
Q9面試官
「你說元件都先在 PlayGround 裡調好再整合。前端圈有現成的 Storybook，你們為什麼不用？」
🎯 對方在考察什麼
考工程判斷力：你知不知道行業標準方案，以及為什麼在自己的場景下選了更輕的做法。答「沒聽過 Storybook」暴露視野窄，答「Storybook 更專業所以該用」暴露不會算成本。
🧭 答題框架
  1. 先認思路同源：PlayGround 就是簡化版 Storybook 思路，每個 UI 元素有單獨的 demo，調好了再整合進正式頁面。
  2. 差別在成本：Storybook 是行業標準，但配置太重，對 AI 輔助的快速原型專案屬於 overkill。PlayGround 用一個靜態頁面把所有元件 demo 排在一起，成本幾乎為零。
  3. 說清換來了什麼：雙向隔離。改元件不影響業務邏輯，調業務邏輯不搞亂元件樣式。直接寫進頁面的話，調一個按鈕要先把整個頁面跑起來，登入、拉資料、切狀態才能看它一眼，圓角改大了還可能擠歪旁邊的佈局。
  4. 給觸發條件：規則寫明，涉及頁面動效時必須先建立靜態頁面 PlayGround，自由調整測試之後，才允許寫進正式頁面。
⭐ 加分點補一個交付細節：demo 裡調好的參數可以直接抄進正式元件，整合時它已經是成品。試衣間裡改好了再上臺，返工就發生不了。
用這些課程頁組織答案 → PlayGround：元件的試衣間
Q10老闆
「上次演示看起來還不錯，一上線全是問題。後來才知道 AI 介面根本沒通，頁面上全是假資料。這種事你怎麼杜絕？」
🎯 對方在考察什麼
老闆被假演示坑過，要的是交付線上的硬性機制。答「以後我會仔細檢查」等於承認沒有機制，下次還會發生。要給出流程裡寫死的關卡。
🧭 答題框架
  1. 給出禁令：凡涉及 AI 模型呼叫的功能，交付前必須確認介面真的能存取，禁止硬編碼假響應或本地模擬繞過真實呼叫。
  2. 卡住源頭：使用者沒給 API Key 時，AI 必須停下來要，不許自己 Mock 著繼續寫。Key 到位後先發一次測試請求驗證可用性，再繼續開發。「介面沒通」這個最大風險被提前到了開發第一步暴露。
  3. 配上第二道線：核心業務邏輯單元測試不過，不得交付。兩道硬性檢查一起構成交付線。
  4. 點破動機：「暫時 Mock」和「先用臨時方案」「簡單處理一下」是同一個模式，AI 想快速給你一個能跑的東西換正回饋。這些話術在規則裡被同一條款點名禁止。
⭐ 加分點把損失翻譯給老闆聽：假資料的危害是把風險藏到了上線那天才爆。規則把驗證挪到 Key 到位的那一刻，風險暴露越早，處理成本越低。
用這些課程頁組織答案 → 除錯鐵律：先 Log 再改碼 不接受分期交付
Q11面試官
「你做的是 AI 對話產品。調一句提示詞，難道要把整個業務流程跑一遍？平時你怎麼調 Prompt？」
🎯 對方在考察什麼
考 AI 產品的除錯基礎設施意識。提示詞是 AI 產品的核心資產，答不出專門的除錯環境，說明產品還停留在「能跑就行」，談不上迭代。
🧭 答題框架
  1. 給出硬性要求：專案涉及 AI 對話功能時，PlayGround 中必須實現簡單的對話測試頁面，脫離完整業務流程也能單獨調一輪對話。
  2. 把提示詞攤開：這個頁面上必須列出專案用到的所有 Prompt。提示詞藏在程式碼字串裡沒法除錯，攤開在頁面上才能快速對比和調整。
  3. 點破本質：提示詞是 AI 產品的核心資產，要像管元件一樣給它專門的試衣間，調好了再進業務流程。
⭐ 加分點補上維護規則：PlayGround 的 demo 只增改、不刪除，需求取消了對應 demo 也保留，它是設計過程的歷史存檔，未來需求復活時直接撿回來用。
用這些課程頁組織答案 → PlayGround：元件的試衣間
Q12面試官
「AI 寫的註釋我見過，全在複述函式名。你們的程式碼放三個月，自己還看得懂為什麼這麼寫嗎？」
🎯 對方在考察什麼
考你能不能把「寫好註釋」這種空話變成可執行結構。「寫好註釋」四個字 AI 執行不了，能報出固定結構、示例和判斷標準的人，才是真的在管 AI 的程式碼品質。
🧭 答題框架
  1. 先認問題：程式碼只能表達「做了什麼」。為什麼存在、為什麼這樣實現、呼叫時要注意什麼，這些資訊只有寫進註釋才能跨時間留存。
  2. 報出三要素：背景（解決什麼業務問題、什麼場景被呼叫）、設計意圖（為什麼選這個方案、放棄了哪些備選，git log 裡找不到這些）、關鍵約束（副作用、依賴關係、邊界條件等呼叫方須知）。
  3. 加保護規則：重構時禁止以「註釋太長」「程式碼自解釋」「順便清理」為由刪掉背景和設計意圖註釋；實現變了導致註釋不準確，必須同步更新內容。
  4. 給判斷標準：只有一條，未來接手的人沒有這條註釋，還能理解當初為什麼這樣做嗎？
⭐ 加分點舉課程裡那個例子最有說服力：merge_chat_history 的三要素註釋記下了「以服務端記錄為權威、只追加本地獨有訊息、system 訊息一律丟棄」，這些決策資訊讀程式碼本身根本讀不出來。
用這些課程頁組織答案 → 註釋三要素與程式碼保護
Q13技術同事
「我上週寫的那段相容舊資料格式的程式碼，被你的 AI 重構時清沒了。你知道這事嗎？」
🎯 對方在考察什麼
技術同事在追責，也在試探你的流程能不能保護他的程式碼。這題答不好，合作信任直接清零。核心考「善意破壞」這類事故的防法。
🧭 答題框架
  1. 先認事故類型：這叫善意破壞。AI 重構時清理它認為多餘的程式碼，事後才發現有用，是四類典型事故之一。
  2. 給宣告規則：刪除任何已有功能程式碼前，必須明確告知使用者並說明理由，禁止以「順手清理」「看起來沒用」為由靜默刪除。
  3. 給標準動作：AI 認為某段程式碼該移除時，先標註 // TODO: 建議移除 - 原因：xxx，拿到明確許可再刪。「看起來沒用」不構成刪除理由。
  4. 補流程閘：這類破壞多發生在批次重構裡。修改超過 3 個檔案必須先交修改計劃，逐檔案寫清改什麼，「順手」的無關清理在審計劃這一關就會暴露。
⭐ 加分點把另一個歧路也堵上：整段註釋掉堆在原地同樣是錯的，規則不鼓勵這種做法，本質上還是破壞。正確路徑只有一條：標註、告知、等許可。
用這些課程頁組織答案 → 註釋三要素與程式碼保護 四步流程：複述、PRD、確認、編碼
Q14面試官
「線上出了故障，翻日誌什麼都沒有，最後發現錯誤全被 catch 住悄悄吞了。你們對錯誤處理有約束嗎？」
🎯 對方在考察什麼
考品質底線有沒有細到語句級。能報出「什麼算靜默吞錯」的具體清單，說明規則真的執行到了程式碼層，答「我們會認真處理錯誤」就是沒規則。
🧭 答題框架
  1. 給禁令：禁止空 catch。所有 try/catch 和錯誤分支必須有實質性處理。
  2. 定義吞錯：僅 console.log(e)、pass、// ignore 都屬於靜默吞錯，一律不允許。
  3. 給合格標準：日誌記錄加使用者可見的錯誤提示，或者合理的降級邏輯，至少佔一樣。
  4. 配上日誌面：後端在終端打詳細日誌，前端在瀏覽器 Console 打日誌。吞錯和缺日誌是同一類病，出問題時都讓「先 Log 定位根因」無從下手。
⭐ 加分點能把這條和註釋保護、刪除宣告歸進同一個板塊（品質底線，專攔 AI 的偷懶），說明你腦子裡裝著規則的全景圖，答的每條都知道它在體系裡的位置。
用這些課程頁組織答案 → 註釋三要素與程式碼保護 除錯鐵律：先 Log 再改碼
Q15老闆
「我跟你說過多少次別用彈窗，換了個對話 AI 又給我彈出來了。我的這些要求，就不能讓它記住嗎？」
🎯 對方在考察什麼
老闆在抱怨重複交代的成本。他要的是一套品味沉澱機制：偏好說一次，之後所有對話都生效。答「我每次開頭都提醒 AI」等於把成本留在原地。
🧭 答題框架
  1. 給機制：METHODOLOGY.md。AI 主動識別對話中的產品思路、決策邏輯和取捨偏好，提煉後直接寫入，新對話自動繼承。
  2. 說彈窗這事的歸宿：使用者否決過彈窗方案並給出理由，AI 把它記進「反模式」，之後同一個方案不會被提第二次。
  3. 報四段結構：產品原則（反覆出現的核心信念）、設計決策記錄（帶日期和理由）、使用者體驗偏好（UI/UX 品味與審美標準）、反模式（明確拒絕過的方案附拒絕理由）。
  4. 說清寫入原則：提煉本質、同類合併、新條目標註日期，避免照搬對話原文；不記技術實現細節和一次性臨時決定。AI 識別到就直接寫入，寫完簡要告知，無需每次徵求許可。
⭐ 加分點背出四個觸發時機：使用者解釋了「為什麼這樣做」、否決方案並給出理由、表達了明確的 UI/UX 偏好、檢討時總結了經驗。這四種時刻 AI 自動記錄，老闆的品味就這樣一條條攢成手冊。
用這些課程頁組織答案 → 三份文件與方法論沉澱
Q16面試官
「三個月前你們有個功能從 A 方案換成了 B 方案。現在讓你說清當初為什麼換，你翻什麼？」
🎯 對方在考察什麼
考功能級的可追溯性。答「翻 commit」的人沒意識到決策資訊和程式碼資訊是兩回事：git log 只記了程式碼怎麼改的，記不了為什麼改。
🧭 答題框架
  1. 直接給答案：翻 docs/FEATURES.md。它是功能點的唯一事實來源，每個功能帶「歷史沿革」，記錄初始需求、方案變更及原因、最終實現。
  2. 報狀態流轉：🟡 規劃中、🔵 開發中、🟢 已完成、⚪ 已取消。每次狀態變更、方案調整都追加一條帶日期的記錄。
  3. 點出細則：取消的功能也不刪，標 ⚪ 並註明原因；日期必須讀系統當前時間，不能憑記憶填寫；方案沒變過也要寫一條「初始需求」。
  4. 說清 git log 為什麼不夠：「搜尋功能因效能問題從 A 方案改用 B 方案」這條原因，commit 裡只能看到改動本身。歷史沿革回答的正是「當初為什麼放棄了 A 方案」。
⭐ 加分點點出一個貫穿的哲學：FEATURES 的「取消不刪」和 PlayGround 的「demo 只增不刪」是同一件事，被砍掉的需求也是設計過程的歷史存檔，未來複活時直接撿回來。
用這些課程頁組織答案 → 三份文件與方法論沉澱 PlayGround：元件的試衣間
Q17面試官
「你們的更新公告裡寫『重構了訊息渲染模組』，使用者看得懂嗎？CHANGELOG 和 RELEASE_NOTES 你們怎麼分工？」
🎯 對方在考察什麼
考文件的讀者意識。兩份文件語言風格完全不同，一份給開發者、一份給使用者，混著寫說明沒想清楚各自給誰看。
🧭 答題框架
  1. 分工一句話：CHANGELOG 回答「這次改了什麼」，給開發者看；RELEASE_NOTES 回答「使用者得到了什麼」，給真實使用者看。
  2. CHANGELOG 的格：按時間倒序，每條用表格記錄問題/需求、根因/方案、改動範圍、影響面、狀態，類型標籤分 BUG / FEAT / REFACTOR / PERF / DOCS。寫之前必須讀系統時間，禁止憑記憶填時間戳、禁止積壓補寫。
  3. RELEASE_NOTES 的紅線：禁寫除錯功能、技術實現細節（模組名、檔案路徑、重構）和使用者無感知的改動。「重構訊息渲染模組」外部行為不變，根本不該出現在公告裡。
  4. 給合格寫法：每條能回答「這對我有什麼用」。新功能一句話說明使用者能做什麼新事情，修復寫之前什麼問題、現在解決了，每條不超過 3 句話，版本號遵循 SemVer。
⭐ 加分點用同一件事演示分工：輸入法誤傳送的修復，CHANGELOG 裡寫根因是沒判斷 isComposing、型別標 BUG；RELEASE_NOTES 裡只寫「輸入中文時不再誤傳送」。一條資訊兩份文件各取所需。
用這些課程頁組織答案 → 三份文件與方法論沉澱
Q18技術同事
「拉了你們的分支一跑，發現 axios 沒了，全換成 fetch 了。這種事都不說一聲的嗎？」
🎯 對方在考察什麼
考依賴治理。依賴變更牽動整個專案的構建和執行環境，靜默替換是團隊協作的大忌。他想知道你有沒有對應的宣告機制，還是全憑 AI 心情。
🧭 答題框架
  1. 先定性：這違反依賴變更宣告。任何 package.json、requirements.txt 的變更都禁止靜默安裝或移除。
  2. 報三件事：動手前必須主動說明新增或移除了什麼依賴、為什麼需要、版本選擇理由。
  3. 說清為什麼嚴：功能等價的替換，影響面可能完全等價不了。課程裡的真實案例是 axios 從 0.27.2 升到 1.6.0，大版本有破壞性變更，可能波及所有網路請求。
  4. 補發版面的兜底：就算漏了宣告，發版前的 diff 審查還會攔一次。Release Notes 沒提的依賴變化會被 SubAgent 標為風險、暫停發版。
⭐ 加分點把邊界說死：在 commit message 裡提一句不算交代。宣告必須發生在動手之前，這和刪程式碼先標 TODO 等許可，是同一個「先宣告、後動手」的模式。
用這些課程頁組織答案 → 註釋三要素與程式碼保護 破壞性操作的三道閘
Q19面試官
「AI 生成的程式碼你們跑測試嗎？測試也是 AI 自己寫的吧，那算不算自己騙自己？」
🎯 對方在考察什麼
考交付線的硬性程度。能報出目錄、命名、覆蓋範圍的人，測試是真的在流程裡；答「有空就跑跑」的人，測試只是裝飾。後半句還埋了個質疑，要接得住。
🧭 答題框架
  1. 給硬線：核心邏輯單元測試不過，不得交付。這是交付前兩道硬性檢查之一，另一道是真實 AI 介面驗證。
  2. 報覆蓋範圍：核心業務邏輯、API 介面、資料處理函式、邊界條件都要覆蓋。
  3. 報規範細節：測試檔案統一放 tests/ 目錄，命名 test_{模組名}.py，Python 專案用 pytest。除錯用的臨時腳本，用完自行刪除，測試資產和除錯垃圾分開管。
  4. 接住質疑：測試只是最後一道關，前面還有 PRD 確認攔理解偏差、修改計劃攔範圍擴散。多道關卡互為補充，單靠哪一道都不夠。
⭐ 加分點補一句邊界意識：測試攔的是實現層的迴歸。AI 對需求理解錯了，測試照樣全綠，所以斷點要設在編碼之前，這正是四步流程存在的理由。
用這些課程頁組織答案 → 除錯鐵律：先 Log 再改碼 四步流程：複述、PRD、確認、編碼
Q20面試官
「你們的規則禁止 AI 提 MVP？做產品先跑 MVP 驗證需求是基本功吧，這不反常識嗎？」
🎯 對方在考察什麼
概念辨析題，考你能不能分清人決定的拆分和 AI 自作主張的降級。把兩者混為一談的人，會把一條好規則用成教條，或者乾脆不敢用。
🧭 答題框架
  1. 先劃界：規則禁的是 AI 主動規劃分期、MVP、階段一二三，從來沒有禁止人做 MVP 決策。拆分是人的決策，降級是 AI 的自作主張，兩者的區別就是這條規則的核心。
  2. 給正確流程：功能確實複雜時，AI 的正確動作是給出完整方案、真實工作量和前置決策清單，要不要拆、怎麼拆由人拍板。
  3. 舉邊界案例：一個功能真需要 2000 行程式碼，一次寫完不現實。這時讓 AI 報完整方案和工作量，人基於工作量決定拆成兩個 PR。這是拆分，與降級無關。
  4. 補一條硬規矩：已知有缺陷的方案，直接給正確版本，別先做一個將就的。
⭐ 加分點用認證系統的例子收尾：AI 報出完整方案約 3 天、複雜度在 OAuth 回撥與多端會話，再列 3 個前置決策（要不要手機號登入、供應商選幾家、會話有效期多長），人幾十秒就能拍板，完整版一次到位。
用這些課程頁組織答案 → 不接受分期交付
Q21面試官
「你們規定 Agent 工具呼叫必須用 XML？現在大家都在用 JSON，這規矩是哪來的？」
🎯 對方在考察什麼
考格式選型背後的工程理由。能講出 escape hell 和 LLM 逐 token 生成的出錯模式，說明你的理解到了生成機制層面，而且知道規則有適用邊界。
🧭 答題框架
  1. 報三分法：Agent 工具呼叫用 XML，配置檔案和資料儲存用 YAML，對外 REST API 用 JSON。三種格式各管一個領域，互不混用。
  2. 講 XML 的理由：JSON 字串裡再套 JSON 就是 escape hell，每層巢狀反斜槓翻一倍，LLM 逐 token 生成時極易配錯括號和引號。XML 標籤閉合直觀，模型出錯率更低。
  3. 講另外兩個：配置檔案讀寫的主體是人，YAML 沒有括號引號噪音、支援註釋，「這個值為什麼這麼設」直接寫在旁邊；REST API 用 JSON 是行業標準，對外介面的原則是不折騰呼叫方。
  4. 說出例外：只用 GPT 系列的專案可以把工具呼叫改回 JSON，它的 function calling 原生就是 JSON。「Agent 用 XML」是多模型混用場景的最大公約數，Claude 系模型在 XML 上表現更穩。
⭐ 加分點順手把 YAML 也排除出呼叫協議：它靠縮排表達層級，LLM 生成時縮排極易漂移，一格之差整棵結構就歪了。三種格式的落選理由都說得出，才是真懂三分法。
用這些課程頁組織答案 → 把環境事實寫進 Rule
Q22面試官
「你們的生圖功能一上線就大面積超時，最後查出來是超時配置的問題。這種低階坑怎麼防？」
🎯 對方在考察什麼
考環境事實的管理方式。這類坑的特點是 AI 會反覆踩：這次改對了，下個對話又用回預設值。考你知不知道用 Rule 一次性解決，而且能報出具體數字。
🧭 答題框架
  1. 說出坑的樣子：圖像 API 經常因為預設 30 秒超時失敗，AI 還會反覆嘗試相同的錯誤配置，改一次好一次、忘一次錯一次。
  2. 給數字：HTTP 客戶端超時對圖像生成至少設 120 到 180 秒，寫進 Rule，每輪對話自動帶入，一次解決。
  3. 報同族規則：網路請求失敗必須先嚐試代理重試（預設 127.0.0.1:7890），仍失敗才向使用者報告，禁止跳過代理直接報錯；前端可見的所有大模型響應必須用 Streaming 返回，後端內部呼叫才允許非流式。
  4. 上升到機制：這些都是環境事實。寫進 Rule 相當於給 AI 一份預填好的 .env 說明書，新開對話不用交代，它直接知道該調哪個模型、超時設多少。
⭐ 加分點給出驗證方法：新開一個對話，不做任何交代，直接問 AI 專案的技術棧和模型配置。它答得出來，才算真寫進了 Rule。這是課程裡的課堂練習，做過的人答得毫不猶豫。
用這些課程頁組織答案 → 把環境事實寫進 Rule
Q23技術同事
「聽說你們同時開好幾個 SubAgent 改程式碼？兩個 Agent 改同一個檔案，後改的把先改的覆蓋了怎麼辦？」
🎯 對方在考察什麼
考多 Agent 並行的一致性意識。這是新出現的工程問題，答得出的人說明真的在用多 Agent 做事，答不出的說明並行對你只是個演示。
🧭 答題框架
  1. 給規則：多個 SubAgent 或多次編輯涉及同一檔案時，後續修改必須先重新讀取檔案當前狀態，禁止基於快取或記憶中的舊內容編輯。
  2. 給類比：這就是多 Agent 時代的「樂觀鎖」。寫之前先確認檔案的最新狀態，別人的改動才不會被無意覆蓋。
  3. 配上目標一致性：並行期間使用者可能改了目標。複述目標時以最新一次為準，並明確標註變更，避免新舊目標混在一起，兩個 Agent 各幹各的。
  4. 說明並行有正面用法：規則鼓勵並行調研。修 bug 前的三問自查，就建議優先啟動 SubAgent 並行調研影響範圍，確認安全後再動手。
⭐ 加分點點破這兩條規則的共同點：長對話和並行操作裡，手上的資訊都會過期。關鍵動作之前先重新整理（重讀檔案、複述目標），比出事後排查便宜得多。
用這些課程頁組織答案 → 長對話錨定與寫作規範 除錯鐵律：先 Log 再改碼
Q24面試官
「AI 建議你們把資料庫從 SQLite 換成 PostgreSQL，理由列得頭頭是道。你換不換？」
🎯 對方在考察什麼
考選型決策權的歸屬。順著 AI 換的人，專案遲早陷進選型漂移。想聽到的答案是「鎖定」，以及鎖定的具體做法。
🧭 答題框架
  1. 先給態度：不換。技術棧選型是人的決策，一旦定了就不再討論替代方案，AI 的職責是在確定的棧內把程式碼寫好。
  2. 說出漂移的樣子：不加鎖定，不同對話裡 AI 會選不同框架，今天 Express 明天 Fastify，資料庫一會兒 MongoDB 一會兒 PostgreSQL，專案在漂移中失去一致性。
  3. 報鎖定內容：把選型寫死進 Rule。課程裡的例子是後端 FastAPI、前端 React + Tailwind + Vite、資料庫 SQLite、向量庫 Chroma。
  4. 補埠細節：埠避開 5000，從 8000 到 9000 隨機分配，多專案同開也不衝突。能報出這條，說明 Rule 真讀到了細節。
⭐ 加分點補上「怎麼換才對」：真要換庫，入口是人改 Rule 裡的技術棧宣告（適配四動作裡的「換」），AI 再在新棧內做事。選型可以變，但變更入口在人手裡，從來不在 AI 的建議裡。
用這些課程頁組織答案 → 把環境事實寫進 Rule 為什麼要給 AI 立規矩
Q25老闆
「上個版本的事故我記著呢：發版時混進了一段沒做完的程式碼。你說加了審查，具體怎麼審？審出問題怎麼辦？」
🎯 對方在考察什麼
老闆要的是步驟級的流程細節。「我們會審查」這四個字他已經聽膩了，要拆到每一步幹什麼、審出問題誰說了算。
🧭 答題框架
  1. 報流程三步：取完整 diff、逐檔案比對、分類處理。讓 SubAgent 獨立分析實際 diff 和 Release Notes 的偏差。
  2. 說清審什麼：Release Notes 寫的是預期改動，實際 commit 可能混進無關調整甚至誤刪。課程案例：發版主題是夜間模式，diff 裡卻混著改寫訊息解析函式的改動和 axios 從 0.27.2 到 1.6.0 的依賴升級，這些沒寫進公告的就是風險。
  3. 給處置：審出風險就暫停發版，等待使用者確認。確認之前，打 tag、push、部署全部禁止，AI 沒有自行發版的權限。
  4. 補發布通道：釋出必須走 GitHub，伺服器透過 git pull 或 CI/CD 拉程式碼。緊急熱修復可以例外，事後必須補 commit 同步。
⭐ 加分點用一句話概括審查的價值：把「我以為我改了什麼」和「我實際改了什麼」拆開比對，兩者的差值就是事故的來源。老闆聽完這句就知道你想明白了。
用這些課程頁組織答案 → 破壞性操作的三道閘
Q26面試官
「你跟 AI 聊了 30 輪，它突然把開頭定好的資料庫給換了。這種事你遇到過嗎？怎麼治？」
🎯 對方在考察什麼
考長對話漂移的成因理解。答「多提醒它幾次」是沒入門；能講出視窗截斷機制和週期性錨點的人，才是長對話的真使用者。
🧭 答題框架
  1. 先講成因：上下文視窗截斷加長文字尾部注意力衰減。第 1 輪說的「用 PostgreSQL」聊到 30 輪已經滑出視窗，AI 只是在它看得見的資訊裡做了一個「合理」推斷，於是建議換 SQLite。
  2. 給規則：超過 10 輪之後，修改程式碼、修改配置、部署這些關鍵操作前，AI 必須先回顧並複述當前目標和關鍵約束。
  3. 給格式：複述有固定格式「📌 當前目標：XXX | 關鍵約束：YYY」，人掃一眼就能確認有沒有跑偏。
  4. 補邊界認知：即使是 200K token 的模型，注意力在長文字尾部的衰減也真實存在。錨定對長視窗模型同樣必要，換大模型治不了這個病。
⭐ 加分點把兩道防線連起來：選型漂移本身就是四類典型事故之一，技術棧鎖定從對話外攔（Rule 每輪注入），錨定從對話內攔（週期性複述），雙保險。
用這些課程頁組織答案 → 長對話錨定與寫作規範 為什麼要給 AI 立規矩
Q27面試官
「你們的產品文案也讓 AI 寫？說實話，AI 味我一眼就能看出來，使用者也能。你怎麼保證寫出來像人話？」
🎯 對方在考察什麼
考你能不能把「自然流暢」這種主觀要求工程化。答「我會多改幾遍」的人沒有方法；能報出違禁清單和自查流程的人，交付品質是穩定的。
🧭 答題框架
  1. 點破空話為什麼沒用：「請用自然流暢的中文」沒有用，AI 認為的自然和你認為的自然可能完全不同。必須給出具體的違禁詞和違禁句式列表，AI 才能精確執行。
  2. 舉違禁模式：writing-style.mdc 的清單裡包括全形破折號、全形省略號、「不是 A 而是 B」這類對比句式、網文式情緒詞、評價他人的話、解讀前置的鋪墊、英文彎引號。
  3. 給自查流程：交付前逐條搜尋違禁模式，發現一處改一處，完成後註明已完成自查。System Prompt 裡的違禁句式同樣要改。
  4. 給配置細節：寫作規範獨立成檔案，frontmatter 設 alwaysApply: false，只在寫文案或 Prompt 時手動引用，避免汙染編碼對話的上下文。
⭐ 加分點說出清單方法的本質：違禁模式是可搜尋的，AI 可以逐條掃描自己剛寫的稿子，主觀品味就變成了機械檢查。錨定對抗遺忘，清單對抗含糊，共同點都是把模糊期望變成可執行動作。
用這些課程頁組織答案 → 長對話錨定與寫作規範 為什麼要給 AI 立規矩
Q28面試官
「你們介面第一版全是 emoji 按鈕，是 AI 的手筆吧？設計品味這種東西，也能立成規矩嗎？」
🎯 對方在考察什麼
考品味能不能規則化。多數人以為規則只管流程和安全，能舉出設計層的具體條款，說明你理解這套規則的覆蓋面到了什麼程度。
🧭 答題框架
  1. 給條款：禁止用 emoji 做按鈕圖示，圖示必須用 SVG。
  2. 給選型方法：看產品調性選圖示集，SaaS 用 Lucide，溫暖調性用 Tabler Icons。
  3. 給工程細節：圖示直接下載到本地使用，不依賴 CDN。
  4. 回答「能不能」：能。這類品味決策和 isComposing 一樣，歸在「文件與設計規範」章節。品味固化成規則後 AI 每次生成都遵守，免得每一版都要人肉挑一遍。
⭐ 加分點分清兩層品味：Rule 管通用底線（禁 emoji、用 SVG），METHODOLOGY 的「使用者體驗偏好」管本專案的具體偏好，比如確認按鈕固定放右下角、用品牌色。兩層配合，品味才完整。
用這些課程頁組織答案 → 把環境事實寫進 Rule 三份文件與方法論沉澱
Q29面試官
「你說這套規範有 14 章。現在給你 60 秒，把它的骨架講清楚。」
🎯 對方在考察什麼
考全域觀和提煉能力。背不出全景圖的人多半只用過其中兩三條；說得出板塊劃分和底層邏輯的人，才配講方法論。
🧭 答題框架
  1. 報五大板塊：流程控制（斷點設在編碼前）、品質底線（完整實現，不接受將就）、文件沉澱（決策跨對話留存）、環境與安全（環境事實一次寫死）、溝通與寫作（錨定與自查）。
  2. 各給一個代表條款：修改超過 3 個檔案先列計劃；禁止猜測性修復；三份文件各管一個維度；備份、回退、diff 審查三道閘；超過 10 輪複述目標。
  3. 收在共同底層：把模糊期望變成可執行的具體動作。「注意品質」執行不了，「刪除程式碼前必須顯式宣告」才執行得了。14 章每一章都在做這個翻譯。
⭐ 加分點能把章號對上就更狠：環境與安全一個板塊就裝了模型配置、資料格式、技術棧、部署四章。說得出結構裡的具體章節，證明你讀過規則原文，60 秒講的是消化過的東西。
用這些課程頁組織答案 → 規則的價值：每條解決一個真實問題
Q30面試官
「假設我們明天就把你這套規則原樣搬進公司倉庫，全員執行。你支援嗎？」
🎯 對方在考察什麼
收官陷阱題。答「支援」就掉坑了：這套規則帶著作者專案的環境事實，照搬必翻車。考你有沒有一套適配方法論，而且答案裡要有取捨。
🧭 答題框架
  1. 先攔住：不建議原樣搬。規則裡寫死了作者專案的技術棧、埠、格式選型，這些環境事實和你們公司對不上。照搬 14 章不如精選 5 章。
  2. 給四個動作：刪（不做中文內容創作就把寫作規範移出 .cursor/rules/，減少無關上下文）、換（技術棧宣告換成公司的選型）、調（「修改超過 3 個檔案先確認」的閾值按專案調，謹慎專案調成 1，快速原型放寬到 5）、補（把團隊裡 AI 反覆犯的錯寫成新規則）。
  3. 給驗證週期：在一個真實專案裡用滿一週，記錄哪些規則被觸發、哪些從沒生效。刪掉從沒生效的，把新踩的坑寫成新規則。
  4. 說清為什麼：規則和程式碼一樣，沒人維護就會腐爛。搬進來只是開始，養起來才算用上。
⭐ 加分點把迴圈補完：刪換調補做完的版本可以開源出去，原倉庫本身就是 MIT License，鼓勵 Fork 改造後釋出自己的版本。能說到這一步，說明你把規則當成了可以持續迭代的資產。
用這些課程頁組織答案 → 規則的價值：每條解決一個真實問題 四步流程：複述、PRD、確認、編碼
最後一個建議
這 30 題最好的準備方式是拿真專案練一遍：把 xs_vibe_rules 放進你的專案，跑兩週，事故和規則都會變成你自己的故事。有故事的回答，和背框架的回答，對方一耳朵就能聽出來。