这几天不知道你有没有被千问APP请客的奶茶刷屏？反正我是喝到了手里捧着这杯热乎乎的“福利”，一边感受着糖分带来的快乐，一边盯着屏幕上滚动的代码，心里却五味杂陈。AI这股浪潮，早Yi不是什么“未来时”，而是实打实的“现在进行时”。它不仅走进了普通大众的生活，geng在我们程序员的圈子里掀起了一场甚至有些残酷的革命。

回想一下从Zui初VS Code里那个偶尔灵光一现的代码提示插件，比如GitHub Copilot、通义灵码，到现在风头正劲的Cursor、Trae这类Neng直接生成、编辑整个文件的AI编辑器，我们的工作方式正在被重塑。第一次尝试用Cursor的时候，那种感觉怎么形容呢？大概就像是一个刚学会骑车的孩子，kan着风驰电掣的F1赛车，心里只有一句：“哇，这也太强了吧！”

但兴奋劲儿一过紧接着就是深深的焦虑。眼kanAI一行行敲出代码，我不禁怀疑：我是不是要失业了？然而当我真正把这些代码接入现有工程时那种“失业焦虑”瞬间变成了“暴躁老哥”的吐槽模式。你来kankan，这dou是些什么玩意儿？

“你kan，这生成的代码风格，跟咱们项目里那套严谨的规范简直是两个世界，变量命名随心所欲，缩进dou透着一股叛逆劲儿；”

“你kan，需求理解完全跑偏了我要的是个查询列表，它给我整了个复杂的表单联动，是不是对‘查询’二字有什么误解？”

“Zui要命的是每次生成的逻辑还不一样，今天这么写，明天那么写，这要是上线了以后维护的人不得哭晕在厕所？”

这时候，摆在我们面前的只有两条路：要么把AI踢出团队，回到那个纯手写的“古典时代”；要么就想办法给这只“狂暴的野兽”套上缰绳。显然放弃是不可Neng的，毕竟它Neng干活，Neng提效。那么问题就变成了：怎么让AIgeng趁手？怎么让它真正成为团队的一员，而不是一个捣乱的“临时工”？

在折腾了快一年，踩了无数坑之后我算是摸出了一点门道。今天咱们就来聊聊，在现有工程中，如何制定一套切实可行的AI落地规范，让AI辅助开发真正稳定地“落地生根”。

一、 核心心法：把规则变成“可执行的说明书”

hen多时候，我们对AI的失望，源于我们沟通的方式太“人类”了。我们习惯于说人话、发语音、甚至截几张图，指望AINeng心领神会。但在工程领域，这种模糊的沟通是灾难的根源。

AI落地的前提，绝对不是你在聊天框里跟它聊得有多火热，而是你的需求和接口，必须被清晰、结构化地表达出来。别指望AINeng从零散的对话记录里拼凑出你的业务逻辑，那样生成的代码，注定是一坨难以维护的乱麻。

所以我们的核心策略非常简单，却又极其有效：把规则写成「可执行的说明 + 可粘贴的代码」。

这是什么意思呢？就是说你的规范文档不Neng只有干巴巴的文字描述，而应该是一套组合拳：清晰的说明文字、结构化的列表、可视化的目录树，以及Zui关键的——Ke以直接复制的代码块。配合Frontmatter与分文件组织，让AI在正确的时机、正确的范围内套用这些约定。这不仅Neng减少反复修改和风格漂移，geng重要的是当有新人加入，或者后续换了一个AI模型时这套规范依然Neng无缝继承，成为团队的“数字资产”。

二、 构建规则库：让AI拥有“项目记忆”

要让AI听话， 得给它建立一个“记忆宫殿”。在Cursor等支持`.cursorrules`或类似机制的工具中，我们Ke以通过一系列精心设计的Markdown文件来承载这些规则。

1. 总览文件：README.mdc

这是AI进入项目的“大门”。我们需要在这里告诉AI：这是个什么项目？核心目录结构是怎样的？主要入口文件在哪里？

我们Ke以利用Frontmatter来声明一些全局属性，比如：

---
alwaysApply: true
description: xxx-xxx-h5 项目规则总览
---
# xxx-xxx-h5 项目规则总览
## 规则文件说明
本目录包含 xxx-xxx-h5 项目的所有 Cursor 规则文件，用于指导 AI 助手geng好地理解和开发该项目。
### 规则文件列表
1.  **project-structure.mdc** - 项目结构指南
    *   项目概述和核心目录结构
    *   模块化架构特点说明
    *   主要入口文件和配置文件位置
2.  **vue-coding-standards.mdc** - Vue 3.x 编码规范
    *   Vue 组件开发规范
    *   JavaScript 编码标准
    *   路由和状态管理规范
    *   ...

通过`alwaysApply: true`，我们告诉AI这些规则是必须时刻遵守的。而编号列表和子项，则Neng让AI快速判断，在处理具体任务时应该去查阅哪个文件。这就像给AI发了一张地图，告诉它：“遇到路由问题，去翻第3号文件；遇到组件样式，去翻第5号文件。”

2. 编码规范：vue-coding-standards.mdc

这是解决“风格漂移”的关键。在Vue项目中，Zui头疼的就是AI生成的代码跟现有代码格格不入。我们需要在这里把“什么NengZuo，什么不NengZuo”写得清清楚楚。

比如关于“配置与数据元不写死”这一条，我们不仅要写原则，还要给代码示例：

// vue-coding-standards.mdc 中规定的方式
export default {
  computed: {
    // 必须使用 computed 获取配置，避免在 data 或 methods 中直接引用
    sbfConfigs:  => {
      return vm.$store.state.configs.xxx
    }
  }
}

注意这里的写法：先写“必须使用以下方式”，再贴代码。AI是非常善于模仿的，当你给出一个具体的模板时它会优先采用这种写法。紧接着，我们还要列出“注意事项”，比如“用户信息走getters、系统配置走state、箭头函数、避免在methods里访问store”。这些细节Neng大幅减少“Neng跑但不符合项目习惯”的垃圾代码生成。

3. 接口与集成：api-integration.mdc

有了清晰的输入，还需要统一的输出。API调用、状态管理方式、模块注册顺序，这些dou需要和现有项目保持高度一致。

比如我们Ke以规定“模块命名与注册统一”规则：业务模块用拼音首字母；新增模块严格按`router → store → api → views`的顺序注册，并在主入口中挂载。这样，AI生成的API封装、请求参数和DTO才Neng与后端约定一致，不会出现“自创接口”的情况。

三、 需求文档的变革：告别“聊天式”开发

有了规则库，接下来就是如何把需求喂给AI。hen多团队的习惯是产品经理在群里发几条语音，或者拉个会口头讲讲，然后就让开发去“kan着办”。这在AI时代是行不通的。

我们需要对需求文档进行一次“结构化改造”。整体上，需求文档应该按照“概述 → 流程 → 页面/接口表格 → 规则说明”的顺序来写。用表格和编号把控件、字段、映射、规则、组件编号固定下来。这不仅Neng让人一眼kan懂，gengNeng让AI按表生成代码、按规则生成逻辑，极大减少歧义和返工。

下面以一个典型的“xxxx缴费记录查询”模块为例，kankan我们该怎么Zuo。

1. 功Neng概述与流程图

不要用一大段文字去描述功Neng。用一两句话说明功Neng面向谁、Zuo什么、范围是什么。然后先画流程图，再配简短流程说明。

sequenceDiagram
    actor 用户
    participant 本功Neng as 本功Neng
    participant 外部系统 as 外部系统
    rect rgba
        Note over 用户,外部系统: 1. 
        用户->本功Neng: 访问xxxx缴费记录查询页面
        本功Neng->外部系统: 引用4.1规则初始化
        外部系统-->本功Neng: 返回初始化配置及数据
        本功Neng-->用户: 展示xxxx缴费记录
    end

这种可视化的逻辑，AI理解起来比纯文字快得多。

2. 页面需求分析：表格化一切

这是Zui关键的一步。我们要把页面拆解成区域，每个区域拆解成控件，全部填进表格里。

导航栏用表格式列出控件名称、可操作、控件类型、交互事件及规则；标题单独一行说明。

查询条件选择区域同样用一张表统一描述控件，列建议包含：控件名称、控件类型、默认值、数据元、交互规则、校验规则。

列表区域列出“展示项 + 取数口径 + 数据元”。例如缴费金额写清单位、格式。这样AINeng直接生成列表列定义和格式化逻辑。

3. 规则说明与配置

在需求文档的Zui后我们需要用编号规则把“页面初始化”、“查询规则”等说清楚，并与前文引用一致。

例如页面初始化逐条写“根据哪份配置Zuo哪件事”、“根据哪条规则初始化数据”。

geng重要的是系统参数配置。我们要建立一个“系统参数配置.md”，按模块列出“主页面提示信息参数配置”等，并说明使用场景、配置项、默认值。前端应：从配置读取提示语等，而不是在页面里写死。

比如提示内容取自“xxxx缴费记录查询 → 主页面提示信息参数配置”，若未配置则不显示。这样，AI会生成“从配置读取，未配置则不展示”的逻辑，而不是写死一段文字。这对于多地区、多环境部署至关重要，也便于后续的二次修改。

四、 实战中的“避坑”指南

制定了规范，不代表就万事大吉了。在实际执行中，还有一些细节需要特别注意。

1. 用现有模块当模板

在让AI生成新模块时Zui好明确告诉它：“参考`src/views/old-module`的实现方式”。让AI参考历史模块的`router/store/api/views`实现方式，再结合新的需求与接口文档，NengZui大程度减少风格偏差。这就像给新员工配了一个老员工带路，效果立竿见影。

2. 目录结构的约定

不要让AI随便乱放文件。在`project-structure.mdc`中，明确约定好目录树。例如：

xxxx缴费记录查询/
├── xxxx缴费记录查询-需求.md         # 功Neng概述、流程、页面与规则
├── xxxx缴费记录查询接口-需求.md     # 接口入参、出参、取值与规则
├── 系统参数配置.md                # 提示信息、开关等可配置项
└── 原型文件/                     # HTML/CSS/JS 原型

这种结构让AINeng够清晰地知道：需求文档在这里接口文档在那里配置文件又在另一个地方。它生成的代码结构，自然也就井井有条了。

3. 接口需求的标准化

接口需求文档中，建议包含：接口概述、入参/出参表、接口规则。这样，AI生成的API调用代码才Neng精准无误，不会出现字段名写错、类型不匹配的低级错误。

五、 ：规范是AI落地的“基础设施”

AI落地规范，听起来像是一堆枯燥的文档，但实际上，它是我们驾驭AI工具的“基础设施”。就像城市里的交通规则，kan似限制了自由，实则保障了所有人的效率。

通过将项目规则显式化，把结构、Vue、组件、API、业务模块、构建拆成独立规则文件，并让AI在上下文中Neng读到这些规则，我们就Neng把AI从一个“偶尔灵光的实习生”，培养成一个“懂规矩、高效率的资深工程师”。

这不仅仅是为了让代码写得geng漂亮，geng是为了让我们依然Neng保持对工程的掌控力。毕竟无论工具如何进化，清晰的逻辑、严谨的结构、可维护的代码，始终是我们软件工程师的立身之本。

所以别再犹豫了。从今天开始，为你手头的项目制定一套AI落地规范吧。当你下次kan着AI精准地生成出符合你心意的代码时你会感谢现在这个努力的自己。这杯奶茶，我干了你们随意！

---