本文永久链接 – https://tonybai.com/2026/07/31/thoughtworks-future-of-software-engineering-2026-verification-bottleneck
大家好，我是Tony Bai。
导读：2026年6月，Martin Fowler联合Thoughtworks，在瑞士小镇Engelberg召集了一场非正式技术峰会。参会者是各大公司的CTO、架构师和资深工程师。当所有人都在惊叹AI写代码有多快时，这一群真正在一线负责生产系统的技术领袖，却在瑞士雪山下达成了一个反直觉的共识：代码生成早就不是问题了，问题是没有人能跟上验证的速度。这场持续三天、40场闭门讨论的峰会，撕开了AI编程狂欢背后最真实的一面。
文章要点：
今年2月，Martin Fowler曾在美国犹他州组织过一次类似的闭门会议，讨论AI给软件工程带来的冲击。仅仅过去几个月，行业变化之快让Fowler和Thoughtworks觉得有必要再开一次。于是6月28日到30日，他们把一群资深技术人拉到了瑞士小镇Engelberg，用“非会议（unconference）”的形式，让40场讨论自由生长，参与者随时可以争论，甚至互相拆台。
报告开篇就很诚实：这场会议追求的不是共识，而是思考的深度和广度。但即便如此，五条主线还是在几乎每一场讨论里反复出现：
接下来，我们逐一拆解这些发现。
会上被引用最多的一句话是：
“工程这件事，现在被压缩成了两件事：我怎么描述目标，我怎么验证自己达到了目标。”
这不是一句空话，而是每天都在发生的具体问题。峰会里出现了一整套新的测试词汇：
针对高风险的迁移项目，一套三层验证栈正在成型：
→ 行为特征测试（从老系统抓取真实行为）
→ 符号执行（数学层面的严谨验证，AI帮不上忙的地方）
→ 生产环境“回测”（拿真实数据流做最后一道关卡）
这是一套相当扎实、也相当新颖的方法论。
对付“LLM当裁判不靠谱”的问题，会上给出的实际解法是混合确定性与非确定性评估：把linter和规则匹配，跟一个“三模型裁判团”结合起来，把首轮合并通过率从大约60%提到了80%。
更扎心的是，与会者开始公开质疑“人工代码评审=质量保证”这个这两年一直被默认的等式：
“屋子里没有一个人能说清楚，人工评审到底能抓住多少缺陷。”
这被称为一种“现状幻觉”——需要用数据去打破，而不是继续假装它天然有效。还有一句话，也许是全场最扎心的技术判断：
“约束测试比规格说明书重要得多。如果约束测试和规格说明书对不上，你猜谁说了算？”
随着模型能力逐渐同质化，多场讨论都指向同一个判断：真正拉开差距的，不是模型本身，而是围绕模型搭建的Harness——上下文管理、确定性护栏、技能库、自我改进的反馈回路。
数据摆在那里：
更有意思的是，表现最好的团队不会自己手写Harness。他们让智能体自己去试错，用一个“学习”技能去复盘每一次会话并提出Harness的修改建议，人类的角色则退到定期做“修剪”和“简化”，而不是从头设计。
但共享Harness和技能库的治理，仍然是个悬而未决的组织难题——它们会像无人认领的代码框架一样腐烂，除非明确谁来负责。可如果把这事儿全部集中到一个专门的“Harness团队”，又很容易重蹈当年运维团队变成瓶颈部门的老路。
至少五场关于团队拓扑的讨论，都收敛到了一个相似的形态：更小的“核心”团队（往往是两三个人）指挥大批智能体干活，但组织整体仍要维持大约10人这个“社交黏合”下限，否则团队会散架。
会上出现的一个新诊断工具，叫“两个时钟”问题：一个时钟计算写代码用了多久，另一个时钟计算等一个决策要花多久。
很多团队发现，开发吞吐量确实爆炸式增长了，但整体的交付周期并没有变快——因为决策和需求澄清，才是真正卡脖子的地方。
会上反复被提到的一个案例，堪称正反教材：
平台团队也需要“信誉升级”——传统偏基础设施的平台团队，未必有足够的编程能力去掌管“Harness”或“黑灯工厂”类工具。反复被提出的解法是：平台团队应该使用他们自己要求产品团队使用的那套智能体工具，并且从“菜单式选项”转向更强势的“铺好的路”。
值得一提的是，领域驱动设计（DDD）在这轮讨论里被重新“翻红”，被认为是当下最适合在智能体速度和规模下，持续协商模块和团队边界的既有方法论——不是因为它能画出一张完美蓝图，而是因为它是目前唯一一套能在大型组织里持续协商和命名边界的成熟方法。
至少六场独立的讨论，都提到了同一种担忧：如果初级工程师永远没机会去啃真正的代码、真正的生产事故、真正的设计权衡——因为这些都被智能体（或者只跟智能体搭档的资深工程师）吸收掉了——整个行业将失去培养下一代“有判断力、有审美”的工程师的机制。
已经有一些具体的应对方案在被试点：
更值得关注的是，7到10年工作经验的这批人被认为承受着最大的压力——他们花了整整十年打磨的技能，如今常常被模型轻松超越，这不只是技术冲击，更是真实的情感和身份认同冲击。
一项相关研究也印证了这种担忧：用AI重度辅助写论文的大学生，三个月后批判性思维能力出现了可测量的下降，即便对比他们自己此前不借助AI时的基准也是如此。
会上有一句话被反复引用：
“所有最好的软件，都是慢慢做出来的。是那些我们花更多时间、更多心思去打磨的东西……我觉得慢思考，真的是好事。”
多场讨论都展示了技术上相当严谨、真正跑通了的AI辅助遗留系统／大型机现代化方案，而且不是PPT里的构想，是已经在生产环境跑着的项目。
几条被反复提及的迁移纪律：
一些原本高不可攀的技术目标，如今变得可行：
定制编译器、转译器、形式化验证——这些以前普通团队根本碰不起的问题，现在触手可及。
给董事会讲这个故事的关键，是把AI投资和现代化／维护预算直接挂钩——这部分预算通常占大型企业IT总支出的30%到50%。这能把一个抽象的技术诉求，变成一个具体的、能上董事会的资本配置决策。有个真实案例，把一个模糊的“1亿美元以上”的诉求，压缩成了一个明确的“800万美元、覆盖20%系统”的方案，还绑定了可衡量的价值。
几乎每场讨论都会提到一个共同的抱怨：董事和CEO们普遍相信“产品经理把需求文档扔进魔法机器，写得好好的软件就出来了”。这很大程度上是因为，他们自己接触AI的经验，来自那些表现优秀的报告写作和摘要工具——但这类工具，恰恰是软件工程能力的一个糟糕替代品。
这条鸿沟，不会因为模型变强就自动消失。
真正管用的是生动、具体、能挂钩到公司资产负债表的故事，再加上数据纪律——比如把供应商的“10倍效率”宣传拿去跟真实的同行基准对照，或者干脆设计一些让高管亲自动手、亲自撞墙的练习。
一个眼下就在发生的警讯：某机构报告的内部安全事件数量，六个月内增长了约20倍，与此同时，AI的token预算原本按一年编列，如今三个月就花完了。这种预算冲击，比任何生产力宣传，都更快抓住董事会的注意力。
关于真实的生产力预期，会上有一个更冷静的判断：把整个软件开发生命周期都算进去，而不是只看代码生成本身，现实增益大概在2到3倍，而不是宣传里的10倍。有与会者预测，这种预期和现实之间的落差，可能会在未来12到18个月内“戳破泡沫”。
关于普通人开发（citizen development）和安全的几场讨论，摆出了一串相当真实、也相当吓人的事故：
一个被认为比较实用的治理模式，是红黄绿风险分级（个人使用／团队使用需配合强制培训／全公司范围使用需专业工程师把关），并且用“检测优先于预防”来兜底——持续扫描智能体的对话日志，找出危险模式，而不是完全依赖跟不上模型每周更新节奏的前置培训。
还有一种新的供应链攻击手法值得警惕：攻击者可以预测LLM大概率会“幻觉”出哪些不存在的库名，然后抢先用这些名字发布真正的恶意包。沙箱本身并不能完全解决这个问题，因为被“投毒”的依赖仍然有机会一路走到生产环境。
眼下能实操的缓解方式包括：
对自建模型的兴趣，驱动力正在从纯粹的成本考虑，转向对主权和控制权的诉求：担心美国联邦法律对数据的长臂管辖，担心供应商单方面涨价或限流，也担心把“学习和改变的能力”整体外包出去。
会上有一场没有达成共识、但相当有分量的辩论：AI到底是加剧了开源本就存在的可持续性危机——维护者精疲力竭、被市值千亿的公司无偿榨取劳动——还是催生了全新的局面：一个人的项目几个月内就能滚到超大规模，AI生成的PR洪水又让维护者根本审不过来？
一个被提出的、相对可行的应对模式：把一个PR的意图先逆向翻译成大白话描述，评估这个意图本身是否值得做，然后让自己的AI从零重新实现一遍再合并——既给贡献者署名，又不需要盲目信任对方的代码，维护成本还很低。
还有一个带点推测性但相当合理的判断：开源分享的重心，可能会从“代码”转移到“规格说明／想法”本身，因为具体实现对每个使用者来说都变得便宜到可以随时重新生成。但风险也在这里——如果智能体彻底取代了共享库依赖，那些没有AI／算力接入能力的人，将失去开源曾经带来的那种“拉平机会”的红利。
整场会议的技术乐观情绪之下，一直流淌着一股严肃的反思：如果验证、原型设计乃至市场测试，都变得几乎免费、人人可得，那么唯一还剩下的差异化因素，就是人类的判断力、审美和用心。组织需要刻意去保护和抬高这一点，而不是把它工程化掉。
会上给出了几个挺有说服力的历史类比：
这不是反技术情绪——它跟整场会议对智能体工具的整体热情是并存的。最清晰的一句表达是：让“判断被注入”的那个环节，刻意地、可见地保持人类主导，即便“东西被造出来”的那个环节，正变得高度自动化。
“我唯一不想外包出去的，是验收标准。剩下的一切，我都愿意外包。”
测试与验证
Harness与上下文工程
团队与协作方式
人才培养
治理
1. 先补纪律，再谈提速。
会上最清晰的一条战略警告是：智能体AI会放大组织里已经存在的习惯——不管好坏。测试文化薄弱、风险责任不清、文档卫生差的团队和组织，只会更快地变差，而不是变好。管理层要抵制“先冲速度、质量以后再补”的诱惑，把补齐纪律缺口放在提速之前或至少同步进行。
2. 管好故事，不只是管好指标。
打动董事和高管的，是生动、具体的故事，而不是汇总的生产力仪表盘。这是把双刃剑：既是让董事会真正重视安全和治理的方式，也是整个AI行业自己惯用的“10倍”话术套路。管理层的职责，是主动核实、把关流向决策层的故事，而不是把指标往上一报了事。
3. 把token／基础设施经济问题当成治理问题，而不只是财务问题。
多家机构报告token支出在几个月内暴涨10倍，事先没有预算，往往等到成了危机才被发现。这本质上是管理流程的失败，跟成本本身一样严重——需要像对待云支出那样，把明确的责任人、预算复审节奏和基于使用模式的政策，尽早而不是事后补上。
4. 抵制一刀切，让自主性跟着风险走。
一种反复出现的失败模式，是给风险差异巨大的整个产品组合，套用同一套AI采用政策（要么“全面提速”，要么“全面锁死”）。表现更好的组织，会按系统关键度、团队成熟度、监管敞口来做分层，而不是选定一种立场一刀切。管理层的工作是搭建并维护这套分层，而不是拍板一个全公司统一的答案。
5. 刻意保护那些创造差异化价值的东西。
随着验证、原型设计乃至基础工程能力都变得商品化、廉价化，会上的一致判断是：判断力、审美和真正的人类协作，将成为稀缺的差异化资源——不是尽管“低效”，而恰恰是因为“低效”才珍贵。
这对管理层意味着：结对、Mob设计会议、慢而审慎的架构思考，应该被明确地投入资源、当作战略能力来保护，而不是在利润压力下当成可以优化掉的历史包袱。悄悄侵蚀这些东西的组织，可能会发现自己在“提效”的名义下，优化掉的恰恰是真正的竞争优势。
“你现在犯的坏习惯，报应来得比以前快多了……以前可能要等很久，现在可能就几个小时，它就会反过来咬你一口。”
6. 为压缩的炒作周期做准备，而不是等一个稳定的高原期。
一些拥有一线市场和估值经验的与会者认为，当前这一轮AI投资周期，会比互联网、加密货币等历史周期压缩得更快，并明确给出了一个大致12到18个月的窗口——届时预期会向真实交付价值（大约2到3倍，而不是10倍）回归。管理层应该按这个节奏来规划投资和对外沟通的周期：把资源押在能穿越炒作周期、始终保值的能力上（Harness工程、验证纪律、治理体系），而不是把整个战略赌在今天最极端的生产力宣传能一直成立上。
这场瑞士峰会传递出的信号，本质上不是一次工具升级，而是一次关于“做软件到底意味着什么”的重新校准。代码生成看起来已经变得轻而易举，真正的瓶颈，变成了怎么把必要的Harness、测试和验证做扎实。
想要跑赢这一轮变化，工程组织需要把“生产力”从一个数量指标，重新理解成一种关于信任和治理的纪律。Harness工程要成为核心能力，学徒制危机要被主动化解——我们需要确保下一代工程师，仍然有机会培养出AI模型和智能体复制不了的判断力和审美。
而随着验证、原型设计和基础工程能力逐渐商品化，最后也是最重要的一条结论是：对一个组织、也对一个工程师个体而言，唯一真正可持续的差异化因素，就是人类的判断力。 我们正在走向这样一个现实：“刻意的人味儿”，不再是一种需要被消灭的低效，而是一项需要被保护的战略资产。
在一个智能体能在几秒钟内生成海量代码的世界里，我们不必害怕在最重要的地方，保持刻意和缓慢。
真正的价值，会留给那些用心打磨意图、愿意为结果负责、并且始终守住那份成就持久系统所需要的审美与耐心的人。
资料来源：Thoughtworks《The Future of Software Engineering》报告，2026年6月28—30日瑞士Engelberg峰会纪要。- https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future_of_software_engineering_europe_2026.pdf
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。