他們會這樣考你

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 放進你的項目，跑兩週，事故和規則都會變成你自己的故事。有故事的回答，和背框架的回答，對方一耳朵就能聽出來。