jnmetacode--agency-agents-zh/strategy/playbooks/phase-4-hardening.md

# 第 4 阶段手册 — 质量与加固

> **时长**：3-7 天 | **智能体**：8 个 | **守门人**：现实检验者（唯一权威）

---

## 目标

最后的质量考验。现实检验者默认判定是"需要改进"——你必须用压倒性的证据来证明可以上生产。这个阶段存在的意义是：首次实现通常需要 2-3 轮修改，这很正常。

## 前提条件

- [ ] 第 3 阶段质量门禁通过（所有任务都 QA 过）
- [ ] 收到第 3 阶段交接包
- [ ] 所有功能已实现并单独验证

## 关键心态

> **现实检验者的默认判定是"需要改进"。**
>
> 这不是悲观——是务实。上生产需要：
> - 完整的用户旅程端到端跑通
> - 跨设备一致性（桌面、平板、手机）
> - 压力下的性能表现（不只是正常情况）
> - 安全验证（不是"我们加了认证"就行）
> - 需求合规（每条需求都满足，不是大部分）
>
> 第一轮拿 B/B+ 是正常的。

## 智能体激活顺序

### 第一步：证据收集（第 1-2 天，全部并行）

#### 证据收集者 — 全面视觉证据
```
激活证据收集者，为 [项目] 做全面系统证据收集。

交付要求：
1. 完整截图套件：
   - 桌面端（1920x1080）— 每个页面/视图
   - 平板（768x1024）— 每个页面/视图
   - 手机（375x667）— 每个页面/视图
2. 交互证据：
   - 导航流程（点击前后）
   - 表单交互（空白、填写、提交、错误状态）
   - 弹窗/对话框交互
   - 手风琴/可展开内容
3. 主题证据：
   - 亮色模式 — 所有页面
   - 暗色模式 — 所有页面
   - 系统偏好检测
4. 错误状态证据：
   - 404 页面
   - 表单校验错误
   - 网络错误处理
   - 空状态

格式：截图证据包 + test-results.json
时间线：2 天
```

#### API 测试员 — 全量 API 回归
```
激活 API 测试员，为 [项目] 做完整的 API 回归测试。

交付要求：
1. 端点回归套件：
   - 所有端点测试（GET, POST, PUT, DELETE）
   - 认证/授权验证
   - 输入校验测试
   - 错误响应验证
2. 集成测试：
   - 服务间通信
   - 数据库操作验证
   - 外部 API 集成
3. 边界情况测试：
   - 限流行为
   - 大负载处理
   - 并发请求处理
   - 畸形输入处理

格式：API 测试报告，每个端点通过/不通过
时间线：2 天
```

#### 性能基准师 — 压力测试
```
激活性能基准师，为 [项目] 做压力测试。

交付要求：
1. 10 倍预期流量的压力测试：
   - 响应时间分布（P50, P95, P99）
   - 压力下的吞吐量
   - 压力下的错误率
   - 资源消耗（CPU、内存、网络）
2. Core Web Vitals 测量：
   - LCP（最大内容绘制）< 2.5s
   - FID（首次输入延迟）< 100ms
   - CLS（累积布局偏移）< 0.1
3. 数据库性能：
   - 查询执行时间
   - 连接池使用率
   - 索引有效性
4. 极限测试结果：
   - 找到系统断点
   - 优雅降级行为
   - 过载后恢复时间

格式：性能认证报告
时间线：2 天
```

#### 法务合规员 — 最终合规审计
```
激活法务合规员，为 [项目] 做最终合规审计。

交付要求：
1. 隐私合规验证：
   - 隐私政策准确性
   - 知情同意管理功能
   - 用户数据权利实现
   - Cookie 同意实现
2. 安全合规：
   - 数据加密（静态和传输中）
   - 认证安全性
   - 输入过滤
   - OWASP Top 10 检查
3. 监管合规：
   - GDPR 要求（如适用）
   - CCPA 要求（如适用）
   - 行业特定要求
4. 无障碍合规：
   - WCAG 2.1 AA 验证
   - 屏幕阅读器兼容性
   - 键盘导航

格式：合规认证报告
时间线：2 天
```

### 第二步：分析（第 3-4 天，并行，第一步完成后）

#### 测试结果分析师 — 质量指标汇总
```
激活测试结果分析师，为 [项目] 做质量指标汇总。

输入：第一步的全部报告
交付要求：
1. 汇总质量仪表盘：
   - 总体质量评分
   - 分类明细（视觉、功能、性能、安全、合规）
   - 问题严重度分布
   - 趋势分析（如果有多轮测试）
2. 问题优先级排序：
   - 严重问题（上生产前必须修）
   - 高优问题（上生产前应该修）
   - 中等问题（下个 Sprint 修）
   - 低优问题（加到待办列表）
3. 风险评估：
   - 上生产就绪概率
   - 剩余风险区域
   - 建议的缓解措施

格式：质量指标仪表盘
时间线：1 天
```

#### 工作流优化师 — 流程效率复盘
```
激活工作流优化师，为 [项目] 做流程效率复盘。

输入：第 3 阶段执行数据 + 第一步的发现
交付要求：
1. 流程效率分析：
   - 开发-测试循环效率（首次通过率、平均重试次数）
   - 瓶颈识别
   - 不同问题类型的解决耗时
2. 改进建议：
   - 第 6 阶段运营的流程改进
   - 自动化机会
   - 质量改进建议

格式：优化建议报告
时间线：1 天
```

#### 基础设施运维师 — 生产就绪检查
```
激活基础设施运维师，为 [项目] 做生产就绪检查。

交付要求：
1. 生产环境验证：
   - 所有服务健康且有响应
   - 自动伸缩已配置并测试
   - 负载均衡配置已验证
   - SSL/TLS 证书有效
2. 监控验证：
   - 所有关键指标在收集
   - 告警规则已配置并测试
   - 仪表盘访问已验证
   - 日志聚合正常
3. 灾难恢复验证：
   - 备份系统可用
   - 恢复流程已文档化并测试
   - 故障切换机制已验证
4. 安全验证：
   - 防火墙规则已审查
   - 访问控制已验证
   - 密钥管理已确认
   - 漏洞扫描通过

格式：基础设施就绪报告
时间线：1 天
```

### 第三步：最终判定（第 5-7 天，串行）

#### 现实检验者 — 最终判定
```
激活现实检验者，为 [项目] 做最终集成测试。

以下流程不能跳过：

第一步：现实检查命令
- 验证实际做出了什么（ls, grep 检查声称的功能）
- 声称的功能与需求文档交叉核对
- 跑一遍全面的截图采集
- 审查第一步和第二步的所有证据

第二步：QA 交叉验证
- 审查证据收集者的发现
- 与 API 测试员结果交叉核对
- 验证性能基准师数据
- 确认法务合规员的发现

第三步：端到端系统验证
- 测试完整用户旅程（不是单个功能）
- 在所有设备上验证响应式行为
- 端到端检查交互流程
- 审查实际性能数据

第四步：需求对照检查
- 引用原始需求文档的原文
- 与实际实现证据对照
- 记录需求与现实之间的每一个差距
- 不做假设——只看证据

判定选项：
- 就绪：压倒性的证据表明可以上生产（首次通过很少见）
- 需要改进：发现具体问题，附修复清单（正常情况）
- 未就绪：架构层面有大问题，需要回到第 1/2 阶段

格式：基于现实的集成报告
默认：需要改进——除非有相反的压倒性证据
```

## 质量门禁 — 最终关卡

| # | 标准 | 阈值 | 需要的证据 |
|---|------|------|-----------|
| 1 | 用户旅程完整 | 所有关键路径端到端跑通 | 现实检验者截图 |
| 2 | 跨设备一致性 | 桌面 + 平板 + 手机都正常 | 响应式截图 |
| 3 | 性能认证通过 | P95 < 200ms, LCP < 2.5s, 可用性 > 99.9% | 性能基准师报告 |
| 4 | 安全验证通过 | 零严重漏洞 | 安全扫描 + 合规报告 |
| 5 | 合规认证通过 | 所有监管要求都满足 | 法务合规员报告 |
| 6 | 需求合规 | 100% 的需求都实现了 | 逐条验证 |
| 7 | 基础设施就绪 | 生产环境已验证 | 基础设施运维师报告 |

## 门禁决策

**唯一权威**：现实检验者

### 如果判定"就绪"（进入第 5 阶段）：
```markdown
## 第 4 阶段 → 第 5 阶段交接包

### 给上线团队的：
- 现实检验者认证报告
- 性能认证
- 合规认证
- 基础设施就绪报告
- 已知限制（如果有的话）

### 给增长黑客的：
- 产品已可交付用户
- 营销话术用的功能列表
- 增加可信度的性能数据

### 给 DevOps 自动化师的：
- 生产部署已批准
- 蓝绿部署方案
- 回滚流程已确认
```

### 如果判定"需要改进"（回到第 3 阶段）：
```markdown
## 第 4 阶段 → 第 3 阶段返工包

### 修复清单（来自现实检验者）：
1. [严重问题 1]：[描述 + 证据 + 修复说明]
2. [严重问题 2]：[描述 + 证据 + 修复说明]
3. [高优问题 1]：[描述 + 证据 + 修复说明]
...

### 流程：
- 问题进入开发-测试循环（第 3 阶段机制）
- 每个修复都要通过证据收集者 QA
- 所有修复完成后 → 回到第 4 阶段第三步
- 现实检验者用更新后的证据重新评估

### 预期：2-3 轮修改是正常的
```

### 如果判定"未就绪"（回到第 1/2 阶段）：
```markdown
## 第 4 阶段 → 第 1/2 阶段返工包

### 发现的架构问题：
1. [根本性问题]：[为什么第 3 阶段修不了]
2. [结构性问题]：[架构层面需要改什么]

### 建议行动：
- [ ] 修改系统架构（第 1 阶段）
- [ ] 重建基础（第 2 阶段）
- [ ] 缩小范围重新定义（第 1 阶段）

### 需要工作室制片人决策
```

---

*当现实检验者给出"就绪"判定且有压倒性证据时，第 4 阶段结束。"需要改进"是首轮预期的正常结果——说明系统在跑，但还需要打磨。*