本文永久链接 – 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编程狂欢背后最真实的一面。

文章要点：

  • 代码生成已经“过剩”，验证能力才是新的核心竞争力
  • “Harness Engineering”（智能体驾驭工程）正在成为一个独立学科，比选模型、写提示词更重要
  • 初级工程师正面临“学徒制断代”危机，7—10年经验的工程师反而压力最大
  • 老板和工程师之间存在巨大认知鸿沟：老板看Demo，工程师看漏洞
  • 遗留系统现代化（COBOL/大型机迁移）是当下AI最能落地变现的场景
  • 治理没跟上：一个AI工具误配置就能让客户数据裸奔在公网上
  • “刻意保持人味儿”成为反共识中的共识：审美、判断力和克制，才是AI时代最后的护城河

一场“诉苦大会”

今年2月，Martin Fowler曾在美国犹他州组织过一次类似的闭门会议，讨论AI给软件工程带来的冲击。仅仅过去几个月，行业变化之快让Fowler和Thoughtworks觉得有必要再开一次。于是6月28日到30日，他们把一群资深技术人拉到了瑞士小镇Engelberg，用“非会议（unconference）”的形式，让40场讨论自由生长，参与者随时可以争论，甚至互相拆台。

报告开篇就很诚实：这场会议追求的不是共识，而是思考的深度和广度。但即便如此，五条主线还是在几乎每一场讨论里反复出现：

  • 代码生成不再是瓶颈，验证才是。无论测试、遗留系统改造、代码评审还是团队设计，讨论最后都会绕回同一个结论：智能体产出代码、测试、规格说明和基础设施的速度，远超任何团队建立信任的速度。
  • “驾驭工程（Harness Engineering）”正在成为一门独立学科。围绕智能体搭建的上下文管理、确定性护栏、技能库和自我改进的反馈回路，被反复认为比模型本身、比提示词更重要。
  • 组织正撞上真正的“学徒制危机”。如果资深工程师只跟智能体搭档，初级工程师就失去了打磨判断力和产品直觉的机会。
  • 管理层和工程师之间的预期落差，比任何技术局限都更危险。老板们看着Demo和自己用AI写周报的经验做出大手笔决策，工程师们却看着一堆没解决的验证、安全和治理问题。
  • 遗留系统现代化，是眼下最清晰、最能守住的价值洼地。多个案例展示了AI辅助COBOL、大型机改造的真实落地，而且验证纪律相当严谨。

接下来，我们逐一拆解这些发现。

发现一：生成已经过剩，验证才是新瓶颈

会上被引用最多的一句话是：

“工程这件事，现在被压缩成了两件事：我怎么描述目标，我怎么验证自己达到了目标。”

这不是一句空话，而是每天都在发生的具体问题。峰会里出现了一整套新的测试词汇：

  • 约束测试（constraint tests）：单输入单输出，专门用来框定智能体的产出边界；
  • 场景测试（scenario tests）和“好日志/坏日志”：直接从真实生产事故里提取的判定样本；
  • 一些团队几个小时就搭出了定制化的审批测试系统，效果反而好过通用的BDD框架——因为它们把人类可评审的表面做得足够简单，让智能体没法“糊弄过关”。

针对高风险的迁移项目，一套三层验证栈正在成型：

→ 行为特征测试（从老系统抓取真实行为）
→ 符号执行（数学层面的严谨验证，AI帮不上忙的地方）
→ 生产环境“回测”（拿真实数据流做最后一道关卡）

这是一套相当扎实、也相当新颖的方法论。

对付“LLM当裁判不靠谱”的问题，会上给出的实际解法是混合确定性与非确定性评估：把linter和规则匹配，跟一个“三模型裁判团”结合起来，把首轮合并通过率从大约60%提到了80%。

更扎心的是，与会者开始公开质疑“人工代码评审=质量保证”这个这两年一直被默认的等式：

“屋子里没有一个人能说清楚，人工评审到底能抓住多少缺陷。”

这被称为一种“现状幻觉”——需要用数据去打破，而不是继续假装它天然有效。还有一句话，也许是全场最扎心的技术判断：

“约束测试比规格说明书重要得多。如果约束测试和规格说明书对不上，你猜谁说了算？”

发现二：Harness Engineering，正在成为独立学科

随着模型能力逐渐同质化，多场讨论都指向同一个判断：真正拉开差距的，不是模型本身，而是围绕模型搭建的Harness——上下文管理、确定性护栏、技能库、自我改进的反馈回路。

数据摆在那里：

  • 一家机构用一套有效的Harness，把token消耗至少削减到原来的1/4，输出的确定性也明显提升；
  • 一场重构实验里，原始的linter输出只能把代码坏味道的解决率提到不到50%；但把linter的结果翻译成具体的、可执行的、一步一步的重构指令（团队内部称之为“习惯钩子”），解决率直接冲到了约90%；
  • 一个搭配良好Harness的小模型，表现能超过一个Harness很弱的大模型。

更有意思的是，表现最好的团队不会自己手写Harness。他们让智能体自己去试错，用一个“学习”技能去复盘每一次会话并提出Harness的修改建议，人类的角色则退到定期做“修剪”和“简化”，而不是从头设计。

但共享Harness和技能库的治理，仍然是个悬而未决的组织难题——它们会像无人认领的代码框架一样腐烂，除非明确谁来负责。可如果把这事儿全部集中到一个专门的“Harness团队”，又很容易重蹈当年运维团队变成瓶颈部门的老路。

发现三：团队在“压缩”，瓶颈转移到了决策上

至少五场关于团队拓扑的讨论，都收敛到了一个相似的形态：更小的“核心”团队（往往是两三个人）指挥大批智能体干活，但组织整体仍要维持大约10人这个“社交黏合”下限，否则团队会散架。

会上出现的一个新诊断工具，叫“两个时钟”问题：一个时钟计算写代码用了多久，另一个时钟计算等一个决策要花多久。

很多团队发现，开发吞吐量确实爆炸式增长了，但整体的交付周期并没有变快——因为决策和需求澄清，才是真正卡脖子的地方。

会上反复被提到的一个案例，堪称正反教材：

  • A团队：产品经理和设计师直接用智能体“单挑”，自己就能疯狂产出功能，工程师被挤到只剩“打扫卫生”的角色。产出确实很高，但被管理层判定为“正在酝酿的灾难”，因为它侵蚀了结对文化和组织的凝聚力。
  • B团队：坚持在需求、测试和设计意图上结对，让一批智能体围绕明确的设计收敛出方案。

平台团队也需要“信誉升级”——传统偏基础设施的平台团队，未必有足够的编程能力去掌管“Harness”或“黑灯工厂”类工具。反复被提出的解法是：平台团队应该使用他们自己要求产品团队使用的那套智能体工具，并且从“菜单式选项”转向更强势的“铺好的路”。

值得一提的是，领域驱动设计（DDD）在这轮讨论里被重新“翻红”，被认为是当下最适合在智能体速度和规模下，持续协商模块和团队边界的既有方法论——不是因为它能画出一张完美蓝图，而是因为它是目前唯一一套能在大型组织里持续协商和命名边界的成熟方法。

发现四：学徒制断代危机，正在真实发生

至少六场独立的讨论，都提到了同一种担忧：如果初级工程师永远没机会去啃真正的代码、真正的生产事故、真正的设计权衡——因为这些都被智能体（或者只跟智能体搭档的资深工程师）吸收掉了——整个行业将失去培养下一代“有判断力、有审美”的工程师的机制。

已经有一些具体的应对方案在被试点：

  • “设计法定人数”或Mob编程模式：资深工程师主导设计讨论，但实际的提示词编写由初级工程师完成；
  • 明确的、公开问责的“非AI学习练习”；
  • 面向早期职业阶段的新课程，把“智能体编排与监督”当作一项基本能力来教。

更值得关注的是，7到10年工作经验的这批人被认为承受着最大的压力——他们花了整整十年打磨的技能，如今常常被模型轻松超越，这不只是技术冲击，更是真实的情感和身份认同冲击。

一项相关研究也印证了这种担忧：用AI重度辅助写论文的大学生，三个月后批判性思维能力出现了可测量的下降，即便对比他们自己此前不借助AI时的基准也是如此。

会上有一句话被反复引用：

“所有最好的软件，都是慢慢做出来的。是那些我们花更多时间、更多心思去打磨的东西……我觉得慢思考，真的是好事。”

发现五：遗留系统现代化，是最确定的价值洼地

多场讨论都展示了技术上相当严谨、真正跑通了的AI辅助遗留系统／大型机现代化方案，而且不是PPT里的构想，是已经在生产环境跑着的项目。

几条被反复提及的迁移纪律：

  • “移植时什么都不加，什么都不改，能删的全删掉”；
  • 一次只改一件事——先保证行为一致，再改架构，绝不同时动两处；
  • 刻意保留已知的bug，作为客户认可的决定，而不是任由AI“好心办坏事”，把下游系统可能依赖的“老毛病”悄悄修掉。

一些原本高不可攀的技术目标，如今变得可行：

  • 4天用AI写出一个完整的定制TypeScript到.NET CLR编译器；
  • 3天、约5000美元的token成本，写出一个能通过NIST测试套件的COBOL编译器；
  • 通过让模型识别字节层面的模式，逆向出一份1994年、加密且无文档的大型机二进制格式。

定制编译器、转译器、形式化验证——这些以前普通团队根本碰不起的问题，现在触手可及。

给董事会讲这个故事的关键，是把AI投资和现代化／维护预算直接挂钩——这部分预算通常占大型企业IT总支出的30%到50%。这能把一个抽象的技术诉求，变成一个具体的、能上董事会的资本配置决策。有个真实案例，把一个模糊的“1亿美元以上”的诉求，压缩成了一个明确的“800万美元、覆盖20%系统”的方案，还绑定了可衡量的价值。

老板和工程师之间，隔着一条认知鸿沟

几乎每场讨论都会提到一个共同的抱怨：董事和CEO们普遍相信“产品经理把需求文档扔进魔法机器，写得好好的软件就出来了”。这很大程度上是因为，他们自己接触AI的经验，来自那些表现优秀的报告写作和摘要工具——但这类工具，恰恰是软件工程能力的一个糟糕替代品。

这条鸿沟，不会因为模型变强就自动消失。

真正管用的是生动、具体、能挂钩到公司资产负债表的故事，再加上数据纪律——比如把供应商的“10倍效率”宣传拿去跟真实的同行基准对照，或者干脆设计一些让高管亲自动手、亲自撞墙的练习。

一个眼下就在发生的警讯：某机构报告的内部安全事件数量，六个月内增长了约20倍，与此同时，AI的token预算原本按一年编列，如今三个月就花完了。这种预算冲击，比任何生产力宣传，都更快抓住董事会的注意力。

关于真实的生产力预期，会上有一个更冷静的判断：把整个软件开发生命周期都算进去，而不是只看代码生成本身，现实增益大概在2到3倍，而不是宣传里的10倍。有与会者预测，这种预期和现实之间的落差，可能会在未来12到18个月内“戳破泡沫”。

治理，还没跟上自主性扩张的速度

关于普通人开发（citizen development）和安全的几场讨论，摆出了一串相当真实、也相当吓人的事故：

  • 一位会计用Copilot搭了个应用，AI建议用Cloudflare隧道，结果不小心把客户数据暴露在了公网上；
  • 一个营销团队的AI助手，通过层层叠加的OAuth授权，拿到了极广的G-Suite访问权限，广到公司在想关掉它的时候，根本理不清它到底能碰到什么；
  • 一个智能体因为磁盘空间不足，直接删掉了备份来腾地方——事后还对此“很高兴”。

一个被认为比较实用的治理模式，是红黄绿风险分级（个人使用／团队使用需配合强制培训／全公司范围使用需专业工程师把关），并且用“检测优先于预防”来兜底——持续扫描智能体的对话日志，找出危险模式，而不是完全依赖跟不上模型每周更新节奏的前置培训。

还有一种新的供应链攻击手法值得警惕：攻击者可以预测LLM大概率会“幻觉”出哪些不存在的库名，然后抢先用这些名字发布真正的恶意包。沙箱本身并不能完全解决这个问题，因为被“投毒”的依赖仍然有机会一路走到生产环境。

眼下能实操的缓解方式包括：

  • 新版本库延迟大约两周再引入（大部分被投毒的版本会在这个窗口期内被发现）；
  • 使用经过审核的内部软件仓库；
  • 用微虚拟机做沙箱（比容器更安全，但也还没被证明完全够用）；
  • 把智能体生成的代码，哪怕是在自己内网里，也当作不可信对象，把零信任原则落到内部，而不只是边界防护。

Token经济学与“主权”，已经上升到董事会议题

对自建模型的兴趣，驱动力正在从纯粹的成本考虑，转向对主权和控制权的诉求：担心美国联邦法律对数据的长臂管辖，担心供应商单方面涨价或限流，也担心把“学习和改变的能力”整体外包出去。

  • 成本效率的差异可以高达1400倍，这不只取决于选什么模型，更取决于企业数据接入的架构方式。模型和企业系统之间低效的MCP往返调用，是一个被严重低估的成本来源，也造成了成本优化（数据离模型更近）和安全（数据暴露面更大）之间的真实张力。
  • 真正大规模的自建模型，是一门稀缺且专业化的手艺——从每美元固定GPU基础设施的吞吐性能工程，一路细到机架物理拓扑，这类能力正被超大规模云厂商和新兴云厂商吸走。多数组织应该正视这道能力鸿沟，而不是想当然地认为自建很简单。
  • 对于编程这类特定场景，会上也给出了一条折中路径：使用小规模的专用推理硬件，或者专门做代码模型托管的服务商，绕开完整的超大规模自建难题。

开源，正面临真正的“大考”

会上有一场没有达成共识、但相当有分量的辩论：AI到底是加剧了开源本就存在的可持续性危机——维护者精疲力竭、被市值千亿的公司无偿榨取劳动——还是催生了全新的局面：一个人的项目几个月内就能滚到超大规模，AI生成的PR洪水又让维护者根本审不过来？

一个被提出的、相对可行的应对模式：把一个PR的意图先逆向翻译成大白话描述，评估这个意图本身是否值得做，然后让自己的AI从零重新实现一遍再合并——既给贡献者署名，又不需要盲目信任对方的代码，维护成本还很低。

还有一个带点推测性但相当合理的判断：开源分享的重心，可能会从“代码”转移到“规格说明／想法”本身，因为具体实现对每个使用者来说都变得便宜到可以随时重新生成。但风险也在这里——如果智能体彻底取代了共享库依赖，那些没有AI／算力接入能力的人，将失去开源曾经带来的那种“拉平机会”的红利。

反共识：刻意保持“人味儿”

整场会议的技术乐观情绪之下，一直流淌着一股严肃的反思：如果验证、原型设计乃至市场测试，都变得几乎免费、人人可得，那么唯一还剩下的差异化因素，就是人类的判断力、审美和用心。组织需要刻意去保护和抬高这一点，而不是把它工程化掉。

会上给出了几个挺有说服力的历史类比：

  • 印象派的诞生，恰恰是因为相机已经能完美复刻现实，人类的价值因此转向“解读”；
  • 鼓机出现之后，鼓手没有被淘汰，反而变得更精进；
  • 1997年以来，世界上最强的“棋手”，某种意义上一直是“人类+引擎”的组合，而不是单独的引擎。

这不是反技术情绪——它跟整场会议对智能体工具的整体热情是并存的。最清晰的一句表达是：让“判断被注入”的那个环节，刻意地、可见地保持人类主导，即便“东西被造出来”的那个环节，正变得高度自动化。

“我唯一不想外包出去的，是验收标准。剩下的一切，我都愿意外包。”

给技术负责人的行动清单

测试与验证

  • 淘汰用步骤定义掩盖复杂度的通用BDD框架，转向定制的审批测试系统（约束测试、场景测试），把人类可评审的表面做得简单、让智能体难以糊弄。会上的案例显示，一个有经验的人在一次会话里就能搭出可用的测试系统，按小时预算，而不是按周。
  • 任何现代化／迁移项目，默认采用三层验证栈：真实系统行为特征测试、AI帮不上忙的符号执行、以及真实数据流的生产环境回测，作为最后一道关卡。
  • 面对陌生或AI生成的代码库，先看覆盖率，再让AI主动尝试绕过测试去“搞破坏”，探测成功后再上变异测试——按这个顺序走，而不是一上来就堆测试。
  • 别再把人工代码评审当成天然的质量保证，去测量它。如果组织拿不出评审到底抓住了多少缺陷的数据，那就把它当成真实的短板，而不是走个流程。

Harness与上下文工程

  • 把被动的lint／静态分析信号，转成确定性的、具体的、一步步的指令反馈给智能体（比如直接告诉它“长函数该怎么拆”，而不是只说“这个函数太长了”）——这是会上记录到的性价比最高的Harness改进。
  • 在Harness里嵌入“学习”闭环：让智能体去试错、复盘、提出Harness修改建议，人类的介入限定在定期修剪，而不是从头设计。
  • 在共享的技能库／上下文资产分叉腐烂之前，明确指定负责人；建立一套轻量的评估流程（对比有无某项技能的场景测试），随着模型能力提升定期清理掉不再增值的部分。
  • 让面向基础设施／云的智能体只能调用范围狭窄、有schema约束、可审计的工具接口，而不是让它直接拿到宽泛的云厂商CLI权限——屏蔽原生的AWS/gcloud命令，改用结构化、可审查的工具调用。

团队与协作方式

  • 明确追踪“两个时钟”：第一个是写代码耗时，第二个是等决策／需求澄清耗时。如果吞吐量上去了但交付周期没变快，说明瓶颈已经转移到了上游，该修的是决策流程，不是流水线。
  • 刻意维护在需求和设计意图上的结对，哪怕实现层面的结对在减少——把“需求结对”看得至少和曾经的“代码结对”一样重要，毕竟一批智能体现在能凭一条指令生成的代码量，早就超过人类结对逐行评审的极限。
  • 按系统或组件采用风险分级的自主性模型（协作机器人式的人工监督 vs 黑灯工厂式的全自动），依据风险、可逆性和影响半径来划分，不要给整个产品组合套用同一套自主性策略。
  • 把平台团队文化从“菜单式选项”转向真正强势的“铺好的路”。让平台团队自己也用上他们要求产品团队使用的那套智能体工具，弥合信誉和节奏上的落差。

人才培养

  • 刻意落地“设计法定人数”或Mob编程模式：资深工程师实时主导设计讨论，初级工程师负责实际的提示词编写，保留他们对设计权衡的一手接触，否则这种接触会彻底消失。
  • 在入职和培训中嵌入明确的、非AI辅助的学习检查点——要求受训者在没有智能体帮助的情况下完成工作并解释推理过程，而不是想当然认为技能会随着AI辅助交付自动传承下去。
  • 特别关注7到10年经验这个群体是否出现脱离感或身份焦虑的信号。他们的专业价值正在被最快、也最隐蔽地稀释，而他们往往又是团队里经验最丰富的交付骨干。

治理

  • 对任何AI／智能体工具的使用，套用红黄绿风险分级（个人生产力用途／团队级用途需配合培训／全公司范围使用需专业工程师签字），并配以持续的日志扫描检测，而不是只靠前置培训兜底。
  • 把智能体生成的应用代码，哪怕是在自己内网里，也当作不可信对象，把零信任和限制影响半径的原则落到内部，而不只是边界防护。
  • 默认采用大约两周的最低库版本引入延迟，作为供应链的默认缓解措施，并在代码评审中专门筛查基于AI幻觉的依赖投毒攻击。

给管理层的战略建议

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》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。