Jon Hyman 是客户互动平台 Braze 的联合创始人兼 CTO，在这家公司已深耕近 15 年。近日他在 Stack Overflow 播客节目 Leaders of Code 中与 Jody Bailey 对谈，讲述如何将一家初创公司打造成全球领先平台，以及如何在短短数月内完成团队向 AI 优先的转型。
从移动时代到 AI 时代：技术 leadership 的两次跨越
Jon 表示，创业至今的近 15 年几乎相当于科技行业的一整代。他经历了移动互联网的崛起——企业进入移动领域后，用户期待随时随地互动，实时性成为基本要求。正是这段经历塑造了他的工程领导观：技术负责人必须深入理解系统如何扩展、产品如何运转。 而如今，AI 正在以同样深刻的方式重塑业务。他透露自己正在亲力亲为地推出各类 AI 代理（agents），并能与最优秀的工程师就 AI 驱动的流水线、自动化和工作流改造展开深入对话。这种技术敏锐度，是他保持领导力的根基。
亲临一线：不做"五角大楼"里的将军
Jon 将自己的领导风格称为"在地上作战的将军"：
"我不在 Pentagon 里坐等指令。我和团队并肩作战，能够真切感知运营挑战、新功能或新产品线中的复杂性，帮助团队共同规模化。"
在他看来，无论是移动时代还是 AI 时代，这种"躬身入局"的态度始终关键。只有真正懂得技术细节，才能在对话中保持可信度，才能真正激励团队。
组织进化：从"工程师池"到事业部制
Braze 的组织架构经历了多次演变。早期和许多初创一样，所有工程师同处一个"池子"中，产品经理和设计师也如此。Jon 将当时的优先级协调形容为一道"数独题"：需要前端工程师、后端工程师、产品经理和设计师同时腾出档期，才能凑齐一个项目所需资源。
随着规模扩大，他们逐步演进为：
- 专业分组：前端 / 后端分离
- 团队制：围绕产品空间组建团队
- 事业部制：工程经理 → 产品空间总监 → 副总裁 → CTO，形成层级化的复杂性管理模式
这一演进路径说明：工程管理者越往上升，越需要驾驭更高层次的复杂度，同时引领超出日常运营范畴的工作流。
部门负责人例会：目标、架构与产品策略
Braze 的部门负责人每周都会召开例会，这些会议承担着多重职责：目标设定、架构与设计审核&查验，以及为业务大方向制定愿景。
在会议上，Myers 会与各部门负责人深入探讨几个核心问题：他们应该构建什么、如何思考各自的产品领域？是需要改善某个产品线的健康度，还是推动功能采用，或是为已有功能探索商业化路径？最终都要回答一个根本问题——公司在市场上的竞争力究竟如何。
领导者也需要「钻到草丛里」
Myers 提到，有时领导者必须亲自深入技术细节，才能判断团队的运作效率。他举例说，在与工程师讨论工期估算时，这种做法尤为有效。很多时候团队对问题的思考过于宏大，反而「只见树木不见森林」。此时领导者可以提出质疑：「这个方案似乎不太合理，为什么不能那样做？」 更有力的方式是亲自做原型演示。Myers 认为，这样做能帮助团队突破瓶颈、看清前进方向，随后由部门负责人接手推进。
AI 在原型开发中的角色
当被问及是否利用 AI 加速原型开发时，Myers 给出了肯定答案。他形容 AI 的发展速度令人惊叹：
- 第一阶段：代码自动补全（如 JetBrains IDE、GitHub Copilot）
- 第二阶段：AI 扮演初级软件工程师，能在指导下完成部分任务
- 第三阶段：AI 成长为高级软件工程师，无需过多引导
- 当前探索：基于触发条件自动构建——例如收到 Bug 报告后自动提交 Pull Request 修复，或在测试失败时自动修复
Myers 表示，这些自动化场景才刚开始探索，「还处于非常早期的阶段」。
三个月完成工程转型
Braze 成立至今已有 15 年，但在最近三个月里，工程实践经历了彻底重塑。Myers 透露，这一转变的契机来自 2025 年 2 月 Claude Code 的发布。他回忆当晚与妻子吃饭时仍兴奋地不断谈论这个工具，还把截图发给联合创始人和 CEO，感叹「真不敢相信 AI 现在能做到这个程度」。
此后两个月，Braze 开始系统性地为团队配置各类 AI 编码工具：Cursor 许可证、为需要的人强化 GitHub Copilot 并引入自动化代码审核&查验、通过 AWS Bedrock 提供 Claude Code 访问权限，同时组织 AI 午餐学习会来推动全公司范围内的 AI 采用。
MCP 服务器：AI 赋能工程的转折点
真正的转折点发生在 2025 年 8 月。当时 Braze 需要在客户大会前发布一组 AI 功能，其中之一是 MCP 服务器。Myers 决定以此作为试验：安排两名工程师完全使用 AI 来构建这个全新的 MCP 服务器，结果比原计划提前了约六周完成。
这一案例让 Myers 真正意识到：AI 将为团队效率带来「阶梯式的提升」。
从怀疑到全面拥抱：60% 代码由 AI 生成
在 Opus 4.5 之前，很多人对 AI 并不看好。有人在社交媒体上说新模型"效率提升 30%、40%"，但 Myers 自己的日常体验并非如此——部分模型表现差强人意，修修补补的时间反而更多。团队内部调研也反映了类似情况：工程师们觉得 AI 有时带来的工作量大于节省的工作量，大家因此不愿意上手，因为"不知道今天掷出的骰子是省时还是费时"。
转折点出现在 8 月。当一个项目取得成功后，情况开始变化。团队逐渐意识到 AI 可以融入更多工作流程，于是开始主动推动更广泛的采用。
模型能力的分水岭
11 月 Opus 4.5 发布，这是一个关键转折点。之前 Myers 给团队的是"需要一定指导才能良好运作"的模型，而 Opus 4.5 是他使用过的第一个"几乎不需要方向纠正就能快速、正确地构建有意义功能"的模型。从那之后，团队对 AI 输出的接受度就像野火一样蔓延开来。上周他看了一下数据：超过 60% 提交到主仓库的代码是由 AI 编写的。
随着越来越多人看到同事使用 AI 并获得实际成果，这个飞轮越转越大。现在他需要在基础设施层面为 AI 提供更多支持。
文化关卡：如何说服怀疑者
这一过程中最大的挑战，Myers 观察是文化层面的。一开始团队里不乏质疑者——不只是观望的人，而是完全不信的人。怎样才能真正说服他们？
答案是：模型质量在短时间内的大幅提升，以及实际效果的验证。
Myers 尝试了工程团队常用的推广方式：举办午餐学习会、做演示分享、安排专人帮助大家上手、推广效果好的案例。这种自下而上的方式在工程团队中很有效——工程师喜欢自己动手折腾，也喜欢了解别人在做什么。当他们看到有趣的东西，自然会说"我也要"。
但真正推动普及的，还是模型本身变得足够好，好到管理层可以提高对团队的预期。回到半年前，大家都在谈论 AI，但连 Myers 自己都没看到实际效果。现在他自己看到了，就会对团队提出要求：线上出现 bug 报告时，他会直接问工程师经理"这个让 Claude 来处理一下行不行"；客户提出功能需求时，他会想"这个用提示词写出来让 AI 生成应该可以"。
当领导者自己看到可能性，就能用更高的标准去要求团队产出和效率。这种要求层层传递，最终带动了更多 adoption。这个过程完全是自我强化的——越多人看到 AI 为自己工作，就越愿意去用它。
收购 OfferFit：不同文化的磨合
Braze 完成了一笔收购——收购了 OfferFit。这家公司是营销软件领域非常出色的强化学习引擎。整合至今效果很好，团队和产品都让 Myers 印象深刻。
把两个组织整合在一起必然面临挑战。OfferFit 是 100% 远程公司，而 Braze 更接近混合模式——全球 15 个办公室，希望员工能够到办公室参与活动、在周中协作。这种后疫情时代的差异需要磨合。但整体而言，两家公司文化契合度很高，都崇尚开放、直接、创新，领导风格也互补。他们正在努力融合两种工作方式。
小团队带来大改变：收购后的工程整合策略
Braze 在收购 Linear 时，团队规模差距显著——Braze 约有 1800 名员工，而 Linear 仅有 150~170 人。作为一家非上市公司，Linear 决策速度更快、试错成本更低，拥有大量值得借鉴的工具与工作流。
整合的核心思路是双向流动：一方面将 Linear 中经过验证的优秀实践引入 Braze，例如将代码审核&查验工具 Graphite 推广至整个组织；另一方面帮助 Linear 团队尽快融入 Braze 的流程体系。Braze 将 Linear 的工程团队设为一个独立产品线，与现有其他事业部并行运作——统一的汇报结构、相同的流程标准，确保整合过程中"全员一队"的感知清晰可追溯。
衡量 AI 落地的三条"Warp Stream"
Braze 将 AI 的应用演进划分为三条并行轨道： 第一轨：赋能 + 意识普及 让全公司员工接触 AI 工具、了解优秀用例、鼓励广泛采纳。效果可见于个人效率提升——工程师写代码更快、客户成功团队用 AI 整理会议纪要和邮件。但 Myers 坦承，这种自下而上的优化不足以驱动公司质变：即便全员效率提升 20%，也无法直接转化为 20% 的增长或利润改善。
第二轨：AI 作为"同事"而非辅助工具 部门层面开始将 AI 视为真正的协作者，而不只是建议生成器。例如：上传一份文档，AI 直接返回经过处理、可交付的输出结果——而非仅仅给出反馈意见。目前 Braze 在部分业务领域已推进到这一阶段。
第三轨：自动化流水线（仍处早期） 目标是让 AI 完成端到端任务闭环，典型场景包括：由 AI 自动生成 Bug 报告并录入 Jira 系统、根据 Jira Epic 自动生成代码等。Myers 表示，"现在每个人都在努力构建这套自动化能力，我们仍处于把武器库充实起来、让机器运转顺畅的阶段。" 工程侧进展最快，原因在于可量化：代码产出速度、合并周期、集成进度都有客观指标可循。这也让回顾复盘有据可依——哪些环节顺利、哪些需要调整，清晰可见。
第三支柱：业务指标与成本效益
前两个支柱解决的是「能不能用」和「用得好不好」的问题，而第三个支柱直指核心——AI 能否真正影响公司的营收和利润。
上市与客服：降本增效的经典路径
在 go-to-market（上市）层面，最直接的指标是缩短新销售（Account Executive）的上手时间。每缩短一天，都能在财务预测中转化为更多收入。这是可以量化优化的方向：能否用 AI 压缩新销售的培训周期？
客服场景同样清晰——降低客服成本、提升处理效率，或者更进一步：通过产品设计从源头减少工单产生。这些都是有明确财务意义的关键指标。
工程侧的成本困境
然而在工程侧，情况要复杂得多。Myers 透露了一个严峻的事实：AI 推理的成本远高于预期。
他分享了一个细节：曾在 Braze 工作，以前最佳投资就是坐飞机——长途飞行中专注写代码，下飞机后直接提交代码。但最近一次从东京返回的长途飞行中，他坦言：「我不想再独自编程了，我需要网络连接来使用 AI 代理。」工作方式已经彻底改变。
更值得警惕的是成本数字——
某位工程师在 3 月第一个工作日已花费 150 美元的推理费用。 线性推算：每月约 4,500 美元仅用于 token 消耗。 若团队有 300 名工程师，这笔成本将是天文数字。
效率与产出的衡量难题
关键问题随之浮现：如何衡量 AI 代理的生产力？ Myers 提出了一个犀利的问题——我们从未真正解决如何衡量开发者的生产力，凭什么认为能衡量 AI 代理？两者本质上是同一个难题。只不过 AI 带来了新的变量：每次任务完成都有明确的美元标价。
这让审视变得前所未有的直观：「这个产出值这 150 美元吗？」 但现实是，这是一场预算冲击。几个月前的预算周期中，没人预见到推理成本会如此之高。当 AI 工具承诺巨大生产力提升时，账单也随之暴涨，企业必须重新调整财务预期。
vibe coding 的成本天花板
Myers 还提出了一个值得深思的判断：高推理成本将逐步侵蚀「vibe coding」（凭感觉自行开发软件）这一论断的基础。
vibe coding 成立的前提是推理成本足够低——理想中「像电费一样便宜」。但现实是，OpenAI 为建设数据中心已投入千亿美元，推理并不廉价。当管理者看到「团队每天烧掉 150 美元」，他们会问：与其让资源消耗在这里，不如直接购买成熟软件？ 这一成本认知一旦普及，企业内部开发的逻辑将发生根本性转变——不是所有问题都值得自己造轮子，核心业务才是重心。
竞争加剧：所有人都提速，不等于技术奇点
即便 AI 让每位工程师的产出等效增长 80%，企业也不会因此集体冲进"技术奇点"、一口气把所有路线图全部实现。原因是竞争对手也在同步提速——当 100 名工程师的产出等效变成 180 名时，所有人都在加速推进各自的产品路线图，赛跑依然激烈。
这意味着 AI 带来的效率提升是全局性的：它让所有公司同时跑得更快，但没有人能靠它甩开对手。最终形成的局面是：竞争门槛整体抬高，而不是某一家公司独占优势。
被忽视的代价：代码维护与长期技术债务
当前公共讨论中缺少的，恰恰是对这种全局加速的代价分析。业界普遍低估了以下几个层面的影响：
- 持续维护成本：AI 生成代码涌入代码库后，未来谁来维护、谁来解决随之而来的技术债务？
- 二阶效应：当 AI 快速帮你实现某个功能时，市场上同类产品的迭代速度也在同步提升，你只是在追赶而非拉开差距。
- 竞争动态：如果竞品已经可以用"氛围编程"（vibe coding）在两周内完成某个功能，你花三个月认真开发完，反而要面对一个已经过时的市场。
这些权衡（trade-offs）和竞争压力，才是工程团队在实际组织中正在真切应对的难题。
快不等于有用：产品价值的核心问题
速度提升之后，更核心的问题才浮出水面：你能快速构建，但它是否是客户真正需要的？ 路线图（roadmap）的意义在这里被重新审视。可以把产品做得更好、更快，但如果最终成果对客户没有实际价值，效率本身就是浪费。对于 AI 在产品管理层带来的变化，Myers 指出了三个值得关注的落地场景：
- 产品经理和设计师能够自助完成过去必须依赖工程师的小型任务，如页面间距调整、布局优化这类 UX 债务（UX debt）修复；
- 产品经理借助 Vercel 和 Cursor 实现快速原型搭建，以交互式 Mock-up 替代传统 Figma 原型，实现更快的内部沟通与客户对齐；
- 开发进度可以适度超前于设计：由于修改用户界面的成本大幅降低，工程团队可以在设计师完善交互流程的同时同步推进，提前交付给愿意接受略不完美体验的 Beta 客户。
这三个场景反映出一个共同趋势：AI 正在模糊设计与工程之间的传统边界，让产品迭代从线性走向并行。
AI 提速不裁员：竞争格局下的工程团队增长逻辑
Myers 指出，AI 确实让团队"做得更多、做得更快"，但这并非意味着可以大幅削减工程师人数。相反，在竞争激烈的市场中，企业拥有远比人力能覆盖的更庞大的产品路线图。
以 Braze 为例，团队手握 100 个优秀想法，过去受限于人力只能实现其中 20 个。AI 加持后，同等团队规模可以推进 40 个——但剩下 60 个依然存在，且竞争压力不会消失。因此，"我们远未达到工程团队人数的峰值"。
这一现象印证了一个关键判断：AI 实际上在刺激更多的软件需求——人们想构建的东西变多了，而非更少。
"Vibe Coding" 无法规模化
快速构建原型与真正支撑高复杂度、高吞吐的生产级系统，是两件性质截然不同的事。Myers 直言：
"你可以用 vibe coding 产出大量代码，但要在高复杂度、高规模、高使用量的场景下稳定运行，需要的是对你所构建内容的深刻理解——包括要解决的业务问题，以及所有系统如何协同工作。"
以 Braze 的工程负责人为例，其大脑中拥有的上下文远超大模型：代码、业务流程、业务系统、客户面临的挑战、客户使用产品的具体场景。这种跨系统、跨角色的领域知识，是当前百万级 token 上下文窗口也无法容纳的。
组织知识如何转译给 AI
将散布在个人大脑和组织各处的隐性知识转化为 AI 可用的形式，是当下真实的挑战。Braze 正在尝试的做法是将工作方式与最佳实践编码成文，典型案例包括：
- 前端 React 编码规范
- 各类测试的编写预期（Cypress 端到端测试 vs 单元测试的边界）
- 框架使用规范
然而，这条路并非坦途。当前许多团队存在工具割裂、标准不一、流程缺失的问题——不同工具承载着不同的技能集合，部分团队甚至在忍受不完整的能力带来的低效。这种混乱的状态会转化为更高的返工成本、更慢的交付速度和更高的运营支出。
Myers 认为，真正需要的解决方案是：将人类脑海中的知识系统转录为标准化的工作流程，而非零散地丢给 AI 去猜。
Braze 技术负责人谈 AI 开发实践：2026 年工作流变革展望
在近期一期 Leaders of Code 播客中，Stack Overflow B2B 编辑 Eira May 与 Braze 技术负责人 Jody Bailey 展开对话，探讨 AI 对软件开发工作流的深层影响。
实验优先，标准化稍后
Jody Bailey 表示，Braze 内部推行 AI 开发时采用"实验优先"策略——允许团队自由探索，不必拘泥于统一规范。但他也指出这条路存在明显边界：当成员彼此依赖时，缺乏共识的代码结构会导致重复造轮子。他预判，随着时间推移，团队会逐步意识到需要建立共享的 AI 开发标准，否则前端测试等基础设施将被反复重建。
AI 代理工作流需要专属基础设施
Jody Bailey 将 AI 代理（Agentic）工作流与持续集成、容器化等基础设施相提并论。他表示，Braze 预计在 2026 年出现专门负责 AI 代理工作流的新型团队，其职责类似于如今的 CI 团队——负责构建、测试和维护 AI 驱动的开发环境。这类专职团队的出现，意味着一套标准化、可复用的 AI 开发基础设施将正式纳入工程体系。
从"我能要求个人做什么"转向"我能要求团队整体做什么"
对话中一个关键转变在于心态：从关注个人开发者能用 AI 完成什么，转向关注整个团队如何借助 AI 协作完成任务。例如，AI 可以帮助编写测试、进行竞品调研——这意味着过去因资源限制而不得不"走捷径"的环节，如今可以被系统性替代。
Jody Bailey 预测，未来每个团队都将配备 7×24 小时运行的 AI 代理：它们自动响应 Bug 报告、处理产品疑问、参与路线图规划。工程师睡一觉醒来，新功能可能已经完成初版。
行动建议：先动手，别光看
针对想要入局 AI 开发的团队或个人，Jody Bailey 给出几条具体建议：
- 并行启动多个 AI 代理：让它们分别处理不同功能模块，观察协作效果；
- 把 AI 应用放到手机主屏：将第一反应从"打开 Google 搜索"替换为"打开 AI 工具"；
- 亲自动手尝试：他提到自己即将进入陪产假，但计划利用这段时间亲自体验 OpenClaw 等 AI 平台，保持对工具变化的敏感度。
Jody Bailey 总结道：参与 AI 开发的门槛不在于知识储备，而在于你是否愿意亲手去试。只要开始动手，就能在工具快速迭代的阶段及时调整自己的软件开发流程（SDLC）和团队预期。
评论