从对话式AI Coding到Harness Engineering，业务系统的端到端AI工程落地实践

当下AI辅助开发已经成为研发团队的标配能力绝大多数开发者都在用对话式AI Coding完成日常编码工作。借助CodeBuddy等工具简单接口开发、代码改写、逻辑补全这类零散需求确实能实现效率翻倍提升。但在我们团队落地应用宝活动平台全量重构项目时却深刻感受到一个核心痛点单纯的对话式AI编码只适合碎片化、轻量化的开发场景一旦面对规模化、复杂化的企业级微服务系统传统AI Coding的短板会被无限放大。应用宝活动平台承载着APP、PC端、手机助手等全渠道产品的日常运营与节假日营销活动后台覆盖90多个微服务、多个独立业务域业务迭代频繁、链路错综复杂。在项目初期我们沿用行业通用的对话式AI开发模式依靠CodeBuddy Plan Mode、自定义Prompt规则、AI辅助编码加人工复审的流程推进开发。初期效率提升十分明显但随着项目推进、业务复杂度攀升各类工程问题集中爆发直接制约了研发效率与代码质量。也正是在这次系统重构的过程中我们接触并深入实践了Harness Engineering工程理念。不同于单点的AI编码提效Harness Engineering核心是搭建一套完整的AI工程体系把AI能力融入需求拆解、开发、测试、部署、验证的全研发链路。经过多轮迭代打磨我们团队搭建完成了基于知识库底座的端到端AI开发流程沉淀出适配复杂业务系统的工程落地经验本文将结合真实踩坑经历与实战成果完整分享这套从AI Coding到Harness工程化的演进之路。一、对话式AI Coding的瓶颈复杂业务场景下的必然困境很多团队停留在AI辅助开发的初级阶段普遍认为只要用好Prompt、配好规则就能实现AI全流程提效。但从我们的实战经验来看对话式AI Coding的本质是“单次对话、单次生效”这种模式天生适配小需求、一次性任务完全无法支撑大型业务系统的规模化迭代。在应用宝平台重构初期我们遇到的核心问题主要集中在四个维度。首先是单窗口上下文持续膨胀引发的精度衰减。为了让AI贴合团队代码规范、理解项目结构与业务逻辑我们会提前沉淀各类规则文档、业务背景资料每次对话都需要将这些内容灌入上下文。随着项目迭代规则文档、业务知识点不断累加还未输入具体开发需求上下文就已经承载了大量冗余信息。同时多轮对话迭代后窗口内信息持续堆积大模型会出现有损压缩问题频繁出现遗忘既定规则、忽略业务约束、生成代码不规范等问题后期纠错成本甚至远超AI编码节省的时间。其次是业务知识无法沉淀高度依赖人工输入。企业级业务系统的核心难点从来不是代码语法而是复杂的业务逻辑与服务依赖关系。应用宝活动平台涉及活动运营、用户权益、数据统计、配置下发等多个业务模块各微服务之间调用链路复杂。传统对话模式下AI没有自主认知业务的能力每一个新需求都需要研发人员手动梳理业务背景、服务依赖、接口关系再逐一对齐给AI。整个上下文构造过程极度耗费人力且本次对话沉淀的业务认知无法复用下次新需求、新对话窗口需要从零开始重复性工作极多。再者是研发链路不闭环AI能力仅局限于编码环节。一个完整的需求交付包含需求拆解、方案设计、编码开发、单元测试、环境部署、接口验证、代码提交等多个环节。传统AI Coding仅能覆盖编码步骤其余所有流程都需要人工手动操作。这就导致AI提效十分片面研发流程存在大量人工断点无法形成自动化闭环整体研发效能的提升十分有限。最后是单窗口串行执行无法适配多任务并行开发。复杂业务需求往往会拆解出多个独立的开发任务比如新增多个独立接口、迭代不同模块逻辑。单一对话窗口仅能串行执行任务只能逐个推进开发。如果开启多窗口并行研发人员需要频繁切换对话、对齐规则、同步进度不仅没有提升效率反而增加了沟通与管理成本。综上可以清晰看出任务越完整、流程越固定、业务越规模化单纯对话式AI Coding的弊端就越明显。这也是我们下定决心跳出单点AI编码全面落地Harness Engineering工程化体系的核心原因我们需要的不是一个会写代码的AI工具而是一套能自主适配业务、自动化跑完完整研发链路的AI工程系统。二、整体架构设计知识库工程与端到端开发工程双轮驱动结合应用宝活动平台的业务特性与前期踩坑经验我们搭建的Harness工程体系核心由两大核心能力构成分别是作为底座的知识库工程以及上层承载业务交付的端到端开发工程两者层层依赖、协同联动形成完整的AI研发闭环。知识库工程是整个体系的核心基石主要负责零散业务知识、技术规范、服务信息的结构化沉淀、自动更新与精准检索。我们将散落在代码仓库、项目文档、监控系统、历史迭代记录中的各类工程知识统一收拢按照标准化结构整理存储为上层所有AI研发环节提供稳定、准确、实时的业务上下文支撑。端到端开发工程则是体系的能力载体我们创新性引入状态文件驱动模式彻底摆脱对话历史的束缚。基于沉淀好的结构化知识库实现需求澄清、任务拆解、并行开发、单测校验、代码审查、环境部署、接口验证、代码提交的全流程自动化执行。在整套流程中研发人员无需全程介入仅需在核心决策节点完成确认与信息补全即可。经过完整迭代落地目前整套体系已沉淀800份结构化业务文档覆盖后台90余个微服务同时内置12个专业场景Agent、30余项业务技能Skill以及10套固定流程脚本完全具备支撑平台全量迭代需求的工程能力。三、知识库工程落地让AI真正读懂复杂业务体系在复杂企业级系统中AI开发的最大瓶颈从来不是模型编码能力而是缺失准确、完整、实时的业务知识。对话式AI Coding的核心缺陷就是没有长效知识沉淀机制AI每次开发都处于“从零认知业务”的状态。为此我们投入大量精力搭建结构化知识库工程解决知识规模大、检索不准、更新滞后三大行业难题。3.1 双层知识架构AI生成人工补充互补赋能企业业务知识分为两类一类是接口定义、代码逻辑、服务依赖、配置信息等可以从代码中自动解析的事实性知识另一类是架构决策、业务背景、历史坑点、跨服务流程等仅靠代码无法识别的经验性知识。基于此我们搭建了“AI自动生产人工精准补充AI高效消费”的闭环知识库体系。我们设计了清晰的知识库目录结构实现知识的分层管理核心目录如下llm-knowledge/ ├── backend/ │ ├── overview.md # 全局业务总览 │ ├── business/ # 各业务域知识 │ │ ├── private_domain/ # 商城会员域 │ │ ├── activity/ # 活动平台域 │ │ ├── yybgame/ # 福利平台域 │ │ │ ├── meta.yaml # 服务索引文件 │ │ │ ├── custom/ # 域级手工文档 │ │ │ └── service_name/ # 各服务独立知识目录 │ └── common/ # 公共知识库 │ ├── conventions/ # 开发规范 │ ├── lib_usage/ # 常用库使用指南 │ └── tech/ # 通用技术专题 └── .codebuddy/skills/ # 知识库自动化技能脚本整体分为全局总览、业务域、单服务三层结构同时明确两类文档的定位。人工沉淀文档主要存放于custom目录和common公共目录用来补充AI无法识别的业务经验、架构思考、开发避坑要点。AI自动生成文档则覆盖八大核心类型包括服务总览overview.md、接口文档interfaces.md、架构设计architecture.md、依赖关系dependencies.md、存储配置storage.md、动态配置config.md、开发坑点pitfalls.md和变更日志log.md全方位覆盖服务技术细节。两类文档地位等同检索时会同步纳入匹配范围兼顾知识的全面性与准确性。3.2 自动化知识流水线实现文档免维护更新为解决人工梳理文档工作量大、更新不及时的问题我们开发了两套核心Skill脚本分别是单服务文档生成的gen-project-docs和多服务批量生成的batch-doc-generator搭建起从代码到结构化文档的自动化流水线。脚本会以服务入口文件为起点通过代码导入链路追踪所有接口注册点结合go.mod文件解析Proto接口定义按照固定模板自动生成标准化文档。同时采用增量更新机制代码变更后仅更新接口参数、依赖关系等事实性内容完整保留人工补充的业务注释、避坑经验等高价值信息避免重复劳作。为区分有效接口与废弃接口我们接入伽利略监控系统获取接口近七日调用量数据在文档中精准标注接口活跃状态从源头避免AI调用过期接口的问题。同时通过meta.yaml作为服务注册中心记录各服务文档对应的代码版本哈希值系统会自动比对代码仓库当前版本与文档绑定版本判断是否需要触发增量更新确保知识时效性。对于全新接入的服务系统支持Git仓库一键导入自动完成克隆、文档生成、业务域归属匹配、索引更新的全流程自动化操作。3.3 渐进式分层检索替代传统RAG实现精准知识调用传统RAG检索依赖向量相似度匹配在复杂业务知识库中容易出现匹配不准、信息冗余、Token消耗过高的问题。我们摒弃传统检索模式采用贴合人类学习习惯的渐进式分层加载检索方案实现精准、轻量化的知识获取。检索流程分为三层递进逻辑第一层加载全局总览文档通过关键词快速锁定对应业务域缩小检索范围。第二层通过grep精准匹配meta.yaml服务索引过滤无关服务无需加载完整业务域文档。第三层根据检索场景按需加载对应类型文档比如接口检索场景仅加载接口文档不加载架构、存储等无关内容最大限度节省Token、提升检索效率。同时我们针对研发全场景设计了四种专属检索模式全方位适配不同开发需求。产品需求拆解模式可将自然语言PRD拆解为可执行后端任务明确涉及服务、改造点与可复用接口。技术方案拆解模式可自动生成时序图、任务拆解表与接口调用关系。接口搜索模式主打轻量高效快速定位目标接口。知识库问答模式可解答业务概念、表结构、逻辑细节等各类技术问题支持自动拉取代码溯源核实。3.4 新鲜度检测机制杜绝过期知识误导开发在工程实践中我们发现过期的错误知识比无知识的危害更大。项目早期曾出现过典型问题知识库未及时更新AI沿用过期接口逻辑开发整套代码链路无报错但最终无法实现业务效果团队耗费数小时才排查出是接口版本过期导致的问题。针对该问题我们搭建了完善的文档新鲜度检测机制核心通过双重哈希值比对实现。系统实时比对meta.yaml中记录的文档生成代码哈希值与代码仓库当前HEAD哈希值当版本差异超过预设阈值时自动标记文档过期并生成更新任务触发增量文档更新流程。整个更新过程严格遵循最小改动原则仅同步代码变更对应的文档内容完整保留人工沉淀的经验信息。同时通过log.md日志文件记录每一次文档更新包含版本哈希、更新时间、变更摘要严禁覆盖历史记录实现所有知识变更可追溯、可回滚彻底解决知识过期、版本错乱的问题。四、端到端开发工程重构从写代码到完整交付的能力升级扎实的结构化知识库为AI全流程研发提供了可靠的上下文底座而端到端开发工程则是依托底座实现的能力升级。我们彻底颠覆单对话窗口的开发模式通过状态文件驱动、专家Agent分工、DAG并行编排、脚本化执行、全DevOps链路打通将AI研发从“单点编码工具”升级为“全自动需求交付系统”真正实现从需求输入到代码提交的无人值守迭代。4.1 状态文件驱动让研发流程脱离对话窗口独立存续对话式开发的核心短板是流程完全依赖对话历史上下文膨胀、窗口关闭、会话中断都会导致所有进度丢失且流程无迹可查、无法复盘。我们通过结构化状态文件将研发进度、任务产出、依赖关系全部持久化让流程脱离对话独立存在实现可中断、可恢复、可观测、可复盘。整套体系采用两类核心状态文件管控全流程分别是product-state.json和e2e-state.json。product-state.json负责管控大型需求的拆解、多任务并行分叉、统一收口全流程记录整体需求的推进阶段与全局状态。e2e-state.json聚焦单个子任务的端到端开发记录当前所处阶段、各步骤产出成果、接口验证结果等细节信息。所有子Agent完成任务后都会将执行结果精准写入对应状态文件主调度器不依赖任何对话记忆仅通过读取状态文件判断当前进度与下一步动作。同时我们配套设计了完善的钩子机制通过Stop Hook防止流程提前终止SessionStart Hook实现断点续跑SessionEnd Hook清理会话残留状态彻底保障流程执行的确定性与稳定性。4.2 专家Agent体系单一职责隔离实现稳定作业早期我们尝试用单一Agent流转全流程实践中发现问题十分突出Agent角色频繁切换会导致行为不稳定容易出现越权修改、判断偏差等问题且不同研发步骤对模型推理能力的需求差异极大统一模型配置会造成资源浪费或能力不足。为此我们搭建了单一职责的专家Agent体系核心遵循四大设计原则分别是单一职责、上下文隔离、工具最小权限、结构化输入输出同时支持模型可插拔配置简单流程使用轻量化模型复杂推理流程使用高精度大模型。我们将完整研发流程拆解为规划、执行、验证、审查、集成五大类智能体覆盖全流程场景。规划类Agent负责需求拆解、方案设计、任务编排执行类Agent专注代码开发、协议修改、代码修复验证类Agent完成单测编写、接口校验、用例设计审查类Agent负责代码合规评审集成类Agent承接环境发布、代码提交、MR发起。所有Agent严格遵守职责边界评审Agent只评不改、开发Agent只按方案落地、验证Agent只诊断不修改通过角色固化、权限裁剪、上下文隔离彻底解决AI行为随机性强、不可控的问题同时内置标准化Prompt无需调度器临时配置大幅降低流程抖动概率。4.3 DAG并行编排与冲突治理大幅提升研发吞吐效率为解决传统串行开发效率低下的问题我们基于DAG拓扑编排和Fork-Join思想实现多任务、多需求的并行开发同时配套完善的冲突治理策略兼顾效率与稳定性。针对单个需求内的多任务并行我们通过task-planner智能体拆解所有开发任务精准识别任务间的依赖关系梳理各任务涉及的文件目录自动构建DAG拓扑分层结构。无依赖的同层级任务会分配独立Worktree工作空间由多个开发Agent同步并行执行所有任务完成后统一合并收口彻底告别单线程串行的低效模式。针对复杂大型需求我们采用Fork-Join并行架构先通过需求拆解将大需求拆分为多个独立子Story所有子Story同步执行任务拆解、开发、单测、评审全流程全部完成后统一进入合并、发布、验证、提交的串行收口阶段实现多需求高效并行交付。并行开发必然带来代码冲突问题我们针对四类核心冲突制定了精准的治理策略。文件合并冲突通过事前文件级隔离规避冲突发生后规范手动解决不跳过校验。入口文件等共享资源统一收敛到收口阶段串行修改避免多Agent同时编辑。Proto协议变更前置串行处理统一生成桩代码后再启动开发。数据库与配置变更统一前置汇总确认由专属Agent统一落地从机制上规避绝大多数并行冲突问题。4.4 脚本化确定性执行AI负责认知、脚本负责落地在流程复盘过程中我们发现研发链路中大量步骤属于无推理的确定性操作包括状态解析、工作空间创建、代码编译、环境部署、知识库初始化等。这类机械操作交给AI执行不仅消耗大量Token资源还容易出现语法错误、参数误用等随机性问题。基于此我们确立了核心工程准则AI专注需求分析、方案设计、问题排查等认知类工作所有确定性执行操作全部脚本化落地。目前我们已沉淀15套核心固定脚本覆盖全流程关键操作。其中e2e-dev.py脚本负责状态机解析与流程调度替代AI的人工判断。worktree.sh系列脚本统一管控多任务并行的工作空间创建、合并、清理操作。build-and-publish.sh实现服务编译发布一键执行。kb-init.sh完成知识库的自动化初始化与更新。脚本化改造后不仅彻底消除了确定性操作的随机性误差大幅提升流程稳定性还极大降低了Token消耗有效控制了AI研发的成本开销。4.5 全DevOps链路打通实现真正的端到端自动化真正的端到端AI工程不能仅局限于代码开发环节必须打通需求、开发、评审、部署、验证、运维的全DevOps链路。我们深度整合腾讯内部各类研发平台能力让AI无需人工转接即可完成全流程跨平台操作。通过接入tRPC-Gateway能力解决本地AI无法调用内网IDC服务的问题实现开发环境与线上服务的无缝联动。深度集成Codar代码评审工具AI生成代码后不仅可以依靠自身规则自查还能调用Codar流水线完成增量代码评审精准识别业务逻辑漏洞与隐性Bug问题自动反馈至修复Agent完成迭代优化。同时我们完成TAPD需求管理、Rick协议管理、123服务发布、七彩石配置管理、伽利略监控等全平台能力集成人工确认后AI可自动完成子需求创建、协议更新、服务发布、配置修改、日志查询等全系列操作彻底打通AI研发的最后一公里实现从需求接入到线上交付的完整闭环。五、实践复盘与行业思考AI工程化的核心逻辑与未来方向经过应用宝活动平台重构的完整落地打磨我们的Harness工程体系已经实现稳定可用完成了从“对话式AI编码”到“系统化AI工程”的跨越。在实战过程中我们沉淀了诸多可复用的工程经验也对AI研发的未来发展趋势有了更清晰的认知。5.1 核心工程复盘规避AI工程落地的常见误区在多轮迭代优化中我们总结出多条适配复杂业务系统的Harness工程落地原则也是我们踩坑后沉淀的核心经验。首先是必须适配异构服务拓扑复杂业务系统存在单仓单服务、单仓多服务、Monorepo等多种代码架构前期必须搭建统一的目录解析抽象层标准化后续处理流程避免后续适配调试成本激增。其次是调度架构的确定性优先我们彻底摒弃早期的主子Agent调度模式与Shell脚本驱动方式改用Go强类型代码编排全局流程通过强类型语言的严谨性杜绝流程失控、指令失效、隐性语法错误等问题保障长链路流程的稳定性。同时必须严格禁用全局记忆机制全局Memory会引发上下文串扰破坏任务的幂等性与可复现性导致Agent偏离既定职责在自动化流程体系中必须保证每一次任务执行的上下文纯粹独立。另外尽早引入Mock机制通过模拟大模型生成结果快速迭代验证调度链路大幅提升联调效率降低试错成本。从全局视角总结我们沉淀出六条核心工程铁律AI负责认知脚本负责执行长链路必须状态化知识库必须结构化Agent必须职责隔离执行步骤必须脚本化Workflow流程编排的确定性远胜于反复打磨Prompt。当下AI研发的核心竞争力早已不是模型能力而是规范化、体系化的AI工程架构。5.2 现存短板与优化方向目前我们的Harness工程体系仅完成“稳定可用”的基础目标距离“极致高效、自主进化”还有很大优化空间。整套系统目前缺乏自我复盘迭代能力流程问题仍依赖人工发现与修复。同时没有完善的量化评估体系无法精准统计流程稳定性、开发提效比例、Token消耗成本等核心指标。此外体系重度依赖CodeBuddy CLI工具尚未实现工程与工具的完全解耦通用性有待提升。针对这些短板我们正在借鉴Claude Workflow模式优化流程编排逻辑将原有AI主导的流程串联模式升级为脚本主导流程串联、AI按需提供认知能力的新模式进一步强化流程确定性降低AI随机性带来的影响。5.3 对AI研发趋势的深度思考在TDD开发模式的落地层面传统先写测试再写代码的模式在AI研发中难以落地业务接口、校验规则、逻辑边界往往需要代码落地后才能明确。我们探索出适配AI的TDD落地方式在需求方案设计阶段提前生成标准化测试用例明确输入输出预期后续自动化流程基于用例完成接口验证实现适配业务场景的测试驱动开发。在AI工程架构层面当下行业内仍缺乏成熟的Agent、Skill分层规范多数团队的AI工程架构只是简单的目录划分缺乏系统化的解耦与插拔设计。未来AI工程的核心比拼点不再是单一Agent的能力强弱而是整体架构的分层合理性、组件可复用性与体系可扩展性。最后是代码与架构的价值思考当下很多观点认为AI普及后开发者可以“忘记代码”无需逐行审码。但在高并发、高可用、强一致性的核心业务系统中高质量的代码架构依旧是核心底线。AI代码腐化速度极快无约束的自由迭代会快速偏离规范而优质的架构设计能反向赋能AI让生成代码更规范、更贴合业务。同时我们也看到差异化落地边界对于运营看板、数据展示、低容错的辅助系统完全可以采用Vibe Coding模式依靠AI全流程自主生成无需人工深度介入。但对于核心交易、活动营销等关键业务系统现阶段仍需要开发者守住架构与质量底线。未来随着AI工程体系的持续成熟人工介入的边界会持续后撤但工程架构的核心价值会愈发凸显。六、总结从零散的对话式AI Coding到体系化的Harness Engineering工程落地我们在应用宝活动平台的重构实践中完整验证了AI工程化的落地价值。单点AI编码只能实现局部效率提升而完整的Harness工程体系通过结构化知识库解决AI不懂业务的核心痛点通过状态化流程解决长链路不稳定问题通过多Agent分工与并行编排提升研发吞吐通过脚本化与全链路集成保障交付确定性。AI研发的下半场早已不是模型能力的竞争而是工程体系的竞争。真正的AI落地不是让AI替代开发者而是通过系统化的工程架构把AI的认知能力规范化、流程化、自动化让开发者从繁琐的重复劳作中解放出来专注于架构设计、业务创新、质量把控等核心价值工作。这套从实战中沉淀的Harness工程实践希望能为行业复杂业务系统的AI研发落地提供可复用的参考思路。