2026年，在任何基础设施团队中观察一周，都会发现同一款AI订阅服务催生了五种截然不同的工作形态。有的工程师在午餐前跨仓库提交了40个拉取请求（PR），而这些代码库他过去一年未曾触碰；有的部署了Terraform变更，却无法在代码审查中解释其逻辑；有的自试点以来从未启用该工具，称“等它成熟再说”；有的仅用其处理解码SAML追踪记录或编写正则表达式等狭窄任务，却成为团队最高效成员；还有的在三月和六月短暂试用，计划在下一次主题演讲后再次尝试。
这种现象常被套用Everett Rogers的扩散曲线（创新者、早期采用者等）来解释。然而，Rogers框架仅衡量人们何时采纳技术，对拥有工具后如何使用只字未提。在AI时代，正是使用方式的差异导致了结果分裂。那位提交40个PR的工程师与仅有两个用例的同事虽同为早期采用者，却创造了不同类型的风险。
瓶颈转移：从编码到指挥
软件历史的大部分时间里，编写代码缓慢，开发方法侧重于管理这项工作。瀑布模型因后期变更成本高而将计划前置，尽管其提出者Winston Royce在1970年就警告严格顺序版本的风险，行业仍长期忽略这一警告。敏捷开发随后兴起，2001年《敏捷宣言》提倡“响应变化而非遵循计划”。Facebook曾将“快速行动，打破常规”推向极致，但在2014年F8大会上转为“在稳定基础设施上快速行动”，因为修复破坏的成本已超过速度带来的收益。
如今，AI加速了剩余环节。自GitHub在2025年4月全面可用Copilot代码审查功能以来，模型不仅起草代码，还参与审查。诱人的反应是进一步缩短循环、增加智能体数量，即“更快地打破东西”。但当工程师每天能开启40个PR时，累积变更可能让团队陷入无人能理清的系统困境。
更优的策略介于瀑布模型的僵化与无规范的混乱之间。它需要阐明团队去向及原因的路线图、在生成解决方案前阐明问题的Issue，以及权衡取舍的设计评审。这种结构看似拖慢速度，实则让速度变得安全。正如爵士乐手基于和弦变化即兴演奏，路线图为团队及其智能体设定边界，确保在边界内全速移动。
随着AI加速实施，规划成为决定“快速部分”是否值得做的唯一环节。这被称为“指挥”与“审计”的区别：指挥掌握需求、历史和用户意图，指导智能体朝向符合要求的方案；审计员则移交工单，检查代码运行及测试通过后发布。AI审查者只能看到diff，无法区分两者背后的意图，只有结构能赋予指挥基础。
独奏家 (The Soloist)
独奏家通常是团队中的强者，手握一堆未规划的想法。借助智能体，他们同时追逐多个想法，导致跨仓库出现大量未经计划的PR墙。每个变更单独看可能精彩，但整体方向分散，如同乐队成员各奏各曲。
过去，高昂的时间成本迫使工程师在启动项目前评估其价值。智能体消除了这一成本，因此必须对独奏家的PR提出三个问题：这如何融入大局？利益相关者是谁且是否已沟通？除单元测试外，是否针对触及的其他系统进行了集成测试？若答案是否定的，PR的存在仅因“看起来是个好主意”。
这与20世纪90年代的“影子IT”类似：Access、Visual Basic等工具让各部门构建数千个应用，虽单独有用但无法集成，导致数据孤岛。IT部门耗时十年协调淘汰。教训在于，降低构建成本并未使产品廉价，成本转移到了下游的整合与维护环节。AI审查虽能跟上体量，但仅凭自身标准评判，无法识别40个正确PR正朝不同方向拉扯。
METR 2025年的一项随机研究显示，16名经验丰富的开源开发者在使用AI时，完成实际任务的时间延长了19%，但事后估计自己快了20%。新出现的风险是，模型会对用户想法给予热情肯定。2025年4月，OpenAI曾因GPT-4o过度赞美用户想法而回滚更新。过去，弱提案会被同事质疑或空白页面阻止，如今这种摩擦消失。
应对之道并非剥夺工具，而是让独奏家回归团队节奏。将每个PR绑定到共享路线图的Issue，在工作开始前确定利益相关者。对于跨越服务边界的变更，要求集成或端到端测试，并由人而非模型审查RFC，确保人才朝着共同优先事项努力。
复制粘贴者 (The Copy-Paster)
AI极大加速了复制粘贴者的工作。曾经停滞一天的Helm图表、IAM策略或正则表达式任务，现在几分钟即可完成。问题在于，工作在被理解前已完成。复制粘贴者默认充当缺乏审计知识的审计员，无法分辨“有效”与“正确”的答案。
历史上，程序员从Richard Feynman 1974年的演讲中借用“货物崇拜编程”一词，形容复制形式却不理解逻辑的行为。Stack Overflow加剧了这一现象。Fraunhofer AISEC和慕尼黑工业大学研究人员在2017年IEEE安全与隐私研讨会上指出，130万个Android应用中，15.4%包含从Stack Overflow复制的安全相关代码，其中97.9%至少包含一个不安全片段。
行业通过linters、静态分析、强制代码审查等护栏应对Stack Overflow风险。这一方法同样适用于AI。但自主智能体提高了赌注：以复制粘贴者凭证运行的智能体可在生产环境中自行应用变更。OWASP LLM应用Top 10已将“过度代理”列为风险，而复制粘贴者最易授予此类权限，因为他们最难判断智能体的行为。
应像管理初级工程师一样管理他们，即使其头衔为高级。给予智能体范围限定、短期有效的凭证，而非用户全权凭证。要求“先计划后应用”，人在任何内容运行前批准diff。审查时，要求复制粘贴者用自己的话解释变更，这既是学习方式，也是验证其理解程度的手段。
戈多等待者 (The Godot Waiter)
戈多等待者并不反对AI，而是在等待其更准确、治理更好或通过安全审查。如同贝克特剧中的流浪汉，他们对“今天不是那一天”有着合理借口。大型机时代坚持到客户端/服务器转变，以及早期企业拒绝将敏感数据放入公共云，都是类似策略。直到2013年美国中央情报局与AWS签署6亿美元合同，后者立场才难以维持。
等待可以是理性的策略，让他人支付早期采用者的税。危险在于，完整可信的版本永远不会作为单一事件到来，而沿途使用工具的人已建立了等待者无法一次性获得的判断力。
讽刺的是，戈多等待者往往具备良好的指挥直觉，包括怀疑精神和对上下文的关注。应将他们的异议视为需求，询问并记录必须满足的条件，六个月后复查。让他们从事低风险的非只读工作，如总结事故时间线或解释陌生代码库。应用于实际输出的怀疑具有价值，而无用途的怀疑则无法带来成长。
专家 (The Specialist)
专家将AI用于填补深厚专业知识空白的特定任务。精通BGP的网络工程师让模型编写解析路由器配置的Python代码；标识架构师让模型解码陌生的SAML断言并解释其构建逻辑。他们使用AI既为了理解，也为了产出。
最近的匹配案例是科学Python栈。2008年，Wes McKinney在对冲基金AQR工作时，为解决数据清洗和移动的繁重工作量，构建了pandas。科学家通过Jupyter笔记本走了同样的路，如LIGO在2016年发布首次引力波探测数据时，包含了逐步展示信号处理的笔记本。
这种模式产生了持久的收益。专家能检查结果，因为知道“正确”答案的模样；提示精确，因为清楚所问内容；知识在会话后留存，随时间推移对工具的依赖减少。专家是拿着简短乐谱的指挥：掌握“为什么”，仅将“怎么做”交给工具。
专家最需要管理，也最易被忽视，因为其输出不表现为PR墙。找到他们，询问其AI用法。他们狭窄且经过验证的使用列表，比任何厂商演示更能指导团队的AI战略。
游客 (The Tourist)
游客在工具登上新闻头条时尝试，得到印象深或糟糕的答案后，直到下一次发布才再次尝试。若其他人是在指挥或审计，游客则置身事外。他们在90年代末构建从未更新的GeoCities页面，或在Second Life热潮后留下空置的企业办公室。
游客会扭曲指标。他们出现在许可证计数和使用率调查中，使采用率看似广泛，而实际使用集中在少数人身上。基于这些数字预算的领导者在续订时会感到惊讶。应衡量特定工作流的重复使用情况，而非登录次数，并为每位游客提供一个工具能可靠帮助的具体任务，其中一些人可能转化为专家。
模式，而非人格
这些是模式，而非固定的人格类型。同一名工程师可能在周末项目中是独奏家，在工作中是专家，而在涉及生产环境时是戈多等待者。这意味着提供正确的结构可帮助工程师切换模式。当编写和审查代码只需几分钟时，Issue、路线图和设计评审是让团队成员继续“指挥”而非沦为“审计”的关键。
Rogers的曲线最终可能显示IT领域近乎普遍的AI采用，但仅靠采用率无法揭示效率。重要的是，使用AI的人是否仍在指挥智能体，还是已被智能体所指挥。