AI编程工具可以快速生成代码，但仅有速度并不能解决最困难的软件工程问题。开发人员仍然需要提供上下文、验证结果、保护可维护性，并对交付的内容保持负责。
为了了解经验丰富的开发人员如何把握这种平衡，我们采访了三位Java Champion，他们都拥有超过十年的Java使用经验。他们分享了在生产环境和开源项目中使用GitHub Copilot的具体示例，以及他们用来将AI生成的输出转化为可靠软件的实践方法。
以下是他们与我们分享的技巧。
Vlad Mihalcea
GitHub主页： @vladmihalcea
GitHub Copilot最近对你有什么帮助？
我一直在用它来分析、设计和实现Hypersistence Utils和Hypersistence Optimizer中的各种功能。
例如，很久以来我一直想开发一个Web应用程序来提供Optimizer事件历史记录，这样我们就能看到性能改进工作如何在应用程序性能中体现。在AI出现之前，我一直推迟这项任务，因为开发它需要花费我数周时间。但使用Copilot就像拥有了一位新的团队成员，所以我用它创建了一个将在Hypersistence Optimizer下一版本中发布的应用。这项任务不再需要数周，只用了两天就完成了实现。
你的典型使用方式是什么？你是将GitHub Copilot作为IDE插件使用，还是使用GitHub Copilot应用？
我在IntelliJ IDEA中使用GitHub Copilot，因为在审查源代码或调试会话期间运行它非常方便。
它作为代码助手非常有用，帮助我加快调查速度，并为需要验证的功能构建原型。
我仍然会审查AI生成的计划和代码，因为它们的目标是提高我的生产力，而不是完全取代我。虽然AI在很多情况下能提供正确的答案，但有时响应并不令人满意，需要我进行干预。
你能分享一些技巧和最佳实践吗？例如，你使用了哪些skills？
我创建了自己的skills，让Copilot生成的文本看起来就像我亲手写的一样。
这个skill从我发表的65篇文章中捕捉了我的写作风格，因此生成的草稿读起来像我的博客，而不像一个语言模型。这在为该项目生成文档时非常有用，因为它让LLM从12年的博客写作中学习，并提供遵循相同原则的示例，例如表达力、可测试性和简洁性。
在我作为软件工程师的职业生涯中，我学到我们花在代码维护上的时间远多于创建代码的时间。因此，由于维护和稳定性对现有产品至关重要，我开发了一些skills，帮助AI遵循最小惊讶原则来模仿现有的代码实践。
一个技巧是根据操作类型更改模型类型。对于深度思考，我使用具有1百万上下文窗口和Extra High或Max推理能力的Opus。然而，对于较简单的任务，例如生成报告、发布说明或验证文档，我使用消耗更少token的轻量级模型。
Patrick Baumgartner
GitHub主页： @patbaumgartner
你的工作涉及团队辅导。你的方法是什么？
我的很多工作都是在正常业务仍需继续运转的情况下进行的。你不可能停下来六个月去进行“转型”。我们通常从共同解决眼前的问题开始，了解团队目前所处的位置，明确我们想要达到的目标以及如何知道我们正在进步，然后一步一步地向目标迈进。
根据具体情况，这可能意味着软件工艺（Software Craft）实践，例如TDD、重构、持续交付和XP；使用Spring Boot、Spring Modulith进行架构和模块化；Spring Security；针对容器优化Java和Spring Boot应用程序；或者越来越多地涉及智能体工程（agentic engineering）。
对我来说，重要的一点是我在工作 与 团队一起。我们一起做决策。我不希望团队变得依赖我。理想情况下，过一段时间后他们不再需要我，或许除了作为一个陪练伙伴。
也许这解释了为什么我觉得这一代新的 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 帮我重新设计测试的表示方式。它没有采用包含标识符、名称和重复描述的冗长表格，而是提出了一种更加紧凑的箭头表示法：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，因为它让我感觉更直接、更快速。
在我的心智模型中，代理也不是一个“初级开发者”。我更把它当作一个陪练伙伴。但就像任何刚加入项目的人一样，它首先需要被带上正轨。
上下文为王。
你能分享一些技巧和最佳实践吗？
我最想推荐的一点是： 停止一次性提示。
对于任何非琐碎的任务，我都希望在执行开始之前先理解问题。我经常会明确要求代理先对我进行采访。那次采访的目的是揭示那些仍然隐含的假设和期望。
一个好的代理可以非常快地执行一个错误的想法。这并不会让绕的弯路变得更便宜。
我在开发 Spring Boot 自动配置优化器时亲自体会到了这一点。最初我想同时支持 Spring Boot 3.5 和 4.x。两者存在架构差异，所以我们实现了两种方案。后来我意识到自己不再需要 3.5 的路径，而移除它的过程很痛苦。
教训很简单： 弯路的代价很高。在加速之前先把需求搞对。
一旦意图清晰，我就想要一份计划。在审核这份计划时，有四点对我尤为重要：假设是否可见、验证关卡是否已定义、方案是否符合架构，以及是否避免了不必要的工作？
第二条原则是定义 针对任务的验证关卡。
“完成”不应该意味着模型说它完成了。
对于一次重构，关卡可能包括：测试通过、证明所有目标文件都已被处理、更新文档并且不留下任何 TODO。对于幻灯片迁移，关卡包括截图、视觉差异、动画、PDF 输出和内容完整性。
关卡取决于任务。但原则不变：代理应该能够提供证据，证明工作符合完成定义。
我最近看到一个技能，叫做 unlazy ，它遵循类似的理念：创建明确的关卡，逐一认真完成，并证明它们已被完成，而不是走捷径。
第三条原则是把你的经验教训转化为 可复用的技能.
我开始编写和维护自己的 Agent Skills。每当我从一次执行中学到东西——也许是代理误解了某个约定、缺少了一个有用的检查，或者我发现了处理某个任务的更好方法——我就更新这个技能。
下次我执行那个任务时，经验教训已经就位了。
一个例子是我称之为 maintainer-audit的技能，它受开放代理技能社区工作的启发。我在自己的各个仓库中都使用它。它会检查并在适当的情况下修复我期望一个得到良好维护的项目所应具备的内容：仓库文档、CI 流水线、Dependabot 配置、CodeQL、一致的清理以及其他项目标准。
它的目标不是再生成一份供我阅读的审计报告。它会自动把仓库拉回到我想要的基线。这让我的项目更一致、更易于维护。
我把这些技能看作 活的工程知识 而不是静态提示词。
第四个原则是在概率性模型周围放置确定性的工程工具。
我有自己的质量工具链,它封装了 Checkstyle、PMD 和 Spring Modulith 架构检查等工具,并生成一份代理可以读取的汇总报告。我可以通过 hooks 运行它,让代理不断迭代:
变更 → 执行检查 → 阅读发现的问题 → 修复 → 再次执行。
它会持续进行,直到没有任何发现的问题为止。
这并不意味着我不再审视软件。我仍然会运行应用程序,与它交互,并判断它的行为和外观是否符合我的预期。有时我会刻意逐个功能地实现,因为这样反馈回路要紧凑得多。
我学到的一点是,因为“AI 能做到”就一次性要求完成所有事情,通常是个坏主意。大型、笼统的规格说明会产生大型、笼统的实现——事后清理它们可能比正确地构建较小的增量更困难。
更广泛地说,我认为我们开发者需要更多地谈论 如何 使用这些工具。分享那些行之有效的实验,也分享那些失败的尝试。互相借鉴想法,并将其适配到你自己的环境中,而不是寻找一种万能的 AI 开发流程。
这也是我喜欢把AI当作陪练伙伴这一想法的原因。在周五晚上，当我想尝试一些东西而没有人类搭档可用时，我突然有了一个人——或者说一个东西——可以和它挑战想法、审视方法，或者把它当作一个非常 sophisticated 的“橡皮鸭”。
但我仍会把这些想法带回给真实的人。人类的反馈、对产品的理解以及真实世界的背景仍然至关重要。
你认为AI正在如何改变我们的职业？
我认为软件工程专业的学生不应该主要立志成为生产代码的机器。他们需要成为强大的问题解决者。他们需要理解用户和利益相关者，发现需求背后的真正问题，质疑假设，理解产品和市场，做出架构权衡，进行批判性思考，以结构化的方式工作，并把有用的解决方案从一个场景迁移到另一个场景。
模型在生成可能性和执行事情方面非常出色。但作为人类，我通常掌握更多实际背景——包括那些从未被记录下来的东西。
因此我希望继续主导解决方案的塑造，而让智能体接管更多执行工作。
从这个意义上说，我认为 AI正在把“工程”重新带回软件工程.
我喜欢这一点。
Frank Delporte
GitHub 主页： @FDelporte
你是如何进入科技行业的？
我11岁得到一台 Commodore 64 时就迷上了计算机。毕业后我曾转向视频制作和电视工作，但最终又回到编程，因为那些视频需要刻录到 DVD 上，还有最早的网站……是的，我就是那么老 ;-）。
GitHub Copilot 最近对你有什么帮助？
它是评估拉取请求和调查错误报告的绝佳伙伴。
一个了不起的故事是关于 Pi4J 库 的，它让你能构建 Java 应用来与 Raspberry Pi 上的电子元件交互。2026年2月，我们发布了 V4，其中有一个使用 Foreign Function & Memory API 的新插件。我们在发布前进行了彻底测试，但尽管如此，发布后不久就有人 报告说使用 5 个输入按钮无法按预期工作。按下前四个已配置按钮中的一个会按预期触发代码执行，而第五个按钮毫无反应。
这是你不想收到的那种报告。没有任何明显损坏的迹象。没有异常，日志中没有警告，第五个按钮就是静默无反应。更糟的是：使用旧的 gpiod 插件时，完全相同的硬件和完全相同的应用程序运行正常。所以问题出在我们新的 FFM 代码中，它位于 Linux 内核的 GPIO 字符设备之上，并通过原生调用与之通信。这可不是代码库中你能指望快速找到答案的部分。
于是我把这个问题分配给 Copilot 编码智能体，并给了它两个文件路径作为起点：provider 类和 FFMDigitalInput。大约半小时后就出现了一个拉取请求，附带一个我完全没有预料到的解释。
每个输入都会运行一个事件监视器，它在原生 poll() 调用中阻塞，等待内核报告其 GPIO 线路上的变化。这些监视器运行在虚拟线程中。而在原生调用中阻塞的虚拟线程无法从其载体线程上卸载。它会在整个调用期间被固定在那里。Raspberry Pi 4 有四个核心，因此虚拟线程调度器有四个载体线程。注册四个输入后，所有四个载体线程就永远停泊在 poll() 中。第五个监视器被创建了，但从未被调度。这正是所报告的那个 bug。不是“事件不稳定”，而是“第五个毫无反应”。
我最喜欢的不是 diff，而是随后的评审对话。我留了一条评论，请 Copilot 更详细地解释这一点：
我以为虚拟线程的目标恰恰是摆脱平台线程的限制？那么为什么四个虚拟线程阻塞四核处理器（如 Raspberry Pi）上的四个线程会成为一个问题？
查看 拉取请求中的完整对话。Copilot 能够将拥有四个 CPU 核心的 Raspberry Pi 与所报告的问题联系起来。它能够为该问题提出一个简单的修复方案，外加它在调查过程中发现的一些额外改进。
你能分享一些技巧和最佳实践吗？
- 告诉它去哪里查找： 针对 Pi4J issue #4，也就是 #622，我添加了两个文件路径。这只是微不足道的努力，却省去了在大型代码库中大量搜索的功夫。即使你对 bug 一无所知，通常也对大致区域有个直觉。把它告诉工具，这样它就不必调查整个代码。
- 要求提供证明和测试： “添加一个单元测试来验证更改”是我近来经常提出的要求。确切地说是曾经经常提出，因为它现在已成为我指令文件中的一条规则。这也能防止诊断错误的情形，因为测试不会在旧代码上失败。
- 询问原因： 如果你不理解某个修复，就直说并提问。解释本身也是一项交付成果，应添加到项目文档中，或写入工单或 pull request 里。这能让后来阅读这些信息的每个人都学到东西。例如，这也在 Pi4J 团队内部引发了关于本地调用中虚拟线程固定（virtual thread pinning）的更多讨论。
- 保持掌控： Pi4J 中的所有这些 pull request 在合入之前都经过了维护者的审查和批准。这是这个项目中效果最好的模式：代理负责调查，人类对发布的内容负责。对于我的其他项目，我也总是会对工具生成的代码进行审查。我始终希望保持代码的可读性和可维护性。工具经常会创建重复的方法，或者重新实现某个其他地方已经存在、本应合并的内容。这是你的责任。如今借助 AI 辅助编程你可以走得非常快，这也意味着你可能很快制造出一团乱麻。别那样做，保持代码易于管理，当你的同事和未来的自己以后需要调查 bug 或进行改进时，他们会感谢你的。
标签：
作者：
首席云倡导者
相关文章
AI 与机器学习如何在 VS Code 中继续 GitHub Copilot 应用的会话
了解如何将代理会话从 GitHub Copilot 应用迁移到 VS Code，而不会丢失对话、代码更改或工作上下文。
AI 与机器学习GitHub 的密钥检测模型：以更少的噪音发现更多密钥
GitHub 具备上下文感知能力的密钥分类器提升了检测质量，将加权接受率提高了 11.5%，并将中位数扫描执行时间缩短了 86%。
AI 与机器学习初学者的 GitHub Copilot 应用指南：如何让 Copilot 了解你的代码库
了解如何向你的仓库添加自定义指令和技能、使用自定义代理，以及连接像 Playwright 这样的 MCP 服务器。