寫在前面

我們有沒有遇到過這種事？

你讓AI幫你寫個(gè)功能——比如“從一堆訂單里找出最早和最晚的日期”，結(jié)果它吭哧吭哧給你寫了兩個(gè)函數(shù)：一個(gè)找最小值，一個(gè)找最大值。每個(gè)函數(shù)都先復(fù)制一遍原始數(shù)據(jù)，再遍歷一次……明明可以一趟搞定的事，愣是干了三趟活兒。

更慘的是，頁面上一堆重復(fù)粘貼的組件，改一處要改八處；異步操作沒加錯(cuò)誤處理，用戶一刷新就白屏；多線程場景下變量亂飛，本地跑得好好的，上線直接崩給你看。

——這哪是AI助手？簡直是AI刺客！

?? 為什么會(huì)這樣？是因?yàn)锳I笨嗎？不，是因?yàn)槲覀儧]給它畫好地圖。

今天這篇文章，我們就來聊聊：如何用“規(guī)則之力”馴服AI編程助手，讓它從“搗蛋鬼”變成“靠譜隊(duì)友”。這不是玄學(xué)，而是一套已經(jīng)被社區(qū)大神 condor 和 jrista 驗(yàn)證過的實(shí)戰(zhàn)方法論。我會(huì)用最直白的語言、最生動(dòng)的比喻，帶你一步步走進(jìn)這場“人機(jī)協(xié)作革命”。

問題爆發(fā) —— AI不是笨，是你沒告訴它“規(guī)矩”

想象一下，你雇了個(gè)天才實(shí)習(xí)生，腦子轉(zhuǎn)得飛快，代碼敲得噼里啪啦，但從來不問需求細(xì)節(jié)，也不看項(xiàng)目規(guī)范，上來就按自己理解開干。

結(jié)果呢？

? 把“登錄按鈕”寫了五遍，每遍樣式還不一樣；

? 數(shù)據(jù)庫刪表腳本里夾帶 DROP DATABASE；

? 異步回調(diào)里忘了 await，測試全綠，上線全紅；

? 多線程共享變量，race condition 爆炸??

是不是很熟悉？

沒錯(cuò)，現(xiàn)在的LLM（大語言模型）就是這個(gè)“天才實(shí)習(xí)生”。它懂語法、懂框架、懂設(shè)計(jì)模式，但它不懂你的項(xiàng)目、你的團(tuán)隊(duì)、你的底線。

jrista 在論壇里說得特別透：

“KEY FACT: The agent and llm, they don’t really know anything! Not about what YOU WANT. They know the fundamentals. They do not know any specifics. UNLESS YOU TELL THEM!”

翻譯成人話就是：

AI不知道你要什么——除非你明明白白告訴它！

所以，別怪AI寫爛代碼，要怪就怪我們沒立規(guī)矩。

那規(guī)矩怎么立？光說“別寫重復(fù)代碼”、“注意線程安全”夠嗎？

不夠！

condor 提醒我們：

“Avoid too many negative statements like ‘a(chǎn)void…’ Negative statements may be associated with bad code as that happens so in training data.”

意思是：少說‘不要XXX’，多說‘應(yīng)該XXX + 為什么’。

因?yàn)锳I是從海量代碼中學(xué)出來的，而那些“壞代碼”里充斥著“avoid this”、“don’t do that”的注釋——它反而更容易把負(fù)面指令和“壞實(shí)踐”關(guān)聯(lián)起來！

所以我們得換種方式說話。

規(guī)則登場 —— 用“說明書”代替“口頭禪”

既然口頭叮囑沒用，那就寫成“產(chǎn)品說明書”。

jrista 的做法堪稱教科書級(jí)別：他把自己的規(guī)則文件命名為 unit-testing.mdc，內(nèi)容長達(dá)數(shù)百行，細(xì)致到連 Jest 命令參數(shù)拼寫錯(cuò)誤都要糾正：

:white_check_mark: ALWAYS USE THESE CORRECT PARAMETERS:
npx jest --testPathPattern="pattern"   # ? Singular form is CORRECT
npx jest --testNamePattern="pattern"   # ? Singular form is CORRECT  
npx jest --testRegex="pattern"         # ? Singular form is CORRECT

:cross_mark: NEVER USE THESE INCORRECT PARAMETERS:
npx jest --testPathPatterns="pattern"  # ? Plural form is INVALID

這不是強(qiáng)迫癥，這是防呆設(shè)計(jì)！

就像給實(shí)習(xí)生發(fā)《入職手冊(cè)》第37版，連“咖啡機(jī)按兩下出美式，按三下出拿鐵”都寫清楚，他就不會(huì)把濃縮倒進(jìn)豆?jié){機(jī)。

jrista 還強(qiáng)調(diào)：

“RULES. They are not a passing thought. They aren’t simple or light weight. They are the infrastructure that GOVERNS the agent and llm!”

規(guī)則不是便簽紙，而是基礎(chǔ)設(shè)施。是你和AI之間的“契約”，是它的“行為憲法”。

而且這些規(guī)則，不是一次性寫完就完事了。jrista 說他的每條規(guī)則都被AI自己迭代過三次——每次發(fā)現(xiàn)漏洞，就讓AI（比如 Sonnet 或 Grok Code）幫忙補(bǔ)丁，形成閉環(huán)。

這才是真正的“人機(jī)共治”。

終極絕招 —— 從“被動(dòng)修BUG”到“主動(dòng)造規(guī)則”

現(xiàn)在我們知道了：規(guī)則要詳細(xì)、要正面、要帶理由、要持續(xù)迭代。

但具體怎么落地？condor 和 jrista 給出了兩條黃金路徑：

? 路徑一：正面引導(dǎo) + 因果解釋（condor流）

與其說“別寫重復(fù)代碼”，不如說：

“提取共享邏輯到 helpers/services（DRY）——因?yàn)榧泄芾砟芎喕瘻y試、加速重構(gòu)、保持行為一致。”

與其說“別阻塞UI線程”，不如說：

“把耗時(shí)任務(wù)放進(jìn) BackgroundService ——這樣UI才不會(huì)卡頓，生命周期也能干凈處理。”

condor 提供了一整套 Blazor/C# 場景下的“正面規(guī)則模板”，比如：

? 使用 var 當(dāng)類型顯而易見 → 降低視覺噪音，重構(gòu)更安全

? 用 decimal 做金錢計(jì)算 → 避免浮點(diǎn)誤差

? JS interop 用小寫命名 → 防止大小寫不匹配

每一條都附帶技術(shù)后果說明，讓AI知道“為什么這么做”，而不是“老板讓我這么做”。

這就像給實(shí)習(xí)生講：“咖啡杯放左邊不是因?yàn)槲蚁矚g，而是因?yàn)橛沂帜檬髽?biāo)時(shí)左手順手——效率高，不容易灑。”

? 路徑二：強(qiáng)制約束 + 場景兜底（jrista流）

jrista 更狠：直接上“MANDATORY”（強(qiáng)制）、“CRITICAL”（關(guān)鍵）、“NEVER”（嚴(yán)禁）。

比如數(shù)據(jù)庫操作：

“Before allowing the agent to do anything, instruct it to create a backup. This is CRITICAL. MAN-DA-TO-RY!”

他還建議：

1. 不讓AI碰生產(chǎn)庫 → 用開發(fā)庫或克隆表

2. 先采樣幾行數(shù)據(jù) → 別讓它吞完整數(shù)據(jù)集燒token

3. 生成SQL腳本讓人執(zhí)行 → 腳本是確定性的，AI是非確定性的

4. 備份+驗(yàn)證+再上線 → 安全三重奏

這招叫“把AI關(guān)進(jìn)籠子，鑰匙交給人類”。

jrista 打了個(gè)比方：

“An LLM is probablistic in nature, and thus highly NON-DETERMINISTIC. You just don’t know what they might do!”

AI像只貓——聰明、敏捷、偶爾給你叼回一只老鼠（驚喜），但也可能半夜把你鍵盤當(dāng)蹦床（驚嚇）。你不能指望它自律，只能給它劃地盤、設(shè)圍欄、裝監(jiān)控。

實(shí)用技巧：不確定時(shí)，讓AI自己選方案

Serp 提了個(gè)超實(shí)用的規(guī)則草案：

“When unsure, propose options and ask for feedback.”

意思是：當(dāng)AI拿不準(zhǔn)時(shí)（比如命名、路徑、架構(gòu)選擇），別瞎猜，列出2~3個(gè)選項(xiàng)，帶上優(yōu)缺點(diǎn)，推薦一個(gè)默認(rèn)項(xiàng)，然后問你選哪個(gè)。

比如：

“關(guān)于這個(gè)日期工具函數(shù)，我有三個(gè)方案：

1. 單函數(shù)返回 {min, max} → 性能最優(yōu)，但API略復(fù)雜

2. 兩個(gè)獨(dú)立函數(shù) → 語義清晰，但重復(fù)遍歷

3. 用reduce一次遍歷 → 代碼簡潔，學(xué)習(xí)成本略高

我推薦方案1，默認(rèn)實(shí)現(xiàn)如下?? 你確認(rèn)嗎？”

這招妙在哪？

? 不浪費(fèi)token：避免AI腦補(bǔ)半天最后被你推翻

? 保留控制權(quán)：關(guān)鍵決策還是你在拍板

? 培養(yǎng)默契：久而久之，AI會(huì)越來越懂你的偏好

leoing 補(bǔ)充的“Refactor Trigger”也很贊：

只要你說“refactor @folder”，它就自動(dòng)：

? 刪死代碼

? 合并重復(fù)邏輯

? 數(shù)Provider數(shù)量（>3就報(bào)警）

? 提取常量到 const.dart

? 驗(yàn)證功能無損

——這已經(jīng)不是助手了，是自動(dòng)化管家！

總結(jié)：規(guī)則不是枷鎖，而是AI的“外掛大腦”

我們來快速復(fù)盤一下：

?? 問題根源：AI不是笨，是缺乏上下文和約束?? 解決方案：用詳盡、正面、帶因果的規(guī)則代替模糊指令?? 進(jìn)階技巧：強(qiáng)制約束 + 人工兜底 + 不確定時(shí)拋選項(xiàng)?? 終極目標(biāo)：讓AI從“自由發(fā)揮的實(shí)習(xí)生”進(jìn)化為“遵守SOP的高級(jí)工程師”

jrista 最后那句話我特別喜歡：

“Bring Your Own Intelligence! Together the agent and llm can behave semi-intelligently, but they again cannot really behave exactly correctly, without YOUR INSTRUCTION.”

BYOI —— 帶上你自己的智能！

AI是工具，規(guī)則是杠桿，而你，才是那個(gè)撬動(dòng)地球的人。

實(shí)戰(zhàn)建議：明天就能用的3條規(guī)則模板

你可以直接復(fù)制粘貼到你的 .cursor/rules/ 目錄下：

1. 【通用正面規(guī)則】

Extend existing code and keep the flow procedural.
→ 因?yàn)閱我谎葸M(jìn)路徑減少維護(hù)成本，縮小bug表面積。

2. 【異步安全規(guī)則】

Snapshot state in async methods.
→ 在async函數(shù)開頭把需要的值存到局部變量，因?yàn)榻M件狀態(tài)可能在await之間改變。

3. 【不確定時(shí)提問規(guī)則】

When unsure, propose 2–3 options with pros/cons, recommend default, then ask for confirmation.
→ 避免無效返工，確保對(duì)齊預(yù)期。

參考資料

? 論壇討論精華：https://community.cursor.so/t/ai-rules-and-other-best-practices

? jrista 的 unit-testing.mdc 規(guī)則文件（全文震撼）

? condor 的 Blazor/C# 正面規(guī)則清單

? leoing 的 Refactor Trigger 自動(dòng)化腳本