走进 CTO 圆桌：构建 AI 原生组织的工程领导者经验分享 | 技术趋势

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 生成的