為什麼要給 AI 立規矩
Vibe Coding 指靠自然語言讓 AI 直接產出程式碼的開發方式。它的問題出在品質：沒有規矩的 AI 會返工、漏改、悄悄刪程式碼、留下永久技術債。這一節先看事故長什麼樣，再看約束怎麼注入才最穩。
下面四類事故在 AI 協作中反覆出現，根源是同一件事：約束沒有進入上下文。
理解偏差返工
AI 拿到需求就開始寫，寫了 200 行才發現理解有偏差，回滾重來。更糟的情況是改了 7 個檔案之後才發現思路錯了，逐個 revert 成本極高。
選型漂移
不同對話裡 AI 會選不同框架：今天 Express，明天 Fastify。資料庫一會兒 MongoDB 一會兒 PostgreSQL。技術棧沒有鎖定，專案就在漂移中失去一致性。
善意破壞
AI 重構時會清理它認為多餘的程式碼，事後才發現那段程式碼有用。善意的清理變成了破壞性操作。
永久技術債
要一個完整認證系統，AI 說先做簡版登入、後續再加 OAuth。結果後續永遠不會來，簡版程式碼成了永久的技術債。
同一句「幫我做一個登入」，在無規矩和有規矩兩種模式下會走向完全不同的結局。點選「下一步」，兩條時間線同步推進。
給 AI 傳達約束有三種常見方式。點選切換，看同一條約束（「資料庫用 PostgreSQL」）在三個時點是否還生效。
frontmatter 控制生效方式
---
alwaysApply: true # 所有對話自動生效
---
# 開發約束與配置規範
以下是使用者重要的約束，請務必嚴格遵循。true 用於全域編碼規範；false 用於寫作規範這類按需引用的檔案，避免汙染編碼對話的上下文。
xs_vibe_rules 的三個檔案
rule-opensource.mdc：主開發規範，14 個章節覆蓋全流程writing-style.mdc：中文寫作風格，按需手動引用secrets.mdc：API Key 與憑證模板，佔位符形式
使用時放入專案的 .cursor/rules/ 目錄即可。
itshen/xs_vibe_rules · 本專題的開源倉庫
整套規則原文全部開源（MIT License）。Fork 一份，放進你專案的 .cursor/rules/ 目錄，再按自己的技術棧刪改，就是你的第一版 AI 協作規範。
規則的價值不在於多，每條都解決一個真實問題。AI 每反覆犯一次錯，就把它變成一條規則，這是整個專題的底層方法。約束靠不靠得住，看的是注入機制：寫十遍「務必」，都比不過一個每輪自動載入的 Rule 檔案。
素材來源：本專題基於作者開源倉庫 itshen/xs_vibe_rules，內容是從多個真實專案整理出來的 Cursor Rules 與設計思考。