在年度文化与方法趋势报告播客中，一群 QCon 演讲嘉宾与 InfoQ 编辑探讨了 AI 采用的成熟度与风险、工程团队结构与角色的转型，以及 2026 年软件开发中不可丢失的人文维度。本次对话由 Shane Hastie（文化与方法版本主编）主持，参与者包括 Ben Linders、Rafiq Gemmail、Craig Smith、Vanessa Formicola、Shawna Martell、Phillip Mortimer 和 Yinka Omole。
你也可以收听完整版文化与方法论趋势报告播客访谈及配套文稿。去年的访谈内容可参见 2025 年趋势报告播客。）
为了便于洞察 InfoQ 以及 QCon 和 DevSummit 全球软件开发大会所展现的当前与未来的行业趋势，我们采用了 Geoffrey Moore 在其同名著作中提出的”跨越鸿沟“技术发展模型。我们试图识别出符合 Moore 所描述的早期市场的理念，即“受众群体由技术爱好者和愿景家组成，他们希望抢在机遇或迫在眉睫的问题之前行动”。
正如我们在 2025、2024、2023、2022、2021、2020、2019、2018 和 2017 年的文化与方法趋势报告中所做的那样，我们同样附上 2026 年的主题图谱：
作为参照，下面是我们 2025 年的主题图谱：
AI 采用成熟度与风险
讨论以当下所有软件开发团队对话的开篇热点作为切入点：AI。但讨论小组的论调明显比行业高涨的追捧热情更为理性审慎。嘉宾提出了一个担忧，AI 采用已经陷入了”要么全有、要么全无“的两级模式，企业要么全盘跟风，要么完全观望。我们需要的是行业一直以来在面对技术决策时一贯秉持的基于风险的研判逻辑：风险是什么、会造成哪些影响、这款软件、这家企业、这支团队所处的实际具体情况如何？
讨论小组呼吁建立 AI 采用的成熟度框架：企业要意识到，低风险内部工具与业务关键系统，二者所需的自动化程度和人类介入规模应该是不一样的。企业应当理解 AI 在其情境下究竟能在多大程度上成为改进的催化剂，以及在多大程度上不能，而不是不分场景、全域强行落地 AI。
两极分化：敏捷是根基
延续 2025 年度报告的一大核心观点，拥抱了新实践的企业与从未建立基础的企业之间的差距正在扩大。讨论小组引用了 Jim Highsmith 在讨论中发出的警告：”如果你在敏捷上失败了，你在 AI 上会失败得更惨“。许多企业仍未将敏捷开发的基本原则嵌入其工作方式中，而现在他们正试图在这个缺失的基础之上妄图依靠 AI 来提升迭代速度。
“这就是卓越与平庸之间的差距。有些企业已经拥抱敏捷并付诸实践，但还有很多企业在二十五年的时间里从未真正完成向敏捷实践的跨越。现在他们试图拥抱这些新技术，但仍停留在 1995 年的软件开发运作模式上。”
——Craig Smith
重要的实践并未发生改变：快速反馈循环、可观测性、发布的可靠性，以及向目标用户交付精准价值。讨论小组指出，AI 时代出现的许多“新”的学科，如 Harness 工程、护栏和规范驱动开发，本质上大多只是业界打磨数十年的经典实践换了新名称。研究过去所做的事情，能够为团队后续发展筑牢根基。如果说有什么变化，那就是这些基础比以往任何时候都更加重要，因为当下技术风险更大、单次交付的代码量也更大。
认知负担与超高速开发
如果说 2025 年的报告担忧的是 AI 生成的代码量，那么 2026 年的现状印证了这一趋势。讨论小组引用了 GitHub 的数据：从去年约十亿个 PR 到 2026 年预测的一百四十亿个，意味着整个行业研发体系中的代码变更总量将会暴涨至原先的 14 倍。播客此前也曾提及一组数据：代码发布量提升 3 倍，随之而来的漏洞数量却激增 4 倍。
“我关注的是我们该如何应对极速开发所带来的认知负担。所有人都在被推着前行，也许很多人都在被推动去采用超高速工程、复合工程，同时在多个工作流上工作，可能同时运行着多个智能体。而作为人类，要跟上这一切、还要频繁切换上下文，变得非常困难……例如，以 合并 PR 为例 i，你真的能读完 AI 生成的所有代码吗？”
——Phillip Mortimer
这不仅仅是流程问题，更是人的问题。嘉宾谈到，开发者往往会同时启动多个 AI 智能体——不想在智能体工作时“干坐着”，这使得人们需要周旋于各类抽象概念之间，不断切换工作上下文，而人类本就不擅长这类行为。由此引出一个开放性问题：长此以往，研发人员的个人能力将会付出怎样的代价？当一些工程师知道如何甄别智能体输出的内容，而另一些人不加批判地信任它时，会产生何种后果？原先为人类产出效率而设计的开发流程，如拉取请求审查，可能已经不再适用；行业需要构建新的系统，让我们能够在这种新的超快开发节奏下管理和理解我们正在构建的东西。
代码产能过剩时代的价值定义
随着代码生成的成本近乎归零，讨论小组反复探讨一个在 AI 普及之前就已存在、但现在变得愈发紧迫的问题：我们在构建真正有价值的东西吗？
“现在产出代码真的很容易，比以往任何时候都容易。我们是否做好了必要工作来确认自己确实在为客户解决原本想要解决的问题？我们是否做了所需的衡量工作来验证这些实验是有效的？”
——Shawna Martell
早在 AI 普及之前，企业就难以形成完整闭环：只管交付成果，却从不验证这些成果是否真正解决了问题。现在的风险在于这种模式正在大规模上演。小组讨论提到了“工作垃圾”（Workslop，《哈佛商业评论》年度热词，将 AI 生成的、会增加价值链下游从业者工作负担的东西），并抛出疑问：整个行业如今正在产出多少垃圾代码。
经济层面的因素让这个问题变得更加棘手。词元消耗成本高昂，使得 FinOps 比以往任何时候都更加重要。讨论小组提出了一个在 AI 在炒作周期中很少听到的警告：当下各类模型与 AI 能力本质上高度依赖上游厂商补贴才能维持运转。那些绑定了这类补贴的企业应该要思考：当经济情况变化要采取怎样的应对方案，以及投资回报是否真的能够落地兑现。
工程师作为守护者
也许对今年角色转变最清晰的阐述，是将工程师框定为守护者而非贡献者。
“感觉工程师正在变得更像守护者，而不仅仅是贡献者。我们正在看到这种变化……更多人正在采用 AI，但信任其输出的人在变少，这是一个十分耐人寻味的矛盾。我认为，作为工程师，我们的角色会更多地演变为通过构建更多系统、护栏、让一切协同工作并驱动正确业务产出的东西来提升人们对 AI 的信任度。”
——Yinka Omole
守护的职责也延伸到了维系团队共识和促进有效的知识传递。在 Hacker News 最近的一篇文章《为什么软件工厂会失败》中，HumanLayer 创始人 Dex Horthy 认为，编码大模型“如果没有相当数量的人工引导，就无法长期维护和提升代码库质量”。相关的讨论也反映了从业者普遍存在的同样的担忧。在最近一篇 InfoQ 文章《为演进式架构构建上下文存储》中，Stella Berhe、Stephan Bragner、Vikram Maran 和 Anand Jayaraman 提出，通过维护一个版本化的上下文存储来使这种引导持久化，其中包含一个机器可读的知识图谱，工程师和 AI 智能体可以从中查询领域知识、设计意图和架构约束。
讨论小组指出的“采用与信任”矛盾在行业数据中得到了证实：Sonar 2026 年开发者代码现状调查报告显示，AI 现在占提交代码的 42%，然而 96% 的开发者并不完全信任它们，只有 48% 的人会在提交代码前对其进行验证。讨论小组发现，工程师正转向平台工作，搭建标准化最优开发流程（黄金路径）与通用标准化组件（黄金模块），即可供智能体编写代码的平台，提升代码评审效率。此外，工程师正在让工程部门之外的同事也能参与贡献。产品和设计团队现在可以像工程师一样自由地提交代码（人人都是开发者），而工程师则负责提供底层基础组件、架构设计和 API，使这类开发模式安全可控。
团队演变：从两张披萨到一张披萨
讨论中最活跃的部分是关于开发团队本身正在发生的变化。
“我们过去谈论 T 型技能、跨职能团队、以及两张披萨团队。我现在可以看到两张披萨团队正在变成一张披萨团队：两个人加一个 AI 工具或一群智能体。”
——Shane Hastie
讨论小组认为，现在的团队组织形式取决于系统未来如何演进：业务关键软件仍会保留传统形态的团队架构，由智能体赋能，而风险较低的产品可能只需要一个产品经理加一个开发者。智能体与人类组成团队，以及纯智能体团队，都是可能的配置，具体取决于风险等级。讨论小组提出了一个颇具颠覆性的全新视角，“团队”可能不再是组织管理的基本分析单元。我们真正需要思考的问题，不再是如何搭建团队架构，而是无论协作形式如何——无论是单人搭配智能体，还是整个大型组织协同运作，都要保障协作高效落地。
各类岗位的职责边界正在变得模糊。讨论小组描述了工程师与管理者钟摆的回摆，管理者重新回归写代码，前端/后端/平台的界限逐渐消解，贡献者很快就成为负责人，因为管理一群智能体就是负责人级别的工作。一位嘉宾甚至宣称，旧的分类——工程经理、首席工程师、后端、前端——“现在肯定已经过时了”，成熟度被重新定义为技能的广度以及在该广度上的熟练程度。
团队规模收缩的同时，外界对团队产出的期望值却在不断抬高。一张披萨团队可能被期望交付以往大型团队才能交付的产出，同时要承担协调、验证、支持和问责。AI 加速了生产，但并没有消除人的工作。相反，人的工作重心转向编排、审查和决策。正如 DX 副 CTO Justin Reock 在纽约 QCon AI 大会演讲《AI 辅助工程中的领导力》中所论述的，开发者体验从根本上说是一个系统问题。企业需要提供能够减少协作摩擦、苦差事、认知疲劳和倦怠的环境，而不是借着单人产出能力提升一味提高期望。
但讨论小组对一人团队所带来的风险也同样保持清醒。工作的一部分乐趣在于与人共事，很难想象人类会对智能体产生同样的感觉。有人描述了这样的组织：小团队变成了大量个体，每个人都安静地配合智能体工作，在站会上各说各话，以及用 AI 来总结 AI 生成的四十七页文档，形成了“依靠 AI 处理 AI 产出内容”的荒诞局面。以往团队的魅力在于成员视角各异、专长不同，大家相互碰撞、辩驳观点，但当团队变成一个个单人项目的集合时，这种思维碰撞的活力就退化了。这种担忧延伸到思想多元性的消亡：当每个人都使用一个基于相同语料库训练出来的智能体工作时，团队富有创造力的个人多样性就悄然丧失了。
AI 时代的心理安全
心理安全这一概念在这些报告中已经出现多年。讨论小组被直接问到：我们不是从 2014 年起就在解决这个问题了吗？
“团队内部、团队之间、组织之间的协作模式正在发生改变。而促成这种协作的一个关键因素是心理安全与透明度的结合。那么人们彼此之间是如何沟通的？他们是否感到足够安全，敢于提出任何问题？”
——Ben Linders
讨论小组对“我们不是已经解决这个问题了吗”这一疑问的回答是，确实有了很多积极的进展，但心理安全感在疫情期间出现了下滑，而近来全球的发展变化又在再次冲击着心理安全。它仍然与 AI 能力挂钩。人们是否驾驭 AI 开展工作，又拥有足够的安全感敢于提出问题？这绝对不是一个已解决的问题。在讨论的后半段，谈到员工身心健康这一点时更加尖锐：讨论小组引用的一项哈佛研究表明，AI 加剧而非减少了工作量。调查显示，70% 至 80% 的人认为自己的角色面临 AI 的威胁，焦虑情绪和超负荷工作正在叠加。如果人们在行业全速前进的同时变得更加焦虑和劳累过度，那么“我们有能力这么做，但我们理应这么做吗？”这个问题不仅适用于产品，也适用于工作方式。
初级工程师、职业路径与资历的新含义
讨论小组坚决驳斥了 AI 消除了对初级工程师需求的观点，同时承认职业路径确实正在发生转变。讨论小组分享了一个值得警醒的故事。一家公司试图让没有经验的员工通过氛围编码从零开始重建一个税务系统，结果失败了。即使能够借助 AI “挥动魔杖就让程序跑起来”，但不代表就拥有判断这套系统两年后能否扩容、是否便于维护的判断力——这种判断力只能源自亲身历练、持续学习、历经失败与收获成功的成长过程。
讨论小组提出了一个关于学习可塑性的见解：如今资深工程师正投入精力去训练机器，比如构建护栏和测试框架、纠正重复犯错的智能体，而初级工程师恰恰拥有智能体所欠缺的可塑性。他们只需经历一次错误，就能举一反三吸取教训，在做技术选型时会考虑库的选择是否与平台一致，而不仅仅是遵守规则。讨论小组还提到一个新兴模式：将初级工程师定位为守门人，验证来自产品和设计贡献者的工作，这种定位本身已经高于初级工程师传统的入行起点，这也引发了一个现实难题：新人如何达到那个入门门槛。与此同时，初级工程师因使用 AI 工具而导致技能掌握程度下降。
关于资历，讨论小组指出，如今一个具有良好判断力的资深人士发现 AI 是一个巨大的力量倍增器，而对初级工程师来说，AI 带来的能力增益往往事与愿违。关于未来存在的分歧，一种观点认为，在一年内，决定性的技能将是管理智能体的能力，而年轻一代的可塑性将让他们的能力远超老一辈从业者。相反的观点认为，熟练使用工具从来都不是难点，真正来之不易的技能是针对产品与业务问题提出精准有效的问题，而这种在点滴领悟中不断成长的过程，不存在任何捷径。一个故意具有争议性的观点认为，职业路径的变化可能小于预期，因为领导者从来不是因为写出最好的代码而被选中的，而是因为愿景、判断力和培养他人的能力，这些是 AI 无法改变的特质。
“我们需要理解的是新的衡量标准：我能对多少东西负责？不是我能交付多少东西，而是我能对多少东西负责。这些对我来说才是工程师更广泛意义上的责任与技能组合的新标准。”
——Vanessa Formicola
创造力与核心业务技能
AI 能找到问题的创造性解决方案吗？讨论小组的经验是，它往往不能。它能写出语法正确、甚至质量上乘的代码，但创造性问题仍然需要人类来解决。讨论小组援引摄影发展史，给出了偏向乐观的类比：摄影诞生让人类无需亲手一笔一画作画，由此催生了印象派与抽象艺术；参数化设计让建筑师不必敲定每一颗螺栓的规格，建筑领域的创意自此迎来爆发式增长。按照这一逻辑，倘若人人都能参与构建，创造力只会变得愈发重要、愈发丰富，而非更少。一个补充观点认为，约束反而能提升创造力。当智能体消除了无尽的编程语言和库选型争论时，人们的注意力就被解放出来用于解决实际的问题。
另一方面是倡导坚守核心领域专业能力。即便任何人都能调用智能体编写代码，也不代表任何人都可以构建银行交易处理系统。批判性思维已经嵌入专业知识体系数十年，包括软件工程、项目管理、业务分析和测试。丢掉业务分析、架构和软件工程，就等于失去了人类审核环节，而只有人类能够在这一环节做出判断：“没错，技术上可以实现，但出于种种原因，我们必须对此加以约束管控。”。领域知识也至关重要。理解你的客户和你的业务，是为了向 AI 提出正确的问题并验证其输出。与客户沟通是摸清客户真实需求最简单的方式。
伦理困境与问责鸿沟
当被直接问及 2026 年合乎伦理的工程实践该是什么模样时，讨论小组将焦点放在问责机制上。大家最关切的问题是：一旦失去对自研系统的完整掌控，我们就再也无法为自己的行为承担责任。过去从业者跟代码有着紧密的接触，尚且会出现疏漏，如今的现状却是“构建能力越强，我们能弄懂的部分却越少”。讨论小组的观点是：无论代码是否由 AI 生成，技术从业者都必须对自己交付的代码承担责任；要么就要对系统配套的测试框架具备十足信心，并同样为交付的代码负责。从业者绝不能拿“这是 AI 生成的，我怎么清楚？那可是一亿行代码”当作推脱责任的说辞。构建使真正的问责成为可能的控制措施是守护者工作的一部分。
AI 带来的环境影响
讨论小组直面 AI 建设带来的环境成本：电力、水，以及行业在碳减排目标关键窗口期加速消耗资源这一令人不安的事实。他们提到了 Jutta Eckstein 此前在播客中的呼吁，即将服务产生的环境足迹列为可量化指标。如今借助令牌消耗量，每位工程师都能直观看到系统环境的损耗，尽管大多数人只有在达到配额时才会注意到它。
“现在我们正在燃烧词元。我们面前摆着一个指标，可以间接衡量我们所做工作造成的环境影响……我之前提到过一个叫 Neuralwatt 的项目，我真的很喜欢他们的模式……他们的定价模型基于功耗……本质上是把对环境的影响暴露给我们看，我真的很喜欢这种做法。”
——Rafiq Gemmail
Neuralwatt 按照功耗而非词元数量来为开源模型推理定价——这是一个细微的信号，表明行业可能开始将 AI 的能源成本体现在定价中。讨论小组还指出了一种普遍陋习：任务明明不需要高级模型却仍习惯性选用顶级模型（拿一把大锤子去砸所有钉子）。在正视能耗成本的同时，大家也认可 AI 具备可观的正向价值。人们可以有针对性地将 AI 应用于核聚变、医疗和其他关乎人类文明发展的问题。讨论小组同时指出了两个事实：这是一项真正具有变革性的技术，而审慎地使用它是一种工程责任。
对未来的期许
讨论以每位小组成员对行业的期许结束：
在应用技术时应更加审慎，尊重人、环境和业务增长
互相照应，留意身边同事能否跟上变革节奏
更加关注质量和测试，快速构建虽容易，构建坚固且有价值的东西才是重点
在这场被比作工业革命的转型中保持同情心和人文主义
不要忽视那些不变的东西，培养后继者，构建能够解决问题的产品；将焦点从产出和指标转移到协作、创造力和人的因素
继续拥抱人性和创新，因为真正的创新来自人们的协作
结语：一切仍然关乎人
整场 2026 年研讨会贯穿一条主线：技术问题越来越确定，而人的问题越来越紧迫。当代码变得唾手可得时，稀缺的是判断力。从业者需要完成这些关键工作：判断系统需要多大程度上适配 AI 及其风险等级；核验上线交付的产品并为之承担责任；保护使团队富有创造力的协作和思想多样性；培养将成为资深人士的初级工程师；审慎使用这款能耗高昂的技术工具。
对于希望在这一环境中蓬勃发展的团队，讨论小组的关键教训包括：
在落地 AI 时结合风险与业务场景综合研判，拒绝“要么全有、要么全无”的极端思路，清晰认清自身业务目标。
首先巩固基础：快速反馈循环、可观测性和价值评估机制。AI 会放大原有基础的优劣。
为 AI 规模的输出重新设计质量和审查流程。传统的 PR 评审机制已经无法应对代码量暴涨 14 倍的现状。
衡量发布的产品是否真正在改善客户生活，并以 FinOps 规范管控词元消耗量与投资回报率。
将工程师培养为护栏构建、验证和促成组织安全贡献的守护者。
随着团队缩小，主动维护协作氛围。一人团队牺牲了使工作可持续的多元视角和乐趣。
继续培养初级工程师。他们的可塑性正是智能体所缺乏的。
对你发布的东西负责。对 AI 生成系统承担责任是一项工程准则，而不是事后推脱的借口（“那是 AI 干的”）。
将 AI 产生的环境成本视为一等工程指标，有意图地选择模型，而不是默认使用大锤砸所有钉子。
主持人以一句毛利谚语结束了对话：
“世界上最重要的东西是什么？是人，是人，是人。”
