f8894dd3f3
- updateNavButtons: 改用数组索引查找，而非简单的+1/-1 - updateSidebarHighlight: 使用parseFloat比较章节ID - updateMobileTOCHighlight: 使用parseFloat比较章节ID - 更新版本号强制刷新缓存
256 lines
6.7 KiB
Markdown
256 lines
6.7 KiB
Markdown
# 案例：认知作战室项目质量反思
|
||
|
||
> 本案例展示了 self-reflection skill 的完整应用过程
|
||
|
||
---
|
||
|
||
## 背景
|
||
|
||
**项目**：认知作战室 (Cognitive War Room)
|
||
**触发**：用户反馈 "我要的不是看起来好"
|
||
**时间**：2026-02-25
|
||
|
||
---
|
||
|
||
## 阶段1: 反思
|
||
|
||
### 1.1 定义反思范围
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 对象 | 认知作战室项目质量 |
|
||
| 触发 | 用户反馈质量不行 |
|
||
| 期望 | 找到真正问题，制定改进方案 |
|
||
| 范围 | 整个项目周期（约3天） |
|
||
|
||
### 1.2 收集信息
|
||
|
||
| 信息 | 数据 |
|
||
|------|------|
|
||
| 代码量 | ~34,000 行 |
|
||
| 测试数 | 726 个 |
|
||
| 测试通过率 | 100% |
|
||
| Git 提交 | 123 次 |
|
||
| 需求文档 | 31 个 |
|
||
|
||
### 1.3 第一层：问题审视
|
||
|
||
| # | 问题 | 证据 | 影响 |
|
||
|---|------|------|------|
|
||
| 1 | 测试太松，只覆盖 Happy Path | 没有边界测试、对抗性测试 | bug 漏到生产 |
|
||
| 2 | 服务堆砌，职责不清 | 71 个服务文件，命名相似 | 维护困难 |
|
||
| 3 | Agent 实现只是占位符 | evaluate_importance 只做简单计算 | 核心功能未实现 |
|
||
| 4 | tasks.md 状态未更新 | 全是 [ ] 但代码已写完 | 文档与代码脱节 |
|
||
|
||
### 1.4 第二层：系统审视
|
||
|
||
**输入分析**：
|
||
- 需求文档有，但可能没有真正理解
|
||
- 设计文档有，但可能没有严格遵循
|
||
|
||
**处理分析**：
|
||
- 测试设计由开发者自己完成，缺乏独立验证
|
||
- 没有架构审查环节
|
||
- 6A 流程有，但执行打折扣
|
||
|
||
**输出分析**：
|
||
- 输出标准（测试全通过）太弱
|
||
- 没有质量维度的验收
|
||
|
||
**反馈分析**：
|
||
- 主要靠用户反馈发现问题
|
||
- 内部反馈机制缺失
|
||
|
||
**根因识别**：
|
||
|
||
| 问题 | 系统根因 |
|
||
|------|----------|
|
||
| 测试太松 | 测试者 = 实现者，缺乏独立验证机制 |
|
||
| 服务堆砌 | 没有架构审查流程，各自为政 |
|
||
| Agent 占位符 | 核心 AI 能力未纳入验收标准 |
|
||
| 文档脱节 | 任务状态更新没有强制要求 |
|
||
|
||
### 1.5 第三层：角色审视
|
||
|
||
**角色识别**：
|
||
|
||
| 角色 | 责任 | 做到了吗 |
|
||
|------|------|----------|
|
||
| Tech Lead（协调者） | 严格审查、质量把关、架构治理 | ❌ 没有严格审查 |
|
||
| Reviewer（审查者） | 验收质量、发现问题 | ❌ 只看测试结果 |
|
||
| Executor（执行者） | 完成任务 | ✅ 任务完成 |
|
||
|
||
**角色冲突**：
|
||
- 执行者 vs 审查者：我既在做又在审，缺乏独立视角
|
||
|
||
**自我问题**：
|
||
|
||
| 层面 | 问题 |
|
||
|------|------|
|
||
| 心态 | 把"完成"放在"质量"之前；怕影响进度不愿打回 |
|
||
| 行为 | 只看测试结果不看测试质量；没有主动发现问题 |
|
||
| 能力 | 缺乏代码审查能力；缺乏架构评估能力 |
|
||
|
||
### 1.6 反思报告
|
||
|
||
**核心发现**：
|
||
1. **现象**：726 个测试全通过，但质量不行
|
||
2. **根因**：验证者与实现者同源，缺乏独立视角
|
||
3. **我的问题**：作为 Tech Lead，没有尽到审查责任
|
||
|
||
---
|
||
|
||
## 阶段2: 计划
|
||
|
||
### 2.1 第一层：直接修复
|
||
|
||
| 问题 | 方案 | 时间 |
|
||
|------|------|------|
|
||
| 测试太松 | 运行变异测试，补充边界测试 | 4天 |
|
||
| 服务堆砌 | 服务审计，合并重复 | 5天 |
|
||
| Agent 占位符 | 实现真正的 LLM 调用 | 5天 |
|
||
| 文档脱节 | 同步 tasks.md 状态 | 1天 |
|
||
|
||
### 2.2 第二层：系统改进
|
||
|
||
| 根因 | 改进 |
|
||
|------|------|
|
||
| 测试者=实现者 | 修改 test-design skill，强制要求对抗性测试 |
|
||
| 没有架构审查 | 建立 服务注册表，新服务必须审核 |
|
||
| 任务状态没更新 | Git commit 必须关联 Task 编号 |
|
||
| E2E Agent 未介入 | 强制 E2E 验收，不合格打回 |
|
||
|
||
### 2.3 第三层：自我改变
|
||
|
||
| 问题 | 改变 | 固化方式 |
|
||
|------|------|----------|
|
||
| 心态：进度>质量 | 明确"质量>进度"原则 | 写入 SOUL.md |
|
||
| 行为：不严格审查 | 建立验收检查清单 | 建立检查清单 |
|
||
| 能力：不懂审查 | 学习代码审查方法论 | 学习计划 |
|
||
|
||
### 2.4 优先级
|
||
|
||
| 优先级 | 行动 |
|
||
|--------|------|
|
||
| P0 | 升级 SOUL.md（改变自己是一切前提） |
|
||
| P0 | 运行变异测试（立即暴露问题） |
|
||
| P1 | 修改 test-design skill |
|
||
| P1 | 服务/模型审计 |
|
||
| P2 | Agent 实现完善 |
|
||
|
||
---
|
||
|
||
## 阶段3: 执行
|
||
|
||
### 执行记录（示例）
|
||
|
||
#### Task 1: 升级 SOUL.md
|
||
- 状态：✅ 完成
|
||
- 结果：添加了质量原则、验收检查清单
|
||
- commit: abc123
|
||
|
||
#### Task 2: 运行变异测试
|
||
- 状态：✅ 完成
|
||
- 结果：存活率 45%，发现 12 个测试盲区
|
||
- 产出：变异测试报告
|
||
|
||
#### Task 3: 修改 test-design skill
|
||
- 状态：✅ 完成
|
||
- 结果：添加了对抗性测试要求
|
||
- commit: def456
|
||
|
||
---
|
||
|
||
## 阶段4: 验证
|
||
|
||
### 4.1 问题解决情况
|
||
|
||
| 问题 | 解决了吗 | 证据 |
|
||
|------|----------|------|
|
||
| 测试太松 | ⚠️ 部分解决 | 变异存活率 45%→25% |
|
||
| 服务堆砌 | ✅ 解决 | 服务从 71→58 |
|
||
| Agent 占位符 | 🔄 进行中 | GeneralStaff 已实现 |
|
||
| 文档脱节 | ✅ 解决 | tasks.md 已同步 |
|
||
|
||
### 4.2 系统改进评估
|
||
|
||
| 改进 | 执行情况 | 效果 |
|
||
|------|----------|------|
|
||
| 对抗性测试要求 | 已加入 test-design | 新测试质量提升 |
|
||
| 服务注册表 | 已建立 | 防止重复创建 |
|
||
| Git commit 规范 | 已执行 | 可追溯 |
|
||
|
||
### 4.3 自我改变评估
|
||
|
||
| 改变 | 执行情况 | 证据 |
|
||
|------|----------|------|
|
||
| 质量>进度 | 执行中 | 打回了 3 个任务 |
|
||
| 验收检查清单 | 已建立 | 每次验收前执行 |
|
||
| 代码审查学习 | 进行中 | 阅读中 |
|
||
|
||
### 4.4 新发现的问题
|
||
|
||
- 对抗性测试增加了 50% 审查时间，需要平衡
|
||
- 服务注册表注册不够及时
|
||
|
||
---
|
||
|
||
## 阶段5: 固化
|
||
|
||
### 5.1 更新的原则
|
||
|
||
```markdown
|
||
## 质量原则
|
||
|
||
1. 质量 > 进度
|
||
2. 真正好 > 看起来好
|
||
3. 主动发现 > 被动等待
|
||
```
|
||
|
||
### 5.2 更新的流程
|
||
|
||
```markdown
|
||
## 测试设计必须包含
|
||
|
||
1. Happy Path 场景
|
||
2. 边界场景
|
||
3. 异常场景
|
||
4. 对抗场景（必须）
|
||
```
|
||
|
||
### 5.3 检查清单
|
||
|
||
```markdown
|
||
## 验收检查清单
|
||
|
||
### 代码审查
|
||
- [ ] 逻辑正确
|
||
- [ ] 命名清晰
|
||
- [ ] 无重复
|
||
|
||
### 测试审查
|
||
- [ ] Happy Path
|
||
- [ ] 边界场景
|
||
- [ ] 对抗场景
|
||
```
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
### 关键发现
|
||
|
||
1. **三层框架有效** - 从问题到系统到自己，层层深入
|
||
2. **角色冲突是根因** - 执行者和审查者同源
|
||
3. **系统改进要固化** - 不固化就会遗忘
|
||
|
||
### 可复用模式
|
||
|
||
1. 收到负面反馈 → 立即启动三层反思
|
||
2. 发现重复问题 → 检查是否系统机制问题
|
||
3. 完成改进 → 必须固化到文档/流程
|
||
|
||
---
|
||
|
||
*案例记录于 2026-02-25*
|