# 组织能力才是 AI 公司真正的壁垒 | 对谈 Palona AI 联创任川

> 42章经 精读

- 发布日期：2025-09-20
- 主持：曲凯
- 原节目：https://www.xiaoyuzhoufm.com/episode/68ccfa75a56ca3e0c438706c
- 网页版：https://42zhangjing.qiaomu.ai/ep/68ccfa75a56ca3e0c438706c.html
- 精读字数：约 8364 字（阅读约 19 分钟）

> 本文为 42zhangjing.qiaomu.ai 基于节目转写的 AI 整理精读，不是逐字稿；引用请注明出处并链接网页版。

去年四月成立的公司，到六七月份就开始让 AI 做代码审查，现在 90% 的代码由 AI 写，二十多人的团队里没有一个全职 PM，也没有一个专职运维。这是 Palona AI 联合创始人任川在 42章经的一场线下活动里交出的数字。Palona AI 做的是餐饮行业的 AI 接电话产品，能处理预约、点单和常见咨询，任川说他们把可靠性做到了 95% 到 98%，而市面上多数同类产品大概在 70% 左右。

任川的背景是前 Google、LinkedIn 工程师。这场分享里，他把 Palona AI 过去一年多的实践拆成三块讲：工作流怎么用 AI 重构、AI 时代需要什么样的人、组织该怎么分工。主持人曲凯在开场就说，组织形式在 AI 时代的重要性被大大低估了，中长期看，它很可能是新一代创业公司相对传统公司最大的竞争优势。

下半场是现场问答，同场的 Mercor 早期员工虞快也补充了不少自己的观察。Mercor 现在一百五十人左右，只有两个 PM。这些问题问得很实在：怎么筛出真正会用 AI 的人、大厂为什么转不过来、十年历史的老代码 AI 能不能碰、核心业务敢不敢交给 AI。下面是这场分享的完整梳理。

## 十分钟做完 code review，靠的是把默认值反过来 3:51

任川用一个环节说明提效幅度：代码审查。在 Google，一次 code review 平均要一到两天，而 Google 的工程效率在传统互联网公司里已经优化得相当好。Palona AI 的这个数字是十分钟。从一两天到十分钟，提升远不止十倍。

做法本身不复杂：只让 AI 来 review。他们用的是 CodeRabbit，去年六七月份开始用，当时做这类工具的公司还不多。AI review 通过之后，代码直接进生产环境。那如果十分钟后在生产环境发现问题呢？两条路，直接回滚，或者在线修掉。任川承认这在传统流程里有点危险，但传统流程里每次 review 要一两天，在线修这个动作根本不可能成立；当一次 review 只要十分钟，它就成立了。从今年年初开始，他们不再要求人来 review 代码，AI 批准即可上线，跑了半年多，效率和效果都不错。

从这个例子，任川总结出三条工作流原则。

**第一条，默认由 AI 承担所有研发工作。**他特意强调是「研发工作」，不只是写代码。整个流程从写文档、写测试、写设计文档，到写代码、code review，再到上线后的监控，都在范围内。公司刚成立时的想法是让 AI 把全流程都干了，现实当然做不到，但他们做了一个逻辑转换：哪个环节 AI 还做不到，才用人去补，而且人要有充分理由才能接手。反过来，如果默认人来做、觉得 AI 行的时候再交给 AI，会漏掉大量本来 AI 就能干的部分。

他列了几个亲测好用的工具。写代码环节用 Linear 加 Devin，在 Linear 里建一个 task，@ 一下 Devin，它会自动生成代码，整个过程连 IDE 都不用打开，可以同时建十个 task 产出十份代码。生产环境监控用 incident.io，它把散在 AWS、Datadog 各处的日志收集起来自动分析、告警，出故障后还给分析，大概能覆盖 40% 到 50% 的运维工作。Palona AI 没有 SRE，运维靠一半工程师加一半 incident.io 顶着。

**第二条，只要有 SOP，就没有 Claude Code 完成不了的任务。**任川说这句话出自刘小排，一位华人创业者，公众号叫「刘小排r」，他每个月花两百美元买 Max Plan，token 消耗量却达到五万美元的量级，几乎 7×24 小时在用。任川推荐大家去学他的用法，理由是 Claude Code 的能力本身强，有 SDK 可以做大量二次开发，而且不要被名字里的 code 限制住，它做的绝不只是写代码的活。

**第三条反直觉：尽量减少人和人之间的交互。**各家公司的习惯都是开会、拉通、对齐，但当工作流变成 AI Native 之后，人与人的交流很容易变成瓶颈。他们的原则是尽量让一个人端到端把工作完成。要交流，就把想法和原则写进 codebase，人和人、人和 AI 都在那里对齐。

## 人是 Context Provider，不是 AI 的操作员 10:51

工作流变了，对人的要求就变了。任川总结了三项能力，第一项他放在最前面，因为「在大多数地方很少有人提到」。

**人是 Context Provider。**他的说法是，观念要转过来：不要把 AI 只当工具、当成给人提效十倍五十倍的东西，真正的价值是人给 AI 提供上下文。他们有一条原则，人加上 AI 之后的产出要大于 AI 本身。这句话听起来理所当然，但一年多的经验里，很多时候人加进来反而让 AI 的效率变差，让整个团队效率变差，这挺常见。

他借用了一个流行概念来解释：context engineering。底层模型能力已经很强，agent 或者 AI 工作流不 work，多数时候是上下文工程的失败，不是模型本身不行。对团队里的每个人也一样，AI 不是不够聪明，是没拿到足够的 context。这个道理在工程之外同样成立。Palona AI 做餐饮，团队里有成员暑期经常去餐馆端盘子，这些流程知识对模型非常重要，但模型本身没有，只能由人喂进去。

**第二项，Fast Learner。**任川把话说得很直：人已经不可能比 AI 更聪明了，快速学习不是要学得比模型强，而是快速掌握「最少必要知识」，然后能跟 AI 沟通。他们团队面试和日常工作的重点都一样，不太在乎一个人现在会不会某件事，只在乎目标定义得清不清楚。只要定义清楚，就认为它应该能被解决。对每个人的要求是，别看你现有的技能，看你能不能快速学习、把 AI 的潜力激发出来。

**第三项，每个人都是 Builder。**Builder 的意思是对最终结果负责、对全流程负责。你负责的可能是大产品里的一小块，但也要对那块的结果负责。任川解释了背后的逻辑：如果某个岗位只做前期整理或前期研究、不对最终结果负责，就必然产生人和人之间分享上下文的过程，而只要有这个过程，AI Native 团队的效率立刻被拉低。

## 按结果分工，工程师直接去见餐馆老板 14:37

组织部分的第一条原则：按结果分工，不按流程分工。每个人为结果负责，不为流程里的某一段负责。

具体到 Palona AI，团队按最终体验切成小组。一个小组对商家的最终体验负责，内部叫 business experience；另一个小组对消费者的体验负责，叫 consumer experience。experience 团队前端工作多一些，但他们不设前端团队、后端团队。如果后端某处影响了前端效果，工程师直接去改，不需要找后端团队、找 research 团队层层转达。

按结果分工不只发生在工程团队内部。任川很鼓励工程师直接去找餐馆老板聊，问产品用得好不好、有什么需求。同样的反馈如果走传统链条，老板找销售，销售反馈给 PM，PM 反馈给工程团队，工程团队说做不了，一圈下来信息已经完全走样。工程师直接见客户，拿到的是一手反馈。

第二条原则：**工程团队是组织的核心，目标只完成前 60%、最多 80% 的工作，剩下的交给专业角色优化。**要上一个新功能，工程团队第一时间不找设计师、不找 PM，而是用各种设计工具先把六十分的东西做出来，先上线再说，他们内部叫 velocity first，速度优先。专业设计师在这个六十分的基础上做到八十分、九十分甚至一百分。

这套做法过去不成立，因为写代码成本高，先做一把不行再做一把，工程团队会抓狂。科技行业以前流行一句话，code is cheap, show me the code。任川把它改了一下：code is cheap，但现在 code 其实更便宜，写代码已经非常容易。所以完全可以先做六十分的东西，再在它上面迭代优化。他把这视为公司能在一年内搭起一个相当复杂的系统的原因之一。

第三条更远一些，他们自己也在尝试。任川提到一位朋友在知乎上写的一篇文章，讲未来组织可能变成少量合伙人加大量合同工。逻辑是：每个人按结果负责，个人价值很高，公司对他的依赖也很强，这个人一旦离职或者自己创业，对公司影响会很大。传统互联网公司管理团队时有一条铁律，每个位置上都要有 backup，在新的 AI Native 团队里这件事已经很困难。所以核心的全职人员要有类似合伙人的待遇，高于普通全职员工；同时搭配灵活的合同工，这些人在某个领域经验很深，也不愿意把能力全职卖给一家组织，卖给多家对他更划算。

## 二十多人，零个全职 PM 19:49

曲凯的第一个问题很直接：PM 在你们内部到底是什么角色？任川的回答是，没有全职 PM，由 Angela 兼职做。团队二十多人，他不太确定涨到五十人、一百人时是否需要全职 PM，至少在这个规模跑下来，并没有特别需要。

曲凯补充了湾区的观察：很多公司都是几十人之后才进全职 PM，Perplexity 是很后面才招的，Cursor 也是，还有一种是先招产品设计师、兼任一部分 PM 工作。任川认同，创业公司里 CEO 或者 head of engineer 直接做 PM 的工作，决策链条少一环，从客户直接到 engineer，比中间加一层 PM 效率高。

曲凯追问：传统印象里 engineer 擅长写代码、偏内向，PM 才了解用户需求、善于沟通提炼，把这些职责压到 engineer 身上，要求是不是太高、人好不好招？任川承认这样的人不好找，既要有产品能力，又要能快速学 AI、把工具用好，市场上不多，但这在未来可能是必须的。他补了一句关键的：AI software engineer 这个岗位并不是只有 engineer 能做。他认识一些原来是 PM、没学过 coding 的朋友，靠现在这些 AI coding 工具就能 build 出自己的产品。最终目的不是区分 PM 还是 engineer，只要能为 build 出来的东西负责，都可以。

曲凯顺着问：你们是技术背景，自然以 engineer 为主体，未来 AI coding 更发达，会不会有公司反过来，一个 engineer 都没有，全是 PM？任川说，或者以后大家都是 builder。

曲凯又抛出一个更根本的问题：分工是工业社会的产物，分工越细理论上配合越好、效率越高，未来会不会又走向更细的分工？任川不敢说现在这套最高效，但确定会和以前不一样。原因很简单，以前是按流程分工，每个环节派不同角色；AI Native 最重要的思维转变是，整个流程以 AI 为主，不以人为主。AI 最后能做 95% 到 98% 的事，人只在 AI 实在做不了的地方补充。这样的分工对应什么岗位不好讲，但和以前不同是确定的。

关于一天怎么过，任川说会议集中在中间三到四个小时，其他时间尽量不开会，各做各的。每个人每天可能有三四五个 code request，自己写、AI review、自己合并，节奏非常快。看起来只是 coding 少了些，实际效率差别很大。

曲凯问这套东西在湾区是明确趋势还是先锋探索。任川说他们算比较先锋，但算小众，不是最激进的。明星创业公司里模式不完全一样，思路都在往那个方向走。

虞快在这里补了 Mercor 的版本：一百五十人左右，两个 PM，最早也没有 PM。他的观察是，早期加 PM 反而有害。有些决定明明工程师自己可以下，有了 PM，人就把难题交出去，ownership 就没了。「这个是个 business decision，我就不 make 了」，于是去找 PM，PM 又要来找人做决定，沟通反而增加，最后很多决定还是 engineer 和 PM 一起做的。他的判断是，让一个很聪明、解决问题能力很强的人去做决定，他能做出好决定，没道理说他只能做好工程决定、做不了好商业决定。

## 大厂转不过来，可能也不需要那么大的公司了 26:09

现场第一个问题来自一位有大厂背景的听众：这套方式在十几二十人的公司没问题，但抖音一个小组一个小业务就很多人，大厂内部也有很多编程工具，为什么还是从用户调研到产品设计到研发测试一条线走下来？这套方案是不是只在初创阶段可行？

任川先划了边界：他们只试了一年多，未来大厂什么样很难预测，规模大了这套方式不 work 完全有可能。他给了两个想法。一是大厂转型有很多技术和效率之外的考量。他举了当天的新闻，微软 CEO 出来道歉，说之前裁人裁得太猛，需要重拾员工信心。这些事跟 AI Native 研发没有关系，但会让公司做不到这么高的效率。据他所知，Google 内部也有一些小团队在用类似做法，但放到 Google 整体，做这种转型非常困难。

二是他自己的判断：**未来可能再也不需要那么大的公司。**不管是此前的明星公司 Cursor，还是现在的各种创业公司，甚至有人在讨论一人独角兽，一个人几个人的团队能做的事已经非常难以置信。未来是否还需要一个十万人规模的公司来做一款产品，他表示怀疑。

曲凯接过话：最近聊了很多创业公司，Palona AI 是少数在思考新时代组织形式的，中短期内创业公司真正的壁垒也许就在组织形式上。大公司要转很难，要 reorg，创业公司能抓住这个窗口，把做 evaluation 的人提上来，让他负责更多东西，每个人都是 builder，端到端负责。

## 十年老代码，AI 理不清，得靠人喂上下文 28:59

第二个问题扎在痛点上：很多代码迭代了十年，逻辑复杂，端上渲染跟设备系统强相关，自己看了几年都理不清，怎么让 AI 来写这块需求？这位听众的感觉是，AI coding 更适合从零到一，从十到一百的存量代码，他自己都理不明白，AI 更理不明白。

任川说这个问题特别好，正好接上前面讲的那点。这时候特别需要人参与，而人最重要的价值就是 Context Provider。过去多少年的经验，任何大厂都没有把这些知识沉淀成模型能学会的东西，只能由人来提供上下文。而提供的 context 准确不准确、性价比高不高，直接决定 AI coding 或 AI agent 的最终效果。所以不是模型能力达不到，是给的 context 不够好。

他给了两条路。一条是等模型变强，context 给得不够好也能 work，但成本会很高，而且模型迭代会越来越慢。另一条是现在很多公司在研究怎么把 context 提供得更好。对个人来说，怎么给 AI 提供更好的 context，会成为未来 AI 工程师一项特别核心的价值和技能。曲凯把这句话翻译回他 PPT 上的公式：人加 AI 大于 AI。

## 怎么筛出真会用 AI 的人 33:07

有人问除了 coding，AI 在哪些工作里好使。任川说研发的每一步 AI 都有很大帮助，另一个他最近看得多的是 go to market。过去整个销售流程很长，从 SDR 到 account manager 到 customer success，一个客户要接触四五个人，有了 AI 之后流程可以大幅压缩，一个人从 initial contact 就能走完。硅谷现在很多公司在做 GTM 自动化，他觉得大有可为。

关于怎么打造 AI Native 团队、有没有从传统团队转型，任川说他们幸运在公司新，没有历史包袱，去年四月创立、六七月开始做这套东西，一开始就是全新的方式。当时的现实问题是人不够，只能想办法。确实有很多人不适应，比如在 Google 做了七八年、vim 用到专家级的人，连 Cursor 都不愿意用。他的感受是，**经验在这个时代不那么重要，很多时候经验会变成负担。**数据量不大，但他们发现最适应的是刚毕业的年轻人，学习能力和欲望强，读书时就离不开 ChatGPT，上手非常自然。这样的人不好招，但会越来越多。

怎么找到会用 AI 的人？两个方法。第一个是不做一小时面对面面试，直接给 take home：两天时间 build 一个产品，两天做不完，必须用 AI；回来聊半小时，讲清楚怎么做的。这样能验证两件事，东西确实是两天内做出来的，说明 AI 用得好，手写更是大牛；以及他对内容有理解，能讲出过程，比如一开始用了什么办法不 work，怎么调 prompt、调 instruction 才跑通。第二个方法还在尝试，给一个现成的大型 project，里面埋了很多雷，一小时内在 AI 辅助下做改进。人眼看一小时什么都干不了，只能靠 AI 快速理解。

虞快追问了一个招聘里的现实问题：背景很强的人，凭什么愿意花八到十小时做 take home？任川说这本身是筛选，发下去大概十分之一会做。refer 来的会考虑例外，普通投简历基本不可能。他也承认可能因此跑掉特别好的候选人，但看的是综合效率。

曲凯分享了自己公司的做法：所有岗位都用 take home，但发任务之前先聊，判断这人可能性高才发，并且给市场价大约 30% 的报酬。比如招产品经理，一套完整的用户调研、产品方案、数据埋点设计正常要五千块，他们告诉候选人做完给一千五。候选人不会觉得被白嫖，公司也能看到 take home 的质量。

## AI review 不看指标，看工程师开不开心 36:27

有人问 AI code review 有没有可量化的指标，比如命中率、误报率，效果不好怎么调。任川说基本不用这类指标，一是现在挺难量化，二是主要看工程师的主观感受。他讲了一个有意思的差别：人给人 review，被 review 的人感觉是在被挑刺；AI 给人 review 之后，人会特别感谢 AI 帮他挑出问题。因为代码进了生产环境再出问题，只有写代码的人负责，AI 提前把错误改掉，人是开心的。所以他们更多是互相分享哪个 AI review 工具最有用。用下来，Cursor、Copilot 都不太好，CodeRabbit 也不是每个场景都好，有时会瞎说。

追问：AI review 会不会检查产品需求的逻辑，还是只看 bug 和安全漏洞？任川说分两种情况。如果是实现新功能，比如一个新的 service，输入输出是什么、要满足哪几条功能，这些会写进 prompt 或 init 文件里给到模型，模型知道你要实现一二三四，发现代码没实现就会提出来。如果只是改 bug 或者改某个模块的小功能，离最终需求比较远，模型可能就不管了。说到底还是 context，有需求的上下文，模型就会把它纳入 review。

AI 生成代码的比例，任川估计至少 90%，默认 AI 写，人在必要时改。

关于不同阶段需要什么角色，任川说自己没有五十人、一百人的经验，只有一个原则：按结果分工。每个人都是来解决问题的，人和人之间只要对齐清楚要解决什么问题、目标是什么，然后你解决这个、我解决那个，具体怎么解决不分工、不限制，让每个人自己发挥，当然要用 AI。虞快补了 Mercor 的实际变化：公司变大之后开始多招 security、QA、testing 的人；早期每个人负责一个 feature，后来开始问 scalability 怎么办、developer experience 怎么办，platform team 和 platform engineering 就出现了。

## 核心业务敢不敢交给 AI 40:58

最后一个技术性追问分三层：十分钟 review 也可能漏掉 P0、P1 级事故，核心业务是否要区别对待？高优先级业务怎么避免事故？除了修 bug，脏数据和用户补偿这类善后也是 AI 做吗？

任川先纠正一个理解：第一条原则不是无脑所有东西都让 AI 做，而是思路的转变，先假设 AI 可以做，一做发现问题不行，再让人来。区别在于，如果反过来先按传统流程什么都让人做、发现某处能提效才让 AI 上，会漏掉很多机会。这是原则上的不同。

具体到核心业务，infra 相关的 AI 做得少一些，但比大多数公司还是多很多。他们的整个 infra 以 IaC 的形式存在 repo 里，AI 也会生成对应代码，只是人会多看一些；前端代码看得少一些，直接上线，出问题再改。AI 已经进入工作流，如果它未来 work 得越来越好，人自然会 review 得越来越少。

最后一个问题是招人：想吸引背景好、综合能力强的毕业生，人家说刚毕业凭什么来初创、要去大厂；资深的工程师又不太适应新的 AI 工程习惯。渠道在哪，该看什么特质，怎么做差异化激励？

任川把这个问题接回第三部分的最后一点：慢慢不能把人当全职员工，要当合伙人。另一个观察来自他的创业朋友：与其招人，不如提升自己。先用好 AI 工具，可能现有团队就能 cover 掉原本要招的人的工作。他见过一些朋友创业，两三个人忙不过来就招人，招完发现比之前还忙。

虞快补充了一条反直觉的经验：越是强的人，越要给他很难的面试流程。强的人对你有天然的好奇心，如果你让他感觉你在求他加入，他不会来；反过来，面试让他觉得这家公司没怎么听说过、面试方式跟别人不一样、题还挺难，他反而更可能加入。

这场分享的价值不在于给出一个标准答案。任川反复说自己只试了一年多，对未来的预测没有那么确定，五十人、一百人之后会怎样他不敢讲。但有些东西已经可以带走。

如果你在带团队，可以先改一个默认值：**先假设 AI 能做，人只在它做不到的地方补位，而不是反过来。**这个顺序一换，能交给 AI 的工作会比你以为的多。接着砍掉不必要的交接，让一个人端到端负责一段结果，工程师直接去见客户，比加一层 PM 转述更有效。招人时别只问会不会，给一个两天做不完、必须用 AI 的 take home，让他讲清楚过程，比一小时面谈更能看出深浅。至于那些理不清的历史代码，答案不在等一个更强的模型，而在有人愿意把上下文喂进去，这项能力本身正在变成 AI 工程师的核心价值。