让AI写出符合团队规范的代码我靠一段System Prompt搞定一个PR的修改意见从15条降到2条代码风格从四个人的写法变成同一个人写的一、一个PR改了三次全是因为风格问题上个月组里来了个新项目四个前端各自负责一个模块都用AI辅助开发。结果Review的时候发现四个人的代码风格完全不统一A的代码用interfaceB用type。C的组件用script setupD的用export default。有人用const声明函数有人用function。引入Element Plus的写法能搞出三种版本。每次Review都要重复提同样的意见“这里改成interface”“这里用setup语法”“这里不要用default export”。一个PR来回改三次才能合并。后来想了个办法写一段System Prompt把团队的代码规范全塞进去所有AI生成代码之前先喂这段。一个月之后再看同一个项目的代码看起来像同一个人写的。PR的平均修改意见从15条降到了2条剩下的基本都是逻辑问题不再有风格问题。二、System Prompt长什么样这段Prompt我维护在团队仓库的.cursor/rules.md里每次让AI写代码之前先发这一段。你是一个Vue 3 TypeScript专家请严格遵循以下规范生成代码 ## 技术栈 - Vue 3Composition API script setup - TypeScript严格模式 - Element Plus按需导入 - Pinia状态管理 - Vite构建工具 ## 代码规范 - 组件名PascalCaseUserProfile.vue - 文件名kebab-caseuser-profile.vue - 变量/函数camelCase - 类型/接口PascalCase - 常量UPPER_SNAKE_CASE - 使用interface定义对象类型type用于联合类型和工具类型 - 函数优先使用箭头函数需要提升时用function ## Vue规范 - 必须使用script setup语法 - Props用definePropsT()带完整类型 - Emits用defineEmitsT()带完整类型 - 所有props标注required和默认值 - 组件样式使用scoped - v-for必须绑定key优先使用唯一id ## API调用规范 - 统一使用项目封装的request实例 - 所有请求包含loading状态 - 错误统一用ElMessage.error展示 - 接口地址以/开头的绝对路径 ## 约束条件 - 不要使用any类型 - 不要使用var - 不要使用console.log用项目封装的logger - 不要修改项目已有的全局配置 - 生成的组件必须能直接运行不需要额外配置这段规则根据项目情况持续迭代每个新成员加入时也直接发给他。AI知道该用什么、不该用什么生成出来的代码基本不用改风格。三、使用前的对话之前让AI写一个用户列表组件生成一个用户列表组件包含表格、搜索、分页AI给了这段template div el-input v-modelsearch placeholder搜索 inputhandleSearch / el-table :datauserList stylewidth: 100% el-table-column propname label姓名 / el-table-column propemail label邮箱 / el-table-column label操作 template slot-scopescope el-button clickeditUser(scope.row)编辑/el-button /template /el-table-column /el-table /div /template script export default { data() { return { search: , userList: [] } }, methods: { handleSearch() { // 搜索逻辑 }, editUser(user) { // 编辑逻辑 } } } /script问题一堆Options API项目用的是Composition APIslot-scope项目用的是#default写法没有TypeScript类型没有loading状态userList没有初始类型Review时提了8条修改意见改了两轮才过。四、使用后的对话先发送System Prompt再说需求[System Prompt 贴在这里] 生成一个用户列表组件包含表格、搜索、分页AI给了这段template div classuser-list div classsearch-bar el-input v-modelsearchKeyword placeholder搜索用户 clearable inputhandleSearch / el-button typeprimary clickfetchData查询/el-button /div el-table v-loadingloading :datatableData stripe sort-changehandleSortChange el-table-column propname label姓名 sortablecustom / el-table-column propemail label邮箱 / el-table-column proprole label角色 / el-table-column propstatus label状态 template #default{ row } el-tag :typerow.status active ? success : info {{ row.status }} /el-tag /template /el-table-column el-table-column label操作 width160 template #default{ row } el-button typetext clickhandleEdit(row)编辑/el-button el-button typetext clickhandleDelete(row)删除/el-button /template /el-table-column /el-table el-pagination v-model:current-pagecurrentPage v-model:page-sizepageSize :totaltotal :page-sizes[10, 20, 50] layouttotal, sizes, prev, pager, next size-changefetchData current-changefetchData / el-dialog v-modeldialogVisible title编辑用户 el-form :modeleditForm label-width80px el-form-item label姓名 el-input v-modeleditForm.name / /el-form-item el-form-item label邮箱 el-input v-modeleditForm.email / /el-form-item /el-form template #footer el-button clickdialogVisible false取消/el-button el-button typeprimary :loadingsubmitLoading clickhandleSubmit 保存 /el-button /template /el-dialog /div /template script setup langts import { ref, onMounted } from vue import { ElMessage, ElMessageBox } from element-plus import { getUserList, deleteUser, updateUser } from /api/user import type { User, UserQueryParams } from /types/user const loading ref(false) const submitLoading ref(false) const tableData refUser[]([]) const total ref(0) const currentPage ref(1) const pageSize ref(10) const searchKeyword ref() const sortField ref() const sortOrder refascending | descending(ascending) const dialogVisible ref(false) const editForm refPartialUser({}) const fetchData async () { loading.value true try { const params: UserQueryParams { page: currentPage.value, size: pageSize.value, keyword: searchKeyword.value, sortField: sortField.value, sortOrder: sortOrder.value } const res await getUserList(params) tableData.value res.data total.value res.total } catch (error) { ElMessage.error(加载失败请稍后重试) } finally { loading.value false } } const handleSearch () { currentPage.value 1 fetchData() } const handleSortChange ({ prop, order }: { prop: string; order: string | null }) { sortField.value prop sortOrder.value order ascending ? ascending : descending fetchData() } const handleEdit (row: User) { editForm.value { ...row } dialogVisible.value true } const handleDelete (row: User) { ElMessageBox.confirm(确认删除该用户吗, 提示, { confirmButtonText: 确认, cancelButtonText: 取消, type: warning }).then(async () { await deleteUser(row.id) ElMessage.success(删除成功) fetchData() }).catch(() {}) } const handleSubmit async () { submitLoading.value true try { await updateUser(editForm.value.id!, editForm.value) ElMessage.success(保存成功) dialogVisible.value false fetchData() } catch (error) { ElMessage.error(保存失败) } finally { submitLoading.value false } } onMounted(fetchData) /script style scoped .user-list { padding: 20px; } .search-bar { display: flex; gap: 12px; margin-bottom: 16px; } /styleReview时只提了2条修改意见都是业务逻辑问题风格方面的修改意见为0。合进去的时候一次过。五、System Prompt如何迭代的这个规则文件放在项目根目录的.cursor/rules.md里跟着代码一起维护。每次遇到风格问题或者团队规范调整就更新这个文件。第一次迭代发现命名不统一有人在用camelCase有人在用snake_case。更新规则文件加了变量/函数用camelCase这一条。第二次迭代发现TypeScript类型经常缺失AI经常忘记加类型或者直接用any。更新规则文件加了所有参数和返回值必须标注类型“禁止使用any”。第三次迭代发现接口地址写法不统一有人用相对路径/api/users有人在前面加了baseURL重复拼了两次。更新规则文件明确了接口地址统一用/api开头baseURL在request里已配置。第四次迭代发现Element Plus版本写法问题项目用的是按需导入AI生成时有时会写import { ElButton } from element-plus有时会写ElButton直接使用。更新规则文件加了Element Plus组件无需单独导入直接在模板中使用。每次迭代都把问题解决在源头。当AI生成的代码本身就符合规范时Review者的精力可以放在逻辑和设计上而不是格式和风格上。六、团队如何统一维护目前这个规则文件在团队里这样用每位开发者在IDE里配置.cursor项目里创建rules.mdCursor会自动识别并作为System Prompt的一部分。新人入职直接复制新同事加入时先把规则文件发给他让他的AI助手也按这套规范生成代码。迭代有记录规则文件的每次改动都走PR流程有讨论、有决策、有记录。不会出现某人私自加了一条规则但别人不知道的情况。定期同步每周团队周会上花5分钟过一下规则文件有没有需要更新的地方保持规范和实际需求同步。大家写代码都用同一套规范Review的效率自然就上去了。七、几个关键点第一System Prompt要放在项目仓库里跟着代码走不要放在个人笔记里不要放在微信群里。放在代码仓库里所有人拿到的版本是一致的。更新了规则全团队共享。第二规则要有可检查性代码风格要统一是废话。组件用PascalCase命名是可检查的。每一条规则都应该是看到代码能判断对不对的标准。第三规则要有优先级哪些是必须遵守的编译级别的哪些是建议遵守的风格层面的。System Prompt里只放必须遵守的建议级别的别往里塞不然Prompt太长AI反而不敏感了。第四定期清理过时规则技术栈升级了某些规则可能不再适用。定期Review一下规则文件把过时的删掉保持精简。第五规则文件本身也是代码像管理代码一样管理规则文件。有注释、有分类、有版本记录。别的团队参考的时候也能理解每一条规则为什么存在。