Armin Ronacher 是编程圈内颇具影响力的技术专家，对于 Python 开发者而言更是耳熟能详。他不仅是资深的开源爱好者，更是 Flask、Jinja2、Sphinx 等知名框架与工具的创造者。
站在 2025 年末，这位技术领袖撰写长文，毫无保留地分享了使用 AI 进行编程一整年的真实体验——涵盖工具选择、工作模式变革、与机器的关系思考，以及对行业未来的展望。
不一样的 2025 年
这一年充满了变化。我不仅离开了之前的公司并创办了新企业，更重要的是彻底改变了以往的编程方式。到了年中，我已经可以自信地分享这种全新的工作模式：
以前我整天沉浸在 Cursor 中写代码，现在则几乎完全依赖 Claude Code，很少需要亲自敲击键盘。……如果在半年前，有人告诉我比起自己写代码，我更愿意扮演工程负责人的角色，带领一个虚拟的“程序员实习生”工作，我绝不会相信。
去年我本就计划多进行写作，这个想法最初与智能体编程无关。但一年下来，我竟然发布了 36 篇文章——这几乎占我自 2007 年开通博客以来总内容的 18%。我还与众多开发者和创业者进行了上百次关于 AI 的交流，因为深入智能体的世界后，我的好奇心被完全激发了。
智能体元年
一切始于四五月份，当时我迷上了 Claude Code。随后的几个月，我一边构建自己的智能体程序，一边试用他人开发的工具。那时社交媒体上充满了对 AI 的讨论，观点各异，褒贬不一。
如今，我对于该领域的现状和未来，终于形成了一套相对稳定的见解。我决定专注于代码生成、文件系统操作、基于解释器的程序化工具调用，以及技能导向的学习这几个方向。
归根结底，Claude Code 开创的模式在我看来依然是顶尖的。过去几个月的实践效果显著，并且看到各大基础模型厂商都在加码技能研发，我更加坚信这条道路的可行性。
我至今仍感到惊讶，文本用户界面竟能如此强势地回归。我目前常用的三个工具：Amp、Claude Code 和 Pi，全都基于命令行操作。
- 在我看来，Amp 像是智能体编程工具中的高端品牌，设计精良。
- Claude Code 则提供了极高的性价比。
- Pi 则是崇尚开源与自由的黑客们的首选。
这几款工具给我的共同感受是：它们的开发者自身就是重度用户，甚至会过度依赖这些工具来构建自己的产品，只是各自的侧重点有所不同。
大型语言模型与工具执行功能结合的威力，依旧让我惊叹。年初时，我还主要用它们来生成代码，如今日常事务处理也已离不开智能体的协助。
我确信，2026 年一定会涌现出大量令人眼前一亮的消费级 AI 产品。现在 LLM 已经能协助我进行生活规划，并且我认为这项功能未来会变得更加强大。
我与机器
由于 LLM 现在不仅能帮我写代码，我开始重新审视自己与这些机器的关系。我越来越察觉到，自己很容易对常用工具产生一种“拟社会关系”，这种感觉既奇特又令人不安。
我们目前使用的大多数智能体缺乏记忆和个性，但构建一个具备这些特征的智能体其实并不困难。一旦体验过拥有记忆功能的 LLM，那种感受就难以忘怀。
这种感觉既有趣，又令人不禁质疑。两年来，我一直努力说服自己这些模型只是字符处理器，但现在我发现，这种简化观点已经站不住脚。我们构建的这些系统的确带有一些类人的特质，但若将其等同于人类，则是完全错误的。
我越来越不赞同用“智能体”来称呼这些机器，却又找不到更贴切的词语。我反感这个称呼的原因是：能动性和责任理应归属于人类。无论这些机器最终形态如何，它们都能引发我们的情感反应，稍不注意，这种反应就可能带来负面影响。我认为，我们当前面临的一个难题正是：无法准确定义这些产物，也无法理清它们与人类的关系。
正是由于这种无意识的拟人化倾向，我有时不知该如何描述与机器的协作方式。我知道这并非个例，很多人都有同感。尤其是在与那些坚决抵制 AI 系统的人共事时，这种感觉会更为明显。我阅读了许多关于智能体编程工具的文章，发现一个普遍观点是：人们反对赋予机器以人格。
众说纷纭
大量使用 AI 后，我观察到一个意想不到的现象：比起技术本身，人们更热衷于讨论使用这些工具的“感觉”。这种工作模式出现还不到一年，却挑战了半个世纪以来形成的软件工程经验。因此各种观点纷至沓来，无人能确定哪些论断能经受住时间的考验。
我发现许多行业共识都经不起推敲，但我也无法提供确凿证据进行反驳。我能如何证明呢？一整年我都在说 MCP 用起来不顺手，但除了“它不适合我”之外，我也没有其他理由。偏偏有人将其奉为圭臬。
选择模型也是如此。年初是 Peter 引领我使用 Claude 的，结果他后来转而使用 Codex，并表示体验良好。我现在也常用 Codex，但体验远不如 Claude。我偏爱 Claude，说到底也只是因为“感觉对了”。
还有一点很重要：许多所谓的“感觉”，实际上是被人为塑造的。你在网络上看到的观点，常常带有利益倾向。例如，有些人是相关产品的投资者，有些则是收取费用的推广者。他们或许真心喜爱产品才进行投资，但也有可能，他们的观点早已被这种利益关系所影响。
外包还是自研
如今，你随意查看一家 AI 公司的代码库，很可能会发现它们要么使用 Stainless 开发，要么用 Fern 构建；文档工具不是 Mintlify；网站的身份验证系统，大概率是 Clerk。许多公司都在提供现成的服务，而这些服务在过去往往需要自行开发。将核心服务外包给专业公司的趋势日益明显，这也使得打造出色用户体验的门槛不断提高。
但借助智能体编程工具，我们实际上有能力自行实现大部分功能。我就曾让 Claude 帮我构建了一个支持 Python 和 TypeScript 的 SDK 生成器：一方面是出于好奇，另一方面也是因为这件事做起来确实不难。熟悉我的人都知道，我一直倡导代码简洁和自主构建。这让我对未来抱有一丝乐观：AI 或许能鼓励人们减少对第三方工具的依赖，更多地自主开发。但与此同时，目睹当前各行各业一窝蜂地进行外包，我也不确定我们真能朝着自研的方向发展。
心得体会与未来期许
接下来我不想做什么预测，只想聊聊我希望未来能获得更多关注的几个方向。实际上，我也无法确切说出自己寻求的答案，只是想分享一些痛点，为大家提供思考的素材。
1、新型版本控制系统
我最大的意外发现是：传统的代码协作工具已经跟不上时代了。
GitHub 的 Pull Request 模式，根本无法提供足够的信息来审核 AI 生成的代码，我真心希望看到每一处修改背后对应的提示词。存在这个问题的不仅是 GitHub，Git 本身也存在局限。
在智能体编程模式下，模型要正常工作，关键在于记住之前犯过的错误。如果你想把模型状态回滚到某个时间点，就需要工具能准确记录哪里出了问题。
简而言之，失败的经验也具有价值。对人类而言，了解哪些路径行不通或许也有益处，但对机器来说，这些失败经验至关重要。当你尝试压缩对话历史时就能体会到：如果删除了那些偏离正轨的尝试，模型下次很可能会重蹈覆辙。
目前已有一些智能体编程工具开始尝试解决方案，例如创建工作树，或在 Git 中设置检查点，实现恢复、对话内分支和撤销功能。这个领域的用户体验还有巨大的创新空间，能让工具用起来更加顺手。这或许正是如今大家都在讨论堆叠差异，以及像 Jujutsu 这类新型版本控制系统的原因。
这种变革是会撼动 GitHub 的地位，还是将为新的竞争者创造市场空间？我真诚希望是后者。我越来越希望能清晰地区分人类的真实输入与机器生成的内容，也希望看到每次修改对应的提示词，以及过程中的失败尝试。我还希望，在代码合并时能将这些信息压缩整合，但在需要时又能完整地调取出来。
2、新型代码审核模式
这一点与版本控制系统紧密相关：现有的代码审核工具设定了严格的角色权限，与 AI 的工作模式完全不匹配。
以 GitHub 的代码审核界面为例：我经常想在 PR 页面添加一些备注，留给我自己的智能体参考，但根本没有合适的入口。而且这个界面不允许我审核自己的代码，只能添加评论，这与我的实际需求相去甚远。
还有一个问题：目前我和智能体之间的许多代码审核工作，都是在本地完成的。例如，我就无法使用 GitHub 上的 Codex 审核功能，因为它一次只能绑定一个组织。
无奈之下，我只能在命令行中使用 Codex 进行审核，但这意味着我整个开发迭代过程中相当大一部分工作，对团队中的其他工程师是不可见的。这显然不是长久之计。
在我看来，代码审核功能应该成为版本控制系统的一部分。
3、新型可观测性方案
我认为，可观测性领域即将迎来新一轮变革。现在我们既有需求，也有机会将这一领域提升到全新的高度。过去大多数人难以驾驭 eBPF 程序的开发，但现在 LLM 能够轻松应对。
同样，许多可观测性工具都因 SQL 语言复杂而避之不及，但 LLM 处理 SQL 的能力，比任何专有查询语言都要强大。它们能够编写查询语句、进行文本检索、执行映射归约操作，还能远程操控 LLDB。
任何具有一定结构化和文本内容的事物，如今都成了智能体编程工具大展身手的舞台。我无法预知未来的可观测性方案具体形态，但我强烈预感这一领域将涌现大量创新。毕竟，机器的反馈循环越顺畅，最终效果就越好。
实际上，我也无法具体描述自己想要什么，但我知道，过去许多关于可观测性的精妙构想——尤其是为了更精准过滤而动态重构服务的思路——都因操作复杂、对用户不友好而未能实现。如今有了 LLM，它们能处理这些繁琐工作，那些旧有的构想或许就能重获新生。例如 Python 3.14 版本新增的外部调试器接口，对于智能体编程工具而言，简直是如虎添翼。
4、应对冗余与混乱
接下来的观点可能有些争议：今年我始终无法做到完全依赖机器。我仍然沿用传统软件工程的思路工作，坚持进行大量的代码审核。但我也注意到，越来越多的人已经抛弃了这种模式，选择完全信任机器。
虽然听起来有些极端，但我确实见过不少人以此种方式取得了成功。目前我还无法评判这种模式的优劣，但我很清楚，尽管最终产物都是代码，但这种全新的工作模式，与我熟悉的那一套已截然不同。
并且我有种预感，既然这种新模式已经站稳脚跟，我们或许需要建立一些新的行业共识，以区分这两种不同的工作方式。
这种模式带来的最直观问题，就是开源项目中这类贡献日益增多。坦白说，这种做法对于那些坚持传统开发模式的人来说，简直是一种冒犯。每次看到这类 PR，我都忍不住感到恼火。
我个人曾尝试通过贡献指南和 PR 模板来解决这个问题，但这感觉就像堂吉诃德大战风车，收效甚微。
或许解决问题的关键，不在于改变我们现有的做法，而在于需要一些支持 AI 工程的业内人士站出来，明确界定在智能体驱动的代码库中，什么样的行为才是规范的。
规范绝非随手提交一堆未经审核的代码，然后将其抛给他人处理。
（原文作者：Armin Ronacher，本文经由 AI 大模型翻译与优化）
原文链接：lucumr.pocoo.org/2025/12/22/a-year-of-vibes/
对于 AI 如何重塑开发流程以及相关的开源实战，开发者们始终保持着极高的讨论热情。若想了解更多关于 人工智能 技术趋势的深度剖析或与其他开发者交流心得，欢迎来到 云栈社区 的 开发者广场 参与讨论。
发表于 2025-12-30 04:34:08
|
查看: 21|
回复: 0
