先看效果
这是在windsurf中与ai对话的反馈
为什么要写这个规则（Prompt）
写的这份针对windsurf的全局规则，详细的涵盖了前端的各个方向：技术栈、测试、工程、性能优化、回答规范
通过提前预设一些关键词，可以提高回答的准确度和精确性
减少一些无用对话
平常我们对ai生成的内容不满意，进行追问，绝大多数原因是因为：没有给ai充足的背景信息
比如：
我跟朋友聊天，可能我直接说最近遇到了什么问题，他就会站在我的角度帮我思考，进行疏导、破局。
但是同样的话术，如果我直接去问ai，chatgpt、deepseek、Claude、gemini、豆包等等，回答的可能会有些令人失望。
原因在于，跟朋友聊天，我不需要介绍一些基础背景。像，我是校招生，刚刚拿到了哪家公司的offer，在纠结到底去哪家。a公司是什么方向的，哪个组的、t公司是哪个部门的、m公司是什么业务。这些前置知识，在我和朋友历次交流中，对方都是知道的，因而每次我开口，只用说最近遇到的困难，之前的事情不必再说。
可是，ai不知道🤷，就会回答不到点子上
因此，就需要我们把对应的背景告诉ai，告诉gpt，这样的话，回答才会更加的有针对性，更能答到点子上
基于此，编写了这份预设Prompt
可以理解为提前告诉ai，你的基本要求是什么，你的背景是什么
全局规则
global_rulses.md文件，下面写了这个文件在哪里
markup
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回答会更贴近项目的需要
markup
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.工程化考虑
- 构建性能和部署策略
- 不同环境兼容性(开发、测试、生产)
- 监控和调试便利性如何添加
在编辑器右下角找到Windsurf-Setting点击打开
第一个Set Global Rules 点击编辑规则，是写全局规则的
点击后，会直接进入global_rulses.md文件，粘贴我写的规则之后，进行保存，这个文件就直接保存在本地了
存在位置
第二个按钮是work space，工作区的规则，即具体的项目规则
这个就是可以提交到git仓库上的了
一份写给ai看的RENAME.md