为什么我在团队大力推进 Harness Engineering 的同时，却不认为它就是未来

为什么我在团队大力推进 Harness Engineering 的同时，却不认为它就是未来

第二，代码库会变成会自我解释的系统。

今天的代码库主要被人维护，文档常常落后。未来的代码库会持续生成自己的模块地图、依赖关系、风险区域、变更影响分析和演进建议。开发者打开的不是一堆文件，而是一个可以对话、可以解释、可以协商变更路径的系统。

第三，开发团队会从“人组成的团队”变成“人和智能体组成的团队”。

一个团队里可能有测试 Agent、迁移 Agent、文档 Agent、review Agent、性能 Agent、依赖治理 Agent。人类工程师的职责不是逐行指挥它们，而是定义目标、分配权限、设计反馈机制，并对最终结果负责。

第四，架构能力会重新升值。

当写代码的边际成本下降，真正稀缺的会是判断：什么不该做，边界放在哪里，系统复杂度如何控制，哪些约束必须长期稳定，哪些可以快速试错。AI 会降低实现成本，但不会自动给组织带来清晰的战略和架构取舍。

第五，软件交付会更接近连续演化。

未来的软件可能不再以大版本为主要节奏，而是围绕目标指标持续生成、验证、发布和回滚。开发从“项目制”进一步转向“演化制”：系统不断观察自己、提出改进、生成变更、接受审查、进入生产。

7. 软件开发从业人员应该做哪些准备

如果我们承认 Harness Engineering 很重要，但又不是终局，那么个人和团队的准备方向就会更清晰。

第一，学会把隐性知识显性化。

未来最有价值的工程师，不只是会写代码的人，而是能把复杂系统解释清楚的人。你需要能写清楚模块边界、业务规则、约束条件、失败模式、测试策略。因为这些东西不仅给人看，也给 AI 看。

第二，提升任务定义能力。

AI 时代，模糊任务会制造更大的混乱。优秀工程师要能把“做一个功能”拆成目标、非目标、输入输出、验收标准、风险点和回滚方案。任务定义越清楚，Agent 的执行质量越高。

第三，掌握验证思维。

不要只问“AI 能不能写出来”，要问“我如何知道它写对了”。测试、类型系统、静态分析、可观测性、灰度、回滚、评测集，会成为 AI 时代工程师的核心武器。

第四，理解工具和协议。

MCP、Agent Runtime、CI/CD、权限系统、代码搜索、知识库、日志平台，这些会成为 AI 进入工程系统的接口。你不一定要成为每个领域的专家，但要理解它们如何连接成一个可靠的工作环境。

第五，保留架构判断和产品判断。

当模型越来越会写代码，工程师的差异会更多体现在判断力上：识别真正的问题，拒绝错误的需求，控制复杂度，设计可演化的系统，理解业务目标和用户价值。

第六，训练与 AI 协作的工作习惯。

不要把 AI 当搜索引擎，也不要把它当实习生。更好的方式是把它当一个高吞吐、可并行、需要约束、需要验证的工程协作者。你给它上下文、目标和边界，它给你方案、实现和反馈；你负责判断、整合和承担后果。

第七，主动参与团队 Harness 建设。

如果你所在团队还没有 AI rules、仓库上下文、Agent 工作流、自动验证体系，现在就可以开始。不要等模型变得完美。真正的红利属于那些在模型还不完美时，就已经学会重构工程系统的团队。

结语：推进它，但不要迷信它

我推进 Harness Engineering，是因为它让 AI 进入真实软件工程的方式变得具体、可控、可复制。

它能让团队从零散的 AI 使用，走向系统性的 AI 协作；从个人提效，走向组织提效；从“模型写几行代码”，走向“模型参与工程闭环”。

但我不认为它就是未来。

未来不会停在 Harness 上。未来会发生在大模型、工具、上下文、验证、权限和组织协作逐渐融合之后。到那时，今天很多需要我们手工搭建的支架，会被模型能力、标准协议和 AI-native 工程平台吞噬。

所以更准确的态度是：

今天认真建设 Harness Engineering，明天准备亲手拆掉它的一部分。

这不是矛盾，而是工程演进的常态。真正值得追求的不是某个中间形态，而是让团队持续靠近更高质量、更高速度、更低摩擦的软件创造方式。