内容来自于2026年2月ThoughtWorks的一场闭门讨论会, 原文地址见文章最后。

软件工程的未来

闭门研讨会发现与战略洞察

感谢各位参与本次研讨，共同探讨AI重塑软件构建方式过程中最重要的问题。以下内容是对所有分组讨论中关键主题和要点的综合梳理。

本次研讨会遵循查塔姆宫规则（Chatham House Rule）。本摘要中不披露任何参与者姓名或所属机构。

2026年2月

执行摘要

来自大型科技公司的资深工程从业者齐聚一堂，参加了为期多天的闭门研讨会，直面AI变革软件开发过程中最重要的问题。讨论涵盖了二十多个主题的分组讨论，但最重要的洞察并非出自某个单一讨论环节。相反，它们在各个交叉领域浮现出来——我们发现，相同的关切不断出现在不同的对话中，由解决不同问题的不同人士提出。

本文综合梳理了这些横跨主题的发现，围绕资深领导者当下需要理解和采取行动的模式进行组织。研讨会没有产出一个单一的、统一的未来愿景，而是产出了更有用的东西：一张标注了当前实践正在断裂、新实践正在形成的断层线地图。

“我们在每个房间里都在问同样的问题：如果AI接管了代码编写，那工程本身到底去了哪里？没有人给出相同的答案。但所有人都同意，这个问题十分紧迫。”

主题概览

以下是每个主题的详细发现。

1. 严谨性去了哪里？

研讨会上最重要的一个问题。几乎在每个讨论环节中都有出现。

如果AI接管了代码生产，那么过去存在于编写和评审代码过程中的工程纪律并不会消失——它会转移到其他地方。研讨会在这个问题上花费的时间比其他任何问题都多，从多个角度进行探讨，包括代码评审、测试、语言设计、自愈系统和组织设计。

研讨小组确定了严谨性正在转移的五个方向：

上移至规格说明评审

多位从业者报告说，他们已经将评审重心从代码转移到了代码之前的计划上。有人描述了自己的做法是“预先评审计划，事后评审工程”，而不是评审代码本身。逻辑很简单：如果AI根据规格说明生成代码，那么规格说明就是捕获错误的最高杠杆制品。糟糕的规格说明会大规模地产生糟糕的代码。

这有实际的影响。正在尝试规格驱动开发的组织发现，规格说明本身需要新的格式。传统的用户故事太模糊了。一些团队正在采用结构化方法，如EARS（易用需求语法方法）、状态机和决策表。这些并非新技术，但它们正在被重新发现，因为它们能给AI智能体提供足够的精度来生成正确的实现。

转入测试套件，使之成为一等制品

研讨会上最值得分享的洞察之一是：测试驱动开发（TDD）能从AI编码智能体中获得显著更好的结果。其机制是具体的：TDD阻止了一种失败模式——智能体编写的测试验证的是错误的行为。当测试先于代码存在时，智能体无法通过编写一个仅仅确认其错误实现的测试来蒙混过关。

这将TDD重新定义为一种提示工程。测试成为非确定性生成的确定性验证。多位从业者描述了将评审工作完全转移到测试套件上，将生成的代码视为可丢弃的。如果测试正确且代码通过了测试，那么无论代码看起来如何，它都是可接受的。

从业者洞察
“TDD配合智能体编码，我获得了前所未有的最佳结果，因为它阻止了一种特定的思维错误——智能体编写测试来验证其错误行为。”

转入类型系统与约束

研讨会浮现出对利用编程语言特性来约束AI生成代码的强烈兴趣。与其在代码生成后再进行评审，从业者们正在探索如何让错误的代码无法被表达出来。这借鉴了形式方法和强类型系统的思想，不是作为学术练习，而是作为智能体输出的实用护栏。

一个关键洞察是将规格说明与约束分离。规格说明描述应该改变什么；约束定义允许改变的有界上下文，包括什么不能被触碰。这些约束限制了爆炸半径，并让智能体能够安全地跨领域边界工作。当一个约束必须被打破时，它标志着一个新的系统边界，并促使进行重构。

转入风险映射

并非所有代码都承载相同的风险。研讨会讨论了按业务爆炸半径对代码进行分级，区分内部工具、面向外部的服务和安全关键系统。这种风险映射决定了哪里需要人工评审，哪里自动化验证就足够了。

一位从业者将此定义为新的核心工程纪律：组织不应该再问“有人评审过这段代码吗？”，而应该问“如果这段代码出错，爆炸半径是什么，我们的验证是否与该风险相称？”这将工程从工匠模式（每一行都由人工评审）转变为风险管理模式（验证投入与风险暴露匹配）。

转入持续理解

如果代码变化的速度超过了人类评审的速度，那么通过代码评审构建心智模型的传统方式就会崩塌。研讨会讨论了替代方案：每周架构回顾、多位工程师同时在同一代码上工作的集成编程（ensemble programming），以及能按需生成系统概览的AI辅助代码理解工具。

其背后的担忧是真实的。一位从业者指出，代码评审在历史上既是学习机制也是质量关卡。指导、共同理解和代码库熟悉度都通过评审过程实现。失去这个渠道而不加以替代，会造成随时间复合累积的理解缺口。

“结对编程解决了所有这些问题。如果理解系统很重要，那就一直这样做。不要分成小阶段来进行代码评审。要持续不断地尝试理解这段代码在做什么。”

2. 中间循环：一种新的工作类别

研讨会上最具先发优势的概念。行业内尚无人为此命名。

软件开发长期以来一直用两个循环来描述。内循环是开发者个人的编写、测试和调试代码的周期。外循环是更广泛的CI/CD、部署和运维的交付周期。研讨会识别出第三个循环：一个介于两者之间的监督性工程工作的中间循环。

这个中间循环涉及指导、评估和修正AI智能体的输出。它需要与编写代码不同的技能集。它要求具备将问题分解为适合智能体处理的工作包的能力、校准对智能体输出信任度的能力、识别智能体何时产出看似合理但实际错误的结果的能力，以及在多个并行的智能体生成工作流中维持架构一致性的能力。

在这项新工作中表现出色的从业者往往有以下共同特征：

• 他们以委派和编排而非直接实现的方式思考。 • 他们拥有强大的系统架构心智模型。 • 他们能够在不逐行阅读的情况下快速评估输出质量。 这些是经验丰富的工程师往往具备的技能，但它们很少在职业发展阶梯中被明确培养或认可。

职业影响
中间循环给热爱编程的开发者制造了真正的身份认同危机。许多人当初被雇用恰恰是为了将预先消化好的工单转化为可工作的代码。这项工作正在消失。新工作需要不同的能力和不同的职业满足感来源。不帮助员工完成这一过渡的组织，将因挫败感而失去最有经验的人才。

研讨会与计算机图形学的历史进行了类比。1992年，工程师手写多边形渲染算法。两年后，这项工作被推入硬件，而工作变成了动画和光照。今天，则是自定义物理和游戏世界。每当抽象层上升时，坚持认为自己是被雇来渲染多边形的工程师就会被落在后面。同样的动态正在代码生产领域上演。

产品管理方面的情况同样不确定。如果开发者现在更多地思考构建什么以及为什么构建，那么他们正在做的工作过去属于产品经理。一家大型科技公司正在积极研究产品经理角色是否需要一个新名称。另一家正在培训所有产品经理在开发者工具中使用Markdown。这种趋同是真实的，即使没有人就其最终走向达成共识。

3. 智能体拓扑与企业架构

康威定律没有退休。它变得更复杂了。

研讨会引入了“智能体拓扑”的概念，作为团队拓扑（Team Topologies）框架的扩展。其前提是：如果组织设计的系统反映其沟通结构，那么当智能体成为这些结构中的一等参与者时会发生什么？

与人类不同，智能体可以被即时复制并部署到多个团队中，没有入职摩擦。一个专业的数据库智能体可以同时存在于每个团队中，带来一致的专业知识，而不会出现依赖单一人类数据库专家时的集中化瓶颈。这听起来像是纯粹的好事，但研讨会识别出了几个复杂因素。

速度不匹配

智能体消化积压工作的速度如此之快，以至于它们与缓慢的组织依赖关系发生碰撞。一位参与者描述了这种经历：你给一个团队AI工具，他们在几天内清空积压工作，然后就撞上了跨团队依赖、架构评审和人类速度决策的墙壁。结果不是更快的交付，而是同样的速度加上更多的挫败感，因为瓶颈已经从工程能力转移到了其他一切。

智能体漂移

从上下文中学习的智能体会随时间发生分化。在电商后端工作的数据库智能体会积累与在ERP系统中工作的那个不同的模式和偏好，即使它们的初始配置完全相同。这反映了团队特定规范的人类问题，但时间线被加速了。研讨会讨论了应该管理这种漂移（类似于人类团队的标准化努力）还是接纳它（类似于让团队进行本地优化）。

决策疲劳成为新瓶颈

如果智能体产出工作的速度超过领导者评审和批准的速度，那么约束就从生产能力转移到决策能力。过去充当协调点的中层管理者现在变成了审批瓶颈。多位从业者报告这种情况已经在他们的组织中发生：智能体生成工作规范、代码修复和功能实现的速度，快于任何人能说“同意”的速度。

研讨会提出了一个尖锐的问题：如果人类对理解系统有能力上限而智能体没有，我们还需要那么多中层管理者吗？小组未达成共识，但这个问题本身就预示着前方存在重大的组织挑战。

“我们为人类优化了软件交付流程。现在参与者不仅仅是人类了，我们必须重新思考组织到底意味着什么。”

4. 自愈与自改进系统

雄心是真实的。但前提条件远未满足。

研讨会探讨了软件系统能否从人工驱动的事件响应转向智能体辅助的自愈。小组区分了两个层次的雄心：自愈（将系统恢复到已知良好状态）和自改进（主动演进系统的非功能性质量，如性能和可靠性）。

尚不存在的前提条件

自愈需要大多数组织尚缺乏的几个基础：

• 每次变更的清晰账本，以便智能体能够理解发生了什么。 • 一个具有身份控制和权限边界的智能体操作系统。 • 强大的通用缓解能力（回滚、功能开关），无需代码变更即可运作。 • 用智能体可评估的术语定义“健康”含义的适应度函数。 研讨会直言不讳：代码变更应该是事件修复的最后手段。通往自愈的道路要先经过更好的回滚、更好的功能开关和更好的可观测性，然后才是智能体重写生产代码。

隐性知识问题

资深工程师在事件响应中带来了数十年的模式匹配经验。他们记得某个特定的错误码实际上是更深层基础设施问题的症状。他们知道某个特定服务的CPU占用率高意味着要在做任何其他事情之前先检查数据库连接池。这些知识几乎从未被文档化。它存在于人们的头脑中，通过经验来应用。

要为智能体复制这些知识，组织需要构建研讨会所称的“智能体潜意识”：一个从多年事后分析和事件数据中构建的知识图谱，为智能体提供解读实时信号的历史上下文。一些组织已经在通过自动化事后分析起草来做这件事，但添加细微差别和上下文的人工步骤仍然必不可少。

事件指挥官问题
人类事件指挥官会质疑假设、反驳令人舒适的假说并维持态势感知。大语言模型倾向于正向强化和同意。构建有效的智能体事件指挥官需要解决这种行为不匹配。一个建议是：训练专门设计用于挑战主流假设的“愤怒智能体”。

智能体协调风险

多个智能体试图修复同一问题时，可能会产生反馈循环——一个智能体的修复触发另一个智能体的纠正，形成不断升级的循环。研讨会引用了一个真实案例：一个能访问代码检查工具（该工具强制执行500行文件限制）的智能体，通过将单行代码变长来响应，从技术上满足了规则但违反了规则背后的原则。当多个智能体对权衡做出不同的优先级决策时，系统会振荡而非收敛。

5. 人的方面：角色、技能与体验

AI并非在取代人。它在重新安排人们做什么，以及他们对所做之事的感受。

生产力/体验悖论

开发者体验传统上从三个维度来定义：心流状态、反馈循环和认知负荷。生产力和开发者体验数十年来一直紧密耦合；研讨会探讨了它们现在正在脱钩的证据。组织可以通过AI工具获得生产力提升，即使在开发者报告满意度更低、认知负荷更大、心流感降低的环境中。

这造成了一个真正的两难困境。如果组织可以在不投资于开发者体验的情况下获得更多产出，那么这项投资的商业理由就会减弱——除非开发者体验的定义本身也演进，以适应智能体监督工作的新现实。一位从业者提出了一个犀利的重新定义：停止称之为开发者体验，改称智能体体验。投资于帮助智能体良好运行的条件，钱包可能会更快地打开，而这些条件与帮助人类良好运行的条件重合度几乎完全吻合。

Staff工程师面临的压力

Staff工程师同时变得比以往更重要也更有压力。一家研究公司涵盖500家企业的数据显示，Staff工程师使用AI工具的频率低于初级工程师，但当他们使用时，每周节省的时间更多。他们更广泛的上下文和对系统架构更深的理解，使他们成为更有效的智能体监督者。

矛盾在于Staff工程师被要求做的事情与他们应该做的事情之间。许多人将不成比例的时间花在人际协调上，而非技术监督上。研讨会主张进行有意识的转变：Staff工程师应该成为摩擦消除者，识别并移除减缓人类和智能体工作的障碍。他们对“尸骨埋在哪里”的深入了解使他们独特地适合这个角色，但许多人在被告知多年没有预算实施他们推荐的改进后，已经产生了习得性无助。

初级开发者更有价值，而非更没价值

研讨会挑战了AI消除了对初级开发者需求的叙事。初级开发者比以往任何时候都更有利可图。AI工具帮助他们更快地度过尴尬的初期净负值阶段。他们是对未来生产力的看涨期权。而且他们比资深工程师更擅长使用AI工具，因为他们从未养成减缓采用的习惯和假设。

真正令人担忧的是在长达十年的招聘热潮期间成长起来的中级工程师，他们可能未曾培养出在新环境中蓬勃发展所需的基本功。这一群体按数量计构成了行业的主体，对他们进行再培训确实很困难。研讨会讨论了学徒制模式、轮岗计划和终身学习体系是否能弥合这一差距，但承认目前没有组织解决了这个问题。

教育信号
研讨会重点提到了滑铁卢大学的带薪实习项目作为模范：深厚的理论基础与2.5年的行业实习（六次四个月的轮岗）相结合。毕业生同时具备了AI工具无法替代的基础功底和实践判断力。多家公司报告，实习转正招聘渠道现在优于传统的应届毕业生招聘。

产品管理的未来

研讨会上没有人能定义产品经理在AI驱动的世界中将做什么。一些组织正在推动产品经理更接近技术工具，培训他们在Markdown和开发者环境中工作。另一些则认为角色会进一步分化，产品经理成为战略编排者，而开发者承担更多战术性的产品决策。

显而易见的是，AI正在暴露产品经理与开发者关系中已有的功能障碍，而非制造新的。知识碎片化、学科间的文化鸿沟和不明确的角色边界在AI之前就已存在。AI只是让忽视它们的代价更高了。研讨会强调工具作为“边界对象”的作用，允许不同角色以各自的方式工作，同时保持共享可见性。

6. 技术基础：语言、语义与操作系统

智能体时代的基础设施尚不存在。这些是正在组装的拼图。

面向智能体的编程语言

现存的每一种编程语言都是以人类作为主要用户来设计的。动态类型的存在是为了减少人类程序员的认知开销。强静态类型的存在是为了捕获人类错误。研讨会追问：一种为智能体生成代码而设计的语言会是什么样子？它是否也能更好地服务于人类？

小组就一个原则达成了共识：对AI有利的对人类也有利。使错误代码无法被表达的语言（通过强类型、受限的计算模型和形式化约束）帮助智能体产出正确的输出，也帮助人类验证它。反之，偏重表达力而非安全性的语言使智能体生成和人类评审都更困难。

一个更激进的可能性是，我们所知的源代码可能成为一种瞬态制品，按需生成且永不存储。研讨会在这一点上存在分歧。有人认为源代码将在十年内消失。也有人认为确定性验证需要一个稳定的制品来进行测试，而这个制品无论我们怎么称呼，本质上就是源代码。

语义层与知识图谱

数十年来未能获得主流采用的技术突然变得重要起来。语义层、知识图谱和领域本体正在被重新发现，作为需要理解业务领域的AI智能体的基础层。研讨会中有从业者正在大规模构建这些系统，报告称一家大型电信公司的整个领域本体可以用大约286个概念来捕获。这个数字让这项工作感觉是可实现的，而不是不可能地宏大。

实际价值在于遗留系统现代化。通过从现有系统构建概念数据模型并与领域专家进行验证，组织可以创建智能体自信地进行现代化改造所需的规格说明层。一个团队描述了使用大语言模型自动识别代码中的命令、事件、聚合和策略，实质上是自动生成事件风暴制品。然后由人类专家进行验证和纠正，将数周的发现研讨会压缩到几天。

智能体操作系统

研讨会探讨了智能体操作系统需要包含的内容：

• 智能体身份和权限管理。 • 记忆和上下文窗口管理。 • 一个工作账本，记录未来、当前和过去的工作，带有所需技能、验收标准、SLO和成本约束等属性。 • 通过智能体能力和合规要求图谱的治理路径。 一个核心洞察是：智能体不仅仅是它的角色设定、目标或当前上下文；它还包括它执行过的工作历史。虽然模型在智能体内部是可替换的（你可以用一个LLM替换另一个），但更换模型会从根本上改变智能体的行为，必须被追踪。工作账本被确立为这个新操作系统的核心基本单元，类似于金融区块链：可搜索、可审计，并使智能体能够发现和竞标工作。

7. 安全、治理与敏捷的未来

安全性危险地落后了

研讨会忧虑地指出，安全讨论环节的出席率很低，这反映了更广泛的行业模式。安全被当作以后再解决的事情，等技术运作正常和可靠之后。对于智能体而言，这种排序是危险的。

最生动的例子：授予智能体电子邮件访问权限就能实现密码重置和账户接管。开发工具的完整机器访问权限意味着智能体决定做的任何事情的完整机器访问权限。研讨会的建议很直接：平台工程应该通过让安全行为简单、不安全行为困难来推动安全默认设置。组织不应依赖个人开发者在配置智能体访问权限时做出安全意识的选择。

三个优先事项浮现出来：安全设计作为不可妥协的底线、跨行业联盟制定可互操作的智能体安全标准、以及能够匹配AI驱动攻击速度和复杂性的AI赋能防御机制。

敏捷在进化，而非消亡

研讨会强烈反驳了“敏捷已死”的叙事。正在发生的事情更加微妙。一些团队正在将冲刺节奏压缩到一周，使用AI自动化冲刺结束仪式，如演示、报告和状态摘要。另一些则重新发现了XP实践（结对编程、集成开发、持续集成），因为这些实践创造了智能体辅助开发所需的紧密反馈循环和共享理解。

敏捷面临的真正威胁是治理。采用AI工具并更快工作的团队仍然遭遇同样的审批流程、合规关卡和组织依赖。如果不在变革开发实践的同时改革治理，更快的团队只是更早地撞上同样的墙。研讨会强调在重新思考团队实践时应尽早让内部审计和治理职能参与进来，而不是将它们视为以后再绕过的障碍。

随着批量大小的增加，软件稳定性也在下降。用AI工具轻松产出大型变更集正在推动一些团队回到类似瀑布的模式，用大量、低频的发布取代小量、高频的发布。这是对DORA十年研究成果（较小批量与更高稳定性相关）的直接逆转。研讨会将此标记为需要行业关注的正在发生的退步。

8. 智能体群体：超越顺序思维

研讨会专门抽出时间讨论智能体群体协作（swarming），并浮现出挑战关于AI辅助工作应如何组织的传统假设的洞察。

有效群体协作的第一个障碍是思维上的，而非技术上的。受过顺序分解训练的工程师很难概念化并行的智能体工作。这种思维模式积极地阻碍了学习。在群体协作方面取得突破的从业者描述说，这种体验与他们在以往软件开发中遇到的任何事情都截然不同。仅仅是要求智能体明确地并行化工作并观察结果，就比任何理论框架教授的内容都多。

对于企业级用例，研讨会识别出一个重要模式：单个智能体的完美准确性不如集体向目标的收敛重要。一群单独来看不完美的智能体，如果系统架构引导收敛，就能产出有价值的成果。这是一个借鉴自分布式系统和生物群体智能的设计原则，被应用于AI智能体编排。

研讨会还指出，大多数企业级智能体编排看起来根本不像群体协作。更常见的模式是“循环巡逻工人”：智能体在持续循环中运行定义明确的ETL转换、数据质量检查和业务流程监控。换言之，就是数据可靠性和清洁度这些不那么光鲜的工作在后台永不停歇地运行。拥有强大、设计良好的API的组织，在群体协作和巡逻式智能体部署方面都明显优于没有的组织。

模型局限性
一些前沿模型存在结构性弱点，使其不太适合群体协作式场景。这正在影响评估的设计方式，预期是随着这些局限性被更好地理解，面向群体协作的架构将会改善。为智能体部署选择模型的组织应专门针对多智能体协调进行测试，而不仅仅是单智能体能力。

9. 开放性问题

研讨会浮现的问题多于答案。以下是那些让众人夜不能寐的问题。

关于工作与身份认同

我们如何帮助热爱编写代码的工程师在监督性工程工作中找到意义和满足感？通往中间循环的职业发展路径是什么？如果产品经理角色和开发者角色正在趋同，由此产生的角色叫什么？谁来拥有它？

关于组织设计

如果智能体使中层管理瓶颈更加可见，组织的回应是减少管理者、培养不同技能的管理者，还是一种根本不同的协调模式？当智能体可以跨越团队边界但治理结构不能时，你如何重新设计企业架构？

关于信任与验证

需要什么条件才能让组织完全停止评审AI生成的代码？是否存在一个世界，在其中测试套件和约束能提供足够的验证而无需人工检查？我们如何在根本上非确定性的系统中建立信任——在这种系统中，使用相同输入重新运行会产生不同的输出？

关于知识与理解

如果代码变化的速度超过人类理解的速度，我们是否需要一种维护组织知识的新模型？知识图谱和语义层能否真正替代多年在代码库中工作所积累的人类直觉？对于大多数组织尚未构建的“智能体潜意识”系统，合适的投入水平是多少？

关于速度与稳定性

我们当前是否处于一种退步中——AI赋能的生产力提升正在被更大批量导致的稳定性损失所抵消？开发速度是否需要放慢，因为决策的数量已经超出了人类评估能力？我们如何衡量认知债务随其累积的真实成本？

接下来会怎样

研讨会浮现出一个一致的模式：为纯人类软件开发构建的实践、工具和组织结构，正在AI辅助工作的重压下以可预见的方式断裂。替代方案正在形成，但尚未成熟。

已准备好进入更广泛行业对话的想法包括：监督性工程中间循环、风险分级作为新的核心工程纪律、TDD作为最强形式的提示工程，以及将开发者体验投资重新定义为智能体体验。对每项内容的详细探索将随后发布。

尚未回答的问题同样重要。如何帮助人们度过职业生涯中的身份认同转变；如何治理智能体运行速度快于人类决策速度的组织；如何在本质上非确定性的系统中建立信任。这些不是有技术解决方案的技术问题。它们是需要坦诚对话和协作的人类问题。我们致力于在未来数月为此做出贡献。

“研讨会没有产出一张路线图。它产出了一个共同的认识——地图正在被重绘，而最有资格绘制它的人，是那些愿意承认自己还有多少不知道的人。”

原文地址：
https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf