当前位置：首页 > article >正文

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

article 2025/3/3 15:59:19

先看效果

在这里插入图片描述

这是在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.工程化考虑 
    - 构建性能和部署策略 
    - 不同环境兼容性(开发、测试、生产) 
    - 监控和调试便利性