蚂蚁数科以Harness工程将AI代码缺陷率降至个位数

随着大模型从代码补全发展到可由Agent独立执行完整任务，研发团队面对的重点已不只是提升代码产出速度，还要确保需求、实现和交付结果能够被持续验证。蚂蚁数字科技资深技术专家魏长征在AICon全球人工智能开发与应用大会上分享了相关实践：一个40多万行的Rust项目从启动第一天就引入Harness流程，另一个超过60万行的C++存量项目则先重建事实源和质量门禁，再让Agent参与仓库升级，最终将代码缺陷率从20%以上降至个位数。

AI辅助编程经历了对话框生成脚本、IDE插件、AI IDE和终端Agent等阶段，任务范围也从补写几行代码扩展到独立完成完整工程任务。开发者因此逐渐从代码生产者转为结果评判者，验收标准也从“代码是否写得好”转向“功能是否正确”，进一步延伸到“放入完整系统后能否稳定运行”。如果验证能力没有同步提升，AI的高产出就会集中放大需求模糊、目标漂移、事实冲突和质量欠账等传统问题。

魏长征认为，Harness并非某个具体工具，而是围绕约束、验证和验收建立研发闭环的方法论。其形成过程通常来自真实项目中的问题积累，并不存在适用于所有团队的固定分层或Reviewer配置。实践总结出的核心环节包括约束、对抗验证、证据、状态写入和目标对齐，分别对应传统研发中的需求与架构评审、Code Review、质量准出、任务拆解及阶段性评审。

在约束层，团队需要明确任务目标与非目标，规定哪些内容必须完成、哪些范围不能涉及，同时指定唯一可信的事实源，避免文档、接口或数据定义相互冲突。这些约束可以分别整理为面向人的说明文档、供Agent读取的上下文材料，以及能够被机器直接检查的规则。对于新项目，这类质量门禁应从第一天开始内建；对于存量工程，则要先把分散的事实和标准重新建立起来。

对抗验证主要解决高速开发下Code Review容易失效的问题。过去人工审查超过2000行的提交就已十分困难，而Agent一次可能生成四五千行代码，因此需要把Agent纳入CI流程，并让不同Reviewer分别检查命名格式、重复实现、根因定位和同类问题覆盖情况。代码量增加不应成为放弃Review的理由，关键是让验证速度与生成速度相匹配。

证据层强调交付结果必须可视化、可验证，不能只接受Agent声称“任务已完成”。团队可以通过测试结论、质量报告、HTML页面、架构图和流程图，快速确认执行过程、测试结果及最终验收状态。对于持续十五到二十小时的长任务，还需要阶段性记录执行进度和中间状态，避免Agent在上下文压缩、记忆丢失或任务跨度过大时偏离最初目标。

Harness方法的重点并不是让Agent无条件承担更多工作，而是把传统研发中的需求评审、设计约束、任务拆解、代码审查和测试准出，以更适合人机协作的方式重新组织。借助自动化约束和快速验证，团队才能在提升AI Coding产能的同时控制质量风险，让“能生成”进一步转化为“可验收、可交付”。