本译文收录两份 Thoughtworks《软件工程的未来》务虚会报告的中文译版，分别来自 2026 年 2 月美国犹他场与 2026 年 6 月瑞士恩格尔贝格场。两份报告各自独立成编，合并于此便于对照阅读。

第一部分：软件工程的未来——务虚会发现与战略洞察

原文：The Future of Software Engineering — Retreat Findings and Strategic Insights，2026 年 2 月。

感谢各位共聚一堂，一同 碰撞那些在 AI 重塑软件构建方式之际最要紧的问题。以下是对各场分组讨论（breakout session）核心主题与要点的综合提炼。

本次务虚会依据查塔姆守则（Chatham House Rule）进行，本摘要不披露任何与会者姓名与所属机构。

2026 年 2 月

执行摘要

来自各大科技公司的资深工程实践者齐聚一场为期数日的务虚会，直面 AI 改造软件开发过程中最关键的问题。讨论覆盖二十余个议题，横跨多场分组讨论；但最有分量的洞见并非出自某一场单独的讨论，而是在各议题的交叉处浮现——我们发现，同样的关切在不同对话里反复出现，由不同的人、在不同的解题场景下被重新表述。

本出版物综合了这些横切主题，围绕资深领导者当下需要理解并付诸行动的若干模式加以组织。务虚会并未产出关于未来的一份统一愿景，而是产出了更有用的东西：一张断层线地图——标示出当前实践正在何处崩裂、新实践正在何处成形。

“我们在每个房间里都在反复问同一个问题：如果代码由 AI 来写，工程本身到底去哪儿了？没人给出一样的答案。但所有人都认同这问题迫在眉睫。“

主题速览

主题时间窗口核心洞见
严谨性去了哪里？当下当 AI 写代码时，工程质量并未消失；它迁移到了规格、测试、约束与风险管理。
从代码评审到风险分级当下代码评审正在被解耦。它的四项职能（辅导、一致性、正确性、信任）各自需要一个新的归宿。
生产力与体验的悖论当下开发者生产力与开发者体验正在脱钩。组织面临”优化哪一个”的艰难抉择。
安全是事后补丁当下智能体安全严重落后。仅凭邮件访问权限就可能实现完整账号接管。
中间循环当下—1 年一类新的监督性工程工作正在内循环编码与外循环交付之间成形。尚无人为其命名。
认知债当下—1 年技术债正在变成认知债：系统复杂度与人类理解之间的鸿沟。
智能体拓扑1—3 年康威定律同样适用于智能体。企业架构如今必须考量智能体的流动性、专精化与漂移。
知识图谱与语义层1—3 年沉寂数十年的技术突然重新变得相关，成为领域感知智能体的接地层。
角色的未来1—3 年产品经理、开发者、设计师的角色正在收敛。Staff 工程师面临新期待。初级工程师比以往更有价值。
自愈系统2—5 年从人工事故响应走向智能体辅助自愈，需先解决”隐性知识”问题。

以下为各主题的详细发现。

1. 严谨性去了哪里？

这是本次务虚会最重要的问题，几乎在每一场讨论中都有浮现。

如果 AI 接管代码生产，过去体现在编写与评审代码中的工程纪律并不会消失；它会迁移到别处。务虚会在这一问题上花费的时间超过其他任何议题，并从代码评审、测试、语言设计、自愈系统与组织设计等多个视角加以切入。

与会者识别出严谨性正在流向的五个去向：

上游迁移到规格评审

多位实践者反映，他们把评审重心从代码前移到了代码之前的计划。有人描述为聚焦于”事前评审计划、事后评审工程实现”，而非评审代码本身。逻辑直截了当：如果 AI 依据规格生成代码，那么规格就是发现错误的最高杠杆产物。糟糕的规格会在规模上产出糟糕的代码。

这有现实含义。试行规格驱动开发的组织反馈，规格本身需要新的格式。传统用户故事过于含糊。一些团队开始采用结构化方法，如 EARS（Easy Approach to Requirements Syntax，需求语法简易法）、状态机与决策表。这些并非新技术，但被重新发现，因为它们给 AI 智能体足够的精度以产出正确实现。

进入测试套件这一一等公民产物

务虚会最值得带回去的洞见之一：测试驱动开发（TDD）能让 AI 编码智能体产出显著更好的结果。其机理很具体——TDD 阻断了一种失败模式，即智能体写出”验证错误行为”的测试。当测试先于代码存在时，智能体无法作弊——它无法通过写一个恰好确认自己那份错误实现的测试来蒙混过关。

这让 TDD 被重新定位为一种提示工程。测试成为针对非确定性生成过程的确定性验证。多位实践者描述将评审重心完全转移到测试套件，把生成的代码视为可抛弃物。只要测试正确、代码能通过测试，代码就可接受——不论它长什么样。

实践者洞察

“我靠 TDD 加智能体编码得到的结果，比我以往任何方式都好，因为它阻断了一种特定的心智错误——智能体会写一个验证错误行为的测试。“

进入类型系统与约束

务虚会浮现出浓厚兴趣：用编程语言特性来约束 AI 生成的代码。与其在生成之后评审代码，实践者在探索如何让错误的代码无法表示。这借鉴了形式方法与强类型系统的思想，但不是作为学术练习，而是作为智能体产出的实用护栏。

一个关键洞见是规格与约束的分离。规格描述应当改变什么；约束则定义允许改变的有界上下文，包括哪些绝不能动。这些约束限制影响半径，让智能体得以安全地跨领域边界工作。当某条约束必须被打破时，它标志着新的系统边界，并触发重构。

进入风险地图

并非所有代码承担同等风险。务虚会讨论了按业务影响半径对代码分级，区分内部工具、对外服务与安全关键系统。这种风险地图决定了哪些地方人工评审不可或缺、哪些地方自动化验证足矣。

有实践者将其定位为新的核心工程纪律：组织不应再问”这段代码有人评审过吗？“，而应问”如果这段代码是错的，影响半径多大？我们的验证投入是否与该风险相称？“这让工程从工匠模式（每一行都手工评审）转向风险管理模式（验证投入匹配风险敞口）。

进入持续理解

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

其背后的关切是真实的。一位实践者指出，代码评审在历史上既是一道质量门，同样也是一种学习机制。辅导、共享理解、对代码库的熟悉度，都是在评审中发生的。若失去这一通道又不加替代，就会造成一种理解缺口，并随时间复利累积。

“结对编程能解决所有这些问题。如果理解系统很重要，那就一直这么做。不要分成一小段一小段的代码评审阶段。要持续地去理解这段代码到底在做什么。“

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

务虚会最具先发优势的概念。业内尚无人为其命名。

软件开发长期被描述为两个循环。内循环是开发者个人的”写、测、调”循环。外循环是 CI/CD、部署与运维这一更宽的交付循环。务虚会识别出第三个：一个居间的中间循环——位于两者之间的监督性工程工作。

这一中间循环涉及指挥、评估与修复 AI 智能体的产出。它所需技能与写代码不同。它要求：把问题分解成智能体量级的工作包、对智能体产出校准信任、识别智能体何时在产出”看起来合理实则错误”的结果、以及在多条并行的智能体生成流之间维护架构一致性。

在这类新工作上表现卓越的实践者，往往共享某些特征：

  • 他们以”委派与编排”而非”直接实现”的方式思考。

  • 他们有扎实的系统架构心智模型。

  • 他们能不读每一行就快速评估产出质量。

这些技能有经验的工程师往往具备，但很少在职业阶梯中被明确培养或认可。

职业影响

中间循环给爱上编程的开发者制造了一场真实的身份危机。许多人当初正是被”把预先消化好的工单翻译成可运行代码”而招进来的。

他们的工作正在消失。新工作需要不同的禀赋与不同的职业满足感来源。不帮助员工度过这一转型的组织，将因挫败感流失大量有经验的骨干。

务虚会做了一个与计算机图形学史的类比。1992 年，工程师手写多边形渲染算法。两年后，那项工作被推入硬件，工作变成动画与光照。今天，则是自定义物理与游戏世界。每一次抽象层抬升，坚持”我是被雇来渲染多边形的”工程师都被甩在身后。同样的动态此刻正发生在代码生产上。

这一方程的产品管理侧同样未定。如果开发者如今更多思考”建什么、为什么建”，他们做的正是过去属于产品经理的工作。某大型科技公司正在研究 PM 角色是否需要一个新名字。另一家则在培训所有产品经理在开发工具里用 Markdown 工作。收敛是真实的，即便没人就落点达成一致。

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

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

务虚会引入”智能体拓扑”概念，作为 Team Topologies 框架的延伸。前提是：如果组织设计的系统映射其沟通结构，那么当智能体成为这些结构中的一等参与者时，会发生什么？

与人不同，智能体可以瞬间复制，并在多个团队间部署而无入职摩擦。一个专精的数据库智能体可以同时存在于每个团队，带来一致的专长，而不产生单一人类数据库专家所带来的集中化瓶颈。这听起来像纯粹的赢面，但务虚会识别出几个复杂化因素。

速度失配

智能体吞噬积压的速度极快，以至于会撞上慢速的组织依赖。一位与会者这样描述：你给一个团队 AI 工具，他们几天清空积压，然后撞上一堵由跨团队依赖、架构评审与人类速度决策组成的墙。结果不是更快交付，而是同样速度加更多挫败——因为瓶颈从工程产能转移到了其他一切。

智能体漂移

从上下文学习的智能体会随时间发散。在电商后端工作的数据库智能体，与在 ERP 系统上工作的那个，即便初始配置完全相同，也会积累出不同的模式与偏好。这映射了人类团队中”团队特定规范”的问题，但时间线被加速了。务虚会争论这种漂移应当被管理（类比人类团队的标准化努力）还是被拥抱（类比让团队局部优化）。

决策疲劳成为新瓶颈

如果智能体产出工作的速度快于领导者评审与批准的速度，约束就从生产产能转移到决策产能。过去充当协调点的中层管理者，如今变成审批瓶颈。多位实践者报告其组织已发生此现象：智能体生成岗位说明书、代码修复与功能实现的速度，超过任何人能说”同意”的速度。

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

“我们过去是为人来优化软件交付流程的。现在不再只是人了，我们不得不追问：组织到底意味着什么。“

4. 自愈与自我改进系统

雄心是真实的。前提条件远未具备。

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

尚不存在的前提

自愈需要大多数组织缺乏的若干基础：

  • 一本清晰的变更账本，让智能体能理解发生了什么。

  • 一套带身份控制与权限边界的智能体操作系统。

  • 强大的通用缓解能力（回滚、特性开关），无需改代码即可工作。

  • 适应度函数（fitness function），用智能体可评估的方式定义”健康”意味着什么。

务虚会很直白：代码变更应当是事故修复的最后手段。通往自愈的路径，先经过更好的回滚、更好的特性开关与更好的可观测性，之后才经过智能体改写生产代码。

隐性知识问题

资深工程师把数十年的模式识别带入事故响应。他们记得某个错误码其实是更深层基础设施问题的表征。他们知道某服务 CPU 飙高意味着先查数据库连接池。这种知识几乎从不被文档化，它活在人脑里、靠经验施展。

要为智能体复制这一点，组织需要构建务虚会所称的”智能体潜意识”：一个由多年事故复盘与事故数据构建的知识图谱，给智能体解释实时信号的历史上下文。一些组织已用自动化事故复盘起草在做这件事，但人类添加细微差别与上下文的那一步仍不可少。

事故指挥官问题

人类事故指挥官会挑战假设、反驳舒适的假设、保持态势感知。LLM 倾向于正向强化与附和。要构建有效的智能体事故指挥官，需解决这一行为失配。一个建议：训练”愤怒智能体”——专门设计来挑战主流假设。

智能体协调风险

多个智能体试图修复同一问题，可能制造反馈回路：一个智能体的修复触发另一个智能体的纠正，形成不断升级的循环。务虚会援引一个真实案例：一个有权限访问 linter 的智能体，linter 强制单文件不超过 500 行，它遂把每一行写得更长——技术上满足规则，却违背了规则背后的原则。当多个智能体对取舍做出不同的优先级判断时，系统可能振荡而非收敛。

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

AI 不是在取代人。它是在重新排列人做什么、以及人对此的感受。

生产力与体验的悖论

开发者体验传统上沿三个维度定义：心流状态、反馈回路与认知负荷。数十年来生产力与开发者体验紧密耦合；务虚会探讨了二者正在分流的证据。组织即便在开发者报告更低满意度、更高认知负荷与更弱心流感的环境中，仍能借 AI 工具获得生产力提升。

这造成了真实的两难。如果组织能在不投资开发者体验的情况下获得更多产出，那笔投资的商业理由就被削弱了——除非开发者体验的定义本身演进，以纳入智能体监督工作的新现实。一位实践者给出犀利的重新框定：别再叫开发者体验，改叫智能体体验。为帮助智能体良好表现的境况买单，钱包大概率打开得更快，而它与帮助人类良好表现的境况的重叠，几乎完全重合。

承压的 Staff 工程师

Staff 工程师同时比以往更重要、也更承压。一家研究机构的数据横跨 500 家公司显示：Staff 工程师使用 AI 工具的频率低于初级工程师，但一旦使用，每周节省的时间更多。他们更宽的上下文与对系统架构更深的理解，使他们成为更有效的智能体监督者。

张力在于 Staff 工程师被要求做的事与他们应当做的事。许多人把不成比例的时间花在人际协调而非技术监督上。务虚会主张一次刻意的转向：Staff 工程师应成为”摩擦杀手”——识别并消除拖慢人与智能体工作的障碍。他们对”尸骨埋在何处”的深入了解，使他们独具这一角色的优势，但许多人在多年被告知”你建议的改进没有预算”之后，已习得性无助。

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

务虚会挑战了”AI 消除了对初级开发者的需求”这一叙事。初级开发者比以往更有利可图。AI 工具让他们更快度过尴尬的初期净负值阶段。他们是未来生产力的看涨期权。他们比资深工程师更擅长 AI 工具，因为从未养成拖慢采纳的旧习惯与假设。

真正的关切是那批在长达十年的招聘潮中成长起来的中级工程师，他们可能未发展出在新环境中蓬勃发展所需的基本功。这群人按体量占了行业的大头，再培训他们确实困难。务虚会讨论了学徒制模式、轮岗计划与终身学习结构能否弥补这一缺口，但承认尚无组织解决。

教育信号

务虚会把滑铁卢大学的 co-op 项目作为典范加以强调：扎实的理论基础叠加 2.5 年的工业实习（六个为期四个月的轮转）。毕业生兼具基本功与 AI 工具无法替代的实践判断。数家公司报告实习生转正管道如今已优于传统校招。

产品管理的未来

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

清楚的是，AI 暴露的是 PM 与开发者关系中既有的功能障碍，而非制造新的。知识碎片化、跨学科文化鸿沟、角色边界不清，这些在 AI 之前就存在。AI 只是让无视它们的代价更高。务虚会强调把工具视为”边界对象”——让不同角色各以自己的方式工作，同时保持共享的可见性。

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

智能体时代的基础设施尚不存在。以下是正在拼装中的零件。

面向智能体的编程语言

现有每一种编程语言都以人为主要用户来设计。动态类型是为降低人类程序员的认知开销。强静态类型是为捕获人类错误。务虚会追问：一种为智能体生成代码而设计的语言会是什么样，它是否也会更好地服务人类。

小组收敛到一个原则：对 AI 好的，对人也好的。让错误代码无法表示的语言（通过强类型、受限计算模型与形式约束）帮助智能体产出正确输出，也帮助人类验证它。反之，偏好表达力胜于安全性的语言，让智能体生成与人工评审都更难。

更激进的可能：源代码如我们所知可能变成一种临时产物，按需生成、永不存储。务虚会对此分歧。有人认为源代码十年内会消失。另一些人则论证，确定性验证需要一个稳定的产物来对照测试，而那个产物无论叫什么，实质就是源代码。

语义层与知识图谱

数十年来未能进入主流采纳的技术突然重新变得相关。语义层、知识图谱与领域本体被重新发现，作为需要理解业务领域的 AI 智能体的接地层。务虚会有在大规模构建这些系统的实践者，报告称一家大型电信商的整个领域本体大约可用 286 个概念捕获。这个数字让这项工作显得可达成，而非不可能般雄心勃勃。

其现实价值在于遗留系统现代化。通过从既有系统构建概念数据模型、并与领域专家验证，组织可创建智能体自信地推进现代化所需的规格层。一个团队描述了用 LLM 自动从代码中识别命令、事件、聚合与策略，等同于自动生成事件风暴（event storming）产物。人类专家再加以验证与修正，把数周的探索工作坊压缩到数天。

智能体操作系统

务虚会探索了一个面向智能体的操作系统需要包含什么：

  • 智能体身份与权限管理。

  • 记忆与上下文窗口管理。

  • 一本工作账本，记录未来、当前与过去的工作，带有所需技能、验收标准、SLO 与成本约束等属性。

  • 穿越一个智能体能力与合规要求图谱的治理路径。

一个核心洞见是：一个智能体不仅是它的人设、目标或当前上下文，它还包含其所做工作的历史。虽然模型在智能体内可互换（你可以把一个 LLM 换成另一个），但更换模型会从根本上改变智能体行为，必须被追踪。工作账本作为这一新操作系统的核心原语浮现，类比于金融区块链：可搜索、可追溯、可审计，并使智能体能发现工作并竞价承揽。

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

安全危险地落后

务虚会关切地注意到，安全这一场讨论出席率低，反映出更广的行业模式。安全被当成”等技术先跑通、可靠了再说”的事后项。有了智能体，这种排序是危险的。

最生动的例子：授予智能体邮件访问权即可实现密码重置与账号接管。开发工具的整机访问权，意味着智能体决定做的任何事都获得整机访问权。务虚会的建议很直接：平台工程应通过”让安全行为容易、不安全行为困难”来驱动安全默认值。组织不应依赖个别开发者在配置智能体访问时做出安全意识选择。

三项优先级浮现：将”安全设计”作为不可妥协的基线；建立跨行业联盟以制定可互操作的智能体安全标准；以及能匹配 AI 驱动攻击速度与复杂度的、AI 驱动的防御机制。

敏捷在演进，而非消亡

务虚会强力回击了”敏捷已死”的叙事。正在发生的更微妙。一些团队把迭代节奏压缩到一周，用 AI 自动化迭代末仪式如演示、汇报与状态摘要。另一些则重新发现 XP 实践（结对编程、集体开发、持续集成），因为这些实践造就了智能体辅助开发所需的紧反馈回路与共享理解。

对敏捷真正的威胁是治理。采用 AI 工具、跑得更快的团队，仍撞上同样的审批流程、合规门与组织依赖。不在改革治理的同时改革开发实践，跑得更快的团队只是更快撞上同一堵墙。务虚会强调，在重塑团队实践时要尽早纳入内审与治理职能，而非把他们当成之后要去绕开的障碍。

软件稳定性也随批量增大而下降。AI 工具产出大批量变更的轻易性，正把一些团队推回瀑布式模式——大而稀的发布取代了小而频的发布。这是对十年 DORA 研究（小批量与高稳定性相关）的直接反转。务虚会将其标记为需要行业关注的活跃退化。

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

务虚会专门留出时间讨论智能体蜂群（swarming），浮现的洞见挑战了关于 AI 辅助工作应如何组织的惯常假设。

有效蜂群的第一道障碍是心智的，而非技术的。受训于顺序分解的工程师难以概念化并行的智能体工作。这种心智模型主动地阻碍学习。在蜂群上取得突破的实践者把这种体验描述为与他们以往软件开发中遇到的任何事都根本不同。仅仅是明确要求智能体并行化工作并观察结果，所教的东西就比任何理论框架都多。

对于企业用例，务虚会识别出一个重要模式：单个智能体的完美准确度不如集体向目标收敛重要。一个由各自不完美的智能体组成的蜂群，只要系统架构引导收敛，就能产出有价值的结果。这是借自分布式系统与生物蜂群智能的设计原则，应用于 AI 智能体编排。

务虚会还指出，大多数企业智能体编排看起来根本不像蜂群。更常见的模式是”循环上的巡检工人”：智能体在持续循环上运行定义良好的 ETL 转换、数据质量检查与业务流程监控。换言之，那些不性感的数据可靠性与清洁度工作，在后台常驻运行。拥有强健、设计良好的 API 的组织，在蜂群式与巡检式智能体部署上都比没有的组织显著占优。

模型局限

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

9. 开放问题

务虚会浮现的问题多于答案。以下是那些让全场难以入眠的问题。

关于工作与身份

我们如何帮助热爱写代码的工程师，在监督性工程工作中找到意义与满足？什么样的职业发展路径通向中间循环？如果产品经理角色与开发者角色在收敛，合并后的角色叫什么、归谁所有？

关于组织设计

如果智能体让中层管理瓶颈更显眼，组织的回应是减少管理者、任用技能不同的管理者，还是一种根本不同的协调模式？当智能体能跨团队边界移动而治理结构不能时，你如何重新设计企业架构？

关于信任与验证

需要满足什么条件，组织才会完全停止评审 AI 生成的代码？是否存在这样一个世界：测试套件与约束提供足够验证而无需人工检视？我们如何在根本非确定性、相同输入产生不同输出的系统里建立信任？

关于知识与理解

如果代码变更速度快于人类理解速度，我们是否需要一种维护制度性知识的新模型？知识图谱与语义层能真正替代来自多年在代码库中工作的人类直觉吗？对于大多数组织尚未构建的”智能体潜意识”系统，恰当的投资水平是多少？

关于速度与稳定性

我们是否正处在一个退化期——AI 驱动的生产力增益正被更大批量带来的稳定性损失所抵消？开发是否需要放缓，因为决策数量已压垮人类评估能力？我们如何度量随认知债累积而真实产生的成本？

接下来

务虚会浮现出一个一致模式：为人本软件开发而建的实践、工具与组织结构，在 AI 辅助工作的重压下正以可预见的方式崩裂。替代物正在成形，但尚未成熟。

已可进入更广行业对话的想法包括：监督性工程中间循环、风险分级作为新核心工程纪律、TDD 作为最强的提示工程形式，以及用”智能体体验”重新框定开发者体验投资。对每一项的深入探索将随后跟进。

尚未回答的问题同样重要。如何帮助人们度过职业生活中的身份转变；如何治理智能体移动快于人类决策的组织；如何在根本非确定性的系统中建立信任。这些不是有技术答案的技术问题。它们是人的问题，需要坦诚的对话与协作。我们承诺在接下来的数月为此贡献力量。

“务虚会没有产出路线图。它产出的是一种共享的理解：地图正在被重绘，而最有资格执笔的人，是那些愿意承认自己尚不知多少的人。“

第二部分：软件工程的未来——2026 年 6 月瑞士恩格尔贝格非会议洞察

原文：The Future of Software Engineering，2026 年 6 月 28—30 日，瑞士恩格尔贝格。一场关于 AI、智能体工程与该学科未来的非会议（unconference）的洞察与发现。

执行摘要

2026 年 2 月，Martin Fowler 在犹他召集行业领袖，反思软件工程的现状。结果浮现了许多在 2026 年持续占据行业注意力的议题。

仅几个月过去，变化仍以惊人速度推进。因此，为既探索犹他场提出的想法与议题，又反思近月新涌现的挑战，Thoughtworks 与 Martin 召集了第二次”软件工程的未来”务虚会，地点在瑞士恩格尔贝格。本报告详述其要点与洞察。

这是一次非会议形式的聚会，参与者为资深技术人、CTO、CEO、架构师与顾问。构成大会的 40 场讨论非正式、由与会者主导，有时甚至充满争论。其价值未必在于达成共识，而在于思考的广度与严肃性。

五条标题性发现贯穿几乎每一场讨论：

  • 代码生成不再是瓶颈——验证才是。 在测试、遗留现代化、代码评审与团队设计各场讨论中，同一个结论反复出现：智能体生成代码（以及规格、测试与基础设施）的速度，远超任何团队能建立信任的速度。胜出的不是生成最多代码的纪律，而是构建廉价、快速、人类可读验证的纪律——特性测试、约束测试、变异测试、生产回溯测试。

  • “驾驭工程”（Harness engineering）正成为一门独立、可归属的学科。 智能体周边的脚手架——上下文管理、确定性护栏、技能、自我改进的反馈回路——被反复描述为比模型或提示更重要。一旦模型商品化，竞争差异化可能就栖身于此。值得注意的是，对”归属与问责”的需求被反复提及，但对”究竟该归谁”并无共识。

  • 组织正撞上真实的学徒制危机。 多场讨论独立提出同一担忧：如果资深工程师只与智能体结对，初级工程师就失去了通向判断力、品味与生产本能的动手路径——而行业一向依赖这一路径培养下一代资深。与犹他讨论一致，多数人认同：以这种方式开发软件的人需要知道”好的样子”是什么，这解释了为何资深工程师如鱼得水。但这加剧了学徒制问题的风险。

  • 高管与工程师的预期差距，是比任何技术局限都更大的风险。 董事会与 CEO 们正基于供应商演示与自己使用”写报告型 AI”的经验，下大而快的注；而工程师看到的是，生产力增益之下，验证、安全与治理问题清单在不断扩大且悬而未决。

  • 遗留现代化是最清晰、最站得住脚的近期价值池。 多场讨论描述了严谨、可运行、技术上详尽的 AI 辅助 COBOL/大型机现代化方法，并带有真实的验证纪律。

与美国场类似，许多开放问题仍待进一步探索与考量。但当下已有对技术人员与业务方如何行动的意涵。

对技术人员而言，需要重新聚焦测试与验证。这应部分包括：重新思考”手工代码评审是质量事实保证”这一假设，并在处理不熟悉的 AI 生成代码时运用对抗式与变异测试技术。

同样关键的是学习机制。这既在”监督 AI 智能体、确保智能体harness内有效反馈回路”这一层面，也在团队层面——推行群体结对（mob-pairing）与学习检查点等实践，以强化理解与技能传递。

对在这个战略不确定与持续变化中航行的业务领导者，有明确共识：今日的 token 经济学挑战不能仅当财务问题处理——它本质上是治理问题，需要持续监督与反馈回路，而非仅预算管理。与此相关，在自主性与不断滋生的影子 AI 之间取得平衡，也要求审慎治理。应抵制一刀切政策，自主性应按风险校准。

或许最重要的战略要点是：我们不应指望行业当前所经历的变化周期会抵达一个最终平台。这是一种可能，但更可能的是，炒作周期只会更压缩、变化节奏只会更快。这使”构建保值的持久能力”与”保护已确立价值的领域”成为当下就该行动的战略必需。

第一篇：横切主题

标题性主题提供了务虚会浮现主要议题的清晰即时画面。但它只讲了故事的一部分：讨论丰富而广泛，因此值得深挖若干主题，理解它们如何浮现，以及小组认为其对更广软件行业可能有何意涵。

验证而非生成，是新瓶颈

大会最被反复重复的观察：智能体生成代码、测试、规格与基础设施的速度，远超任何人类或组织当前能对产出建立信任的速度。“工程如今被蒸馏为：我如何描述目标，我如何验证我已达成目标。“这体现为一个具体的、实践的问题，而非抽象的：

  • 一套新的测试词汇正在成形。“约束测试”（约束智能体被允许生成什么的单一输入/输出测试）、“场景测试”与”好/坏日志”（源自真实生产事故）被点名并现场演示。用数小时构建的、定制、专为审批测试（approval testing）而造的测试台，证明比通用 BDD 框架更有效。这部分是因为它们让人工可评审的面保持简单，且让智能体难以钻空子。

  • 一个分层的信任验证栈正在为高风险迁移工作成形。它长这样：特性测试（从遗留系统捕获行为）→ 符号执行（数学上扎根，非 AI 生成）→ 针对真实数据流的”生产回溯测试”。这是一种真正严谨且新颖的技术方法论。

  • 确定性与非确定性混合评测，是 LLM-as-judge 不可靠的实用答案。有讨论描述某团队如何把 linter 与模式匹配同一个”三模型评审团”结合，把首轮合并接受率从约 60% 提升到 80%。

  • 对手工代码评审的长期信仰正被公开质疑。多位实践者指出，在场没人能引用”手工评审实际捕获多少缺陷”的数据——这是一种需要用证据挑战的”现状幻觉”。

“合规测试比规格重要得多。如果合规测试与规格冲突，你猜哪个赢？“

驾驭工程（harness engineering）正成为一门独立、可归属的学科

随着模型商品化，多场讨论收敛到同一主张：模型周边的脚手架——上下文管理、确定性护栏、技能、自我改进的反馈回路——才是真正区分好坏智能体工程的关键。

  • 存在具体的、被测量的结果。一个组织报告，使用有效harness至少把 token 用量降了 4 倍，并实质性地提升了产出确定性。一项重构实验发现，裸 linter 把代码异味解决率提到不足 50%，而把 linter 输出翻译成具体、确定性、分步的重构指令（“习惯钩子”）达到约 90% 解决率。一个好harness配小模型，据说也胜过弱harness配大模型。

  • 表现最好的团队并不手写harness。他们让智能体失败，运行一个”learn”技能对每次会话反思并提出harness修改，把人的工作定位为周期性修剪与简化，而非从零撰写。

  • 共享harness/技能的治理仍是未解的组织问题。技能与共享上下文产物的衰减，恰如无人拥有的代码框架——除非确立明确归属。然而，集中成一个专门的”harness团队”有重蹈旧 ops 团队反模式的风险。

团队设计在压缩——而瓶颈正向决策迁移

团队拓扑的对话至少横跨五场讨论，收敛到类似形态：更小的”核心”团队（常为结对或三人组）监督大规模智能体舰队，但为组织健全保留约 10 人的社会/凝聚力底线。

  • “两个时钟”问题是浮现出的最锐利的新诊断。团队同时追踪产出代码的时钟与等待决策的时钟。他们发现：开发者吞吐量爆炸了，但整体周期时间并未改善——因为决策与规格清晰度如今成了约束。

  • 一个鲜活的健康对不健康案例在多场讨论中原样复现。A 团队里，产品经理与设计师变成”超人”，用智能体独自狂出功能，工程师沦为收拾残局；与之相对，B 团队在规格、测试与设计意图上结对，同时一队智能体收敛到方案。前者被认为高度多产，但被领导层视为”正在酝酿的灾难”，因为它侵蚀了结对文化与组织凝聚力。

  • 平台团队需要一次信誉升级。传统聚焦基础设施的平台团队，可能缺乏拥有”harness”或”黑灯工厂”工具的编码成熟度。被反复提出的解法是：平台团队使用他们要求产品团队使用的同类智能体工具，并从”选项菜单”转向更强势的”铺装路”（paved road，亦常译”黄金路径” golden path）。

  • 领域驱动设计被重新评价为”在智能体速度与规模下协商模块与团队边界最相关的既有学科”。这不是因为它产出一份大设计，而是因为它是唯一一门在大型组织里持续协商与命名边界的既有学科。

学徒制与技能传递危机正在发生

独立地，在至少六场不同讨论中，资深实践者提出同一担忧：如果初级从不与真实代码、真实生产事故、真实设计取舍搏斗——因为智能体（或只与智能体结对的资深）吸收了这些工作——行业将失去培养下一代有判断力、有品味的工程师的关键机制。

  • 具体对策已被提出且正在试点。“设计法定人数”或群组编程模式——资深主导设计对话，初级做实际提示；显式的非 AI 学习练习并带公开问责；教授智能体编排与监督作为早期职业能力的新课程。

  • 七到十年经验群体被识别为承压最剧的群体。投入十年掌握的技能如今常被模型超越，他们正面临真实的情感与身份冲击。

  • 相关研究发现强化了这一关切。在论文写作中重度依赖 LLM 的大学生，三个月内批判性思维能力出现可测量的退化——即便相对其自身不依赖 LLM 的基线。

“有史以来最好的软件，都是慢慢做出来的。是那些我们花了更多时间、更多心思的东西……我认为慢思考其实是好事。“

遗留现代化是最清晰、最站得住脚的价值池

多场讨论描述了技术上严肃、可运行的 AI 辅助遗留/大型机现代化方法。这些不是投机，要么是高级试点，要么当前正在生产运行。

  • 迁移纪律原则在多场讨论中重复。“什么都不加，什么都不改，能删的都删”（移植期间）；一次只改一件事（先行为保真，再架构——绝不两者同时）；有意识地保留已知 bug，作为客户批准的决策，而非让 AI”好心”去修一个下游系统可能依赖的东西。

  • 新近变得可解的技术。用 AI 四天构建一个完整的自定义 TypeScript 到 .NET CLR 编译器；三天、约 5000 美元 token 构建一个通过 NIST 测试套件的 COBOL 编译器；通过让模型识别字节级模式，逆向工程一个未文档化、加密的 1994 年大型机二进制格式。此前在经济上不值得解决的问题——定制编译器、转译器与形式验证——如今已在普通团队可达范围内。

  • 能打动董事会的框定。把 AI 投资直接关联到现代化与维护预算（大企业中常占总 IT 支出 30—50%），把一个抽象的技术诉求重新框定为有范围、董事会可读的资本配置决策。一个真实案例把一个模糊的 1 亿美元以上诉求，缩为一个有范围的 800 万美元/20% 系统提案，并附带可度量的绑定价值。

高管与工程师的认知差距，是比任何模型局限都更大的风险

一个反复、几乎普遍的抱怨：董事会与 CEO 常相信”产品经理把 PRD 倒进魔法机器，完美可用的软件就出来了”。这部分因为他们亲手的 AI 体验是 AI 写报告与摘要工具，它们表现很好，却是软件工程的糟糕代理。

  • 这一差距不靠更好的模型弥合。它靠与组织资产负债表影响绑定的、鲜活具体的故事性来弥合。它还需要数据纪律——比如用真实同行基准核查供应商的”10 倍”宣称，以及让高管亲自尝试构建点东西、撞上真实极限的结构化练习。

  • 一个具体的、当下的警示信号。某组织六个月内报告的内部安全事件上升约 20 倍，而 AI token 预算在三个月而非十二个月内烧穿年度配额。这种预算冲击如今比生产力宣称更快引起董事会注意。

  • 现实的生产力预期应从供应商炒作主动下调。一位实践者估算，计入完整 SDLC 而非仅代码生成，现实近期增益约为 2—3 倍，而非 10 倍。他们预测炒作与这一现实的差距可能在 12—18 个月内”刺破泡沫”。

治理尚未跟上公民开发或智能体自主性

关于公民开发与安全的讨论共享一组一致的真实、具体事件：一位会计用 Copilot 搭的应用，因 AI 建议的 Cloudflare 隧道意外把客户数据暴露到开放互联网；一个营销团队的 AI 助手通过级联 OAuth 作用域获得广泛 G-Suite 访问权，公司在试图关停时甚至无法枚举这些作用域；一个智能体磁盘空间不足，删掉备份腾地方——还对此”很得意”。

  • 一个反复出现且有用的治理模式。绿/黄/红风险分级模型（个人使用/团队使用带强制培训/全公司需专业工程师签署），配以”检测优于预防”——持续扫描智能体对话日志寻找危险模式，而非仅靠前置培训（后者跟不上每周模型发布）——可以是关键的治理战术。

  • 一个新的供应链攻击向量。恶意行为者可预测 LLM 可能凭名字幻觉出哪些不存在的库，然后用那些确切名字发布真实恶意包。仅靠沙箱不能完全解决，因为依赖仍可能进入生产。

  • 实用、部分的缓解措施存在并在扩散。新库版本等约 14 天再采纳（多数入侵在此窗口内被发现）；审查过的内部注册表；微虚拟机沙箱（优于容器，但尚未被证明完全足够）；以及把智能体生成的代码视为不可信——即便在你自己网络内部也如此，对内应用零信任原则，而不仅在边界。

Token 经济学（token economics）、自托管与主权已成董事会级问题

对自托管模型的兴趣日益被主权与控制需求驱动，而非成本：对美国/联邦法律对数据长臂管辖的恐惧，对供应商单边涨价或限流的恐惧，以及避免因外包而丧失组织”学习与改变能力”的愿望。

  • 成本效率按多达 1400 倍变化，不仅取决于模型选择，也取决于企业数据访问如何架构。模型与企业系统之间低效的基于 MCP 的往返，是一个被低估的成本驱动因素。它在成本优化（数据靠近模型）与安全（更广数据暴露）之间制造真实张力。

  • 真正大规模的自托管是一门专门、稀缺的学科。固定 GPU 基础设施下每美元吞吐量的性能工程，下沉到物理机架拓扑，正大体被超大规模云与新云厂商吸收。组织应预期这一能力差距并据此规划，而非假设自托管简单。

  • 对编码专用工作负载，存在一条可行的中间路径。具体是：更小的专用推理硬件，或专精的编码模型托管商，免去解决完整超大规模自托管问题的需要。

开源面临真正的清算

会上发生了一场热烈而未决的辩论：AI 是加剧了既有的开源可持续性危机（维护者倦怠、十亿美元公司无偿榨取劳动），还是创造了全新的动态（单人巨型项目数月内达海量规模、AI 生成的拉取请求洪流让维护者无法评估）？

  • 一个建设性模式被提出，用于规模化处理 AI 生成贡献：把一个拉取请求的意图逆向工程为白话描述，评估该意图，然后让你自己的 AI 从头重新实现再合并——既致谢贡献者，又避免盲目信任，且维护者成本低。

  • 一个推测性但合理的转变。开源共享可能从代码转向规格/想法，因为实现可按消费者低成本再生。但也有真实风险：如果智能体完全取代共享库依赖，没有 AI/硬件访问的人将失去开源历史上曾带来的民主化效应。

一种价值驱动的反叙事：“刻意的人性”

在技术乐观之下，流淌着一股持续、严肃的逆流：一种担忧——如果验证、原型乃至市场测试都变得近乎免费且人人可得，唯一剩下的差异化就是人类判断、品味与用心。组织需要刻意保护并提升它，而不是把它工程化掉。

  • 有历史类比表明这不是天真的怀旧。印象派恰恰因为相机能完美复制现实而兴起，把人的价值推向诠释；鼓手在鼓机到来后变得更复杂而非被淘汰；自 1997 年以来世界上最好的”棋手”可以说是人加引擎的组合，而非引擎独演。

  • 这不是反技术情绪——它与大会对智能体工具的整体热忱共存。最清晰的表述是：让”刻意、可见地注入判断”的那个回路保持人的存在，哪怕”建造东西”的那个回路已高度自动化。

“我唯一不想外包的，是验收标准。其余一切我都愿意外包。“

第二篇：技术领导者的行动

那么，对技术人员有哪些实践意涵？需要指出，这一领域演进迅速——7 月初成立的事，几个月后未必还成立——仍有一些建议值得技术领导者考量与反思。

测试与验证

  • 在”步骤定义隐藏复杂性”之处淘汰通用 BDD 框架；采用定制、专为审批测试（approval testing）而造的测试台（约束测试、场景测试），让人工可评审面保持简单、让智能体难以钻空子。按小时而非周来预算——大会议例表明，一个可用的测试台可由有经验的人在一次会话内建成。

  • 对任何现代化/迁移项目，把三层验证栈作为默认：来自真实系统行为的特性测试、模型帮不上忙处的符号执行（数学严谨性）、作为最终闸门、针对真实数据流的生产回溯测试。

  • 对任何不熟悉或 AI 生成的代码库，在信任其测试套件前运行”覆盖率→对抗式 AI 探测→变异测试”序列：先查覆盖率，再让 AI 主动尝试在不破坏测试的前提下破坏代码，仅在探测成功后才施加变异测试。

  • 别再把手工代码评审当事实质量保证；去测量它。若你的组织拿不出”评审实际捕获多少缺陷”的数据，把那当成真实缺口，而非走过场。

驾驭工程与上下文工程

  • 把被动的 lint/静态分析信号转化为确定、具体、分步的指令反馈给智能体（“这是如何重构一个长函数”，而非”这个函数太长”）——这是大会记录到的最高杠杆、最低成本的harness改进。

  • 在harness里建一个”learn”回路：让智能体失败、反思、提出harness修改，把人的参与限定在周期性修剪而非前置撰写。

  • 在共享技能/上下文产物分叉与衰减之前，为其指派明确归属；建一个轻量评估流程（带/不带技能的场景测试）以周期性修剪随模型改进而不再增值的技能。

  • 把面向基础设施/云的智能体约束到狭窄、schema 定义、可审计的工具接口，而非宽泛的云厂商 CLI 访问——屏蔽裸 AWS/gcloud 命令，代之以结构化、可评审的工具调用。

团队设计与工作方式

  • 显式追踪”两个时钟”：产出代码所花时间，与等待决策/规格清晰所花时间。若吞吐量上升而周期时间未改善，约束已上游迁移。修决策流程，而非管道。

  • 即便实现结对在下降，也要刻意保留在规格与设计意图上的结对——把规格结对视为至少与曾经的代码结对同等重要，因为一队智能体现在能凭单条指令生成远超人类结对能逐行评审的代码。

  • 按系统或组件采用风险分级的自主性模型（协作式人监督 vs. 黑灯工厂式全自动），显式基于风险、可逆性与影响半径——不要在整个资产组合上套用单一自主性政策。

  • 把平台团队文化从”选项菜单”转向真正强势的铺装路。让平台团队使用他们要求产品团队使用的同类智能体工具，以弥合削弱平台团队权威的信誉/节奏差距。

人才与技能养成

  • 刻意而非偶然地推行设计法定人数或群体结对模式：资深工程师实时主导设计对话，初级工程师做实际提示，保住本会消失的设计取舍动手接触。

  • 在入职与培训中建显式的、非 AI 学习检查点——受训者必须在不靠智能体的情况下工作并解释其推理——而非假设技能传递会随 AI 辅助交付自动发生。

  • 专门盯住七到十年经验群体有无脱节或身份应变的迹象。这群人的专长正被最快、最隐蔽地贬值，而他们常是你最有经验的交付负责人。

治理

  • 对任何 AI/智能体工具使用套用绿/黄/红风险分级模型（个人生产力/带培训的团队级/需专业工程签署的全公司级），并以持续日志扫描检测作支撑，而非仅靠前置培训。

  • 即便在你自己网络内部，也把 AI 智能体生成的应用代码视为不可信；对内应用零信任与限制影响半径原则，不仅限于边界。

  • 采纳最低库引入延迟（约两周）作为默认供应链缓解，并在代码评审中显式筛查基于 AI 幻觉的依赖攻击。

第三篇：面向管理层的战略建议

瑞士的讨论不仅浮现了对技术人员的潜在行动；还有一些超越软件工程、与业务领导者相关的重大战略意涵。

先讲纪律，再讲加速

大会最清晰的一条战略警告，在安全、治理与受监管行业讨论中以不同措辞重复：智能体 AI 放大组织中既已存在的纪律与习惯——无论正负。测试文化薄弱、风险归属不清、文档卫生糟糕的团队与组织，会变得更快地变差，而非变好。对管理的实践意涵是：抵制”先快跑、后补质量”的诱惑——先修底层纪律缺口，或至少并行修，而非之后修。

管理叙事，而不只是指标

董事会与高管被鲜活、具体、特定的故事打动——而非聚合生产力看板。这把双刃剑两边都管用：组织靠它让董事会重视安全与治理，AI 行业自身也靠它（可重复的”10 倍”轶事而无底层数据）夸大能力。管理者的工作是主动策展并核查到达决策者的故事，而非简单把指标往上汇报、指望对结论被自然得出。

把 token/基础设施经济学当治理问题，而非仅财务问题

多家组织报告 token 支出数月内增长 10 倍，未预算、且基本未被察觉，直到成为危机。这既是成本问题，也是管理流程失败：它需要与组织已施加于云支出同类的治理纪律（具名问责、预算复核节奏、基于使用模式的政策），并及早施加而非被动反应。

抵制一刀切政策；自主性按风险校准

会上描述的一个反复失败模式：对风险画像其实差异巨大的资产组合套用单一 AI 采纳政策（“处处快跑”或”全部锁死”）。会上描述的更有效组织则显式按系统关键性、团队成熟度、监管敞口分级，而非选一个姿态统一套用。管理者的工作是建并维护那套分级，而非给一个全公司统一的答案。

刻意保护创造差异化价值的东西

随着验证、原型乃至基础工程能力被商品化、变廉价，大会一致的主张是：判断、品味与真实的人与人协作成为稀缺、差异化的资源——不是因为”低效”，而是恰恰因为”低效”。这有直接的管理意涵：结对、群组设计会话、缓慢审慎的架构思考等实践应作为战略能力被显式注资与保护，而非被当成在利润压力下优化掉的遗留成本。以 AI 驱动效率为名悄然侵蚀它们的组织，可能发现自己优化掉的正是竞争优势的真实来源。

“对坏习惯的惩罚，如今比以往来得快得多……现在只要几个小时，它就回来踢你一脚。“

为压缩的炒作周期做规划，而非稳定平台

若干有直接市场/估值经验的与会者预期，当前 AI 投资周期会比此前技术周期（互联网、加密）压缩得更快，并特别标出一个合理的 12—18 个月窗口，届时预期会对照真实（约 2—3 倍，而非 10 倍）的交付价值重置。管理者的投资与信息节奏应据此规划：构建保值的持久能力（驾驭工程、验证纪律、治理），而不论炒作周期落在何处，而非把战略押在当下最极端的生产力宣称能站住脚上。

结语

向智能体未来的过渡，与其说是工具的变化，不如说是对”构建软件意味着什么”的一次根本再校准。正如瑞士讨论所示，这个新时代的核心张力是：代码生成看似已变得微不足道，而确保必要的harness、测试与验证已成为关键瓶颈。

要成功，工程组织需要把生产力从体量指标，转向将其视为一门信任与治理的纪律。前路要求把驾驭工程作为核心能力，并主动缓解学徒制危机；我们需要确保下一代工程师能够发展出 AI 模型与智能体无法复制的判断力与品味。

随着验证、原型与基础工程被商品化，最终也最关键的要点是：一个组织——以及一个工程师个人——唯一真实、可持续的差异化，是人类判断。我们正走向这样一个现实：“刻意的人性”投入不是一种待消除的低效，而是一种待保护的战略资产。

在至关重要的地方，我们不应害怕刻意与缓慢。在一个智能体能在数秒内生成海量代码的世界里，最高价值将属于那些谨慎策展意图、为结果承担责任、并保留构建持久系统所需的品味与用心的人。