开场0:00
There's something there.
我最近呢经常和各种人去讨论 "AI 时代的组织形式 " 这件事情 ，因为我觉得组织形式在 AI 时代的重要性其实现在仍然是被大大低估的 。
甚至于中长期来看 ， 组织形式很可能就是新一代的创业公司和传统公司相比最大的竞争优势跟壁垒 。 因为传统的大厂现在最大的问题就是分工实在是太细了 ， 分工如果太细 ， 就说明这个团队里面缺少核心的人对模型的掌控和对最终产品的输出结果来负责 。
但反而是创业公司 ， 几个人就能做很多端到端的事情 ，他们更理解模型能力的边界 ， 更理解哪些用户需求是可以用模型的哪些能力来达到的 。
所以呢前段时间我们就请到了在湾区创业的一个好朋友 ， 讲了讲他们是怎么打造 AI Native 的工程团队的 。他们做了很多有意思的事情 ，在后面的他的分享里都会讲到 ， 比如说他们现在 90% 的代码都是 AI 写的 ， 比如说他们现在可能有 20 人左右的团队 ，但里面是没有任何一个 PM 的 ， 全都是工程团队在做所有的事情 。
我觉得这期的分享是非常有价值的 ， 所以我们非常快地就把这一期剪了出来 ， 然后希望能让更多的国内的创业者跟做 AI 的人听到 。
因为我觉得大家呢应该能从这期播客里面得到很多启发 ， 就是湾区最先进甚至于说有点激进的组织管理形式到底是怎么样的 ，他们是如何利用 AI 的 ，他们是怎么处理团队跟 AI 之间的关系的 。
所以后面这部分呢 ， 首先是他个人的一个完整的分享 ， 然后后面呢会接一些我们当时活动现场的问答 ， 我觉得都非常的精彩 。
我叫任川 ， 来自 Palona AI， 之前在 Google 和 LinkedIn 都做过几年 。 我们公司的主要业务是做 Restaurant AI， 就是说用 AI 来帮助餐饮行业提效 。
我们第一个产品呢其实就是帮餐馆接电话 ，因为在美国还稍微有点落后， 没有美团呀 ， 国内现在打的这么热闹 ， 这些先进的东西就有人订 Pizza 呀 ， 还有很多人打电话 。
然后呢这边接电话的人可能每个小时， 你要雇人的话也要至少 25 美金 。 所以说我们的产品可以 end-to-end， 你的电话完全不用响了 ， 我们可以 take 预约 ，take order， 普通的咨询都是可以做到的 。
然后我们的主要的价值在于我们是 AI agent 里面少数可以做到 95% 到 98% 可靠性的公司 。 大部分现在 AI agent 产品 ， 它的可靠性一般可能在 70% 左右已经很不错了 。
但对于我们来说呢 ， 我们这个是非常实用 ， 你可以完全放心 ， 就是不用再用人来管这个电话了 。
当然这个具体我其实在别的地方有一个纯技术方面的分享 ， 我们是怎么做到的 。 但是今天呢咱们就不讨论这些技术问题 ，而是稍微聊一下在这个背后我们这个团队是什么样的 。
我们的这个题目呢是如何打造 AI Native 的工程团队 ， 然后今天主要分三个部分 。 第一个部分呢讲我们的 AI Native 的工作流 ， 就是一些比较实际的 ， 我们公司是怎么利用 AI 工具做研发工作的 。
第二部分呢就是讲讲人， 我们觉得 AI Native 时代需要什么样的人才 。 第三部分呢讲讲组织 ， 就在 AI 时代 AI Native 的组织应该是什么样的 。
那咱们就先进入第一部分 ， 重构工作流来提升识别效率 。 嗯 ， 这个识别效率其实是一个虚数了 ， 我自己的感觉呢应该是远不止识别效率 。
AI工作流3:47
我可以稍微举一个例子 ，在我们公司研发工作大概是什么样的 ，其中有一个环节叫做代码审查 CodeReview。CodeReview 这个过程呢在 Google 平均的需要的时间差不多是一到两天 。Google 作为古典的这个互联网科技公司 ， 它的工程效率已经是非常非常优化了 ， 那这个时间在我们公司是 10 分钟 。
这个 10 分钟和一到两天相比 ， 肯定是提升了不止 10 倍 。 那我们怎么做到 10 分钟 CodeReview 这个事呢 ， 这个也非常简单 ， 就是我们只让 AI 来 review。
我们公司去年 4 月份成立的 ， 大概到六七月份的时候 ， 我们就开始用这个 AI 的 CodeReview。 我们用的一个工具叫做 CodeRabbit AI，在当时是为数不多的做 CodeReview 的工具 ， 现在已经有挺多的了 ，但是我们还是继续用这个 CodeRabbit AI， 我们用下来觉得还是最合适的 。
那即便它是同类产品里面最好 ，但实际上还是有很多问题 ， 比如说 AI 虽然 review 了之后， 哎 ， 觉得这个 code okay，checking 了 ， 出了问题怎么办呢 ， 这个道理也特别简单 。
因为我们可以做到 10 分钟的 CodeReview，code 就可以进这个生产环境 。 那这 10 分钟如果在生产环境中发现问题 ， 一可以直接把这个 code roll back or revert， 就是说把它给撤回 ， 或者呢你可以直接在线上就把它给 fix 掉 。
这件事如果大家有经验的话 ， 听起来是稍微有点危险 ， 或者稍微有点不符合传统的 。 啊 ，但是在传统的开发流程中， 如果每一次 review 都需要一到两天 ， 那你这个事是不可能实现的 。
但是如果每一次只要 10 分钟就可以 fix 的话 ， 实际上这个 work 是可以实现的 。 我们从差不多今年年初开始 ， 已经不要求人来 review code 了 ， 啊 ， 只要 AI approve 了 ， 我们就可以直接把 code merge。
所以试用下来半年多 ， 效率非常高 ，而且这个效果也是非常好的 。 然后 CodeReview 只是其中一个例子 ， 啊 ， 通过这个例子呢 ， 我想分享总共这个工作流里面的几个原则吧 ， 或者几个经验 。
第一个呢就是我们默认由 AI 承担所有研发工作 。 注意我这里面写的是研发工作 ，而不只是 coding 的工作 。 研发整个流程呢 ， 从比如说写文档 ， 到写各种 task， 到写设计文档 ， 然后到写代码 ， 到 CodeReview， 到最后上线之后， 还需要做这种监控 。
所以 AI 不仅仅单单只是在 coding 的部分有价值 。 那因为这个公司创建的比较新 ， 大概去年 4 月份成立 ， 所以我们第一个想法就是 ， 我们能不能让 AI 把这个全流程都干了 。
但实际上现在的情况 ，AI 的能力是肯定达不到的 。 但是呢我们把这块做一个逻辑的转换 ， 哪个地方 AI 还做不到 ， 我们用人去来帮它弥补 。
但是这个时候 ， 人需要有一个非常充分的理由 ，而不是说人来默认完成这个工作 ， 哎 ， 觉得 AI 好的时候再去让 AI 来做 。
这样子我们发现了非常多的部分可以由 AI 来直接承担工作的 。 我稍微举几个工具 ， 大家如果有兴趣可以试用 。
第一个我们在 coding 的时候用的一个工具叫做 Linear。Linear 其实是 track 我们的整个工作的 ，Linear 加 Devin。Devin 的话是一个 coding 的工具 ，也是一个华人团队做出来的 。
它的效果就是说 ， 我每次创建一个 Linear 的 task 之后， 你只要 assign 给 Devin，Devin 会自动创建代码 。其实这整个过程你连 IDE 都没有打开 ， 连你的代码工具都没有打开 ， 啊 ， 你可以同时创建 10 个 task， 然后就产生 10 个代码 。
所以这个是和人的研发工作是完全不一样的 。 然后呢我们在这个生产环境中做监控的时候 ， 用一个工具叫做 incident.io。
它的工作呢就是说 ， 它把所有的 log，不管你的 log 可能是在 AWS 上面 ， 或者在 Datadog 上面 ， 把这些 log 全都收集起来 ， 它自动的分析这些 log， 给你提醒 ， 啊 ， 甚至出 incident 之后给你一些分析 。
那这个呢其实大概能够 cover 我们 40% 到 50% 的工作 ， 还不像 coding 那么完善 。 但是其实已经我们公司是没有 SRE 的 ， 就是没有运维的人员 ， 完全靠一半的工程师 ， 一半 incident.io。
大概我们的研发工作流是这样 ， 哈 ， 所以这是第一个经验啊 ， 尽量让 AI 承担所有的工作 。 第二一个经验就是 ， 特别是在 coding 方面了 ， 要用 Claude Code。
这个有点尴尬 ，因为我在准备的这个时候还是推荐 Claude Code 的 ，但是上周好像 Anthropic 把国内给封了 ，不让用了 。
但是我们自己用下来 ，Claude Code 还是最好用的 。 有几点原因吧 ， 一个原因就是它本身的能力也是非常强的 ，因为毕竟 Anthropic 对这个模型肯定是最理解的 。
第二一个呢就是 Claude Code 本身是有 SDK 的 ， 我们可以在上面做非常多的二次开发 ，而且不要被这个 Claude Code 这个 code 部分这个名字给影响了 ， 它做的绝对不只是 coding 的工作 。
那我这块第二个经验呢 ， 就是只要有 SOP， 就没有 Claude Code 没法完成任务 。 这句话其实不是我说的 ， 实际上是 Claude Code 全球第一人说的 。
这个人是谁呢 ， 叫做刘小排 。他是一个华人的创业者 ， 然后他前一段时间比较有名 ， 就是因为 Anthropic 发现有一个 ，其实就是刘小排了 ，他每个月花 200 块钱买 The Mescaleros，但是他 token 消耗量要达到 5 万美金 ，他基本上 7 成 24 小时在用这个 Claude 的 API。他自己有一个公众号 ， 就叫刘小排 ， 非常推荐大家去学习一下 Claude Code 是怎么使用 ，因为发现这个远远不只是做 coding 的工作 。
这是第二点经验吧 。 然后第三点经验就是 ， 你看我们默认让 AI 承担大部分工作 ， 然后呢人来去补充这些 AI 做不了的事情 。
那人自己的工作有一个什么经验 ， 或者有一个什么原则呢 ， 就是尽量一个人独立 end-to-end 把这个工作完成 ， 减少人和人之间的交互 。
这件事其实在各个公司都有一些反直觉 ，因为我们老觉得开会啊 ， 拉通对齐 ， 这个是工作里面非常重要的一个内容 。
但是当你的工作流变得 AI Native 之后， 你会非常明显的发现 ， 人和人之间的交流一下子都会非常容易变成平价 。
然后我们的原则就是尽量减少人和人之间的冷烂 。 如果要冷烂 ， 就是比如说这个研发工作 ， 把你的想法 ， 把你的原则也好 ， 冷烂到 codebase 里面 ， 大家自动的就人和人也好 ， 人和 AI 也好 ， 就烂了 。
但是说到这儿呢 ， 那这个工作方式和之前传统的工程团队是有点不一样的 。 那需要什么样人才呢 ， 咱们进到第二部分 ， 就说在未来呢 ， 成为 AI 工程师 ， 或者在 AI 的工程团队最需要的人才是什么样的 。
那这里边呢 ， 我差不多根据我们这个经验总结了三点 。 第一个呢叫做 Context Provider， 这件事其实在大多数地方应该很少有人提到 。
人才新标准10:51
从我们自己的感觉来讲 ， 一定要转变一个思路 ， 就是说不要把 AI 只当成工具 ， 好像 AI 工具给人提效十倍也好 ， 五十倍也好 ，其实并不是这样 。
它真正的价值是人给 AI 提供 context， 或者说人为 AI 提效 。 我们有一个原则就是人加上 AI 之后， 它的产出要大于 AI 本身 。
这个看起来好像是显而易见的 ，但是呢仅仅是我们这个一年多的经验 ，有很多的时候人加入以后， 实际上会让这个 AI 的效率变差 ， 或者让整个的团队效率变差 ， 这个是挺常见的事情 。
那其实前一段时间有一个非常流行的概念叫做 Context Engineering， 它的概念是什么呢 ， 就是我们现在的底层模型能力已经非常强了 ， 之所以 agent， 或者之所以你的 AI 工作流不 work， 更多的是因为上下文工程的失败 ， 或者说你的 context 没有提供对 ，并不是因为模型本身的问题 。
作为我们 AI 的团队来讲 ，其实是一样的 ， 我们 AI 并不是说它的能力不行 ，不够聪明 ，而是说它没有拿到足够的 context。
所以 Context Provider 在这里面不但在工程上有价值 ， 同时呢比如说产品 ， 比如说像我们做餐饮行业 ， 我们有一个团队的成员 ，他是在暑期经常在餐馆里面端盘子 ， 这些餐饮整个流程 ， 这些 context 实际上是对模型非常非常重要的 。
但这些东西可能是模型本身并没有的知识 ， 啊 ， 所以人的特别重要的价值叫做 Context Provider， 这是第一点 。 第二点呢叫做 Fast Learner， 就快速学习 。
那这里面的快速学习并不是指说遇到一个问题 ， 我能够非常快的学习 ， 然后学的比 Mondo 还强 ， 啊 ， 这个已经再也不可能了 。
我是不是这么觉得 ， 就是人已经不可能比 AI 更聪明了 ， 啊 ， 这块的 Fast Learner 其实指的是你快速学习 ， 掌握最少必要知识 ， 然后能够跟 AI 沟通 。在我们团队呢 ， 包括面试也好 ， 包括平时工作也好 ，有一个特别重要的事 ， 就是说我们不太在乎其他的团队成员这件事会不会 ， 我们只在乎这个目标 ， 这个问题定义的是不是清楚 。
只要定义清楚 ， 我们认为它就应该是能够解决的 。 当然了 ， 实际解决起来肯定会碰到非常多困难 ，但是我们对每个人的要求都是 ，不要去看你现在有什么 skill，而是要看你能快速学习 ， 然后把 AI 的这部分的潜力激发出来 ， 这是最重要的 ， 啊 ， 所以第二点是 Fast Learner。
第三一点呢叫做 Head of Builder， 就是说每个人都要是一个 Builder。 一个 Builder 的概念呢指的是说 ，在整个工作里面 ， 你要对最终的那个结果负责 ， 要对全流程负责 。
你负责这个可能是整个大的产品的一小部分 ，但是呢你也要对最终的结果负责 。 那我们可能有一些岗位 ， 比如说他只是做前期的整理工作 ， 或者做前期的研究工作 ，但是如果他不能够对最后的结果负责的话 ， 就会产生一个问题 ，其实是我们刚才讲的 ， 就会有一个人和人之间 context sharing， 或者说要分享这个上下文 ， 或者分享这些知识的过程 。
只要有人和人之间分享的过程 ， 一下子就会拉低整个 AI Native 团队的效率 。 这是第二部分 ， 就是说 AI Engineer 需要的三个主要技能 。
然后第三个部分呢就稍微更虚一点 ， 讲到这个组织的形式 ， 刚才稍微也 cover 了一点的哈 ， 就是说第一条 ， 我们希望整个组织每个人按结果分工 ，而不是按流程分工 。
组织新范式14:25
每个人为结果负责 ，而不是为中间流程的某一部分负责 。 按结果分工的话是什么意思呢 ， 比如说我有一个小团队 ，他只对商家最终的体验负责 ， 我们内部叫 business experience。
另一个小团队 ，他为消费者最终的 experience 负责 ， 叫做 consumer experience。 实际上 experience 团队 ，他的工作内容前端的会多一些 ，但是呢我们不分成说有前端团队 ，有后端团队 ， 你就是为 experience 负责 。
如果 backend 里面有哪些影响了最后前端的效果 ， 那你就直接去改 ，不需要再去找到 backend 团队 ， 再找到 research 团队 ， 或者再找到运维团队去改这个事 ， 你自己就去改 ， 啊 ， 没有任何问题 。
这个按结果分工实际上不但是工程团队 ， 我们的工程师甚至会去参与产品 ， 包括设计 ， 包括 go to market 的 。
因为我就举一个例子 ， 作为 business experience 来说 ，其实就是这些我们餐饮行业每一个老板的最终的体验 。 那我非常鼓励我们的工程师直接去找老板面谈 ， 这个东西用的好不好 ，有什么需求 。
那这个反馈流程呢 ， 如果搁在传统的团队 ， 那就得这个老板可能找到销售 ， 到时候再把这个情况反馈给 PM，是吧 ，PM 可能再把这个情况反馈给工程团队 ， 工程团队再说这个做不了 。
可能就是整个这个链条下来已经完全走样了 ，但是我们现在就鼓励工程团队直接去见客户 ， 那他们也会直接收到一手的反馈 。
对 ， 这是第一点 。 那第二一点呢 ， 就是我们整个团队基本上是以工程团队为中间的核心 ，因为工程团队是最容易为结果负责的 。
那工程团队呢 ， 目标只完成前 60%， 最多到 80% 的工作 。 这些工作包括研发工作 ，也包括产品和设计的工作 。 比如说我们现在就要上新一功能 ， 工程团队第一时间不会去找设计师 ，不会去找 PM，而是直接就用各种各样的设计工具 ， 先把这个 60 分的东西做出来 ， 先上线再说 ， 叫做 velocity first， 速度优先 。
那其他团队 ， 比如说我们也有专业的设计师 ，是在这个 60 分的基础上做优化 ， 把它做到 80 分 、90 分 ， 甚至 100 分 。
这么做的好处就是因为在过去我们可能会开很多会 ， 所有人一起来拉通对齐 ， 然后呢拿到一个特别完善的设计 ， 然后再开始工作 。
这件事在过去是成立的 ，因为过去来说 ，不管是 coding 也好 ， 研发也好 ， 这个成本比较高 ， 我们不可能说先做一版觉得不行 ， 哎 ， 再做一版 。
那就工程团队肯定就非常抓狂了 。 之前科技行业流行一句话叫做 "Talk is cheap, show me the code"， 要展示代码 。
但现在的话 ，Talk is cheap，但是 code 其实是 cheaper。 现在生成 code 已经是非常容易那事了 ， 所以我们完全可以先做一个 60 分的东西 ， 然后大家在这个 60 分的基础上面做一些 align 也好呀 ， 做一些对接也好 ， 再在这个基础上去优化 。
那基本上我们工程团队这件事也是做得非常好 。 这也是我们为什么能在短短一年的时间把一个非常复杂的系统做起来 。
这是第二一点 。 第三一点呢 ， 就更虚一点了 ， 这个是我们公司也正在尝试吧 ，也是有一个朋友 ，他在知乎上也挺活跃的 ， 前一段分享一篇文章 ， 就说未来的组织可能会变成很少量的合伙人和大量的合同工 。
原因就是说 ，因为你也看到刚才说每个人都是按结果分工 ， 为结果负责 ， 那每个人的价值其实是非常高 ， 整个公司对他的依赖其实也是非常强的 。
那有一个风险就是 ， 如果这个人离职了 ， 或者说如果这个人想要做自己的公司了 ， 那对公司的影响其实是会挺大的 。
但是在原来的 ， 比如在 Google、Meta 这种传统的互联网公司 ， 管理团队的时候有一个特别重要的一点 ， 就是每一个位置上都一定要有 backup。
但是在新的 AI Native 团队 ， 可能这件事已经很困难了 ， 所以未来的基地方式可能也需要变化 。 那就是说这些全职的核心的人， 一定要有这种类似合伙人的待遇 ， 这个待遇要高于普通的全职员工 。
但是呢 ， 你肯定不可能整个团队就只靠这些合伙人了 ，因为这个成本是会比较高的 。 但同时就会需要一些比较灵活的合同工 ， 这些合同工呢 ，他会在某一个行业 ， 或者说某一个领域非常的有经验 ， 那对他自己来说 ，他也不愿意把自己的能力完全 full time 的卖给其中一个组织 。他把自己的能力卖给多个组织 ，其实对他也是一个更好的方式 。
这一点呢 ， 我们也是在探索吧 ， 可以稍微跟大家分享一点一些 ， 听一听大家的想法 。 那差不多这个分享就到这 。
无PM团队19:26
听起来非常有意思啊 ， 我觉得比我想的还要易懂一点 ， 就是非技术的我也完全能听得懂 。 然后也还是我先快速问几个问题 ， 然后把时间交给大家 。
我觉得第一个问题就是我好奇的点 ， 那 PM 在你们内部到底是一个什么角色 ，他现在是在怎么工作呢 ？
简单说就是我们没有全职的 PM， 基本上就是 Engineer 兼职做 PM 了 。 我们现在团队差不多 20 个人啊 ， 我其实不太知道 ， 比如我们团队可能找到 50 个人， 甚至到 100 个人来说需不需要全职 PM。
但是我们自己跑下来 ， 至少在这个小的规模的时候 ， 还是并没有特别需要一个全职的 PM。
对 ， 我感觉湾区那边其实都是在几十个人之后， 可能才会进来全职的 PM， 对吧 ？ 你看 Code.ai 也是很后面才给招的 PM， 然后 Cursor 我知道也是很后面其实才有的 PM， 或者说那边还有个职位是类似于产品设计师的角色 ， 对吧 ？
就是他可能有的时候就先招一个产品设计师 ， 然后再兼任一些 PM 的工作 。
是的 ， 或者这么说 ，其实对于创业公司来说 ，CEO 或者说像 Head of Engineer 其实很重要的就直接做 PM 的工作了 ，也是为了在这个决策流程要少一环吧 ， 比如从客户直接到 Engineer， 比中间加一层 PM 这个效率会高一些 。
对 ，但你看就是按照传统定义里面 ，Engineer 应该是特别擅长写代码 ， 然后呢 ，Engineer 一般大家印象都是比较内向 ，不善于与人沟通 ，但 PM 呢 ， 应该是说他要非常了解用户需求 ， 非常善于沟通 ，以及体验总结那些要点 。
那如果你把这些职责放在 Engineer 上 ，是不是对 Engineer 的要求就变得特别高 ？ 那这样的 Engineer 多不多 ， 好不好招呢 ？
明白 ， 第一 ， 这样的 Engineer 肯定不太好招 ， 特别是不光是要有产品能力 ， 现在对 AI 能够快速学习 ， 纯能够把 AI 这套工具用好的 Engineer 也不多 。
但问题是这个可能在未来是必须的了 。 就我们现在的 AI Software Engineer 这个岗位 ，并不是说只有 Engineer 能做 。其实我也认识一个朋友 ，他原来是 PM， 可能没有学过 Coding，但是呢 ， 现在用各种 AI Coding 的 tool 非常厉害 ， 就可以 build 出来自己的一个产品 。
就是我们最终的目的并不是说一定要区分他到底是 PM 还是 Engineer， 只要他能为自己最后 build 的这个东西 ， 对这个结果负责 ，其实都是可以的 。
对 ， 我刚才就在想说 ，因为你自己是技术背景 ， 所以呢 ， 你们很自然的以 Engineer 作为主体来做这件事情 ， 会不会未来比如说 AI Coding 更发达了 ， 然后有公司反而过来讲说我们没有 Engineer， 我们所有人都是 PM？
没错没错 ， 或者以后可能不讲 Engineer， 大家就都是 Builder。
对 ，但这里又衍生出来一个问题 ， 你看分工其实是工业社会的一个产物嘛 ， 就理论上来说 ， 分工越细说明这个链条配合的越好 ， 效率越高 。
那当下呢 ，是因为 AI 出来 ， 所以在一个比较早期的阶段 ， 那可能重构了整个的组织跟产业链 ，但你觉得未来会不会又变成又开始分工 ， 又有不同的分工体系 ， 又变得更细 ， 还是说就是你觉得现在这个模式是最高效最 work 的 ？
我肯定不敢说现在这个模式最高效的 ，但是我觉得肯定会和之前不一样 。 未来可能会有分工 ，但不会像之前这种工业时代或者说互联网时代的分工了 。
原因也很简单 ， 之前的话还是按流程的分工 ， 就是我们在这个流程中每一个环节派不同的人， 对吧 ， 不同的角色把这个事情做好 。
那 AI Native 我觉得最重要的一个思维的转变就是 ， 整个这个流程应该是以 AI 为主的 ，不是以人为主的 。AI 可能最后能做 95%、98% 的事 ， 人只是在那些最后这个 AI 实在做不了的地方做一些补充 。
那这种分工到底是什么岗位呢 ，其实确实不太好讲 ，但是我觉得会跟之前是不一样的 ， 这个是比较确定 。
明白 ， 然后我还有两个问题啊 ， 第一个问题是说 ， 你们现在实际上用你现在这个模式跟组织架构 ， 你们的一天到底是怎么样的 ， 能不能给大家大概讲一下 ？
我们首先把会议只集中在中间的三到四个小时 ，其他时间我们都尽量没有任何会议 ， 所有人自己做自己的事情 。
你像我刚才讲的 Code Review 的事哈 ， 我们基本上每个人每天可能就有三四个 ， 甚至四五个这种 Code Request，因为整个过程中他完全自己写 Code， 然后让 AI review，AI review 完了之后自己 merge， 所以这个效率非常非常快 。
所以说这个一天可能每个人看起来跟平时工作只是会少了一些 ，Coding 的工作多了一些 ，但是呢 ， 实际的这个效率还是差别挺大的 。
明白 ， 然后我最后一个问题啊 ， 就是在你看来 ， 你刚才讲这套东西在湾区它已经是一个很明确的趋势 ， 甚至于说很多人已经在这么做了 ， 还是你们哪怕在湾区也是比较先锋的 ，在探索的一个角色 ？
我们算是比较先锋 ，但是不能算小众 ， 肯定还不是最 aggressive 的 。 但是我觉得在 startup 里面可能不是完全一样的模式 ，但是大家这个思路还是都是往这个方向去的 。
好 ， 哎 ， 虞快还在吗 ？ 我再 call back 一下， 虞快有什么 ？
在我在 。
对对对 ， 你听起来感觉怎么样 ？ 然后你们内部现在是怎么做这件事情呢 ？
我觉得跟我们挺像 ， 我们其实到目前为止公司也已经大概 150 个人了 ， 可能有两个 PM 吧 ， 公司在最早期其实就是没有 PM 的 ， 我觉得很正常 。
因为我的感觉是这样 ，有的时候你不是说 Engineer 没有办法 make 这些决定啊 ， 就是你越是跟他说 ， 哎 ，有一个 PM， 很多明明应该他自己可以下的决定 ，他就把这个难的问题交给别人了 。
我觉得这个是非常不好的 ， 这个 ownership 就没有了 。 经常比如说遇到后面开会就说 ，OK， 这个是一个 business decision， 那我就不 make 了 ， 这个是 PM 的 。
好 ， 那 PM 要 make 这个 decision，其实他又要来找这个 Engineer， 对吧 ， 说 OK， 那你这些 data 现在有没有 ， 对吧 ， 就说那又增加了很多的沟通 。
最后其实这个 decision 呢 ，也很多时候就是 Engineer 和 PM 一起 make 的 。 我不觉得在早期需要这么多 back and forth， 我的感觉就是你让一个很聪明的 、 解决问题能力很强的一个人去做决定 ，他是可以做出很好的决定的 ， 没有道理说他只能 make 好的 engineering decision，但不能够 make 好的 business decision。
OK， 好 ， 谢谢 。 对 ， 我觉得我们今天在听的人可能见证了一个新的时代的组织形式的变革跟产生的过程吧 。
对 ， 然后把时间交给大家 ， 看看大家有什么问题 。 我要问任川 。
大厂转型25:54
哎 ， 我可以先问个问题吗 ？
哎 。
我之前就是在一个大厂上班的 ， 我觉得您刚刚说的这种方式 ，在十几个人 、 二十几个人是完全没有问题的 ， 或者说这种规模的公司就得这么搞 ，他没有那么多人。
但是比如说之前在抖音 ， 一个组一个小业务 ，其实很多人那为什么大公司不效仿这种东西 ？ 他们自己内部有很多的编程工具 ，但为什么所有东西还是按照一条线 ， 从用户调研到产品设计 ， 需求到研发到测试 ， 整个一条线来做 ？
有没有想过 ， 比如说你们这种方案只能在初创阶段的时候能做 ，在很大的规模情况下其实很难行得通 ？
嗯 ， 明白 。 我就只说一些我的想法啊 ，因为我们其实也就是试了一年多 ， 未来大厂会什么样其实也都很难预测 。
你可能说大厂规模大了之后， 这套方式不 work 了 ， 完全有可能 。 我肯定是对未来这个预测没有那么确定的 。
但是我自己的想法啊 ， 为什么大厂不做这个事呢 ？ 我自己也在 Google 工作过一段时间 ， 这个对大厂来讲 ， 它这个转型有非常多技术也好 ， 或者说效率之外的考量 。
今天微软的 CEO 已经出来道歉了 ， 觉得他们之前裁人裁得太猛了 ， 然后需要重拾员工的信心 ， 对吧 ？
就这些事呢 ， 跟 Engineer 或者工程研发没有什么关系 ，他可能因为某一些的原因 ，他没有办法做到像这种效率这么高 。
那在 Google 呢 ， 据我所知有一些很内部的小的团队 ， 实际上也是类似的这种做法 。 但是如果大到 Google 整体上来讲 ，他如果做这种转型还是非常非常困难的 。
这是第一点哈 。 第二点就是我自己感觉 ， 未来可能再也不需要那么大的公司了 。 大家看现在不管是之前明星公司 Cursor， 或者现在的各种创业公司 ， 甚至都在讨论有没有这种一人独角兽公司 ， 就是说一个人几个人的团队能做的事情已经非常难以置信了 。
所以未来会不会还需要像 Google 有 10 万人的公司来做这么一个产品 ， 实际上我是比较怀疑的 。 我自己的一点判断吧 。
对 ， 我觉得这个问题很有意思 ， 就是我们最近聊了很多创业公司 ， 然后我觉得里面是少数的在思考新的时代的组织形式 。
然后我们现在的体感是 ，也许在中短期内 ， 创业公司真的壁垒就是在组织形式上 。 就大公司你要让它转是很难的 ， 就它里面要做非常多的动作 ， 才很多人在重新 reorg 这个组织 。
但创业公司可能就是能抓到这点机会 ， 然后把做 evaluation 的人提上来 ， 让他做更多的负责的东西 ，以及就是刚才讲的每个人都是 Builder， 能更多的端到端去负责一些事情吧 。
好 ， 然后下个问题 。
好 ， 我第二个问题啊 ， 就是说对研发而言 ， 整个代码其实迭代可能大几年， 有的都有十年了 。 你用 AI 去做这块的可行性到底有多大 ？
就比如说有些代码很复杂的逻辑 ， 各种比如说端上 、 旋转 、 重力跟设备系统很相关的东西 ， 连我自己看了几年这块代码 ， 我自己都理不清楚了 ， 怎么让 AI 来帮我写这块需求 ？
我的这个问题其实还是感觉 AI Coding 这块更适用于我所有东西我都从 0 到 1 的 ，但你比如说从 1 到 100， 从 10 到 100， 我自己都理不明白 ， 东西我觉得他更理不明白 。
嗯 ， 这个问题特别好 ， 跟我刚才讲的一点是比较相关的 。 这时候就特别需要 AI 工程师 ， 或者需要人的参与了 。
那人最重要的价值就叫做 Context Provider， 就像你刚才说的 ， 过去多少年的经验 ， 我相信任何一个大模型现在都没有这些知识 ，也很难让它学会 。
那这时候就需要人来为它提供这个 Context。 那你提供的 Context 的准确程度 ， 你提供的 Context 这个性造比 ， 都会直接影响 AI Coding 也好 ，AI Agent 也好 ， 它最终的效果 。
那这件事不是模型的能力达不到 ，而是我们给 AI 或者给模型提供的 Context 不够好 。 那我觉得一方面呢 ， 我们可以等模型变得更强 ， 就是说你的 Context 不够好也能 work，但是这个的成本会很高了 ， 到时候 GPT-6 啊什么这个出的就越来越慢了 。
那另一方面呢 ， 现在有很多公司在研究我们怎么能把这个 Context 提供得更好 。 同时我觉得作为我们个人， 我们也可以想一想怎么样能给 AI 提供更好的 Context， 这个会变成未来这个 AI 工程师一个特别核心的价值和技能 。
嗯 ， 好 ， 明白 。 那就是你 PPT 上面写的就是人加 AI 大于 AI， 对吧 ？
对 ， 就是这个意思 。
好 ， 谢谢 。
好 ， 下一个问题 。 我想问问 ， 除了 Coding 以外， 您觉得 AI 在哪些你们工作中是比较好使的一些场景 ？
招聘方法30:37
其实刚才说到这儿 ， 就是说对研发团队来说 ， 每一个步骤其实 AI 都会有非常大的帮助 。 第二一个的话 ， 我们现在发现 ，也是我最近看得比较多的 ， 就是 Go to Market。
过去整个销售流程也跟研发流程是非常长 ， 从最开始的 SDR 到最后 Account Manager 到最后 Customer Success， 就是中间整个流程一个客户可能要接触四五个人。
那现在有了 AI 之后， 这个流程也被大大的压缩 ， 可能一个人就直接从 end to end 都可以解决了 。 现在特别多的硅谷这边的公司 ， 就是在做 Go to Market 方面的自动化 ， 你也可以研究研究 。
我觉得这个地方也是大有可为的 。
好 ， 下一个问题 。
我想请问一下， 您在打造这样的一个 AI Native 团队的时候呢 ，是不是有从传统团队里面转过来 ， 还是说从一开始就是用这种工作模式去打造的团队 ？
以及说你在打造的过程中有遇到什么困难 ， 怎么去解决 ？
这个我们比较幸运的一点就是我们公司比较新 ， 我们没有这些历史包袱 ， 所以我们从去年 4 月份创立到差不多 6、7 月份开始做这套东西 ， 都是以一种全新的 AI Native 的方式来做的 。
当时也有一个比较现实的问题了 ， 就是说这个人不够 ， 你人不够的话肯定要想办法 。 然后有很多人确实是不适应的 ， 特别是有些 Senior，他比如说在 Google 做了七八年了 ， 这套东西已经做得非常熟了 ，他可能用 VM 已经是个专家了 ， 用 Emacs 都是专家了 ，他连 Cursor 都不愿意用 。
这是我们也能见到过这种情况 。 所以我自己的感觉 ， 经验在这个时代不是很重要 ，而且很多时候这个经验会变成负担 。
当然我们的这个数据量比较少啊 ， 我们其实发现最适应这个时代的还是一些比较年轻的刚毕业的人， 同时他们有特别强的这个学习能力和欲望 ， 就是他们可能在读书的过程中就已经离不开 ChatGPT 了 ， 已经离不开 AI 了 。
所以他出来拿这个工作非常的自然 。 这样的人确实不好招 ，但是我觉得还是会越来越多 ， 大家把这个方式转变过来之后 。
好 ， 下一个问题 。
我想问就是在找人的时候 ， 你是怎么找到这样比较会使用 AI 的人 ？
我们有两个方式 。 第一个方式就是我们不做这种一个小时面对面这种面试 ， 我们直接给一个问题 ，take home， 你回家做 。
这个问题或者这个项目很大 ， 你没有 AI 肯定是做不完的 。 就给你比如两天的时间 ， 你要给我 build 一个什么 Product，build 完之后呢 ， 回来我们就半个小时聊一下， 你告诉我你大概是怎么做的 。
同时你能知道说他确实是两天时间把这东西做出来了 ，他一定是 AI 工具用得好 ， 否则的话他如果是手写的 ， 那更是大牛 。
第二一个 ，他也不能只是轮 AI 把东西做出来 ， 里面内容完全不了解 ，他要有一个过程 ， 比如说我最开始用了什么办法 ， 这块不太 work， 哎 ， 我又怎么调整了一下这个 Prompt 也好 ， 我又怎么调整一下我的 Instruction， 它才弄得 work 了 ， 要问一下这些过程或者这些细节的地方 。
我们这么做下来还是效果比较好吧 。 我们其实这种一个小时的面对面的面试 ，也在尝试一些新的办法 ， 还没有特别的 ready， 就是说这一个小时我们把一个现成的 、 写好的一个大型的 Project 给到你 。
但是这个 Project 它里面有各种各样的问题 ， 埋了很多的雷 ，因为它是一个新的 Project， 你只能靠 AI 去迅速理解 。
你要人看的话 ， 你一个小时肯定啥也干不了 。 所以这个时候我们就需要说你用 AI 这个 Tool， 它能不能一个小时把这个 Project 做改进 。
我们也在尝试这种方式 。
嗯 ， 然后我看虞快也刚需要补充是吧 ？
是有问题想要问 Kevin。
就是我觉得 take home 的问题就是一个人的 Background 如果很强 ， 然后你跟他说这个 take home 你会 take 比如说 8 个小时 、10 个小时， 你怎么让人家愿意来做你这个 take home 呢 ？
嗯 ， 这个其实也是一个筛选的过程 。 我们基本上发下去之后， 可能有十分之一会做的 ， 确实会这样 。
我觉得就是你要让别人对你感兴趣 ， 最后你可以 sell 嘛 。 就是说他可能通过你的面试过程什么觉得很有意思 ，他有可能最后会 join 的呀 ，但一上来如果他面试过程都不开始 ，他会不会就被这个给吓跑 ？
比如说你有没有遇到过情况就看这个人背景很强 ， 你觉得他是个 good fit，但是呢 ，他不愿意做这个 take home， 你会不会就 fast track， 你会 OK， 那行吧 ， 就你直接来我们公司面 ， 你会这样子 make exception 吗 ？
方太简历基本不可能 ， 可是如果有 refer 的话 ， 会考虑这种情况 。 但是呢 ， 说到底这个最终是一个效率的问题 ，有没有可能没有做 take home 就跑了 ，但是一个特别好的候选人有可能 。
但是呢 ， 我们肯定是看综合的效率 ， 最终能不能招到这个合适的人。
嗯 ， 这个问题我分享一下我的经验 ， 就是我们日常在所有的这个岗位都是使用 take home 这样的招聘方式的 。
但是我们在给人家 take home 这个任务之前 ， 我们会先聊一下， 我觉得这个人是否有比较高的这个可能性 。
如果说他有比较高的可能性的话 ， 这个 take home 会给一个大概市场价格 30% 的这个报酬给到他 。 就比如说我们招一个产品经理 ， 我们日常的这种用户调研 ， 然后去设计产品方案 ， 再到数据买点的这个设计 ， 就是一整套全流程 ， 我们都需要他去做完 。
但是可能正常情况下 ，他如果做完这一套可能要 5,000 块钱 ，但是我们会告诉他 ， 你把这个任务做完之后， 我们给你 1,500 块钱 。
这样的话其实让候选人他不会觉得 ， 哎 ， 你是为了白嫖我 ， 我们也可以看到最后他这个 take home 的质量 。
Makes sense。
感谢分享 。
OK， 然后下个问题 。
就是想问一下， 你们用 AI 做 Code Review 的时候 ， 会用一些常见的可量化指标 ， 比如说命中率啊 、 误报率或者是一些这样的东西 。
代码审查36:15
那如果效果不好的话 ， 你们怎么调整呢 ？
第一 ， 我们基本不用这种指标 ，因为一个是这个也挺难量化的现在 。 第二一个 ， 我们主要看我们工程师的主观感受 。
因为什么呢 ， 这个 Code Review 说到底 ， 当人给人 review 的时候 ， 你感觉他是在叨嗑 ，但是我们用 AI 给人 review 之后， 有个特别神奇的效果 ， 就是人会特别感谢这个 AI 帮他挑这个问题 。
因为最终这个代码进到 Production 以后， 如果出了问题 ， 只有这个写代码的人负责 。 所以说如果 AI 帮他把这个错误再提前改好的话 ，其实人会很开心的 。
所以说我们更多的是大家相互 share， 觉得哪个 AI Review 的 Tool 是最有用的 ， 最能帮你提升你自己代码质量 。其实还是挺明显的 ， 就是我们用下来像那个 VS Code 的 Copilot 都不太好 ，Cursor、BugBot 也不是特别好 ，有时候就会瞎说啊什么的 。
所以我们倒不是用一个指标去衡量这个事的 ， 看工程师的感受 。
好 ， 下一个问题 。 我再追问一下 ，在你们 AI Code 的过程中， 你们会去 review 这个需求的逻辑吗 ？ 还是只是评审一些 ， 包括一些 bug 或者一些安全漏洞之类的 ， 或者代码规范 ？
需求的逻辑指的是什么 ？ 就是产品需求的逻辑 。
就是你这个 Code 里面有没有把产品的需求完整实现啊 ， 或者是这类的问题 。
哦 ， 这个是这样 ，有两种情况 。 如果说你的 Code 是比较偏 ， 比如说实现一个新的功能 、 新的 feature， 那可能会有 。
比如说你新的一个 Service， 这个 Service 具体是干什么的 ， 它的输入是什么 ， 输出是什么 ， 它要满足 123 这几个功能 。
那这个我们都会在我们 Python 这个 init 文件里面把这个写好 ， 这些东西也会给到模型 。 所以模型也会知道 ， 哦 ， 你想实现这么一二三四个功能 ， 那发现你的 Code 并没有实现 ， 那它就会提出来这些问题 。
但如果说你这个 Code 只是比如说改 bug， 或者说改其中某一个模块的一个小功能 ， 它离最终的需求有点远 ， 那模型可能就不会了 。
说到底就是 Context， 如果说有这个需求的 Context， 那模型也是会考虑进来做 review 的 。
明白 。 呃 ， 另外一个问题 ， 就是你们一个 Project 里面多少是 AI 生成的 ， 怎么去统计 AI 生成的这个代码量 ？
我估计至少 90% 了 。 我们就是默认 AI 写代码 ， 人在必要的时候再去改 。
好 ， 下一个问题 。
我这边有一个问题想问一下， 一个公司啊 ， 从 10 个人 、50 个人或 100 个人， 咱们具体实践下来 ， 都包含哪些角色 ， 相互怎么配合 ， 然后不同的发展阶段又是应该是增加哪些角色 ？
我不敢说 50 人 、100 人的面 ， 我也没有这个经验 。 我自己觉得这个分工就有一个原则 ， 刚才虞快也说了 ， 按结果分工 。
按结果分工的意思呢 ， 就是说我们每个人来也都是解决问题 。 最终我们人和人之间有个 Line 的 ， 就是说我们到底要解决的是什么问题 ， 或者说我们的目标是什么 。
只要把这个 Line 清楚 ， 那咱们就分好 ， 你解决这个 ， 我解决那个 。 具体怎么解决 ， 这个过程 ， 这个手段 ，不去分工 ，不去限制 ， 让每个人自己去发挥 。
当然了 ， 要利用 AI。 你说到 100 个人或者 50 个人之后， 会产生什么岗位 ， 这个我真不太好预测 。 一会儿虞快说说你们现在 150 个人了 ，是什么岗位 ？
我感觉我们公司渐渐变大了之后， 开始多招一些这种 Security 的一些人， 然后招一些 QA 的人 、Testing 的人。 然后之前的话 ， 一上来大家就是每个人负责一个 feature， 然后后面的话渐渐的 ，OK， 那我们这个 Scalability 怎么办 ，Developer Experience 怎么办 。
所以接下来 Platform Team 就开始出现了 ，Platform Engineer 也开始变多了 。 这是我的感受 。
好 ， 看还有问题吗 ？
哎 ， 你好 ， 我问一下， 听您讲第一 part 的 ， 就是你们很信任 AI Coding 的一个很大的因素 ，是因为它迭代足够快 ， 比如说它 Review 每次只要 10 分钟 。
我想问的是 ， 就算我们认为它足够快 ，但 10 分钟之内仍然会可能产生一个 P0 或 P1 级别的事故 ， 就是对于这种你们一开始时候会区分业务吗 ？
比如说核心业务其实 AI Coding 会比较少 。 然后第二个是 ， 假设这种级别更高的业务在 AI Coding 上， 怎么能避免这种事故的发生 ？
然后第三个就是我想说 ，其实除了 Fix Bug 之外， 某一次我们可能还会带来其他 ， 比如说 Database 的一些脏数据 ， 甚至一些用户补偿 ， 这部分也是 AI 来做吗 ？
还是说其实人为的干预会更多 ？
刚才说的那个第一部分 ， 第一点 ，并不是说我们无脑所有东西都用 AI 做 ，而是一个思路的转变 。 我先假设 AI 可以做 ， 那如果 AI 一做发现问题了不行 ， 我们肯定还是让人来做 。
这个区别在于可能现在我们是先 follow 传统的工作流 ， 什么东西都让人来做 。 我发现某个地方 AI 能奇效 ， 我再让 AI 去做 ， 这样会 miss 掉很多的机会 。
所以这是一个 principle 的不同 ，而不是说我们真的什么都要用 AI 做 。 第二个就是你刚才说的 ， 比如说 Infrastructure 的东西 ， 我们其实 AI 做的会少一些 ，但实际上比大多数公司也要多很多了 。
比如说我们整个的 Infrastructure 都是以 IaC 的形式存在 Repo 里的 ， 所以 AI 也会生成对应的代码 ，但是呢 ， 我们可能就会 on-call， 会看得多一些 。
但是产品方面 ， 特别是前端的代码 ， 那可能就看得少一些 ， 就直接上线了 ， 发现问题再改都可以 。 但是 AI 已经进入我们这个工作流了 ， 如果 AI 未来 work 得越来越好 ， 那我们可能人就自然而然的 review 得越来越少了 。
好 ， 我们要不最后一个吧 。
激励人才42:06
哎 ， 你好 ， 这边有一个提问 ， 就是在我们对 AI Engineer 的招聘过程当中 ，其实我们会遇到一些问题 。 当我们想要去吸引一些 BG 好 ， 然后综合能力出众的这些同学的时候 ，他们往往会更倾向于说 ， 哎 ， 我刚毕业 ， 凭什么来你这初创 ， 对吧 ， 我要去大厂 。
然后遇到那些比较 Senior 的 Engineer，他们可能会不太适应新的 AI Engineer 的工程习惯 。在这样的情况下， 比如说我们在招聘 ， 或者说在人才培养上， 我们需要去一个是通过哪些渠道去找到这些合适的人选 ， 另外一个是我们需要关心这些人的什么样的特质 。
如果说想要去做一些有差异化的激励 ， 那我们应该怎么样做 ？
这个也是我前面分享第三部分最后一点 。 像刚才说的 ， 可能慢慢的就不能把人当全职员工了 ，而要当合伙人， 这是一个吧 。
第二一个其实是我一个创业朋友的观察 ， 就是说与其招人， 不如提升自己 。 就是与其招这样的合伙人， 不如先看看能不能你真的几个合伙人， 采用这种方式来提效 。
因为有可能你用好了这个 AI 工具之后， 不需要多花更多的精力 ， 可能就把要招的人那个工作给 cover 了 。 这是很有可能的 。
我有一些朋友创业啊 ， 可能刚开始就两三个人， 有点忙不过来了 ， 就招人。 招来人发现比之前还忙 ， 这都是有可能发生的 。
所以我觉得可能招人之前想一想 ， 能不能现有团队就把这个效率提升了 ， 可能也是一个解决的思路 。
我看虞快要补充吗 ？
我稍微补充一点 ， 我自己招人的感觉是这样 ，其实越是强的人， 你越是要给他很难的那个面试的流程 。
我的感觉是强的人 ，他对你有天生的这种好奇心 ， 然后如果你给他一种感觉就是 ， 哎 ， 我好像你在求他让他加入的话 ，其实他不会加入你的 。
你反过来你的面试让他觉得 ， 怎么这家公司我都没有听说过 ， 为什么 ， 就是很神奇 ， 对吧 ， 怎么感觉面试也跟别人不一样 ， 然后面试的题感觉也很难什么的 。其实你越是这样子 ，他越是会很有可能最后会加入的 ， 这个是我的感觉 。
好 ， 那就感谢大家的时间 ， 然后谢谢任川 。
拜拜 ， 谢谢 。
拜拜
。