docs(commands): 新增Qoder指令及同步规则文档
- 新增`.qoder/commands-sync.md`,持久化存储项目指令,解决账号切换导致指令丢失 - 添加多条指令文档,涵盖代码审查、PR创建、项目测试、安全检查、记忆同步、后台启动等 - 编写指令的详细说明及操作指南,便于用户触发对应流程 - 新增`.qoder/memory-sync.md`文件,持久化存储项目记忆并定义同步规则 - 增加规则文件`.qoder/rules/`,包含代码修改规范、通用规则、需求文档规范等,规范项目管理与开发流程 - 完善项目规则索引,明确各规则文件的触发条件及适用场景
This commit is contained in:
parent
1912be6962
commit
21d12e1c95
|
|
@ -0,0 +1,25 @@
|
||||||
|
# Qoder 指令同步文件
|
||||||
|
|
||||||
|
> 持久化存储项目指令,解决账号切换导致指令丢失。由 AI 自动维护,请勿手动编辑。
|
||||||
|
|
||||||
|
**最后更新时间:** 2026-03-05
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 指令列表
|
||||||
|
|
||||||
|
| 指令 | 说明 | 文件 |
|
||||||
|
|------|------|------|
|
||||||
|
| `/code-inspect` | 代码审查(技术评估、安全合规、质量评估) | `commands/code-inspect.md` |
|
||||||
|
| `/create-pr` | 创建PR(代码提交流程、质量门禁) | `commands/create-pr.md` |
|
||||||
|
| `/project-test` | 项目测试(单元/集成/冒烟测试) | `commands/project-test.md` |
|
||||||
|
| `/security-check` | 安全检查(漏洞检测、威胁防御、合规验证) | `commands/security-check.md` |
|
||||||
|
| `/memory-sync` | 记忆同步(项目记忆持久化同步) | `commands/memory-sync.md` |
|
||||||
|
| `/start-store` | 启动商家后台(localhost:8120,Vue 2 + Ant Design Vue) | `commands/start-store.md` |
|
||||||
|
| `/start-admin` | 启动超管后台(localhost:8110,Vue 2 + Ant Design Vue) | `commands/start-admin.md` |
|
||||||
|
|
||||||
|
## 同步规则
|
||||||
|
|
||||||
|
- 指令文件变更时自动同步到本文件
|
||||||
|
- 启动时检查:文件中存在但系统缺失的指令需反向同步
|
||||||
|
- 指令文件位于 `.qoder/commands/` 目录
|
||||||
|
|
@ -0,0 +1,40 @@
|
||||||
|
---
|
||||||
|
description:
|
||||||
|
---
|
||||||
|
# 代码审查 (code-inspect)
|
||||||
|
|
||||||
|
##概
|
||||||
|
用于评估源代码的系统化框架,以验证技术卓越性、稳健性和安全合规性。
|
||||||
|
|
||||||
|
## 评估领域
|
||||||
|
|
||||||
|
### 技术实现
|
||||||
|
-准确实现
|
||||||
|
-算效率
|
||||||
|
-管理
|
||||||
|
-性能考虑
|
||||||
|
-系统集成
|
||||||
|
|
||||||
|
### 开发标准
|
||||||
|
- 设计模式
|
||||||
|
- 代码模块化
|
||||||
|
- 文档完整性
|
||||||
|
-测试覆盖
|
||||||
|
- 日志实现
|
||||||
|
-错误处理
|
||||||
|
|
||||||
|
###管理管理
|
||||||
|
-安全最佳实践
|
||||||
|
- 数据验证
|
||||||
|
-身验证
|
||||||
|
-授权规则
|
||||||
|
- API安全
|
||||||
|
|
||||||
|
###维护方面
|
||||||
|
- 代码可维护性
|
||||||
|
- 依赖管理
|
||||||
|
-版本兼容性
|
||||||
|
-技术债务
|
||||||
|
|
||||||
|
## 使用方法
|
||||||
|
在对话中输入 `/code-inspect`触发代码审查流程。
|
||||||
|
|
@ -0,0 +1,39 @@
|
||||||
|
---
|
||||||
|
description:
|
||||||
|
---
|
||||||
|
# 创建PR (create-pr)
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
用于提交代码更改的标准化流程,包含全面的文档和验证要求。
|
||||||
|
|
||||||
|
## 主要步骤
|
||||||
|
|
||||||
|
### 1. 代码质量保证
|
||||||
|
-分析
|
||||||
|
-格验证
|
||||||
|
-移除未使用代码
|
||||||
|
- 更新注释
|
||||||
|
-测试覆盖
|
||||||
|
|
||||||
|
### 2.变更文档
|
||||||
|
- 实现细节
|
||||||
|
-技术决策
|
||||||
|
-性能影响
|
||||||
|
-迁步骤
|
||||||
|
-回程序
|
||||||
|
|
||||||
|
### 3. 测试验证
|
||||||
|
-单元测试套件
|
||||||
|
-测试
|
||||||
|
-冒测试
|
||||||
|
- UI/UX验证
|
||||||
|
-跨测试
|
||||||
|
|
||||||
|
##门禁
|
||||||
|
- 代码审查通过
|
||||||
|
-安全审查通过
|
||||||
|
-性能标准符合
|
||||||
|
- CI/CD绿色
|
||||||
|
|
||||||
|
## 使用方法
|
||||||
|
在对话中输入 `/create-pr`触发PR创建流程。
|
||||||
|
|
@ -0,0 +1,45 @@
|
||||||
|
---
|
||||||
|
description:
|
||||||
|
---
|
||||||
|
#记忆同步 (memory-sync)
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
用于同步项目记忆与 `.qoder/memory-sync.md` 文件的指令,解决账号切换导致的记忆丢失问题。
|
||||||
|
|
||||||
|
##同步流程
|
||||||
|
|
||||||
|
### 1.系统 → 文件检查
|
||||||
|
-扫描系统记忆
|
||||||
|
-对比文件内容
|
||||||
|
-识别变更
|
||||||
|
|
||||||
|
### 2. 文件 →系统检查
|
||||||
|
-读取文件
|
||||||
|
-检查缺失记忆
|
||||||
|
-准备反向同步
|
||||||
|
|
||||||
|
### 3.执行同步
|
||||||
|
-写入文件
|
||||||
|
-导入系统
|
||||||
|
-更新时间
|
||||||
|
|
||||||
|
##同步内容
|
||||||
|
|
||||||
|
### 项目配置记忆
|
||||||
|
-目录结构
|
||||||
|
-命名约定
|
||||||
|
-技术栈版本
|
||||||
|
|
||||||
|
###环境配置记忆
|
||||||
|
-启动命令
|
||||||
|
-口配置
|
||||||
|
-数据库连接
|
||||||
|
- Docker部署
|
||||||
|
|
||||||
|
### 开发工作流记忆
|
||||||
|
-构建步骤
|
||||||
|
-测试命令
|
||||||
|
-代码规范
|
||||||
|
|
||||||
|
## 使用方法
|
||||||
|
在对话中输入 `/memory-sync`执行记忆同步。
|
||||||
|
|
@ -0,0 +1,44 @@
|
||||||
|
---
|
||||||
|
description:
|
||||||
|
---
|
||||||
|
# 项目测试 (project-test)
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
执行项目测试套件并通过系统化故障排除和验证解决检测到的问题。
|
||||||
|
|
||||||
|
## 测试阶段
|
||||||
|
|
||||||
|
### 1. 环境设置
|
||||||
|
-验证开发环境
|
||||||
|
-检查依赖状态
|
||||||
|
-确认测试数据
|
||||||
|
-验证配置
|
||||||
|
|
||||||
|
### 2.测试执行
|
||||||
|
-单元测试套件
|
||||||
|
-测试
|
||||||
|
-冒测试
|
||||||
|
-代码覆盖率检查
|
||||||
|
|
||||||
|
### 3. 问题解决
|
||||||
|
-记录失败
|
||||||
|
-分析错误模式
|
||||||
|
-调试用例
|
||||||
|
-实施修复
|
||||||
|
|
||||||
|
##验证矩阵
|
||||||
|
|
||||||
|
###核测试测试
|
||||||
|
-单元测试
|
||||||
|
- API测试
|
||||||
|
-数据库测试
|
||||||
|
-缓存行为
|
||||||
|
|
||||||
|
###系统健康
|
||||||
|
-内存使用
|
||||||
|
-响应时间
|
||||||
|
-错误率
|
||||||
|
-资源利用
|
||||||
|
|
||||||
|
## 使用方法
|
||||||
|
在对话中输入 `/project-test`执行项目测试。
|
||||||
|
|
@ -0,0 +1,51 @@
|
||||||
|
---
|
||||||
|
description:
|
||||||
|
---
|
||||||
|
#安全检查 (security-check)
|
||||||
|
|
||||||
|
## 概述
|
||||||
|
系统安全态势的系统化检查,专注于漏洞检测、威胁防御和合规验证。
|
||||||
|
|
||||||
|
## 评估领域
|
||||||
|
|
||||||
|
### 1.应用安全
|
||||||
|
-漏洞扫描
|
||||||
|
-安全补丁状态
|
||||||
|
-框架安全审计
|
||||||
|
-库版本控制
|
||||||
|
|
||||||
|
### 2.认证系统
|
||||||
|
-身管理审查
|
||||||
|
-密码策略合规
|
||||||
|
-多因素认证
|
||||||
|
-会话管理审计
|
||||||
|
|
||||||
|
### 3. 数据保护
|
||||||
|
-加密实现
|
||||||
|
- 数据访问模式
|
||||||
|
-隐私合规
|
||||||
|
-备份安全
|
||||||
|
|
||||||
|
### 4. 系统架构
|
||||||
|
-络分段
|
||||||
|
-火墙配置
|
||||||
|
-载均衡器安全
|
||||||
|
- API网关保护
|
||||||
|
|
||||||
|
##验证要点
|
||||||
|
|
||||||
|
###核心要求
|
||||||
|
-安全补丁
|
||||||
|
-加密标准
|
||||||
|
-访问控制
|
||||||
|
-审计日志
|
||||||
|
-入侵检测
|
||||||
|
|
||||||
|
###高级措施
|
||||||
|
-透测试
|
||||||
|
-安全监控
|
||||||
|
-灾恢复
|
||||||
|
-事件响应
|
||||||
|
|
||||||
|
## 使用方法
|
||||||
|
在对话中输入 `/security-check`执行安全检查。
|
||||||
|
|
@ -0,0 +1,37 @@
|
||||||
|
# Qoder 项目记忆同步文件
|
||||||
|
|
||||||
|
> 持久化存储项目记忆,解决账号切换导致记忆丢失。由 AI 自动维护,请勿手动编辑。
|
||||||
|
|
||||||
|
**最后更新时间:** 2026-03-05
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 记忆列表(共 2 条)
|
||||||
|
|
||||||
|
### 1. Qoder 指令同步规则
|
||||||
|
**分类:** project_configuration | **作用域:** 📁 当前项目
|
||||||
|
|
||||||
|
指令存储: `.qoder/commands/*.md`,同步文件: `.qoder/commands-sync.md`
|
||||||
|
当前指令: code-inspect, create-pr, project-test, security-check, memory-sync, start-store, start-admin
|
||||||
|
|
||||||
|
### 2. lhxd-admin / lhxd-store 打包命令
|
||||||
|
**分类:** project_configuration | **作用域:** 📁 当前项目
|
||||||
|
|
||||||
|
**lhxd-admin** (`/Users/zhouyonggao/Desktop/wbxm/lhxd/lhxd-admin`):
|
||||||
|
- `yarn serve` → 开发(proxy → localhost:8090)
|
||||||
|
- `yarn build` → 生产(https://lhxd.ojcc168.com/index.php?s=/admin)
|
||||||
|
- `yarn build:staging` → 测试(https://test.lhxd.ojcc168.com/index.php?s=/admin)
|
||||||
|
|
||||||
|
**lhxd-store** (`/Users/zhouyonggao/Desktop/wbxm/lhxd/lhxd-store`):
|
||||||
|
- `yarn serve` → 开发(proxy → localhost:8090)
|
||||||
|
- `yarn build` → 生产(https://lhxd.ojcc168.com/index.php?s=/store)
|
||||||
|
- `yarn build:staging` → 测试(https://test.lhxd.ojcc168.com/index.php?s=/store)
|
||||||
|
|
||||||
|
baseURL 逻辑: `process.env.VUE_APP_API_BASE_URL || config.BASE_API`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 同步规则
|
||||||
|
|
||||||
|
- 记忆变更时自动同步到本文件,启动时反向同步缺失记忆
|
||||||
|
- 代码规范等已转为规则文件,见 `.qoder/rules/` 目录
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
trigger: model_decision
|
||||||
|
description: 后端API服务编码规范、技术栈,生成、修改后端api代码时参考
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -0,0 +1,25 @@
|
||||||
|
---
|
||||||
|
trigger: always_on
|
||||||
|
alwaysApply: true
|
||||||
|
---
|
||||||
|
|
||||||
|
# 代码修改规范
|
||||||
|
|
||||||
|
## 修改前必须执行的操作
|
||||||
|
|
||||||
|
在执行任何文件内容修改操作前,必须:
|
||||||
|
|
||||||
|
1. **评估修改的置信度**(高/中/低)
|
||||||
|
2. **明确说明**:
|
||||||
|
- 要修改的文件路径
|
||||||
|
- 修改的具体内容和原因
|
||||||
|
- 可能的影响范围
|
||||||
|
- 置信度评估结果
|
||||||
|
3. **等待用户明确授权**后再执行修改
|
||||||
|
4. **禁止**在未获得确认的情况下直接修改文件
|
||||||
|
|
||||||
|
## 置信度评估标准
|
||||||
|
|
||||||
|
- **高置信度**:需求明确、影响范围清晰、修改方案标准化
|
||||||
|
- **中置信度**:需求较明确但可能有多种实现方式、影响范围需确认
|
||||||
|
- **低置信度**:需求模糊、影响范围不明确、可能存在多种理解方式
|
||||||
|
|
@ -0,0 +1,21 @@
|
||||||
|
---
|
||||||
|
trigger: always_on
|
||||||
|
glob: "**/*.md"
|
||||||
|
ignore: ["doc/**"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 通用规则
|
||||||
|
|
||||||
|
## 项目记忆同步
|
||||||
|
|
||||||
|
- 记忆变更时同步更新 `.qoder/memory-sync.md`;用户要求同步时检查文件,缺失的记忆反向同步回系统
|
||||||
|
|
||||||
|
## 技术栈版本管理
|
||||||
|
|
||||||
|
- 开发阶段使用最新稳定兼容版本,引入新依赖前确认版本兼容性
|
||||||
|
|
||||||
|
## 任务拆分与聚焦
|
||||||
|
|
||||||
|
- 每次任务小而聚焦,专注单一功能点,确保质量后再进行下一步
|
||||||
|
- 复杂任务必须拆分为多个独立小任务,逐个完成
|
||||||
|
- 完成标准:代码检查通过、功能验证通过、无遗留问题
|
||||||
|
|
@ -0,0 +1,41 @@
|
||||||
|
---
|
||||||
|
trigger: model_decision
|
||||||
|
description: 项目规则索引,查看所有规则文件及其适用场景时参考
|
||||||
|
---
|
||||||
|
|
||||||
|
# 项目规则索引
|
||||||
|
|
||||||
|
## 通用规则(始终生效)
|
||||||
|
|
||||||
|
| 规则文件 | 适用场景 | 说明 |
|
||||||
|
|---------|---------|------|
|
||||||
|
| [general.md](./general.md) | 通用规则 | 记忆同步、技术栈版本管理、任务拆分规范 |
|
||||||
|
| [code-modification.md](./code-modification.md) | 代码修改规范 | 修改前评估、置信度判断、获取授权 |
|
||||||
|
|
||||||
|
## 文档规则(按需触发)
|
||||||
|
|
||||||
|
| 规则文件 | 适用场景 | 加载条件 |
|
||||||
|
|---------|---------|----------|
|
||||||
|
| [requirements.md](./requirements.md) | 需求文档规范 | 生成需求文档时 |
|
||||||
|
| [api.md](./api.md) | 后端API规范 | 生成、修改后端API代码时 |
|
||||||
|
|
||||||
|
## 项目相关信息
|
||||||
|
|
||||||
|
### 项目概述
|
||||||
|
- **项目名称**: 邮储积分商城 (post-bank-point-mall)
|
||||||
|
- **主要文档**:
|
||||||
|
- 接口设计规范文档
|
||||||
|
- 营销开放API文档
|
||||||
|
- 序列图设计文档
|
||||||
|
|
||||||
|
### 目录结构
|
||||||
|
```
|
||||||
|
post-bank-point-mall/
|
||||||
|
├── .qoder/
|
||||||
|
│ └── rules/ # 项目规则文件
|
||||||
|
├── docs/ # 项目文档
|
||||||
|
│ ├── 接口设计规范文档
|
||||||
|
│ ├── 营销API文档
|
||||||
|
│ └── 序列图文件
|
||||||
|
└── README.md # 项目说明
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,29 @@
|
||||||
|
---
|
||||||
|
trigger: model_decision
|
||||||
|
description: 生成需求文档的时候需要
|
||||||
|
---
|
||||||
|
|
||||||
|
# 需求文档编写规范
|
||||||
|
|
||||||
|
## 文档结构要求
|
||||||
|
|
||||||
|
必须且仅包含以下4个章节,顺序固定:
|
||||||
|
|
||||||
|
1. **功能模块划分**: 明确的模块结构和模块关系
|
||||||
|
2. **功能详细说明**: 每个功能的具体描述、业务规则、验收标准
|
||||||
|
3. **数据需求**: 数据实体、字段定义、数据规则
|
||||||
|
4. **流程图**: 使用 PlantUml 语法实现,清晰展示业务流程和逻辑
|
||||||
|
|
||||||
|
## 需求描述要求
|
||||||
|
|
||||||
|
- **简洁**: 避免冗余和无关信息
|
||||||
|
- **聚焦**: 只描述业务需求,不涉及实现方案
|
||||||
|
- **明确无歧义**: 每个需求点都有准确定义,避免模糊表述
|
||||||
|
|
||||||
|
## 规则作用
|
||||||
|
|
||||||
|
保持需求文档的纯粹性,将需求分析与设计实现分离,通过流程图直观展示业务逻辑
|
||||||
|
|
||||||
|
## 规则重要性
|
||||||
|
|
||||||
|
确保需求文档聚焦业务价值和用户需求,便于需求评审、开发理解和后续变更管理
|
||||||
Loading…
Reference in New Issue