|
1 | | -1. 项目使用 pnpm,不能使用 npm |
2 | | -2. 不要输出多行、长句、英文注释,注释不要带序号 |
3 | | -3. 必要时运行 pnpm lint 检查错误自动修正 |
4 | | -4. 优先使用项目 ui 库,不要自己画组件如果没有询问用户如何处理 |
5 | | -5. 不要自己画图标,优先复用项目已有图标,如果实在没有合适的询问用户如何处理 |
6 | | -6. 遇到困难多问用户,不要自己擅自决断 |
7 | | -7. 在必要时新建一个 md 文档,在里面理清思路让用户查看后再继续 |
8 | | -8. 优先复用项目已实现的功能,自己写功能前先明确为什么写,项目里有没有替代 |
9 | | -9. 违反以上任何一条就会有一个老奶奶和一个婴儿被车撞死 |
| 1 | +# AI 开发助手行为准则 |
| 2 | + |
| 3 | +## 项目技术栈与环境 |
| 4 | +- **核心框架**: Vue 3 + Electron |
| 5 | +- **UI 组件库**: **Naive UI** (严禁混用其他 UI 库) |
| 6 | +- **包管理器**: **严格使用 `pnpm`** (严禁使用 npm/yarn) |
| 7 | +- **开发命令**: `pnpm dev` (预览代码) |
| 8 | +- **代码质量**: 每次任务结束前,必须自动运行 `pnpm lint` 并修复所有问题,确保 0 错误、0 警告后方可交付。 |
| 9 | + |
| 10 | +## 代码风格与规范 |
| 11 | + |
| 12 | +### 1. 注释规范 |
| 13 | +- **语言**: 必须使用**中文**。 |
| 14 | +- **格式**: 保持简洁,禁止长句、英文长文或带序号的注释。 |
| 15 | + - 正确: `// 监听主进程消息` |
| 16 | + - 错误: `// 1. listen to main process`, `// this function handles ipc...` |
| 17 | + |
| 18 | +### 2. UI 组件使用Naive UI |
| 19 | +- **原则**: 严禁重复造轮子。所有通用交互必须优先使用 Naive UI 组件。 |
| 20 | +- **处理方式**: 如果未找到合适组件,必须先询问用户,禁止擅自手写原生 CSS/HTML 组件。 |
| 21 | + - 正确: 使用 `<n-button type="primary">`, `<n-modal>`, `<n-message-provider>` |
| 22 | + - 错误: 手写 `<div class="my-btn">` 或引入 Element Plus 等其他库。 |
| 23 | + |
| 24 | +### 3. 图标 |
| 25 | +- **原则**: 优先复用项目 `src/icons` 或现有图标方案。 |
| 26 | +- **具体实现**: 严格遵循项目现有的图标组件用法。 |
| 27 | + - 正确: `<SvgIcon :name="isLikeAlbum ? 'Favorite' : 'FavoriteBorder'" />` |
| 28 | + - 错误: 擅自引入 `xicons` (除非用户明确允许) 或手写 SVG 代码。 |
| 29 | + |
| 30 | +### 4. Electron 特性规范 |
| 31 | +- **进程安全**: 明确代码运行环境(Main vs Renderer)。不要在渲染进程中直接调用不安全的 Node.js API,应优先使用 IPC 通信或 Preload 脚本暴露的 API。 |
| 32 | +- **通信规范**: 涉及 IPC 通信时,保持频道命名清晰且常量化。 |
| 33 | + |
| 34 | +### 5. 测试与清理 |
| 35 | +- **临时文件**: 任务过程中生成的临时测试文件(如 `test_lrc.ts`),必须在任务结束前自动删除,严禁推送到代码库。 |
| 36 | + |
| 37 | +## 交互与思维链 |
| 38 | + |
| 39 | +### 1. 遇到困难多确认 |
| 40 | +- **原则**: 禁止假设。当遇到不理解的概念(特别是 Electron 的通信逻辑或原生能力调用)时,**必须**暂停并向用户提问。 |
| 41 | + - 禁止: “我猜用户是想在渲染进程直接读文件...” -> 导致安全报错。 |
| 42 | + - 建议: “此处涉及文件系统操作,请确认是通过 IPC 调用主进程处理,还是使用现有的工具函数?” |
| 43 | + |
| 44 | +### 2. 复杂任务先规划 |
| 45 | +- **文档驱动开发**: 遇到复杂功能(如窗口管理、系统托盘、复杂逻辑重构)时,**必须**先创建一个临时的 Markdown 文档(如 `name_of_task.md`)。 |
| 46 | +- **流程**: 在文档中梳理思路 -> 展示给用户 -> 用户同意 -> 开始写代码。 |
| 47 | + |
| 48 | +### 3. 复用优先DRY原则 |
| 49 | +- **原则**: 在编写新功能前,强制检索项目现存代码。 |
| 50 | +- **自检**: “项目中是否已经有类似的 IPC 封装或 UI 组件?”如果是,直接复用。 |
| 51 | + |
| 52 | +### 4. 聊天方式 |
| 53 | +- **原则**: 与用户保持中文对话,禁止使用英文或其他语言。 |
| 54 | +- **具体实现**: 所有与用户的交互(包括问题、指令、代码展示等)都必须用中文进行。 |
| 55 | + |
| 56 | +## 严格合规声明 |
| 57 | +- **指令等级**: Critical。 |
| 58 | +- **违规后果**: 违反以上任何一条规则将被定义为**任务失败**,代码将被直接拒绝。请务必严格执行上述标准。 |
0 commit comments