腾讯 TAB Harness 全链路实战：从 Vibe Coding 到 13 阶段接力赛¶
Ch05.109 腾讯 TAB Harness 全链路实战：从 Vibe Coding 到 13 阶段接力赛¶
📊 Level ⭐⭐ | 5.0KB |
entities/tencent-tab-harness-production-practice.md
腾讯 TAB Harness 全链路实战：从 Vibe Coding 到 13 阶段接力赛¶
腾讯 TAB（A/B 实验平台）团队完整复盘 Harness 搭建过程。30+ 微服务、10+ 前端微应用大仓的真实落地案例。1
核心定位¶
Harness 主要不是给 AI 用的，是给团队用的。目标是让 AI 在复杂工程里稳定、规范、可被审计地把事情做对。AI 的瓶颈不是模型，是协作、流程、信任。1
Harness 六层资产概览¶
| 层 | TAB 形态 | 关键数字 |
|---|---|---|
| Rule | 最少（能判定的全下沉） | ~0 独立 Rule |
| Skill | 标准操作手册，按需加载 | 11 个，4 组 |
| Sub Agent | 接力关系（非协商） | 4 个 + 1 总控 |
| Workflow | 13 阶段接力赛 | 每个阶段有独立失败模式 |
| Scripts | 7 道门禁（3 硬 + 4 软） | 含基线对比反作弊 |
| MCP | 外部系统受控接口 | 5 个（TAPD/iWiki/工蜂/Knot/企微） |
与 Harness Engineering 互补——该实体是通用框架，本实体是 30+ 微服务业务大仓的完整生产级实现。
核心方法论¶
4 个 Agent 的分工与演进¶
- 需求 Agent — TAPD → 需求理解 + 影响半径分析
- 方案 Agent — 需求 → 技术方案 + 任务清单
- 开发 Agent — 业务代码 + 单测 + 接口用例文档 + 增量接口测试代码
- 代码审查 Agent — 4 维度审查（方案一致性/验收覆盖/质量基线/前端增量）
核心纪律：下游 Agent 不可直接修改上游产物（只能提阻塞项）。1
13 阶段工作流¶
初始化 → 需求分析 → [需求确认] → [Bug 复现] → 技术方案 → [方案确认] → 方案评审 → 分支准备 → 开发 → 集成测试 → 代码审查 → 验收 → 交付收尾
关键决策：集成测试前置到代码审查之前（CR 打回率 1.8→0.4）。1
7 道门禁脚本¶
- 硬门禁（3 道）：静态检查+安全扫描 / 沙箱部署 / 接口测试
- 软门禁（4 道）：覆盖率检查 / 制品一致性 / 前端冒烟 / 日志验收
- 反作弊设计：基线快照 → 增量差异对比，剥夺 AI "这是历史问题"解释权
- 软门禁伤疤：失败不阻断但留警告痕迹，CR 必然读到
人工关卡（5 个半自动节点）¶
| 关卡 | 耗时 | 频率 |
|---|---|---|
| 需求确认 | 10~30s | 每个需求 1 次 |
| 方案确认 | 30~60s | ~40% |
| 方案评审打回 | 1~2min | <10% |
| 前端冒烟选择 | 5s | 前端时触发 |
| 熔断暂停 | — | 异常 |
三级兜底：UI 按钮 → 文本关键词 → 语义识别
关键撞墙：Team Mode 卡死¶
"复杂度自给自足"陷阱 — Team Mode 的存在主要为了 fix 自己引入的副作用。决策：彻底删除 Team Mode，改用项目级子 Agent + 同步阻塞调用，删 200+ 行代码问题消失。1
项目级记忆（两层）¶
- 仓库代码导航地图（~26KB）：由开发 Agent 自维护
- 任务看板（CheckPoint）：跨需求总控
纪律：团队知识必须落仓库（可审计可交接）；Memory 只放个人偏好。1
实测数据（50+ 需求）¶
| 指标 | 当前值 |
|---|---|
| 端到端耗时 | 30~75 min |
| 人工介入 | 2~3 次 |
| 集成测试一次通过率 | ~70% |
| CR 阻塞率 | ~25% |
| 平均打回次数 | 0.4 次（前置前 1.8） |
与已有实体的关系¶
- Harness Engineering — 上位框架；本实体是 30+ 微服务大仓的完整生产级实现
- 腾讯 CDN LEGO Harness 工程 — 互补：前者聚焦 C++ 高风险后端系统，本实体聚焦 Go/Ts 微服务业务平台
- Harness 知识沉淀实践 — 互补：知识管理维度不同
- Harness 10 步路线图 — 互补：抽象方法论 vs 真实案例
参考¶
→ [raw/articles/LGo7daiYYRf1r_YY3r-cXw|原文存档]