系统化AI编码：我从布鲁塞尔Eclipse基金会工作坊的收获

Eclipse 基金会举办了他们的首次 AI 编码工作坊。这是一个全新的活动形式，在布鲁塞尔启动，这很合理：Eclipse 活动团队的大部分成员都位于欧洲心脏地带的布鲁塞尔。计划是从这里开始，将这一形式推广到更多城市，所以如果你未来想参加这样的工作坊，请多加留意。他们提供了 10 张免费门票，与 BeJUG 和 Foojay 社区分享。老实说，我自己用掉了一张😉。工作坊由来自 EclipseSource 的 Jonas Helming 主持，下午还有 Thomas Froment 主持的有趣问答。以下是我的收获。

[LOADING...] [LOADING...] [LOADING...] [LOADING...] [LOADING...]

从“氛围编码”到系统化编码

工作坊以一个重要的引导性问题开始：我们在 AI 编码的旅程中处于什么位置？Jonas 将 AI 辅助分为 1 到 5 级，1 级是基础代码建议，5 级是完全自主。目前我们通过 Claude Code 等工具已达到 4 级。当完全基于云的自主智能体可用时，5 级即将到来。

大多数开发者目前仍处于某种“氛围编码”区域。氛围编码是一种“做什么，而不是怎么做”的方法：你描述你想要什么，不太仔细（或根本不）查看生成的代码，专注于结果。它对于原型设计和已知领域的低复杂度问题可能效果不错，但一旦进入真正复杂项目的实际项目，它很快就崩溃了。

工作坊的核心根本转变是，从实验阶段走向可重复且系统化的阶段。Jonas 称之为系统化 AI 编码：理解编码智能体实际上如何运作，并围绕它们构建工作流程，而不是仅仅给出提示并期望结果。

编码智能体实际上如何工作

最有用的环节之一是剖析编码智能体内部发生了什么。很容易将其视为一个魔法盒子，但其中的机制对于正确使用它非常重要。

一个编码智能体接收多个输入：系统消息、用户消息、助手回复、你的代码库以及你提供的任何额外上下文。这个上下文包括项目上下文、任务上下文（你的计划）以及智能体可用的技能或工具。除此之外，你还可以有可选的智能体分层，比如一个模型路由器，为任务选择合适的模型。

从那里开始，智能体使用工具、调用 LLM 并生成变更集：文件、操作、上下文更新、MCP 调用。所有流程都通过 Jonas 描述的请求模型的一部分流动：工具 + 消息 + 工具消息 + 工具响应。这一切归结为一个词：上下文。上下文就是一切。

一个关键见解：LLM 是无状态的，会立即遗忘。 每次运行时，你需要重新发送完整的对话历史，它才能理解之前发生的事情。这有一个实际后果：上下文被污染，成本上升，因为需要额外的 token 来处理输入。还有一个被称为“愚蠢区”的微妙陷阱：在你达到上下文窗口限制之前，效率实际上已经下降。根据一些实验，这大约从上下文容量的 ±40% 开始。所以，一个感觉上仍在工作的会话可能已经产生更差的结果。

工作流程

一旦你理解了智能体如何工作，实际的工作流程就更有意义了。大致如下：你的 AI 智能体生成输出，你需要审查或决定。从那里你有几个选择：退出（中止）、优化（调整提示）、重做（开始新的聊天）、进一步划分任务、压缩会话、调整智能体配置，或者提交有用的内容。然后重复。

Jonas 在此提出了两个重要要点：

• 不要害怕丢弃更改并重新开始。 一个带有更清晰、范围更明确的提示的新会话，通常会优于试图挽回一个已经偏离方向的会话。你可能会有“编码工作丢失”的糟糕感觉，这种感觉是真实的，但无关紧要，因为那不是你的工作，而是工具完成的。
• 自己压缩会话，不要依赖智能体来做。 如果你让智能体自动压缩，你就会失去对哪些上下文被丢弃的控制。自己动手意味着你决定保留什么。

一个我应该遵循的技巧：当你的 AI 工具正在工作时，不要在其他项目中开始另一个会话。看看窗外，思考你正在解决的实际问题，以便更好地处理结果。对于人类来说，上下文切换代价也很高。

使用 AI 时，时间变了

没有 AI，开发者通常将大约 70% 的时间花在设计和编码上，30% 花在调试上。有了 AI，时间分配看起来完全不同：

• 设计：约 30%
• 审查：约 30%
• 调试：约 35%
• 实际 AI 生成的代码：约 5%

工作并没有消失，而是发生了转移。你花更多的时间思考、审查和调试，花更少的时间敲代码。这对你如何执行任务有影响。

设计 — 在你向智能体发出提示之前：

1. 思考任务是否应该拆分。
2. 精确描述你的意图。
3. 提供示例、相关文件和现有实现。
4. 给智能体一个验证自己输出的方法。
5. 应用“好朋友”隐喻：分享你自己代码库中那些你会告诉新同事的技巧和诀窍。

审查不是可选的：

1. 首先，找出阻碍因素。
2. 决定后续行动（优化、重做、拆分等）。
3. 只有在没有剩余阻碍因素时：进行详细审查以完成任务。

“完成”不等于“就绪”

一个值得单独列出的幻灯片标题：完成 ≠ 就绪。

当智能体说它完成了，这并不意味着可以推送了。AI 生成的代码可能在质量上漂移，引入安全风险，并产生让你同事沮丧的“工作废料”。在推送之前，要像一位细心的同事那样进行审查。

公司需要为此提供什么

Jonas 强调了公司如果想真正实现系统化 AI 编码，需要为其开发者提供的几个重要条件：

• 工具（需要花钱）
• 时间来学习和实验
• 空间来实验并在团队中分享经验

第三个常常被低估。个人实验很好，但如果没有机制来分享哪些方法有效，团队就永远不会共同进步。

在 Eclipse 方面

Thomas Froment 还进行了一个简短的问答，涵盖了一些值得了解的 Eclipse 基金会项目。

• Open VSX 是 Visual Studio Marketplace 的一个开源、供应商中立的替代品：一个开放注册表，一个开源项目，以及一个工作组。
• Theia IDE 基于 Theia 平台，是一个现代、AI 原生的 IDE，适用于云端和桌面。它拥有许多方便的开发者 AI 工具，例如显示智能体采取的每一步、token 使用情况、一个 @PR Review 智能体（你可以给它一个 PR 号，它会检出、构建、运行并制定审查计划）等。

最后的想法

感谢 Eclipse 基金会提供的免费门票，完美的组织工作，以及所有参与的 BeJUG 和 Foojay 成员！这是他们第一次以这种形式举办工作坊，我希望他们很快能将其带到更多城市。也感谢赞助商，他们提供了良好的场地、专业的技术团队和一整天的美食。

这是充实而实用的一天。这篇总结只是 Jonas 在四个多小时里分享的所有技巧、窍门、提示、陷阱和其他知识的很小一部分。他还有一个更长版本的此工作坊，会在公司和其他活动中讲授。如果你有机会见到他或参加其中一次会议，你一定要去！

对我来说，最大的转变不是任何一个单一技巧，而是从氛围编码转向系统化编码的重要性。AI 编码不是魔法，也不是捷径。它是一种不同的工程学科，有其自己的工作流程、失败模式和学习曲线。最受益的开发者是那些认真对待它、建立可重复流程并将工程判断力置于核心位置的人。

附注

Jonas 还指出，你可以将这些 AI 工具用于编码之外的更多领域。所以，再次实话实说，这篇博客是在我从布鲁塞尔到科特赖克的火车上，由 Claude Code 创建的。该工具能够使用我从 reMarkable 手写笔记导出的 PDF。当然，经我本人进行了完整的审查、重写和微调😉。

原文 Systematic AI Coding: My Takeaways from the Eclipse Foundation Workshop in Brussels 首发于 foojay。