15 KiB
15 KiB
name, description
| name | description |
|---|---|
| soul-role-workflow | Soul 创业派对开发协同流程。小程序开发工程师、管理端开发工程师、后端开发职责与协同。跨端功能开发、新增/优化时使用。Use when 跨端协同, 角色流程, 功能开发协作. |
Soul 创业派对 - 角色流程控制 Skill
当进行跨端功能开发（小程序新增/优化、管理端配置、API 变更）时，使用本 Skill 明确开发三角色职责与协同流程，保证开发顺畅、减少漏改与返工。
1. 开发三角色定义
| 角色 | 负责目录 | 职责概要 | 开发风格规范 |
|---|---|---|---|
| 小程序开发工程师 | miniprogram/ | 微信原生小程序 C 端功能，只调 /api/miniprogram/* |
SKILL-小程序开发.md：WXML/WXSS/JS、app.request、scene 编解码、权限与支付约定 |
| 管理端开发工程师 | soul-admin/ | React 管理后台，只调 /api/admin/*、/api/db/* |
SKILL-管理端开发.md：React + Vite + Tailwind、client.ts、Radix UI、鉴权与列表约定 |
| 后端开发 | soul-api/ | Go + Gin + GORM 接口服务，按使用方挂 miniprogram / admin / db 路由 | SKILL-API开发.md、soul-api.mdc：GORM、Gin、路由分组、响应格式 |
开发风格约定：各角色在各自端内开发时，必须按上表对应的 Skill 与 boundary 执行，保持代码风格、目录结构、命名与接口约定一致。不得跨路径调用（详见 soul-project-boundary）。
2. 协同流程总览（线框图）
2.1 主流程：小程序功能开发驱动的协同
┌─────────────────────────────────────────────────────────────────────────────────┐
│ 小程序功能开发（新增/优化）协同流程 │
└─────────────────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ 需求/变更发起 │ （产品/小程序开发者提出）
└──────┬───────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────┐
│ 阶段 1：需求分析与接口设计 │
│ │
│ API 开发者 ──────► 分析接口需求（miniprogram 组） │
│ │ │
│ ├──► 管理端开发者 ──────► 分析：该功能在管理端是否需要？ │
│ │ • 字段调整（列表/表单） │
│ │ • 配置/开关/审核/统计 │
│ │ • 输出：需要 / 不需要 │
│ │ │
│ └──► 输出接口契约（路径、请求/响应、字段） │
└──────────────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────┐
│ 阶段 2：并行开发 │
│ │
│ API 开发者 ──────► 实现 miniprogram 接口（优先/并行） │
│ │ │
│ │ ┌─────────────────────────────────────────────────────────────┐ │
│ │ │ 若管理端需要：同时实现 admin/db 接口 │ │
│ │ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ 小程序开发者 ───► 实现小程序功能（依赖 miniprogram 接口） │
│ │
│ 【管理端暂不开发，等小程序完成后再启动】 │
└──────────────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────┐
│ 阶段 3：小程序完成 → 管理端启动（若需要） │
│ │
│ 小程序开发者 ──────► 完成并自测 ✓ │
│ │ │
│ ▼ │
│ 管理端开发者 ──────► 若阶段 1 判定「需要」：开始管理端调整 │
│ │ • 字段展示/表单提交 │
│ │ • 配置页、审核、统计 │
│ │ • 调用 admin/db 接口 │
│ │ │
│ API 开发者 ──────► 若管理端有新增需求：补充 admin/db 接口 │
└──────────────────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────┐
│ 阶段 4：联调与收尾 │
│ │
│ 三端联调 ───► 过 soul-change-checklist ───► 提交 │
└──────────────────────────────────────────────────────────────────────────────┘
2.2 Mermaid 流程图（可渲染版本）
flowchart TB
subgraph 阶段1["阶段 1：需求分析与接口设计"]
A[需求/变更发起] --> B[API 开发者分析 miniprogram 接口]
A --> C[管理端开发者分析]
C --> C1{管理端是否需要?}
C1 -->|需要| C2[记录：字段/配置/审核/统计]
C1 -->|不需要| C3[无需管理端调整]
B --> D[输出接口契约]
C2 --> D
end
阶段1 --> 阶段2
subgraph 阶段2["阶段 2：并行开发"]
E[API 开发者实现 miniprogram 接口]
F[API 开发者实现 admin/db 接口<br/>若管理端需要]
G[小程序开发者实现功能]
E --> G
end
阶段2 --> 阶段3
subgraph 阶段3["阶段 3：小程序完成 → 管理端启动"]
H[小程序完成并自测 ✓]
H --> I{管理端需要?}
I -->|是| J[管理端开发者开始调整]
I -->|否| K[跳过]
J --> L[API 开发者补充 admin/db<br/>若有新增需求]
end
阶段3 --> 阶段4
subgraph 阶段4["阶段 4：联调与收尾"]
M[三端联调]
N[过 soul-change-checklist]
O[提交]
M --> N --> O
end
2.3 角色时序图（谁在何时做什么）
sequenceDiagram
participant P as 产品/需求
participant MP as 小程序开发者
participant AD as 管理端开发者
participant API as API 开发者
P->>API: 1. 需求/变更
P->>AD: 1. 需求/变更
Note over API,AD: 阶段 1：需求分析
API->>API: 分析 miniprogram 接口需求
AD->>AD: 分析管理端是否需要字段/配置/审核/统计
AD->>API: 反馈：需要 / 不需要 + 具体项
API->>API: 输出接口契约
Note over API,MP: 阶段 2：并行开发
API->>API: 实现 miniprogram 接口
par 若管理端需要
API->>API: 实现 admin/db 接口
end
API->>MP: 接口可用
MP->>MP: 实现小程序功能
Note over MP,AD: 阶段 3：小程序完成 → 管理端
MP->>MP: 完成并自测 ✓
MP->>AD: 小程序完成
alt 管理端需要
AD->>AD: 开始管理端调整
AD->>API: 若有新增接口需求
API->>API: 补充 admin/db 接口
end
Note over API,AD: 阶段 4：联调
API->>API: 联调
MP->>MP: 联调
AD->>AD: 联调
Note over P,AD: 过 soul-change-checklist → 提交
3. 各角色执行清单
各角色在执行下列动作时，均按各自端的开发风格 Skill 编写代码（小程序→SKILL-小程序开发、管理端→SKILL-管理端开发、API→SKILL-API开发）。
3.1 小程序开发工程师
| 阶段 | 动作 |
|---|---|
| 需求分析 | 参与需求评审，明确功能范围与接口依赖 |
| 并行开发 | 按接口契约实现小程序功能，只调 /api/miniprogram/* |
| 完成自测 | 完成并自测通过后，通知管理端开发者（若管理端需要） |
| 收尾 | 参与联调，过 soul-change-checklist |
3.2 管理端开发工程师
| 阶段 | 动作 |
|---|---|
| 需求分析（关键） | 分析该功能在管理端是否需要： • 字段调整（列表/表单新增或修改） • 配置页、开关、审核、统计 • 输出「需要」或「不需要」及具体项 |
| 并行开发 | 暂不开发，等待小程序完成 |
| 管理端启动 | 小程序变更完成后，若需要则开始管理端调整 |
| 收尾 | 参与联调，过 soul-change-checklist |
3.3 后端开发
| 阶段 | 动作 |
|---|---|
| 需求分析 | 分析 miniprogram 接口需求，输出接口契约 |
| 并行开发 | 实现 /api/miniprogram/* 接口（优先）若管理端需要，同时实现 /api/admin/*、/api/db/* |
| 管理端补充 | 若管理端开发中有新增接口需求，补充 admin/db 接口 |
| 收尾 | 参与联调，过 soul-change-checklist |
4. 决策表：管理端是否需要调整
| 功能类型 | 管理端通常需要 | 示例 |
|---|---|---|
| 提现/审核类 | ✅ 审核、列表、统计 | 提现审核、拒绝 |
| 推荐/分销 | ✅ 配置、统计 | 推荐设置、数据看板 |
| 内容/章节 | ✅ CRUD、配置 | 章节管理、内容编辑 |
| 配置项 | ✅ 配置编辑 | 开关、文案、规则 |
| 纯展示/活动 | ❌ 或仅统计 | 活动页、弹窗 |
| 用户行为 | 视情况 | 若需审核/统计则要 |
原则：不确定时，管理端开发工程师主动与产品/小程序开发工程师确认。
4.1 管理端跟进原则（必守）
小程序变更 → 管理端须跟进做管理功能补充。
当小程序有功能新增或变更时，管理端开发工程师必须主动分析：该功能在后台需要哪些配置、审核、统计能力，并同步提出管理端需求。后端需配合提供相应的 admin/db 接口。
示例（stitch_soul 导师模块）：
- 小程序：导师列表展示价格、v2 弹窗选咨询项目（单次/半年/年度）
- 管理端补充：导师 CRUD + 每个导师独立价格配置（单次、半年、年度）
- 后端：mentors 表支持 price_single、price_half_year、price_year 等字段，或 mentor_prices 关联表
流程：小程序需求评审时，管理端即参与并输出「管理端补充项」；后端设计接口时一并考虑 admin 配置能力。
5. 与现有 Skills/Rules 的配合
Skills 索引按角色驱动，见 .cursor/README.md 第二节。
| 文档 | 关系 |
|---|---|
| soul-change-checklist.mdc | 阶段 4 必过清单 |
| SKILL-变更关联检查.md | 详细关联检查思路 |
| SKILL-小程序开发.md | 小程序开发工程师主 Skill：请求、scene、支付、权限等约定 |
| SKILL-管理端开发.md | 管理端开发工程师主 Skill：client、auth、Radix UI、列表等约定 |
| SKILL-API开发.md | API 开发者主 Skill：GORM、路由分组、响应格式等约定 |
三角色在各自端内开发时，必须遵循对应主 Skill 的开发风格，保证三端风格统一、规范一致。
6. 何时使用本 Skill
| 触发条件 | 动作 |
|---|---|
| 小程序有新增功能或功能优化 | 启动本协同流程（主流程） |
| 管理端新增配置/审核页，需 API 支持 | 按「管理端先行」流程 |
| API 先实现接口，前端后对接 | 按「API 先行」流程 |
| 多人/多角色协作 | 按本 Skill 分工与顺序执行 |
| 单人在多端开发 | 按本流程自检，避免漏改 |
7. 其他驱动场景（简要）
| 驱动方 | 流程要点 |
|---|---|
| API 先行 | API 开发者先实现接口 → 小程序/管理端并行对接；接口契约需提前输出 |
| 管理端先行 | 管理端新增配置/审核页 → API 开发者实现 admin/db 接口 → 小程序按需对接配置 |
核心原则不变：先确定使用方 → 接口挂到正确路由组 → 变更后过 soul-change-checklist。
创建时间：2026-02
适用：跨端功能开发、三角色协同