科技Bestblogs·腾讯技术工程··AI 生成
从 Vibe Coding 到 Harness—— 一套大仓 AI 工程化实战
文章分享了在某大型跨仓库工程（30+微服务、10+前端微应用）中，从随性的Vibe Coding进化到结构化AI工程化体系Harness的全过程。核心不是让AI更聪明，而是建立流程纪律与可审计性——设计了13个独立阶段、4个分工Agent、7道门禁脚本来约束AI，并保留了关键人工节点。对正在建设AI协作流程的团队有直接可迁移的参考价值。原文 ↗原文 ↗
核心观点
- ▍大仓AI工程化的核心不是让AI更聪明，而是建立流程纪律与可审计性；Harness的目标是让AI稳定、规范、可审计地将事情做对。
- ▍能写成脚本的约束就不留在Rule中，能判定的事就不让AI解释执行；自然语言Rule易被绕过，下沉为可判定脚本将‘完成’定义权从AI手中拿回。
- 01Harness由Rule、Skill、4个Sub Agent、13阶段Workflow、7道门禁Scripts和MCP组成，围绕30+微服务、10+前端微应用的真实TAB平台大仓构建。
- 0213个阶段不可合并，因为每个阶段对应独立的失败模式和回退位置；合并将丢失精细回滚能力。
- 03Agent从单Agent演进为4个角色（总控、设计、实现、验证），解决了上下文混杂、缺乏制衡、Token爆炸问题。
- 04人工关卡采用半自动设计，关键节点必须留人，交互密度硬约束为‘不能让人每分钟点一次以上’，防止团队绕过工具。
- 057道门禁脚本通过开发前基线对比来阻断新增失败，剥夺AI对失败的解释权；软门禁虽不阻断但会在产物中留下警告式‘伤疤’。
- 06Team Mode卡死的根因被定位为：消息路由到了已结束对话的主Agent，而非当前活跃的子Agent。
- 07工程纪律包括‘能写成bash的就别让Agent跑’、‘让偷懒变得醒目’——通过可视化伤疤使AI难以无痕绕过约束。
反方 / 局限
- — 作者承认，当前设计对设计阶段的质量依赖较重——如果底层设计Agent产出有根本性偏差，后续所有阶段的工作都可能需要回滚。
- — Harness当前主要适配PRD清晰的规范性工程（如功能开发），对于纯探索性、需求极模糊的原型研发场景，这套重流程框架可能反而降低灵活性。
概念锚点
前置背景
平行视角
未来推演
延伸追问