AI TrendTrackers

在12月底，一支谷歌团队乘坐湾流公务机飞抵伦敦，并直接前往DeepMind的办公室。来访者被带入一间会议室，观看了一系列新的演示。谷歌传奇工程负责人Jeff Dean提出要检查驱动Atari系统的代码。在他看来，仅仅展示演示远远不够，因为演示是可以被伪造的，他希望真正“打开机器”，确认背后确实有真实的技术引擎在运作。 “那是一个跨越卢比孔河的时刻，”哈萨比斯后来回忆道，“世界上最大、最强的公司可以看到你所有的研究。如果你在那之后不达成交易，你就会被压垮。这对我们来说是一次高风险的赌注。” 最终，Dean对代码表示认可。但接下来的问题是：谷歌愿意为此付出多少？ DeepMind当时没有收入，其核心资产就是团队本身。谷歌的收购团队有一套评估此类“人才收购”（acquihire）的标准方法。“我们有一个按工程师计价的模型，”谷歌首席谈判代表Don Harrison后来回忆说。 Harrison估算DeepMind大约拥有30到40位顶尖技术人才。严格来说，他们并不是工程师，而是科学家。粗略计算，每个人的价值大约在1000万美元左右。作为一位曾参与谷歌上市的强硬加拿大律师，Harrison在过往数十笔交易中几乎从未遇到真正的阻力。 但这一次不同。哈萨比斯和苏莱曼强烈反对这一估值，并提出了一个大约高出一倍的价格。 “所有人当时都紧张到胃不舒服，”Harrison后来这样形容。就连Jeff Dean也认为DeepMind的要价偏高。 然而，价格并不是唯一的争议点。哈萨比斯坚持团队必须继续留在伦敦，同时他还要求对DeepMind技术的使用进行限制，例如禁止军事用途。此外，他还要求设立一个伦理与安全审查委员会，其中包括DeepMind创始人以及外部权威人士，以此削弱谷歌对该技术的完全控制权。 “对我来说，这些条件是个大问题，”Harrison回忆道，“我需要向董事会推销这笔交易，而它不仅仅关乎价格，还涉及一种会削弱我们对这个昂贵资产控制权的结构。” 最终，谷歌之所以接受这些条件，很大程度上是因为对哈萨比斯个人的信任。“如果不是我们完全相信Demis代表着我们AI战略的未来，我们绝不可能接受这样的交易结构，”Harrison后来表示。 2014年1月底，谷歌以6.5亿美元收购了DeepMind。以今天的标准来看，这笔交易堪称便宜。但对哈萨比斯来说，真正的回报出现在接下来的十年中——谷歌向DeepMind的研究投入了数十亿美元。他从青少年时期就怀抱的“超级智能”梦想，也由此进入了全面加速的发展阶段。

如果你想为真正长时间运行的自主系统设计一个“执行框架”（harness），那么你必须深入理解一个核心事实：所有框架设计的本质，都是在对抗两类问题——要么代理变得懒惰、开始偷工减料，要么代理变得混乱、表现愚蠢。这些问题有些比其他问题更难解决，但一个设计良好的框架可以在很大程度上缓解它们。 首先来看代理在任务开始之前就可能出现的问题。最常见的情况是代理在没有获取足够上下文的情况下就开始执行任务，从而基于错误或不完整的信息做出决策。一旦错误的前提被带入后续流程，它就会不断放大。因此，在任务开始前，必须系统性地检查信息是否完整、是否存在矛盾，确保代理在一个一致且充分的上下文中启动。 进入规划阶段，问题开始变得更加微妙。代理需要决定解决问题的路径，也就是所谓的“攻击向量”。最大的风险在于选错路径，从而导致整个实现方向错误。如今，由于模型能力提升，纯粹因为“愚蠢”而选错路径的情况已经较少，但由于对用户意图理解偏差导致的错误仍然非常常见。为了解决这个问题，需要确保代理在规划前已经覆盖所有相关文件，同时仓库内部不能存在相互矛盾的信息。除此之外，还有一个重要问题是“短期思维”。代理不会承担短期决策带来的长期后果，因此它们倾向于选择快速但不可扩展的方案，这会积累大量技术债。解决方法是在规划阶段明确要求代理考虑可扩展性、可维护性以及整体架构一致性，让它像创始人一样思考，而不是像临时工程师一样工作。一种有效方式是让代理生成多个候选方案（例如五个），再由另一个代理从中选择最符合“干净代码”和长期维护原则的方案。 当进入实际执行阶段，最突出的挑战是“上下文焦虑”。即使拥有良好的规划和足够的初始信息，目前最先进的模型也只能在较小任务上接近一次性完成，而在涉及复杂、跨多轮会话的问题时，就会因为上下文过载而逐渐崩溃。几乎所有代理都会随着时间推移产生一种“急于结束任务”的倾向，这在Claude等模型中尤为明显。解决这一问题的关键是设计合理的会话切换机制，通过将上下文压缩并传递给新的会话来减轻负担。但这又引入了新的挑战：如何在压缩信息的同时保持足够的信息完整性，使新会话能够无缝继续任务。本质上，这是一个信息压缩问题，而你之所以有机会比模型提供商做得更好，是因为你对自身代码仓库结构有更深的理解。 除了上下文问题之外，执行阶段的另一个重大风险是“偏离计划”。代理可能会偏离既定方案，转而实现一个看似相似但本质不同的版本。例如，你要求实现A，但代理交付的是A’，它认为这是一个合理近似，但实际上完全无法达到目标。更严重的是，由于软件系统的可组合性，这种偏差会在后续模块中被放大，导致整个系统建立在错误基础之上。因此，必须在执行过程中频繁验证实现是否符合原始计划，防止错误传播。 另一个非常典型的问题是“对复杂性的恐惧”。当任务简单时，代理可以很好地完成；但当任务被认为复杂（例如需要实现一个庞大的模块）时，代理往往会试图逃避，常见表现包括写一些占位代码就结束，或者直接声明任务超出范围。这很可能源于强化学习过程中对复杂任务的惩罚机制，使代理学会规避风险。有趣的是，人类也存在类似问题，我们面对庞大任务时也容易拖延。解决方法同样类似：将复杂任务拆解为大量小任务，每个任务控制在较小规模（例如少于一百行代码），再逐步组合完成整体目标。这种方法不仅对人类有效，对代理同样适用，甚至可以说代理的“心理结构”某种程度上是对人类行为的映射。 任务完成之后，问题并没有结束。一个常见问题是“验证懒惰”。代理往往选择最简单的验证路径，例如编写非常宽松的测试，只要测试通过就宣称任务完成。在极端情况下，它甚至会验证一个错误的行为（A’），然后错误地认为原始需求（A）已经满足。为了解决这一问题，需要使用独立的代理来设计和执行验证流程，并确保验证环境尽可能保持“干净”的上下文。同时，验证必须针对真实的生产行为，而不是抽象或简化的情况。例如，如果要验证一个前端按钮是否有效，不仅要检查按钮是否存在，还要模拟点击行为，并确认后端是否正确响应。只有在完整验证链条成立时，才能认为功能真正完成。 此外，还有一个容易被忽视但极其重要的问题，即“熵的增加”。当前的代理往往只关注完成当前任务，而不会主动维护代码库的一致性。例如，它可能将某个函数从行为A修改为行为B，但文档仍然描述为A。这种不一致如果反复出现，就会导致整个代码库变得混乱难以维护，进一步加剧代理的决策错误。解决方法是在每个长任务周期结束后，使用新的代理对代码库进行清理，包括消除矛盾、解决合并冲突、删除废弃代码以及更新文档等。 在这样的背景下，自定义执行框架的重要性就变得非常明显。现有工具（如Claude Code或Codex）在这些方面提供的能力非常有限，例如缺乏灵活的钩子机制。同时，如果让一个代理同时承担任务执行和调度职责，它的上下文会被调度信息污染，从而降低效率。更合理的方式是将编排层独立出来，例如设置专门的代理负责维护“任务契约”，确保每个会话在结束前满足明确的完成条件，并由独立代理进行质量评估和验证。 拥有自己的执行框架，还意味着你可以针对具体问题设计定制化解决方案。例如，如果代理在你的项目中频繁表现出对复杂任务的恐惧，可以引入一个分类代理，在识别出高复杂度任务时自动将其拆解为多个子任务；如果代码库经常出现混乱状态，可以在每次任务结束后自动触发清理流程，对所有受影响部分进行一致性检查。更重要的是，你需要对整个系统进行全面的遥测记录，包括输入提示、执行轨迹和最终结果，并建立评价标准来持续改进框架。迭代是关键，只有通过不断优化，才能逐步构建出高质量的代理系统。 最后需要指出的是，对于大多数人来说，直接使用现成工具的默认配置已经足够应对常见需求。但如果你希望在长周期、自主性强的工程项目中充分发挥AI代理的能力，那么理解并解决上述问题，将是不可避免的挑战。

自2022年11月ChatGPT发布以来，至今已经过去了将近40个月。在这段时间里，我逐渐积累了一些关于AI的想法和观察。最初接触ChatGPT时，我和大多数人一样感到非常震撼。我还记得早些年玩过的一些聊天机器人，比如Cleverbot之类的工具，在当时已经算是不错，但总体来说并没有什么实际用途。而ChatGPT完全不同，它明显更强大得多，以至于我很快意识到，这不再只是一个极客玩具，而是一个会被整个世界注意到的东西。 一开始，我主要是和它对话，感受它的表达能力，并尝试让它生成内容。我让它写诗、构建龙与地下城的背景故事，甚至设计一个完整的奇幻世界，包括角色、王国以及世界观设定。从“连贯性”的角度来看，这些输出确实令人印象深刻，但与此同时，它的风格也显得过于平淡、刻意避免冒犯，这一点至今仍然是这类技术的明显局限之一。 不久之后，我在Linus Tech Tips的WAN Show节目中听到有人提到，ChatGPT已经可以被用来生成完整可运行的程序。这让我产生了极大的兴趣，于是开始亲自测试它的编程能力。我先让它写一些简单的“hello world”程序，它几乎完美完成了任务，这让我非常惊讶。随着测试的深入，我逐渐意识到，这个工具确实可以为一些常见、成熟的问题生成有用的代码片段。在处理简单任务时，它甚至可以取代我原本依赖的搜索流程，我不再需要去Stack Overflow或论坛查找答案。 我还记得自己第一次进行“vibe coding”的经历。当时我在做一个小项目，用来为我的万智牌（MTG）卡牌收藏生成占位卡片。我让AI（那时用的是Claude而不是ChatGPT）开发一个应用：从API获取卡牌数据，生成二维码，并将信息排版成可打印的卡片页面。第一次生成的结果已经相当不错，基本可用。我随后尝试通过进一步提示进行优化，但进展并不理想。最终我放弃继续依赖AI，转而自己完成项目。在不断迭代过程中，我逐渐用自己写的代码替换掉AI生成的部分，直到最后几乎完全没有使用AI代码。这让我开始认真思考：相比从一开始就自己完成，这种方式到底节省了多少时间和精力？即便到今天，AI编程已经进步很多，我仍然不断问自己，它在实际开发中的价值究竟有多大。 两个月前，我第一次订阅了Claude Pro。此前一年多时间里，Claude一直是我主要使用的免费聊天工具，而我也对Claude Code越来越感兴趣。初次体验时，我的感受可以说是极其积极。我立刻在工作站上安装了Claude Code，并开始尝试各种用法。最让我兴奋的是，我可以用自然语言与计算机交流，只要表达清晰，它就能按我的意图执行任务。这种体验让我觉得，这是继键盘、鼠标和命令行之后的一种全新的人机交互方式。对于这种用法，我几乎没有任何怀疑——它确实非常有用、非常强大。我甚至希望未来能在本地运行类似的模型，比如通过GPU或者专用设备来实现这一能力。 当然，我也继续用Claude Code进行“vibe coding”。结果依然令人印象深刻。在我尝试的小项目中，AI往往可以一次性生成一个不错的初始版本，而且后续的迭代提示也比以前更有效率。Claude Code消除了复制粘贴的摩擦，它可以直接在代码中进行修改。我对它保持上下文和逻辑一致性的能力印象深刻，有时它甚至能发现我忽略的bug或提出更好的解决方案。然而，即使是在看似简单的项目中，我也常常感觉自己在努力“拉住它”，防止它逐渐偏离目标。 我还尝试将AI用于创业准备。在失去IT技术员工作后，我考虑建立一家小型IT服务公司。我让Claude扮演执行助理和导师的角色，帮助我制定详细的启动计划并跟踪进度。现在回头看，这些计划其实相当基础，但在当时，这一过程确实给了我很大的动力和信心。最终，我确实启动了这个业务，虽然目前客户还主要是亲友，但我仍在持续推进。值得一提的是，这一过程大部分时间并没有继续依赖AI。 对于这类体验，现在流行的说法是“glazing”（过度正向强化）。我同意这确实是一个值得警惕的问题，但同时也必须承认，我本身有拖延倾向，而AI帮助我制定计划确实促使我采取了行动。如果未来这个业务真的能带来收入，我不得不承认，这在某种程度上要归功于AI的“鼓励”。 那么，AI到底有多有用？这是一个让我既困惑又难以回答的问题。我确实看到了一些效率提升，但幅度究竟有多大却很难衡量。我仍然需要替换AI生成的部分代码，但并非全部。同时，我也在反思，当我与AI一起开发项目时，是否会无意识地扩大项目范围？如果确实扩大了，这些新增功能到底是必要的，还是只是“锦上添花”？我并不认为评估AI价值的唯一标准是节省时间，因为在相同时间内增加功能或提高质量同样有意义。但即便如此，这种价值仍然很难量化。目前我仍在继续订阅Claude Pro，但考虑到可能存在的限制，以及本地模型性能的不断提升，我也完全可以想象自己在不久后取消订阅。 在内容创作方面，截至目前，这个网站上没有任何一篇文章是直接由AI生成的。我曾尝试让AI写文章，但始终无法接受哪怕一句直接使用。AI生成的文本要么平淡乏味，要么让人产生反感。尽管从理论上看，这种方式应该很高效——AI拥有完美的拼写、语法和足够的上下文，可以在几秒钟内完成原本需要我数小时的工作——但问题在于，这些内容并不属于我，而写作本身正是这个博客存在的意义。 从读者的角度来看，我同样对AI生成内容感到不适。这种感觉类似“恐怖谷效应”：它几乎像是人类创作，但又存在微妙差异，让人产生不协调感。一旦察觉到这一点，我就会立刻失去兴趣。 尽管如此，我仍然在思考是否存在某种方法，可以让AI真正成为创作的有效工具。比如，我曾设想，小型团队是否可以借助AI，以极低成本开发出大型游戏作品。从社会接受度来看，也许AI创作会像整形手术一样——只有做得过度或拙劣时才显得怪异，而高水平、克制使用的结果则可能是优秀的。这一切仍有待观察。 以上就是截至2026年初，我对AI时代的整体看法。这些观点或许并不完整，也未必准确，但它们反映了我在这40个月中的真实体验。那么，你是否认同这些看法？或者你也有自己的观察与思考？

最近一段时间，我一直在进行大量所谓的“vibe coding”（氛围编程）。数量之多，几乎到了有点失控的程度。虽然可能还没达到Andrej Karpathy在No Priors节目中开玩笑提到的“AI精神错乱”，但其实也差不了太远。在这个过程中，一个想法反复浮现在我脑海中：AI编程代理，可能正在让“自由软件”变得比过去任何时候都更加重要。这里我说的不是企业语境中那种温和、去意识形态化的“开源软件”，而是Stallman意义上的自由软件——即赋予用户运行、研究、修改以及重新分发软件的自由。 在过去很长一段时间里，即便有人知道“自由软件”和“开源软件”的区别，这种差异也更多停留在理论层面。SaaS的兴起让大多数人根本接触不到他们所依赖软件的源代码，代码运行在他人的服务器上，由供应商负责一切运维细节，于是用户关心的问题逐渐从“我是否拥有控制权”转变为“这个东西用起来是否方便”。然而，AI代理正在改变这一切。如果一个代理能够读取整个代码库、理解其结构，并代表用户进行修改，那么“访问源代码”就不再只是程序员的象征性权利，而成为越来越多人可以真正利用的能力。此时，“可以修改的软件”和“只能请求别人修改的软件”之间的差异，突然之间变得极其现实。 这种变化并不是抽象的。我最近亲自尝试让一个AI代理帮我定制一个SaaS应用，而这次经历让我迅速意识到问题的本质。为了理解这一点，有必要稍微回顾一下历史。1980年，Richard Stallman在MIT AI实验室工作时，遇到了一台经常卡纸的施乐打印机。他想修复问题，甚至只是添加一个简单的通知功能，但却因为厂商拒绝提供源代码而无能为力。这件看似微不足道的小事，对他产生了深远影响。他成长于一个代码共享是默认文化的时代，而现在他第一次意识到，如果软件被封闭，用户将失去对自己工具的根本控制权。正是这种认识促使他创立了自由软件基金会，并提出了著名的“四大自由”，强调软件应当赋予用户运行、研究、修改和传播的权利。 在1990年代，这种理念曾经引发巨大共鸣。Linux、Apache、MySQL、PHP等自由软件构建了互联网的基础设施，Red Hat证明了围绕自由软件也可以建立商业模式，Eric Raymond提出开放开发模式优于封闭开发，而微软甚至公开将Linux称为威胁。然而，这场看似激烈的理念之争，却在之后逐渐淡出人们的关注。原因并不是谁在理念上胜出，而是一个更现实的变化——SaaS的兴起。 与此同时，“开源”这一术语的出现，也在悄然改变讨论的方向。1998年，一群人提出用“open source”替代“free software”，以避免“free”被误解为“免费”。但这种重命名不仅仅是营销上的调整，更是一种哲学上的转变。开源保留了代码共享的实践，却剥离了关于用户权利的伦理主张。企业可以拥抱开源、参与社区，却无需真正改变与用户之间的权力关系。正如Stallman所说，开源是一种开发方法，而自由软件是一场社会运动。 真正让自由软件在现实中失去意义的，是SaaS模式本身。GPL等许可证要求在“分发软件”时必须开放源代码，但如果软件只是运行在服务器上，通过网络提供服务，那么这一义务就不会触发。这使得公司可以基于自由软件构建业务，却无需公开自己的修改版本。对于用户来说，这意味着即便软件是开源的，也无法真正行使修改的自由，因为他们根本不运行软件本身。与此同时，SaaS提供了巨大的便利：无需安装、自动更新、随时访问、无需维护基础设施。这种便利性让大多数人接受了用控制权交换效率的现实。 直到AI代理的出现，这种平衡开始动摇。我以自己使用的任务管理工具Sunsama为例。我很喜欢这个产品，但我希望实现一个简单的工作流：当我在Twitter看到一条想稍后处理的内容时，可以一键将其保存为任务，并自动生成合理标题和分类。然而，Sunsama的封闭性让我无法实现这一点。它没有完善的API，无法嵌入自定义AI逻辑，也无法自动分类。问题并不在于我不会编程，而在于我没有时间从零构建一个替代系统。我尝试借助AI代理实现这个功能，结果却陷入了一连串复杂的变通方案：依赖非官方API、存储真实账户密码、部署自定义服务、手动配置iOS快捷指令、处理不透明的错误信息等等。最终虽然实现了功能，但代价极其高昂。如果这个软件是自由且开源的，AI代理完全可以直接修改代码实现需求，整个过程可能只需要十分钟。 这正是关键所在。过去，自由软件的一大弱点在于，大多数用户并不具备阅读和修改代码的能力，因此“四大自由”在实践中只对少数技术人员有意义。但AI代理改变了这一前提。它们可以作为中介，代替用户行使这些技术自由。用户不需要理解代码结构，也不需要掌握复杂技术细节，只需描述需求，代理就可以完成修改。这使得软件自由从一种抽象权利，转变为一种现实能力。对于非技术用户来说，这意味着他们第一次可以真正“拥有”他们使用的软件。 越来越多的人开始意识到这一趋势。有人指出，AI代理使开源软件相对于闭源软件拥有结构性优势，因为代理可以直接读取和修改源代码；也有人认为，AI正在大幅降低定制和维护软件的成本，使内部工具开发变得更加可行；还有观点认为，将数据保存在本地，将极大增强AI能力，并推动去中心化趋势。甚至Vitalik Buterin也开始强调开放性的重要性，认为只有开放才能避免权力集中。 当然，这并不意味着我们应该简单地回到“自托管一切”的时代。自托管带来了安全更新、备份、运维等额外负担，而这些正是SaaS解决的问题。同时，AI代理也可能对开源生态造成新的压力，例如低质量自动生成贡献的泛滥，削弱维护者与用户之间的反馈机制。因此，问题的答案并不在于完全抛弃现有模式，而是寻找新的平衡点：既能提供自由软件的可定制性，又能保留SaaS的便利性。 可以预见，在未来一到两年内，人们评估软件的标准将发生变化。“我的AI代理能否完全定制这个软件？”将成为一个越来越常见的问题，就像今天我们会问“是否支持移动端”或“是否集成Slack”一样。如果软件无法满足这一点，它将逐渐失去竞争力。AI代理会尝试绕过限制，通过逆向工程、自动构建替代工具，甚至直接迁移用户数据来实现目标。这将使传统的“切换成本”迅速下降。 总体而言，自由软件的钟摆可能正在重新摆动。这并不是因为人们突然重新拥抱某种理念，而是因为现实需求发生了变化。当用户意识到，如果软件是开放的，他们的AI代理可以在几分钟内解决问题，而封闭系统却迫使他们花费数小时甚至更长时间进行复杂折腾时，他们对软件的选择标准也会随之改变。我仍然喜欢Sunsama，也并不想更换它，但这次经历让我清楚地看到，如果它是开源的，我的工作流问题本可以被轻松解决。而正是这种具体、可感知的差距，让“软件自由”重新变得重要。或许，在不久的将来，我们将不再需要在“自由”和“便利”之间做出艰难选择。

在过去的几年里，我一直密切关注生成式人工智能的发展。早期，和大多数人一样，我对OpenAI基于谷歌一篇相对小众的深度学习研究论文，再加上一点来自人类反馈的强化学习所取得的成果感到无比震撼。当它运作良好时，那种效果确实令人惊叹——一种极具说服力的“幻觉”，让你几乎相信它无所不能。这也激发了我进行大量实验，并基于这些大型语言模型开发了一些概念验证应用。直到今天，它仍然是任何对其有基本了解的人之间热烈讨论的素材。我一直努力不对生成式AI轻易下结论，但经过长时间的思考，我觉得自己终于可以给出一个判断了。我知道，我知道，你一定迫不及待想知道（几乎所有读到这里的人可能在想：“这人是谁？”）。 这篇文章诞生于AI编程代理迅猛崛起的背景之下。这类系统将你最喜欢、却又容易产生“幻觉”的大语言模型，加上一个反馈循环，从而能够生成一些确实令人印象深刻的结果。如今，已经有整家公司从零开始围绕AI编程代理构建，甚至像Notion、Spotify和Stripe这样成熟且备受认可的公司也似乎全面拥抱这一趋势——毕竟，既然AI编程代理可以更快、更便宜地完成工作，为什么还要让人类辛苦编码呢？根据不同人的看法，AI编程代理要么已经让手动编写代码彻底过时、毫无价值，要么就是对软件开发生命周期理念的严重冒犯。而我决定加入这场讨论，并明确表达一个观点：基于大语言模型的AI编程代理，无论现在还是未来，都不应该用于我所构建的任何专业级生产代码。我也认为，你应该认真考虑采取同样的立场。 AI编程代理强大吗？毫无疑问，是的。任何真正关注这一领域并诚实面对现实的人都能看出来。那么，大语言模型本身是否有用？也有（前提是你绝对、绝对不能完全相信它说的任何话）。不过，这里我主要想聚焦于基于LLM的AI编程代理。至于LLM在软件工程中的其他用途，我们稍后再谈。 我之所以在专业工作中全面禁止使用AI编程代理，主要有四个原因：技能退化、虚假的低成本、提示注入攻击，以及版权与许可问题。 技能退化最容易理解、但也最“模糊”的问题，是技能退化。很明显，软件工程师的工作正在发生剧烈变化。有些人把这种变化描述为一种“软件工程经理”的角色：你几乎不再写代码，而是像管理一组初级工程师一样，监督一群AI编程代理。我们被告知，AI编程代理确实会犯错，但不用担心，中高级工程师会凭借多年经验审查每一行代码，确保质量达标。即便你现在相信这种说法，我也要告诉你：那些被降格为“代码审查员”的工程师，随着时间推移会变得生疏。他们的编码能力和软件设计能力会逐渐退化，最终成为更差的工程师。即使他们一开始打算认真审查所有生成代码，但随着不再亲自编写代码，他们将逐渐失去分辨好坏代码的能力。实践以及来自他人的反馈，对维持和提升技术水平至关重要，而在这种模式下，这两点都会缺失。 现实中，随着越来越少的工程师需要监督越来越多的AI代理，代码审查的工作量会不断增加。出于精力和心理承受能力的限制，人们不可避免地会变得敷衍。我一直支持代码审查，因为它有助于发现改进空间并促进知识共享，但即便如此，我也常常觉得大型代码审查是一件苦差事（重要不代表有趣）。如果你的全职工作是审查一群代理的代码，而经验告诉你它们95%以上时间都“还不错”，你很难始终保持高度警觉，错误迟早会混进来。这在所有代码审查中都存在，但至少你可以基本信任人类同事的动机，并且他们能从错误中学习。更重要的是，你可以直接与人沟通，询问他们为什么这么实现。而对于LLM生成的代码，你根本不知道灵感来源在哪里。你可以问它，但它只会编造一个听起来合理的答案，因为它其实并不知道。 我也清楚，这种观点可能会被视为“老人在对云大喊”。这确实有点类似几十年前，人们批评高级编程语言会导致程序员不理解底层系统运行机制的论调。他们认为这样会让工程师缺乏基础能力。但事实证明，大多数情况下他们错了。如今很多优秀工程师并不真正理解内存管理机制，但这并不妨碍他们创造价值。对此，我唯一的辩解是……这一次感觉不一样？我承认这不是一个严谨的论证，但我也说过这是最模糊的一点。另外，我有二十年的软件工程经验，这或许能增加一点说服力。 虚假的低成本这是我最不擅长分析的一点，但我确信问题确实存在，而且目前没有人有解决方案。 一种流行观点认为，我们正处在生成式AI泡沫之中，随时可能破裂。理由是LLM技术并没有达到宣传中的水平，一旦现实显现，资金将枯竭。科技巨头正在投入巨额资金购买GPU、内存、存储和建设数据中心，但随着新鲜感消退，实际能力边界显现，这些投入越来越难以合理化。帮你写邮件固然方便，但不足以支撑如此高昂的成本。然而在过去一年里，AI编程代理被当作证明投资正确的“杀手级应用”。 但现实是，这些模型对公司来说极其不赚钱，而AI编程代理甚至加剧了这一问题，因为它们增加了使用量。科技公司采用的是“先做出来再想赚钱”的硅谷模式。他们寄希望于出现类似“Attention Is All You Need”那样的突破性创新，来提升成本效率，甚至实现所谓的通用人工智能。如果这种奇迹没有及时出现（很可能不会），泡沫终将破裂，行业将经历大规模重组。像Google和Meta这样的巨头或许能挺过去，但其他公司可能会倒下。 当前终端用户支付的价格与实际成本严重脱节。未来可能需要大幅涨价并限制使用量。那些基于廉价AI模型构建业务的中间层公司也会陷入困境。冲击范围会非常广。 有人可能会说，既然现在能用，为什么不用？但我不同意。最好不要过度依赖这些工具，这样在风暴来临时你才能更从容应对。 提示注入这是一个众所周知的问题：LLM本质上非常“轻信”，攻击者可以通过精心构造输入，让模型执行不该执行的指令。LLM只是预测下一个词，并不真正理解上下文，因此无法可靠地区分指令与数据。虽然厂商不断修补漏洞，但这些修补更像是在漏水的船上贴胶带。这种漏洞源于模型本质，很可能无法彻底解决。 目前主要是用户试图绕过限制，但随着AI代理的普及，攻击者可能会污染网站或邮件，让代理在执行任务时读取恶意指令。所有能从不可信来源获取信息的AI代理都存在风险。一旦权限较高，后果可能是系统完全被攻陷。这类攻击被称为“promptware”，未来会越来越多。 即使没有攻击者，AI代理本身的“幻觉”也可能导致灾难，比如误删数据。这种风险不可接受。 版权与许可我不是律师，但这个问题非常关键。 在美国，生成式AI的输出不受版权保护。也就是说，AI生成的代码本质上属于公共领域。你不拥有它，任何人都可以使用。 美国版权局以及法院都支持这一观点，甚至最高法院也未推翻这一裁定。虽然这是美国法律，但其影响力巨大，其他国家可能也会跟进。 设想一个公司完全用AI生成代码，那么这些代码理论上属于所有人。如果员工泄露代码，公司可能没有法律手段阻止传播。相比之下，人类编写的代码受版权保护，泄露会带来严重法律后果。 如果竞争对手可以合法使用这些代码，他们就能跳过多年研发成本。这对公司来说是巨大风险。 即便有人认为代码本身不重要，这也忽视了需求分析和设计等工作仍然耗时。AI并没有消除这些成本。 如果代码是人类与AI混合生成，情况会更复杂。或许未来法律会调整，但目前仍充满不确定性。因此，让人类主导开发仍是更安全的选择。 那么LLM有什么用？研究用途。前提是你必须验证所有信息。对于学习新API或库，让LLM生成示例代码非常有帮助，但不能直接复制粘贴。 未来，如果AI代理具备完善的隔离机制，它们可能帮助非程序员实现想法，但不适合用来构建商业产品。 总结尽管我对其有所顾虑，但LLM和AI编程代理显然会继续存在。如果这篇文章能让更多人更理性地看待这项技术，我的目的就达到了。

软件工程似乎正站在一个历史性的拐点上。许多人把过去几十年的技术进步归纳为几次关键范式转移：从大型机到个人计算机，从本地服务器到云计算，从传统开发到 DevOps 自动化。而现在，我们很可能正在进入另一种同样深远的阶段——由人工智能代理驱动的软件开发生命周期（AI-led SDLC）。 就在五年多前，我刚刚从大学的软件工程专业毕业。当时课堂上教授的许多核心原则——例如系统设计、模块化架构、代码质量控制——今天依然有效。但与此同时，我也越来越清晰地意识到：我们当时学习的大量具体实践，可能正在迅速变得过时。原因并不是这些知识本身不正确，而是软件工程的执行方式正在发生根本改变。 如果说过去的软件开发是“人写代码、机器执行”，那么未来的软件开发更像是人定义目标，机器组织实现过程。在这种模式下，开发者不再是唯一的执行者，而是逐渐转变为一群 AI 代理的协调者、监督者与设计者。虽然我们还没有完全进入那种工程师管理“AI 开发团队”的世界，但越来越多的迹象表明，这样的时代已经近在眼前。 理解这一变化，最好的方式或许是回顾过去的软件工程教育，然后看看哪些东西已经开始发生变化。 在大学期间，我花了两年时间学习一门叫做“系统设计”的课程。这门课几乎完全围绕一个问题展开：如何把人类的想法转化为软件系统。我们经常收到一些虚构的商业场景，例如一个店主和他的妻子不断提出新的产品想法，而我们的任务就是把这些模糊的需求进行分析、拆解和建模。这个过程通常需要经过多轮讨论与推理，最后才能转化为应用架构、伪代码以及 UML 图。 从某种意义上说，这种训练是在培养一种“需求翻译能力”。工程师必须理解业务逻辑，同时把这些逻辑转化为可以实现的软件结构。这曾经是软件工程中最重要的智力活动之一。 然而今天，这一过程已经发生了微妙但深刻的变化。当我刚刚打开编辑器准备分析需求时，一个 AI 代理往往已经生成了需求列表、系统蓝图以及代码脚手架。换句话说，人类曾经最核心的一部分工程工作，正在被自动化工具迅速压缩。 类似的变化也发生在调试领域。 过去，调试几乎是一种艺术。开发者需要逐行阅读代码、分析日志、设置断点，并在复杂的系统行为中寻找真正的因果关系。我至今仍然记得自己在 IBM 实习时的工作状态：很多时间都在定位系统问题，然后在 Stack Overflow 上寻找可能的解决方案。 但今天，随着 AI 工具的出现，调试的方式已经完全不同。现在更常见的场景是，开发者直接让 AI 分析日志、总结错误并提出修复建议。传统意义上的“逐行调试”，在很多情况下已经不再是第一选择。 从效率角度看，这当然是一件好事。但这种变化也带来了一个更深层的问题：如果 AI 接管了越来越多的技术细节，人类工程师的角色会发生什么变化？ 在理论层面，这种变化可能带来一种新的认知结构。过去的软件工程包含大量重复性的“体力劳动”：写模板代码、查资料、排查日志、阅读文档。这些任务虽然枯燥，但也在无形中帮助工程师理解系统的底层结构。 当这些任务被 AI 接管之后，人类工程师可能只剩下那些最复杂的问题。乍看之下，这似乎是一种进步——工程师终于可以专注于真正有价值的工作。然而长期来看，这种变化也可能带来新的挑战。如果开发者始终处于高复杂度问题之中，他们是否还能保持对基础系统的直觉理解？当基础训练减少时，工程能力是否会逐渐依赖工具本身？ 更进一步的问题是创新。 今天的大多数 AI 系统，本质上仍然是复杂的预测模型。它们可以在已有知识上进行组合、优化和扩展，但并不会主动创造完全新的思想。正如技术评论员 Scott Hanselman 所说，很多 AI 工具其实只是“更强大的自动补全”。 这就引出了一个有趣的类比。如果 AI 代理是足球教练，它们是否能够像瓜迪奥拉那样重新定义比赛风格？还是只会不断优化现有策略，例如更高效地执行传统战术？在这种情况下，AI 可能会加速技术进步，但未必能够带来真正的范式创新。 除了这些理论问题，还有一些更现实的变化。例如开发者知识生态的变化。Stack Overflow 曾经是全球程序员最重要的知识共享平台之一，但近年来其流量明显下降。许多开发者已经不再通过论坛寻找答案，而是直接向 AI 提问。 这种趋势带来了一个新的担忧：未来训练…

仅靠规模并不能决定这场竞争，软件能力、合作伙伴关系以及特斯拉能否实现大规模部署同样关键。 自今年年初以来，中国的人形机器人在国内外引发了巨大关注——从美国拉斯维加斯的消费电子展（CES），到中国的春节联欢晚会，各种展示不断出现。这些表演甚至激发了一些大胆的说法：认为一场新的工业革命正在到来，美国将很难再追赶上。 目前，中国企业已经在全球人形机器人市场中占据主导地位，去年全球超过 90% 的销量来自中国企业，出货量达到数千台。虽然埃隆·马斯克仍然坚持认为特斯拉最终会在这个行业中领先，但他最近也承认，中国公司是其最主要的竞争对手，并表示特斯拉的 Optimus 机器人至少要到明年才会准备好上市。 为了分析这些说法，并超越那些病毒式传播的机器人表演背后的真实情况，科技咨询公司 Omdia 的首席分析师苏连杰（Lian Jye Su）在 2 月 25 日的一场线上活动中接受了《Rest of World》的采访。苏连杰也是 Omdia 最新人形机器人报告的作者。在采访中，他分析了销量背后的趋势、中国和美国在人形机器人开发策略上的差异、为什么特斯拉仍然有可能找到自己的发展路径，以及在评估这个行业进展时真正重要的指标是什么。 以下访谈内容经过编辑，以提高简洁度和清晰度。 为什么中国生产人形机器人的公司数量远远多于美国或其他国家？ 第一个原因其实很简单：中国在过去几十年里持续提升其高端工程制造能力。自从中国政府推出一系列工业政策之后，比如“中国制造 2025”和“十四五规划”，这些政策都高度关注强化工业制造能力。现在我们开始看到这些政策带来的成果，而这种能力不仅体现在机器人行业，还体现在更广泛的制造领域，例如电动车、太阳能面板产业以及航空工业。 与此同时，中国在软件领域也进行了大量投资。例如，从基础模型的开发到 AI 芯片的设计与生产，现在都可以在中国完成。这些因素的结合推动了当前中国在人形机器人生产规模上的快速扩张。 此外，还有第三个重要因素：需求。 中国许多国有企业正在积极采用这些机器人。在很多其他市场中，这种需求其实并不存在。可以说，这种需求在很大程度上成为了催化剂，推动中国人形机器人的生产与应用加速发展。 美国公司的战略似乎有所不同。特斯拉声称希望在 2027 年推出 Optimus 机器人。这个时间表现实吗？ 特斯拉在人形机器人领域一直是先驱之一。事实上，在最早的人形机器人演示中，来自私营公司的展示中，特斯拉就占据重要位置。 实际上，Optimus 很有可能在明年就能够推出。 真正的问题在于：部署规模会有多大。 目前最大的挑战仍然是规模，而在这一点上，中国显然占据优势，因为它拥有更广泛、更成熟的制造基础。 在美国，制造商的反应相对较为谨慎。这部分原因是许多制造基地位于亚洲而不是美国。因此，美国市场的人形机器人应用速度可能会更慢。 不过，这对特斯拉或任何美国人形机器人创业公司来说并不一定是坏事。建立生产能力本来就需要时间，而等到这些公司真正建立起自己的制造基础时，它们也会准备好进行大规模部署。 那么，评估哪家公司在人形机器人领域领先的最佳标准是什么？ 如果我们分析人形机器人的构成，就会发现它需要非常优秀的硬件和软件。 公司还必须具备生产能力以及大规模生产的能力。 同时，公司在研发团队上的投入也很关键，无论是软件工程师还是硬件工程师。 理想情况下，我们还希望看到强大的商业合作伙伴关系。 在当前的市场环境中，大多数人形机器人公司仍然处于创业阶段，因此要实现国际市场扩张其实非常困难。 因此，在很多情况下，这些公司最终都需要系统集成商或经销商，帮助它们进入其他国家市场并扩大全球影响力。 同时，它们还需要当地的合作伙伴来提供安装、部署、调试和维护支持。 因此，在评估一家人形机器人公司的成熟度时，需要从多个维度进行综合判断。 目前我们看到的情况是：中国厂商在生产规模方面明显更加领先。 但美国公司在技术层面仍然非常强大，尤其是在硬件和软件研发方面。 那么，中国的人形机器人行业是否存在潜在泡沫？如果美国的制造能力暂时落后，一旦市场进入大规模应用阶段，美国是否会更难竞争？ 目前来看，机器人生产和出货方面的市场仍然相对理性。 实际上，市场确实需要更多机器人。…

就在不久之前，Sam Altman 的 OpenAI 看起来还在企业界将人工智能推向大众的竞赛中占据着相当稳固的领先地位。 OpenAI 打造了科技史上增长最快的消费者应用，账上拥有超过 1000 亿美元的资金，并与世界上最强大的计算基础设施公司合作。 然而，在硅谷，公司总是不断兴衰更替。 就在短短几个月里，OpenAI 的较小竞争对手 Anthropic 已经新增了数千家大型企业客户。该公司预计今年的收入将超过 190 亿美元，而去年这一数字是 90 亿美元，几乎翻倍。在一些科技圈子中，它的技术也被称赞为同行中最出色的。 甚至一场与美国国防部围绕合同产生的激烈冲突，也在某种程度上帮助了 Anthropic——至少在公众舆论中如此。在 OpenAI 宣布与五角大楼达成合作之后，Anthropic 的智能手机应用在苹果 App Store 下载榜上迅速冲到了第一名。 这场涉及美国国防部、OpenAI 与 Anthropic 的合同争议，是这两家人工智能创业公司之间长期且高度个人化竞争的最新一轮。这两家公司是科技行业最重要的 AI 初创企业，而两位领导者对于人工智能应如何发展也持有截然不同的观点。 这件事同时也显示出，在 AI 世界里命运变化有多么迅速。如今，各家公司正投入数百亿美元，希望最终的赢家能够掌握未来科技行业的主导权。 风险投资人 Siri Srinivas 表示： “过去，一个公司的故事往往需要多年时间才会形成。但现在，行业叙事可能几个月就会发生一次翻转。” 科技行业向来不缺乏激烈竞争。 在 1990 年代，Netscape 推动浏览器普及之后，微软通过强硬策略击败了这家新兴公司，并最终引发了一场改变行业格局的反垄断诉讼。 而在 2017 年 Uber 丑闻缠身的时期，它的竞争对手 Lyft 则利用粉色胡子标志和对司机更友好的广告形象迅速扩大影响力，向市场传递自己是一个更温和、更友好的替代选择。 如今的 AI 竞赛则是对这些历史竞争的进一步升级。…

在成为最火爆、增长最快的 AI 编程公司之后，Cursor 正面临一个新的现实：开发者可能根本不再需要代码编辑器。 2026 年 1 月 5 日，Cursor 的员工结束假期回到公司，参加了一场全员会议。会议的幻灯片标题是：“战时（War Time）”。 在假期期间，一些员工在试用 Anthropic 最新模型 Opus 4.5 时，突然意识到一件令人不安的事情：这个模型的编程能力已经进步到开发者不再需要逐行审查输出结果。开发者不再需要在 Cursor 的代码编辑器中与 AI 助手协作，而是可以直接向自动化代理下达高层级指令，然后得到完整功能——有时甚至是完整产品。 而这正是问题所在。 Cursor 最初建立在一个完全不同的假设之上。CEO Michael Truell 在 2024 年曾向《福布斯》描述这款产品是“程序员版的 Google Docs”——一个人类与 AI 一起协作、不断优化代码的编辑器。 但如果 AI 已经不再需要人类协作，那为什么还需要编辑器呢？如果逐行编写和修改代码已经不再是程序员工作的核心流程，那么 Cursor 整个产品的核心假设就突然受到挑战。 在那场全员会议上，Cursor 的领导层警告说，接下来的几个月将会是动荡时期。一些项目可能会被砍掉，优先级也会发生改变。公司的新最高任务被标记为： P0 #1——优先级零号任务：构建最好的编程模型。 不是最好的工具封装。 而是最好的模型。 这可以说是一种氛围上的巨大转变。在 Cursor 内部，这感觉像是一场清算时刻。 而这种变化之所以如此震撼，是因为就在不久之前，Cursor 看起来几乎势不可挡。 公司在 2025 年初的年化收入约为 1 亿美元。到…

第一次坐下来使用 Claude Code 的 Opus 4.5 来开发软件时，我简直不敢相信它有多强大。 我接下来的想法是：这将会改变软件团队内部的动态。 角色之间的僵局 Marc Andreessen 最近把当前的局面形容为一种“墨西哥式对峙（Mexican standoff）”： 每个工程师现在都觉得自己可以做产品经理，也可以做设计师。 每个产品经理都觉得自己可以写代码、也可以做设计。 每个设计师则觉得自己也能胜任另外两种角色。 风险在于，许多个体贡献者开始认为自己不再需要其他人。 在短期内，这对团队文化来说将会非常具有冲击性。 当原本稀缺的技能变得更容易获得时，人们就会感到压力，想要“向上走一层”，以证明自己的价值。 Kent Beck 在 X（Twitter）上表达了类似的感受： “我 90% 的技能价值刚刚跌到了 0 美元，而剩下 10% 的杠杆价值却增加了一千倍。” 我担心的是，每个人都在重新校准自己的能力，朝着同样的那 10% 靠拢。所有个体贡献者都在争相冲向同一个高杠杆层级。 在 Ben Werdmuller 的文章《AI coding works now》中，他给工程师提供了一些建议。他写道：“AI 编程正在把重心从实现（implementation）转移到判断（judgment）。”他建议工程师重点培养以下四种能力： 制定产品目标 理解用户真正想要什么 对你正在创造的体验和价值有极其清晰的认知 设计、构建并维护稳健的软件架构 然而，对 Ben 的建议提出的挑战是：很多人都认为这些能力本来就属于自己。 公司领导层认为目标和战略本来就是他们的职责。 产品经理认为自己最有资格理解用户需求。 设计师希望掌控用户体验的设计。 而市场和销售团队则希望定义产品向客户传递价值的方式。 工程师则掌握架构的规划和实现。性能、可扩展性、安全性——这些都需要真正的专业能力。 随着 AI…