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

摘要

• 曲凯认为，组织形式可能是新一代创业公司相对传统公司的竞争优势和壁垒；Palona AI 约 20 人、没有全职 PM，至少 90% 的代码由 AI 生成。 任川的核心不是“用 AI 给人提效”，而是默认让 AI 承担文档、测试、设计、编码、review、监控等全流程，人只补足 AI 暂时做不了的部分；判断标准是“人加 AI 的产出要大于 AI 本身”。

• 这套工作流用更高迭代速度置换传统流程的确定性：Google 平均 1—2 天的 code review，在 Palona AI 被压到约 10 分钟。 公司从年初起不再强制人工 review，只要 CodeRabbit AI approve 就可 merge；线上出错便 rollback、revert 或直接 fix。但任川强调，这不是无脑放权，infra 类工作仍会少让 AI 做，并增加 on-call 时的检查。

• 真正稀缺的人才不是某个岗位专家，而是 context provider、fast learner 和 hands-on builder 的结合。 模型缺的往往不是智力，而是高信噪比的业务知识；人的任务是快速掌握“最少必要知识”、把经验写进可供 AI 使用的 context，并对最终结果负责，而不是把中间产物交给下一个角色。任川还以 Anthropic 排行榜上的“全球第一用户”刘小排为例：每月购买 200 美元的 Max Plan，token 消耗可达 5 万美元，几乎 7×24 小时使用 Claude API。

• 组织应从“按流程分工”转向“按结果分工”，因为人与人之间的交接很容易成为 AI 工作流的瓶颈。 负责消费者体验的人可以直接改 backend，工程师也会见餐馆老板、做产品、设计与 go-to-market；任川的原则是“尽量一个人独立 end to end”，把共识沉淀进 codebase，而不是反复开会 align。

• Palona AI 选择 velocity first：工程团队先交付 60 分版本，再由专业设计等角色推进到 80、90 甚至 100 分。 过去返工昂贵，先开会拿到完整设计有其合理性；现在“talk is cheap，但是 code 其实是 cheaper”，可运行的产品反而成了更高效的讨论介质。

• 小团队去 PM 化并不等于永久取消分工，规模化后的组织形态仍是本期最重要的未决问题。 任川不敢断言 50 人、100 人后仍无需 PM；另一位参与者提供的约 150 人样本也显示，虽然公司可能只有约两个 PM，但 security、QA、testing 与 platform engineering 会随着 scalability 和 developer experience 问题重新出现。

• 任川分享的一个仍在探索的方向，是少量“合伙人式”核心成员加一些专业合同工，可能比传统全职金字塔更匹配 AI Native 组织。 核心 builder 价值高、公司对其依赖强，传统“一岗必有 backup”可能难以维持；任川也建议创业者先别急着招人，因为“招来人发现比之前还忙”，不如先让现有几个合伙人用 AI 覆盖新增工作。

精读

1. 餐饮电话是检验 Agent 可靠性的硬场景

• 任川介绍，Palona AI 用 AI 帮美国餐馆接电话：预约、点单和普通咨询都能 end to end 完成，让店里的电话“不用再响”；当地接线人员至少约 25 美元/小时，自动化价值直接对应人工成本。

• 他的差异化主张是 95%—98% 的可靠性，而一般 AI Agent 产品做到约 70% 已经不错。前者意味着餐馆可以放心不再安排专人盯电话，而不是只把产品当作辅助工具。

• 曲凯介绍，Palona AI 去年 4 月成立，团队约 20 人、没有全职 PM，约 90% 的代码由 AI 编写；任川在后续问答中估计至少有 90%。这期没有展开达到可靠性的技术细节，而把镜头转向背后的组织：公司试图从一开始就按 AI Native 而非传统软件公司的方式工作。

2. 十分钟 code review 改写了“先确保正确再上线”的成本函数

• 任川用 Google 作基准：经过长期优化，其 code review 平均仍需 1—2 天；Palona AI 借助 CodeRabbit AI，把同一环节压缩到约 10 分钟，并在试行半年多后认为效率与效果都很好。

• 公司约在去年 6—7 月开始引入 AI review，从今年年初起不再要求人工 review；AI approve 后代码即可 merge。写代码的人仍对 production 结果负责，因此 AI 提前挑错时，“人会特别感谢这个 AI”，而不是把意见视为同事挑刺。

• 这套机制的关键不只是 review 更快，而是恢复也足够快：问题出现后可 rollback、revert，或直接在线 fix。传统流程每次变更都等 1—2 天时，这种高频试错不可行；10 分钟一轮时，风险收益比发生了变化。

• 团队不以命中率、误报率等指标衡量 review 工具，主要依据工程师的主观效用比较；其体验是 VS Code Copilot 不够好，Cursor、BugBot 也不是特别好，有时会“瞎说”，CodeRabbit AI 更适合当前工作流。

3. 默认让 AI 做完整研发，人类例外必须给出理由

• 任川刻意使用“研发工作”而非 coding：文档、测试、设计文档、代码、code review、上线与监控都先假设交给 AI。当前模型当然做不到全部，因此人的位置是补缺，但逻辑起点不能是“默认人做，偶尔发现 AI 能提效”。

• Linear 与 Devin 展示了新工作单元：创建 Linear task 后直接 assign 给 Devin，它自动产出代码；人甚至不用打开 IDE，还可以同时发出 10 个 task，让 10 份代码并行生成，这已不是传统工程师逐项编码的节奏。

• 监控侧使用 incident.io 汇总 AWS、Datadog 等来源的 log，自动分析、提醒，并在 incident 后给出一些分析，目前约覆盖 40%—50% 的相关工作。公司没有专职 SRE，而是由部分工程师配合工具完成运维。

• 对 Claude Code，任川的评价是“只要有 SOP，就没有 Claude Code 没法完成的任务”；它能力强、有 SDK、便于二次开发，且远不只会 coding。任川还介绍了 Anthropic 排行榜上的“全球第一用户”刘小排：他每月花 200 美元购买 Max Plan，token 消耗可达 5 万美元，基本 7×24 小时使用 Claude API。

• 任川提到，准备这次分享时他仍推荐 Claude Code，但称 Anthropic“上周好像”已经限制国内使用。

4. AI 团队的瓶颈从技能供给转向 context 供给

• 任川反转了常见叙事：“不是 AI 工具给人提效，而是人为 AI 提效。”一年多的实践里，人加入后拖慢 AI 或整个团队并不少见，所以最低标准不是有人参与，而是“人加上 AI 之后，它的产出要大于 AI 本身”。

• Context Engineering 的判断是，底层模型已经很强，Agent 或工作流失效更多源于上下文工程失败。遗留代码的听众质疑尤其尖锐：连维护多年的人都理不清的复杂逻辑，AI 怎么可能懂？任川的回答不是否认难度，而是把问题定位为 context 的准确度与信噪比。

• 业务 context 同样不可替代：团队有人在暑期经常去餐馆端盘子，对餐饮流程的现场认识可能并不存在于模型知识中。人的价值是把这类经验转化为模型可用的信息，而不是与模型比谁记得更多。

• 产品需求若被写进 Python __init__ 文件，包括 service 的目的、输入、输出及应满足的功能，AI review 便能检查实现是否完整；若只是远离最终需求的小模块或 bug 修改，缺少对应 context，模型就未必能判断产品逻辑。

5. 新型工程师只学习最少必要知识，但必须负责最终结果

• “Fast learner”不是迅速把自己学得比模型更强；任川直言，“人已经不可能比 AI 更聪明了。”团队更在意问题与目标是否定义清楚，只要定义清楚，就假设成员能快速补齐最少必要知识，再借 AI 解决。

• 第三个要求是 hands-on builder：即便只负责大产品的一部分，也必须对最终结果和全流程负责。只做前期研究或资料整理、再把产物交出去，会重新制造 context sharing，立刻拉低 AI Native 团队效率。

• 因而 engineer 与 PM 的边界开始失去意义。任川认识原本不会 coding 的 PM，如今也能熟练使用 AI coding 工具 build 产品；未来也许既不是“所有人都是工程师”，也不是“所有人都是 PM”，而是“大家就都是 builder”。

6. 按结果分工，才能减少前端、后端与产品之间的接力

• Palona AI 按商家最终体验、消费者最终体验等结果划分小队，而非设独立前端、后端、research 或运维流水线。体验负责人发现 backend 影响结果时就直接修改，不必排队寻找另一个团队。

• 工程师甚至直接拜访餐馆老板，询问产品是否好用、还缺什么。传统链条可能从客户到销售、PM、工程团队，最后再返回“做不了”；多次转述后信息已经走样，直接接触则把一手 context 留给真正执行的人。

• 任川把日常会议集中在中间 3—4 个小时，其余时段尽量无会；每人每天可提交约 3—5 个 pull request，自行写代码、接受 AI review、merge。原则是“尽量减少人和人之间的 align”，需要共识就把规则写进 codebase。

• 他没有宣称当前模式已是终局。未来仍可能重新出现分工，但不会再沿工业时代、互联网时代按流程切人的方式；其推测是 AI 最终或承担 95%—98% 的流程，人只补最后无法完成的部分。

7. 没有全职 PM，是缩短决策链而非取消产品判断

• 约 20 人的 Palona AI 没有全职 PM，工程师兼做产品，CEO 或 head of engineering 也直接承担 PM 工作。任川承认自己“不太知道”团队增长到 50 人甚至 100 人后是否仍可如此，结论只适用于当前小规模实践。

• 曲凯追问得很具体：传统 engineer 被认为擅长代码但较内向，PM 则负责理解用户、沟通与提炼；把两套职责放在一人身上，人才是否极难招？任川承认“肯定不太好招”，但认为对产品、AI 学习能力和结果负责可能会成为必需品。

• 另一位参与者以约 150 人、约两个 PM 的公司补充：一旦告诉 engineer 有 PM，很多本可自行决定的问题便会被推成“business decision”；PM 又必须回来索取技术与数据，最终仍由两人共同决策，只是增加 back and forth、削弱 ownership。

• 他的判断是，一个聪明且解决问题能力强的人没有理由只能作出好的 engineering decision，却不能作出好的 business decision；但随着公司扩大，security、QA、testing 与 platform engineering 仍会因 scalability、developer experience 等横向问题自然出现。

8. Velocity first 让代码从昂贵交付物变成对齐媒介

• 工程团队先承担研发、产品和设计，把新功能快速做成 60 分版本上线，而不是第一时间找 PM 或设计师。专业设计等角色再基于实物优化到 80、90 甚至 100 分，这就是“velocity first”。

• 旧流程先开很多会、拿到完善设计再动工，并非纯粹低效：过去 coding 成本高，反复重做会让工程团队崩溃。现在生成代码极便宜，任川改写那句老话：“talk is cheap，但是 code 其实是 cheaper。”

• 60 分产品让所有人围绕可运行对象 align，也解释了团队为何能在约一年内搭起复杂系统。它并不意味着质量永远停在 60 分，而是把专业优化从启动前的门槛，移到已有反馈的第二阶段。

9. 大公司难复制的首先是组织约束，不只是工具差距

• 一位听众质疑，这套方法或许只适用于十几、二十人；抖音等大公司内部也有编程工具，却仍沿用户调研、产品设计、研发、测试的流水线推进。任川承认规模化后可能不 work，自己只有一年多样本，对未来“没有那么确定”。

• 他的解释是，大厂转型受技术效率以外的约束。任川举“今天”微软 CEO 为裁员过猛道歉、需要重建员工信心为例；据他所知，Google 内部虽有小团队采用类似方式，但要让整个这么大的组织转向，难度完全不同。

• 更激进的判断是，未来也许“不再需要那么大的公司了”：一人独角兽已成为讨论对象，几个人能完成的事情令人难以置信。任川只是“比较怀疑”未来还需十万人公司做一个产品，并未把它说成确定预测。

• 曲凯由此提出投资与创业层面的窗口：中短期内，组织形式也许就是创业公司的壁垒；大公司要裁员、reorg 才能转身，新公司却可从第一天让少数 builder 端到端负责。任川自评 Palona AI“比较先锋，但不能算小众”，且还不是最 aggressive。

10. 招聘、风险控制与用工关系都要围绕 ownership 重做

• Palona AI 不依赖一小时面试，而给候选人两天 take-home，要求 build 一个不用 AI 几乎做不完的产品，再用半小时复盘：哪里不 work、如何调整 prompt 或 instruction。团队还在试验一小时理解带有大量“埋雷”的大型 project，以观察候选人能否借 AI 快速改进。

• 曲凯追问，背景强的人为何愿花 8—10 小时做 take-home？任川说发出后约十分之一会完成，这本身就是筛选；仅凭简历基本不破例，有 referral 才可能调整。另一位参与者分享付费方案：先筛高概率候选人，再按市场价约 30% 付费，例如正常值 5,000 元的 PM 全流程任务支付 1,500 元，以避免“白嫖”感。

• 经验并非无条件加分。任川见过在 Google 工作七八年、精通 Vim 或 Emacs 的 senior，连 AI coding 工具都不愿采用；反而是学习欲强、在学校已离不开 ChatGPT 的年轻毕业生适应更自然，但他明确提醒团队样本很小。

• 针对听众提出的 P0/P1、脏数据和用户补偿等风险，任川没有逐项展开，而是重申：默认 AI 能做只是思维原则，“并不是无脑所有东西都用 AI”。IaC 虽放在 repo 中并可由 AI 生成，infra 仍较少放权，并可能增加 on-call 时的人工检查；前端产品代码则更常直接上线、发现问题再改。

• 任川分享的一个仍在探索的方向，是少量合伙人加一些专业合同工：核心 builder 价值高、公司对其依赖强，传统“一岗必有 backup”可能难以维持，因而需要高于普通员工的合伙人式待遇；专业合同工则可把领域能力提供给多个组织，不必 full time 卖给一家。

• 任川给招聘焦虑的反建议是“与其招人，不如提升自己”：现有几个合伙人若真正用好 AI，可能已经覆盖原计划新增的岗位；现实中也存在团队稍忙就招人，结果“招来人发现比之前还忙”。另一位参与者则补充，强候选人往往会被独特且困难的面试激起好奇，而非被低门槛礼遇打动。