产品开发流程的瓶颈转移、自建代理实践与产品经理职能演变——Ramp首席产品官Geoff Charles演讲要点梳理（Lenny's Podcast，2026-09-25）

——据Lenny's Podcast节目《Inside Ramp’s AI factory: How product should look when coding is solved | Geoff Charles (Ramp CPO)》（2026-09-25）整理

摘要：本文对Lenny's Podcast节目发布的Ramp首席产品官Geoff Charles在Lenny and Friends Summit上的演讲主要观点进行了梳理汇总。梳理了其以赛车运动为喻提出的瓶颈转移框架，介绍了Ramp在痛点识别、产品定义、编码、评审、测试、协调与打磨等环节自建代理的做法与成效，最后归纳了其对速度衡量、资源约束及产品经理职能演变的看法。据其介绍，Ramp 75%的合并代码请求（PR）由自研编码代理生成，93%的PR由评审代理自动处理，向产品经理提出的问题中85%已由AI完全覆盖。

关键词：编程代理；企业代理；研发效率；组织变革；Ramp；Inspect

一、瓶颈转移框架与产品开发周期

Charles以职业赛车为喻，认为AI每消除一个瓶颈，就会把瓶颈推向下一环节，产品团队需要投资建设自己的“工厂”。

（一）赛车运动中的瓶颈消除

Charles从自己参加“24小时Lemons”业余耐力赛发生事故的经历谈起，引出其分析框架。一是车手对比赛结果的影响仅约15%，起决定作用的是车手、赛车与车队之间的配合，取胜之道在于消除驾驶环节周围的瓶颈。二是进站换胎用时由1950年代的67秒缩短至目前的1.8秒，他指出，这一约37倍的效率提升来自找到并消除瓶颈，具体包括专门化分工、更好的技术与更多的练习。三是一级方程式赛车（F1）车队每年更换90%的零件，一辆赛车1.6万个零件中仅10%沿用至下一年。他据此类比软件开发，认为代码每年更换90%“正是现在的标准”。

（二）产品开发周期中的瓶颈后移

Charles将上述框架套用于产品开发。一是计时起点为客户痛点出现，终点为客户拿到解决问题的产品，AI只是消除其中一个瓶颈并将瓶颈向后推移，胜出的团队能够率先找到下一个瓶颈、将其消除并继续转向下一个。二是产品开发周期依次包括定义、规划、创造与打磨，工程师已将大量写码工作自动化，写码难度显著下降。三是瓶颈由此转向产品一端，产品团队需要定义更多、协作更多、协调更多、发布更多、测试更多。

基于此，他建议产品经理“像工程师一样懒”，投资建设自己的“工厂”，并按五个步骤介绍了Ramp的自动化进展。

二、痛点识别与产品定义环节的代理实践

在产品开发前端，Ramp重点解决从噪音中筛选信号、将AI接入自有系统两方面问题。

（一）客户洞察代理

Charles表示，识别问题的难点在于孤立系统过多、意见过多，首先要解决的瓶颈是从噪音中筛出信号。据其介绍，客户痛点散落于Gong的销售通话记录、Zendesk工单、LogRocket用户会话回放、调查问卷及写给管理层的投诉信中。他给出一个尺度：100万token的上下文窗口容纳不下Ramp的Gong记录的0.5%，因此只能从小处起步。Ramp起初设立“仇恨频道”，每天将客户的负面评价贴入Slack，这一做法很快失控，他坦言“我对此并不自豪”，随后推倒重来，建设了客户洞察代理。该代理的功能包括：一是从公司全部数据源取数，采用传统的抽取、转换、加载（ETL）管道与向量检索；二是按相近语境对反馈进行聚类；三是理解Ramp的产品、团队与功能划分，并向全组织开放。

在推广使用方面，Ramp进行了多轮实验：一是可在Slack中直接提问的代理；二是登录即可阅读的HTML看板；三是Charles较为偏爱的“仇恨播客”，一天从收听一百位客户对产品不足的抱怨开始。他强调，这套工具旨在让员工尽快接触数据，与客户交谈仍有必要，其价值在于借助可追踪的数据精确指明应与哪些客户沟通。

（二）产品定义代理Glass

Charles认为，市面上的AI工具大同小异，开口即问“你想做什么”，面对超级智能，这未必是理想的起点，使用AI的意义在于将其接入自有系统。基于此，Ramp自建了名为Glass的代理，并为其提供全部必要的上下文。一是接入公司全部系统，能够读懂Snowflake中的数据与用户研究，定位客户想要解决的问题，结合定性与定量数据给出具体判断。二是理解Ramp的产品策略、技术需求的定义方式与代码库，产品经理无需再反复向工程师确认“这能做吗、会不会弄坏什么、我漏了什么”，改为向AI提问，Charles称“AI成了你的技术负责人”。三是理解产品原则、设计系统与代码库，产品经理可直接在真实产品中定义并搭建可运行的原型。

（三）产品与工程之间的“新契约”

据此，Charles重新界定了产品与工程之间的契约。他表示，工程团队无需单独拿到原型，“原型没用”，也无需长篇规格文档，“那也没用”，其需要的是三者的组合：一是证明问题存在的定性与定量数据；二是可直接输入编码代理的真实需求；三是能够提供灵感的原型。

三、编码、评审与测试环节的代理实践

Charles认为，每解决一个瓶颈，下一个瓶颈随即出现，编码、评审与测试依次成为约束环节，Ramp针对各环节分别自建代理。

（一）编码代理Inspect

Charles认为，现阶段每家公司都应拥有自己的编码代理。Ramp自研了名为Inspect的编码代理，旨在建立稳健的工具链并确保代理真正理解自家代码库。其特点：一是在Slack中工作，配置完备，数秒内即可启动；二是可将成品部署至预览环境，产品经理可直接使用并与正在生成的代码交互。

据其介绍，Ramp全员均已可以编写代码，使用情况如下：一是Inspect已累计运行100万次会话；二是Ramp 75%的合并代码请求（PR）由Inspect生成；三是上月有一千个PR由非工程师提交。值得注意的是，他同时指出，编码代理仅在架构强健、代码库质量较高的前提下才能有效运转，满足这一前提，公司内能够使用AI的人群范围才会扩大。

（二）评审代理Review Buddy

代码产出大幅增加后，验证成为新的瓶颈，工程师需持续评审海量代码。Ramp为此开发了Review Buddy：一是理解代码库、质量标准与安全问题；二是能够找到合适的专家参与评审；三是理解生成代码的全部上下文与提示词，能够核查“你是怎样使用AI的”，使评审与协作建立在可见的上下文之上。据其介绍，Ramp 93%的PR已由Review Buddy自动处理，资深工程师得以将时间集中于剩余7%真正关键的PR，处理“我们做对了吗、有没有风险”一类问题。

（三）浏览器测试代理Testo

测试随之成为下一个瓶颈。Charles指出，产品经理普遍熟悉搭建测试环境、修改设置、逐屏检查工程师是否遗漏关键功能的工作，Ramp将这一过程自动化，开发了浏览器测试代理Testo。一是基于Ramp可访问的真实生产数据，以100种不同组合运行产品，模拟用户在产品中操作，并可执行“付这张账单，但要分期摊销”一类指令。二是反馈内容既包括卡点、缺陷与问题，也包括被其称为“相当有想法”的设计与质量意见，如哪里表述不清、哪里破坏了设计系统或设计语言。三是上述反馈回流至产品开发周期。据其介绍，过去30天Testo共找出425个缺陷，他表示“这些错误由我们找出来，好过由客户找出来”。

四、协调与打磨环节的代理实践

发布节奏加快后，人的注意力成为新的瓶颈，Ramp通过协调代理与小循环自动化加以应对。

（一）协调代理Gadget

Charles指出，发布过多过快之后，产品经理被通知淹没，流程过多会拖慢开发者，流程过少则导致人人困惑。他提出“每个问题都是一个API”，并围绕这一原则设计系统。Ramp开发了名为Gadget的代理，理解每个提问的意图，并将提问接入正式的记录系统，包括Notion中的路线图、规格文档与客户通话记录，以及Slack与Linear中的工单。他认为，代理要具备能力，就必须能够读懂组织，组织也必须对代理保持清晰。

Gadget的用途主要有三方面：一是回答“项目进展如何、发布是否按计划”一类问题，掌握全局、明确下一步责任人、以事实作答，并更新路线图、发送状态通报、催促延误人员；二是回应销售部门关于功能内容、销售方式、巴西是否可用、使用方法与定价等问询，无法作答时转交相应人员；三是在发布环节撰写帮助中心文章，协助撰写博客与客户信。据其介绍，目前向产品经理提出的问题中85%已完全由AI覆盖，未能作答的问题经处理后回流至系统。

（二）打磨环节的小循环自动化

打磨环节完成后，产品开发周期重新开始。Charles认为，产品经理天然倾向于承担显眼、确定可完成、能带来即时多巴胺的小型被动任务，他称之为“巨大的错误”，专注小事难以成就远大抱负，必须将流程自动化才能跳出这些小循环。

Ramp让大多数小任务由AI独立完成，人工参与较少：一是将问题路由至相应团队，与Linear中的待办事项比对，完成去重、计数与排序；二是执行计划，必要时通过Slack向相关人员确认“这个可以做了吗，我准备写代码了”；三是完成写码、测试及持续集成与持续部署（CI/CD），上线时同步更新知识库。他表示，数千个小循环处理数千件小事，人才能专注于大事。据其介绍，由客户、销售、支持团队或Ramp自身发现的用户体验（UX）问题，60%在24小时内得到解决。

五、速度衡量、资源约束与产品经理职能演变

Charles针对听众可能关心的速度衡量、资源约束与产品职能前景三个问题作出回应。

（一）速度衡量

关于如何判断自身变快、如何在保持质量的同时提速，Charles承认，这比赛道单圈时间难以量化得多。他以Niki Lauda在1974年试驾法拉利（Ferrari）赛车后向Enzo Ferrari直言操控、抓地与刹车均存在不足、工程师随即全部改进的经历为例，称这与Ramp的文化有相似之处。他认为，只有雇到了解真正高速的“车手”，将控制权交给对方并接受其挑战，才能判断自身是否足够快，这对部分领导者而言难度较大，也正是组织所需要的。

（二）资源约束

关于如何与不受约束的公司竞争，Charles表示，资源是有限的，“无论是工程师还是token”。他以2006年奥迪（Audi）车队为例：其赛车速度较慢，于是选择在燃油效率上取胜，减少进站、延长在赛道上的时间，连续三年赢得勒芒耐力赛（Le Mans）。他据此认为，约束迫使企业选择一个能够做到世界一流的维度，“拥抱你的约束，但别拥抱你的瓶颈”，应找到可能使公司增长十倍的那个瓶颈并从此着手。

（三）产品经理职能的三条路径

关于产品经理是否在将自身工作自动化，Charles认为，产品经理从大量工程师可自行处理的事务中退出是好事，将带来巨大杠杆，无须担忧。他提出三条发展路径：一是技术型产品经理，他认为当前对此类人才的投入远远不够，其职责是建设真正的“工厂”，识别组织中的瓶颈并拆除“刹车”，交付对象是帮助公司或AI打造面向客户产品的整套系统；二是“品味制定者”，相当于赛车中的车手，负责掌控方向、完成AI无法胜任的工作，守住好产品与好品味的标准，这一路径目前受到的关注较多；三是总经理型，产品经理将职责扩展至营销、销售、分析与运营，对真实业务结果负责并领导整个职能。

总的看，Charles将演讲内容归结为三点：一是速度体现为识别并消除开发流程中的瓶颈，每个组织都存在此类瓶颈；二是解决一个瓶颈后下一个随即出现，关键在于尽快逐一穿越；三是产品负责人应减少对所交付产品本身的关注，更多关注帮助更快造出产品的“工厂”。他同时表示，当天展示的内容实际上已经过时，正如F1车队相互借鉴，他希望听众借鉴并超越Ramp，一切取决于下一个赛季，并引用Enzo Ferrari的话“最好的Ferrari是下一辆”作结。