導讀AI編程工具的興起讓開發效率有了質的飛躍，但很多開發者在使用過程中會發現一個問題：AI生成的代碼往往與現有項目的技術棧、編碼規範不匹配，需要大量的手動修改，開發效率拖了後腿。如何讓AI按照我們的意圖和規範來編寫代碼？這就是"可控AI編程"要解決的核心問題。
通過Cursor可控AI編程技術，我們大幅提升了開發效率，同時確保了產品的高質量和可靠性。本文將展示這一技術如何為企業創造實際價值。

作者：阮奇

楓清科技（Fabarta）前端開發專家

01可控AI開發技術的核心價值

效率提升數據

基於實際項目的統計數據顯示：

• 開發週期縮短60%：原本需要2周的功能模塊，現在可以在5天內完成

• Bug率降低50%：嚴格的約束機制確保了代碼的可靠性

• 系統維護成本降低60%：標準化規範減少了人為錯誤的發生

技術優勢

• 掌握前沿的AI輔助編程技術

• 建立標準化的開發流程

• 實現代碼質量的一致性保障

• 具備快速響應需求變化的能力

02可控AI編程的三大核心

約束：項目規範先行

約束是可控編程的關鍵，主要包括：

• 項目風格：代碼風格、命名規範

• 技術規範：技術棧限制、架構模式

• 修改範圍：明確代碼變更的邊界

需求：越清晰越好

給AI提供明確的需求規格（SPEC）是成功的第一步，模糊的需求只會得到模糊的結果。

最佳實踐：

• 提供詳細的功能需求文檔

• 明確輸入輸出格式

• 指定具體的技術實現要求

驗證和迭代：提示詞庫建設

建立個人或團隊的提示詞模板庫，實現高效複用。

03約束

Project Rules：可控編程的核心武器

什麼是Project Rules？

Project Rules（項目規則）是Cursor提供的一項核心功能，它能夠將項目的技術棧、結構規範、開發標準等信息告知AI，確保生成的代碼符合項目要求。

Project Rules的組成要素

以一個Vue前端工程為例，一個完整的Project Rules包含：

1. 技術棧定義

整個工程使用的主要技術路線，作為後續代碼生成的基礎：
Markdown

技術棧

• 前端框架: Vue 3.3.4 + JavaScript
• UI組件庫: Ant Design Vue 4.1.0
• 狀態管理: Pinia 2.1.7
• 路由管理: Vue Router 4.2.2
• 構建工具: Vue CLI 5.0.0
• 樣式預處理: Less 4.1.3
• 國際化: Vue I18n 9.2.2
• 微前端: qiankun 2.10.16
• HTTP客户端: Axios 1.4.0
• 代碼規範: ESLint + Prettier
• ...

2. 項目結構規範

項目的文件功能結構，指導後續代碼生成和修改到正確的位置：
Markdown

項目結構

src/
├── api/ # API 接口層
├── components/ # 可複用組件
├── views/ # 頁面視圖
├── utils/ # 工具函數
├── router/ # 路由配置
├── store/ # Pinia 狀態管理
├── assets/ # 靜態資源
├── hooks/ # Vue 組合式函數
├── directives/ # 自定義指令
├── constants/ # 常量定義
├── shared/ # 共享模塊
├── locales/ # 國際化
├── app/ # 應用核心
└── examples/ # 示例代碼

3. 開發規範

從代碼的命名到組件的模板格式，從API的接口定義到異常處理，都需要一致的規範來約束：
Markdown

開發規範

代碼規範

1. 組件命名 : 使用 PascalCase，多個單詞組合 (如: KnowledgeServiceCard)
2. 文件命名: Vue 組件使用 PascalCase.vue，工具文件使用 camelCase.js
3. 目錄命名: 使用 camelCase 或 kebab-case
4. JSDoc 註釋: 所有函數和組件必須添加 JSDoc 註釋

Vue 3 組件開發規範

• 優先使用 Composition API
• 使用 <script setup> 語法糖
• Props 定義使用 TypeScript 類型或運行時驗證
• 事件命名使用 kebab-case
• 組件文件結構: <template> → <script> → <style>

API 接口規範

• API 文件按業務模塊分組: knowledge.js, application.js
• 使用統一的 HTTP 請求工具: request.js
• 錯誤處理統一在請求攔截器中處理

樣式規範

• 使用 Less 預處理器
• 組件樣式使用 scoped
• 全局樣式定義在 App.less
• 主題配置使用 theme.js

圖1. 典型Project Rules文件示例

對比：有Rules vs 無Rules 的AI自動生成效果對比

以實現Figma設計中的登錄頁為例：

圖2. 原始Figma登錄頁面設計稿

無Rules的問題

當沒有Project Rules約束時：

• 使用錯誤的技術棧（如用原生HTML替代組件庫）

• 忽略國際化要求

• 不遵循現有的API接口規範

• 代碼風格與項目不一致

AI生成不可控，導致生成代碼不可維護；並且由於沒有使用工程已有的技術棧和樣式風格，導致生成頁面與設計相去甚遠，結果中還有編譯錯誤。

圖3. 沒有rules情況下自動生成的登錄頁面

有Rules的開發優勢

引入Project Rules後：

• 嚴格遵循項目技術棧

• 自動添加國際化支持

• 遵循既定的API接口規範

• 保持代碼風格一致性

• 生成的代碼可以直接運行

圖4. 在設置rule之後，生成的登錄頁面，還原度和可行性都很高

自動生成Project Rules

項目規則對於AI可控編程的作用極大，但是要手寫一份符合自己工程的Project Rules還是足以嚇退很多開發者的，好消息是Cursor從0.49版本開始支持自動生成Project Rules：
Plain Text

在Cursor中使用以下命令

/Generate Cursor Rules

AI會自動分析當前項目的代碼結構、技術棧和編碼規範，生成適合的Project Rules。

圖5. 自動生成符合當前工程的Project Rules

04需求

高效提示詞的四要素

基於實踐總結，優秀提示詞遵循"任務-規則-上下文-功能"結構，讓AI清晰理解上下文和邊界

圖6. 一個優秀cursor功能開發提示詞示例模板

任務（Task）

明確要完成的具體任務：
Markdown

任務

添加一個知識庫列表頁面

規則（Rules）

引用Project Rules確保代碼規範：
Markdown

規則

@cursor_rules 請遵循項目的開發規範

上下文（Context）

指定代碼的位置和入口：
Markdown

上下文

• 文件路徑：src/views/knowledge/
• 路由路徑：/knowledge/list
• 入口文件：src/router/index.js

功能（Features）

詳細描述功能需求：
Markdown

功能需求

數據層

• 調用知識庫列表API：GET /api/knowledge/list
• 支持分頁：pageSize=10
• 支持搜索：按名稱搜索

展現層

• 表格展示：名稱、創建時間、狀態
• 分頁組件：顯示總數、支持跳轉
• 搜索框：實時搜索功能

操作層

• 新增按鈕：跳轉到新增頁面
• 編輯按鈕：跳轉到編輯頁面
• 刪除按鈕：支持批量刪除

05最佳實踐建議

規則先行：為項目奠定堅實基礎

核心思想：在編寫任何功能代碼之前，首先要定義好項目的規則（Project Rules）。這就像建造大樓前必須有精準的藍圖一樣。

對於新項目：不要從零開始。可以利用社區提供的優秀規則模板（如 https://www.cursorrules.org/），結合自身項目的技術棧進行定製。先花半天時間完善規則，勝過後續一週的修補工作。

對於現有項目：利用 /generate cursor rules 命令，讓AI分析現有代碼庫，自動生成一套基準規則然後微調，確保規則既符合現狀，又能引導未來的開發方向。

規則的版本化管理：將 .cursor-rules 文件納入Git版本控制，存放在項目根目錄。這樣，不僅團隊成員能共享最新的規則，AI也能在每次交互中獲取到最準確的上下文，確保代碼生成的一致性。

定期維護：規則不是一成不變的。建議在每個迭代週期（Sprint）結束時，花少量時間回顧並更新規則，廢棄過時的模式，引入新的最佳實踐。

模板建設：將重複性工作標準化

核心思想：將常見的開發任務（如創建組件、API、測試用例）製作成標準化的提示詞模板（Prompt Template），將開發人員從重複的思考和輸入中解放出來。

識別高頻場景：分析團隊的日常工作，找出最常進行的開發任務。例如，"創建一個包含數據表格和搜索功能的Vue頁面"、"實現一個符合RESTful風格的Node.js API接口"等。

建立提示詞庫：在項目中創建一個 PROMPTS.md 文件，用於存放這些標準化的提示詞模板。一個好的模板應包含我們前面提到的四要素：任務、規則、上下文、功能。

Markdown

新建頁面的開發提示詞模板

需求

添加一個知識庫列表頁面

參考的頁面或者組件

設計Figma

rules：

頁面信息

• 路徑：/kbList
• 文件：src/views/demo/KbList.vue
• 標題：知識庫列表

功能需求

列表功能：

• 表格：名稱、創建時間、類型、操作
• 分頁、排序、多選 搜索篩選：
• 名稱搜索框 操作功能：
• 名稱搜索框
• 新建按鈕
• 行操作：刪除

共享與迭代：鼓勵團隊成員貢獻和完善這個模板庫。每當有人發現一個更高效的提問方式時，都應該更新到共享的模板庫中，讓整個團隊受益。

工具組合：發揮1+1\>2的效能

核心思想：Cursor不是要取代現有的開發工具鏈，而是要作為核心加速器融入其中，與代碼審查（Code Review）、自動化測試等工具形成合力。

AI輔助Code Review：在提交Pull Request (PR) 之前，可以讓AI先進行一輪預審查：@codebase /review 請根據項目規範檢查這段代碼的潛在問題。AI可以快速發現命名不規範、缺少註釋、代碼風格不一致等問題，從而讓團隊成員的Review更專注於業務邏輯和架構設計。

自動化測試生成與驗證：利用AI快速生成單元測試和集成測試的草稿。@file.test.js 請為這個文件中的 [函數名] 方法編寫單元測試，覆蓋正常和異常場景。然後，將這些測試用例納入CI/CD流水線，自動驗證AI生成代碼的正確性，形成"AI生成代碼 -\> CI自動驗證 -\> 人工審查邏輯"的高效閉環。

與設計工具聯動：通過 Figma MCP 等工具，實現從設計稿到代碼的直接轉換，極大減少UI開發中的信息損耗和重複勞動。

06總結

Cursor可控AI編程不是簡單地讓AI寫代碼，而是建立一套完整的約束和指導體系，讓AI在規範的框架內發揮最大價值。通過Project Rules、提示詞模板和MCP工具的組合使用，我們可以真正實現"可控"的AI編程體驗。

核心要點回顧：

1. 規則先行：建立完善的Project Rules
2. 模板複用：構建高效的提示詞庫
3. 工具增強：善用MCP擴展功能
4. 持續優化：不斷改進工作流程

AI編程的未來不是替代開發者，而是讓開發者更專注於架構設計和業務邏輯，讓AI處理重複性的編碼工作。通過可控AI編程，我們可以在保證代碼質量的同時，大幅提升開發效率。