Mimingguang ee078b61bc feat: 后台管理系统完整重构 + 前后台数据联通
- 后台全面引入 Naive UI 组件库,统一 UI 规范
- 前台 usePublicApi 切换到 API 调用(GET /api/content/[key])
- 前后台数据源统一(site_content 表)
- 产品线统一管理(tour/camp/course 三套编辑器)
- 产品数据归一化(itinerary/faq/pricing 格式统一)
- 表单提交 API 改写入 submissions 表
- 新增 submissions 标记已读 API
- site-content PUT 支持 upsert
- 修复前台 bug(stories 路由冲突、占位符警告、selector breadcrumb)
- 消除 PageHero 类型警告(useSEO reactive 修复)
- 25 个前台页面全部 HTTP 200,展示效果不变

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-24 17:48:02 +08:00

109 行
3.9 KiB
Markdown

此文件含有模棱两可的 Unicode 字符

此文件含有可能会与其他字符混淆的 Unicode 字符。 如果您是想特意这样的,可以安全地忽略该警告。 使用 Escape 按钮显示他们。

# 工作流调度器
这是多 Agent 协作的工作流调度器。按照以下流程执行:
## 参数
$ARGUMENTS
如果没有参数,提示用户输入需求。
## 模型选择策略
| 模型 | 适用场景 | 典型任务 |
|------|----------|----------|
| **haiku** | 简单/重复性任务 | 文案修改、样式微调、配置更新 |
| **sonnet** | 标准复杂度任务 | 标准页面开发、API CRUD、组件修改、常规测试 |
| **opus** | 高复杂度/决策性任务 | PM 分析、复杂交互、全新功能模块、数据库设计 |
### 各 Phase 默认模型
| Phase | 角色 | 默认模型 | 何时升级 |
|-------|------|----------|----------|
| Phase 1 | PM 分析 | **opus** | — |
| Phase 2 | UI/UX 设计 | **sonnet** | 全新页面类型时升级 opus |
| Phase 3 | Backend 开发 | **按任务判定** | — |
| Phase 4 | Frontend 开发 | **按任务判定** | — |
| Phase 5 | 测试验证 | **sonnet** | 涉及安全时升级 opus |
| Phase 6 | PM 验收 | **opus** | — |
## 完整工作流
### Phase 1: 产品经理分析需求
以产品经理身份:
1. 读取 `.claude/agents/pm.md` 角色定义
2. 读取 PM 的所有记忆文件
3. 分析用户提出的需求
4. 扫描项目现状(已有 API、页面、组件
5. 生成任务分配方案
### Phase 2: UI/UX 设计(如有新页面)
对于需要新增页面的任务,使用 Agent 工具以 UI/UX 设计师身份:
1. 读取 `.claude/agents/uiux.md` 角色定义和记忆
2. 查看现有类似页面作为参考
3. 输出设计方案(只出方案,不写代码)
4. 将方案追加到任务描述中
### Phase 3: Backend 开发(如有 API 变更)
对于涉及后端的任务,使用 Agent 工具以后端开发身份:
1. 读取 `.claude/agents/backend.md` 角色定义和记忆
2. 按任务列表开发 API、数据库变更
3. 遵循 Nitro + Drizzle 开发规范
4. 每完成一个任务记录结果
### Phase 4: Frontend 开发
使用 Agent 工具以前端开发身份:
1. 读取 `.claude/agents/frontend.md` 角色定义和记忆
2. 按任务列表开发页面、组件
3. 遵循 Vue 3 + Nuxt 3 开发规范
4. 每完成一个任务记录结果
### Phase 5: 测试验证(只测不改)
使用 Agent 工具以测试工程师身份:
- **关键规则**: 测试 Agent 只用 Read/Grep/Glob/Bash,**绝不修改源代码**
1. 读取 `.claude/agents/tester.md` 角色定义和记忆
2. 对前端和后端的产出进行代码审查(只读)
3. 生成测试报告(✅通过 / ⚠️有问题 / ❌不通过)
### Phase 6: 问题修复闭环(如有问题)
如果 Phase 5 测试报告中有 ⚠️ 或 ❌:
1. PM 分析问题,转化为修复任务
2. 派发给前端或后端修复
3. 回归测试(最多 3 轮)
### Phase 7: 产品经理验收
回到产品经理身份:
1. 确认测试报告 ✅通过
2. 更新各 Agent 的记忆文件
### Phase 8: 自动提交代码
测试通过后:
1. `git status` 查看变更文件
2. `git add` 暂存本批次涉及的文件(不要 add -A
3. `git commit` 生成提交信息,格式:
```
feat: {简要描述}
- TASK-1: {任务描述}
- TASK-2: {任务描述}
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
```
4. 不自动 push
## 角色边界
| 角色 | 可用工具 | 不可用工具 | 职责 |
|------|---------|-----------|------|
| PM | Read, Grep, Glob | Edit, Write, Bash(代码) | 分析需求、分配任务、验收 |
| Frontend | Read, Edit, Write, Bash, Grep, Glob | — | 前端页面和组件开发 |
| Backend | Read, Edit, Write, Bash, Grep, Glob | — | API 和数据库开发 |
| Tester | Read, Grep, Glob, Bash(检测) | Edit, Write | 测试、发现问题、出报告 |
| UI/UX | Read, Grep, Glob | Edit, Write | 出设计方案 |
## 异常处理
- 如果某个 Phase 失败,回到产品经理身份分析原因
- 测试不通过 → PM 分析 → 对应角色修复 → 再测试(闭环,最多 3 轮)
- 所有决策和问题记录到各 Agent 的记忆文件