从Vibe Coding到Harness Engineering：AI辅助JDK升级的工程化实践

AI Coding的局限性：为什么写代码不等于做工程

过去一年，AI Coding从代码补全工具逐渐发展为能够理解项目、规划任务并执行开发的工程助手。Vibe Coding这种「边想边写、快速迭代」的开发方式，在探索性新功能开发中展现出了极高的效率优势。

然而，当我们审视真实软件工程的全貌时，会发现一个被忽视的真相：工程团队的大部分时间，实际上并不花在开发新功能，而是消耗在框架迁移、安全补丁、版本升级、依赖治理、代码重构等维护性工程上。

这两类工作的本质差异在于：新功能开发关注的是「能不能实现」，而维护性工程关注的是「能不能安全实现」。一个修改不仅要满足需求，还要遵守项目规范，通过编译、能够启动、通过测试，并且不破坏已有系统。这些约束往往藏在项目历史和开发经验里，而不是代码本身。

JDK升级就是最典型的维护性工程案例。从旧版本升级到JDK 21，看起来只是改一个版本号，实际上往往牵一发而动全身：Spring框架兼容性、第三方依赖、编译插件、JVM参数、启动脚本、测试用例——任何一个环节出问题都可能导致服务无法启动。

当我们尝试用Vibe Coding方式直接完成这类工作时，AI确实能够完成部分修改，但在面对复杂依赖关系和长链路验证时，很容易逐渐偏离目标：修改范围失控、依赖关系混乱、配置相互冲突。问题的根源不在于模型能力不足，而在于AI缺少一套能够约束工程执行过程的方法。

Harness Engineering：用工程约束AI的行为

Harness Engineering的核心解决思路是：不过分依赖模型能力，而是通过系统设计约束AI的行为。如果把开发过程比作装修，Vibe Coding更像告诉施工人员「你看着办」；Harness Engineering则先给出施工图，把边界、规范和流程提前定义清楚，让执行过程尽可能减少对模型能力的依赖。

这套体系主要由三部分组成：构建执行约束、沉淀工程经验、建立反馈闭环。三者串联成「约束执行→经验复用→反馈进化」的完整链路。

构建执行约束：让AI在正确的边界内工作

项目上下文构建是第一步。我们发现Vibe Coding失败的首要原因，并非AI不知道如何升级JDK，而是AI在不了解项目约束的情况下就已开始修改代码。它不知道哪些文件由代码生成器自动维护不能修改，不知道某些编译参数需要特殊配置，不知道JVM启动参数的来源位置。这些散落在资深开发者经验中的隐性知识，对AI来说就是看不见的暗礁。

我们的做法是将这些知识转化为AI可消费的结构化规范，核心是动态组装Agent每步所需的精确信息——既不过多导致干扰，也不过少导致盲区。

工程工具编排是第二步。JDK升级涉及的工程动作非常多样：扫描依赖树、解析冲突链路、执行集成测试、读取测试结果。如果每一项都让AI临场发挥，结果仍然不可控。解决思路是把工程动作封装成输入输出明确、失败路径清晰的可调用工具，让AI只需要视情况决定「调用哪个工具」，保证对固定问题表现稳定。

沉淀工程经验：把一次升级变成长期能力

每次升级，AI都像从零开始，升级经验散落在对话、文档和开发者脑中，没有被结构化为AI能复用的格式。因此，我们把执行过程中积累的工程经验沉淀成可复用的Skill模块。

以jdk-upgrade Skill为例，它明确定义了升级过程的核心约束：禁止修改业务逻辑代码、禁止优化或重构业务方法、禁止添加新功能、禁止删除原有功能、仅进行必要的兼容性修改。这些约束明确了Skill的能力边界，避免AI在升级过程中「顺手优化」导致修改范围失控。

在知识组织上，我们采用渐进式披露方式：SKILL.md作为入口和导航，详细的参考资料按需查阅。目录结构示例：

jdk-upgrade/
├── SKILL.md                 # 主技能文档（概览+约束+执行步骤）
└── references/
    ├── maven.md            # Maven插件升级详细配置
    ├── dependency.md       # Pom依赖处理详细列表
    ├── jvm.md              # JVM参数调整详细方案
    └── code.md             # 代码兼容修改详细映射

在执行流程上，我们将升级过程拆分为5个清晰步骤，每个步骤都有明确的操作要点和验证要求：

Step 1 — Maven插件升级：使构建工具链支持JDK 21编译和JUnit 5测试。涉及maven-compiler-plugin升级至3.12.1+、spring-boot-maven-plugin升级至3.5.3、maven-surefire-plugin升级至3.2.5+等。

Step 2 — Pom依赖处理：清除javax时代依赖，迁移至Jakarta EE体系。移除javax.annotation-api等旧依赖，将javax.替换为jakarta.，升级Spring Boot和Lombok版本。

Step 3 — JVM参数调整：移除已废弃参数，适配模块系统和新GC体系。清除CMS相关参数、旧版GC日志参数、PermGen参数，新增–add-opens模块权限参数组和G1GC/ZGC参数。

Step 4 — 代码兼容修改：消除所有javax.*引用，迁移测试框架至JUnit 5。完成包名替换和JUnit 4到JUnit 5的注解迁移。

Step 5 — 验证：执行mvn clean compile和mvn test命令，基于测试报告分析结果进行排查处理。

建立反馈闭环：让系统持续提升

验证反馈循环是Harness Engineering中ROI最高的机制。核心是每步操作后进行检查，防止错误传播。实践表明，验证循环可显著提升任务完成率，无需改模型或提示词。

升级前：撰写集成测试。我们要求AI针对项目的主要功能组件撰写集成测试，覆盖核心业务逻辑链路验证、关键依赖兼容性验证、关键组件功能可用性验证。测试必须真实完整加载Spring上下文，避免mock导致的假性通过，并能结构化输出通过/不通过状态及错误原因。

升级后：重新执行测试。升级完毕后再次执行相同测试集。测试通过说明升级没有破坏已有功能；测试失败则AI需要根据失败信息定位问题并修复。这种「测试前置+升级后验证」的循环确保了升级的可验证性——AI不再能够「谎报结果」，编译通过不代表升级成功，必须通过测试验证。

经验回流机制是闭环的延伸。jdk-upgrade-lessons Skill会在升级任务完成后主动触发，总结升级过程中遇到的问题，生成结构化的经验文档，并基于这些经验生成新版本的升级Skill。执行流程包括：收集升级上下文、引导经验回顾、生成经验文档、生成新版本技能、确认与归档。

效果验证：从工程实践到业务收益

上述方法并非理论设计，而是在真实项目中持续验证。以一次典型的JDK升级为例，目标是从旧版本升级到JDK 21+Spring Boot 3.5.3。单个项目整体涉及30+个文件修改、50+个依赖升级/新增/移除，以及大量配置和启动参数修改。

AI承担了绝大部分工作：从项目分析、任务规划，到代码修改、编译调试和自动修复大部分启动错误。人工只需在最终阶段进行代码Review核验变更质量。

升级效率方面，70%的项目可在单次对话中完成整个升级任务，剩余30%需要人工介入关键节点。

性能收益方面（基于内部多个项目升级前后的生产环境监控对比）：

• 多个服务的CPU使用率平均降幅约22.5%
• 同等负载下堆内存平均下降约23%
• GC改善尤为显著：每分钟GC停顿时间降至1ms以下，业务几乎无感知
• 接口延迟P99平均降幅18.1%，尾部延迟最大降幅达47%（548ms→288ms）
• 在60% CPU负载下，主要Web服务峰值QPS提升超过30%

对于JDK升级这类长期积压的技术债，Harness Engineering改变的不只是执行效率，更是成本结构。过去需要投入大量人力、反复评估ROI，如今AI已经能够承担绝大部分工程工作，团队只需在关键节点进行决策和审查。这意味着许多过去「知道应该做、却一直没有时间做」的工程优化，可以进入常态化执行。

从写代码，到定义约束

这次实践最大的收获，不是升级快了多少，而是我们对AI在工程中的定位有了新的认识。

规范正在成为比代码更重要的资产。项目约束、升级经验、排查方案、执行流程——这些原本存在于开发者经验中的知识，一旦结构化沉淀下来，就能够持续被AI复用。代码反而变成了产物。

文档的首要读者正在从人转变为AI。这些工程知识不是为了约束人，而是为了约束AI。当我们定义项目规范时，目标不是写一份「人类可读的文档」，而是构建一份「AI可执行的约束」。

开发者的角色正在从代码编写者转变为约束设计者。当AI承担执行层工作后，人的核心价值变成了定义「什么能做、什么不能做、做到什么程度」。

这些变化共同指向一点：工程的重心正在从「写代码」转向「定义约束」。JDK升级只是第一块试验田，框架迁移、安全修复、依赖治理——这些维护性工程都能用同一套方法复现。真正提升工程效率的，不是让AI更聪明，而是让工程体系能够持续约束、复用和进化AI的能力。

在AI辅助软件工程的新阶段，或许我们需要的不是更强的模型，而是一套让AI稳定工作的工程基础设施。Harness Engineering正是这个方向的一次有益探索。