fix(framework): 宪法+目录框架整改——统一权限体系、覆盖后端路径、补齐提示词、工作流闭环
- 权限矩阵: RL/R/W/RW 四态替代 ✅/❌，三文件语义对齐 - 目录重构: server/config/types 移入 src/，projects/*/src/ 全覆盖 - 提示词库: 新增 code-style.md / doc-template.md / bug-report.md - 工作流: 8阶段→4阶段，新增 retry 循环 + escalation 升级规则 - 审核报告: reports/quality-reports/framework-review-2026-05-23.md
This commit is contained in:
@@ -1 +1,6 @@
|
||||
# coding
|
||||
# Dev AI 提示词库
|
||||
|
||||
| 文件 | 说明 |
|
||||
|------|------|
|
||||
| [code-style.md](code-style.md) | 代码风格、命名规范、目录组织 |
|
||||
| [doc-template.md](doc-template.md) | impact.md / acceptance.md 等文档模板 |
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
# Dev AI 代码风格规范
|
||||
|
||||
## 适用技术栈
|
||||
|
||||
| 层 | 技术 | 语言 |
|
||||
|-----|------|------|
|
||||
| 前端 | Taro 4 + React 18 | TypeScript 5.x |
|
||||
| 样式 | Tailwind CSS 4 | — |
|
||||
| 后端 | NestJS 10 | TypeScript 5.x |
|
||||
| 训练 | PyTorch 2.0 | Python 3.10+ |
|
||||
|
||||
---
|
||||
|
||||
## 1. 文件命名
|
||||
|
||||
| 类型 | 规则 | 示例 |
|
||||
|------|------|------|
|
||||
| 页面组件 | kebab-case | `error-detail.tsx` |
|
||||
| UI 组件 | kebab-case | `button.tsx` |
|
||||
| 工具函数 | kebab-case | `format-date.ts` |
|
||||
| 类型定义 | kebab-case | `error-entry.d.ts` |
|
||||
| NestJS 模块 | kebab-case | `auth.module.ts` |
|
||||
| Python 模块 | snake_case | `data_loader.py` |
|
||||
|
||||
## 2. 目录组织（前端）
|
||||
|
||||
```
|
||||
src/
|
||||
├── pages/{page-name}/ # 页面 —— 一个目录一个页面
|
||||
│ ├── index.tsx
|
||||
│ ├── index.config.ts
|
||||
│ └── index.css
|
||||
├── components/ # 通用组件
|
||||
│ └── {component-name}/
|
||||
│ └── index.tsx
|
||||
├── lib/ # 工具函数、hooks
|
||||
├── types/ # 全局类型声明
|
||||
├── server/ # NestJS 后端
|
||||
└── config/ # Taro 构建配置
|
||||
```
|
||||
|
||||
## 3. 目录组织（NestJS 后端）
|
||||
|
||||
```
|
||||
src/server/src/
|
||||
├── modules/{name}/ # 一个模块一个目录
|
||||
│ ├── {name}.module.ts
|
||||
│ ├── {name}.controller.ts
|
||||
│ ├── {name}.service.ts
|
||||
│ ├── dto/
|
||||
│ └── entities/
|
||||
├── common/ # 共享：拦截器、守卫、管道
|
||||
└── main.ts
|
||||
```
|
||||
|
||||
## 4. 命名风格
|
||||
|
||||
**TypeScript：**
|
||||
- 组件：PascalCase —— `ErrorCard`
|
||||
- 函数/变量：camelCase —— `getUserProfile`
|
||||
- 常量：UPPER_SNAKE —— `MAX_PAGE_SIZE`
|
||||
- 接口/类型：PascalCase —— `ErrorEntry`
|
||||
|
||||
**Python：**
|
||||
- 类：PascalCase —— `DataLoader`
|
||||
- 函数/变量：snake_case —— `load_dataset`
|
||||
- 常量：UPPER_SNAKE —— `BATCH_SIZE`
|
||||
|
||||
## 5. 导入顺序（TypeScript）
|
||||
|
||||
```
|
||||
1. 第三方库
|
||||
2. Taro 相关
|
||||
3. 项目内部（@/ 别名）
|
||||
4. 相对路径
|
||||
5. 样式文件
|
||||
```
|
||||
|
||||
示例：
|
||||
```typescript
|
||||
import { useState } from 'react';
|
||||
import Taro from '@tarojs/taro';
|
||||
import { Button } from '@/components/ui/button';
|
||||
import { formatDate } from './lib/date';
|
||||
import './index.css';
|
||||
```
|
||||
|
||||
## 6. 组件规范
|
||||
|
||||
- 优先使用函数组件，不用 class 组件
|
||||
- 一个文件只有一个 export default 组件
|
||||
- 组件 props 必须声明类型接口
|
||||
- 跨端兼容：避免使用 `document`、`window`（用 Taro API 代替）
|
||||
|
||||
## 7. API 调用规范
|
||||
|
||||
- 前端统一使用 `@/network.ts` 中的 `Network.request`，不要直接调用 `Taro.request`
|
||||
- 后端Controller 只做参数校验和路由，业务逻辑放在 Service
|
||||
- API 响应统一使用 Envelope 格式 `{ code, msg, data }`
|
||||
|
||||
## 8. 不能做的事
|
||||
|
||||
- 不要在 `src/` 下写测试文件（测试在 `tests/`）
|
||||
- 不要引入未经 package.json 声明的依赖
|
||||
- 不要在组件中硬编码后端地址（用 `PROJECT_DOMAIN` 全局变量）
|
||||
@@ -0,0 +1,76 @@
|
||||
# Dev AI 文档模板
|
||||
|
||||
下面三个模板用于 Dev AI 在 `review/{task_id}/` 下产出标准化文件。
|
||||
|
||||
---
|
||||
|
||||
## A. impact.md 模板（变更影响范围）
|
||||
|
||||
```markdown
|
||||
# {TASK_ID} - 变更影响范围
|
||||
|
||||
## 修改的文件
|
||||
| 文件路径 | 修改类型 | 影响等级 |
|
||||
|---------|---------|---------|
|
||||
| projects/P01_errlens_app/src/server/src/modules/auth/auth.service.ts | 新增 | HIGH |
|
||||
| projects/P01_errlens_app/src/server/src/modules/auth/dto/login.dto.ts | 新增 | MEDIUM |
|
||||
|
||||
> 影响等级：HIGH=核心逻辑变更 | MEDIUM=新增文件 | LOW=注释/格式
|
||||
|
||||
## 影响的功能模块
|
||||
- [x] 用户认证模块
|
||||
- [ ] 错题管理模块（无影响）
|
||||
|
||||
## 需要回归测试的场景
|
||||
- 场景1: 用户登录成功流程
|
||||
- 场景2: 密码错误返回 401
|
||||
- 场景3: Token 过期后刷新
|
||||
|
||||
## 环境依赖变更
|
||||
- 新增依赖: bcrypt, @nestjs/jwt
|
||||
- 数据库迁移: 新增 users 表
|
||||
```
|
||||
|
||||
**要点：**
|
||||
- `修改的文件` 必须使用从仓库根目录开始的完整路径
|
||||
- 影响等级要实事求是，不要全写 HIGH
|
||||
- `需要回归测试的场景` 要写**用户视角**的场景，不是代码内部细节
|
||||
|
||||
---
|
||||
|
||||
## B. acceptance.md 模板（验收标准）
|
||||
|
||||
```markdown
|
||||
# {TASK_ID} - 验收标准
|
||||
|
||||
## 功能验收
|
||||
- [ ] 用户可以注册新账户（邮箱+密码）
|
||||
- [ ] 密码强度不足时提示明确错误信息
|
||||
- [ ] 登录成功返回有效 JWT Token
|
||||
|
||||
## 非功能验收
|
||||
- [ ] API 响应时间 < 200ms
|
||||
- [ ] 密码使用 bcrypt 加密存储
|
||||
- [ ] JWT Token 有效期 24 小时
|
||||
|
||||
## 测试覆盖要求
|
||||
- 单元测试覆盖率: >= 80%
|
||||
- 集成测试覆盖率: >= 60%
|
||||
- E2E 测试场景: >= 3 个
|
||||
|
||||
## 验收通过条件
|
||||
- 所有功能点验证通过
|
||||
- 测试覆盖率达标
|
||||
- 无重大安全漏洞
|
||||
```
|
||||
|
||||
**要点：**
|
||||
- 功能验收用「用户可以…」句式，让 QA AI 和人类都能看懂
|
||||
- 每个功能点对应 task.md 里的一项交付物
|
||||
- 非功能验收写具体的可测量指标，不要写「性能好」「代码整洁」
|
||||
|
||||
---
|
||||
|
||||
## C. 没有 task.md 模板
|
||||
|
||||
task.md 由人类负责人创建，Dev AI 只读不写。Dev AI 如需补充技术细节，写在 impact.md 的「技术备注」段落中，不要直接修改 task.md。
|
||||
Reference in New Issue
Block a user