O'Reilly Radar：AI 时代工程师的五种使用模式——Soloist、Copy-Paster 与 Tourist

O'Reilly Radar· Sar Haidar·2026-10-26 18:54· 4 小时前AI 评分69

独奏者、复制粘贴者和游客

AI 导读

Sar Haidar 在 O'Reilly Radar 撰文指出，同一份 AI 订阅在基础设施团队中会产出五种截然不同的使用模式：Soloist、Copy-Paster、Godot Waiter、Specialist 和 Tourist，且这些是可切换的模式而非人格类型。

正文 · 原文

在 2026 年，几乎任何基础设施团队待上一周，你都会看到同一份 AI 订阅产生五种截然不同的结果。一位工程师在午餐前就在他们一年没碰过的仓库里开了 40 个拉取请求。另一位提交了一个 Terraform 变更，却在代码审查中解释不清楚。第三位自试点以来就没再打开过这个工具，并说“等它准备好了”再回来。

第四位用它做两项狭窄的工作：解码 SAML 跟踪日志，以及编写他们再也不想手写的正则表达式，而且可能是团队中最高产的人。第五位在三月试过一次，六月又试了一次，还会在下一场主题演讲之后再试一次。

描述这种现象的常见方式是 Everett Rogers 的扩散曲线：创新者、早期采用者、早期大众、晚期大众、落后者。Rogers 的框架衡量的是人们何时采用。它完全没有说明人们一旦拥有工具后如何使用它，而在 AI 领域，结果的分化恰恰就在这里。开了 40 个 PR 的工程师和只有两个用例的工程师都是早期采用者，但他们取得了不同的成果，并为团队制造了不同类型的风险。

Rogers 描述的五种类型没有一种是新的。以往的技术变革，从 PC 和 Web 到 Stack Overflow 和云，都产生了类似的行为。AI 只是改变了瓶颈所在的位置。

瓶颈转移了

在软件历史的大部分时间里，编写代码很慢，因此开发方法侧重于管理这项工作。瀑布模型把规划放在前面，因为后期改变方向代价高昂。然而，即使在通常被视为瀑布模型起源的1970 年论文中，Winston Royce 也警告说，严格顺序的版本“有风险，容易招致失败”。业界忽略了这一警告，采纳了那张图。

敏捷是纠正。2001 年的《敏捷宣言》优先考虑“响应变化高于遵循计划”，短迭代取代了长达一年的规格说明。宣言仍然重视计划，但这一部分也被忽略了。Facebook 用“快速行动，打破陈规”把这一理念推到了极限。在 2014 年的 F8 大会上，它弃用了这句口号，改用“快速行动，基础设施稳定”，因为修复被打破的东西所花的时间已经开始超过速度所节省的时间。

AI 现在加速了剩下的部分。模型起草代码，而且自从GitHub 在 2025 年 4 月让 Copilot 代码审查全面可用以来，模型也经常审查代码。诱人的回应是把敏捷推得更远：更短的循环、更多的智能体、更少的仪式。换句话说，更快地打破东西。但当一位工程师一天能开 40 个 PR 时，累积的变更可能让团队留下一个没人能理解的系统。

更好的位置介于两者之间。它不是瀑布模型的固定规格，但也不是完全没有规格。它意味着路线图要说明团队要去哪里以及为什么去，问题要在任何人生成解决方案之前先陈述问题本身，设计评审中人们要就权衡取舍展开争论。这种结构看起来会拖慢进度，但正是它让速度变得安全。爵士乐手之所以能自由即兴，是因为舞台上的每个人都知道和弦进行和曲子的结构。没有这个框架，他们只是在制造噪音。路线图对一群人及其智能体也起着同样的作用。它设定边界，在边界之内，每个人都可以在工具允许的范围内尽可能快地行动。

随着 AI 加速实现，规划如今成了唯一决定快速部分是否值得去做的环节。在我的博客 Synthetic Auth 上，我把这称为指挥与审计之间的区别。指挥者掌握“为什么”（需求、历史、用户），并引导智能体走向与之匹配的“怎么做”。审计者交出一张工单，检查代码能运行、测试能通过，然后发布。两者最终可能得到相同的 diff，但只有指挥者知道它是否解决了真正的问题。AI 审查者无法区分两者，因为它只看到 diff，看不到背后的意图。结构正是让指挥者有事可指挥的东西。

独奏者

独奏者往往是团队中最强的成员之一，脑子里积压着一堆从未被规划或写下来的想法。有了智能体集群，独奏者可以同时追逐每一个想法，结果就是一堆跨仓库的拉取请求，而这些仓库本季度根本没人计划要改动。每一段独奏或许都演奏得很好，但乐团的其他人正在演奏别的东西。

问题在于，所有这些改动可能会把团队拉向不同的方向。一个团队只有在其成员大致朝同一方向用力时才能前进。过去让个人保持一致的是成本。数周的努力迫使人们在开始一个项目之前先问它是否值得启动。智能体消除了这种成本，因此对任何独奏者的 PR 都值得问三个问题：这如何融入更大的图景？利益相关者是谁，有没有人跟他们谈过？除了智能体随代码一起编写的单元测试之外，这个改动是否针对它所触及的系统其余部分做过测试？太多时候，这三个问题的答案都是否，而 PR 之所以存在，只是因为当时觉得是个好主意。

历史上最接近的对应物是 1990 年代的终端用户计算。Access、Visual Basic 和大量使用宏的 Excel 让任何有 PC 的人都能构建应用，各部门构建了成千上万个。许多应用单独来看很有用，但无法彼此集成，也无法与现有 IT 系统集成，于是两个部门可能各自拥有独立的客户数据库，对客户是谁的说法还不一致。IT 部门花了接下来十年寻找、核对并淘汰这些系统，行业最终把这个问题命名为影子 IT。

那个时代的教训是：让东西建起来更便宜，并不会让它们变得廉价。成本会向下游转移，转嫁给那些不得不集成和维护成果的人。AI 审查可以跟上数量，但它只按各自的语境评判每个 diff。它无法告诉你，40 个正确的 PR 正把项目拉向 40 个方向，也无法告诉你，agent 的测试只能证明代码做了 agent 假定它该做的事。生产率的提升也可能比感觉上要小。在 METR 2025 年的随机研究中，16 名经验丰富的开源开发者在被允许使用 AI 时，完成真实任务的时间反而长了 19%。事后，他们估计 AI 让自己快了 20%。

有一件事是新的。Access 从不告诉任何人他们的想法很出色。如今，Soloist 用模型起草一份 RFC，再问同一个模型这份 RFC 是否合理，然后得到一个热情的“是”。这种模型谄媚是一个广为人知的问题：2025 年 4 月，OpenAI 甚至在用户发现 GPT-4o 几乎称赞他们给出的任何想法后，回滚了一次 GPT-4o 更新。薄弱的提案过去会早早夭折，被持怀疑态度的同事或一张白纸拦下。如今这种摩擦消失了。

答案不是把工具拿走。Soloist 往往是你最有能力的工程师，而 agent 让他们更有能力。把他们带回乐团里来吧。把每个 PR 都关联到共享路线图上的一个 issue，并在工作开始前而非发布后点名利益相关者。对任何跨越服务边界的变更，要求集成测试或端到端测试，而不是依赖 agent 编写的单元测试。让一个人来审查每份 RFC，而不是让帮忙撰写它的模型来审查。目标是让这些人才朝着共同的优先事项努力。

复制粘贴者

AI 对复制粘贴者的帮助比任何人都大。一项过去会卡上一整天的任务，比如一个 Helm chart、一条 IAM 策略，或一个用于解析日志的正则表达式，现在几分钟就能完成。问题在于，工作在被理解之前就完成了。和初级工程师一样，复制粘贴者分不清一个能用的答案和一个正确的答案，而 AI 的输出几乎总是看起来能用。复制粘贴者默认就是审计者，而且是一个没有审计知识的审计者。

早期的编程工具也制造过类似的问题。程序员们从 Richard Feynman 1974 年在加州理工学院的毕业典礼演讲中借用了“货物崇拜”一词，用来描述那种复制了可用解决方案的形式、却不理解其背后原理的代码。随后 Stack Overflow 让复制这种形式变得毫不费力。Fraunhofer AISEC 和慕尼黑工业大学的研究人员在《Stack Overflow Considered Harmful?》（IEEE 安全与隐私研讨会 2017）中测量了结果。在 130 万个 Android 应用中，15.4% 包含从 Stack Overflow 复制的安全相关代码，其中 97.9% 至少包含一个不安全的代码片段。

业界用护栏来应对 Stack Overflow 的风险：linter、CI 中的静态分析、强制代码审查以及带安全默认值的框架。同样的方法也适用于 AI，因为护栏检查的是输出，无论它由谁或什么产生。

自主智能体提高了风险。从 Stack Overflow 粘贴的代码仍需经过构建和审查才能造成危害。一个以 Copy-Paster 的凭据运行的智能体可以自行在生产环境中应用变更，并拥有该人持有的所有权限。OWASP 的 LLM 应用 Top 10 已将“过度代理”列为风险。Copy-Paster 是最有可能授予该权限的用户，因为他们最没有能力判断智能体即将做什么。

像管理初级工程师一样管理它们，即使他们的头衔写着高级。给智能体分配它们自己的、范围受限的短期凭据，而不是用户的凭据。要求先计划后应用的工作流程，以便在任何内容运行之前由人批准差异。在审查中，请 Copy-Paster 用自己的话解释每项变更。这就是他们学习的方式，也是你了解他们是否理解了变更的方式。

Godot 等待者

Godot 等待者并不反对 AI。他们在等待它准备就绪：更准确、治理更好、通过安全审查，或者只是更进一步。就像贝克特笔下的两个流浪汉，他们对于为什么今天不是那个日子有一个合理的解释，而且他们已经给了这个解释一段时间了。

每一次平台转变都有等待者。大型机商店在向客户端/服务器迁移的过程中坚持了下来，而“没有人因为购买 IBM 而被解雇”是一个真实的策略，而不是一句笑点。二十年后，许多企业表示他们永远不会将敏感数据放入公共云。2013 年 CIA 与 Amazon Web Services 签署了一份 6 亿美元的合同后，这一立场变得更加难以辩护。

等待可能是理性的。让别人支付早期采用者的税是一种合法的策略，而 Godot 等待者经常能发现狂热者错过的问题。危险在于，一个完成的、可信的版本永远不会作为单一事件到来。与此同时，一路使用这些工具的人已经建立了 Godot 等待者无法一下子获得的判断力。

讽刺的是，Godot 等待者往往有良好的指挥家直觉，包括怀疑精神、对上下文的关注，以及要求知道为什么。他们只是还没有拿起指挥棒。将他们的反对意见视为需求。询问必须满足什么条件，写下来，并在六个月后再次检查。让他们从低风险的只读工作开始，比如总结事件时间线或解释一个不熟悉的代码库。应用于真实输出的怀疑精神是有价值的，但没有实际用途的怀疑精神什么也教不了。

专家

专家将 AI 用于一小部分特定工作，以填补原本深厚专业知识中的空白。一位精通 BGP 的网络工程师让模型编写解析 40 个路由器配置的 Python 代码。一位能背诵 OAuth 规范的标识架构师让模型解码一个不熟悉的 SAML 断言，然后询问为什么该断言是这样构建的。他们使用 AI 既是为了理解事物，也是为了生产事物。

最近最接近的对照是科学计算领域的 Python 技术栈。2008 年，Wes McKinney 是对冲基金 AQR 的一名研究员。他的团队可以在半小时的会议里讨论完一个典型项目，但真正把它做出来，正如他后来所说，是“一大堆工作”，其中大部分是清理和搬运数据。他构建了后来成为 pandas 的东西，来解决这一个问题。科学家们用 Jupyter notebook 走了同样的路。2016 年 LIGO 发布其首次引力波探测的数据时，其中就包含一个逐步演示信号处理的 notebook。

这种模式产生了每个时代最持久的收益。专家型能检查输出，因为他们知道“正确”的答案长什么样。他们的提示词很精确，因为他们知道自己要问什么。当他们用工具来学习时，知识在会话结束后仍留在他们身上，因此随着时间推移，他们对工具的需求会越来越少，而不是越来越多。专家型是指挥短乐谱的指挥：他们自己掌握“为什么”，只把“怎么做”交给工具。

专家型需要最少的管​​理，也最容易被忽视，因为他们的产出不会以一大片 PR 的形式出现。找到他们，问问他们用 AI 做什么。他们那些狭窄、经过验证的用途清单，比任何供应商演示都更能指导你团队的 AI 战略。

游客型

游客型在工具上新闻时试用一下，得到一个令人印象深刻的答案或一个糟糕的答案，然后飘然离去，直到下一次发布。如果其他人是在指挥或审计，游客型就是观众。每个炒作周期都有他们。他们在 1990 年代末建了从未更新过的 GeoCities 页面，在 2006–2007 年热潮过后几年，建了大多空置的 Second Life 企业办公室。

游客型会扭曲你的指标。他们会出现在许可证计数和“你本月用过 AI 吗？”的调查中，这让采用看起来广泛，而实际使用其实集中在少数人身上。依据这些数字做预算的领导者会在续约时大吃一惊。衡量特定工作流的重复使用，而不是登录次数，并给每个游客型在他们自己的工作中分配一个工具能可靠帮助的具体任务。有些人会成为专家型。

是模式，不是性格

这些是模式，不是性格类型。同一个工程师可以在周末副业项目上是独奏者，在工作中是专家型，而在让智能体接触生产环境这件事上是戈多型等待者。这意味着给工程师正确的结构可以帮助他们切换模式。当编写和审查代码都只需几分钟时，问题、路线图和设计评审才是让团队的人保持指挥而非审计的关键。

罗杰斯曲线最终或许会显示，AI 在 IT 领域近乎全民采用，但仅凭采用率无法揭示人们使用它的效率如何。真正重要的是，使用它的人究竟仍在指挥自己的智能体，还是正被智能体所指挥。

来源：O'Reilly Radar · oreilly.com