一个人 + AI 的团队，开发测试体系怎么建

一、数据管道：先设计再编码#

任何新数据源接入，数据要经过 6 个阶段流动：

1
拉取 → 解析 → 清洗 → 计算 → 评分 → 渲染

铁律：不能在最后一个阶段（渲染）才发现第一个阶段（拉取）的问题。每一段出口放一个检查点（详见数据管道六阶段验证）。

二、API 契约先行#

前后端最容易扯皮的是”字段名对不上”。解法是契约先行：

设计阶段先写出请求/响应的 JSON 形状，前后端各自确认，再开始编码。

禁止”后端写完让前端适配”或”前端写完让后端照着返回”。契约文件就是你们的产品需求文档。

三、三层测试架构#

没有 QA，就把”测试职责”拆成三层，每层负责一类问题：

1
Layer 3：用户视角（浏览器自动化，走真实网关）
2
  ├─ 每页截图存档
3
  ├─ 验证渲染出来的值正确（不是"元素存在"）
4
  └─ 跨页面导航完整走通
5

6
Layer 2：全链路追踪（浏览器抓网络请求）
7
  ├─ 用户点击 → 前端 → HTTP → 网关 → 后端 → 数据库
8
  └─ 验证每一步的 URL、响应码、内容类型
9

10
Layer 1：后端单元 + 接口集成（自动化测试）
11
  ├─ 接口形状验证（响应里关键字段都在）
12
  ├─ 字段名一致性验证
13
  └─ 边界条件

三层缺一不可：Layer 1 证明”接口返回对”，Layer 2 证明”网关转发对”，Layer 3 证明”用户看得到对”。只测一层就宣布”修好了”，是”声称修复但用户看不到”的最常见来源。

四、修复验证清单（每次改 bug 必须过）#

修完任何一个 bug，逐项打勾：

• Layer 1：接口返回正确数据？
• Layer 2：网关代理正常？
• Layer 3：用户能看到正确内容？
• 所有页面都验证（不只改的那一页）
• 所有角色/分组都验证（不只默认的那个）
• 每个按钮点击有效果
• 截图存档作为证据

重点看两条：

1. “所有 X”类验证：很多 bug 只修了”默认的那个”——默认页面修了，其他页面还坏；默认分组测了，其他分组没测。一次改动必须验证所有实例。
2. 截图存档：没有证据的”应该好了”，等于没修。

五、bug 修复的层次思维#

业务系统的数据通常是分层的（全局 / 分组 / 个人）。修 bug 时：

1
发现 bug → 确认影响范围 → 检查所有层级 → 修复 → 验证所有层级

禁止：修完一个层级就声称”修好了”。全局改对了，分组和个人可能还是旧的。

六、部署链路检查#

从代码到线上，中间每一步都可能出错：

1
产出 → 语法检查 → 检查外部依赖 → 检查路径 → 对接数据 → 部署 → 走网关验证

具体的坑：脚本语法错误、引用了境外 CDN、用了绝对路径、字段名前后端不一致。每一项都有对应的自动化检查。

结论#

一人 + AI 团队的本质，是把团队的分工写成制度，用工具执行：

• 数据管道检查点 = 数据正确性的”代码审查”
• API 契约 = 前后端的”需求文档”
• 三层测试 = 你的”测试同事”
• 修复验证清单 = 你的”验收人”

一个人做事，最怕的是”自己觉得没问题”。制度就是那个说”你不许觉得没问题”的人。

没有团队，就给自己造一个虚拟团队——分工、流程、验收标准一个不少。这正是 Agent 时代一个人能顶一个团队的关键。