20 人、零 PM、90 % 代码 AI 写:Palona 如何把 Google 级流程压缩 144 倍?
导读: 在 Google,一次代码审查(Code Review)平均需要 1-2 天。而在湾区一家仅 20 人的 AI 创业公司 Palona AI,这个数字是 10 分钟——效率提升了 144 倍。他们是怎么做到的?答案简单粗暴:90% 的代码由 AI 完成,团队里甚至没有一个全职的产品经理(PM)。这不仅是工具的胜利,更是一场组织形态的底层革命。
一、主角登场:带回 Google "病历"的创业者
2023 年 4 月,前 Google 和 LinkedIn 工程师任川创立了 Palona AI。他没有带着大厂的光环,却带着一份清晰的"病历"——对传统科技巨头组织效率的深刻反思。
"传统大厂最大的问题就是分工太细,"任川在一次分享中提到,"一个功能从产品、设计、前端、后端到测试,链条过长,人和人之间的沟通成了最大的瓶颈。"
在 Google,一次代码审查(Code Review)流程走下来,平均耗时 1 到 2 天。这个在"古典互联网"时代被视为工程质量保证的"黄金标准",在 AI 时代却显得无比笨重。
Palona AI 的业务是为美国的餐厅提供 AI 电话接线员,处理预订和咨询。这是一个需要快速响应市场、高频迭代的场景。"客户的餐厅电话可等不了我们 2 天的内部流程,"任川说。
核心困境: 如何在资源有限的初创公司,实现远超行业巨头的迭代速度?
答案从创业第一天就已明确:必须彻底抛弃大厂的组织包袱,建立一个真正的 AI-Native(AI 原生)组织。
二、转折点:当 AI 成为默认员工
Palona AI 的革命,始于一个颠覆性的原则:默认所有研发工作由 AI 承担,人类工程师只在 AI 做不到的地方"补位"。
这与大多数公司"让 AI 辅助人"的思路完全相反。在 Palona,AI 不再是人的"副驾驶",而是**"主驾驶"**,人是那个在旁边看着,偶尔扶一下方向盘的教练。
这个原则下,第一个被颠覆的就是代码审查流程。2023 年 6 月,公司成立仅两个月,他们就上线了全自动 AI 代码审查工具——CodeRabbit。
"我们是当时少数这么做的公司,"任川回忆,"风险很大,但收益更高。"
传统流程中,工程师写完代码,需要排队等待资深同事 review。而在 Palona,代码提交后,CodeRabbit 会在 10 分钟内自动完成审查。只要 AI "点头",代码就可以直接合并进入生产环境。
"如果线上出了 Bug 怎么办?"
"很简单,1 分钟内回滚,或者直接在线上修复,"任川解释道,"因为下一次修复也只需要 10 分钟。当你的迭代成本足够低时,风险就变得可以接受。"
就这样,一个困扰行业巨头多年的效率枷锁,被一个简单的逻辑转换轻松解开。
三、AI 工作流拆解:144 倍效率的秘密
Palona 的高效并非只靠一个环节,而是一套完整的 AI 驱动工作流。
第一步:代码生成(Linear → Devin → Claude Code)
工作流程始于任务管理工具 Linear。一旦创建任务,可以直接指派给 AI 编程工具 Devin。Devin 会自动创建代码分支、编写代码、生成测试用例。整个过程,工程师甚至不需要打开自己的代码编辑器。对于更复杂的逻辑,团队会使用 Claude Code 进行二次开发和优化,因为其强大的上下文理解能力和 SDK 支持。
结果: 90% 的代码由 AI 生成,工程师的角色从"码农"转变为"代码指挥官"。
第二步:代码评审(CodeRabbit 10 分钟搞定)
如前所述,CodeRabbit 承担了 100% 的审查工作。它不仅检查代码风格和潜在 Bug,还能根据项目文档理解业务逻辑,判断代码是否完整实现了需求。
结果: Code Review 时间从 Google 的平均 1-2 天压缩至 10 分钟。
第三步:监控与运维(http://Incident.io,零 SRE)
在监控端,Palona 使用 http://Incident.io。这个工具能自动汇集所有云服务和应用的日志,通过 AI 进行分析,主动预警,甚至在事故发生后给出分析报告。
结果: 约 40%-50% 的运维工作被自动化,公司至今没有设立一个 SRE(网站可靠性工程师)岗位。
第四步:产品设计(工程师 → 60 分原型 → 设计师)
Palona 团队没有全职 PM。工程师在理解客户需求后,会直接使用 AI 工具(如 Midjourney 或各类 UI 生成工具)快速生成一个"60 分"的产品原型并直接上线。然后,专业的设计师再介入,将其优化到 80 分、90 分。
结果: "先上线,再优化"的模式得以实现。因为 "Code is cheaper now",代码的生产成本极低,快速试错不再是奢望。
四、理论支撑:「AI-Native 组织」的三大原则
这套激进的工作流背后,是三个核心的组织原则:
默认 AI 原则: 如前文所述,工作流的设计以 AI 为主体,人是变量。
单人端到端原则: 尽量让一个工程师独立完成一个功能的端到端(End-to-End)开发,减少人和人之间的沟通。因为在 AI Native 组织里,人与人的对齐(Alignment)最耗时,是最大的瓶颈。
按结果分工原则: 团队不按"前端"、"后端"等流程职能划分,而是按"商家最终体验"、"消费者最终体验"等结果划分。负责"消费者体验"的工程师,如果需要修改后端代码,就应该自己动手,而不是提交一个需求给后端团队。
五、成果与局限
这套体系的成果是惊人的:
团队规模: 20 人团队,零全职 PM,零 SRE。
研发效率: 代码审查效率提升 144 倍,90% 代码由 AI 生成。
产品质量: 核心的 AI 电话 Agent,在复杂的真实场景中实现了 95%-98% 的可靠性。
当然,任川也坦言这套模式的局限性:
规模限制: 目前只在 50 人以下的初创团队得到验证。
模型幻觉: AI 的"一本正经胡说八道"仍需要资深工程师来兜底。
复杂项目: 对于需要严格合规或极度复杂的系统工程,这套模式尚待验证。
六、结语:未来属于两类人
Palona AI 的实践,不仅是一个创业故事,更像是一场未来组织形态的预演。
它证明了,在 AI 时代,真正的壁垒已不再是技术本身,而是驾驭技术、重塑流程的组织能力。过去工业时代"分工越细,效率越高"的金科玉律,正在被 AI 的浪潮彻底颠覆。
正如任川所说,"未来组织里可能只有两种人:为 AI 提供高质量上下文的人,和为 AI 的产出打补丁的人。"
你是哪一种?
from 42章经
组织能力才是 AI 公司真正的壁垒 | 对谈 Palona AI 联创任川