How 3 Java Champions are using GitHub Copilot for increased productivity

标题：三位 Java 领域专家如何利用 GitHub Copilot 提升工作效率

URL 来源：https://github.blog/ai-and-ml/github-copilot/how-3-java-champions-are-using-github-copilot-for-increased-productivity/

发布时间：2026-10-20T09:05:03-07:00

Markdown 内容： AI 代码工具可以快速生成代码，但仅凭速度本身无法解决最复杂的软件工程问题。开发人员仍需提供上下文、验证结果、保障代码可维护性，并对最终交付内容负责。

为了了解经验丰富的开发人员如何实现这种平衡，我们采访了三位 Java 领域专家，他们都拥有超过十年的 Java 使用经验。他们分享了在生产环境和开源项目中使用 GitHub Copilot 的具体案例，以及如何将 AI 生成的代码转化为可靠软件的实践方法。

以下是他们与我们分享的建议。

Vlad Mihalcea

GitHub 个人主页：@vladmihalcea

GitHub Copilot 最近对您有哪些帮助？

我一直在使用它来分析、设计和实现 Hypersistence Utils 和 Hypersistence Optimizer 中的各种功能。

例如，我长期以来一直希望开发一个 Web 应用程序，用于展示 Optimizer 的事件历史记录，以便我们能够观察性能优化措施如何在实际应用中体现。在 AI 出现之前，我总是因为开发这个功能需要耗费数周时间而推迟任务。但使用 Copilot 就像是多了一位团队成员，因此我用它开发了一个将在 Hypersistence Optimizer 下一版本中发布的应用程序。这项任务原本需要数周时间，但实际只用了两天就完成。

您通常如何使用？是通过 IDE 插件还是 GitHub Copilot 应用？

我在 IntelliJ IDEA 中使用 GitHub Copilot，因为它在代码审查或调试过程中运行起来非常方便。

作为代码助手，它对加快问题排查和构建需要验证的功能原型非常有用。

尽管 AI 的目标是提高我的工作效率，而不是完全取代我，但我仍然会审查 AI 生成的计划和代码。虽然 AI 在许多情况下都能给出正确的答案，但有时生成的结果并不令人满意，需要我进行干预。

您能分享一些技巧和最佳实践吗？例如，您使用了哪些技能？

我创建了自己的技能，使 Copilot 生成的任何文本都看起来像是我亲手写的。

这项技能从我发表的 65 篇文章中捕捉了我的写作风格，因此生成的草稿听起来更像我的博客，而不是语言模型的输出。这在为该项目生成文档时非常有用，因为它可以让大语言模型从我 12 年的博客内容中学习，并提供遵循相同原则（如表达性、可测试性和简洁性）的示例。

在我的软件工程师职业生涯中，我学到的一个重要经验是：我们花在代码维护上的时间远多于编写代码的时间。因此，由于维护和稳定性对现有产品至关重要，我开发了一些技能，帮助 AI 模拟现有代码实践，遵循“最小惊讶”原则。

一个技巧是根据操作类型调整模型类型。在需要深入思考时，我会使用具有100万上下文窗口的Opus模型，并选择Extra High或Max推理模式。然而，对于生成报告、发布说明或验证文档等简单任务，我会使用消耗更少token的轻量级模型。

Patrick Baumgartner

GitHub主页：@patbaumgartner

您的工作涉及指导团队。您的方法是什么？

我的很多工作是在正常业务仍需持续运行的情况下进行的。您不能停摆六个月去"转型"。我们通常先共同解决眼前的问题，了解团队当前所处的位置，明确目标方向以及如何判断改进的进展，然后逐步推进。

根据具体情况，这可能意味着采用软件工艺实践，如TDD、重构、持续交付和XP；使用Spring Boot和Spring Modulith进行架构设计和模块化；使用Spring Security；优化Java和Spring Boot应用以适配容器；或者越来越多地采用智能体工程。

对我而言重要的是，我与团队是共同协作的。我们共同做决策。我不希望团队变得依赖于我。理想情况下，经过一段时间后，他们可能只需要我作为陪练伙伴，而非必须依赖的人。

这或许也解释了为什么我发现新一代AI工具如此有趣：我喜欢与人合作、学习、实验和解决问题。AI为我们提供了另一个强大的工具来实现这些目标。

您能分享一个GitHub Copilot最近如何帮助您的好例子吗？

实际上有三个截然不同的例子改变了我对使用GitHub Copilot的看法。

让我们从第一个例子开始。

其中一个例子是将约900张教学幻灯片从Reveal.js迁移到Marp，这些幻灯片分布在15个演示文稿中。这些幻灯片并非简单的文本，许多包含代码、动画，甚至交互式示例，我可以在教学过程中实时修改JavaScript。更重要的是，这些演示文稿已经过学生实战检验，流程已经成熟。丢失任何一个细节都可能破坏我在课堂上使用的叙事逻辑。

手动完成这次迁移可能需要我一周或更长时间——实际上，考虑到工作量的繁琐性，我可能直接选择避免执行。

使用Copilot后，我采取了不同的方式。我们首先分析现有材料，定义目标，制定迁移计划，设定约束条件，提供示例，并明确哪些内容必须保持原样。然后我们从大的结构变更逐步深入细节。

真正重要的部分是验证。

我们生成了Reveal.js和Marp版本的截图，并进行了视觉和算法层面的对比。我们构建了一个小型应用，我可以并排运行两个幻灯片集以手动验证动画效果。我们甚至对比了生成的PDF文件。

这意味着代理工具没有简单地说"迁移完成"。我们有确凿的证据。

整个迁移过程耗时约8到10小时。我仍然掌控着内容、教学意图和所有有意义的变更。Copilot可以自动修正拼写错误，但如果内容、版本、日期或含义发生变化，这些都是我们需要讨论的事项。

对我而言，这次经历强化了一个重要原则：委托执行，而非责任。我拥有最终结果的控制权。

您能分享第二个例子吗？

另一个例子来自使用 Tamboui 构建终端 UI 应用程序。它最初在 Linux 的 WSL 环境下运行良好，但我完全忘记了有人可能会直接在 Windows CMD 或 PowerShell 中运行它。

然后，一位真实用户确实这样做了。

他们发现某些表单中 Enter 键被完全忽略。这又是一个我坚信的原则：尽早发布软件，因为你可以从人们实际使用方式中学习。

我们使用 Copilot 将用户反馈转化为可复现的 UI 测试。在 Linux 上，Copilot 通过 tmux 操作应用程序。在与它的协作过程中，我了解到 psmux 并能在 PowerShell 中执行类似的流程。我们复现了问题，创建了本地修复方案，追踪到 Tamboui 的真实问题根源，并提交了上游修复方案，该方案已被合并。

在此次工作中，测试描述本身变得过于冗长，超出了可用上下文范围。因此我请求 Copilot 帮助我重新设计测试的表示方式。它没有采用包含标识符、名称和重复描述的冗长表格，而是提出了更紧凑的箭头表示法：step → step → input，仅在关键位置添加补充信息。

这让我感到意外。我们不仅在使用 AI 执行信息，更在共同探讨 _信息应该如何表示以供执行_。它不需要完全符合人类友好性，只要在保持语义的前提下对代理高效即可。

第三个例子呢？

第三个例子完全不同。

我身边有人需要练习数学，我想到：我们为什么不开发一个小型学习应用？

它覆盖了小学一至四年级的加法、减法、乘法、除法和带余数除法。但我并不想再开发另一个简单的测验应用。与 Copilot 一起，我研究了间隔重复、即时反馈、自适应难度、动机激励、协作学习和无暗黑模式的游戏化等学习方法。

有趣的是，在研究过程中 Copilot 挑战了我最初的假设。我最初希望该应用能适用于全球所有儿童。但研究引导我们转向实际的学校课程体系。我意识到，主题引入顺序、运算类型和数字范围的差异足够显著，使得立即追求“通用性”变得没有必要。

因此我们首先聚焦于瑞士，并据此调整了学习进度。由于瑞士是多语言国家，该应用现已提供德语、法语、意大利语和英语版本。

它还包含协作和竞争的双人模式，当有人答错时，应用会解释一种解题方法，并通过间隔重复机制重新引入类似问题。

我刻意选择了无后端架构。我没有任何理由将儿童的个人数据上传到服务器，因此数据保留在设备本地，应用可以直接托管在 GitHub Pages 上。

最初只是一个小实验，现在却在朋友间被使用和分享。它意外地成为了一个小产品。

这段经历让我看到了 Copilot 的另一面：不要只用它来实现你的方案。要把它当作 _在开始构建前扩展和挑战解决方案空间的合作伙伴_。

你通常如何使用 Copilot？

实际上，我已不再使用经典的 Copilot 自动补全体验。

我的工作几乎完全转向了智能代理工作流程。

当需要紧密的视觉反馈循环时，我会使用 VS Code——比如在需要仔细查看文档、代码、演示文稿或中间结果，并根据情况调整流程时。

对于更大规模的执行导向型任务，我通常通过终端与编码代理协作。在终端中，我可以更自如地将任务委托给代理，让它执行，然后检查完整结果。我选择的界面主要取决于所需的反馈循环类型。

在前往 JavaLand 的旅途中，我通过 GitHub 使用编码代理工作流程的经历非常有趣。当时我开始探索一个 Maven 插件的构想，该插件可以优化加载的 Spring Boot 自动配置项。在大约四小时的旅途中，我通过手机引导代理：分配任务、审查其执行情况、思考下一步行动并发送新指令。

到达时，我已经完成了一个可用的 Maven 插件、CI 流水线、针对示例应用的性能测试，以及能够验证优化效果的报告。

这是我第一次以这种方式工作，惊讶于这种方法竟然如此有效。我并不是在手机上编写 Java 代码，而是在代理执行任务的同时进行审查、决策和引导。

当 MCP 服务器提供有用的能力建设或上下文时，我也会使用它们。例如，我曾用 Context7 进行文档编写和与 Logseq 知识库的集成，还尝试过 Adobe Premiere Pro 的 MCP 集成。

但我不使用 MCP 只是因为可以使用。如果存在优秀的 CLI 工具，我通常更倾向于使用 CLI，因为它对我来说更直接且更高效。

在我的认知模型中，代理并不是“初级开发者”。我更倾向于将其视为一个对手。但就像任何加入项目的成员一样，它首先需要了解项目背景。

上下文是关键。

你能分享一些技巧和最佳实践吗？

我最推荐的一点是：停止使用一次性提示（one-shot prompting）。

对于任何非简单任务，我希望在执行前先理解问题。很多时候我会明确要求代理先与我进行访谈。这次访谈的目的是揭示那些尚未明确的假设和预期。

一个优秀的代理可以非常快速地执行错误的想法。但这并不会让绕道变得更便宜。

我在开发 Spring Boot 自动配置优化器时就亲身体验过这一点。最初我想要同时支持 Spring Boot 3.5 和 4.x。由于架构差异，我们同时实现了两种方案。后来我意识到不再需要 3.5 的路径，而删除它却非常痛苦。

教训很简单：绕道成本高昂。在加速之前，确保需求准确。

一旦意图明确，我想要一个计划。在审查该计划时，有四点对我特别重要：假设是否清晰可见、是否定义了验证关卡、方法是否符合架构、是否避免了不必要的工作？

第二个原则是定义任务特定的验证关卡。

“完成”不应意味着模型声称已经完成。

对于重构任务，验证关卡可能包括通过测试、证明所有目标文件都被处理、更新文档并消除所有 TODO。对于幻灯片迁移，验证关卡包括截图、视觉差异、动画、PDF 输出和内容完整性。

原则不依赖于任务：代理应能够提供证据，证明工作满足“完成”的定义。

我最近接触了一项名为 unlazy 的技能，其理念类似：创建显式的门控机制，有意识地通过它们，并证明它们已完成，而不是走捷径。

第三个原则是将你的经验转化为_可复用技能_。

我开始撰写并维护自己的代理技能库。当从执行中学习到新知识时——例如代理误解了某种惯例、缺少有用的检查，或我发现了更优的任务处理方式——我会更新相应的技能。

下一次执行相同任务时，这些经验已经准备就绪。

一个例子是名为 maintainer-audit 的技能，灵感来自开源代理技能社区的工作。我将其应用于自己的所有仓库中。它会检查并修复维护项目应具备的要素：仓库文档、CI流水线、Dependabot配置、CodeQL、一致的清理规范及其他项目标准。

目标不是生成另一份供我阅读的审计报告。它会自动将仓库恢复到我期望的基础水平。这使我的项目更加一致且易于维护。

我认为这些技能应被视为_动态的工程知识_，而非静态提示。

第四个原则是为概率模型构建确定性工程工具。

我拥有自己的质量检测套件，封装了Checkstyle、PMD和Spring Modulith架构检查等工具，并生成代理可消费的汇总报告。我可以通过钩子运行该套件，让代理进行迭代：

变更 → 执行检查 → 阅读结果 → 修复 → 再次执行。

直到没有检查结果出现才会停止。

这并不意味着我停止观察软件。我仍然会运行应用、与之交互，并判断其行为和表现是否符合预期。有时我会刻意逐个功能实现，因为反馈循环更紧密。

我认识到一次性要求所有内容的做法（“AI可以做到”）通常是个坏主意。宽泛的通用规范会导致同样宽泛的通用实现，而后续清理工作可能比正确构建小规模增量更困难。

更广泛地说，我认为开发者需要更多讨论_如何_使用这些工具。分享成功实验，分享失败案例，互相借鉴并适应各自环境，而不是寻找统一的AI开发流程。

这也是我喜欢将AI视为陪练伙伴的原因。在周五晚上想要尝试新事物但没有人类搭档时，我突然有了可以挑战想法、审查方案或作为高级橡皮鸭的伙伴。

但我会将这些想法带回真实的人群。人类反馈、产品理解与现实场景依然至关重要。

你认为AI如何改变我们的职业？

我不认为软件工程学生应主要追求成为代码生成机器。他们需要成为强大的问题解决者。他们需要理解用户和利益相关者，发现需求背后的真实问题，挑战假设，理解产品和市场，做出架构权衡，批判性思考，以结构化方式工作，并将有用方案从一个场景转移到另一个场景。

模型在生成可能性和执行任务方面表现得非常出色。但作为人类，我通常对实际背景了解得更多——包括那些从未被记录下来的事情。

因此，我希望继续掌控解决方案的塑造，让代理承担更多执行工作。

从这个角度看，我认为 _AI正在将工程重新带回软件工程中_。

我喜欢这一点。

Frank Delporte

GitHub 个人资料：@FDelporte

你是如何进入科技领域的？

我11岁时得到了一台Commodore 64，从那时起就对计算机着迷。毕业后曾短暂涉足视频制作和电视行业，但后来又回到编程领域，因为那些视频需要被刻录到DVD上，而最早的网站也需要开发……是的，我确实有那么老 ;-).

GitHub Copilot 最近如何帮助你？

它是我评估拉取请求和调查错误报告的完美助手。

一个特别的故事是关于 Pi4J 库，它允许你构建 Java 应用程序与树莓派上的电子元件进行交互。2026 年 2 月，我们发布了 V4 版本，其中引入了一个使用 Foreign Function & Memory API 的新插件。在发布前我们进行了彻底的测试，但发布后不久，有人报告称使用 5 个输入按钮时效果不符合预期。前四个配置的按钮按下时会按预期触发代码执行，但第五个按钮却毫无反应。

这是你最不希望收到的报告。没有明显的问题。日志中没有异常，也没有警告，第五个按钮只是完全沉默。更糟糕的是：使用旧版 gpiod 插件时，同样的硬件和同样的应用程序却能正常工作。因此问题出在我们的新 FFM 代码中，它建立在 Linux 内核的 GPIO 字符设备之上，并通过本地调用与其通信。这不是你期望能快速找到答案的代码部分。

所以我将这个问题分配给 Copilot 编程代理，并提供了两个文件路径作为起点：提供者类和 FFMDigitalInput。大约半小时后，出现了一个拉取请求，附带的解释是我完全没想到的。

每个输入都运行一个事件监视器，它在本地 poll() 调用中阻塞，等待内核报告其 GPIO 引脚上的变化。这些监视器在虚拟线程中运行。而阻塞在本地调用中的虚拟线程无法从其载体线程中卸载。在整个调用期间，它会一直固定在该线程上。树莓派 4 有四个核心，因此虚拟线程调度器有四个载体线程。注册四个输入后，所有四个载体线程都会永远阻塞在 poll() 中。第五个监视器被创建，但从未被调度。这正是被报告的错误。不是“事件不稳定”，而是“第五个按钮完全没反应”。

我最喜欢的部分不是代码差异，而是随后在代码审查中展开的对话。我留下了一个评论，要求 Copilot 进一步解释：

_我以为虚拟线程的目标正是摆脱平台线程限制？那么为什么在像树莓派 4 这样的四核处理器上，四个虚拟线程会阻塞四个线程会成为问题？_

检查完整的对话请查看拉取请求。Copilot成功将拥有四个CPU核心的Raspberry Pi的使用与报告的问题关联起来。它不仅提出了一个简单的修复方案，还在调查过程中发现了一些额外的改进点。

能否分享一些技巧和最佳实践？

• 告诉它查找范围： 针对Pi4J问题#622，我添加了两个文件路径。这虽然只是微小的努力，却能大幅减少在大型代码库中搜索的时间。即使你对bug一无所知，通常也会对问题所在的区域有一个模糊的预感。将这些信息提供给工具，可以避免它对整个代码进行调查。
• 要求证明和测试： “添加单元测试来验证更改”是我最近经常提出的要求。实际上，这已经成为我指导文件中的规则。这也能防止误诊的情况，因为测试不会在旧代码上失败。
• 追问原因： 如果你不理解某个修复方案，请明确表达并提出疑问。解释也是交付物之一，应该添加到项目文档、工单或拉取请求中。这能让后续阅读这些信息的每个人受益。例如，这也促使Pi4J团队对本地调用中的虚拟线程绑定问题产生了更多疑问。
• 保持主导权： 所有Pi4J中的拉取请求在合并前都经过维护者的审查和批准。这是该项目最有效的模式：代理进行调查，人类负责最终的代码发布。对于我的其他项目，我也会始终审查工具生成的代码。我始终希望保持代码的可读性和可维护性。工具经常会产生重复的方法或重新创建已存在的功能，这需要你来负责。如今AI辅助编码速度非常快，这也意味着你可能很快就会制造混乱。不要这样做，保持代码的可控性，这样当同事或未来的你需要排查bug或进行改进时，会感谢现在的你。

作者信息

首席云倡导者