9.3 KiB
9.3 KiB
Team V2 升级验证计划
📋 验证目标
验证升级后的灵活 Agent 团队架构是否正常工作，确认：
- PM 能正确扫描和分类 Skill
- PM 能按照注入协议将 Skill 摘要下发给子 Agent
- 子 Agent 能消费 Skill 摘要并遵循约束
- 子 Agent 能按统一格式汇报结果且不自行终止
- 技术栈特有规范（如双内边距、搜索区域）没有因迁移而丢失
- Agent 足够通用，不包含技术栈 hardcode
🧪 测试用例
测试 1: PM 阶段 0 — Skill 扫描与分类
操作: 使用 /team 启动一个需求，例如：
"开发一个商品管理列表页，包含搜索、新增、编辑、删除功能"
验证清单:
- PM 是否扫描了
.opencode/skills/目录？ - PM 是否正确识别了三类 Skill？
- 技术栈 Skill:
tech-stack/umijs-procomponents - 业务 Skill:
business/product-management - 通用 Skill:
engineering/code-quality
- 技术栈 Skill:
- PM 是否读取了匹配到的 Skill 内容？
- PM 是否在任务启动输出中列出了匹配的 Skill 清单？
预期输出:
## 🚀 任务启动
**需求**: 商品管理列表页 **Skill 匹配**: umijs-procomponents + product-management + code-quality **团队组装**: @planning + @frontend + @code-spec + @qa-tester
测试 2: PM → @planning 的 Skill 注入
操作: 观察 PM 委派 @planning 时的指令内容
验证清单:
- 委派指令中是否包含 📦 技术栈要点 章节？
- 是否提到 UmiJS 4 + ProComponents？
- 是否提到搜索区域规范（< 4 字段 vs >= 4 字段）？
- 是否提到零 CSS / Token 样式？
- 是否提到双内边距禁止？
- 委派指令中是否包含 🔧 质量红线 章节？
- 是否提到禁止 any？
- 是否提到 500 行限制？
- 是否提到安全规范（XSS、金额精度）？
- 委派指令中是否包含 📋 业务要点 章节？
- 是否包含 product-management Skill 中的业务规则？
- PM 是否直接写入了 Skill 内容（而非让 @planning 自己去读文件）？
测试 3: @planning 的 Skill 消费与规划
操作: 检查 @planning 输出的规划文档
验证清单:
- 规划是否遵循了技术栈 Skill 的约束？
- 是否规划使用 ProTable 做列表？
- 是否规划了搜索区域模式（根据字段数量选择方案）？
- 是否规划了 src/services/ + mock/ + data.d.ts 结构？
- 规划是否融合了业务 Skill？
- 是否包含商品数据模型？
- 是否考虑了业务状态和约束？
- @planning 是否调用了 superpowers 进行产品细化？
- @planning 是否使用了 Context7 验证技术方案？
- 输出是否使用了子 Agent 协议的统一格式？
- 是否以
## 📋 规划结果摘要开头？ - 是否包含"下一步行动建议"？
- 是否结尾有"请主 Agent 审阅"？
- 是否以
- @planning 是否自行结束了会话？（不应该）
测试 4: PM → @frontend 的 Skill 注入
操作: 用户确认规划后，观察 PM 委派 @frontend 时的指令
验证清单:
- 委派指令中是否包含完整的技术栈摘要？
- ProComponents 组件选型？
- 禁止双内边距？
- 零 CSS + Token？
- 服务层目录结构？
- i18n 规范？
- 委派指令中是否包含业务摘要？
- 委派指令中是否包含质量红线？
测试 5: @frontend 的红线执行
操作: 检查 @frontend 的实施过程
验证清单:
- @frontend 是否在编码前调用了 Context7 查询组件 API？
- @frontend 是否遵循了注入的技术栈约束？
- 使用 ProTable 而非手写表格？
- 使用 Token 样式而非 CSS 文件？
- ProComponents 外层没有包裹 Card？
- i18n 使用了 intl.formatMessage + defaultMessage？
- @frontend 是否遵循了质量红线？
- 无 any 类型？
- 单文件不超过 500 行？
- 服务层隔离？
- 输出是否使用了统一格式
## 🚀 实施结果摘要？ - @frontend 是否自行结束了会话？（不应该）
测试 6: @code-spec 的动态审计
操作: 观察 PM 委派 @code-spec 时的审计过程
验证清单:
- PM 委派指令中是否附带了技术栈审计要点？
- @code-spec 是否执行了固定审计项？
- any 类型检查？
- 500 行限制？
- XSS 安全？
- 服务层隔离？
- 加载状态？
- 防重复点击？
- @code-spec 是否执行了Skill 驱动审计项？
- ProComponents 双内边距检查？
- Token 样式检查？
- i18n 完整性？
- 输出是否使用了统一格式
## ✅ 代码审查结果摘要？- 是否有优先级分级（P0/P1/P2）？
- @code-spec 是否自行结束了会话？（不应该）
测试 7: @qa-tester 的动态测试
操作: 观察 PM 委派 @qa-tester 时的测试过程
验证清单:
- PM 委派指令中是否附带了技术栈测试要点？
- @qa-tester 是否执行了固定测试项？
- 功能完整性（按钮、表单、CRUD）？
- 控制台零错误？
- 加载状态？
- 防重复提交？
- @qa-tester 是否执行了Skill 驱动测试项？
- i18n 双语验证？
- 样式合规（如 ProComponents 布局）？
- 输出是否使用了统一格式
## 🧪 QA 测试结果摘要？ - @qa-tester 是否自行结束了会话？（不应该）
- @qa-tester 是否尝试修改代码？（不应该）
测试 8: PM 闭环与终止控制
操作: 观察整个流程的 PM 行为
验证清单:
- PM 是否在 @planning 完成后停下等待用户确认？
- PM 是否在收到子 Agent 汇报后检查了后续阶段？
- 如果 @code-spec 发现问题：
- PM 是否回派给 @frontend 修复（而非自己修）？
- 修复后是否重新走 @code-spec → @qa-tester 闭环？
- 如果 @qa-tester 发现问题：
- PM 是否回派给 @frontend（而非自己修）？
- 修复后是否从 @code-spec 重新走起？
- PM 是否在所有阶段通过后才宣布完成？
- 最终交付是否使用了
## ✅ 任务完成格式？
测试 9: 通用性验证（负面测试）
操作: 检查新 Agent 文件中是否有技术栈 hardcode 残留
验证方法（命令行）:
# 在 Agent 文件中搜索不应出现的技术栈关键词
grep -n 'UmiJS\|ProComponents\|ProTable\|QueryFilter\|Ant Design\|antd\|useRequest\|src/services\|data\.d\.ts\|零 CSS\|formatMessage' \
.opencode/agents/frontend.md \
.opencode/agents/code-spec.md \
.opencode/agents/qa-tester.md \
.opencode/agents/planning.md
预期: 命令应该无输出（无匹配）。如果有匹配，说明还有技术栈 hardcode 残留。
注意: team.md 中允许出现这些词，因为 PM 需要知道如何识别技术栈。但 4 个子 Agent 中不应有。
测试 10: Figma 集成验证（可选）
操作: 使用带 Figma 链接的需求启动 /team，例如：
"根据这个 Figma 开发订单管理页面 https://figma.com/design/xxx/yyy?node-id=1-2"
验证清单:
- PM 阶段 0 是否调用了 Figma MCP 提取产品信息？
- PM 是否将 Figma 产品信息和设计规范注入给 @planning？
- @planning 是否在规划中融合了 Figma 信息？
- @frontend 是否根据 Figma 设计稿进行高保真还原？
- @qa-tester 是否执行了 Figma 视觉还原对比？
📊 验证结果记录模板
| 测试编号 | 测试名称 | 结果 | 发现的问题 |
|---|---|---|---|
| 1 | PM Skill 扫描与分类 | ⬜ | |
| 2 | PM → @planning Skill 注入 | ⬜ | |
| 3 | @planning Skill 消费与规划 | ⬜ | |
| 4 | PM → @frontend Skill 注入 | ⬜ | |
| 5 | @frontend 红线执行 | ⬜ | |
| 6 | @code-spec 动态审计 | ⬜ | |
| 7 | @qa-tester 动态测试 | ⬜ | |
| 8 | PM 闭环与终止控制 | ⬜ | |
| 9 | 通用性验证（负面测试） | ⬜ | |
| 10 | Figma 集成（可选） | ⬜ |
🚀 建议的验证需求
用以下需求启动一次完整的 /team 流程即可覆盖测试 1-8：
"开发一个商品管理列表页。要求： > 1. 包含商品名称、价格、状态、创建时间等字段的搜索和列表 > 2. 支持新增、编辑（弹窗表单）、删除操作 > 3. 价格需要支持分到元的转换显示 > 4. 支持中英双语"
这个需求会触发：
- ✅ 技术栈 Skill 匹配（umijs-procomponents）
- ✅ 业务 Skill 匹配（product-management）
- ✅ 通用 Skill 加载（code-quality）
- ✅ 搜索区域模式判断（≥ 4 字段 → QueryFilter）
- ✅ 金额精度安全规则
- ✅ i18n 双语验证
- ✅ 完整的 规划 → 实施 → 审计 → 测试 流程
验证完成标准: 测试 1-9 全部通过（测试 10 可选）。