雙十一將至，用Rules玩轉電商場景提效詳情 - 前端,人工智能,知識,教程,程序員文心快碼博客

雙十一將至，結合電商場景，來聊聊如何 “讓AI寫代碼更省心” ——使用Rules幫助解決 “AI寫代碼總跑偏” 的問題。

01 什麼是Rules&如何使用Rules

Rules是什麼呢—— 是⼀組規則/指令，⽤來教AI在特定項⽬或框架中應該遵守的模式、最佳實踐和約束，做好這個規則⽂件，可以顯著提升AI⽣成代碼的質量、⼀致性，減少之後⼈⼯修正的⼯作。

可以把Rules想象成 “行為説明書”或者“工作守則”：

對人來説，Rules就像“公司員工手冊”👉 讓新同事知道要遵守什麼流程、不能亂改配置；
對AI來説，Rules就是“編程導航圖” 👉 讓 AI 明白項目結構在哪、該用什麼命令啓動、要注意哪些細節。

實際開發中，Rules可以理解為一套項目級的“開發約束與規範” ，幫助統一AI的編碼行為，讓生成的代碼更符合團隊習慣、項目架構和業務場景。來看看電商團隊在實際工作中是如何應用Rules的：

1、在Rules中定義環境依賴、啓動命令、目錄結構等，避免AI “自由發揮”；

2、針對電商業務，設置業務規則，比如所有的價格展示統一使用一個組件、涉及到的訂單狀態統一維護一個組件等；

3、加入團隊代碼規範和安全要求，例如在代碼中不能隨意引用npm包、寫法風格生成一致等；

4、定義錯誤處理機制，比如所有可能出錯的地方，都使用統一的機制處理（例如統一彈出錯誤信息、異常捕獲等）。

Rules就像是團隊的“AI導師”：

1）對新人友好： 即使是不熟悉項目的新同學，也能通過 Rules 快速瞭解項目規範和最佳實踐。

2）對AI可控： 讓AI生成的代碼“開箱即用”，減少人工review和修改成本。

3）架構一致： 確保代碼風格、目錄結構、技術棧統一，維護性更強。

02 電商場景下，未配置Rules的問題

相信大家平時都有網購經驗，肯定要關注所購買商品的狀態，以訂單詳情頁為例：根據設計稿，通過Figma to Code模式生成一個訂單詳情頁。

説明：Figma to Code是Zulu針對前端場景開發的功能，在傳統開發中，設計師出圖、前端再手寫頁面的流程被大大簡化了。如“訂單詳情頁”設計稿，通過Figma to Code模式，只需要將設計稿導入系統，就能自動生成可運行的頁面原型。

生成視頻👉https://mp.weixin.qq.com/s/QaZL34zk094i-BYWT_l55g

以上的生成過程，在沒有Rules的情況下有什麼問題？

當前，數據是按一個一個渲染的，而不是數組形式渲染；存在CSS文件的style沒有用到lang="less”,生成的文件默認用了“原始px”的寫法；圖標用的是符號，而不是組件icon。Comate生成的代碼沒有合理使用團隊所引用的組件庫、也沒有拆成特別細的組件，CSS的寫法也不是研發所要求的。此外，還會有一些通用性問題，例如樣式沒有按要求的規範去寫、組件的顆粒度不夠等。

未配置Rules，訂單詳情頁生成的結果

那麼，如何解決這些問題呢？切換到當前的代碼生成界面，輸入對話並引導改善。在沒有Rules的場景下，模型並不知道具體的業務規則、代碼規範或者樣式要求。想要修改一些問題（比如代碼格式不對、CSS寫法不規範、佈局跑偏等），只能依靠和模型的對話交互（Prompt）來一步步引導它調整，每次改動都需要重新輸入Prompt，明確告訴模型要改哪裏、怎麼改。

一次次“人工指導”——雖然靈活，但成本也比較高。隨着上下文越來越多，Prompt的長度也會增加，token消耗變高，模型響應速度也會變慢。如果問題過多，使用自然語言交互就會比較困難。

有沒有一種更好的方式，能讓模型“記住”這些通用規範？是不是可以通過配置Rules的方式，讓這些交互自動化？ 從而實現一次配置，長期生效。

03 電商場景下，配置Rules的效果

在沒有配置Rules的情況下，修改問題得靠一輪輪和模型對話。如果配置了Rules，會發生什麼樣的質變呢？ 可以把Rules想象成是給大模型配的一本「行為規範手冊」，它的效果主要分幾個層面：

1.命名約定 —— 代碼界的“起名大會”

命名約定模板就像在代碼界開了一場“起名大會”。變量不能隨便叫“張三”，函數也別整成“李四”。有了命名規則之後，模型就能統一風格、保證可讀性。不再出現一堆奇怪的名字。從此團隊協作更順暢，調試也不再像拆盲盒。

2.代碼結構 —— 給模型戴上“緊箍咒”

代碼結構約束就像是給模型戴了個“緊箍咒”。不允許模型寫“俄羅斯套娃”式的嵌套結構，也不允許函數變成一團“意大利麪條式”的災難代碼。有了結構約束後，代碼層次清晰、邏輯明瞭，就像寫作文有大綱，模型不會亂飆自由發揮。

3.業務邏輯層 —— 模型的“邏輯交警”

業務邏輯層是大模型的“腦回路”，而Rules在這裏扮演的角色，就像一個“邏輯交警”。它負責指揮——“這個流程該往哪跑”、“那個判斷在哪停”。防止模型亂開車、邏輯撞車，讓業務流轉更順暢、更可控。

有了Rules，模型就像從“自由創作”變成了“規範生產” ，既能理解設計意圖，又能按照標準穩定輸出。

目前有兩種配置Rules的方式，一種是採用編譯器，根據某個標準頁面生成：

第二種是手動更新項目Rules，找到入口，然後進行更新：

Rule具體內容如下：

---
description:
globs:
alwaysApply: true
---
## 項目概述
自動解析項目框架版本，這是一個移動端的項目，所有的樣式需要參考移動端來實現。
## 開發指南
1. **class 類名處理**
    - 所有 class 名應可讀、可猜測功能 統一採用 - 拼接法，如：content-title
    - 去除多餘複雜的 class 類名
    - 保持 class 層級扁平，儘量最多嵌套三層
2. **css 寫法**
    - 尺寸單位優先把 PX 改成 * @rex414 的寫法; （例如 1px 變成 1* @rex414），這一點一定要執行，不要使用 @rpx414。
    - 組件樣式必須加 lang="less"
    - 每個新寫的 style 文件 必須引入 @import 'src/lib/style/common.less';，這個只需要在<style></style>標籤裏面引入就行
3. **組件開發**
    - 事件命名採用 handleXxx 格式。
    - 組件請幫我寫在 src/routes/components 下，不要生成組件使用示例，直接生成組件。
4. **頁面開發**
    - 根據設計稿，並且根據頁面的模塊，請務必合理拆分組件！幫我把頁面寫在 src/routes/ 下。
    - 頁面的組件寫在 src/routes/components 下。
5. **圖片資源管理**
    - 所有的圖片都採取佔位符的方式實現。
    - 圖片的所有資源都要放在 assets 下，例如 list-demo 的圖片都放在 src/routes/list-demo/assets 下。
    - 例如，組件在 src/routes/list-demo/components 路徑下 組件使用圖片引入方式都需要按照 /assets/list-demo/image_1.png 這樣實現。

配置完Rules，下一步會打開設計稿，根據約束的方式自動生成代碼。

有了Rules的約束後，會有什麼樣的效果呢? 以上文提到的訂單詳情頁為例，可以明顯看出配置後項目代碼層級的優化（如CSS格式等）。

配置Rules後，訂單詳情頁代碼展示

電商場景下，配置Rules的效果視頻👉https://mp.weixin.qq.com/s/QaZL34zk094i-BYWT_l55g

04 Q&A

Q1: 在實際場景中，如何配置符合項目的Rules？

A：不要把AI看作一個能獨立完成工作的程序員，而應視為一個知識淵博但缺決策能力的程序員。Rules，就是給這位“隊友”的工作指引和邊界説明。首先要明確幾點：

明確不引入外部依賴確保生成代碼安全可控；
明確告知AI項目的架構與模式，確保數據的正確引入與使用；
告知AI項目使用的技術棧語法，保證生成代碼在項目中可用。

最好的方式，就是讓AI先生成一段代碼，發現不足後，總結成一個通用規範。如果項目有已存在文件，按照已有文件的代碼風格，自定義Rules的規則並逐步改善，最終使生成代碼與原有代碼風格保持一致。

Q2：沒有Rules時，AI輸出的代碼會出現哪些問題？

A：比如格式不統一、命名不規範、CSS或接口寫法不符合項目標準等，AI會“憑自己理解”生成，容易出現跑偏或低質量代碼。

Q3：沒有Rules時，有沒有快速讓AI輸出符合規範的方法？

A：在沒有配置Rules的情況下，可以通過一些方式儘量讓AI輸出符合規範，不過每種方法都有優劣。最直接的就是多輪對話逐步引導， 每次都要手動下指令，對寫提示詞的能力要求比較高、效率低，且容易出錯。除了多輪對話，還有一些輔助辦法：

1）Few-shot 示例： 給AI看幾個標準示例，讓它模仿好例子輸出；

2）RAG（檢索增強生成） ：把公司的規範文檔或者參考代碼庫檢索進來，讓模型在生成時參考，這樣可以減少偏離規範的情況。

但説到底，這些都是權宜之計，效率和穩定性都不如一次性建立Rules。一旦把規則配置好，模型就像有了“行動指南”，以後生成的代碼基本能自動符合規範，這才是真正一勞永逸的辦法。

Q4：Rules是不是隻針對前端項目有效？

A：Rules可以用在任何編程場景。 本質上，它就是給模型定規範、定邊界，告訴它“該怎麼做”、“不能亂做”。前端用它可以規範命名、組件風格、CSS寫法；後端可以約束函數命名、接口設計、數據庫操作、日誌格式；文檔、報告、甚至Markdown，也能規定模板、格式和用詞。甚至在多模型協作或者Agent場景，Rules也可以幫助明確輸入輸出、調用順序、任務邊界。只要你的任務有規範可遵循，Rules就能發揮作用，絕對不侷限於前端。針對不同的場景，可以寫不同的Rules去規範模型的輸出。