跨国深谈← 返回←从传统科技公司到 AI 原生：Maven Clinic 的转型实录

从传统科技公司到 AI 原生：Maven Clinic 的转型实录

关联

人物 Dan Feng

公司 Maven Clinic

概念 AI 原生公司 · AI 编程工具 · 代码审查 · 幻觉 · 招聘 · 迭代周期

这一集来自一场现场演讲，主角是 Maven Clinic(一家专注于孕产、生育、育儿、更年期的大型数字健康平台)的 Dan。他讲的主题是：一家传统科技公司，如何在两年内转型成一家「AI 原生」公司。

开场他先给听众泼了盆冷水：AI 已经在这里、每天都在进步，采用它不是可选项——即使你选择不用，你的竞争对手也会用。他引用了一个说法：就像拖拉机想取代农民，但真正会发生的是，会操作拖拉机的农民取代不会操作的农民。

他先承认：AI 原生没有单一定义，更没有一套照着做就能「叮」一声变身的操作手册。对他们来说，它归结为三件事。

三件事：内部用 AI、产品装 AI、改文化

第一件，内部能用 AI 就用 AI。可以简单到生成每日摘要、管理会议、创建 Jira 任务——任何今天需要手动做的事，都应该想一想能不能用 AI 做；任何想让别人替你做的事，先想想能不能用 AI 做。他透露，如今 Maven 包括 CIO 在内的很多领导者，都自己用 AI 解决这类任务，而不是委派给别人。

第二件，把 AI 构建进产品，目标有两个：改善用户体验、降低运营成本。最典型的例子是 AI 聊天机器人——24/7 全天候可用、即时响应客户，比人工客服又好又便宜。

第三件(他认为最重要)，改文化、改流程、改工作方式，让 AI 的价值最大化。

落地策略：抓中间的大多数

推广新技术时总是有三类人。早期采用者不用管太多，只要给他们开好工具，鼓励他们把学到的东西分享给全公司。

真正要下功夫的是中间的大多数：为他们建共享基础设施、做好用的工具、让采用过程尽量无缝，并且持续倾听反馈、持续改进。一个实例是：去年 Maven 大部分人用 Cursor,今年很多人切换到了另一款 AI 编程工具——他们两个都支持，「在他们所在之处与之相会」。

【背景】原文此处提及的新工具为 Claude Code(Anthropic 出品的编程助手)。

对少数慢的采用者，也要理解他们的顾虑，但更重要的是：清楚地告诉他们公司要往哪走。

AI 擅长执行，所以改招聘和考核

核心逻辑：只要知道要做什么，AI 真的很擅长执行——所以要改的是招聘和奖励的方式。

过去的工作模式是：资深工程师感知问题、想出方案，分派给其他工程师实现，以此并行提速。但现在资深工程师不愿意把实现分派出去了——因为方案想清楚后，用 AI 立刻就能做完，分派给人反而开销更大、效率更低。

这带来两个推论：新人的门槛变了，你必须能独立解决问题，公司已经无法承担「别人给你分派实现任务」的模式；同时，招人时要找真正对 AI 感兴趣的人(领域变化太快，需要他们持续学习、带着团队不掉队)。另一层是：有了 AI,工程师能做的远超从前，PM 和工程师的边界在模糊——真正理解产品的工程师，贡献可以远大于只懂软件的传统工程师；对系统的深刻理解、处理复杂模糊问题的能力，也变得更有价值，因为那正是 AI 的短板。

考核也在变：绩效评估里开始问「你在 AI 方面做了什么」，并且明确奖励那些用 AI 倍增自己影响力的人。

重新切规划周期：季度规划死了

传统流程是花几周甚至几个月充实需求、敲定设计、再做实现——因为实现贵，开头做错后面改起来代价高。但事实是，任何大项目他们从来就没在一开始做对过。现在有了 AI,构建快到几分钟就能完成，论证才是贵的那个——所以要重新设计工作方式：

• 一年期的目标照样可以想，大胆梦想，但只当它是激励和方向。
• 真正聚焦的是未来两到四周要交付什么：PM 和设计师说清这个迭代周期要做什么，工程师专注实现，周期结束时(甚至更早)发布。
• PM 利用同期时间去充实下一批需求。如果迭代中发现之前定的方向错了，完全没问题——换挡，快速修正。
• 文档也变了：不再写一页又一页的 PRD 或技术设计文档，只写一两页的短文档，它的作用就是沟通、供迭代。

最尴尬的是三个月、六个月的中期目标：现在很难规划，因为你不知道三个月后 AI 模型会有什么能力。他承认，这对习惯了季度规划的老兵最难适应——但适应新时代就是我们的职责。

软件开发：从低风险任务建立信心

AI 编程工具可能是最成功的 AI 应用，但不必一步到位。Maven 的路径是：从风险最低的任务起步——写单元测试和文档(极易验证、风险极低)——借此建立信心；然后构建自己的规则、技能和护栏；再推广到整个工程师团队，要求所有任务都用 AI 编程工具；有人不用时，正是要去了解「为什么」的时候。此刻，他们几乎所有的实现都用 AI 编程工具完成，工程师真正专注的是审查、架构设计和评估。

写代码快了，代码审查就成了瓶颈：以前一个好工程师每天写几百行以内，现在轻松上千行——照老办法审查根本跟不上。他们试了多款 AI 审查工具，有点帮助，但还不敢 100% 依赖，工程师的反馈仍然非常有价值。所以他们改了审查制度：

• 允许工程师自行判断这个 PR 还需不需要人审——觉得足够简单、有信心，可以直接合并，但责任照旧由他担。
• 想要人审的，守最佳实践：每个 PR 不超过 500 行，因为没人能对几千行的代码做出有意义的审查。
• 启用堆叠式 PR:大功能拆成多个 PR,别人在审的同时你可以继续往下写。

最要避免的是「橡皮图章」——提交了代码审查，你什么也做不了，只能盲目批准确认。那是最坏的情况，只会给人虚假的信心：以为审过了、没问题，就发布了。

同时他们继续投入 AI 代码审查工具，因为认为那才是未来。最终目标：AI 自动化从设计、实现到发布的端到端全生命周期，甚至监控线上流量、及早发现问题并自动修复——还在路上。

可靠性：幻觉消不干净，就分层处理

传统软件只做你实现的东西，不多不少；但生成式 AI 有幻觉，不能忽视，可完全消除的成本非常高，有时也没必要。正确做法是从一开始就有一个整体方案。

第一步是区分哪些失败可豁免、哪些不可：帮客户预约日程，一千次失败一次大概没关系(不是好体验，但用户再点一次按钮就行)；但帮用户提交报销申请就零容忍——申请 200 美元发了 50 美元、或反过来，每一单都会立刻引发升级投诉。对不可豁免的场景加额外关卡：收到收据后用不同的模型审查同一张收据，只有结果彼此一致才继续往下走；实在判断不了哪个对，就坦然告诉客户「我处理遇到困难，要不要转人工？」——这完全可以接受。

发布端同样严格：几百个集成测试覆盖所有已知用例并持续追加；因为模型可能做出不同行为，每个测试用例要跑很多次、持续要求高通过率(比如始终保持 90%)。上线后还有自动演化系统按预定义的评分标准逐条评估每次对话，另有一个专门的团队人工抽查对话，用来判断系统要不要改进、评分标准是太严还是太松。

新功能上线时，抽查不够，会人工审查约 20% 的对话。这整套流程让他们有信心：尽管知道幻觉存在，但重大事故不会溜出去。

本集带走

• 转型没有现成手册，但有框架：内部能用 AI 就用 AI、把 AI 装进产品(体验+成本)、再改文化流程放大收益。
• 推广抓中间的大多数：给早期采用者开工具让他们分享；给中间层建共享基础设施和易用工具；对慢的采用者，关键是讲清公司要往哪走。
• AI 擅长执行 → 招聘和考核跟着变：新人必须能独立解决问题；优先招真正对 AI 感兴趣、懂产品、能处理模糊问题的人；绩效里直接问「你在 AI 上做了什么」。
• 规划周期重切：一年目标只当方向，聚焦两到四周的迭代；文档只写一两页供沟通迭代；中期(3-6 个月)规划基本放弃，因为预测不了模型能力。
• 从低风险任务起步：先让 AI 写单测和文档建立信心，再建规则和护栏，最后全量推开。
• 代码审查制度重构:PR 不超 500 行、允许自信的工程师免审合并但责任自负、大功能拆堆叠式 PR,坚决避免「橡皮图章」式假审查。
• 可靠性分层：区分可豁免与不可豁免的失败；高风险场景用多模型交叉验证 + 转人工兜底；测试多轮跑、上线后自动评估 + 人工抽查(新功能审 20%)。

我认为采用它不是可选的。即使你选择不采用，你的竞争对手也会采用。
I think adopting it is not optional. Even if you choose not to, your competitors will do.
—— Dan Feng · [01:21]

但事实上，对于任何一个大项目，我们从来就没有在一开始就把它做对过。
But in fact, we never get the same thing right at the beginning anyway for any of our big projects.
—— Dan Feng · [07:30]

你只是盲目地说，批准。这是我们真正应该避免的最坏情况，因为那只会给我们虚假的信心。
You just say, blindly prove it. This is the worst case we should really avoid, because that just gives us false confidence.
—— Dan Feng · [12:40]

我们发现真正理解产品的工程师，事实上，他们的贡献可以远大于只专注于软件侧的传统工程师。
We found engineers who really understand the product, in fact, they can have way more contribution than the traditional engineer who only focus on software side.
—— Dan Feng · [06:06]