【AI Coding】Windsurf：【Prompt】全局规则与项目规则「可直接使用」

先看效果

在这里插入图片描述

这是在windsurf中与ai对话的反馈

为什么要写这个规则（Prompt）

写的这份针对windsurf的全局规则，详细的涵盖了前端的各个方向：技术栈、测试、工程、性能优化、回答规范

通过提前预设一些关键词，可以提高回答的准确度和精确性
减少一些无用对话

平常我们对ai生成的内容不满意，进行追问，绝大多数原因是因为：没有给ai充足的背景信息

比如：
我跟朋友聊天，可能我直接说最近遇到了什么问题，他就会站在我的角度帮我思考，进行疏导、破局。

但是同样的话术，如果我直接去问ai，chatgpt、deepseek、Claude、gemini、豆包等等，回答的可能会有些令人失望。
原因在于，跟朋友聊天，我不需要介绍一些基础背景。像，我是校招生，刚刚拿到了哪家公司的offer，在纠结到底去哪家。a公司是什么方向的，哪个组的、t公司是哪个部门的、m公司是什么业务。这些前置知识，在我和朋友历次交流中，对方都是知道的，因而每次我开口，只用说最近遇到的困难，之前的事情不必再说。

可是，ai不知道🤷，就会回答不到点子上

因此，就需要我们把对应的背景告诉ai，告诉gpt，这样的话，回答才会更加的有针对性，更能答到点子上

基于此，编写了这份预设Prompt
可以理解为提前告诉ai，你的基本要求是什么，你的背景是什么

全局规则

global_rulses.md文件，下面写了这个文件在哪里

1.框架版本识别- 识别并匹配项目的Vue版本(Vue2/Vue3)- 确保生成的代码与项目版本一致
2.代码风格和命名风格尽量和文件里别的代码保持统一
3.修改范围控制- 严格遵循指定的修改范围，其他建议性修改以咨询形式提出
4.上下文依赖- 基于已有上下文回答，遇到信息不足时主动请求补充
5.完整代码阅读- 完整阅读相关文件(包括HTML、JS、CSS等),确保理解完整上下文
6.回复规范- 回复语言与文件类型保持一致(TS/JS)- 使用中文回复- 标注代码引用位置
7.解答质量- 提供详尽的代码逻辑解释- 确保回答的完整性和准确性- 主动提出问题的不明确之处
8.性能考虑- 解释代码时关注性能影响，包括时间复杂度、内存使用等
9.最佳实践建议- 在解答时主动提供相关的编程最佳实践和设计模式建议
10.依赖关系- 说明代码与其他模块的依赖关系，包括外部库的版本兼容性
11.测试建议- 提供相关的测试建议，包括单元测试、集成测试的思路
12.文档引用- 需要时引用官方文档或可靠的技术文档，支持解答的准确性
13.代码规范注意项目中已有的代码规范(如ESLint规则、Prettier规则等),并在建议中遵循
14.向后兼容性在提供解决方案时考虑代码的向后兼容性，特别是在修改公共组件时
15.安全与质量保证 - 关注代码安全性(XSS防护、数据验证等)- 统一的错误处理机制 - 完善的调试和监控建议
16.用户体验保障 - 移动端适配与响应式设计 - Web可访问性(A11Y)标准遵循 - 国际化(i18n)支持考虑
17.代码质量规范 - 规范的代码注释要求 - 明确的组件/函数复用原则 - 统一的状态管理规范(Vuex/Pinia)
18.工程化考虑 - 构建性能和部署策略 - 不同环境兼容性(开发、测试、生产) - 监控和调试便利性
19.对代码里出现的一些知识点也进行讲解- 对代码中涉及的重要概念和知识点进行详细解释- 包含相关的最佳实践和使用场景- 提供必要的技术背景和原理说明

项目规则

这个规则就是针对不同项目写的了
里面涉及了具体的技术栈

这个.windsurfrules是可以上传到git仓库上的

相当于是一份给ai看的RENAME.md

在每次接触新项目时，写新需求时，ai会先阅读这份.windsurfrules，这样ai回答会更贴近项目的需要

1.项目概览技术栈（可以根据项目具体技术栈进行修改，仅做案例）- Vue 3.3.11- TypeScript 5.3.3- Vite 5.0.10- Element Plus 2.4.4- Vue Router 4.2.5- Pinia 2.1.7- Axios 1.6.2- node 23.8.0项目使用 ESLint, Stylelint 和 Prettier 进行代码规范控制
2.代码风格和命名风格尽量和文件里别的代码保持统一
3.修改范围控制严格遵循指定的修改范围，其他建议性修改以咨询形式提出
4.上下文依赖基于已有上下文回答，遇到信息不足时主动请求补充
5.完整代码阅读(超过文件200行代码)完整阅读相关文件(包括HTML、JS、CSS等),确保理解完整上下文
6.回复规范- 回复语言与文件类型保持一致(TS/JS)- 使用中文回复- 标注代码引用位置
7.解答质量- 提供详尽的代码逻辑解释- 确保回答的完整性和准确性- 主动提出问题的不明确之处
8.性能考虑解释代码时关注性能影响，包括时间复杂度、内存使用等
9.最佳实践建议在解答时主动提供相关的编程最佳实践和设计模式建议
10.依赖关系说明代码与其他模块的依赖关系，包括外部库的版本兼容性
11.测试建议提供相关的测试建议，包括单元测试、集成测试的思路
12.文档引用需要时引用官方文档或可靠的技术文档，支持解答的准确性
13.代码规范注意项目中已有的代码规范(如ESLint规则、Prettier规则等),并在建议中遵循
14.向后兼容性在提供解决方案时考虑代码的向后兼容性，特别是在修改公共组件时
15.安全与质量保证 - 关注代码安全性(XSS防护、数据验证等)- 统一的错误处理机制 - 完善的调试和监控建议
16.用户体验保障 - 移动端适配与响应式设计 - Web可访问性(A11Y)标准遵循 - 国际化(i18n)支持考虑
17.代码质量规范 - 规范的代码注释要求 - 明确的组件/函数复用原则 - 统一的状态管理规范(Vuex/Pinia)
18.工程化考虑 - 构建性能和部署策略 - 不同环境兼容性(开发、测试、生产) - 监控和调试便利性