最近大家谈 AI 开发自动化，注意力很容易集中在 Harness Engineering 上：怎么给 Agent 提供上下文、拆任务、调用工具、执行代码、做评测、失败重试……

这些当然重要。

但我越来越觉得，在中大型科技企业里，如果目标不是让 AI 偶尔帮某个工程师多写一点代码，而是要把整个开发流程真正做成自动化、标准化、能够复制的体系，尽量降低每个环节对具体个人的依赖，那么最重要的可能不是 Harness，反而是基建。

Harness 解决如何工作，基建决定能不能工作

Harness 解决的是：如何让 AI 更好地工作。

而基建决定的是：AI 到底有没有一个适合工作的环境。

很多公司的现实情况是：

  • 同一个业务概念，在不同系统里有三四种叫法
  • 同一类需求，不同团队有完全不同的实现方式
  • 大量业务规则藏在历史代码、配置平台、数据库字段，甚至某几个老员工的脑子里
  • 废弃代码没人敢删，过期逻辑仍然和主流程混在一起
  • 发布、查数据、改配置都依赖人工操作和临时权限

在这样的环境里，就算 Agent 再聪明，也很难稳定地完成端到端任务。

因为 AI 不知道应该相信哪段代码，不知道哪个系统才是事实来源；做决策时，公司内部就没有一套清晰、统一、机器可以理解的决策依据。

AI 友好的开发架构

真正的 AI 开发基建，首先是 AI 友好的开发架构。

模块边界要清楚，依赖关系要可识别，接口和数据模型要稳定，业务规则尽量显式表达。新需求应该能沿着相对固定的路径落到代码里，而不是每次都靠经验丰富的人重新判断“这次应该改哪里”。

统一开发范式，降低理解成本

其次是统一的开发范式。

相似的问题尽量使用相似的目录结构、代码组织、配置方式、错误处理、测试方法和发布流程。这里的统一并不是为了追求形式上的整齐，而是为了降低系统的“理解成本”。

对人来说，混乱的系统可以靠经验勉强维持；对 AI 来说，不一致就意味着更多上下文、更高的不确定性，以及更多不可预测的错误。

清理历史逻辑，减少错误事实

还有一个经常被低估的工作，就是清理历史代码和废弃业务逻辑。

很多企业想直接在庞大的旧代码库上叠加 AI，却不愿意先处理多年积累下来的技术债。结果 AI 每做一个任务，都要先在大量失效信息里判断什么还在用、什么已经废弃、什么只是为了兼容五年前的一次活动。

这不仅是消耗 Token 的问题，更严重的是，它会让 AI 基于已经失效的逻辑，做出看起来合理、实际上错误的修改。

让内部系统可以被安全操作

除此之外，还需要把企业内部系统改造成 AI 可以安全访问和操作的基础设施。

Codebase、业务系统、配置平台、发布系统、监控系统、数据库访问、文档和知识库，都需要有稳定的接口、清晰的语义、可查询的状态，以及足够细粒度的权限控制。

需要更加清晰地定义 AI 可以读什么、改什么，什么操作必须经过确认，什么环境可以自动执行，出了问题如何定位和撤销。这些都应该成为基础设施的一部分。

建立验证和反馈闭环

再往后，还要有完整的验证和反馈闭环。

代码生成并不等于任务完成。测试、静态检查、灰度发布、监控、异常归因、自动回滚，以及线上结果反馈，都需要被纳入同一套机器可执行的流程。

只有这样，AI 才能从“帮你写代码”走向“对交付结果负责”。

再强的 Harness 也不能高效调度混乱

我并不是说 Harness Engineering 作为 AI 开发体系上层的调度和执行框架不重要。

问题在于，如果底层架构混乱、开发方式不统一、历史逻辑真假难辨、内部系统无法安全调用，再强的 Harness 也只是在更高效地调度混乱。

模型能力会继续提升，Harness 也会快速迭代。但企业内部的代码结构、业务规则、权限体系和工程流程，不会因为模型升级就自动变得清晰。

未来真正拉开企业 AI 研发效率差距的，可能不是谁最早接入了更强的模型，或者谁做出了更复杂的 Agent，而是谁更早把自己的研发体系改造成了一个结构清楚、规则显式、接口统一、权限可控、结果可验证的环境。

说到底，AI 自动化不是简单地给现有研发流程加一个 AI，而是要重新建设一套既适合人，也适合 AI 参与的工程基础设施。

但是现实的困境是，企业中大多都在为了短期的产出和绩效忙忙碌碌，鲜有为了长期目标而容忍短期没有实际收益的付出。

本文首发于 X：查看原文。