next level 的前端开发姿势：前端 Prompt 工程化

💡 思考：程序员要"懒"（提高做事的效率）。我觉得不仅是程序员，我们所有人都应该有这个"懒"劲。正是因为"懒"，才会去动脑寻找更好的解决方案，达到我们最终的目的。

一、为什么需要寻找新的开发模式？

传统开发模式的困境

传统的开发流程：产品 → UI 设计 → 交互设计 → 开发 → 测试

存在的痛点：

❌ 样式、交互难以完全还原设计稿、缺乏统一的交互规范和方案，且开发周期较长
❌ 开发效率受限于重复性工作
❌ 沟通成本高，需求传递层层衰减

我们真正需要的：

提升开发效率 - 减少重复劳动，专注业务逻辑
提升开发质量 - 保证样式和交互的一致性
提升开发体验 - 让开发过程更流畅、更愉悦

二、我们应该如何解决以上这些问题呢？

答：使用 ai 编程工具

AI 技术能力现状

目前 AI 技术（如 GPT-4/5、Claude 等）已经具备：

✅ 理解自然语言描述的需求
✅ 生成符合规范的代码
✅ 提供优秀的交互体验方案
✅ 解决传统开发中交互不够流畅的问题

AI 能带来的价值：

快速原型开发：通过 Prompt 快速生成页面结构
交互方案优化：AI 可以提供最佳实践的交互设计
降低技术门槛：让非技术人员也能参与开发过程
代码质量提升：基于优秀的 Prompt 代码规则，约束代码规范

是否真的能帮助解决上述的问题呢？

AI Coding 带来的新问题

在 AI 编程工具刚出现时（2021-2022），开发者面临一个严重问题：

问题场景：

开发者："帮我创建一个 Vue 组件"

AI 生成：
- 有时用 Vue 2，有时用 Vue 3
- 有时用 Options API，有时用 Composition API  
- 有时用 JavaScript，有时用 TypeScript
- 组件命名风格不统一
- 完全无法保证代码规范一致性

新的痛点：

❌ 每次生成都是"开盲盒"，不可控
❌ 需要反复修正 AI 的错误倾向
❌ 团队协作时代码风格混乱
❌ 每次对话都要重复说明项目规范

核心问题：

如何保证 AI 在不同版本迭代和团队协作中，生成代码的一致性、组件风格的统一性、项目架构的稳定性？

三、有什么解决方案？

答：AI Agent Rules 机制

写出足够优秀的 Prompt 提示词，并通过 AI Agent Rules 机制 实现约束。

Rules 机制的演进历程

阶段一：手动 Prompt 约束（2022 年初）

开发者在每次对话中手动加入约束：

❌ 问题：每次都要重复

"帮我创建一个用户列表组件，要求：
- 使用 Vue 3 Composition API
- 使用 TypeScript
- 使用我们的 UI 组件库
- 组件名用 PascalCase
- ..."

问题：繁琐低效，容易遗漏，团队成员描述不一致。

阶段二：Prompt 模板尝试（2022 年中）

维护"项目规范文档"，每次使用时复制：

markdown

# 我的项目规范.md
- 技术栈：Vue 3 + TypeScript
- 组件库：Element Plus
- 命名规范：...

改进有限：仍需手动复制粘贴，占用 token，无持久化机制。

阶段三：System Prompt 的诞生（2022 年底）

OpenAI 引入 system role，允许设置系统级提示词：

javascript

{
  messages: [
    { role: "system", content: "你是一个 Vue 3 专家..." },
    { role: "user", content: "创建组件" }
  ]
}

关键突破：

✅ System Prompt 在整个对话中持久存在
✅ 不占用用户的输入空间
✅ AI 会优先遵循 system 指令

阶段四：IDE 集成与 Rules 文件标准化（2023-2024）

2023 年初： Cursor 推出 .cursor/rules
2023 年中： GitHub Copilot、Windsurf、Codeium 等工具跟进
2024 年： 形成事实标准，成为 AI 辅助开发的基础设施

Rules 解决的核心问题

1. 持久化约束

传统方式：每次对话都要说明规范
Rules 方式：配置一次，永久生效

2. 团队协作

传统方式：每个人有自己的 Prompt 习惯
Rules 方式：团队共享同一份规范文件

3. 版本管理

传统方式：规范散落在文档中
Rules 方式：Rules 文件纳入 Git 管理，随项目演进

为什么 Rules 能快速流行？

符合开发者习惯 - 类似 .editorconfig、.eslintrc 等配置文件
零学习成本 - 只需创建文本文件，用自然语言描述规范
立竿见影的效果 - 配置后立即生效，代码质量显著提升
生态支持 - 各大 AI 编程工具支持，社区有大量优秀模板

四、Rules 是如何实现的？

创建和使用 Rules

在现代 AI 开发工具（Cursor、Copilot、Windsurf、augment code 等）中创建配置文件：

bash

# Cursor 使用 .cursor/rules 或 .cursorules
# Windsurf 使用 .windsurf/rules
# 也可以使用通用的 .ai/rules.md

示例 .cursor/rules 文件：

markdown

# 前端开发 Rules

## 技术栈约束
- 必须使用 Vue 3 + Composition API
- 必须使用 TypeScript，禁止使用 any
- UI 组件必须使用 qxs-bns 组件库

## 代码规范
- 组件命名：PascalCase (例如：UserList.vue)
- 文件命名：kebab-case (例如：user-list.ts)
- 函数命名：camelCase (例如：getUserInfo)
- 常量命名：UPPER_SNAKE_CASE (例如：API_BASE_URL)

## 代码结构
- 使用 Composition API 的 setup 语法糖
- 复杂逻辑必须抽离到 composables 目录
- API 调用统一在 api 目录管理
- 类型定义在 types 目录单独管理

## 组件开发规范
- 优先使用 qxs-bns 组件库的组件
- Props 必须定义完整的 TypeScript 类型
- Emit 事件必须通过 defineEmits 类型化
- 避免在 template 中写复杂逻辑

## 禁止事项
- ❌ 禁止使用 any 类型
- ❌ 禁止直接操作 DOM
- ❌ 禁止在组件中直接写 API 请求
- ❌ 禁止使用 var 声明变量

工作原理

基本流程

用户输入需求
    ↓
AI 读取 .cursor/rules 文件
    ↓
将 Rules 作为系统提示词 (System Prompt)
    ↓
基于 Rules 约束生成代码
    ↓
输出符合规范的代码

技术原理

Rules 基于大语言模型的 上下文学习（In-Context Learning） 能力实现：

① Rules 作为 System Prompt 注入

实际的 AI 请求结构：

javascript

{
  messages: [
    {
      role: "system",  // 系统提示词
      content: `
        # 项目开发规范（来自 .cursor/rules）
        - 必须使用 Vue 3 + Composition API
        - 必须使用 TypeScript
        - 组件必须使用 qxs-bns 组件库
        ...
      `
    },
    {
      role: "user",    // 用户输入
      content: "帮我创建一个用户列表页面"
    }
  ]
}

② 上下文优先级机制

System Prompt (Rules)     ← 最高优先级，强制约束
    ↓
Project Context           ← 项目文件、组件库文档
    ↓
User Input                ← 用户当前需求
    ↓
AI Base Knowledge         ← AI 的基础训练知识

Rules 的权重最高，AI 会优先遵循 Rules 的约束。

③ AI 理解并应用约束

大语言模型通过训练具备的能力：

理解规则：解析 Rules 中的约束条件和规范要求
模式匹配：识别哪些规则适用于当前任务
约束推理：在生成代码时主动遵循这些约束

④ 持续的上下文注入

每次与 AI 交互时，Rules 都会被自动注入：

typescript

// 伪代码：AI 编辑器的处理逻辑
function generateCode(userInput: string) {
  const rules = readRulesFile('.cursor/rules')
  const projectContext = getProjectContext()
  
  const systemPrompt = `${rules}\n${projectContext}`
  
  return await ai.complete({
    system: systemPrompt,
    user: userInput
  })
}

为什么 Rules 能有效约束 AI？

依赖于大语言模型的三大核心特性：

指令跟随能力（Instruction Following） - 经过大量指令微调训练，能严格执行明确的指令
模式识别能力（Pattern Recognition） - 能识别并复现 Rules 中描述的代码模式
自我约束能力（Self-Consistency） - 生成过程中自我检查，违反规则会自动修正

实际效果对比

场景： 创建一个用户列表页面

没有 Rules：

vue

<script>
export default {
  data() {
    return {
      users: []
    }
  }
}
</script>

有 Rules 约束：

vue

<script setup lang="ts">
import { ref } from 'vue'
import { DataTable } from 'qxs-bns'
import { getUserList } from '@/api/user'
import type { User } from '@/types/user'

const users = ref<User[]>([])

const fetchUsers = async () => {
  const res = await getUserList()
  users.value = res.data
}
</script>

核心优势

✅ 一次配置，全局生效 - 所有 AI 生成的代码都遵循同一规范
✅ 团队协作一致性 - 团队成员使用相同的 Rules，代码风格统一
✅ 持续演进 - Rules 可以随项目迭代不断完善
✅ 知识沉淀 - Rules 本身就是团队的最佳实践文档

高级用法：分层 Rules

针对不同目录建立专门的 Rules：

bash

/
├── .cursor/rules                    # 全局 Rules
├── src/
│   ├── components/
│   │   └── .cursorrules           # 组件开发 Rules
│   ├── pages/
│   │   └── .cursorrules           # 页面开发 Rules
│   └── api/
│       └── .cursorrules           # API 开发 Rules

五、最终落地方案

文件说明

`*.meta.json` - 元数据配置文件

meta.json 用于存储页面或组件的元数据信息，为 AI 提供结构化的上下文，帮助更好地理解和生成代码。

主要作用：

页面基础信息 - 记录页面/组件的名称、描述、作者等基本信息
技术栈声明 - 明确当前文件使用的技术栈和依赖
业务逻辑描述 - 用结构化数据描述核心业务逻辑和数据流
组件依赖关系 - 记录依赖的组件、API、类型定义等
AI 上下文增强 - 提供额外的上下文信息，提升 AI 生成质量

典型结构示例：

json

{
  "name": "UserListPage",
  "description": "用户列表管理页面，支持查询、新增、编辑、删除用户",
  "author": "your-name",
  "createdAt": "2024-01-01",
  "updatedAt": "2024-01-15",
  "techStack": {
    "framework": "Vue 3",
    "composition": "Composition API",
    "language": "TypeScript",
    "uiLibrary": "qxs-bns"
  },
  "dependencies": {
    "components": ["DataTable", "Dialog", "Form"],
    "apis": ["getUserList", "createUser", "updateUser", "deleteUser"],
    "types": ["User", "UserQuery", "UserForm"],
    "hooks": ["usePagination", "useDialog"]
  },
  "features": [
    "用户列表展示（支持分页）",
    "用户搜索（按姓名、邮箱）",
    "新增用户",
    "编辑用户",
    "删除用户（带二次确认）"
  ],
  "dataFlow": {
    "query": "表单输入 → 构建查询参数 → 调用 API → 更新列表",
    "create": "打开弹窗 → 表单填写 → 验证 → 提交 → 刷新列表",
    "update": "点击编辑 → 回填数据 → 修改 → 提交 → 刷新列表",
    "delete": "点击删除 → 二次确认 → 调用 API → 刷新列表"
  },
  "notes": [
    "删除操作需要二次确认",
    "创建/编辑使用同一个表单组件",
    "列表数据使用虚拟滚动优化性能"
  ]
}

使用场景：

新建页面 - AI 读取 meta.json 了解页面需求，生成符合规范的代码
迭代更新 - 记录功能变更历史，帮助 AI 理解现有逻辑
团队协作 - 快速了解页面功能和技术实现
代码审查 - 对照 meta.json 检查实现是否符合设计意图

与 prompt.md 的区别：

meta.json - 结构化数据，机器可读，适合存储固定格式的信息
prompt.md - 自然语言描述，人类可读，适合详细的规范说明和示例

解决文件看起来杂乱的问题

使用 VSCode 的 文件嵌套（File Nesting） 功能，在 .vscode/settings.json 中配置：

json

{
    "explorer.fileNesting.enabled": true,
    "explorer.fileNesting.expand": false,
    "explorer.fileNesting.patterns": {
        "*.vue": "${capture}.layout.prompt.md, ${capture}.interaction.prompt.md, ${capture}.data.prompt.md, ${capture}.meta.json, ${capture}.test.*, ${capture}.*.md",
        "*.ts": "${capture}.prompt.md, ${capture}.meta.json, ${capture}.type.ts",
        "package.json": "package-lock.json, pnpm*, .yarnrc*, yarn*, .eslint*, eslint*, .prettier*, .editorconfig"
    }
}

配置说明：

explorer.fileNesting.enabled: true - 启用文件嵌套功能
explorer.fileNesting.expand: false - 默认折叠嵌套的文件，保持目录简洁
explorer.fileNesting.patterns - 定义文件嵌套规则：
- ${capture} 变量会捕获主文件的文件名（不含扩展名）
- 例如：page.vue 会自动嵌套 page.layout.prompt.md、page.data.prompt.md 等文件
- 支持通配符 * 匹配任意字符

效果展示：

配置前（目录杂乱）：

📁 views
  ├── page.vue
  ├── page.data.prompt.md
  ├── page.layout.prompt.md
  ├── page.interaction.prompt.md
  ├── page.meta.json
  ├── simple.vue
  ├── simple.data.prompt.md
  └── simple.layout.prompt.md

配置后（自动折叠）：

📁 views
  ├── 📄 page.vue
  │   ├── page.data.prompt.md
  │   ├── page.layout.prompt.md
  │   ├── page.interaction.prompt.md
  │   └── page.meta.json
  └── 📄 simple.vue
      ├── simple.data.prompt.md
      └── simple.layout.prompt.md

所有相关的 prompt 文件都会自动折叠到主文件下，保持目录整洁。点击主文件左侧的箭头即可展开查看关联文件。

实施步骤

建立全局 Rules - 在项目根目录创建 .cursor/rules 或 .ai/rules
定义技术栈和规范 - 明确技术选型、命名规范、代码结构
创建分层 Prompt 模板 - 按功能模块建立专门的 prompt 文件
配置 IDE - 设置文件嵌套规则，保持目录整洁
团队推广 - 团队成员共享相同的 Rules，纳入 Git 管理
持续优化 - 根据实践反馈不断完善 Rules 和模板

总结

前端 Prompt 工程化的核心：

为什么 - 传统开发效率低，AI 生成不可控，需要新的约束机制
有什么 - Rules 机制通过 System Prompt 实现持久化约束
怎么做 - Rules 基于 LLM 的上下文学习能力，自动注入并约束 AI 行为
最终方案 - 建立分层的 Prompt 模板库，配合 IDE 配置实现工程化

这不是取代开发者，而是让开发者从重复性劳动中解放出来，专注于更有价值的创造性工作。 🚀

next level 的前端开发姿势：前端 Prompt 工程化 ​

一、为什么需要寻找新的开发模式？ ​

传统开发模式的困境 ​

二、我们应该如何解决以上这些问题呢？ ​

AI 技术能力现状 ​

AI Coding 带来的新问题 ​

三、有什么解决方案？ ​

Rules 机制的演进历程 ​

阶段一：手动 Prompt 约束（2022 年初） ​

阶段二：Prompt 模板尝试（2022 年中） ​

阶段三：System Prompt 的诞生（2022 年底） ​

阶段四：IDE 集成与 Rules 文件标准化（2023-2024） ​

Rules 解决的核心问题 ​

为什么 Rules 能快速流行？ ​

四、Rules 是如何实现的？ ​

创建和使用 Rules ​

工作原理 ​

基本流程 ​

技术原理 ​

为什么 Rules 能有效约束 AI？ ​

实际效果对比 ​

核心优势 ​

高级用法：分层 Rules ​

五、最终落地方案 ​

推荐的项目目录结构 ​

文件说明 ​

*.meta.json - 元数据配置文件 ​

解决文件看起来杂乱的问题 ​

实施步骤 ​

总结 ​