第一时间捕获有价值的信号
本文整理自 InfoQ Dev Summit Munich 上 Patrick Debois 的演讲 4 Patterns of AI Native Development。Patrick Debois 是 DevOps 概念的创始人之一，合著了《DevOps 手册》，并于 2009 年发起了首届 DevOpsDays。本文将探讨他提出的 AI 原生开发四大模式，以及这些模式如何重新定义开发者的工作方式。
前言：AI 正在改变开发的一切
一年半前，我们还会骄傲地展示一张由 AI 生成的图片，问大家：“你能猜出这是 AI 生成的吗？” 今天，这已经司空见惯。Patrick Debois 用四匹马的图片开场——独角兽不存在，我们都需要努力工作，而 AI 正在让这一切变得既令人兴奋又带点未知的迷茫。
从 Tab 补全到 Copilot，从代码建议到多文件生成，从 IDE 中的 AI 到终端里的 AI，再到浏览器中的 AI——我们的开发环境正在被 AI 全方位渗透。测试生成、完美测试覆盖率、MCP 服务器……工具在爆炸式增长。
Debois 指出，他年初整理的 AI 原生开发工具 landscape 大约有 250 个工具，现在已经超过 600 个。这是一个混乱的时期，就像当年云计算、安全工具、DevSecOps 刚出现时一样，我们都在尝试弄清楚什么有效、什么无效。
关键的是：没有人是专家。 这就是现实。Debois 说他也不是专家，但他投入了时间去尝试、去玩、去给人们解释这些事情。就像当年他写《DevOps 手册》时试图理解那个世界一样，现在他正试图理解 AI 原生开发的世界。
什么是 AI 原生？
当我们把东西移到云端时，我们说：“让我们把整个 VM 都搬过去。” 现在你看到人们说：“我们现在是 AI 原生的了。” 他们在自己的东西上撒了一点 AI，然后就说自己是 AI 原生的了。当然，这不是真的。
我们仍在探索 AI 原生的真正含义，但这就是我们正在经历的旅程。作为开发者，每当新技术出现时，我们的一些任务会被技术以更快的速度取代，同时一些新任务会出现，一些任务会改变。
Debois 喜欢用”任务拆分”的可视化来描述这个过程。很多人说：“这只是更快的打字方式。” 不，事情正在改变我们的工作方式。
模式一：从生产者到管理者
第一个模式是人们通常最先体验到的：你让 AI 生成代码，现在你不再做太多创建工作，而是要判断什么是好的、什么是坏的。你不再是代码的生产者，而是成为了管理者。
代码审查成为新的挑战
代码生成正在爆炸式增长。Debois 听到越来越多的人说，使用这些工具提高效率后，真正的挑战其实是审查。
还记得多文件差异对比吗？谁喜欢读它们？Debois 坦白自己是色盲，红、绿、灰对他来说很难区分。他也不想看所有的聊天视图，因为没有时间。
Cursor Composer 曾经有一个功能很有意思：审查时显示代码，但带有内联注释。这让理解发生了什么变得更容易一点——只是，这是那个变化中改变的东西。这只是一个例子，说明我们需要寻找减少认知负荷的方法，因为生成得越多，我们要花的时间就越多。
审查不一定是文本。 有时在图表上进行审查更有意义。为什么差异对比不适应图表呢？
有个公司已经不存在了（又是工具列表中的一个），但这个概念很有趣：展示变化到底是什么。Google 有 NotebookLM 来构建播客之类的东西，然后 Google 说：“这是个好主意，我们为什么不做一个 Codecast 呢？” 早上我们就听听 LLM 谈论它做的所有牛逼代码更改。可能不是最好的方式，但 Debois 想指出：它不一定是文本，可以是音频，可以是任何提示。
可塑开发环境
有个网站叫 Moldable Development（可塑开发环境）。我们看到从 IDE 回到终端的趋势，但 Debois 仍然用 IDE 做审查，但如果 IDE 实际上能更好地处理审查任务呢？现在还处于早期阶段，但这就是我们看到的处理这些代码变更的新兴方式。
有趣的是，通过 MCP，我们的聊天中可能也会有更多 UI 元素。不只是文本，也许会有一个小部件进来帮助他们，类似于那个图片审查。
自动提交与回滚
如果我们直接自动提交，然后在需要时回滚呢？我们把桌子翻过来。Aider 是第一个说”我就自动提交了，如果你不喜欢，你来回滚”的工具。很有意思。我们什么时候能确定这一点？这是 Debois 最大的抱怨：代码生成越快，这些决策就越会拖慢我们的脚步。这某种程度上给那个进化踩了刹车。
我们开始创建更安全的环境。Agent 生成代码，而我可以回滚。到这里都还不错。这有助于在自动提交的安全环境中，但仍然能够回滚，类似于 CI/CD 系统，但现在它发生在你的 IDE 中，而编码 agent 在你的笔记本上做所有事情。
我们都成了 Ops
然后我们进入了另一个有趣的领域：AI 实际上被允许接触我的代码库中的哪些部分？突然间，我们变得像是用户管理和访问管理器。AWS 发明 IAM 还不够复杂，现在它就发生在我们的编辑器里。我们变成了那个说”你可以访问那个，不能访问这个”的人。
然后我们还要担心成本，因为 agent 一直在运行。看看我的账单，烦人。我想用它，但另一方面，人们或公司开始有那个 max 计划，然后人们滥用了那个 max 计划，他们都回到了”四小时有上限，然后你得等”。成本管理有点像 FinOps，就在我们的 IDE 里。
我们都成了 Ops。 我们都在审查别人构建的代码。当我们把它投入生产时，我们要对那段代码负责。如果晚上发生了什么事，agent 可能帮不了我们，但我们得处理它。这可能就是那个管理者角色的转变：担心成本，担心我的 agent，告诉他们做什么，然后从那里开始。
DevOps 的类比
如果用 DevOps 来类比，我们曾经对基础设施即代码非常满意：很棒的自动化，我现在可以一次性删除所有系统。然后我们引入了安全、CI/CD 系统、更多测试等等，但后来意识到我们仍然需要在生产中做这些，而 IDE 在把东西投入生产方面仍然非常薄弱。提交是一回事，如何推送到生产还很遥远。
弹性工程可能帮助我们重新思考构建应用的方式，以及 AI 给我们带来的风险。然后我们有了可观测性。就像这是一件非常常见的事情：如果我们不再生产代码，而你成为了管理者，你怎么知道好是什么样子？因为你不再做了。
混沌工程非常相似。我们开始引入故障，这样我们就可以持续训练，并在事情失败时保持警惕。也许这就是我们的新职业：成为事情失败时的消防员，我们必须处理它。显然，这会很有趣。如果发生了什么事，哪个 agent 做了什么？谁对什么负责？我不知道。
模式二：从实现到意图
我们都成了管理者。这可能从审查者到处理，并实际负责去做那件事。这假设我们仍然非常紧密地告诉 AI 做什么，而我们处于那个配对模式中。
如果你可以只给”这里有一堆需求，agent，编码出来，然后我们做审查，我们负责”呢？Debois 现在要讲在做那件事之前的一个步骤。
规范驱动的开发
告诉人们做什么——我假设有一些架构师，你们非常擅长这个。或者 QA 人员，他们测试东西，他们知道要找什么，然后去做那件事。
在这个模式中，Debois 要解释我们想要表达我们的意图，然后编码由 agent 完成，但我们实际上少担心一些非常详细的事情，比如实际的实现。只要我们的测试通过，只要我们的需求通过，我们就 ok。这仍然有点像白日梦，但它让你进入也许我会去那里的心态。
用一种非常粗糙的方式，Cursor 规则已经是一种给我们的 agent 设置一些需求的方式。我告诉它我喜欢我的代码是什么样的，我希望事情如何完成。现在我们在行业中有了更多的标准化，通过 AGENTS.md，我们不依赖每个工具把它放在哪里，但我们可以在多个工具中重用 AGENTS.md。进步。
然后你看到人们做的不只是放技术需求、我们团队如何工作，他们开始重用功能需求的规范。他们不做提示，而是”让我把所有东西重写在一个 markdown 文件里，然后把它传到提示里”。一种非常粗糙的方式，但你看到人们在构建那个。
这来自 GitHub。我们不再在他们的聊天循环中了，我们只是说：“我有一个任务，我写一个规范，agent 规划它并推出它。”
他们甚至实验，当他们说：“那个自然语言应该是什么样的？” 我认为辩论还没有结束，那个规范的格式是什么？大多数人只是用 markdown。我认为 LLM 大致足够理解如何做那件事。他们最近带来了 Spec Kit，规范驱动的开发，规范从那里开始。这有点实验性，但它传达了这个想法。
OpenAI 也一直在谈论规范，但他们是为了另一个原因做的，他们是为了训练模型做的。你显然可以重用那些规范作为需求来实际也实现事情。然后来自 AWS 的 Kiro 可能是第一批在他们的编辑器中认真做这件事的 IDE 之一。
双向同步
Debois 想要指出的一件事是：我们如何在规范和实现之间保持同步？因为这一直是个问题，对吧？我们写了需求文档，然后我们偏离了，没有人更新那个需求文档。在这个新世界里，如果我更改规范，我的代码会更新吗？如果我更改代码，我的规范会更新吗？这有点像那个双向同步的事情，我们需要弄清楚，以便我们能够在这两个世界中保持最新。
其中一个例子是：你有一个现有的代码库，你实际上把它转换成规范，然后你可以从那里去重写你的应用程序，或者你可以开始为你的代理团队写一个全新的应用程序。
谁将拥有那个规范？是架构师吗？是产品负责人吗？是 QA 人员吗？还是我们会有一个新的角色，就像我们有 DevOps 工程师一样，我们会有提示工程师？我不认为提示工程师会是那个，因为如果有一件事我们已经学会了，就是提示是短暂的。你今天写的提示，六个月后就没用了，因为模型变了。所以那不会在那里。
但我们可能需要一种新型的技术作者，他们真正理解如何为人类和 AI 写文档。这可能是会出现的角色之一。
模式三：从交付到发现
第三个模式：从交付到发现。Debois 必须承认他偷了这个标题，或者他问了他是否可以用这个标题，来自 Emil 的一个演讲，叫”从编程到园艺”。他真的很喜欢那个。
这个想法是：我们不再做线性交付，而是同时尝试很多不同的事情。把我们自己从只做一件事、线性地推向生产，变成真正在做很多实验的园丁，看看什么有效，什么无效，然后我们才能从中学习。
Vibe Coding
有个叫”Vibe Coding”的概念，来自 Swyx。这个想法是：如果我不只是和一个 agent 一起工作，我实际上同时和多个 agent 一起工作，看看什么有效，什么无效呢？
我们可以用 Git worktree 已经有点这样做了，对吧？我们可以有多个 worktree，我们可以在不同的容器中尝试不同的变化，我们真的可以隔离变化。但现在有了 AI agent，我们可以让多个 agent 同时工作，然后比较结果。
Debois 给我们看了 Claude Squad 的一个演示：你可以有多个 agent 同时处理一个问题的不同方面，然后他们互相分享知识。这不是一个 agent 按顺序做所有事情，而是多个 agent 并行工作，然后你可以选择最好的想法或合并最好的部分。
蜂群编码 / 群体编码
有些人称之为”蜂群编码”（Hive Coding）或”群体编码”（Swarm Coding）。这个想法是多个 agent 共享知识并互相学习工作。你不是只有一个 agent，而是有一群 agent，他们都在同一个问题上工作，但从不同的角度。
这不仅仅是并行运行多个 agent，而是让他们真正地交流和协作。一个 agent 可能想出一个想法，另一个 agent 可以在此基础上构建，第三个 agent 可能会发现一个缺陷，他们一起工作来完善解决方案。
Debois 指出，这改变了我们思考交付的方式。我们不再试图线性地交付一个完美的解决方案，而是探索多种可能性，学习什么有效，然后根据我们学到的东西进行迭代。这更像是发现而不是交付。
管理多个上下文
当然，这带来了新的挑战。你如何管理多个 agent 上下文？你如何处理并行实验之间的合并冲突？你如何比较不同的方法并选择最好的？
这些是我们仍在弄清楚的事情，但模式很清楚：我们正在从”找到一个正确的方法并交付它”转变为”探索许多可能性，发现什么有效，然后学习并迭代”。
模式四：从内容到知识
第四个模式是从内容到知识。我们不仅仅是在生成内容（代码、文档、测试），我们还在管理组织知识。
捕捉知识，而不仅仅是生成代码
Debois 讨论了从各种来源管理组织知识，包括文档、事件响应、代码库和开发历史。他谈到将开源库转换成规范，并使用 AI 进行训练和知识保存，而不仅仅是代码生成。
这个模式引入了”agentic UX”概念，系统从开发者交互中学习，并在开发流程中捕获知识。这包括维护事件响应历史以防止重复错误，跟踪失败的功能实验，以及创建反馈循环，让 agent 根据开发活动更新文档。目标是将静态文档转换为动态的、学习型的知识系统，随着时间的推移而改进。
事件响应即学习
一个例子是事件响应。当出现问题时，我们不仅修复它，还捕获关于哪里出错了、为什么出错、我们如何修复它的知识，然后确保 agent 将来不会犯同样的错误。这不是静态的事后分析文档，而是 agent 实际可以用来学习和改进的动态知识。
另一个例子是跟踪失败的实验。我们经常尝试一些不起作用的事情，但我们没有捕获关于为什么它不起作用的知识。然后六个月后，其他人（或者我们自己）尝试同样的事情，犯同样的错误。通过用 AI 捕获这些知识，我们可以确保我们从失败中学习，而不仅仅是从成功中学习。
从文档到学习系统
Debois 认为，目标是将静态文档转换为随时间改进的动态学习知识系统。这不仅仅是写下来的东西，而是实际在开发过程中使用、学习和进化的东西。
当 agent 工作时，他们不仅在生成代码，还在捕获关于我们如何工作、什么有效、什么无效、我们做出了什么决定以及为什么的知识。这种知识然后被反馈到系统中，所以未来的 agent 可以从我们的经验中学习。
总结与问答
Debois 总结说，这些模式代表了 DevOps 工作流在开发者笔记本上的根本性重组，创造了他描述的”现在回到我们笔记本上的 CI/CD 工作流”，agent 处理以前由管道系统管理的任务。
问答环节
问答环节涉及了几个问题：
成本可持续性： Debois 指出，虽然 LLM 成本正在下降，基础设施正在改善，但当前的定价可能代表了提供商的”资金流血”，长期可持续性取决于找到正确的投资回报率。
初级开发者： 关于 AI 阻止通过实践学习的担忧，Debois 认为初级开发者现在有”一个整天帮助我变得更好的东西”，而不是需要 15 年才能发展专业知识，尽管他承认需要创建”故障安全学习环境”。
团队结构： 未来可能涉及更小、更专注的团队，能够通过 AI 辅助处理以前的多学科角色，尽管确切的组织结构仍然不确定。
最后的思考
演讲强调，虽然 AI 改变了开发实践，但在审查、架构决策和理解”好是什么样子”方面的人类技能对于成功的软件工程仍然至关重要。
我们可能不再是编写每一行代码的生产者，但我们是决定什么是好的、什么方向是正确的、我们想要构建什么的管理者。我们可能不再实现每一个细节，但我们是表达我们意图并确保结果符合我们需求的人。我们可能不再线性交付，但我们是探索可能性并发现什么有效的人。我们可能不只是创建内容，但我们是管理和增长组织知识的人。
这就是 AI 原生开发的四大模式。而这仅仅是个开始。