一篇日期为 2026 年 10 月 20 日的 GitHub 官方文章介绍了三位拥有十余年 Java 经验的 Java Champion：Hypersistence 创始人 Vlad Mihalcea、42talents 软件工程师 Patrick Baumgartner，以及 Azul 高级技术作者兼 Foojay.io 维护者 Frank Delporte。他们的经历表明，Copilot 的主要价值并非只是更快地生成代码，而是缩短从创意到可运行实现，再到有证据表明结果符合预期之间的距离。下文所述的时间节省和成效均来自 GitHub 的访谈，而非独立基准测试。
开发工作的具体变化
Mihalcea 使用 Copilot 设计并构建了一个用于检视 Hypersistence Optimizer 事件历史的应用程序。此前，这项工作因他估计需要数周而被搁置；据他报告，使用 Copilot 后，他在两天内完成了这项工作。该应用计划用于下一个产品版本，因此，这是一份由供应商发布的内部开发成果记录，而不是经过独立审计的性能对比。
Baumgartner 的示例涉及的范围更广。他将 15 份 Reveal.js 演示文稿中的约 900 张教学幻灯片迁移到 Marp；据他说，这一过程用了八到十小时，而人工完成原本预计需要一周或更久。这些幻灯片包含代码、动画和交互式示例，因此团队在接受迁移结果前，比对了截图和视觉差异，并人工检查了 PDF 输出和动画效果。
他还把一位真实用户关于 Enter 键被忽略的问题报告转化成了可复现的终端 UI 测试，将问题追踪到 Tamboui，并提交了一个后来被合并的上游修复。在另一个项目中，他与 Copilot 共同构建了一款面向儿童的数学学习应用，先让它与某套特定课程体系对齐，随后又针对瑞士使用德语、法语和意大利语的社区进行了本地化。
Mihalcea 利用上下文保留自己的表达风格和编码约定
Mihalcea 喜欢在 IntelliJ IDEA 中使用 Copilot，以便在阅读源代码或调试时随时参考它。他仍会审查 Copilot 提出的计划和生成的代码。据他说，AI 往往会给出有用的答案，但这并不能免除开发者判断结果是否正确的责任。
为了让文档呈现自己的写作风格，他用 65 篇已发表的文章创建了一项技能。他还开发了编码技能，用来沉淀项目已经形成的实践，并以表达力、可测试性和简洁性为指导原则。对于难度较高的分析，他会选择具有 100 万 token 上下文窗口和更高推理设置的模型；对于报告、发布说明和文档检查，则使用消耗更少 token 的轻量级模型。
他真正关注的是可维护性。由于开发者需要花大量时间维护现有软件，生成的代码应当与代码库中已有的约定保持一致，而不是引入一种团队之后还得重新协调的新风格。
Baumgartner 委派执行，而非责任
Baumgartner 的工作流在很大程度上已从自动补全转向代理式执行。需要紧密的视觉反馈时，他使用 VS Code；对于规模更大、以执行为主的任务，则使用基于终端的编码代理。在前往 JavaLand 的四小时旅途中，他通过手机指挥一个代理，代理则创建了一个 Maven 插件，用于优化 Spring Boot 所加载的自动配置。抵达时，这个项目已经包含一条 CI 流水线、针对示例应用的性能测试，以及用于评估优化效果的报告；他并未报告一种普遍适用的性能提升。
他的核心原则是：可以委派执行，但结果责任仍由自己承担。他认为，上下文与技术能力同样重要。MCP 服务器可以提供有用的文档和集成，但如果直接使用命令行界面同样有效，他更倾向于命令行界面。
需求与验证应先于提速
Baumgartner 建议不要用一次性提示处理非简单工作。他经常让代理先采访自己，以便明确各项假设和预期。他的 Spring Boot 自动配置项目就说明了跳过这一步的代价：同时支持 3.5 和 4.x 形成了两条架构路径，而移除已经不再需要的 3.5 路径非常痛苦。
意图明确后，他会从四个方面审查计划：
- 假设是否清晰可见？
- 是否定义了验证关卡？
- 方法是否符合预期架构？
- 是否避免了不必要的工作？
“完成”应当意味着有证据表明任务满足验收标准，而不只是模型报告说已经完成。重构可能需要测试通过、证明所有预期文件均已处理、文档得到更新，并且没有遗留 TODO。幻灯片迁移则需要视觉对比、动画检查、PDF 输出和内容完整性检查。
可复用的检查让概率性输出更可靠
Baumgartner 会把反复出现的经验转化为 Agent Skills。例如，他的 maintainer-audit 技能会检查仓库文档、CI 流水线、Dependabot 配置、CodeQL 和清理规范，并在适当情况下进行修复。其目标不是生成另一份需要人来解读的报告，而是让仓库重新达到一个明确定义的维护基线。
他还为模型配套使用确定性工具。一套质量检查工具链把 Checkstyle、PMD 和 Spring Modulith 架构检查整合成一份报告，代理可以在“变更—执行—检查—修复”的循环中读取并使用该报告。这并不能消除人工判断：他仍会运行应用，并评估其行为和外观。对于复杂功能，他通常会增量推进，因为更小的增量能带来更紧凑的反馈回路，也能避免把宽泛的需求说明变成宽泛而泛化的实现。
这种方法在哪里有效——又在哪里无效
这些访谈中效果最强的用例具有三个共同特征：它们包含足够的上下文，供代理进行推理；允许进行可观察的验证；并为开发者审查关键决策留出空间。Copilot 很适合迁移、原型开发、可重复的维护任务、测试编写、文档编写以及边界明确的实现工作。
当需求仍然处于隐含状态、架构约束被忽视，或者在没有证据的情况下就接受“完成”时，它就不那么可靠。这些访谈始终把责任放在开发者身上：AI 可以加速执行、质疑假设并提出其他可能的解法，但它无法确定预期结果，也不能保证生产环境中的变更既可维护又正确。
资料来源：How 3 Java Champions are using GitHub Copilot for increased productivity（2026-10-20）。
一起聊聊
留下你的想法，评论审核通过后展示。