三位 Java Champion 分享 GitHub Copilot 提效实践经验

三位 Java Champions 分享了他们如何使用 GitHub Copilot 解决问题、加速开发，并让人类对结果负责。

2026年10月20日

|

17 分钟

• 分享：

AI 编程工具可以快速生成代码，但仅凭速度并不能解决最棘手的软件工程问题。开发者仍然需要提供上下文、验证结果、保护可维护性，并对交付的内容负责。

为了了解经验丰富的开发者如何把握这种平衡，我们采访了三位 Java Champions，他们都拥有超过十年的 Java 使用经验。他们分享了在生产环境和开源项目中使用 GitHub Copilot 的具体示例，以及他们将 AI 生成的输出转化为可靠软件的实践方法。

以下是他们分享给我们的技巧。

Vlad Mihalcea

GitHub 主页：@vladmihalcea

GitHub Copilot 最近对你有什么帮助？

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

举个例子，我很久以来一直想开发一个提供 Optimizer 事件历史记录的 Web 应用，这样我们就能看到性能优化工作是如何在应用性能中体现的。在 AI 出现之前，我一直推迟这项任务，因为它需要花费我数周时间来开发。但使用 Copilot 就像拥有了一位新的团队成员，所以我用它创建了一个将在 Hypersistence Optimizer 下一版本中发布的应用。这项任务没有花几周，只用了两天就完成了。

你的典型使用方式是什么？你是使用 GitHub Copilot 的 IDE 插件还是 GitHub Copilot 应用？

我在 IntelliJ IDEA 中使用 GitHub Copilot，因为在审查源代码或调试会话期间使用它非常方便。

它作为代码助手非常有用，能帮助我加快调查速度，并为需要验证的功能构建原型。

我仍然会审查 AI 生成的方案和代码，因为它们的目标是提高我的生产力，而不是完全取代我。虽然 AI 在很多情况下都能给出正确的答案，但有时回应并不令人满意，需要我来干预。

你能分享一些技巧和最佳实践吗？比如，你在使用哪些技能（skills）？

我创建了自己的技能（skills），让 Copilot 生成的文本看起来就像我亲手写的一样。

这项技能从我的 65 篇已发表文章中捕捉我的文风，因此生成的草稿读起来像我的博客，而不像语言模型的输出。这在为该项目生成文档时特别有用，因为它让 LLM 从我 12 年的博客写作中学习，并提供遵循相同原则的示例，例如表达力、可测试性和简洁性。

在我作为软件工程师的整个职业生涯中，我学到我们在代码维护上花费的时间远多于创建代码的时间。因此，由于维护和稳定性对现有产品至关重要，我开发了一些技能，帮助 AI 模仿现有代码的实践方式，遵循最小惊讶原则。

一个技巧是根据操作类型切换模型类型。对于需要深入思考的任务，我会使用拥有 100 万上下文窗口和 Extra High 或 Max 推理强度的 Opus。而对于更简单的任务，比如生成报告、发布说明或校验文档，我会使用消耗更少 token 的轻量模型。

Patrick Baumgartner

GitHub 主页：@patbaumgartner

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

我的很多工作是在业务仍需正常运转的情况下进行的。你不可能为了“转型”而让一切停摆六个月。我们通常会先一起解决眼前的问题，了解团队目前的状况，明确我们想要达到的目标以及如何知道自己正在进步，然后一步步向目标迈进。

根据具体情况，这可能意味着采用 TDD、重构、持续交付和 XP 等软件工艺（Software Craft）实践；使用 Spring Boot、Spring Modulith 进行架构和模块化；Spring Security；针对容器优化 Java 和 Spring Boot 应用；或者越来越多地涉及智能体工程。

对我来说，重要的是我与团队一起工作。我们共同做决策。我不希望团队变得依赖我。理想情况下，一段时间后他们就不再需要我了，或许只是作为陪练伙伴。

这也许能解释为什么我觉得新一代 AI 工具如此有趣：我喜欢与人合作、学习、实验和解决问题。AI 恰好为我们提供了一个非常强大的工具来做这些事情。

您能分享一个最近 GitHub Copilot 帮到您的好故事吗？

实际上有三个截然不同的例子，改变了我对与 GitHub Copilot 协作的看法。

我们先从第一个说起。

其中一个是将 15 份演示文稿中约 900 张教学幻灯片从 Reveal.js 迁移到 Marp。这些可不是简单的幻灯片。很多包含代码、动画，甚至还有交互式示例，让我在授课时可以实时修改 JavaScript。更重要的是，这些演示文稿已经在学生中经过了实战检验。演示流程很顺畅。哪怕丢掉一小部分，都可能破坏我在课堂上使用的故事线。

手动完成这次迁移大概会花我一周甚至更长时间——而且现实地说，我可能干脆就不做了，因为这是一项极其枯燥的工作。

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

真正关键的部分是验证。

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

这意味着智能体不只是说一句“迁移完成”。我们有了证据。

整个迁移花了大约八到十个小时。我仍然掌控内容、教学意图和每一个有意义的改动。Copilot 可以自动修正拼写错误，但如果内容、版本、日期或含义发生变化，那就是需要我们讨论的事情。

对我来说，这次经历强化了一个重要原则：委托执行，而非委托责任。结果由我负责。

您能分享第二个例子吗？

第二个例子来自使用 Tamboui 构建终端 UI 应用。它最初在 WSL 下的 Linux 上运行得很好，而我完全忘了有人可能会直接在 Windows CMD 或 PowerShell 中运行它。

然后一位真实用户就这么做了。

他们发现，回车键在某些表单中直接被忽略了。这也是我坚信的另一个原则：尽早发布软件，因为你能从人们实际使用的方式中学到东西。

我们用 Copilot 把这些反馈转化为可复现的 UI 测试。在 Linux 上，Copilot 使用 tmux 来操作应用程序。在与它合作的过程中，我了解到了 psmux，并能在 PowerShell 中执行类似的流程。我们复现了问题，创建了一个本地修复，将真正的问题追溯到 Tamboui，并提交了上游修复，该修复已被合并。

在这项工作中，测试描述本身变得过于庞大，超出了可用的上下文。于是我请 Copilot 帮我重新设计测试的表示方式。它没有采用包含标识符、名称和重复描述的冗长表格，而是提出了一种更加紧凑的箭头表示法：步骤 → 步骤 → 输入，只在关键之处附加额外信息。

这让我很惊讶。我们不只是在用 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，因为它对我来说更直接、更快。

在我的心智模型中，智能体也不是“初级开发者”。我更多把它当作一个陪练伙伴。但就像任何刚加入项目的人一样，它首先需要熟悉情况。

上下文为王。

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

我最想建议的一点是：停止一次性提问。

对于任何非平凡的任务，我都想在执行开始之前理解问题。很多时候我会明确要求智能体先“面试”我。这种面试的目的是挖掘出仍然隐含的假设和期望。

一个好的智能体能以惊人的速度执行错误的想法。这并不会让绕的弯路变得便宜。

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

教训很简单：绕路代价高昂。在加速之前先把需求弄对。

一旦意图明确，我就要一份计划。在审查这份计划时，我尤其关注四点：假设是否可见，验证关口是否已定义，方案是否符合架构，以及是否避免了不必要的工作？

第二条原则是定义针对具体任务的验证关口。

“完成”不应该意味着模型说它完成了。

对于重构，验证关口可能包括测试通过、证明所有目标文件都已处理、更新文档以及不留任何 TODO。对于幻灯片迁移，验证关口包括截图、视觉差异对比、动画、PDF 输出和内容完整性。

验证关口取决于任务，但原则不变：智能体应该能够提供证据，证明工作满足“完成”的定义。

我最近遇到一个名为 unlazy 的技能，它遵循类似的思路：创建明确的关卡，认真逐一推进，并证明它们已经完成，而不是走捷径。

第三条原则是把你的经验教训转化为可复用的技能。

我已经开始编写和维护自己的 Agent Skills。当我从一次执行中学到东西——也许智能体误解了某个约定、缺少了一个有用的检查，或者我找到了更好的任务处理方式——我就会更新这个技能。

下次执行同样的任务时，经验教训已经在那里了。

一个例子是我称之为 maintainer-audit 的技能，它的灵感来自开放 agent skills 社区的工作。我在自己的代码仓库中广泛使用它。它会检查并在适当的时候修复我期望一个得到维护的项目所应具备的内容：仓库文档、CI 流水线、Dependabot 配置、CodeQL、一致的清理工作以及其他项目标准。

目标不是再生成一份供我阅读的审计报告。它会自动把仓库拉回到我想要的基线。这让我的项目更加一致、更易于维护。

我把这些技能视为活的工程知识，而不是静态的提示词。

第四条原则是在概率性模型周围部署确定性的工程工具。

我有自己的质量工具链，它封装了 Checkstyle、PMD 和 Spring Modulith 架构检查等工具，并生成一份智能体可以使用的整合报告。我可以通过钩子运行它，让智能体不断迭代：

修改 → 执行检查 → 阅读发现的问题 → 修复 → 再次执行。

这一过程会持续到没有任何问题残留为止。

这并不意味着我不再关注软件本身。我仍然会运行应用程序、与它交互，并判断它的行为和外观是否符合我的预期。有时我会刻意逐个功能地实现，因为这样反馈循环要紧凑得多。

我学到的一点是，因为“AI 能做到”就一次性要求完成所有事情，通常是个坏主意。庞大而笼统的规格说明会产生庞大而笼统的实现——之后清理它们可能比正确地构建更小的增量还要困难。

更广泛地说，我认为我们开发者需要更多地讨论我们如何使用这些工具。分享那些行之有效的实验，也分享那些失败的尝试。从彼此那里借鉴想法，并根据你自己的场景加以调整，而不是去寻找一套放之四海皆准的 AI 开发流程。

这也是我喜欢把 AI 当作陪练伙伴这一理念的原因。在周五晚上，当我想实验点什么而身边没有人类搭档时，我突然就有了一个可以挑战想法、审视方案的伙伴——或者说是某个东西——或者把它当作一个非常聪明的橡皮鸭来用。

但我仍会把这些想法带回给真实的人。人类的反馈、对产品的理解以及真实世界的背景依然至关重要。

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

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

这个模型在生成各种可能性和执行任务方面极其出色。但作为人类，我通常掌握着更多实际背景——包括那些从未被记录下来的东西。

因此，我希望继续主导解决方案的塑造，让智能体接管更多执行工作。

从这个意义上说，我认为 AI 正在把“工程”重新带回软件工程之中。

我很喜欢这一点。

Frank Delporte

GitHub 主页：@FDelporte

你是如何进入科技行业的？

我从 11 岁得到一台 Commodore 64 起就迷上了计算机。毕业后我曾涉足视频制作和电视工作，但后来又回到了编程，因为那时视频需要刻录成 DVD，还有最早的那些网站……是的，我就是那么老 ;-）。

GitHub Copilot 最近如何帮到了你？

它是评估拉取请求和调查 bug 报告的完美搭档。

一个值得注意的故事与 Pi4J 库有关，这个库让你可以构建 Java 应用来与 Raspberry Pi 上的电子元件交互。2026 年 2 月，我们发布了 V4 版本，其中包含一个使用 Foreign Function & Memory API 的新插件。我们在发布前进行了充分测试，但就在发布后不久，还是有人报告说使用 5 个输入按键无法按预期工作。按下前四个已配置的按键中任何一个都会按预期触发代码执行，而第五个按键却毫无反应。

这是你最不想收到的那种报告。表面上没有任何东西损坏。没有异常，日志里没有警告，第五个按键就是静默无响应。更糟的是：使用旧版 gpiod 插件时，完全相同的硬件和完全相同的应用程序却运行正常。所以问题出在我们新的 FFM 代码里，它构建在 Linux 内核的 GPIO 字符设备之上，并通过原生调用与之通信。这可不是代码库中你指望能快速找到答案的部分。

于是我把这个 issue 指派给了 Copilot 编码智能体，并给了它两个文件路径作为起点，即 provider 类和 FFMDigitalInput。大约半小时后，出现了一个拉取请求，其解释完全出乎我的意料。

每个输入都运行一个事件监听器，它会在原生 poll() 调用中阻塞，等待内核报告其 GPIO 线路上的变化。这些监听器运行在虚拟线程中。而在原生调用中阻塞的虚拟线程无法从其载体线程上卸载。它会在整个调用期间一直钉在那里。Raspberry Pi 4 有四个核心，所以虚拟线程调度器只有四个载体线程。注册四个输入，全部四个载体线程就永远停在了 poll() 里。第五个监听器被创建了，但永远不会被调度。这正是被报告的那个 bug。不是“事件不稳定”，而是“第五个毫无反应”。

我最喜欢的不是那个 diff，而是随后在代码评审中的对话。我留了一条评论，请 Copilot 更详细地解释这一点：

我以为虚拟线程的目标恰恰就是摆脱平台线程的限制？那么为什么四个虚拟线程会阻塞像 Raspberry Pi 这样的四核处理器上的全部四个线程，这怎么会成为问题？

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

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

• 告诉它去哪里看：对于 Pi4J 的 issue #622，我添加了两个文件路径。这只是很小的投入，却能省去在庞大代码库中大量的搜索。即使你对这个 bug 一无所知，通常也会对大致范围有个直觉。把它告诉工具，这样它就不需要调查整个代码。
• 要求提供证据和测试：“添加一个单元测试来验证改动”是我近来经常提出的要求。不过，现在它已经成了我指令文件里的一条规则，不用再问了。这也能防止诊断出错的情况，因为测试不会在旧代码上失败。
• 追问原因：如果你不理解某个修复，就直说并追问。解释本身也是交付成果，应当添加到你的项目文档中，或写入工单或拉取请求里。这能让日后读到这些信息的每个人都受益。例如，这也引发了 Pi4J 团队内部关于本地调用中虚拟线程固定（virtual thread pinning）的更多讨论。
• 保持掌控：Pi4J 中所有这些拉取请求在合并前都经过了维护者的审查和批准。这是这个项目中效果最好的模式：智能体负责调查，人类对交付的内容负责。对我的其他项目，我也总是审查工具生成的代码。我始终希望代码保持可读和可维护。工具经常会创建重复的方法，或者重复实现某个已经在别处存在、本应合并的东西。这是你的责任。如今借助 AI 辅助编程，你可以跑得非常快，这也意味着你可以非常快地制造出一团乱麻。不要那样做，保持代码可管理，当你的同事和未来的你需要调查 bug 或做改进时，他们会感谢你。

作者：

首席云布道师（Principal Cloud Advocate）

相关文章

我们也做新闻通讯

在我们专为开发者打造的半月刊新闻通讯中，发现技巧、技术指南和最佳实践。