让 AI 真正成为你的「结对编程搭档」
如果说 AI 编程助手是一把瑞士军刀，那 AI 工程化就是教你如何把这把刀磨得更锋利、用得更顺手的方法论。
前言：AI 编程的「野蛮生长」与「工程化觉醒」
你是否有过这样的体验？
- 让 AI 写代码，它写出来的风格和项目完全不搭
- 每次开新会话，都要重复解释一遍项目背景
- AI 生成的代码能跑，但完全不符合团队规范
- 让 AI 改一个 bug，它把旁边好好的逻辑也改坏了
这些问题的根源不是 AI 不够聪明，而是你没有给它足够的「上下文」和「约束」。
AI 工程化，就是用工程化的思维，系统性地解决「人与 AI 协作」中的效率和质量问题。
核心概念：先搞懂这些「黑话」
LLM（大语言模型）—— AI 的「大脑」
类比：如果把 AI 编程助手比作一个新入职的高级工程师，LLM 就是他的「大脑」和「知识储备」。
LLM（Large Language Model）是一切 AI 编程能力的基座。它通过海量代码和文本训练，具备了：
- 代码理解能力：能读懂你的代码意图
- 代码生成能力：能根据描述生成代码
- 推理能力：能分析问题、规划方案
- 上下文理解：能在对话中保持连贯
常见的 LLM：
| 模型 | 特点 | 适用场景 |
|---|---|---|
| Claude (Anthropic) | 长上下文、逻辑严谨 | 复杂工程任务、代码审查 |
| GPT-4o (OpenAI) | 通用能力强、生态丰富 | 全栈开发、快速原型 |
| DeepSeek Coder | 代码专项优化、性价比高 | 纯代码生成、算法实现 |
| Qwen (通义千问) | 中文理解强、开源可控 | 国内项目、私有化部署 |
关键认知：LLM 再强大，也只是一个「有知识但没有项目经验的新人」。它需要你告诉它：项目用什么技术栈、团队有什么规范、业务有什么特殊逻辑。这就是 Rules 的价值。
Rules（规则）—— AI 的「员工手册」
类比：Rules 就像你给新员工的「入职须知 + 编码规范 + 项目文档」的合集。
Rules 是写给 AI 看的指令文件，告诉 AI：
- 你是谁（角色定义）
- 项目是什么（技术栈、架构）
- 怎么写代码（编码规范）
- 怎么做事（工作流程）
Rules 的分类
Rules 体系
├── 通用 Rules（Global）—— 所有项目通用的基础规范
│ ├── 语言偏好（用中文对话、英文思考）
│ ├── 代码风格（注释规范、命名规范）
│ └── 安全规则（不泄露密钥、不删生产数据）
│
├── 项目 Rules（Project）—— 特定项目的技术上下文
│ ├── 技术栈说明（React/Vue + TypeScript）
│ ├── 目录结构（pages/、components/、services/）
│ ├── 编码规范（组合式 API、Hooks、状态管理）
│ └── 路由/请求/状态管理的统一用法
│
└── 需求 Rules（Task）—— 具体需求的实现指导
├── 需求理解文档
├── 技术方案设计
├── 任务拆解清单
└── 会话交接文档
真实案例：一个项目 Rule 长什么样？
# 项目纵览（Next.js + React + TypeScript）
- 框架：Next.js 14（App Router）
- 语言：TypeScript 严格模式
- 状态管理：Zustand
- 样式方案：Tailwind CSS
- 路径别名：统一使用 `@/` 绝对路径导入
- 组件库：shadcn/ui
## Service 层规范
- 统一请求实例：`src/lib/request.ts`（基于 fetch 封装）
- 业务服务放在 `src/services/xxx.service.ts`
- 严禁在组件中直接发起请求
## 组件规范
- 使用函数式组件 + Hooks
- Props 必须定义 TypeScript 接口
- 复杂逻辑抽离为自定义 Hook（以 use 开头）
为什么 Rules 这么重要？ 因为 LLM 的上下文窗口是有限的。Rules 让 AI 在每次对话开始时，就自动加载最关键的项目信息，而不需要你每次手动复述。
Rules 的触发方式
| 触发方式 | 说明 | 适用场景 |
|---|---|---|
| Always Apply | 每次对话自动加载 | 项目规范、通用规则 |
| File Match | 编辑特定文件时加载 | 组件规范、样式规范 |
| Manual | 手动引用时加载 | 特定需求文档、参考资料 |
MCP（Model Context Protocol）—— AI 的「外接设备」
类比：如果 LLM 是大脑，Rules 是记忆，那 MCP 就是 AI 的「手」和「眼睛」——让它能触达外部世界。
MCP（模型上下文协议）是 Anthropic 提出的开放标准，定义了 AI 如何与外部工具和数据源交互。你可以把它理解为 AI 世界的「USB 接口」——标准化、可插拔、即插即用。
MCP 解决了什么问题？
没有 MCP 之前：
你：帮我看看这个接口的字段定义
AI：我无法访问你的接口文档，请把内容贴给我
你：（手动复制粘贴一大段 JSON Schema）
AI：好的，我看到了...
有了 MCP 之后：
你：帮我看看用户登录接口的定义
AI：（自动调用接口文档 MCP 获取信息）
我已经获取到了接口定义，请求参数是...返回字段是...
前端常用的 MCP 服务
| MCP 服务 | 能力 | 使用场景 |
|---|---|---|
| 文档 MCP | 读取飞书/Notion/语雀文档 | 获取产品需求文档 |
| Swagger/OpenAPI MCP | 读取接口定义 | 获取后端接口字段、类型 |
| Figma MCP | 读取设计稿 | 获取 UI 尺寸、颜色、布局 |
| GitHub MCP | 操作 Git 仓库 | 创建 PR、查看 Issue |
| 数据库 MCP | 查询数据库 Schema | 了解数据结构 |
| Playwright MCP | 浏览器自动化 | E2E 测试、页面截图 |
MCP 的配置方式
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ghp_xxx" }
},
"figma": {
"command": "npx",
"args": ["-y", "figma-developer-mcp", "--figma-api-key=xxx"]
},
"playwright": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-playwright"]
}
}
}
MCP 的本质：它把「人工复制粘贴信息给 AI」这个动作，变成了「AI 自己去查」。这不仅节省时间，更重要的是保证了信息的准确性和实时性。
Skill（技能）—— AI 的「肌肉记忆」
类比：如果 Rules 是「知道该怎么做」，Skill 就是「已经做过很多次，形成了固定套路」。
Skill 是预定义的、可复用的操作模式。它把复杂的多步骤任务封装成一个「技能」，AI 可以直接调用。
Skill 的典型形态
技能：创建新页面
├── 步骤1：在 src/app/ 下创建路由目录
├── 步骤2：创建 page.tsx（使用标准页面模板）
├── 步骤3：创建 layout.tsx（如需独立布局）
├── 步骤4：创建对应的 hooks 文件
├── 步骤5：创建对应的 service 文件
└── 步骤6：添加页面级别的类型定义
Skill vs Rules 的区别
| 维度 | Rules | Skill |
|---|---|---|
| 本质 | 知识/规范 | 操作/流程 |
| 作用 | 告诉 AI「什么是对的」 | 告诉 AI「怎么做」 |
| 触发 | 自动/条件加载 | 主动调用 |
| 类比 | 员工手册 | SOP 操作手册 |
Steering（导航文件）—— AI 的「GPS 导航」
类比：Steering 就像开车时的 GPS——不是告诉你交通规则（那是 Rules），而是在你开车的过程中，实时告诉你「下一步往哪走」。
Steering 文件是一种更灵活的上下文注入机制，可以根据不同条件动态加载不同的指导信息。
---
inclusion: fileMatch
fileMatchPattern: "src/components/**/*.tsx"
---
# 组件开发导航
当你在开发组件时，请注意：
1. 必须使用函数式组件 + TypeScript
2. Props 必须定义接口类型
3. 复杂逻辑抽离为自定义 hooks（以 use 开头）
4. 导出时使用命名导出，组件名使用 PascalCase
Hook（钩子）—— AI 的「条件反射」
类比：Hook 就像人的条件反射——当特定事件发生时，自动触发特定行为，不需要你手动指挥。
{
"name": "Lint on Save",
"version": "1.0.0",
"when": {
"type": "fileEdited",
"patterns": ["*.ts", "*.tsx"]
},
"then": {
"type": "runCommand",
"command": "npm run lint"
}
}
常见的 Hook 场景
| 触发事件 | 动作 | 效果 |
|---|---|---|
| 文件保存 | 运行 lint | 实时发现代码问题 |
| 提交代码前 | 运行测试 | 防止引入 bug |
| AI 写文件前 | 检查规范 | 确保代码符合标准 |
| 任务完成后 | 运行构建 | 验证代码可编译 |
Agent（智能体）—— AI 的「自主行动模式」
类比：普通的 AI 对话像「问答」——你问一句它答一句。Agent 模式像「委托」——你说一个目标，它自己规划步骤、调用工具、完成任务。
Agent 的核心能力：
- 规划：把大任务拆解为小步骤
- 执行：调用工具（MCP）完成每个步骤
- 观察：检查执行结果是否符合预期
- 调整：根据结果调整后续计划
用户：帮我实现用户登录的表单页面
Agent 的思考过程：
1. 读取技术方案文档，了解登录功能的设计要求
2. 读取现有代码，了解项目的表单组件用法
3. 调用 Figma MCP，获取登录页的 UI 设计稿
4. 调用 OpenAPI MCP，获取登录接口的定义
5. 编写组件代码
6. 运行 lint 和类型检查
7. 更新任务进度文档
它们之间的关系：一张图说清楚
┌─────────────────────────────────────────────────────────┐
│ AI 编程助手（IDE） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ LLM │ │ Rules │ │ Steering │ │
│ │ (大脑) │◄───│ (记忆) │◄───│ (导航) │ │
│ └────┬─────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Agent │───►│ MCP │───►│ 外部服务 │ │
│ │ (行动力) │ │ (接口) │ │(GitHub等) │ │
│ └────┬─────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Skill │ │ Hook │ │
│ │ (套路) │ │(条件反射) │ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
一句话总结：
LLM 提供智能，Rules 提供知识，MCP 提供能力，Skill 提供套路，Steering 提供导航，Hook 提供自动化，Agent 把这一切串起来自主工作。
工程化实践：如何在前端项目中落地？
第一步：建立 Rules 体系
这是 AI 工程化的地基。一个成熟的 Rules 体系应该分层设计：
.cursor/rules/（或 .kiro/steering/）
├── general.mdc # 通用规则：语言、风格、安全
├── project.mdc # 项目规则：技术栈、目录、规范
├── workflow.mdc # 工作流：需求→分析→设计→编码
├── technical-design.mdc # 技术方案规范
├── figma.mdc # UI 还原规范
├── typescript.mdc # TS 编码规范
└── FEAT-1234/ # 具体需求的 Rules
├── 需求理解.md
├── 需求分析.md
├── 技术方案设计.md
└── 任务拆解.md
写好 Rules 的关键原则
-
具体胜于抽象
- ❌ "请写出高质量的代码"
- ✅ "使用函数式组件 + TypeScript，Props 必须定义接口，复杂逻辑抽离为自定义 hooks"
-
示例胜于描述
- ❌ "请求要统一封装"
- ✅ 给出一个完整的 service 文件示例代码
-
约束胜于建议
- ❌ "建议使用绝对路径"
- ✅ "严禁使用深层相对路径，统一使用 @/ 别名"
-
分层胜于堆砌
- 不要把所有规则写在一个文件里
- 按职责分文件，按条件触发加载
第二步：接入 MCP 服务
根据团队的工具链，接入对应的 MCP 服务：
团队工具链 对应 MCP
─────────────────────────────────────
飞书/Notion（需求文档） → 文档 MCP
Swagger（接口文档） → OpenAPI MCP
Figma（UI 设计） → Figma MCP
GitHub（代码管理） → GitHub MCP
PostgreSQL（数据库） → Database MCP
Sentry（错误监控） → Sentry MCP
接入 MCP 的收益：
| 场景 | 没有 MCP | 有 MCP |
|---|---|---|
| 看接口文档 | 手动打开 Swagger → 复制 → 粘贴给 AI | AI 自动读取，直接生成类型定义 |
| 还原 UI | 手动量尺寸 → 告诉 AI 参数 | AI 自动读取 Figma 节点数据 |
| 查 Bug | 手动看 Sentry 日志 → 描述给 AI | AI 自动获取错误堆栈和上下文 |
第三步：设计工作流（Workflow）
这是 AI 工程化的核心——把「人与 AI 协作」的过程标准化。
一个完整的 AI 辅助开发工作流
graph TD
A[需求文档] --> B[需求理解阶段]
B --> C[需求分析阶段]
C --> D[技术方案设计]
D --> E[任务拆解]
E --> F[编码实施]
F --> G[代码审查与验收]
B -->|文档 MCP| B1[自动读取需求文档]
C -->|代码分析| C1[理解现有代码结构]
D -->|OpenAPI MCP| D1[获取接口定义]
D -->|Figma MCP| D2[获取 UI 设计]
F -->|Agent 模式| F1[自主编码+验证]
G -->|GitHub MCP| G1[创建 PR + Review]
每个阶段 AI 做什么、人做什么？
| 阶段 | AI 的职责 | 人的职责 |
|---|---|---|
| 需求理解 | 读取文档、提炼要点、识别歧义 | 确认理解、补充信息 |
| 需求分析 | 分析代码现状、拆解功能模块 | 确认页面路径、提供接口文档 |
| 技术方案 | 设计架构、识别难点、规划方案 | 审核方案、确认技术选型 |
| 任务拆解 | 拆解为可执行任务、标注依赖 | 确认优先级、调整粒度 |
| 编码实施 | 按任务逐步实现、自动验证 | 代码审查、功能验收 |
第四步：建立质量保障机制
AI 生成的代码不能「无脑信任」，需要建立多层质量保障：
质量保障体系
├── Hook 层：文件保存时自动 lint + 类型检查
├── Rules 层：编码规范约束（AI 生成即合规）
├── 验收层：每个功能单元人工验收
├── 测试层：关键路径自动化测试
└── 回溯层：产物文档同步更新机制
质量度量指标
衡量 AI 工程化效果的几个关键指标：
| 指标 | 含义 | 目标 |
|---|---|---|
| 首次生成合规率 | AI 生成的代码无需修改即符合规范的比例 | > 80% |
| 上下文命中率 | AI 正确理解项目上下文的比例 | > 90% |
| 返工率 | AI 生成后需要人工大幅修改的比例 | < 20% |
| 工作流完成率 | 按标准流程走完的需求比例 | > 70% |
这些指标越好，说明 Rules 写得越精准、MCP 接入越完善、工作流设计越合理。
思考：如何让 AI 工程化真正落地？
思考一：Rules 不是一次性的，是「活文档」
很多团队写了 Rules 就放在那里不管了。但好的 Rules 应该：
- 随项目演进：新增了组件库？更新 Rules
- 随问题修正：AI 总犯同一个错？加一条 Rule
- 随团队共识：团队讨论出新规范？同步到 Rules
思考二：MCP 的价值在于「消除信息差」
AI 最大的短板不是「不会写代码」，而是「不知道该写什么」。MCP 的核心价值是：
- 让 AI 能直接获取「最新的、准确的」业务信息
- 消除「人工转述」过程中的信息损耗
- 让 AI 的输出从「大概对」变成「精确对」
思考三：工作流的本质是「信任的渐进建立」
为什么要分阶段？为什么每个阶段都要人确认？
因为 AI 工程化不是「把活全丢给 AI」，而是：
- 先让 AI 理解（需求理解）→ 人确认理解正确
- 再让 AI 分析（需求分析）→ 人确认分析到位
- 然后让 AI 设计（技术方案）→ 人确认方案可行
- 最后让 AI 执行（编码实施）→ 人验收代码质量
每一步都在建立信任，每一步都在缩小 AI 犯错的空间。
思考四：不要追求 100% AI 生成
AI 工程化的目标不是「完全替代人」，而是：
- 把 80% 的重复劳动交给 AI（模板代码、CRUD、样式还原）
- 让人专注于 20% 的核心决策（架构设计、业务逻辑、用户体验）
最高效的模式是：人做决策，AI 做执行；人定方向，AI 填细节。
快速上手：三步开始你的 AI 工程化
Step 1：写一份项目 Rule（30 分钟）
把你项目的技术栈、目录结构、编码规范写成一份 markdown，放到 .cursor/rules/ 或 .kiro/steering/ 目录下。
Step 2：接入一个 MCP（1 小时）
从最常用的工具开始，比如 GitHub MCP 或 Figma MCP。让 AI 能自动读取外部信息，这一个改变就能节省大量时间。
Step 3：定义一个简单的工作流（2 小时）
不需要一步到位。先定义「需求理解 → 编码实施」两个阶段，跑通后再逐步完善。
效果对比：工程化前 vs 工程化后
| 维度 | 工程化前 | 工程化后 |
|---|---|---|
| 上下文传递 | 每次手动复述项目背景 | Rules 自动加载 |
| 信息获取 | 手动复制粘贴文档 | MCP 自动获取 |
| 代码规范 | AI 随机风格，人工修正 | 首次生成即符合规范 |
| 任务管理 | 口头描述，容易遗漏 | 文档化追踪，可回溯 |
| 质量保障 | 全靠人工 review | Hook 自动检查 + 人工验收 |
| 知识沉淀 | 散落在聊天记录中 | 结构化产物文档 |
| 协作效率 | 单次对话有效 | 跨会话、跨成员可复用 |
总结
AI 工程化 = Rules（知识） + MCP（能力） + Workflow（流程） + Hook（自动化）
它不是一个工具，而是一套方法论。核心思想是：
用工程化的方式，把 AI 从「偶尔好用的玩具」变成「稳定可靠的生产力工具」。
就像软件工程把「写代码」变成了「做工程」一样，AI 工程化把「和 AI 聊天」变成了「与 AI 协作」。
延伸阅读
如果这篇文章对你有帮助，欢迎点赞收藏。你的团队是怎么做 AI 工程化的？欢迎在评论区分享实践经验。
