开场：为什么组织形式被低估
曲凯：我最近经常和不同创业者聊 AI 时代的组织形式。越聊越觉得，这件事的重要性仍然被低估了。中长期来看，新一代创业公司和传统公司之间最大的差距，可能不是模型、不是工具，而是组织本身。
传统大厂最大的问题，是分工太细。分工太细，就意味着很少有人真正对模型能力边界、用户需求和最终产品结果同时负责。反过来，创业公司几个人就能端到端做很多事情，他们更理解模型能做什么、不能做什么，也更容易围绕结果重新设计工作流。
这一期请来任川，讲 Palona AI 怎么打造 AI native 工程团队：90% 的代码由 AI 生成，20 人左右的团队没有全职 PM，工程师直接面对客户，并且把 AI 作为研发流程里的默认执行者。
任川：Palona AI 的背景
任川：我叫任川，来自 Palona AI。之前在 Google 和 LinkedIn 都做过几年。Palona AI 主要用 AI 帮餐饮行业提效，第一个产品是帮餐馆接电话：预约、点单、普通咨询，都可以端到端完成。
我们比较特殊的一点是，能把 AI agent 的可靠性做到 95% 到 98%。这意味着餐馆可以真的放心把电话交给 AI，而不是还要安排一个人在旁边盯着。
今天不讲技术细节，只讲背后的团队：AI native 的工作流，需要什么样的人，以及组织和分工应该怎么变。
Part 1 — 用 AI 重构研发工作流的经验
一个例子：code review 为什么不止十倍提效
在 Google，一次 code review 平均可能要一到两天。Google 作为古典互联网科技公司，工程效率已经非常优化了；但在 Palona，这件事大概是 10 分钟。
做法很直接：只让 AI review。AI approve 后，代码就可以 merge。听起来比传统流程激进，但因为 review 和修复速度足够快，如果线上发现问题，就 rollback，或者直接在线上修掉。
这不是无脑相信 AI，而是把流程从“默认人做，AI 辅助”改成“默认 AI 做，人补 AI 做不了的部分”。
默认由 AI 承担所有研发工作
这里说的是研发工作，不只是 coding。写文档、写测试、写设计文档、写代码、code review、上线后的监控，都先假设 AI 可以承担。哪里 AI 做不到，再让人补上。
这个视角会发现很多原本没想到的机会。如果先按传统流程让人做，只在“觉得 AI 很好用”的局部试 AI，就会错过很多可以被重构的环节。
亲测好用的工具
任务管理用 Linear。创建 task 后 assign 给 Devin，Devin 就能直接生成代码。这个过程甚至不需要打开 IDE，可以同时创建十个 task，让十个代码改动并行跑起来。
监控和 incident 处理用 incident.io。它会把 AWS、Datadog 等系统里的 log 汇总起来，自动分析、提醒，甚至给出 incident 分析。Palona 没有专门的 SRE，很多运维工作由工程师和 incident.io 一起覆盖。
有 SOP，就能交给 Claude Code
Claude Code 不只是写代码。只要一个工作流能被定义成标准操作流程，就可以基于 Claude Code 做二次开发，把很多协作自动化。
只要有 SOP，就没有 Claude Code 无法完成的任务。
减少人与人之间的交互
AI native 工作流里，人和人之间的交流很容易变成瓶颈。Palona 的原则是尽量让一个人端到端完成工作，减少“拉通”“对齐”和上下文传递。
如果真的需要 align，就把原则、想法和约束写进 codebase、文档和系统里。这样人和 AI 都能直接读取，团队不需要靠一次次会议维持同步。
Part 2 — AI 时代最需要什么样的人才？
人是 Context Provider
AI native 团队里，人的第一个核心价值是 context provider。真正的转变是：不要只把 AI 当成给人提效的工具，而是要看到人给 AI 提供 context、让 AI 变得更有效。
Palona 内部有一个原则：人加 AI 的产出，必须大于 AI 本身。这个听起来显然，但实际工作里，经常会发生相反的情况：人加入之后，反而让 AI 的效率变差。
不是 AI 给人提效，而是人为 AI 提效
很多 agent 或 AI 工作流不 work，不一定是模型能力不够，而是 context engineering 失败。模型没有拿到足够好的上下文，信噪比不够，最后效果自然不稳定。
这不仅适用于工程。做餐饮行业，真正理解餐馆怎么运转、老板每天怎么工作、服务员怎么接电话，这些行业 context 对模型同样重要，而且往往不是模型本身天然拥有的知识。
Fast Learner：快速掌握最少必要知识
快速学习不是指人还能比模型学得更强，而是能快速掌握最少必要知识，把问题定义清楚，并和 AI 有效沟通。
团队并不太在乎一个人当下会不会某个具体技能，更在乎他能不能把目标定义清楚、快速补齐必要知识，然后把 AI 的潜力激发出来。
每个人都是为最终结果负责的 Builder
Builder 指的是对最终结果负责，而不是只负责流程里的某个环节。如果有人只负责前期研究，另一个人再负责实现，中间就会产生大量 context sharing；只要有这层传递，AI native 团队的效率就会被拉低。
Part 3 — AI Native 的组织与分工
按结果分工，而不是按流程分工
传统组织是按流程分工：前端、后端、产品、设计、测试、运维，每个环节都有一个角色。AI native 组织更适合按结果分工。
比如一个小团队负责商家最终体验，另一个小团队负责消费者最终体验。负责 experience 的团队，前端工作可能多一些；但如果后端影响了最终体验，他们也应该能直接改后端。
为什么工程师也应该去跑客户
如果负责商家体验，就直接去找餐馆老板聊：这个东西好不好用？还有什么需求？传统链条里，老板先找销售，销售再反馈给 PM，PM 再反馈给工程，最后信息很容易走样。
工程师直接接触客户，一手反馈会更快进入产品和代码。这也是为什么团队不急着按岗位切得很细，而是让负责结果的人尽量拿到完整 context。
工程团队和其他团队如何协作
Palona 基本以工程团队为核心。工程团队先把功能做到 60 分，甚至 80 分，先上线。设计师、产品和其他角色再在这个基础上优化到 90 分、100 分。
过去大家说 talk is cheap, show me the code。现在生成代码的成本大幅下降，几乎变成 code is cheaper。既然如此，与其先开很多会追求完美设计，不如先做出一个 60 分版本，再围绕真实东西对齐。
未来组织：少量合伙人 + 大量合同工
当每个人都按结果负责，单个人的价值和影响会变得很高。核心全职成员可能需要接近合伙人的待遇，否则离职或创业都会对组织产生很大影响。
同时，很多行业 context 很强的人未必愿意 full-time 绑定一个组织。未来的组织结构，可能会变成少量核心合伙人，加大量灵活合同工。
Part 4 — Q&A 精选
20 人团队为什么没有全职 PM
曲凯：PM 在你们内部到底是什么角色？
任川：简单说，就是 engineer 兼职做 PM。现在团队差不多 20 人，至少在这个规模下，没有特别需要全职 PM。CEO 或 head of engineering 也会直接做很多 PM 的工作，因为从客户到工程师，中间少一层，效率会更高。
未来可能没有 Engineer，大家都是 Builder
曲凯：这会不会对 engineer 的要求特别高？这样的人好招吗？
任川：肯定不好找。但未来可能必须这样。最终要找的不是传统意义上的 engineer 或 PM，而是能为最终结果负责的 builder。有些人原来是 PM，不怎么写代码，但现在用 AI coding 工具也能 build 出自己的产品，这种人也完全可能适合。
硅谷是否已经形成 AI Native 组织共识
曲凯：你们这套东西在湾区已经是趋势，还是你们也算比较先锋？
任川：我们算比较先锋，但不算小众。可能不是最 aggressive 的，但 startup 里的思路基本都在往这个方向走。
大厂为什么难以转型
现场提问：大公司为什么不效仿这种方式？是不是只有十几二十个人时才 work？
任川：大厂转型有很多技术和效率之外的考量。Google 内部也有小团队在类似地做，但如果整个 Google 都转，会非常困难。另一个可能性是，未来也许不再需要那么大的公司了。一个人、几个人能做的事情已经非常夸张，我们可能需要重新思考什么组织规模才是必要的。
AI 能否处理复杂历史代码
现场提问：老代码很复杂，连人都理不清，AI 怎么帮我写需求？
任川：这正是 context provider 的价值。多年积累下来的系统知识，大模型本身没有，也很难凭空学会。人要把关键 context 提供给 AI，而且 context 的准确性和信噪比会直接影响 AI coding 的效果。
AI 还可以重塑哪些工作流
现场提问：除了 coding，AI 在哪些工作中比较好使？
任川：研发流程的每一步都会有帮助。另一个很大的方向是 go-to-market。过去销售流程从 SDR 到 account manager 到 customer success，一个客户可能要接触四五个人；AI 之后，这个流程可能被压缩成一个人端到端解决。
如何打造 AI Native 的组织形式
现场提问：你们是从传统团队转过来，还是一开始就这样？过程中有什么困难？
任川：比较幸运的是公司很新，没有太多历史包袱，所以从一开始就能用 AI native 的方式搭工作流。真正困难的是人。有些非常 senior 的工程师不适应这套新方式，反而是一些年轻、学习欲望强、读书时就离不开 AI 的人适应得更自然。
如何筛选真正会用 AI 的人
现场提问：招聘时怎么找到真的会用 AI 的人？
任川：一个方式是 take-home。题目会大到如果不用 AI，两天肯定做不完。回来之后聊半小时，不只看结果，也看过程：一开始怎么做，哪里不 work，后来怎么改 prompt、改 instruction。这个过程很能看出一个人是不是真的会用 AI。
怎么衡量 AI Code Review 的效果
现场提问：AI code review 会看命中率、误报率这类指标吗？效果不好怎么调？
任川：我们基本不用这种指标，因为很难量化。更多看工程师的主观感受。AI 帮你提前挑出问题，代码进 production 后写代码的人要负责，所以工程师反而会感谢 AI 提前帮他发现问题。
不同阶段公司需要哪些岗位
现场提问：公司从 10 人到 50 人、100 人，不同阶段应该增加哪些角色？
任川：核心原则还是按结果分工。大家先对齐要解决的问题和目标，然后分配谁负责哪个结果。至于具体手段，不应该限制太细。现场也有人补充，团队变大后 security、QA、testing、platform engineering 会逐渐出现。
怎样招到并激励 AI 人才
现场提问：优秀应届生想去大厂，senior 又不一定适应 AI 工程习惯，怎么招人和激励？
任川：一方面，核心人可能不能再只当全职员工，而要更像合伙人。另一方面，与其急着招人，不如先提升现有团队使用 AI 的效率。很多时候招人以后反而更忙，先看看现有合伙人能不能用 AI cover 掉原本想招的工作。
最后的判断
组织能力，而不是技术本身，可能才是 AI 公司真正的壁垒。
模型会进步，工具会普及，单点技术也会被追上。但如何组织一个团队，让 AI 做 90% 的执行，让人专注在 context、判断和结果负责上，这套组织能力短期内很难复制。
也许未来不再有传统意义上的 engineer、PM、designer，而是更多对结果负责的 builder。创业公司的机会，可能就藏在这种组织形式的重构里。