曲凯
There's something there.
我最近经常和各种人讨论 AI 时代的组织形式，因为我觉得，组织形式在 AI 时代的重要性其实仍然被大大低估了。甚至从中长期来看，组织形式很可能就是新一代创业公司和传统公司相比最大的竞争优势和壁垒。
传统大厂现在最大的问题，就是分工实在太细了。分工如果太细，就说明这个团队里面缺少真正掌控模型、并且对最终产品输出结果负责的核心成员。反而是创业公司，几个人就能做很多端到端的事情，他们更理解模型能力的边界，也更理解哪些用户需求可以通过模型的哪些能力来实现。
所以前段时间，我们请到了一位在湾区创业的好朋友，来讲讲他们是怎么打造 AI Native 工程团队的。他们做了很多有意思的事情，后面的分享里都会讲到。比如，他们现在 90% 的代码都是 AI 写的；他们现在大概有 20 个人，但团队里没有任何一个 PM，全都是工程团队在做所有的事情。
我觉得这期分享非常有价值，所以我们很快就把这一期剪了出来，希望能让更多国内的创业者和做 AI 的人听到。因为我觉得，大家应该能从这期播客里面得到很多启发：湾区最先进、甚至有点激进的组织管理形式到底是什么样的？他们是如何利用 AI 的？又是怎么处理团队和 AI 之间的关系的？
所以后面这部分，首先是他个人的完整分享，之后会接一些我们当时活动现场的问答，我觉得都非常精彩。
任川
我叫任川，来自 Palona AI，之前在 Google 和 LinkedIn 都工作过几年。我们公司的主要业务是做餐饮行业的 AI，也就是用 AI 来帮助餐饮行业提效。
我们的第一个产品，其实就是帮餐馆接电话。因为美国在这方面还稍微有点落后，没有美团，也没有国内现在竞争正激烈的这些先进产品。比如说，订披萨的时候，还是有很多人会打电话。
在美国，接电话的人每小时至少要花 25 美元来雇。所以我们的产品可以端到端地处理电话：电话完全不用响，可以帮你接预约、接订单，普通咨询也都可以处理。
我们的主要价值在于，我们是 AI agent 里面少数可以做到 95% 到 98% 可靠性的公司。现在大部分 AI agent 产品的可靠性一般可能在 70% 左右，这已经很不错了。但对我们来说，因为这个产品非常实用，所以你可以完全放心地把电话交给它，不需要再安排人来管理。
具体技术上我们是怎么做到的，我在别的地方有过纯技术方面的分享。今天我们不讨论那些技术问题，而是稍微聊一下，在这背后我们团队是什么样的。
今天的题目是《如何打造 AI Native 的工程团队》。主要分 3 个部分：第一部分讲我们的 AI Native 工作流，也就是我们公司是怎么利用 AI 工具做研发工作的；第二部分讲人，我们觉得 AI Native 时代需要什么样的人才；第三部分讲组织，在 AI 时代，AI Native 的组织应该是什么样的。
1. AI Rebuilds The Workflow
那我们先进入第一部分：重构工作流，提升 10 倍效率。
这个“10 倍效率”其实是一个虚数。以我自己的感觉，应该远不止 10 倍。我可以稍微举一个例子，讲讲我们公司研发工作大概是什么样的。
其中有一个环节叫代码审查，也就是 code review。Code review 这个过程，在 Google 平均需要的时间差不多是 1 到 2 天。Google 作为一家传统的互联网科技公司，工程效率已经非常、非常优化了。但这个时间在我们公司是 10 分钟。10 分钟和 1 到 2 天相比，肯定提升了不止 10 倍。
那我们怎么做到 10 分钟 code review 呢？其实非常简单，就是我们只让 AI 来 review 代码。我们公司是去年 4 月成立的，大概到六七月份的时候，就开始使用 AI 做 code review。
我们当时用的工具叫 CodeRabbit AI。当时它是为数不多的 code review 工具之一，现在已经有很多同类产品了，但我们还是继续用 CodeRabbit AI，因为用下来觉得它还是最合适的。
即便它是同类产品里面最好的，实际上还是有很多问题。比如，AI review 之后觉得代码没问题，check in 了，但出了问题怎么办？这个道理也很简单：我们可以做到 10 分钟完成 code review，代码就可以进入生产环境。如果在这 10 分钟之后发现问题，可以直接把代码 rollback 或者 revert，也就是撤回；或者你也可以直接在线上把它修掉。
如果大家有经验的话，会觉得这件事稍微有点危险，或者不太符合传统流程。但在传统的开发流程中，如果每一次 review 都需要 1 到 2 天，这件事是不可能实现的。如果每一次 review 只要 10 分钟，发现问题之后也可以快速修复，实际上这种工作方式是可行的。
从今年年初开始，我们已经不要求人来 review code 了。只要 AI approve，我们就可以直接把代码 merge。试用下来半年多，效率非常高，效果也非常好。
Code review 只是其中一个例子。通过这个例子，我想分享一下重构工作流的几个原则和经验。
2. AI Owns The Workflow
第一个原则，是默认由 AI 承担所有研发工作。注意，我这里写的是“研发工作”，而不只是 coding 工作。整个研发流程，从写文档、写各种 test、写设计文档，到写代码、做 code review，再到最后上线之后做监控，AI 不只是能在 coding 这一部分发挥价值。
因为我们公司成立得比较新，大概是去年 4 月成立的，所以我们一开始就想：能不能让 AI 把整个流程都做了？实际上现在 AI 的能力肯定还达不到，但我们可以做一个逻辑上的转换：哪些地方 AI 还做不到，就由人来帮它补充。
但在这种情况下，人必须有一个非常充分的理由来承担这项工作，而不是默认由人完成，等发现 AI 做得好的时候再让 AI 来做。按照这个思路，我们发现有非常多的工作都可以直接交给 AI。
我稍微举几个工具，大家如果有兴趣也可以试用。我们 coding 的时候，用的一个工具叫 Linear。Linear 其实是用来追踪我们整个工作的，Linear 加 Devin，Devin 是一个 coding 工具，也是一个华人团队做出来的。
它的效果是这样的：我每次创建一个 Linear task 之后，只要把它 assign 给 Devin，Devin 就会自动创建代码。整个过程你连 IDE 都没有打开，连代码工具都没有打开，就可以同时创建 10 个 task，然后生成 10 份代码。
这个和人的研发工作是完全不一样的。
我们在生产环境中做监控时，用的工具叫 incident.io。它会把所有 log 收集起来，不管你的 log 是在 AWS 上，还是在 Datadog 上。收集之后，它会自动分析这些 log，给你提醒；甚至在出现 incident 之后，还会提供一些分析。
这个工具大概能够覆盖我们 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 美元买 Max Plan，但 token 消耗量能达到 5 万美元，基本上是 7×24 小时在使用 Claude 的 API。
他自己有一个公众号，就叫“刘小排”。非常推荐大家去学习一下 Claude Code 是怎么使用的，因为它远远不只是用来做 coding 的工作。
这是第二点经验。
第三点，你看，我们默认让 AI 承担大部分工作，然后由人来补充 AI 做不了的事情。那人自己的工作有什么经验或者原则呢？就是尽量一个人独立地、端到端地把工作完成，减少人与人之间的交互。
这件事在各个公司都有点反直觉，因为我们总觉得开会、拉通、对齐是工作里非常重要的内容。但当工作流变得 AI Native 之后，你会非常明显地发现，人与人之间的交流很容易变成瓶颈。
所以我们的原则是尽量减少人与人之间的 align。如果需要 align，就把你的想法、原则也好，直接 align 到 code base 里面。这样大家不管是人与人之间，还是人与 AI 之间，就都能自动对齐。
任川
3. Context Providers Create Leverage
说到这里，这种工作方式和传统工程团队有点不一样。那需要什么样的人才呢？我们进入第二部分：未来成为 AI 工程师，或者说在 AI 工程团队里最需要的人才，应该是什么样的？
根据我们的经验，我总结了 3 点。
第一点叫 context provider。这件事在大多数地方应该很少有人提到。从我们自己的感觉来讲，一定要转变一个思路：不要把 AI 只当成工具，好像 AI 工具给人提效 10 倍、50 倍。其实并不是这样，它真正的价值是人给 AI 提供 context，或者说，人为 AI 提效。
我们有一个原则：人加上 AI 之后，产出要大于 AI 本身。这看起来好像是显而易见的，但仅仅根据我们这一年多的经验，很多时候人加入之后，实际上会让 AI 的效率变差，或者让整个团队的效率变差。这是挺常见的事情。
前一段时间有一个很流行的概念，叫 context engineering。它的概念是什么呢？就是我们现在底层模型的能力已经非常强了。之所以 agent 或者 AI 工作流不 work，更多是因为上下文工程失败了，或者说你的 context 没有提供对，并不是模型本身的问题。
作为 AI 团队来说其实也是一样。不是 AI 的能力不行、不够聪明，而是它没有拿到足够的 context。所以 context provider 在这里面不但在工程上有价值，同时在产品上也有价值。
比如我们做餐饮行业，有一个团队成员暑期经常在餐馆里端盘子。餐饮行业的整个流程，这些 context 实际上对模型非常重要，但可能是模型本身没有的知识。
所以人的特别重要的价值，就叫 context provider。这是第一点。
第二点叫 fast learner，也就是快速学习。这里的快速学习，不是说遇到一个问题，我能够非常快地学习，然后学得比 model 还强。我觉得这已经再也不可能了，人已经不可能比 AI 更聪明。
这里的 fast learner，指的是你能够快速学习并掌握最少的必要知识，然后能够和 AI 沟通。在我们团队，包括面试和日常工作中，有一件特别重要的事情：我们不太在乎其他团队成员会不会做这件事，我们只在乎目标和问题定义得是否清楚。
只要定义清楚，我们认为这个问题就应该能够被解决。当然，实际解决起来肯定会碰到很多困难，但我们对每个人的要求不是看你现在有什么 skill，而是看你能不能快速学习，然后把 AI 的潜力激发出来。这是最重要的。
所以第二点是 fast learner。
第三点叫 hands-on builder，也就是说每个人都要是一个 builder。Builder 的概念是，在整个工作里，你要对最终结果负责，要对全流程负责。
你负责的可能只是整个大产品的一小部分，但你也要对最终结果负责。我们可能有一些岗位，只负责前期的整理工作或者前期的研究工作，但如果他不能对最后的结果负责，就会产生一个问题，也就是刚才讲的，会产生人与人之间的 context sharing，需要去分享上下文或者分享知识。
只要有人与人之间存在分享的过程，就会拉低整个 AI Native 团队的效率。
这就是第二部分：AI engineer 需要的 3 个重要技能。
4. Organizations Run On Outcomes
第三部分稍微更虚一点，讲组织形式。刚才其实也稍微讲到了一点：第一条，我们希望整个组织每个人按结果分工，而不是按流程分工。每个人为结果负责，而不是为中间流程的某一部分负责。
按结果分工是什么意思呢？比如我们有一个小团队，只对商家最终的体验负责，我们内部叫 business request。另一个小团队，为消费者最终的 experience 负责，叫 consumer experience。
实际上，experience 团队的工作内容可能前端会多一些，但我们不会分成前端团队和后端团队。你就是为 experience 负责。如果后端里面有什么问题影响了最后的前端效果，你就直接去改，不需要先找到 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 is cheaper。现在生成代码已经非常容易了，所以我们完全可以先做一个 60 分的东西，然后大家在这个 60 分的基础上做一些 align，在线上做一些对接，再在这个基础上优化。
我们工程团队在这件事上做得非常好，这也是为什么我们能在短短一年的时间里，把一个非常复杂的系统做起来。
第三点更虚一些，也是我们公司正在尝试的方向。有一个朋友在知乎上也挺活跃，前段时间分享过一篇文章，说未来的组织可能会变成少量合伙人和大量合同工。
原因是，既然每个人都按结果分工、为结果负责，那么每个人的价值其实都非常高，整个公司对他的依赖也会非常强。这里面有一个风险：如果这个人离职了，或者他想去做自己的公司，对公司的影响可能会很大。
在 Google、Meta 这种传统互联网公司管理团队时，有一个特别重要的原则，就是每一个位置上都一定要有 backup。但在新的 AI Native 团队里，这件事可能已经很难做到，所以未来的激励方式可能也需要变化。
全职的核心成员一定要有类似合伙人的待遇，这个待遇要高于普通全职员工。但你肯定不可能整个团队只依靠这些合伙人，因为成本会比较高。
同时，团队也会需要一些比较灵活的合同工。这些合同工可能在某一个行业或者某一个领域非常有经验，但对他们自己来说，也不愿意把能力完全 full-time 地卖给其中一个组织。把能力卖给多个组织，可能对他们来说也是更好的方式。
这一点我们也还在探索，可以和大家分享一下，也听听大家的想法。
曲凯
5. Builders Absorb Product Work
差不多，这个分享就到这里。听起来非常有意思，而且比我想象的还要易懂，非技术背景的人完全能听得懂。
我先快速问几个问题，然后把时间交给大家。我的第一个问题是，PM 在你们内部到底是一个什么角色？现在是怎么工作的？
任川
简单说，我们没有全职 PM，基本上就是 engineer 兼职做 PM。我们现在团队差不多 20 个人，我其实不太知道，如果团队可能涨到 50 个人，甚至 100 个人，需不需要全职 PM。
但我们自己跑下来，至少在这个小规模的时候，并没有特别需要一个全职 PM。
曲凯
我的感觉是，湾区那边一般都是几十个人之后，可能才会进入全职 PM。你看，Pika AI 也是很后面才开始招 PM，Cursor 我知道也是很后面才有 PM。或者那边还有一个类似产品设计师的角色，对吧？可能会先招一个产品设计师，然后兼任一些 PM 的工作。
任川
是的。或者这么说，作为创业公司来说，CEO 或者 head of engineering 其实很重要的一项工作，就是直接做 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 实在做不了的地方进行补充。
这种分工到底会对应什么岗位，确实不太好讲，但我觉得肯定会和之前不一样。
曲凯
明白。我还有两个问题。第一个问题是，按照你们现在这个模式和组织架构，你们的一天到底是怎么样的？能不能给大家大概讲一下？
任川
我们首先把会议集中在中间的 3 到 4 个小时，其他时间尽量不安排任何会议，所有人自己做自己的事情。
像我刚才讲的 code review，我们基本上每个人每天可能都有 3、4 个，甚至 4、5 个 pull request。因为整个过程中，他完全自己写 code，然后由 AI review，AI review 完之后自己 merge，所以效率非常快。
所以一天看起来可能和以前只是少了一些 coding 工作、多了一些其他工作，但实际效率的差别还是非常大的。
曲凯
明白。最后一个问题，在你看来，你刚才讲的这套东西在湾区已经是一个非常明确的趋势，甚至很多人已经在这么做了，还是说你们即使在湾区也算比较先锋、还在探索的角色？
任川
我们算是比较先锋，但不能算小众，肯定还不是最 aggressive 的。不过我觉得在 startup 里面，可能不是完全一样的模式，但大家的思路还是都在往那个方向走。
曲凯
余凯还在吗？我再 call back 一下。余凯，你有什么想法？
余凯
我在，我在。
曲凯
你听起来感觉怎么样？你们内部现在是怎么做这件事情的？
余凯
我觉得跟我们挺像。我们到目前为止公司也已经大概 150 个人了，可能只有 2 个 PM。公司最早期其实就是没有 PM，我觉得这很正常。
我的感觉是，有的时候不是 engineer 没有办法 make 这些决定，而是你越是告诉他“有一个 PM”，很多明明应该由他自己下的决定，他就会把这个难题交给别人。我觉得这是非常不好的，ownership 就没有了。
经常遇到一个问题，最后大家会说：“好，这是一个 business decision，那我就不做了，这是 PM 的事情。”那 PM 要 make 这个 decision，其实又要回来找 engineer，对吧？然后问：“你的 data 现在有没有？”这样就增加了很多沟通。
最后这个 decision 很多时候其实还是 engineer 和 PM 一起 make 的。我不觉得早期需要这么多 back and forth。我的感觉是，你让一个很聪明、解决问题能力很强的人去做决定，他是可以做出很好的决定的。没有道理说他只能做出好的 engineering decision，却不能做出好的 business decision。
曲凯
好，谢谢。刚才大家可能见证了一个新时代组织形式变革和产生的过程。下面把时间交给大家，看看大家有什么问题。我要问任川吗？
观众
我可以先问个问题吗？
6. Scale Breaks The Old Model
我之前一直在一些大厂上班。我觉得您刚才说的这种方式，在十几个人、二十几个人的规模下完全没有问题，或者说这种规模的公司就应该这么做，因为没有那么多人。
但比如之前在抖音，一个组或者一个小业务可能就有很多人。为什么大公司不效仿这种方式？它们内部也有很多编程工具，但为什么所有事情还是按照一条线，从用户调研、产品设计、需求，到研发、测试，整个流程一条线地做？
有没有可能你们这种方案只能在初创阶段使用，但到了很大的规模，其实很难行得通？
任川
我就说一些自己的想法。我们其实也只是试了一年多，未来大厂会是什么样，其实很难预测。你说大厂规模大了之后，这套方式不 work，完全有可能。我对未来的预测也没有那么确定。
但我自己的想法是，为什么大厂不做这件事？我自己也在 Google 工作过一段时间。对大厂来说，这种转型除了技术和效率之外，还有非常多其他考量。
任川
今天微软的 CEO 已经出来道歉了，觉得他们之前裁员裁得太猛了，现在需要重拾员工的信心，对吧？这些事情和 engineer 或者工程研发没有什么关系。可能因为某些原因，它没有办法做到像这种效率这么高。
在 Google，据我所知，内部有一些小团队实际上也是类似的做法。但如果大到 Google 整体，要做这种转型还是非常、非常困难的。
这是第一点。第二点，我自己的感觉是，未来可能再也不需要那么大的公司了。
大家看现在，不管是之前的明星公司 Cursor，还是现在的各种创业公司，甚至都在讨论有没有所谓的“一人独角兽公司”。一个人或者几个人的团队能做的事情，已经非常难以置信了。
所以未来还需不需要像 Google 这样有 10 万人的公司来做一个产品？实际上我是比较怀疑的。这是我自己的一点判断。
曲凯
我觉得这个问题很有意思。我们最近聊了很多创业公司，而任川的公司是少数真正思考新时代组织形式的公司。
我们现在的体感是，也许在中短期内，创业公司的壁垒真的就在组织形式上。大公司要转型很难，内部要做非常多的动作，要裁很多人、重新 reorg 组织；但创业公司可能就能抓住这个机会。
比如把做 evaluation 的人提上来，让他承担更多责任，以及刚才讲的，每个人都是 builder，能够更多地端到端负责一些事情。
好，下一个问题。
Guest 3
7. Context Is The Bottleneck
我第二个问题是，对于研发而言，整个代码可能已经迭代很多年了，有的甚至已经有 10 年。用 AI 来做这部分的可行性到底有多大？
比如有些代码逻辑很复杂，涉及端上旋转、重力，以及和设备系统相关的内容。连我自己看了几年之后都理不清楚，怎么让 AI 来帮我写这部分需求？
我感觉 AI coding 更适用于所有东西从零到一。但别说从一到一百了，从十到一百，有些东西我自己都理不明白，我觉得 AI 更理不明白。
任川
这个问题特别好，和我刚才讲的一点比较相关。这时候就特别需要 AI engineer，也需要人的参与。
但人最重要的价值就叫 context provider。就像你刚才说的，过去很多年的经验，我相信任何一个大模型现在都没有这些知识，也很难让它学会。
这时候就需要人来提供 context。但你提供的 context 的准确程度，以及 context 的信噪比，都会直接影响 AI coding 或者 AI agent 最终的效果。
这件事不是模型的能力达不到，而是我们给 AI、给模型提供的 context 不够好。一方面，我们可以等模型变得更强，也就是说，即使你的 context 不够好，它也能 work，但成本会很高。到时候 GPT-6 之类的模型，更新可能会越来越慢。
另一方面，现在也有很多公司在研究，怎么把 context 提供得更好。同时我觉得，作为个人，我们也可以想一想怎么样才能给 AI 提供更好的 context。这会变成未来 AI 工程师特别核心的价值和技能。
Guest 3
明白，就是你 PPT 上写的“人加 AI 大于 AI”，对吧？
任川
对，就是这个意思。
Guest 3
好，谢谢。
Guest 4
我想问一下，除了 coding 以外，您觉得 AI 在你们的工作中还有哪些比较好用的场景？
任川
其实刚才已经说到，对研发团队来说，每一个步骤 AI 都会有非常大的帮助。
第二个方面是 go-to-market。过去整个销售流程也和研发流程一样很长，从最开始的 SDR，到 Account Manager，再到 Customer Success，中间整个流程里，一个客户可能要接触四五个人。
但现在有了 AI 之后，这个流程也被大大压缩了，可能一个人就可以直接端到端地解决。现在硅谷这边有很多公司都在做 go-to-market 方面的自动化。大家也可以研究一下，我觉得这个地方大有可为。
Guest 4
好，下一个问题。
Guest 5
8. Building The AI Native Team
我想请问一下，您在打造这样的一个 AI Native 团队时，是不是有从传统团队转过来，还是从一开始就是用这种工作模式去打造的？在打造的过程中有没有遇到什么困难？又是怎么解决的？
任川
我们比较幸运的一点是，公司比较新，没有历史包袱。所以从去年 4 月创立，到六七月份开始做这套东西，都是以一种全新的 AI Native 方式来做的。
当时也有一个比较现实的问题，就是人不够。人不够的话，肯定要想办法。但确实有很多人不适应，特别是一些 senior。他可能在 Google 工作了七八年，这套东西已经用得非常熟了，可能用 Vim 已经是专家，用 Emacs 也是专家，但他连 Cursor 都不愿意用。这种情况我们也见到过。
所以我自己的感觉是，经验在这个时代不是特别重要，而且很多时候经验会变成负担。当然，我们的数据量比较少。我们发现，最适应这个时代的还是一些比较年轻、刚毕业的人，同时他们有特别强的学习能力和学习欲望。
他们可能在读书过程中就已经离不开 ChatGPT、离不开 AI 了，所以出来工作之后，使用这种方式非常自然。这样的人确实不好招，但我觉得会越来越多。大家把这种方式转变过来之后，情况会慢慢改变。
Guest 5
好，下一个问题。我想问一下，找人的时候，您是怎么找到这些比较会使用 AI 的人的？
任川
我们有两个方式。
第一个方式，我们不做这种一个小时的面对面面试，而是直接给一个问题，做 take-home。候选人回家做这个问题，或者如果项目比较大，没有 AI 肯定是做不完的，我们就给他两天时间，让他 build 一个 product。
做完之后回来，我们再聊半个小时，让他告诉我们大概是怎么做的。这样我们能知道，他确实是在两天时间里把东西做出来的。他一定是 AI 工具用得很好，否则如果完全手写，那就更是大牛了。
第二，他也不能只是让 AI 把东西做出来，而自己完全不了解内容。他要能够讲清楚过程，比如最开始用了什么办法，发现不太 work 之后，又怎么调整 prompt，怎么调整 instruction，最后让它 work。我们会问这些过程和细节。
这样做下来，效果还是比较好的。
我们也在尝试一些新的面对面面试方式，还没有特别 ready。比如一个小时里，我们把一个现成的大型 project 给到候选人，但这个 project 里面有各种各样的问题，埋了很多雷。因为它是一个新的 project，如果靠人自己看，一个小时肯定什么也做不了。
这时候我们就希望看他能不能使用 AI 工具，在一个小时里把这个 project 改进起来。这个方式我们也还在尝试。
余凯
我有个问题想问任川。take-home 的问题是，如果一个人的 background 很强，你跟他说这个 take-home 要花 8 个小时、10 个小时，你怎么让他愿意来做这个 take-home？
任川
这个其实也是一个筛选过程。我们基本上发下去之后，可能只有十分之一的人会做，确实会这样。
曲凯
但如果你想让别人对你感兴趣，可能他通过面试过程觉得很有意思，最后有可能会 join。
可是，如果一开始面试流程他都不愿意开始，会不会就被这个 take-home 吓跑？你有没有遇到过这种情况：看一个人的背景很强，觉得他是 good fit，但他不愿意做 take-home。你会不会 fast-track，直接让他来公司面试，做一个 exception？
任川
光看简历，基本不可能。但如果有 refer 的话，会考虑这种情况。
不过说到底，这最终是一个效率的问题。有没有可能因为没有做 take-home，候选人就跑了，但他其实是一个特别好的候选人？有可能。但我们肯定还是要看综合效率，最终能不能招到合适的人。
曲凯
这个问题我分享一下自己的经验。我们日常所有岗位都使用 take-home 这样的招聘方式。
但在给候选人 take-home 任务之前，我们会先聊一下，判断这个人是不是有比较高的可能性。如果我们认为可能性比较高，take-home 会按照大概市场价格的 30% 给他报酬。
比如我们招一个产品经理，日常的用户调研、设计产品方案，再到数据埋点设计，这一整套全流程都需要他做完。正常情况下，这套工作可能值 5,000 元，但我们会告诉他，任务完成之后给他 1,500 元。
这样候选人就不会觉得你是在白嫖他，我们也可以看到最后 take-home 的质量是否 make sense。
Guest 6
感谢分享。
Guest 7
我想问一下，你们使用 AI 做 code review 的时候，会用一些常见的可量化指标吗？比如命中率、误报率之类的。如果效果不好，你们怎么调整？
任川
第一，我们基本不用这种指标，因为现在这件事也挺难量化。
第二，我们主要看工程师的主观感受。为什么呢？因为人给人做 review 的时候，你会感觉对方是在挑刺儿。但用 AI 做 review 之后，有一个特别神奇的效果：人会特别感谢 AI 帮他挑出了一个问题。
因为代码最终进入 production 之后，如果出了问题，只有写代码的人负责。所以如果 AI 能帮他提前把错误改好，人其实会很开心。
所以我们更多是大家相互分享，看看哪个 AI review tool 最有用，最能帮助你提升代码质量。我们用下来，VS Code Copilot 不太好，Cursor、BugBot 也不是特别好，有时候会瞎说。
所以我们不是用一个指标去衡量这件事，而是看工程师的感受。
Guest 8
我再追问一下，在你们做 AI code review 的过程中，会 review 需求逻辑吗？还是只评审 bug、安全漏洞、代码规范之类的？
任川
需求逻辑指的是什么？
Guest 8
就是产品需求的逻辑。比如代码有没有完整实现产品需求，或者类似的问题。
任川
这个分两种情况。
如果你做的是比较偏新的事情，比如实现一个新功能、新 feature，可能会有一个新的 service。这个 service 具体是做什么的，输入是什么，输出是什么，要满足哪几个功能，我们都会在 Python 的 __init__ 文件里面写好。这些内容也会给到模型。
模型就会知道，你想实现一、二、三、四这几个功能。如果它发现你的代码没有实现，就会把这些问题提出来。
但如果你的代码只是改 bug，或者修改某个模块里的一个小功能，离最终需求有点远，那模型可能就不会判断。
说到底还是 context。如果有需求的 context，模型也会把它考虑进来做 review。
Guest 8
明白。
Guest 9
另外一个问题是，一个 project 里面有多少代码是 AI 生成的？你们怎么统计 AI 生成的代码量？
任川
我估计至少有 90%。我们的默认方式就是 AI 写代码，人只在必要的时候修改。
Guest 10
我想问一下，一个公司从 10 个人到 50 个人、再到 100 个人，具体都包含哪些角色？相互之间是怎么配合的？不同发展阶段又应该增加哪些角色？
任川
我不敢说 50 人、100 人之后会怎么样，因为我没有这个经验。
我自己觉得，分工有一个原则，刚才也说过，就是按结果分工。按结果分工的意思是，每个人来到这里都是为了解决问题。最终人与人之间需要 align 的，是我们到底要解决什么问题，或者说我们的目标是什么。
只要把这个讲清楚，就可以分工：你解决这个，我解决那个。至于具体怎么解决，采取什么手段，不去分工，也不去限制，让每个人自己发挥。当然，还是要利用 AI。
你说到 50 个人或者 100 个人之后会产生什么岗位，我确实不太好预测。一会儿可以让余凯说说他们现在 150 个人都有哪些岗位。
余凯
我感觉公司渐渐变大之后，开始多招一些 security 的人，也开始招 QA 和 testing 的人。
之前一开始，大家都是每个人负责一个 feature。后来慢慢会遇到一些问题：我们的 scalability 怎么办？Developer experience 怎么办？所以接下来 platform team 就开始出现了，platform engineering 的人也开始变多。这是我的感受。
曲凯
好，还有问题吗？
Guest 11
您好，我想问一下，听您讲第一部分时，感觉你们非常信任 AI coding，一个很大的因素是它迭代得足够快，比如每次 review 只要 10 分钟。
但就算我们认为它足够快，10 分钟之内仍然可能产生 P0 或 P1 级别的事故。对于这种情况，你们一开始会区分业务吗？比如核心业务可能会少用 AI coding。
第二个问题是，假设是级别更高的业务，在 AI coding 上怎么避免这种事故发生？
第三个问题是，除了 fix bug 之外，某一次事故可能还会带来 database 脏数据，甚至用户补偿。这部分也是由 AI 来做吗，还是人为干预会更多？
任川
刚才说的第一点，并不是说我们无脑地把所有东西都交给 AI 做，而是思路上的转变。
我先假设 AI 可以做。如果 AI 一做发现有问题、不行，那我们肯定还是让人来做。区别在于，过去可能是先 follow 传统工作流，什么东西都让人来做；发现某个地方 AI 能提效之后，再让 AI 去做。这样会 miss 掉很多机会。
所以这是 principle 的不同，而不是说我们真的什么都要用 AI 做。
第二，你刚才说的 infra 这类东西，我们确实会少让 AI 做一些，但实际上还是比大多数公司多很多。比如我们整个 infra 都以 IaC 的形式存在 repo 里，所以 AI 也会生成对应的代码，但我们可能会增加 on-call 时的检查。
产品方面，特别是前端代码，可能看得少一些，直接上线，发现问题再改也可以。AI 已经进入我们的工作流了，如果 AI 未来 work 得越来越好，那人自然会越来越少地 review。
曲凯
好，我们要不最后一个问题？
Guest 12
您好，这边有一个问题。在 AI engineer 的招聘过程中，我们会遇到一些问题。
当我们想吸引一些背景好、综合能力出众的同学时，他们往往会更倾向于说：“我刚毕业，凭什么来你这个初创公司？我要去大厂。”而一些比较 senior 的 engineer，可能又不太适应新的 AI engineer 工程习惯。
在这种情况下，不管是招聘还是人才培养，我们需要通过哪些渠道找到合适的人选？需要关注这些人的什么特质？如果想做一些差异化激励，应该怎么做？
任川
这也是我前面分享第三部分最后讲到的一点。像你刚才说的，可能慢慢不能把人只当成全职员工，而要把他当成合伙人。
第二点，是一个创业朋友的观察：与其招人，不如先提升自己。与其去招这样的合伙人，不如先看看能不能让现有的几个合伙人采用这种方式提效。
因为有可能你把 AI 工具用好之后，不需要花更多精力，就能把原本要招的人所负责的工作覆盖掉。这种情况是很有可能的。
我有一些朋友创业，刚开始两三个人有点忙不过来，就开始招人。结果招来人之后，发现比之前还忙，这些事情都有可能发生。
所以我觉得，招人之前先想想现有团队能不能把效率提升上去，也可能是一个解决思路。
余凯
我稍微补充一点。我自己招人的感觉是，越是强的人，越要给他一个有难度的面试流程。
强的人对你有一种天然的好奇心。如果你给他的感觉是“你好像在求他加入”，其实他反而不会加入。相反，如果你的面试让他觉得：“这家公司我都没有听说过，为什么这么神奇？面试也跟别人不一样，题目感觉也很难。”他反而很有可能最后加入。
这是我的感觉。
曲凯
好，那就感谢大家的时间，也谢谢任川。
任川
拜拜。
余凯
拜拜，谢谢，拜拜。