導讀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包含:
- 技術棧定義
整個工程使用的主要技術路線,作為後續代碼生成的基礎:
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
- ...
- 項目結構規範
項目的文件功能結構,指導後續代碼生成和修改到正確的位置:
Markdown
項目結構
src/
├── api/ # API 接口層
├── components/ # 可複用組件
├── views/ # 頁面視圖
├── utils/ # 工具函數
├── router/ # 路由配置
├── store/ # Pinia 狀態管理
├── assets/ # 靜態資源
├── hooks/ # Vue 組合式函數
├── directives/ # 自定義指令
├── constants/ # 常量定義
├── shared/ # 共享模塊
├── locales/ # 國際化
├── app/ # 應用核心
└── examples/ # 示例代碼
- 開發規範
從代碼的命名到組件的模板格式,從API的接口定義到異常處理,都需要一致的規範來約束:
Markdown
開發規範
代碼規範
- 組件命名 : 使用 PascalCase,多個單詞組合 (如:
KnowledgeServiceCard) - 文件命名: Vue 組件使用 PascalCase.vue,工具文件使用 camelCase.js
- 目錄命名: 使用 camelCase 或 kebab-case
- 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編程體驗。
核心要點回顧:
- 規則先行:建立完善的Project Rules
- 模板複用:構建高效的提示詞庫
- 工具增強:善用MCP擴展功能
- 持續優化:不斷改進工作流程
AI編程的未來不是替代開發者,而是讓開發者更專注於架構設計和業務邏輯,讓AI處理重複性的編碼工作。通過可控AI編程,我們可以在保證代碼質量的同時,大幅提升開發效率。