原创 曲凯 2025-09-26 16:31 北京
我们默认所有事都由 AI 完成，而人类是为 AI 提效
本期播客前半部分是任川的单人分享，后半部分是现场交流，原文约 14500 字，本文经过删减整理后约 5600 字。
任川单人分享
我们公司成立于去年 4 月，一开始就采用了 AI Native 的组织形式，两三个月后，就把 AI 深度嵌入了研发的各个环节，这一年多实践下来，效率和效果都很好。
今天我就会从工作流、人才、组织三个维度，分享我们打造 AI Native 工程团队的经验。
先说第一部分：如何用 AI 重构研发工作流，把效率提升 10 倍。
所谓「10 倍提效」只是保守说法，实际体感远不止于此。拿 Code Review 举例，这件事即使在效率优化到极致的 Google，平均也要一两天，而我们只需 10 分钟。
我们是怎么做到的呢？
很简单：只让 AI 来做 Review。
AI 不仅能提效，还有一个意想不到的好处，就是减少摩擦。人工 Review 很容易让人觉得是在「挑刺」，但如果是 AI 指出问题，工程师反而会感谢它帮自己排雷。所以在我们团队里，大家都会相互推荐好用的 AI Review 工具。这种「好用」很难用量化指标衡量，更多取决于工程师的主观体验。
目前我们觉得最好用的工具是 CodeRabbit。只要它批准，我们就直接合并代码。
当然，即便 AI Review 的效果已经很好了，还是有可能会漏掉 bug。这听起来有点危险，因为在传统工作流里，上线后再发现 bug 很麻烦，但 AI Review 的速度极快，所以哪怕出现问题，我们也可以立刻回滚或线上修复。
通过这个例子，我想和大家分享我们用 AI 重构工作流的三条经验。
首先，我们默认由 AI 来承担所有研发工作。
这并不是说要无脑地把一切都交给 AI，而是要转变思维模式。
在传统工作流里，我们通常会默认所有事都由人类完成，只有偶尔发现 AI 能帮上忙时，才会让它介入。但这样可能会错过很多 AI 提效的机会。
我们的逻辑正好相反：我们默认所有事都由 AI 完成，只有当 AI 遇到确实解决不了的问题时，再由人类来补位。
这样思考下来，AI 其实可以直接完成很多工作，重构我们的工作流。
它不止能写代码，还可以写文档、写测试、写设计文档、做 Review、上线和监控等等。和大家分享几个场景和工具：
在 Coding 环节，我们会用 Linear 管理任务，用 Devin 生成代码。我们可能会一次性在 Linear 中创建 10 个任务，然后由 Linear 将任务自动分配给 Devin，再由 Devin 批量生成代码。整个过程中，我们甚至都不需要打开 IDE。现在，我们大约 90% 的代码都是通过这种方式生成的。
在生产监控中，我们会用 incident.io。它会收集我们的工作日志，自动分析和预警，甚至在出现问题时给出初步诊断，目前这已经能覆盖我们近一半的监控需求。现在我们已经不需要专职的运维人员了，只靠工程师配合 incident.io 就足够。
此外，我们最近还发现了一个 AI 可以重塑的工作流，就是 go-to-market。传统销售流程很长，一个客户可能从头到尾要接触四五个人，但有了 AI，整个链条将被大幅压缩，或许一个人就能 end-to-end 地完成全部工作。现在硅谷很多公司都在做 GTM 自动化，我也觉得这里面大有可为，很值得关注。
虽然 AI 现在还不能完全替代人力，比如 Infra 层还是比较依赖人工，但在前端、产品等环节，AI 的表现已经非常好了。随着 AI 的效果越来越好，我相信未来需要人类参与的部分也会越来越少。
第二条经验，就是我非常推荐大家使用 Claude Code。
这点现在讲起来有点尴尬，因为 Anthropic 最近限制了国内访问…但我们用下来，它确实还是最好用的，一是 Claude Code 能力本身就很强；二是它有 SDK，可以做大量二次开发。
而且 Calude Code 能做的事远不止写代码。Claude Code 「全球第一人」刘小排（他用 200 美元的套餐消耗掉了价值 5 万美元的 token）就说过：只要有 SOP，就没有 Claude Code 执行不了的任务。
第三条经验有点反直觉。
大家通常觉得开会、对齐很重要。但在 AI Native 的工作流里，人与人之间的交流很容易变成瓶颈。
所以我们的做法是：让每个人从头到尾独立完成工作，尽量减少对齐。如果必须要对齐，那大家就把原则和想法写进 codebase，让人和人、人和 AI 在代码里自动对齐。
讲到这里，其实大家能感受到，AI Native 的工作方式和传统的工作方式很不一样，这也对人才提出了新的要求。
那么 AI Native 的工程团队最需要什么样的人才呢？
第一，人需要成为 AI 的「Context Provider」。
我们使用 AI 有个原则，就是「人 + AI」的产出必须大于「AI 单独工作」的产出。
这听上去非常合理，但在实践中，很多时候人类的介入反而会拖慢效率。
很多人只把 AI 当提效工具，但其实大家应该转变思路：让人类为 AI 提效。这样或许反而能取得更好的效果。
因为今天模型的能力已经很强了，AI 产出效果不够好，更多是因为 Context Engineering 不够好，或者是人类没有为 AI 提供足够的上下文
所以在 AI Native 的团队里，人类很重要的价值，就是成为 Context Provider，为 AI 打造更好的上下文，提供它不具备的知识。
比如我们的产品主要是用 AI 帮餐饮行业提效，让 AI 帮忙接电话、预约、下单等等。要做好这些工作，需要对餐饮行业有很深的理解，而 AI 本身不具备这些知识。但我们有同事暑假常在餐厅端盘子，ta 所积累下来的对餐饮流程的理解，就是对 AI 极有价值的 Context。
第二，人应该做「Fast Learner」，快速掌握最少必要知识，从而与 AI 高效沟通。
现在一个人遇到新问题，已经不太可能在短时间内学得比 AI 还强了。所以在面试和日常工作中，我们不太在乎一个人已有多少技能，更在乎 ta 能否快速掌握基本知识，把目标和问题定义清楚，然后激发 AI 的潜力，用 AI 的力量去解决问题。
第三，每个人都应该是「Hands-on Builder」。哪怕一个人只负责产品中的一小部分，也要对全流程和最终结果负责。
举个例子，如果你只做前期研究，却不 Build、也不对结果负责，那你就需要和上下游反复传递 Context。而只要出现这种传递，团队效率就会显著下降。
讲完人才，最后，我们再讲讲 AI Native 工程团队的组织形式和分工模式。
首先，我们实践下来，发现更合理的方式是「按结果分工」，而不是「按流程分工」。
什么叫「按结果分工」呢？
举个例子，我们有一个对商家需求负责的小组，还有一个对消费者体验负责的小组。其实后者的日常工作更偏前端，但我们不会把它定义成前端组，而是要求这个小组具备前后端、运维等全链路能力。只要消费者体验出了问题，不管在哪个环节，都由这个小组直接解决。
甚至我们的工程师也要参与产品设计、GTM 等环节。我也非常鼓励我们的工程师自己去跑客户，获取一手反馈，而不是像在传统团队里那样，由销售去见客户、把客户的需求转达给 PM、再由 PM 转达给工程团队，因为这样层层转述下来，一来工程团队未必能实现，还要再反复沟通，二来客户的需求可能已经走样了。
「按结果分工」不一定是最佳模式，但我相信即便未来继续演变，也不会再回到工业时代、互联网时代那种「按流程分工」的模式。
原因很简单：过去需要在每个环节安排不同的人，而在 AI 时代，可能 98% 的工作都能由 AI 完成，人类只需在 AI 做不了的地方补位。到那时，还按流程来分工明显就很不合理。
第二，我们的组织以工程团队为核心，因为工程团队最容易为结果负责。
比如我们要上线一个功能时，工程团队会第一时间利用各种各样的工具，完成包括研发、产品、设计在内的基础工作，先做出一个 60 分的版本，快速上线。而其他团队，比如专业的设计师，会再在这个 60 分版本的基础上优化。
过去大家总说「talk is cheap, show me the code」，但上线一个新功能的成本很高，所以大家要开很多会，让所有人全部拉通对齐，得出一个很完善的方案再付诸行动。
但现在「talk is cheap, but code is cheaper」，生成代码的成本极低，所以我们完全可以追求「速度优先」，先上线一个 60 分的东西，大家再一起努力把它做到 100 分。
正是这种方式，让我们在一年内就能搭起一个复杂系统。
第三，未来的组织形态，可能是「少量核心合伙人 + 大量灵活合同工」。
在传统互联网公司里，每个岗位都会有 back up 员工。但在 AI Native 的组织中，每个人都按结果分工、为结果负责，所以一个人的价值和不可替代性很高。一旦一个员工离开，就会对公司产生很大的影响。
那为了留住这些人才，就需要给这些员工提供类似于合伙人的待遇。
但如果所有的员工都享受合伙人级别的待遇，成本又很高，所以全职的核心员工数量不会特别多，需要大量的灵活合同工来作为补充。这些合同工往往在某个领域有很丰富的经验，他们也更愿意和多个组织合作，而不是全职绑定在一家企业。
我们这套模式在硅谷算是比较先锋，但绝不小众，更不是最激进的。湾区初创公司各有各的做法，不过大家的思路基本都在往这个方向发展。
Q&A 精选
（活动的另一位嘉宾是上期Mercor 高速增长的秘诀与其中的聪明人｜42章经的虞快，所以 Q&A 部分也有一些虞快的补充）
Q1：为什么大厂不效仿你们这种 AI Native 的组织形式？是不是这种方案只适合初创公司，一旦公司规模大起来，就很难行得通？
任川：我在 Google 的时候，内部一些小团队也会这么做，但要推行到整个公司确实非常困难，因为大厂想调整组织架构，要考虑的不只是效率，还有很多额外因素。比如微软 CEO 最近就公开道歉，说之前裁员过猛，需要重建员工信心。
不过现在很多明星 AI 公司规模都不大，甚至有人在讨论会不会出现「一人独角兽」。如果未来几个人就能做出惊人的产品，那可能也不需要 Google 这样十万人的公司了。
Q2：在你们这种组织模式下，团队的一天是怎样的？
任川：我们的工作节奏表面上可能和传统公司差不多，但实际产出效率差别很大。
我们每天会把会议集中在中间的 3–4 个小时，其他时间尽量不排会，大家分头去做事。像我最开始提到的 Code Review，每个人每天都会收到 3-5 个这种请求，然后会各自完成写代码、AI review、merge 的全流程，效率非常高。
Q3：有些代码可能已经迭代了十年，非常复杂，人类工程师都未必能完全掌握。这种情况下，AI 介入的可行性有多大？是不是 AI 更适合从 0 到 1，而不太适合从 1 到 100 的场景？
任川：这个问题特别好。你所提到的，就是典型的需要人来给 AI 做 Context Provider 的场景。
就像你说的，大模型不具备这么多年的经验积累。在这种情况下，AI Coding 的效果，很大程度上取决于人类所提供的 Context 的准确性和信噪比。如果 AI 跑出来的效果不够好，并不是因为模型能力不行，而是因为我们提供的上下文不够好。
要解决这个问题，要么就是等模型更强大，强大到上下文不够也没关系；要么就是人类想办法给 AI 提供更好的上下文。前者成本很高，也很难预期，但后者是公司和个人都可以努力的方向 。从个人角度来看，学会为 AI 提供更好的 Context，将是未来 AI 工程师非常核心的技能和价值。
Q4：PM 在你们内部是什么样的角色？
任川：我们团队现在差不多 20 个人，没有全职的 PM，基本上工程师就把 PM 的工作做了，这样工程师也可以直接拿到客户反馈，比中间隔着一层 PM 的效率更高。
而且其实对于创业公司来说，CEO 或者工程负责人就是最重要的 PM。
虞快有什么补充吗？
虞快：我觉得公司早期没有 PM 很正常。Mercor 到现在已经有大约 150 人，也只有 2 个 PM。
很多时候不是工程师做不了 PM 的事，而是他们知道有 PM 的存在后，就容易丧失 ownership，倾向于把难题推给别人。可 PM 在做决定时，又必须回过头来找工程师确认，来回沟通一大圈，最后这个决定往往还是工程师和 PM 一起下的。
所以其实只要你招的人足够聪明、善于解决问题，ta 没理由只能做工程决策、做不了产品或商业决策。
Q5：大家对工程师的固有印象可能是特别擅长写代码，但不善与人沟通，而 PM 则是懂用户、会沟通、能提炼需求。如果让工程师兼做 PM，是不是对工程师的要求特别高？这样的人好招吗？
任川：这样的人确实不太好招。现在能快速学习 AI、用好 AI 工具的工程师本就不多，还兼备产品能力的更少。
但其实现在软件工程师岗位，已经不是只有懂代码的人才能胜任了。我认识一些 PM，他们不会写代码，但现在用各种强大的 AI Coding 工具，也能独立做出产品。
所以我觉得未来可能不会再有「PM」和「工程师」的严格区分，大家都是 Builder。只要能 Build 出东西、对结果负责就可以。
Q6：怎么筛选出真正会用 AI 的人？
任川：我们有两种方式。
首先，我们不做传统的一小时面对面的面试，而是会直接给候选人一个 take-home 的任务。
比如我们会让你在两天时间内 Build 一个产品，而这个产品比较复杂，没有 AI 基本做不出来。如果你能在两天内做出这个产品，那你肯定很会用 AI 工具。如果你手搓了一个产品出来，那说明你更是技术大牛（笑）。
两天后，我们再约着聊半小时，请你讲讲过程中的思路和细节。这样我们也可以进一步判断你能不能用好 AI。
当然，有些背景很强的人可能不愿意花时间来做这个任务，那这本身也是一种双向筛选。我们可能会因此错过一些人，但这种方式整体来看效率比较高，最后也能帮我们招到想要的人。
另外，我们最近也在尝试一些新的办法。比如我们会给你一个写好的大型 project，其中埋了很多雷，然后要求你在一小时内优化它。这个项目很复杂，时间又很紧迫，你大概率只能靠 AI 来快速理解和解决问题。
Q7：该如何打造一个 AI Native 的团队？
任川：我们比较幸运，公司很新，没有历史包袱，所以一开始就在用全新的 AI Native 的方式来组建团队。
在我看来，经验在这个时代未必是优势，很多时候甚至会成为负担。
比如有一些比较 senior 的人，已经习惯了传统的工具和工作流，连 Cursor 都不愿意用，就很难适应新的组织方式。相比之下，一些刚毕业、学习能力和求知欲都很强的年轻人，反倒是更适应 AI Native 的团队。他们在读书时就已经离不开 AI，用 AI 工作对他们来说非常自然。这样的人虽然不好招，但我相信未来一定会越来越多。
Q8：公司在 10 人、50 人、100 人的规模下，分别需要设立哪些岗位？
任川：我们现在只有 20 人，所以我不敢断言 50 人、100 人的公司会怎样。但我们的底层原则始终是「按结果分工」，也就是每个人都要为某个目标或问题负责。至于怎么实现，我认为没必要通过分工设太多的限制，可以让大家自由发挥。
这里可以请虞快补充下，Mercor 扩张到 150 人之后，出现了什么新岗位？
虞快：我们一上来就是每个人负责一个 feature，公司渐渐变大了之后，开始招负责安全、QA、测试的人，后面随着平台扩张，也会需要平台工程师。
Q9：该怎么招到和留住优秀的人才？
任川：前面我有提到过一点，就是未来需要给核心员工合伙人级别的待遇。
另外，我很认同一位朋友说过的一句话：与其费劲招人，不如先提升自己。
有时候你招来两三个人帮忙，可能比你一个人干还要忙。但如果你能用好 AI 工具，那你一个人也有可能完成原本需要两三个人才能完成的工作，效率反而更高。
虞快：我补充一点。
在招人时，我发现越是强的人，越要给 ta 上面试难度。因为强者往往有天然的好奇心和挑战欲，如果你的公司名不见经传，面试流程却很特别、很有挑战，ta 可能更愿意加入。
42章经
思考事物本质
