原文来自The Developers Building Systems Around AI Are About to Leave Everyone Else Behind.，可点击文末阅读原文跳转。作者为Mayank Agarwal。

📝 TLDR：软件开发的真正竞争优势不在模型本身，而在围绕模型搭建的系统——记忆、上下文管理、专门智能体、验证循环与工作流编排，因为前沿模型的差距在缩小，而这些系统会随时间复利。谁更早把 AI 从『聊天助手』升级成有记忆、会自我改进的工程操作系统，谁就握有几年内难以追赶的优势。开发者的核心技能正从『写代码』转向『编排智能』。

大多数开发者使用 AI 的方式，仍然和他们在 2023 年使用 ChatGPT 的方式一样。

打开一个聊天窗口、提一个问题、复制一些代码、粘贴到编辑器里，然后重复。

这确实有用。没人说它没用。

但它已经在以大多数人尚未察觉的方式变得过时。而那些早早察觉到这一点的开发者，正在悄悄建立一种以后会非常难以追赶的优势。

眼下，一类新的开发者正在出现。他们并不像其他人那样把 AI 当作编码助手来用。他们在围绕 AI 构建整套操作系统：带有记忆、上下文、专门智能体、验证循环，以及会随着时间复利增长的工作流的结构化系统。

这两种方法之间的差距，正在成为软件开发中最重要的竞争优势之一。不是因为某一类人比另一类人更聪明，而是因为某一类人更早明白：真正的杠杆从来不在模型本身，而始终在模型周围的系统。

今天理解这一转变的开发者，将拥有一种在未来几年持续增长的优势。因为软件开发的未来，不在于更快地写代码，而在于大规模地编排智能。

所有人都在谈的，其实是一个错误的问题

过去两年，整个 AI 讨论几乎都被一个以不同形式反复出现的问题主导。

哪个模型更好？

Claude 对 GPT，GPT 对 Gemini，Gemini 对 DeepSeek，开源对专有。所有人都在比较基准测试、编码分数、上下文窗口和推理评测，仿佛模型本身就是竞争的终点。

这场讨论的重要性，正在慢慢变得低于参与者自己的想象。

在所有噪音之下，一个更有价值的问题正在悄然浮现。

你如何把一个语言模型变成一名高产的软件工程师？

不是一个回答问题的聊天机器人，不是一个节省敲键盘次数的自动补全引擎，也不是一个按需生成函数的代码生成器。而是一个真正的工程系统，能够规划工作、研究解决方案、审查代码、发现 bug、编写测试、更新文档、管理长期项目中的上下文、从过去的决策中学习，并随着时间改进自己的输出。

这种转变正在 Claude Code 这样的工具周围发生。而它的重要性，远远超出了基准测试争论所暗示的范围。

第一波 AI 编码工具解决了错误的问题

第一代 AI 编码工具几乎完全专注于代码生成。这是最显而易见要解决的问题，也确实是一个值得解决的真实问题。

GitHub Copilot 证明了 AI 可以以真正有用的方式自动补全代码。ChatGPT 第一次让软件开发变得可以对话。模型快速进步，上下文窗口不断扩大，代码质量提升到很多输出只需少量编辑就能用于生产的程度。

有一段时间，整个行业看起来都在朝着一个清晰的目标竞赛：用更少的错误、更快地生成更多代码。

但有经验的工程师很快发现了一件本该从一开始就显而易见的事。

写代码很少是软件开发中最难的部分。

真正的工作，也就是占用高级工程师大部分时间、消耗团队大部分精力的工作，通常是这样的：理解不完整或相互矛盾的需求，在一个沉淀了多年历史和决策的代码库中研究解决方案，做出架构选择，而这些选择会根据思考是否充分，要么复利成优势，要么复利成技术债，管理那些一旦积累起来的技术债，测试规划阶段没人想到的边界情况，从正确性、安全性和可维护性角度审查实现，在压力之下调试生产问题，维护总是略微过时的文档，以及在对正在构建的东西有不同心智模型的人之间协调复杂项目。

工程生命周期的大部分都发生在编辑器之外。

而这恰恰是传统 AI 工作流，也就是打开聊天、复制一些代码的做法，开始彻底崩溃的地方。

为什么 Claude Code 真的和之前的一切都不一样

Claude Code 引入了一个根本不同的想法，而这个想法值得准确说清楚，因为这种差异很容易被低估。

它不是把 AI 当作你偶尔咨询以获得帮助的东西，而是把 AI 直接放进工作流本身，让它作为执行中的主动参与者。

这听起来像是一个细微差别。但它一点也不细微。

聊天机器人等待指令并作出回应。操作员参与执行，并在你的真实环境中采取行动。这个区别改变了开发者和工具之间关系的整体性质。

当开发者第一次开始认真使用 Claude Code 时，讨论从“AI 能否写出某个特定函数”，转向了“AI 能否端到端处理一整套工作流”。一旦这个问题出现在你的脑海里，你就不再把代码生成视为目标。你开始思考系统。而系统，一直都是工程中真正杠杆所在。

今天最能从 Claude Code 中获益的开发者，并不是那些写出最巧妙单条提示词的人，而是那些围绕它构建了最周密系统的人。

瓶颈几乎从来不是智能

大多数人以为，当 AI 产出平庸时，是因为模型还不够聪明。这个假设会导致人们不断寻找一个更好的模型，期待它最终产出所有人都在等待的结果。

现实中，瓶颈几乎总是上下文。不是智能。是上下文。

想象一下，你雇到了一位你能想到的最优秀的软件工程师，然后不给他任何文档、项目历史、编码规范、过往架构决策记录，也不给他任何已经发现并修复过的 bug 的知识。那位工程师会极其吃力。不是因为他没有能力，而是因为他在缺少让能力变得有用的上下文中工作。

在每一场没有此前记忆、从零开始的对话里，AI 模型都面临完全相同的问题。

这解释了一件人们第一次遇到时会感到困惑的事。两个开发者可以使用完全相同的模型，却得到仿佛来自完全不同工具的结果。一个人得到的输出真正有用，并且可用于生产；另一个人得到的输出很平庸，所需修正甚至比原本手写代码还多。

差异几乎从来不在模型，而在上下文管理。一个开发者给了模型做好工作所需的东西，另一个没有。

这是认真使用 AI 时最具实践意义的认知之一。你不只是在选择一个模型。你是在构建一个环境，让这个模型能够有效运行。相比其中模型的原始能力，这个环境对输出的决定作用要大得多。

上下文正在成为新的基础设施

大多数 AI 讨论都聚焦于提示词，因为提示词是可见层。它们是你输入的东西，是你看到的东西，也让你感觉那就是你正在控制的东西。

但提示词只是表面。

在每一种持续成功的 AI 工作流之下，都有一套大得多的基础设施，而大多数人从未明确思考过它，也几乎从不公开讨论它。

这套基础设施包括：能够跨会话保留信息、而不是每次都从零开始的记忆系统；以模型可引用的形式捕获决策、标准和模式的知识存储；在正确时刻浮现正确信息、同时避免一次性用所有信息压垮模型的上下文检索；按正确顺序排列任务，并让正确输入在各环节之间流动的工作流编排；在输出进入下一阶段之前根据标准进行检查的评估循环；定义模型能碰什么、不能碰什么的安全控制；在错误复利放大之前捕捉错误的验证流水线；以及识别系统在哪些位置产出糟糕结果、以便改进这些位置的性能监控。

这些系统决定了 AI 是会真正对一个工程组织有用，还是仍然只是一个昂贵的自动补全引擎，只能节省一些敲键盘次数，并在演示中给人留下印象。

今天正在构建这些层的公司和个人开发者，实际上是在构建 AI 时代的操作系统。他们不只是在使用已有工具，而是在构建下一代工具将运行其上的基础设施。

智能体式开发的兴起，以及为什么它像极了优秀团队的构建方式

这就是软件开发正在走向的方向；如果把它和一件已经符合直觉的事联系起来，会更容易理解。

想想一个真正高效的工程组织是如何运作的。你不会雇一个人，然后要求他做所有事。你会拥有在特定领域有深厚技能的专家：理解问题空间的研究人员，做结构性决策的架构师，在实现中捕捉问题的审查者，以产品导向工程师容易忽略的方式思考可能出错之处的安全工程师，用现实检验假设的 QA 工程师，让系统对所有参与者都可理解的技术写作者，以及让一切在生产环境中持续运行的运维人员。

同样的模式正在高级 AI 工作流内部出现。

今天，一个设计良好的智能体式系统，可能会先经过一个研究智能体，在任何决策之前调查问题空间；然后经过一个架构智能体，根据研究设计结构性方案；然后经过一个实现智能体，按照架构规范编写代码；然后经过一个测试智能体，根据需求和边界情况验证实现；然后经过一个安全智能体，审查漏洞；然后经过一个文档智能体，记录构建了什么以及为什么这么构建；最后经过一个部署智能体，管理发布流程。

每个系统都有特定职责。每个系统都专注于一个特定问题。它们合在一起，不再那么像一个聊天机器人，而更像一个有明确角色、彼此之间有清晰交接的工程组织。

这就是为什么最成熟的 Claude Code 用户不再把大部分时间花在打磨单条提示词上。他们把时间花在设计工作流上。提示词只是一个更大系统中某个阶段的输入。真正持续产出好结果的是系统。

记忆最终可能比模型能力更重要

这是大多数人还没有足够认真对待的转变，也是我认为未来几年最重要的转变。

模型正在快速改进，而最强可用模型之间的差距正在缩小。前沿模型之间的基准测试差距越来越近，而不是越来越远。主导讨论的模型大战，争夺的是正在缩小的差异。

但记忆会创造不会缩小的复利优势。它们会增长。

想想相比一个原始智力相近的初级工程师，高级工程师真正有价值的地方是什么。经验。而经验之所以重要，是因为经验创造记忆。记忆会形成关于什么有效、什么无效的直觉。直觉会让人以更少精力、更快做出更好的决策。那些更好的决策会随着时间复利，形成无法快速复制的履历和判断深度。

没有记忆时，无论之前发生过什么，每个项目都从零开始。每个错误都会重复，因为没有记录表明它曾经发生过。每一条学到的经验都会在会话结束时消失。每一个运行良好的工作流，下一次需要时都必须重新构建。这是一种巨大的低效，并且会在每个项目中无形累积。

这就是为什么最有前瞻性的 AI 系统构建者，正在高度关注能够跨对话承载上下文的会话持久性，能够以可检索形式捕获模式和决策的长期记忆，能够自我累积而不是不断重置的知识积累，以及能够根据以往有效经验改进系统的工作流演化。

真正正在到来的未来，不只是更聪明的模型，而是会记住并改进的更聪明系统。复利优势属于最先构建这些系统的人。

大多数人完全忽略的隐藏层

当我思考真正的优势存在于哪里时，有一个观察我总是会反复回到。

今天，三个开发者可以使用完全相同的 Claude 模型。一个得到的只是平均水平结果，比手动写代码稍好一点。一个得到优秀结果，显著加快自己的产出。另一个围绕这个模型构建出一家完整的软件公司，并产出几年前任何规模团队都不可能完成的东西。

这三种结果之间的差异不是智能。甚至也不是努力，至少不是直接意义上的努力。差异在于基础设施。

获胜的技术栈越来越像一块千层蛋糕：模型位于顶层，可见，并被不断讨论；而它下面的一切，才是真正竞争优势所在。模型之下是记忆，再下面是工作流编排，检查输出的评估系统，定义边界的安全控制，消除重复步骤的自动化，以及把所有东西串联起来的执行流水线。

大多数人只关注最上面那一层。他们关注模型，因为模型是他们直接交互的东西，也是市场宣传强调的东西。

最高的杠杆，也就是当下最大优势正在被构建出来的地方，存在于可见层之下的一切。

为什么这个时刻让我想起云革命

这个类比值得认真对待，因为即便它在当下总显得像可选项，事后回看却总是准确的。

今天，大多数开发者把智能体式工作流视为一个有趣的实验，或者一个有时间时值得探索的生产力增强手段。这正是 2008 年和 2009 年云计算看起来的样子。人们觉得自己完全可以运行自己的服务器。那些早早基于云基础设施构建东西的开发者，看起来像是在过度工程化。然后云成了标准，而那些没有完成转变的人，突然就在一些修正成本很高的方面落后了。

同样的模式也出现在版本控制、容器、持续集成和部署上。每一次基础设施转变，最初看起来都像是给有时间实验的人准备的可选生产力技巧。然后它会成为早期采用组织的竞争优势。再然后，它会成为默认工作方式，而其他所有人都在追赶。

智能体式开发正在沿着同样的轨迹前进。今天，它还处于实验阶段，由一小部分对它异常兴奋的开发者实践。明天，想保持竞争力的工程组织会把它视为理所当然。早期采用能够创造持久优势的窗口现在正开着，但它不会无限期保持开放。

开发者技能集正在朝一个明确方向演化

在软件工程的大部分历史中，成功都与实现能力高度相关。你能多快写出正确代码，你对特定语言和框架理解得有多深，你能记住并应用多少算法。这些技能曾经极其重要，现在也仍然重要。

但未来十年最高杠杆的开发者，将越来越多地聚焦于一组不同的能力。

设计工作流，让 AI 智能体以正确顺序、带着每个阶段所需的正确输入和输出完成复杂任务；管理上下文，让模型拥有表现良好所需的信息，同时不被信息压垮；构建评估系统，在输出被使用之前进行验证；创建能够积累知识并随时间改进的记忆架构；协调各自专注于特定问题的专门智能体；定义随着输出量增加仍能维持质量的验证流程；以及构建能够串联成可靠自动化系统的执行流水线。

这份工作正在从构建事物演变为指挥智能，从写代码演变为设计产生代码的系统，从实现演变为编排。

这意味着“精通”的含义发生了重大变化。那些早早认识到这一点，并从现在开始构建这些技能的开发者，将与那些继续围绕旧式工程卓越定义进行优化的人处在非常不同的位置。

这会通向哪里，以及它可能还有多远

开发者与 AI 关系的演化，似乎正在经历几个可识别的阶段。

第一阶段，是开发者与编辑器一起工作，借助能够组织和显示代码、但不参与编写代码的工具，手动产出一切。

第二阶段，是开发者与 AI 助手一起工作，AI 回答问题、按请求生成代码，并加速特定任务，而开发者仍然是主要生产者。

第三阶段，也就是今天最先进实践者所在的阶段，是开发者与更接近 AI 团队的东西一起工作。多个专门系统处理工作流中的不同部分，开发者负责指挥和审查，而不是直接产出每一项成果。

第四阶段，正在地平线上变得可见，是开发者与一个 AI 操作系统一起工作。它是一套完整基础设施，把研究、规划、实现、测试、安全、文档和部署作为集成功能来处理，而开发者作为架构师和决策者运作，不再是执行者。

今天大多数在职开发者，大致处在第二阶段和第三阶段之间。向第三阶段的移动正在加速。第四阶段并没有看起来那么遥远。

真正值得关注的东西

眼下大多数 AI 讨论都集中在模型大战上。Claude 对 GPT，开源对专有，以及那些可能反映、也可能无法反映真实世界表现的评测分数。

这些争论很有趣，也并非完全没有价值。但它们的重要性，可能远低于参与者自己的想象。

更大的故事是，软件开发本身正在变得智能体化。软件被构建出来的结构正在发生根本层面的变化，而不仅仅是在边际上变得更快。

在那个世界中的赢家，不一定是能访问最聪明单个模型的开发者，而会是那些围绕这些模型构建出最聪明系统的开发者。是那些理解上下文管理比原始模型能力更重要、记忆会创造复利优势、工作流设计才是真正杠杆所在、编排智能比生成代码更有价值的人。

Claude Code 的重要性，不只在于它是一个工具，更在于它是一个信号。它是我们最早、也最清晰地窥见软件工程在智能成为可编程基础设施、而非偶尔咨询对象时会是什么样子的窗口之一。

一旦这种转变完全落地，问题就不再是 AI 能不能写代码。所有人都已经知道它能写代码。

问题变成了：完整软件开发生命周期中，有多少可以由设计良好的 AI 系统接管，并由懂得如何构建和运行这些系统的开发者来指挥。

这个问题的答案每个月都在扩大。而此刻正朝着这个答案构建的人，正在拥有一种悄然复利的优势；一旦它足够大，就会变得非常难以追赶。

我们仍然处在这一切最早的章节。未来两三年做出的决定，会在此后很长时间里持续重要。

（以上为译文，以下为AI反思）

文章把『模型周围的脚手架才是护城河』当作新洞见，但这恰恰和 AI 领域最被反复验证的一条规律相冲突：Rich Sutton 2019 年那篇《The Bitter Lesson》。它的结论是，凡是依赖人工精心编码的知识、规则、上下文结构去补足模型的方法，长期都会被『单纯堆算力、让模型自己学』的通用方法碾压。历史已经演过一遍：1980 年代的专家系统（MYCIN、XCON 等）下的赌注一字不差——推理引擎是通用的，真正的价值在它周围那套人工维护的知识库。结果是 AI 寒冬，因为手工维护的知识既不可扩展又极其脆弱。今天『上下文是新基础设施』的口号，是同一个赌注换了层皮。

更具体的证据是：每一代新模型都会吃掉一层脚手架。2023 年一大批人辛辛苦苦搭的多步提示链、向量检索（RAG）管线，到了 128k、200k 长上下文窗口出现后，相当一部分直接作废。也就是说，你今天围绕模型缺陷搭的『复利资产』，很可能是一项随模型变强而贬值的负债，而文章只字未提这种贬值。

谁在主推这套『系统/智能体』叙事？是从中直接获利的人：Anthropic（文章的主角 Claude Code 反复出场）、向量数据库厂商（Pinecone、Weaviate）、LangChain 这类编排框架，以及靠卖课、卖咨询、卖模板的『context engineering / AI engineering』影响者经济。他们的动机是工具销售、订阅锁定和注意力变现，所以『窗口正在关闭、以后很难追赶』这种 FOMO 话术对他们特别有用。

谁在反对？一是相信 bitter lesson 的扩展派研究者，他们认为做大模型、做长上下文会持续抹平你手搭的那层价值；二是被自己 RAG 栈反复『报废』过的一线开发者。诚实的中间结论是：确实有一部分基础设施会复利（领域知识沉淀、评估标准、可复用的验证清单），但也有一大部分（巧妙的提示链、针对当前模型缺陷的补丁）会折旧——而搭建与维护这套东西本身就是昂贵劳动，正是文章自己警告的那种技术债。这一点被刻意略过了。

这类人看到一个具体编码请求时，第一秒注意到的不是『模型能不能写出这个函数』，而是『这属于软件生命周期的哪个阶段，它周围那套系统长什么样』。他们的视线会本能地往上跳一层，从任务跳到流程，从单点输出跳到管线结构。普通人盯着编辑器里的光标，他们盯着光标背后的工作流。

他们切片问题的方式是按角色和管线切，而不是按任务切。把一件复杂事拆成研究者→架构师→实现者→审查者→测试者的交接链路，本质上是在画一张组织架构图，是把软件工程里的『关注点分离』原则套用到智能身上。所以他们谈的是『这个阶段输入什么、输出什么、谁来检查』，而不是『我该怎么把提示词写得更巧』。

他们丢掉的、常人会保留的假设有三个：其一，假设瓶颈是智能（他们反过来假设瓶颈几乎永远是上下文）；其二，假设人必须是生产者（他们把自己重新定义成架构师和决策者，让产出交给系统）；其三，假设更好的单个答案来自更好的单条提示词（他们押注于系统设计，而不是提示词工艺）。

给 AI 的输出建一个最小评估循环：拿你过去 5 次让 AI 干活的结果，写下你当时接受或拒绝它们的具体标准（比如『必须有错误处理』『不能引入新依赖』）。把这些标准固化成一份清单，让模型在你阅读之前先自检一遍。这就是把『隐藏层』里的 eval loop 做成你今天就能用的东西。

最后，把一个稍大的任务拆成 researcher、implementer、reviewer 三个角色，串行各跑一遍，而不是塞进一个大提示词。哪怕只是手动复制粘贴交接，你也会立刻感受到『编排』和『一次性提问』在结果质量上的差别。

🚨友情提醒：第一，bitter lesson：模型一变强，你搭的脚手架就贬值，文章把它说成只会复利、绝口不提折旧。第二，维护成本：这套记忆、编排、验证基础设施本身就是要持续喂养的技术债，和它警告你的东西是同一种。第三，全文没有一个数字、一个可复核的案例，全是断言；而那个『一个人围绕模型建起一家公司』的故事是典型的幸存者偏差——你听不到成千上万套精心搭建却烂尾、报废的系统。 还有两点被混淆了：它把『大型工程组织需要的基础设施』直接套到个人开发者头上，但对单兵作战者，搭一整套智能体管线的投入常常超过收益；以及它默认你自建的这套上下文/记忆栈会带来优势，却回避了厂商锁定的风险——当你把记忆和工作流深度绑死在某个工具的格式里，迁移成本本身就成了别人的护城河，而不是你的。