随着大模型能力增强,AI Coding 正从代码补全走向由 Agent 独立执行完整任务。
研发团队面对的问题也随之改变:当代码产出速度成倍提升,原有的需求约束、Code Review 和测试验收机制还能否跟上?
如果验证能力没有同步升级,AI 带来的可能不只是效率,还有更集中、更难控制的质量风险。
在 AICon 全球人工智能开发与应用大会上,蚂蚁数字科技资深技术专家魏长征结合两个真实项目,分享了团队对这一问题的探索:在一个 40 多万行的 Rust 新项目中,从第一天开始将 Harness 内建进研发流程;在一个超过 60 万行的 C++ 存量项目中,先重建事实源和质量门禁,再让 Agent 参与仓库升级。
经过改造,后者的代码缺陷率从 20% 以上降至个位数。
在魏长征看来,AI Coding 并没有创造全新的软件工程问题,而是以更高的产能,将需求模糊、目标漂移、事实冲突和验证不足等旧问题集中放大。
Harness 也不是某一种具体技术,而是一套围绕约束、验证和验收建立研发闭环的思路。
本文将沿着演讲的逻辑,呈现这套体系如何从实际问题中逐步形成,以及它在新项目和存量工程中的具体落地过程。
AI Coding 最近被频繁提起,但使用大模型辅助编程并不是刚刚发生的事情。
大模型出现不久后,很多团队已经开始尝试让模型写代码。
那时还没有成熟的 Agent 工具,大家主要在对话框里提问、粘贴代码,让模型帮忙编写脚本、处理繁杂任务或者分析错误,确实可以节省不少力气。
随后,Cline 等工具开始以插件的方式嵌入 VS Code,大家逐渐在 IDE 中使用 AI。
再往后,我们集中采购了 Cursor 一类的 AI IDE,开发者的使用方式从“在 IDE 中安装插件”,变成使用一整套内嵌 Agent 的开发环境。
那一阶段,大家使用最多的能力还是 Tab 补全。
到了后来,Claude Code 等终端形态的工具出现,Cursor 的产品形态也发生变化。
我们逐渐发现, IDE 可能已经不再是主要战场,对话框反而成为人与 Agent 协作的主要入口。
随着模型越来越强、工具可以完成的工作越来越多,我们交给它的任务也越来越完整。
最初只是让 AI 写几行代码,后来则希望它独立完成一项任务,最后由人来验收。
因此,检验标准也在变化。
过去,我们关心的是代码写得好不好;后来,需要判断功能是否正确;当 Agent 开始处理工程级任务时,仅仅判断某个模块能不能运行已经不够,还要看它放进整个项目以后,能不能在完整链路中稳定工作。
🔗 原始来源
如果你要核对细节,可以再看原文: InfoQ AI原文链接
AI热榜