当写代码不再是瓶颈，产品工作变成了什么｜Ramp 首席产品官 Geoff Charles

Geoff Charles 用赛车作比喻，把注意力从个人写代码的速度转向整个系统。在产品工作中，他认为计时应从客户出现痛点开始，到产品解决问题时结束。构建环节加速，只有放在这段完整旅程中才有意义。

标题里“编码已解决”的前提是刻意简化的。Charles 随后也作了限定：一个瓶颈改善后，下一个就会出现。定义、审查、测试、协调和持续改进，都可能限制整体流动。他建议围绕当前约束重做产品工厂，而不是只庆祝代码产量。

客户痛点散落在通话、支持系统、录屏、问卷和直接消息中。Charles 说，最初集中广播抱怨的频道很快变得不堪重负。问题不只是摘要不够好，而是如何从割裂来源中找出真正有用的上下文。

他描述了重新建设的系统：常规数据管道、向量搜索和聚类，再加上产品与团队背景。聊天、仪表盘，甚至播客，提供了不同的访问方式。尤其重要的是，他说目的是借助可追溯证据，知道下一步该找哪些客户交流，而不是用智能体摘要替代客户对话。

如果系统没有公司背景，一句“你想做什么”的空白提问并不是好起点。Charles 把 Glass 描述为连接用户研究、量化数据、战略、规格与代码库的智能体，用来帮助具体化问题，并探索实现上的疑问。

他希望得到的是组合成果：证明问题重要的定性与定量证据、编码智能体可以使用的需求，以及符合现有产品的原型。单独一份长规格或脱离系统的模型，都不等于这种交接契约。把 AI 称作思考伙伴，也不会免除判断证据和设计是否扎实的责任。

07:20查看原图

Charles 将 Inspect 描述为带有预备环境、能产出预览的编码智能体，并强调扎实的架构和代码库会让这类工具更有用。演讲报告了较大使用量，以及许多由非工程岗位发起的代码变更。

产量上升之后，压力就转向审查。按照他的介绍，Review Buddy 会结合代码库、安全要求和生成过程中的提示上下文进行检查，并联系合适的人类审查者。报告中的比例属于录制时 Ramp 的陈述，不是独立缺陷率测量，也不能证明所有改动都能绕过人工审查。真正的设计重点是上下文可见和升级处理，而不只是自动化百分比。

接着介绍的 Testo，会像用户一样在浏览器里操作不同配置。Charles 说，它既能报告阻断性错误，也能指出令人困惑的流程，或与设计原则不一致的地方。

他报告近期发现了数百个问题，但演讲没有证明测试覆盖完整，也没有提供与所有旧方法的受控比较。关键循环在于：发现的问题会返回团队，进入修复。生成加速并没有使验证变得多余，反而增加了让验证能力跟上规模的需要。

Charles 把人的注意力称为下一个瓶颈：流程太多拖慢建设，太少又让所有人困惑。他以 Gadget 为例，将问题连接到路线图、规格、工单和客户通话等正式记录。

智能体可以用证据回答项目状态问题，识别负责人，协助更新记录或准备发布材料。不能回答时，就转交给人，并把答案反馈回系统。报告的回答比例是内部陈述，不是保证。可复用的原则是：智能体需要能读懂组织，而组织记录也需要持续有意义、有人负责。

Charles 希望产品经理摆脱持续不断的微小被动任务，把注意力放到更大的机会。他描述的小循环包括分派问题、去重和排序、制定计划、在 Slack 获得人工检查、写代码、通过测试与 CI，以及发布后更新知识库。

演讲报告的快速 UX 修复比例，不能被读成所有工作都已无人监督，因为其流程本身就包含批准和验证。选择高杠杆瓶颈，也不保证业务十倍增长。他把约束视为集中资源的理由，而不是要求听众照搬演讲中的每一个内部工具。

Charles 勾勒了三个方向：改善产品生产方式的技术型工厂建设者，把握方向与质量标准的品味判断者，以及跨职能负责更完整业务结果的总经理型角色。

这些是他提出的路径，不是所有产品岗位的既定未来。结尾强调的是持续重做：台上展示的工具会过时，其他团队会学习，下一个瓶颈还会出现。持续的任务，是缩短真实问题到经过检查的解决方案之间的距离，同时保留让方案值得发布的判断。