通義靈碼的 Project Rules 功能真的解決了我使用 AI 編碼過程中最實際的一些“誤差”問題。現在我的 AI 編碼助手不再“天馬行空”，而是真的按照我的要求來“定制產出”。

作者：不起名字可以不

我是一名全棧開發，平時會大量使用通義靈碼做代碼生成、接口注釋、測試代碼補全等工作，效率提升是真的肉眼可見。最近通義靈碼推出的 Project Rules 功能，我立刻體驗了一下，現在已經用上了！

為什么我需要定制規則？

在我們項目組里，不同人寫出來的代碼格式和命名習慣不一樣，尤其是通過 AI 輔助生成的代碼，有時會“跑偏”，比如：

• 用了不符合我們項目約定的注釋風格
• 命名不貼合業務語義
• 忽略了我們常用的工具類

以前每次 review 都要花時間來調整格式或重命名，現在我直接通過 Project Rules 把這些偏好告訴 AI，生成出來的代碼更“懂我”了。

我的 Project Rules 示例配置

規則限制

每個規則文件最大限制為 10000 字符，超過部分將自動截斷。

規則文件請使用自然語言描述，不支持圖片或鏈接的解析。

我的項目語言是 Vue（使用 Vue 3 + Composition API） ，以下是我對代碼風格、注釋方式和生成代碼的偏好：

### 1. 語法和框架規范：
- 使用 Vue 3 的 **Composition API**，不使用 Options API；
- 腳本部分必須使用 `<script setup>` 語法；
- 模板中盡量使用簡潔語法，如 `v-if / v-for / v-model`，避免多余嵌套；
- 盡量避免使用 `any` 類型，優先使用 TypeScript 明確類型；
- 如果使用了異步請求，默認封裝為 `useXXX()` 的組合式函數，統一放在 `composables/` 文件夾中；
- 所有頁面組件統一放在 `views/` 文件夾中，通用組件放在 `components/` 中。
### 2. 命名規范：
- 文件命名統一為 **小寫中劃線格式**（如：`user-list.vue`）；
- 變量、函數名使用 **camelCase**；
- 組件名使用 **PascalCase**；
- 鉤子函數命名使用 `use` 前綴，如 `useUserList`；
- SCSS 變量使用 `$` 開頭，命名清晰，避免縮寫。
### 3. 注釋風格：
- 所有方法必須添加注釋，注釋風格清晰簡潔，使用自然語言說明該方法的作用；
- 對于復雜邏輯、watchEffect、computed 計算過程請寫明業務含義；
- 文件頂部應注明作者、創建時間和功能簡述；
- 注釋語氣中性，不帶個人語氣，不重復代碼內容。
### 4. 樣式和布局：
- 使用 SCSS 或 Less 預處理器，**禁止在 style 中使用 scoped**；
- 樣式統一使用 BEM 命名規范；
- 組件布局使用 CSS Grid 或 Flex，禁止使用 table；
- 移動端優先使用 rem 單位，桌面端可適當使用 px。
### 5. 代碼結構和項目約定：
- 每個組件文件中順序為：模板（template）> 腳本（script）> 樣式（style）；
- API 請求統一封裝到 `api/` 文件夾中，禁止在組件內直接寫 `axios` 請求；
- 所有 API 響應結果請使用統一的響應封裝器處理（如 `useRequest()`）；
- 表單組件封裝時需支持 `v-model` 雙向綁定。
### 6. 響應和異常處理：
- 所有請求必須添加異常捕獲處理，如 `try/catch` 或 `onError` 鉤子；
- 異常提示語應通用，避免硬編碼字符串；
- 頁面加載時使用骨架屏或 loading 動畫，避免頁面空白。
### 7. 通義靈碼回復和生成內容要求：
- 靈碼回答請使用中文；
- 回答內容結構清晰，重點內容可使用列表展示；
- 不推薦使用未經引入的三方包，如 lodash、dayjs，除非已有安裝；
- 如生成表單、表格代碼，請基于 Element Plus UI 框架；
- 建議代碼塊加上簡要解釋，便于理解。

通義靈碼提效使用經驗

?? 提高注釋生成質量

平時讓我頭疼的就是寫注釋，現在用了 Javadoc 規范 + neutral 評論語氣，通義靈碼生成的注釋幾乎可以直接使用，甚至文檔都不太用手動整理了。

?? 避免不必要的“AI 幻覺”

之前我讓它幫我生成一個工具方法，它老是引入我們項目中沒有的三方庫，現在通過 "use_stream_api": false 和 "exception_handling": "customExceptionClass"，它會更貼近我項目的寫法。

?? 團隊協作保持一致性

我們組里是多人協作，我直接把 project-rules.json 加進 git 項目中，大家用同一套規則，不僅生成代碼風格統一，連靈碼生成的提示回復也更一致，review 也更省事了。

使用建議 & 期待

• 希望之后能支持團隊規則庫共享和一鍵應用；
• 如果能內置幾套“通用行業規則模版”（比如 Spring Boot 項目推薦規則）就更友好了；
• 靈碼提示區支持高亮哪些是根據 Rules 特別優化過的部分，會更直觀。

總結一下

通義靈碼的 Project Rules 功能真的解決了我使用 AI 編碼過程中最實際的一些“誤差”問題。現在我的 AI 編碼助手不再“天馬行空”，而是真的按照我的要求來“定制產出”。

如果你也經常用靈碼寫業務邏輯、處理項目細節，強烈推薦你定制一份屬于自己的編碼規則，效果真的不一樣！

下載通義靈碼：https://lingma.aliyun.com/download