作者：fitchzheng、leoshli

这是一篇聚焦于后端微服务架构与前端微应用在Monorepo大仓环境下，如何落地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实验平台——产品同学通过它创建实验、配置用户群、设定评估指标以及进行灰度放量，背后由一整套从实验编排到效果统计的服务体系支撑。从技术角度看，它具有以下几个显著特征：

它的真实复杂度在于。

1.2 Harness 在 TAB 上