sion123
e6614ae5a3
重构 Monisuo 项目开发流程文档，将原有的 Phase 3-4 拆分为两个独立的 Agent 阶段： - Phase 3 (Agent A)：专注于代码精简、自动化测试和构建验证 - Phase 4 (Agent B)：专注于基于测试用例的功能验证 明确两个 Agent 的职责分工和 Bug 修复循环机制，提升开发流程的清晰度和质量保证能力。
207 lines
6.6 KiB
Markdown
207 lines
6.6 KiB
Markdown
---
|
||
name: monisuo-dev
|
||
description: Monisuo 项目结构化开发流程。需求分析 → 架构设计 → 开发 → 测试构建。
|
||
---
|
||
|
||
# Monisuo 开发工作流
|
||
|
||
## 流程概览
|
||
|
||
```
|
||
Phase 1: 需求定义 → Phase 1.5: 架构设计 → Phase 2: 模块化开发
|
||
↑ │
|
||
│ ↓
|
||
│ [Agent A] Phase 3: 精简 + 测试 + 构建
|
||
│ │
|
||
│ ↓ (通过)
|
||
│ [Agent B] Phase 4: 功能验证（用例驱动）
|
||
│ │
|
||
└──────────────── Bug 修复 ←──────────────────┘
|
||
```
|
||
|
||
**Phase 1-1.5-2 在主对话完成，Phase 3 和 Phase 4 分别启动独立 Agent。**
|
||
|
||
---
|
||
|
||
## Phase 1: 需求定义
|
||
|
||
将用户需求结构化为 Feature Spec，输出到 `docs/features/[feature-name].md`。
|
||
|
||
### Feature Spec 结构
|
||
|
||
```markdown
|
||
# [功能名称]
|
||
|
||
## 概述
|
||
功能名称 / 优先级(P0-P2) / 业务背景(痛点→方案→收益)
|
||
|
||
## 用户故事
|
||
作为 [角色]，我希望 [行为]，以便 [目的]
|
||
|
||
## 功能列表
|
||
- [ ] 功能点1
|
||
- [ ] 功能点2
|
||
|
||
## 技术方案（Phase 1.5 填充）
|
||
### API 设计
|
||
### 数据模型
|
||
### 技术决策
|
||
|
||
## 测试用例
|
||
- [ ] 正常 / 异常 / 边界
|
||
|
||
## 验收标准
|
||
```
|
||
|
||
### 执行步骤
|
||
1. 与用户确认需求，识别关键场景和约束
|
||
2. 创建 `docs/features/[feature-name].md`，填充概述、用户故事、功能列表、测试用例
|
||
3. 与用户评审确认
|
||
|
||
---
|
||
|
||
## Phase 1.5: 架构设计
|
||
|
||
编码前确定技术方案。**必须先探索代码库再设计。**
|
||
|
||
### 执行步骤
|
||
|
||
1. **探索现有代码库**
|
||
- Glob/Grep/Read 扫描相关模块，理解现有模式和架构
|
||
- 识别可复用的组件、Service、工具类
|
||
- 确认集成点
|
||
|
||
2. **定义 API 契约** — 方法、路径、请求/响应体，写入 Spec 的「API 设计」
|
||
|
||
3. **设计数据模型** — 表结构、Entity/DTO/VO 映射，写入 Spec 的「数据模型」
|
||
|
||
4. **记录技术决策** — 选型理由、模块职责、关键约束，写入 Spec 的「技术决策」
|
||
|
||
### 完成标准
|
||
- 已扫描现有代码，无重复造轮子
|
||
- API 契约完整，前后端可并行开发
|
||
- 数据模型与现有表结构兼容
|
||
|
||
---
|
||
|
||
## Phase 2: 模块化开发
|
||
|
||
依据 Spec 中的 API 契约和数据模型，自底向上开发：
|
||
|
||
```
|
||
1. 数据层 → 2. 后端 API → 3. 前端实现
|
||
DDL/Entity Controller/Service Model/Provider/UI
|
||
```
|
||
|
||
### 代码规范
|
||
- Flutter: `flutter analyze` 无错，用 AppSpacing/AppRadius/AppColorScheme，禁止硬编码颜色
|
||
- Java: Lombok 简化，资金变动方法加 `@Transactional(rollbackFor = Exception.class)`，RESTful 设计
|
||
|
||
---
|
||
|
||
## Phase 3: 精简 + 测试 + 构建（Agent A）
|
||
|
||
Phase 2 完成后，启动独立 Agent 执行代码精简、自动化测试和构建。
|
||
|
||
### 启动 Agent A
|
||
|
||
```
|
||
Agent(
|
||
description: "精简+测试验证与构建",
|
||
prompt: |
|
||
你是 Monisuo 项目质量 Agent，独立完成以下任务，不要询问用户。
|
||
|
||
## 1. 读取 Spec
|
||
- 路径: docs/features/[feature-name].md
|
||
- 理解验收标准
|
||
|
||
## 2. 代码审查
|
||
- git diff 查看变更
|
||
- Flutter: flutter analyze, AppSpacing/AppRadius/AppColorScheme 规范
|
||
- Java: @Transactional 资金方法, 统一异常处理, RESTful 设计
|
||
|
||
## 3. 代码精简（simplify）
|
||
- 对变更代码执行 /simplify：审查复用性、质量和效率，修复发现的问题
|
||
- 精简完成后重新运行 git diff 确认变更合理
|
||
|
||
## 4. 测试
|
||
- 后端: mvn test
|
||
- Flutter: cd flutter_monisuo && flutter test
|
||
- API: ./tests/api/test-[feature].sh（如存在）
|
||
|
||
## 5. 构建
|
||
- 后端: mvn clean package -DskipTests → target/monisuo-*.jar
|
||
- Flutter: cd flutter_monisuo && flutter build web --release --dart-define=ENV=prod → build/web/
|
||
|
||
## 6. 输出报告
|
||
| 项目 | 状态 | 备注 |
|
||
|------|------|------|
|
||
| 代码审查 | ✅/❌ | |
|
||
| 代码精简 | ✅/❌ | 改动摘要 |
|
||
| 后端测试 | ✅/❌ | |
|
||
| Flutter 测试 | ✅/❌ | |
|
||
| 后端构建 | ✅/❌ | |
|
||
| Flutter 构建 | ✅/❌ | |
|
||
|
||
如有 Bug，列出：文件、原因、修复建议。返回主对话修复后重新验证。
|
||
)
|
||
```
|
||
|
||
---
|
||
|
||
## Phase 4: 功能验证（Agent B）
|
||
|
||
**Agent A 全部通过后**，启动第二个独立 Agent，基于 Spec 中的测试用例验证功能正确性。
|
||
|
||
### 启动 Agent B
|
||
|
||
```
|
||
Agent(
|
||
description: "功能验证（用例驱动）",
|
||
prompt: |
|
||
你是 Monisuo 项目功能验证 Agent。基于 Feature Spec 中的测试用例，验证功能实现是否正确。不要询问用户。
|
||
|
||
## 1. 读取 Spec
|
||
- 路径: docs/features/[feature-name].md
|
||
- 提取「测试用例」和「验收标准」
|
||
|
||
## 2. 读取变更代码
|
||
- git diff 查看本次变更的文件列表
|
||
- 阅读变更的 Controller、Service、Provider、UI 代码
|
||
- 对照 Spec 中的 API 设计，确认实现与契约一致
|
||
|
||
## 3. 逐条验证测试用例
|
||
对 Spec 中的每条测试用例：
|
||
- **正常流程**：追踪代码路径，确认主流程逻辑正确（参数传递、返回值、状态变更）
|
||
- **异常流程**：确认错误处理覆盖（参数校验、权限检查、边界条件）
|
||
- **边界条件**：空值、零值、溢出、并发等极端场景是否有防护
|
||
|
||
### 验证方法
|
||
- **后端 API**：阅读 Controller → Service → Mapper 代码路径，确认请求参数、业务逻辑、数据库操作与 Spec 一致
|
||
- **前端页面**：阅读 UI → Provider/State → Service 代码路径，确认交互流程、状态管理、错误展示正确
|
||
- **数据一致性**：确认资金变动相关的操作有事务注解、余额校验、流水记录
|
||
|
||
## 4. 输出验证报告
|
||
| 用例编号 | 用例描述 | 验证结果 | 备注 |
|
||
|----------|----------|----------|------|
|
||
| TC-01 | 正常：xxx | ✅ 通过 / ❌ 失败 | 具体原因 |
|
||
| TC-02 | 异常：xxx | ✅ 通过 / ❌ 失败 | 具体原因 |
|
||
| ... | ... | ... | ... |
|
||
|
||
### 总结
|
||
- 通过率：X/Y
|
||
- 未通过用例：列出失败原因和修复建议
|
||
- 风险点：潜在问题或遗漏
|
||
|
||
如有未通过用例，返回主对话修复后重新启动验证。
|
||
)
|
||
```
|
||
|
||
---
|
||
|
||
## Bug 修复循环
|
||
|
||
- **Agent A 失败**（测试/构建不通过）→ 主对话修复 Bug → 重新启动 Agent A
|
||
- **Agent B 失败**（功能验证不通过）→ 主对话修复逻辑 → 重新启动 Agent B
|
||
- **全部通过** → 开发完成
|