1. 項目概述當AI編碼助手需要“護欄”而非“指南”最近在折騰各種AI編碼助手比如Cursor、Claude Code、Codex時我總被一個問題困擾如何讓這玩意兒更“聽話”、更“懂我”我可能在一個項目里要求所有函數(shù)必須有JSDoc注釋在另一個項目里又希望它優(yōu)先使用特定的工具庫。簡單地在每次對話里重復這些要求不僅低效而且AI很容易“忘記”或“混淆”上下文。這背后其實是一個更深層的問題我們到底應該如何系統(tǒng)性地、持久地配置和管理AI編碼代理的行為這正是“Guardrails Beat Guidance: A Large-Scale Study of Rules, Skills, and Persistent Configuration for Coding Agents”這個研究標題所指向的核心。它不是一個具體的工具而是一套方法論和實證研究的總結(jié)。簡單來說它探討了在AI輔助編程的實踐中是依賴每次對話時提供的臨時“指導”Guidance還是建立一套固化的、項目級的“護欄”Guardrails與“技能”Skills配置更有效。結(jié)論從標題就能看出護欄勝于指導。這里的“護欄”指的是一系列強制性的、不可逾越的規(guī)則比如代碼風格規(guī)范命名、縮進、安全紅線禁止使用某些危險函數(shù)、架構(gòu)約束必須遵循特定的設計模式。而“技能”更像是可插拔的工具集或知識庫比如“熟練掌握Vue 3 Composition API”、“精通使用項目內(nèi)部的工具函數(shù)庫”。至于“持久配置”就是指將這些規(guī)則和技能與具體的代碼倉庫、項目或開發(fā)環(huán)境綁定形成一種“開機即用”的默認工作狀態(tài)而不是每次打開聊天窗口都要重新說一遍。為什么這個話題現(xiàn)在這么熱看看網(wǎng)絡上的搜索詞就明白了langchain guardrails、vue rules validator、cursor設置環(huán)境上下文 全局 項目級 rules、skills和mcp區(qū)別……開發(fā)者們已經(jīng)受夠了與AI進行重復、低效的溝通迫切希望找到一種一勞永逸的配置方式讓AI助手真正成為貼合自己團隊習慣和項目需求的“資深搭檔”。2. 核心理念拆解規(guī)則、技能與持久化配置的三角關(guān)系要理解這套方法論我們需要把“規(guī)則”、“技能”和“持久化配置”這三個概念拆開來看并理清它們之間的關(guān)系。這不僅僅是三個功能點更是一種構(gòu)建可靠AI協(xié)作工作流的設計哲學。2.1 規(guī)則不可逾越的底線與強制規(guī)范規(guī)則是剛性的、強制性的約束。它的目的是保證產(chǎn)出的代碼在基礎(chǔ)質(zhì)量、安全性和一致性上達到最低標準。你可以把它想象成交通規(guī)則中的“紅燈停”、“限速60”——沒有商量的余地。規(guī)則的核心類型代碼風格規(guī)則這是最普遍的需求。例如強制使用2個空格縮進、變量命名必須采用camelCase、函數(shù)名必須用動詞開頭、必須為公共API添加JSDoc/TSDoc注釋。這些規(guī)則可以通過集成ESLint、Prettier的配置來實現(xiàn)AI在生成代碼時必須遵守。安全與最佳實踐規(guī)則這類規(guī)則防止引入已知的漏洞或反模式。例如禁止使用eval()函數(shù)、禁止直接拼接SQL字符串必須使用參數(shù)化查詢、禁止向innerHTML插入未凈化的用戶輸入、要求對異步操作進行錯誤捕獲。架構(gòu)與設計規(guī)則在特定項目中你可能有一些架構(gòu)上的硬性要求。比如“所有數(shù)據(jù)獲取必須通過src/api/目錄下的封裝函數(shù)進行”、“React組件必須為函數(shù)式組件并使用Hooks”、“狀態(tài)管理必須且只能使用Zustand”。這些規(guī)則引導AI遵循項目的整體設計思路避免架構(gòu)污染。注意規(guī)則的制定要“少而精”。一開始就設置上百條規(guī)則會讓AI束手束腳也可能引發(fā)大量無意義的修正沖突。建議從最影響代碼質(zhì)量和團隊協(xié)作的3-5條核心規(guī)則開始逐步迭代。2.2 技能可擴展的能力包與上下文知識如果說規(guī)則是“禁止做什么”那么技能就是“擅長做什么”。技能是一種軟性的能力增強它為AI注入特定的領(lǐng)域知識、技術(shù)棧偏好或工具使用習慣。技能的常見形態(tài)框架/庫專精技能例如“本項目使用Vue 3 script setup語法糖 Pinia”或者“熟悉并使用Ant Design Vue組件庫的特定配置”。安裝了此類技能后AI在建議組件或?qū)戇壿嫊r會優(yōu)先采用你指定的技術(shù)棧的 idioms慣用法。項目上下文技能這是最有價值的技能之一。它可以將項目的關(guān)鍵文檔、核心工具函數(shù)、業(yè)務實體定義、API接口規(guī)范等作為參考知識提供給AI。例如你可以創(chuàng)建一個技能內(nèi)容包含src/utils/formatDate.js這個日期格式化函數(shù)的用法說明AI在需要格式化日期時就會直接調(diào)用它而不是自己生成一個可能不一致的新函數(shù)。代碼模式技能封裝一些常見的、項目特有的代碼模式。比如“如何在本項目中發(fā)起一個帶認證和錯誤處理的API請求”、“如何創(chuàng)建一個新的CRUD頁面模板”。這能極大提升開發(fā)類似功能時的一致性和速度。網(wǎng)絡上熱議的skills和mcp區(qū)別這里可以簡單厘清Skills通常指AI代理如Codex、Cursor內(nèi)置AI自身可加載的、用于增強其代碼生成能力的擴展包。而MCP可能指“Model Context Protocol”或類似概念是一種更通用的、用于為AI模型提供外部上下文和工具的協(xié)議框架。Skills可以基于MCP來構(gòu)建但MCP的范疇更廣。對于大多數(shù)開發(fā)者而言直接關(guān)注如何創(chuàng)建和使用Skills更實際。2.3 持久化配置讓習慣成為默認這是連接規(guī)則和技能并使其生效的關(guān)鍵。持久化配置解決了“一次性說明永久生效”的問題。它的目標是將項目和環(huán)境的特定要求從臨時的聊天上下文沉淀為可版本化、可共享的配置文件。配置的承載形式項目級配置文件最理想的方式。在項目根目錄放置一個如.cursor/rules.json、.aider.yml或guardrails.config.js的文件。該文件定義了本項目適用的所有規(guī)則和需要加載的技能。任何打開本項目的開發(fā)者或其AI助手都會自動繼承這些配置。這完美呼應了搜索詞cursor設置環(huán)境上下文 全局 項目級 rules的需求。全局用戶配置用于存放開發(fā)者個人的通用偏好比如偏好的代碼注釋風格、常用的個人工具函數(shù)庫技能等。當打開一個新項目時AI可以結(jié)合項目配置和全局配置來工作。環(huán)境/工作區(qū)配置在像VS Code這樣的IDE中配置可以保存在工作區(qū).vscode/settings.json中與項目綁定但作用范圍是整個編輯環(huán)境不僅限于AI插件。持久化的價值它消除了記憶負擔和溝通成本。團隊新成員加入克隆代碼庫的同時也克隆了開發(fā)規(guī)范。AI從第一行代碼開始就處于“合規(guī)”狀態(tài)。這比任何入職文檔都來得直接有效。3. 大規(guī)模研究揭示了什么為什么“護欄”更有效原研究標題提到了“A Large-Scale Study”這意味著其結(jié)論不是拍腦袋想出來的而是基于大量實際數(shù)據(jù)和分析得出的。雖然我們無法看到論文全文但可以從工程和認知角度推斷其核心發(fā)現(xiàn)這與我們?nèi)粘５捏w驗高度吻合。3.1 臨時“指導”的固有缺陷我們習慣的“Guidance”模式就是在聊天框里輸入“請用TypeScript寫記得用async/await風格要跟現(xiàn)有代碼一致?！边@種方式存在幾個致命問題上下文遺忘與衰減大型語言模型有上下文窗口限制。在漫長的對話中早期提到的要求很容易被“擠到”注意力邊緣導致AI在后續(xù)響應中逐漸忽略或違背最初的指導。表述模糊與歧義“風格一致”這種要求對AI來說過于模糊。是哪方面的風格縮進命名還是代碼組織人類靠默契AI則需要明確規(guī)則。極高的重復成本每個新任務、每次新對話甚至同一個對話中的不同階段你都需要重復強調(diào)相同的要求。這是一個巨大的心智負擔和效率黑洞。難以保證團隊一致性團隊中每個成員給AI的“指導”可能略有不同導致最終代碼庫中出現(xiàn)風格迥異的代碼增加了理解和維護成本。3.2 “護欄”機制帶來的確定性優(yōu)勢相比之下通過“規(guī)則”設置的護欄提供了確定性和一致性強制合規(guī)無需提醒一旦規(guī)則被設定為護欄AI在代碼生成階段就會將其作為硬性約束。例如如果規(guī)則要求“函數(shù)行數(shù)不超過50行”AI在生成一個長函數(shù)時可能會主動將其拆分為幾個小函數(shù)而不是等你來審查時再指出。早期攔截降低返工很多問題在代碼生成階段就被阻止了而不是在代碼審查甚至運行時才發(fā)現(xiàn)。這相當于將質(zhì)量保障左移節(jié)省了大量后期修改的時間。形成團隊公約項目級的規(guī)則配置文件成為了團隊共同遵守的“法律”。它客觀、明確減少了因個人習慣不同引發(fā)的爭論讓團隊協(xié)作更順暢。技能庫的累積效應項目相關(guān)的技能被沉淀下來隨著項目發(fā)展不斷豐富。新加入的AI或開發(fā)者能立即獲得項目積累的所有“領(lǐng)域知識”上手速度極快。一個生動的類比指導Guidance就像副駕駛在每次轉(zhuǎn)彎前都提醒司機“注意看路”而護欄Guardrails就像是道路上畫好的車道線和堅固的防護欄。前者依賴持續(xù)的、高注意力的溝通后者則構(gòu)建了一個安全的、自解釋的行駛環(huán)境讓司機開發(fā)者可以更專注于駕駛業(yè)務邏輯本身。4. 實操指南如何為你的AI編碼助手配置“護欄”與“技能”理論說再多不如動手配置。下面我將以目前最流行的幾款AI編碼助手為例拆解具體的配置方法和實操要點。由于生態(tài)在快速演進具體路徑可能變化但核心思想是相通的。4.1 環(huán)境與工具選型目前對“規(guī)則”和“技能”支持比較顯性化的工具主要有Cursor內(nèi)置了強大的規(guī)則和上下文管理功能是實踐這一理念的先鋒。Claude Code通過其桌面應用或編輯器插件支持一定程度的項目上下文設置。Aider一個命令行AI編碼工具通過.aider.yml或--rules參數(shù)支持規(guī)則配置理念非常契合。通用方案對于任何使用OpenAI API或類似模型的工具如VS Code的CodeGPT插件你可以通過精心設計系統(tǒng)提示詞System Prompt來模擬“規(guī)則”并通過RAG檢索增強生成技術(shù)向上下文注入項目文檔來模擬“技能”。選型建議如果你追求開箱即用的集成體驗和活躍的社區(qū)Cursor是目前的最佳選擇。如果你喜歡命令行和極客風格Aider非常強大。如果你主要使用Claude模型Claude Code是自然之選。4.2 實戰(zhàn)在Cursor中設置項目級規(guī)則Cursor的規(guī)則設置是其核心特性之一它允許你在不同層級全局、項目、會話定義規(guī)則。步驟1創(chuàng)建項目級規(guī)則文件在項目的根目錄下創(chuàng)建.cursor/rules目錄。然后在該目錄下創(chuàng)建以.md結(jié)尾的規(guī)則文件。例如code-style.md代碼風格規(guī)則security.md安全規(guī)則project-conventions.md項目特定約定步驟2編寫規(guī)則內(nèi)容規(guī)則文件的語法是自然語言但要求清晰、無歧義。Cursor會讀取這些文件并將其融入AI的決策上下文。code-style.md示例# 代碼風格規(guī)則 ## 通用規(guī)則 - 使用 **TypeScript**嚴格模式。 - 使用 **2個空格**進行縮進禁止使用Tab。 - 字符串使用單引號除非字符串內(nèi)包含單引號。 - 行尾不留空格。 ## 命名約定 - 變量和函數(shù)名使用 **camelCase**。 - 類名、接口名、類型別名使用 **PascalCase**。 - 常量使用 **UPPER_SNAKE_CASE**。 ## 函數(shù)與注釋 - 每個導出函數(shù)都必須有完整的 **JSDoc/TSDoc** 注釋說明參數(shù)、返回值和示例。 - 函數(shù)長度盡量不超過30行。如果邏輯復雜請拆分為多個小函數(shù)。 ## React/Vue特定規(guī)則 - React組件必須使用函數(shù)式組件和Hooks。 - Vue組件必須使用 script setup 語法。 - 優(yōu)先使用組合式函數(shù)Composables封裝可復用邏輯。project-conventions.md示例# 項目特定約定 ## API調(diào)用 - 所有HTTP請求必須通過 src/libs/api-client.ts 中封裝的 request 函數(shù)發(fā)起。 - 錯誤處理必須在調(diào)用層使用 try-catch 包裹并調(diào)用統(tǒng)一的 handleError 函數(shù)。 ## 狀態(tài)管理 - 全局狀態(tài)使用 **Zustand**store定義在 src/stores 目錄下。 - 禁止直接使用 useState 管理跨組件共享狀態(tài)。 ## 目錄結(jié)構(gòu) - 新頁面組件放在 src/pages/ 下對應路由配置需同步更新 src/router/index.ts。 - 工具函數(shù)放在 src/utils/ 下并在 src/utils/index.ts 中統(tǒng)一導出。步驟3驗證規(guī)則生效創(chuàng)建規(guī)則文件后當你在這個項目中使用Cursor的AI功能如“Chat”或“Edit”時它生成的代碼就會自動遵循這些規(guī)則。你可以嘗試讓它“創(chuàng)建一個新的用戶登錄組件”觀察其生成的代碼是否符合你的命名、結(jié)構(gòu)和API調(diào)用約定。實操心得規(guī)則文件不要一次性寫得太長。先從最痛的點開始寫3-5條觀察AI的遵守情況。有時AI對規(guī)則的理解會有偏差你需要像調(diào)試代碼一樣“調(diào)試”你的規(guī)則描述使其更加精確。例如將“代碼要簡潔”改為“每個函數(shù)的圈復雜度不超過10”后者就明確得多。4.3 實戰(zhàn)構(gòu)建與加載自定義技能技能Skills的構(gòu)建更靈活其本質(zhì)是向AI的上下文注入高價值信息。方法1創(chuàng)建項目知識庫文件在.cursor目錄下你還可以創(chuàng)建docs文件夾存放項目文檔。例如.cursor/docs/business-entities.md定義核心業(yè)務對象如User, Order的字段和關(guān)系。.cursor/docs/auth-flow.md詳細說明項目的認證授權(quán)流程。.cursor/docs/key-utils.md重點工具函數(shù)的用法示例。Cursor會自動索引這些文件在相關(guān)對話中作為參考。這解決了codex skills推薦、github skills中人們尋找現(xiàn)成技能包的需求——最好的技能往往是根據(jù)自己項目定制的。方法2利用“上下文引用”功能在Cursor的Chat界面你可以直接使用符號引用項目中的特定文件或代碼塊。例如輸入“請參考src/utils/formValidator.ts的寫法為這個新表單添加驗證邏輯”。這相當于臨時加載了一個精準的技能。方法3探索社區(qū)技能市場像騰訊skills市場、github skills這樣的概念指的是一個共享和發(fā)現(xiàn)預制技能包的平臺。雖然成熟的跨編輯器技能市場還在發(fā)展中但你可以從開源社區(qū)如GitHub找到針對特定框架如Vue3、React或任務如單元測試、數(shù)據(jù)庫操作的“最佳實踐”提示詞集合將其內(nèi)容復制到你本地的規(guī)則或文檔文件中。對于使用其他工具的開發(fā)者Aider在項目根目錄創(chuàng)建.aider.yml內(nèi)容可包含rules: - “所有代碼必須用Python 3.9編寫?！?- “使用pathlib處理文件路徑不要用os.path?！蓖ㄓ孟到y(tǒng)提示詞如果你用的工具支持自定義系統(tǒng)提示詞你可以將你的核心規(guī)則和項目簡介整合成一個長長的提示詞。但要注意上下文長度限制優(yōu)先放入最重要的規(guī)則。4.4 配置的層級與優(yōu)先級策略當存在多個層級的配置時理解其優(yōu)先級至關(guān)重要這能避免配置沖突帶來的困惑。一個典型的優(yōu)先級順序是從高到低會話級指令在單次聊天中輸入的即時命令。例如在Cursor里說“這次忽略命名規(guī)則用快速原型寫法”。這是最高優(yōu)先級用于臨時覆蓋。項目級規(guī)則/技能.cursor/rules/,.cursor/docs/這是團隊協(xié)作的基石優(yōu)先級高確保項目內(nèi)一致性。工作區(qū)/編輯器配置如.vscode/settings.json中為AI插件設置的規(guī)則影響當前打開的所有項目。全局用戶配置開發(fā)者的個人默認偏好優(yōu)先級最低僅在無其他配置時生效。管理策略建議將強制性的、關(guān)乎代碼正確性和團隊規(guī)范的規(guī)則放在項目級。將個人編碼風格偏好放在全局配置。這樣當你切換到不同項目時能自動適應不同的團隊規(guī)范同時保留自己的小習慣。5. 常見問題與故障排查實錄在實際配置和使用過程中你肯定會遇到各種問題。下面是我和同事們踩過的一些坑以及解決方案。5.1 規(guī)則不生效或部分生效問題現(xiàn)象明明配置了規(guī)則但AI生成的代碼還是違反了。排查思路檢查文件位置和格式確認規(guī)則文件放在正確的目錄如.cursor/rules下且是.md格式。文件名最好用英文避免特殊字符。檢查規(guī)則描述是否明確AI不是人對模糊語言的理解會出偏差?！氨３执a整潔”是模糊的“函數(shù)行數(shù)不超過50行一個函數(shù)只做一件事”是明確的?；仡櫮愕囊?guī)則用更客觀、可衡量的語言重寫。規(guī)則沖突如果存在多條規(guī)則可能沖突AI可能會困惑。例如一條規(guī)則說“優(yōu)化性能”另一條說“代碼行數(shù)要少”。在追求性能時可能增加代碼行數(shù)。你需要權(quán)衡優(yōu)先級或合并規(guī)則。上下文過載如果你在單次對話中通過輸入提供了大量臨時指令又加載了很多項目規(guī)則可能會超出AI的有效上下文處理能力導致部分規(guī)則被忽略。嘗試簡化會話指令或拆分復雜任務。5.2 AI對規(guī)則的理解出現(xiàn)偏差問題現(xiàn)象AI似乎理解了規(guī)則但執(zhí)行結(jié)果與預期不符。案例與解決案例規(guī)則要求“使用const聲明不會被重新賦值的變量”。但AI對所有變量都使用了const包括在循環(huán)中需要更新的計數(shù)器。解決細化規(guī)則描述。改為“使用const聲明不會被重新賦值的變量。對于循環(huán)計數(shù)器或需要重新賦值的變量使用let。優(yōu)先使用const?！?并提供正反例子。心得把AI當成一個非常聰明但缺乏常識的新手程序員。你需要像編寫測試用例一樣為重要規(guī)則提供“正面示例”和“反面示例”。在規(guī)則文件里加一個## Examples章節(jié)效果會好很多。5.3 技能上下文加載導致響應變慢或混亂問題現(xiàn)象引用了一個很大的文檔或代碼文件后AI響應速度變慢或者回答開始偏離主題夾雜了一些無關(guān)信息。原因與解決原因注入的上下文過長擠占了AI處理當前問題所需“思考空間”的權(quán)重同時也增加了計算耗時。解決精煉技能文檔不要將整個API手冊扔進去。只提取最關(guān)鍵的函數(shù)簽名、一兩個核心示例和注意事項。分拆技能將一個大文檔按主題拆分成多個小技能文件按需加載。使用精準引用在Cursor中盡量用文件名引用具體文件中的特定部分而不是把整個文件拖入上下文。注意網(wǎng)絡熱詞中提到的skills rules mcp 上下文占用情況這正是指技能和規(guī)則會占用寶貴的模型上下文窗口。管理上下文是一門藝術(shù)目標是放入“足夠用”的信息而不是“全部”信息。5.4 團隊協(xié)作中的配置同步問題問題現(xiàn)象你配置好了規(guī)則但團隊其他成員沒有效果或者大家的配置不一致。標準化流程將配置納入版本控制確保.cursor目錄或?qū)呐渲梦募惶峤坏紾it倉庫中。在.gitignore中不要忽略它。編寫簡單的啟用說明在項目README中增加一節(jié)“AI助手配置”說明本項目使用了基于規(guī)則的AI輔助克隆項目后即可自動生效。定期評審規(guī)則在團隊例會中將規(guī)則文件的更新作為一項議題。討論哪些規(guī)則好用哪些需要修改哪些需要添加。讓規(guī)則成為團隊共識的產(chǎn)物而不是某個人的獨裁。處理個性化沖突如果某個成員有強烈的個人習慣比如就是喜歡4空格縮進而團隊規(guī)則是2空格。說服他/她在本項目遵守團隊規(guī)則同時可以將其個人偏好設置在全局配置中在其他個人項目中使用。6. 進階思考從規(guī)則配置到智能體工程當我們熟練運用規(guī)則和技能后我們的AI助手就不再是一個需要頻繁調(diào)教的“實習生”而逐漸成為一個理解項目脈絡、遵守團隊紀律的“正式工程師”。這讓我們可以進一步思考更高級的用法。6.1 動態(tài)規(guī)則與條件上下文規(guī)則不一定總是靜態(tài)的。我們可以設想更智能的場景基于目錄的規(guī)則src/backend/下的文件需遵循Python PEP8規(guī)范而src/frontend/下的文件需遵循ESLint Airbnb規(guī)范。這可以通過在規(guī)則文件中描述路徑模式來實現(xiàn)。基于文件類型的規(guī)則對.ts文件啟用嚴格類型檢查規(guī)則對.vue文件啟用模板樣式規(guī)則。條件技能加載當AI檢測到用戶正在編輯與“身份認證”相關(guān)的文件時自動將auth-flow.md技能文檔的權(quán)重提高。目前這些高級特性可能需要結(jié)合更復雜的腳本或工具鏈來實現(xiàn)但這是未來演進的方向。6.2 度量與迭代你的規(guī)則有效嗎配置不是一勞永逸的。你需要像對待產(chǎn)品一樣對待你的AI配置。設立度量標準在引入規(guī)則前后可以抽樣檢查AI生成代碼的“首次通過率”即不需要人工修正直接可用的比例、代碼審查中因規(guī)范問題被駁回的次數(shù)。收集反饋鼓勵團隊成員在遇到AI生成代碼不符合預期時不只是修改代碼而是記錄下“當時我期望的規(guī)則是什么”。這是一個寶貴的規(guī)則迭代來源。定期優(yōu)化每季度回顧一次規(guī)則集。移除那些很少被觸發(fā)或已被團隊內(nèi)化的規(guī)則例如大家已經(jīng)習慣寫JSDoc了。添加新出現(xiàn)的高頻問題作為新規(guī)則。6.3 安全與邊界的再審視最后必須清醒認識到“護欄”再堅固也不能完全替代人類的監(jiān)督。尤其是安全規(guī)則護欄是輔助不是銀彈AI可能生成一個看似遵守了“禁止SQL拼接”規(guī)則使用了參數(shù)化查詢模板但邏輯上存在嚴重業(yè)務漏洞的代碼。安全審查不可或缺。保護敏感信息切勿在規(guī)則或技能文件中寫入真實的API密鑰、密碼、內(nèi)部服務器地址等敏感信息。這些文件通常會被提交到代碼倉庫。知識產(chǎn)權(quán)的邊界向AI注入的“技能”文檔應確保是你有權(quán)使用的代碼和文檔。避免將受版權(quán)保護的第三方庫完整源碼作為技能注入。讓AI編碼助手從“一個有時很聰明但經(jīng)常犯錯的臨時工”轉(zhuǎn)變?yōu)橐粋€“訓練有素、熟知項目情況的可靠伙伴”關(guān)鍵在于從臨時的、模糊的“指導”轉(zhuǎn)向系統(tǒng)的、明確的“護欄”與“技能”配置。這需要前期的思考和投入但帶來的長期收益是巨大的更高的代碼質(zhì)量、更一致的團隊輸出、更低的溝通成本以及開發(fā)者能更專注于創(chuàng)造性的問題解決本身。開始為你當前的項目創(chuàng)建一個.cursor/rules目錄吧哪怕只從一條最重要的規(guī)則寫起你會立刻感受到那種“它終于懂我了”的順暢。