2026 年，智能体将在企业级应用中取得哪些实质性突破？ 点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！
随着 AI 改写规则，几乎每一位工程领导者都在回答同样的问题：工程团队应该如何组织？当基础模型持续进步时，组织应该把资源投向哪里？怎样在不引入不可接受运营风险的前提下提升工程效率？AI-augmented 组织与 AI-native 组织到底有什么本质差别？
关于如何构建一个 AI-native 工程组织，目前并不存在成熟剧本，工程领导者也很少有机会公开对比彼此学到的经验。这类讨论往往只停留在单个公司内部，并受到竞争压力和技术快速演进的影响。
Snowflake 作为一个承载成千上万家组织构建其数据与 AI 战略的平台，天然适合成为这类对话的召集者。CTO Circle 的设立，就是为了给工程领导者提供一个可信赖的同行交流空间，让大家能够彼此借鉴那些正处于相同转型中的真实经验，并挑战固有假设。在 2026 年于旧金山举办的 Snowflake Summit 期间，首届活动汇聚了来自金融服务、电信、零售和科技等行业的 350 多位 CTO，共同交换实践经验。
讨论很快超越了 coding assistants 和模型选型本身，转而聚焦于：工程组织正在如何被重构、哪些实践已经在生产中被验证有效、以及领导者们正在把投资放在哪里，才能构建长期竞争优势。最终，讨论逐步收敛到三个主题上，这也定义了什么是 AI-native 工程组织：让 AI 真正在生产中运行、在速度与风险之间取得平衡，以及重新设计面向 AI 的工程团队。
AI 进入生产：什么会失效，什么能扩展
很多组织的 AI 之旅，都是从在现有工程工作流里引入 coding assistants 开始的。开发者写代码更快了一点，文档也更容易产出了。这些提升确实有价值，但它们并没有真正改变底层的工程系统。
Snowflake 工程高级副总裁 Vivek Raghunathan 挑战大家用更宽的视角去思考 AI 采纳。他认为，构建 AI-native 工程组织的起点，是管理哲学的转变。Snowflake 没有把开发者生产力视为一个“工程问题”或“文化问题”，而是开始把它当作一个产品来经营。
“如果你把开发者当作客户来对待，会怎样？”这个问题成了 Snowflake 推进自身工程变革的出发点。团队不再默认管理层知道工程师需要什么，而是像打造面向外部客户的产品一样，采用同样的产品管理原则来设计内部开发者体验。
他们先访谈开发者，找出工作在哪些环节被拖慢，再把整个软件开发生命周期中的摩擦点映射出来。随后，团队建立了基线指标，并通过实验去衡量每一次改动带来的影响。整个方法既有清晰的高层支持，也有自下而上的采纳过程，从而确保这些改善反映的是真实的工程工作方式，而不是领导者想象中的工作方式。
图 1：AI-native 方法
结果是可量化的。18 个月内，Snowflake 内部开发者 Net Promoter Score 提升了 30 多个点，满意与不满意开发者的比例达到 4:1。更重要的是，这种提升并不只是体验变好，而是转化成了一个能够更高效交付软件、并随着 AI 能力继续演进而更快适应的工程组织。
图 2：Snowflake 整体开发效率满意度
Vivek 还解释说，仅仅“采用”工具，并不足以带来真正显著的生产力提升。高杠杆来自于使用深度，以及在大规模场景下对工具的真正掌握。在 Snowflake，这个过程大致经历了三个阶段：
Adoption：开发者开始在日常工作中学会使用 AI 工具。
Mastery：工程师逐渐摸索出可重复、可稳定产生更好结果的工作流。
Optimization：这些工作流沉淀成组织知识，能够被每位工程师共享和复用。
图 3：AI-augmented 组织与 AI-native 组织的差异
一个典型例子，是 Snowflake 内部逐步沉淀出的工程设计模式。最早的 AI 使用者不断尝试 prompting 技术、规划方法和调试方式。随着时间推移，组织把那些能够持续产生更好结果的模式记录下来，并在整个工程团队中共享。
于是，虽然每位开发者都拥有同样的 AI 工具，但采用成熟工作流的工程师，表现会持续优于那些还停留在早期使用层级的人。真正的竞争优势，并不是简单地多部署一个 AI assistant，而是把成功的工作方式制度化。
这种对工作流的重视，也在改变组织对软件开发本身的理解。随着 AI 大幅降低了把想法变成可运行软件所需的成本，每个人都开始成为 builder。产品经理可以快速搭建原型，设计师可以直接在代码里验证概念，领域专家也可以为其他角色补充 guardrails。团队不再只能通过演示文稿和文档争论想法，而是可以通过构建可运行软件来验证假设。代码，正越来越成为测试想法的最快方式。
《The Algorithm》作者 Jon McNeill 进一步扩展了这一点。他鼓励领导者重新审视那些塑造了工程组织几十年的基本假设。很多公司总是先从技术出发，再去寻找能把它用到哪里的地方；而 Jon 认为，真正成功的组织恰恰反过来做：先明确少数几个最重要的业务约束，再围绕解决这些问题去重构工程系统。当组织把 AI 推向生产时，成功的衡量标准不再是谁生成了最多代码、消耗了最多 tokens，而是谁构建出了最简单、最快速、最有效的工程系统。真正更值得关注的排行榜，也许不是谁写出了最多 AI 代码，而是谁消除了从一个想法走到生产之间最多的不必要步骤。
最大化速度，同时控制风险
随着 AI 嵌入整个软件开发生命周期，工程领导者面临的第二个挑战也随之出现：每一次开发速度的提升，都会让系统可靠性和运营纪律的重要性进一步上升。走得最快的组织，往往正在投资那些既能保证速度、又能保证可靠性的架构。
Snowflake Observability Business Unit 总经理 Jeremy Burton 指出，AI 已经进入了一个新阶段。早期的实验正在让位于生产部署，组织越来越被要求证明可衡量的业务价值，而不只是展示孤立的技术亮点。与此同时，AI 也引入了全新的运营难题。AI agents 会生成更多 telemetry、与更多系统交互，并基于分散在更复杂环境中的信息做出决策。这使得 observability 的角色，从单纯监控基础设施，转变为为 AI 系统提供可靠运行所需的上下文。
图 4：新的 AI 工作负载带来了更多 telemetry 和更高复杂度
Jeremy 也挑战了企业 AI 中一种很常见的假设：即更好的模型只需要更好的数据。现实是，AI 的有效性取决于它能够获得多少上下文，而这个上下文远远超出原始 telemetry 本身。它还包括解释数据含义的语义层、通过 ontologies 和 knowledge graphs 建立的关系，以及把系统连接起来的业务上下文。同样重要的，还有上下文被访问的方式。AI agents 需要 API、CLI 和 Model Context Protocol (MCP) 这类标准化接口，才能可靠地检索和操作信息；而工程师则需要直观的方式去深入数据、验证 AI 生成的洞察。
当丰富的上下文与开放的访问方式结合起来，原本割裂的 telemetry 就能变成一个人类与 AI 都可有效推理、快速排障并做出更优决策的环境。那些仍把 logs、metrics、traces、运营数据和业务上下文存放在彼此孤立系统中的组织，会让 AI 很难准确理解生产环境。相反，工程 telemetry 应该被看作是存在于统一基础之上的数据，在那里系统之间的关系可以被理解、被查询。
Netflix 工程经理 Aditya Gaur 用他们在自动化 root cause analysis 方面的工作，展示了这种做法在现实中的样子。虽然这个项目常被描述为 AI initiative，但 Aditya 解释说，它的成功更多依赖于数据架构，而不是 AI 本身。
在引入 AI agents 之前很多年，Netflix 就已经投入精力，把分散的 telemetry 连接起来，用 ontology 和 knowledge graph 建模系统关系，并构建共享上下文层。等到 AI 真正进入这个场景时，基础设施其实早已准备就绪。于是，AI agents 不需要在割裂的 logs 和 dashboards 里四处搜索，而是可以基于结构化运营知识进行推理，在故障调查中提出更有价值的假设。
Caitlin Colgrove 作为 Hex 的 CTO，则从另一个角度讨论了“速度”。她提醒大家重新定义在 AI 时代“move fast”究竟意味着什么。组织不能只是部分 AI native，最终总会走到一个节点：必须彻底投入，并重构团队如何构建产品、做出决策、把 AI 融入日常工作。她把这个过程称为 “burning the boats” 。AI 必须成为业务运行方式中的基础能力。
Hex 最初应对 generative AI 的方式，是先成立一个专门的 AI 产品团队。虽然这种方法产出了一些有用功能，但同时也制造了组织瓶颈。最终，Hex 解散了集中式 AI 团队，把责任分散到每一个产品团队。如今，Hex 之所以能快速交付产品、把 AI 能力深入嵌入产品之中，核心原因正是 ownership 掌握在最接近客户问题的工程师手里。
Barclays 董事总经理 Chris Kozlowski 则从大型企业视角补充了另一点：只有当速度与治理、信任配套时，速度才真正产生价值。在高度受监管的环境里，工程团队不能被迫在创新与控制之间二选一。
Dialpad 工程高级副总裁 Corey Burke 与 project44 工程副总裁 Arun Rajamanickam 一起描述了 AI 如何改变软件开发节奏。当 AI agents 已经能够独立完成一项功能中相当大比例的实现工作时，工程师花在“写代码”上的时间会更少，而更多投入到定义意图、编排多个 agents、以及验证结果上。
他们强调，如果想最大化速度，就必须构建允许团队快速实验、同时又不牺牲可靠性的工程平台。AI 缩短了从识别客户问题到验证解决方案之间的路径，但前提是团队已经拥有足够的基础设施、共享上下文和运营纪律，能让他们有信心地快速迭代。
为 AI 重新设计工程团队
如果 AI 改变了软件的构建方式，它也必然会改变工程组织的设计方式。这意味着新的团队结构、新的领导模型，以及对于工程师到底在哪里创造最大价值的全新理解。
Cerebras Systems 的 EVP Qi Jin 提出，那些为上一代软件开发模式而优化过的组织，往往本身就是 AI 采纳的最大障碍。现有流程和组织边界，本来是为了扩大已验证的工作方式，而不是为了持续吸收颠覆性技术。因此，成功拥抱 AI 不只是引入新工具而已，领导者还必须重新思考 operating models，让团队能够随着技术演进快速吸纳新能力。
Qi 用 “Code Yellow” 这个概念来描述这种转型：它是一种以紧迫感和客户问题为中心推动组织变革的框架。这一视角也呼应了他在关于 “wartime manager” 的文章中提出的更广泛领导理念：当外部变化剧烈加速时，领导者必须简化决策、果断行动，并敢于挑战既有规范，而不是继续在旧流程上做局部优化。
Capital One 云平台、韧性工程与企业架构高级副总裁 Parvez Naqvi 则进一步解释了这些组织变化如何重塑工程师角色本身。随着 AI 让实现速度大幅提升，工程的价值会越来越集中到那些 AI 还无法独立完成的判断之上。软件交付的主要约束，逐渐从纯粹编码转向规划、架构设计和工程判断。
那些围绕人工编写代码而形成的传统 review 流程，在 AI 大幅提高开发速度后会逐渐失效。资深工程师的杠杆作用，越来越来自于定义技术方向和确立架构模式。他们也会更加深度参与系统设计，并为工程师和 AI agents 提供足够上下文，使后者能做出更好的决策。
图 5：围绕数据工程师角色变化的 CTO Circle 圆桌讨论
这种演进也抬高了 developer platforms 和工程基础设施的重要性。内部工具和部署系统之所以会成为战略资产，是因为它们能减少运营负担，让团队把注意力集中在设计高韧性系统上，而不是反复处理重复性劳动。随着越来越多的产品经理、设计师和领域专家开始直接参与软件创建，工程组织会越来越像质量、架构与运营卓越的守门人，而不再只是唯一的代码生产者。
CodeRabbit CEO Harjot Gill 分享了 AI 如何从根本上改变开发者体验。随着 AI 接手更多实现工作，工程师花在把想法翻译成代码上的时间会减少，而更多精力会放在定义意图、评估权衡和塑造系统设计上。AI-assisted reviews 则帮助工程团队在不牺牲正确性、安全性和可维护性的前提下跟上节奏。
Cursor COO Jordan Topoleski 关注的是代码生成之后的环节。随着 AI 大幅提升开发速度，code review、验证以及工程质量维护，会成为新的瓶颈。他的观点再次强化了一个结论：能成功规模化的组织，会构建更强的反馈回路和工程系统，确保 AI 生成的软件真正做好进入生产的准备。
图 6：CTO Circle 圆桌讨论现场
把这些讨论放在一起看，可以看到一个更宏观的转型方向。AI-native engineering 的核心，不在于谁最快使用了某个工具，而在于一个组织能多快学习、沉淀并制度化更好的软件构建方式。走得最快的公司，将是那些持续重构自身工程组织，以吸收每一次 AI 进步的公司。
展望未来：塑造下一阶段的关键对话
整场活动中的讨论反映出，行业已经远远走出了“试试看”的实验阶段。尽管每一家组织都处在不同转型阶段，但它们面对的挑战却惊人相似。与会者的反馈也进一步强化了我们对 CTO Circle 的判断：工程领导者非常珍惜与面临类似决策的同行进行坦诚交流的机会。这个活动真正有价值的地方，就在于它提供了一个很难在别处获得的 candid conversation 空间。
Snowflake 跨行业的独特视角，使我们能够把那些面临相似挑战的组织聚集起来，从而构建一个可信赖的经验交流场，而不是只展示经过修饰的成功故事。
AI-native engineering 的 playbook 仍在书写中。随着模型持续进步、工程实践也不断演变，这些经验只会变得越来越重要。我们也将继续分享来自工程领导者构建 AI-native 组织过程中的实践经验，其中也包括对 Snowflake 自身转型更深入的拆解。如果这些讨论和你所在组织面对的挑战高度相关，我们也邀请你继续关注我们后续的内容，一起探索下一代工程组织究竟应该如何构建。
点击链接立即报名注册：Ascent-Snowflake Platform Training-China 更多 Snowflake 精彩活动请关注专区
