从Vibe Coding到Harness—— 一套大仓AI工程化实战¶

Ch05.106 从Vibe Coding到Harness—— 一套大仓AI工程化实战¶

📊 Level ⭐⭐ | 5.2KB | entities/从vibe-coding到harness-一套大仓ai工程化实战.md

从Vibe Coding到Harness—— 一套大仓AI工程化实战¶

作者：fitchzheng、leoshli

一篇属于后端微服务 + 前端微应用大仓的 Harness 实战分享。 不讲理念有多重要，只讲我们这一路是怎么搭起来、怎么撞墙、撞完怎么补的。

写在前面¶

这篇文章想聊的是一件具体的事：怎么让 AI 在一个真实的、跨多个仓库的前后端业务工程里稳定地跑完一个需求 。

现在大家手里都有越来越强的模型，但只要你试过让 AI 独立做完一个完整的产品需求——从产品那条 TAPD 单子开始，到方案落地、代码改完、接口跑通、CR 通过、最后 MR 提到工蜂上——你就会发现一件事：模型够强了，工程没跟上 。AI 一个人跑不完，因为整条链路上太多事不是"写代码"本身，而是协作、流程、信任、收口。

我们 TAB 实验平台是一个典型的前后端业务为主的技术平台 ：拥有超过30+的微服务、10+ 个前端微应用、各平台SDK库，我们把它们集成在整个大仓做统一管理，然后用沙箱做集成验证、用TAPD 管各种需求输入、iWiki 沉淀方案、工蜂托管代码等等。在这种工程里搭建 Harness，会遇到一组很实在的一些挑战，比如：

• 你可能有时不是改一个仓库，是同时动可能跨 5 个 submodule 的代码
• 你不仅是验证一个功能是否跑得起来，是要拉沙箱、刷 schema、起 Redis、跑真实 HTTP 接口测试，是让整个功能能够真正放心上线
• 你不是面对一份本地用户文档，是面对 TAPD 单 + iWiki 文档 + 工蜂 MR + Knot知识库管理的四套外部输入输出系统
• .......

我们花了一段时间把这套 Harness 慢慢搭起来。这一路上踩了不少坑、撞了不少墙、删过不少自以为正确的设计。这篇文章把这些经验完整复盘一遍，希望对正在做类似事情的同学有用。

全文阅读约 25 分钟。  一共 10 小节，按"先讲项目 → 再讲方法论 → 再讲撞墙 → 最后讲取舍"的顺序展开。如果时间紧，可以直接跳到第六章（门禁脚本）和第七章（Team Mode 撞墙复盘）——这两章的密度最高、踩坑最深，对其他团队可能也最有参考价值。

第一章：TAB工程背景¶

在讲我们怎么搭 Harness 之前，必须先让你知道我们在搭什么样的工程上。否则后面所有取舍都没法理解——同样一套方法论，落在不同工程上长出来的样子会差很多。

1.1 TAB 工程画像¶

TAB 是公司内部的 A/B 实验平台 ——产品同学发起一个实验、配人群、配指标、灰度推全，背后是一整套从实验编排到效果统计的服务体系。技术上它有几个显著特征：

主语言| Go、Ts语言为主，同时融合各平台SDK技术栈，以及少量 Python 工具链

架构分层| 胶水层（协议↔领域对象转换）→ 接口层 → 服务层 → 领域层（数据访问 + 领域模型）

横切关注点| 7 个切面顺序串成一条链：错误 → 日志 → 数据库上下文 → 鉴权 → 参数校验 → 事务 → 出参整形

验证手段| 一键拉起完整沙箱环境（Docker Compose），数据库 / 缓存全新初始化，可跑真实 HTTP

外部协作| TAPD 管需求单、iWiki 沉淀制品方案、工蜂托管代码 + + Kont知识库管理 + MR、企微通知等

它的真实复杂度

→ 原文存档

关联¶

• 相关概念: Harness Engineering