ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← Home NO.112
第 112 期 · 思维模型 · 收录于 2026 年 8 月 15 日

Ramp的持续划范围

LM
Leo Mehr · AI Engineer
视频 14:04 原文约 1.2 万字 预计阅读 10 分钟 来源视频 ↗ 中英对照全文
双人对谈 · 本期速读电台 00:00 / 23:27
TL;DR · 三句话
  1. FDE 的工作不是对客户一路说 yes,而是「永远在划范围」(always be scoping)——一味点头交付出来的不是 Waymo,是「马腿上绑几支火箭」;周五晚上销售冲进来说「不做 SAP 集成这单就签不下来」,训练有素的第一反应是停一秒问「这个急,到底是谁在急」。→ 详细
  2. 光会划范围也不够,还得「跟着 token 扩张」(scale with tokens)——把工作链路摊开(收集上下文 → 划范围 → 写 spec → 实现),每一环都可以换成 agent;Ramp 用 Notion agent 接管需求追问这一环,响应从几小时/几天变成几秒,省掉约两成的划范围时间。→ 详细
  3. 两条腿缺一条都会摔:只会划范围不肯建 agent 工厂,会被原生靠 agent 干活的对手直接超掉;工厂建得漂亮但范围划不清,只会得到一门「token 拉满的垃圾产出加农炮」——而无论自动化到哪一步,最终产出的品味和判断,责任仍然在人身上。→ 详细
01

讲者是谁:Ramp 的 FDE 从 2 人长到 30 人

  • Leo Mehr,Ramp(美国金融科技公司,做企业支付与费用管理)工程总监。两年半前加入时 FDE 只有两个工程师,今天他这个组约 30 人,分四块:deployed(驻场交付)、developer API、新的 AI services 业务。FDE = Forward Deployed Engineer,大白话是「派到客户现场去的工程师」,既写代码又直接面对客户,岗位由 Palantir 带火。→ 详细
  • 他开场先否掉流行说法:那张把 FDE 画成「技术型 go-to-market 岗位的最终进化 / 满级 boss 形态」的 meme,他觉得好笑但完全不认同。在 Ramp,FDE 长在工程组织里、不归销售,目标是帮公司「打赢上探大客户(win upmarket)」。→ 详细
02

全场只讲两件事

  • 14 分钟只有两条原则(他说「真的就两件,所以这场分享特别轻松」):always be scoping(永远在划范围)scale with tokens(跟着 token 扩张产能)→ 详细
03

最大的误解:以为 FDE 的活就是说 yes

  • 「很多很多人觉得,做 FDE 的活儿就是对客户一路说 yes。」他直接判死刑:这是错的→ 详细
  • 配的那张图很毒:如果你只会说 yes,今天在旧金山满街跑着载人的就不是漂亮的 Waymo,而是马腿上绑几支火箭。意思是——客户要「更快的马」,你逐字照办,就会造出一个荒唐、危险、根本不该存在的东西。→ 详细
  • 但他也没有滑到另一个极端。原话是:你当然想帮客户成功,你也确实要想办法找出一条能说 yes 的路径;只是你真正要交付的是好软件,你得做对的东西,所以不能无止境地对人点头。划范围不是学会拒绝,是学会在点头之前先弄清楚点的是什么头。→ 详细
04

案例一:周五晚上的 SAP S/4HANA

  • 场景(他说这类事在 Ramp「换着花样、隔三差五就会上演一次」):周五晚上,一个 enterprise 销售冲过来提紧急需求——有个特别重要的战略客户,只有把 SAP S/4HANA 的集成做出来才肯签。(S/4HANA 是德国 SAP 的大型企业管理系统,大公司用它管财务和供应链,接进去通常是个不小的工程。)→ 详细
  • 工程师的本能反应他学得很像:「完了,SAP 的 API 文档在哪儿?我上哪儿找,这集成到底怎么写?」——这个反应看起来极其敬业,却已经默认接受了整个前提:这件事该做、现在做、按这个形态做。→ 详细
  • 训练有素的 FDE 会先停一秒,问的第一个问题不是「怎么做」,而是:「等等,首先,这个『急』到底是谁在急?」→ 详细
05

「这个急,到底是谁在急」

  • 他给出的真实答案很扎心:他见过的一种情况是,销售之所以火烧眉毛,是因为季度末到了、他要冲自己的 quota(业绩指标)把单子签掉,而并不是客户那边真的在催→ 详细
  • 这一问把「紧急」拆成了两半:别人的日历压力真实的业务后果——前者会伪装成后者传到你桌上,而且传得理直气壮。→ 详细
06

划范围的提问清单,和那个最重要的动作

  • 停下来之后要做的事是问一大堆问题去收集上下文,判断到底什么才是重要的、真正该做的是什么。他现场列的几问:这个集成到底谁在用?各种变通办法我们都试遍了吗?眼下有没有什么人工的法子能先顶一阵?客户自己有没有技术资源?他们能不能直接调我们的 API,这样我们干脆不用做这个东西?→ 详细
  • 但他说 FDE 最重要的一个动作是另一件事:把目光从这一个需求上挪开,去看 pipeline 里正在推进的其他潜在客户、以及别的现有客户,看看还有没有谁也能从这件事里受益。→ 详细
  • 这一步的本质是把单点请求放回队列里称重:只服务一个客户的定制件,和能摊到五个客户身上的通用件,是完全不同的两笔账。他给的道理很朴素——「把这些上下文都拿到手,你才更有把握把对的东西做出来。」→ 详细
07

案例二:两个平台肝完,客户全员用 iOS

  • 这是他口中「早期特别惨痛」的故事。一个大 enterprise 客户需要手机端的报销(reimbursement)功能,但 Ramp 的 mobile 团队当时忙得完全脱不开身。→ 详细
  • FDE 只能自己上:让组里两个工程师现学 iOS 和 Android 开发。他形容当时的状态是「特别爽、都很兴奋」——「好,这个功能我们要上线了,肯定特别棒,太带劲了」。然后埋头肝了几周,两个平台都做完了→ 详细
  • 交付时他们问客户:能不能把你们 Android 这边的 beta 用户名单发来?「这时候他们才告诉我们,公司强制规定所有员工只能用 iOS 设备。」内部的反应是一句脏话——Android 那一半,从头到尾没有一个用户→ 详细
  • 他提炼的教训不是「别学新技术」,而是:哪怕最基本的假设——比如你到底要在哪个平台上做——都非常有必要专门去验证一遍。越是显而易见、越是没人怀疑的前提,越容易一路带着跑到交付日才炸。→ 详细
08

第二条原则:把自己的活拆成流水线,每一环换成 agent

  • 转折句:「假设你和你的团队已经把 scoping 练成了绝活……但光有这个还不够。除非你能跟着模型能力一起往上走,否则你就会被落下。」他的说法是我们现在得不停地重新发明自己的工作——今天做的大部分是知识工作,就必须想清楚怎么让模型和 agent 替我们做掉。→ 详细
  • 落到 FDE 身上的具体解法:把整条工作链路摊开看——收集上下文 → 给需求划范围 → 写出 spec(需求说明书)→ 把功能实现出来——这条流水线上每一个环节都可以换成 agent。他承认第一眼挺唬人,但只要把问题拆开、一步步往前推,其实相当可做→ 详细
09

Ramp 的实战:一个 Slack 频道 + 一只小企鹅

  • 需求入口是内部 Slack 频道 #FDE requests:客户经理、解决方案团队、销售代表,碰到某个潜在客户或现有客户身上足够大的卡点,就发到这里。演讲里那条是团队 CSM(客户成功经理)Greg 发的,背后接的是一套 Notion 工作流(他还专门谢了在场的 Notion 同事,说「我们真的太依赖 Notion 了」)。→ 详细
  • 真正的痛点是质量方差极大:有人会从客户那里带回非常详细、写得很到位的需求;有人只丢一行字——「我们需要那个 SAP 集成」。以前 FDE 得人工一条条啃:整份读完、理解清楚、搞明白产品里现在到底有什么、再跟客户来回沟通好几轮——他明说,这正是前半场那件事,always be scoping。→ 详细
  • V1 极其简陋:用 Notion 的 agent 搭了一版,干的活「字面意义上就是:接过需求,问几个问题。就这么点」。结果上线才几周就省了很多时间——响应延迟从几小时甚至几天变成几秒,销售和客户经理马上开始主动跟这个 agent 互动。后续版本还加了个小企鹅头像,他说这确实让它「显得更友好、更好接近一点」。→ 详细
10

省下两成时间,和「中间那段最难啃」

  • 现在这个 agent 会跟提需求的人来回追问好几轮,直到它判断可以出一份 spec 了为止。效果他形容为「大到不可思议」,给的数字是:大概省下了原本花在划范围上的两成时间(他自己说「具体我说不准,大概 20% 吧」)。→ 详细
  • 但他很克制地指出,这只是流水线的第一段。而最后一段(从一份成型的 spec 到能跑的产品)也已经不难——「现在的前沿模型基本上可以一把(one-shot)做出中等规模的功能」。→ 详细
  • 两头都变容易了,难的是中间:从「收集到的上下文」到「一份真正对的 spec」那一段,他的原话是「特别棘手、特别没成型、特别难搞」——AI 把两端吃掉之后,人的价值被挤压到中间那道判断工序上→ 详细
11

6-12 个月后的 FDE:在搭一座「工厂」

  • 他对未来的描述很具体:6 到 12 个月后,团队的全部时间会花在这一类「应用 AI」的问题上——为每一个环节造出对应的 agent,也就是「搭这座工厂」。→ 详细
  • 三件具体的活:① 确保跑每一步的那套 agent harness(承载 agent 运行的那层脚手架:怎么调工具、怎么串环节、怎么处理失败)运转得足够顺;② 确保流水线每一步的产出质量真的过关——靠 evals(自动化评测)、rubric(评分标准)、人类反馈;③ 最大挑战之一:在发起模型调用的那一刻,保证 agent 拿到的上下文是对的→ 详细
  • 关于上下文难在哪,他打了个很好的比方:想想一个产品经理脑子里装着的那些关于自家产品的知识——怎么才能把这些塞进一个 agent 里? Notion 文档、现有知识库、帮助中心文章「能覆盖的只有那么一点点」;剩下要靠 skills、memories、tools 这些手段去补。→ 详细
12

不外包的那一件事:品味和判断

  • 「归根到底,这里最重要的一点是:作为 FDE,最终产出的品味和判断,责任仍然在我们身上。这会是贯穿始终的那条主线。」——工厂可以自动化每一道工序,但质检的那双眼睛不能。→ 详细
13

收尾:两条腿缺一条都摔

  • 只有工厂、没有范围 → 你得到的是一门「token 拉满的垃圾产出加农炮(token maxing slop cannon)」,产能越大、废品越多。→ 详细
  • 只有范围、没有工厂 → 「那你也一样完蛋——那些原生就靠 agent 干活的竞争对手会直接超过你、把你打掉」。最后一句收得干脆:Always be scoping,同时 scaling with tokens。FDE 的未来,两样都需要。→ 详细
🎯 于你何益 为你定制 · 非通用结论

这一期跟你关系很直接,不用客气着写。Leo 讲的两条原则,一条正对你的元约束(一个人扛正职加多个副业,精力是最稀缺资源),一条正对你手上两个 agent 编排项目。下面按项目分。

一、你本人的精力与聚焦(这一条最重)

怎么做的。 整场演讲最硬的一句不是"要学会拒绝",而是那个动词形态:always be scoping——永远在划范围。他没有说"季度初排一次优先级",也没有说"建一个准入标准然后照着执行"。他说的是:每一个请求进来,都要重新停一秒、重新称一次重。周五晚上销售冲进来说"不做 SAP 集成这单就签不下来",工程师的本能反应是「完了,SAP 的 API 文档在哪儿」——这个反应看起来极其敬业,但它已经默默接受了三件事:这事该做、现在做、按这个形态做。训练有素的人第一句问的是「这个『急』,到底是谁在急」。他给的真实答案是:见过销售火烧眉毛,是因为季度末要冲自己的业绩指标,客户那边根本没催

你可以怎么做。 你现在同时扛着 ERP 正职、两个自媒体号、造 App 链路、第二大脑、投资看板和决策外脑——你的"销售"不是某个人,是你自己每一次兴起的新点子、每一条刷到的好方法、每一个"这个我也可以做"的瞬间。它们全都自带一种伪装成业务后果的紧急感。把「谁在急」这一问原样搬过来:这周每接一个新任务、新想法、新工具之前,先写一行字回答"如果这件事往后推一个月,具体会有什么事发生"。写不出具体后果的,就是季度末冲指标型的假急。更具体的落法:给自己开一个跟 Ramp 那个 #FDE requests 频道同构的单一入口——所有"我想做的新事"只准进一个地方(你的想法库就行),不准直接跳进日程;入口和执行之间隔一道称重。

再补一层。 他讲的那个"最重要的动作"你尤其该抄:别只看这一个请求,去看队列里其他事谁也能从中受益。他看的是 pipeline 里别的潜在客户,你要看的是你另外几个项目——同一件事,只服务一个项目的定制件,和能同时喂饱三个项目的通用件,是完全不同的两笔账。你已经吃过这个红利:wiifm 技能从视频总结里拆出来单独可跑,一份内容同时服务视频、书、巡检三条线。下次再有新想法,先过一遍这个筛子:**它只服务一个项目,还是能摊到两三个上?**只服务一个的,默认往后放。

二、Holdwell 的多-Agent PRD 工厂

怎么做的。 Leo 把 FDE 的活摊成一条流水线:收集上下文 → 划范围 → 写 spec → 实现,然后逐环换 agent。他给的进度报告非常诚实:第一环(接需求、来回追问)已经用一个极简的 Notion agent 接管了,省掉约两成的划范围时间最后一环(spec → 能跑的产品)也不难了,"前沿模型基本上可以一把做出中等规模的功能";难的是中间那一段——从收集到的上下文到一份真正对的 spec——原话是"特别棘手、特别没成型、特别难搞"。

你可以怎么做。 这句话直接说中了你那条从澄清到定稿的链路:两头都在快速贬值,你的护城河全部集中在中间那道判断工序上。所以工厂的投入重心该往中间挪——不是继续加前端的收集环节,也不是继续优化最后的成稿质量,而是把"上下文 → 该做什么"这一段的评判标准显性化。你现在的痛点里写着"碰撞协议纪律难落实"、"agent 产出缺可验证证据",Leo 给的正是那三件工具:evals(自动化评测)、rubric(评分标准)、人类反馈这周可做的一件事:挑你链路里最关键的那一道关(比如碰撞后的合成定稿),为它写一份不超过十行的 rubric(这一步的产出满足哪几条才算过),然后拿三份历史产出人工打一遍分。有了分数,评审才有牙齿;没有分数,纪律永远是一句口号。

还有一条更贴的。 他说 agent 化最大的挑战之一是在发起模型调用的那一刻,保证它拿到的上下文是对的,并且打了个正中你职业的比方:「想想一个产品经理脑子里装着的那些关于自家产品的知识——怎么才能把这些塞进一个 agent 里?」他的判断是 Notion 文档、知识库、帮助文章"能覆盖的只有那么一点点",剩下要靠 skills、memories、tools 去补。对到你:你六条产品线的跨线对齐难就是这件事的另一面——不是文档不够多,是产品的实体、状态、术语没有被结构化地写下来,所以每个 agent 每次都要靠散装文档猜。动作:别再想着"把知识库补全",先只补一件事——把 ERP 里最常被反复解释的那五到十个核心实体(各是什么、有哪些状态、跟谁关联)写成一份结构化清单,塞进所有 agent 的固定上下文。这比再写十份文档有用。

三、app_incubator(7-Agent 造 App 链路)

怎么做的。 Ramp 那个 agent 的 V1 简陋到不好意思说:"接过需求,问几个问题。就这么点。" 但它上线几周就见效了——响应从几小时甚至几天变成几秒,销售和客户经理开始主动去找这个 agent 聊。后来的版本才加了来回追问好几轮、直到判断可以出 spec。还有一个不起眼但很真实的细节:加了个小企鹅头像,"确实让整个东西显得更友好、更好接近一点"。

你可以怎么做。 你这个项目的痛点里写着"把该做什么前移到 agent"——Leo 给的就是最小可行版本的样子:不要一上来就造一个能出完整 spec 的 agent,先造一个只会追问的 agent。它唯一的职责是:你说一个 App 想法,它按固定的几问逼你(用户是谁、不做会怎样、有没有现成东西能顶、这事只服务这一个想法还是能复用)追到你答不上来为止,然后才准进入设计稿环节。这一个 agent 就足以把"该做什么"前移。另外那个小企鹅别当笑话看——你的采用率瓶颈也常常是"这个入口用起来别扭",内部工具的门面成本极低、回报很直接。

四、一人公司账号(build-in-public)

怎么做的。 这场演讲提供了一个现成的、可验证的观点句:"FDE 的活不是对客户说 yes",配一张极毒的图——只会说 yes,造出来的不是 Waymo,是马腿上绑几支火箭。加上一个真实翻车案例(两个工程师现学 iOS 和 Android,肝了几周两个平台都做完,交付时才发现客户强制全员用 iOS,Android 那一半从头到尾没有一个用户),和一个具体数字(把追问环节交给 agent,省下约两成划范围时间)。

你可以怎么做。 这是一条标准的"大佬说 X,我试了"选题原料,而且过得了你那道弹药库闸门——因为你能补上自己的实测:把"always be scoping"翻译成一人公司版的"每个新想法进来先称一次重",跑两周,记录你砍掉了几个想法、哪个砍错了。删掉你的判断和实测就不成立,这条就合格。标题方向(记得标题封面前置):「一个人公司最贵的成本不是钱,是你答应下来的每一件事」;或者直接用他那个反差图做封面概念——"你以为在造 Waymo,其实在给马腿绑火箭"。另外,Android 那个案例是最好的"翻什么车"素材模板:不是能力不行,是最基本的假设没人去验——你自己肯定有同构的故事(做了一版没人用的东西)。

五、第二大脑与摄入 SOP

怎么做的。 他收尾时造了个词:token maxing slop cannon——"token 拉满的垃圾产出加农炮"。意思是如果范围划不清,产能越大、废品越多。

你可以怎么做。 这正是你摄入 SOP 的信噪比问题的另一种说法:AI 让你"处理内容"的产能暴涨,但如果入库标准不变,涨的只是垃圾的吞吐量。你的 wiifm 档案里那条"宁可空,不要凑"的红线,就是你自己版本的防加农炮阀门——它已经在了,需要的是同样对"要不要转这个视频"生效,而不只是对"要不要写这段分析"生效。动作:在入库前加一问——"这一篇如果不转,我一个月后会不会想起它",答不上来就不转。


该反着用

Leo 说"你当然想帮客户成功,你也确实要想办法找出一条能说 yes 的路径"——这句话对他成立,因为他背后有 30 个工程师和一家要打赢大客户的公司,说 yes 的边际成本可以被团队摊掉。你的默认值应该反过来:先找出一条能说 no 的路径。同样一个请求进来,他的问题是"怎样才能做成",你的问题该是"能不能不做,或者能不能让别人/现成的东西做"。他清单里的"有没有人工的法子先顶一阵""客户能不能自己调 API"这两问,对你就是最高优先级选项而不是备选。还有一处也该反着用:他能靠人手并行去验证假设(两个工程师同时学两个平台),你不能——所以你的范围必须比他划得更早、更狠,因为你没有那种"错了还能补"的冗余。

和你现在做法冲突

Ramp 的第一版 agent 只做一件事——接需求、问几个问题——先上线,再长大。而你手上的 PRD 工厂是三驾马车加六步碰撞协议加真人评审的完整编排,是先设计完整条链路,再验证。两条路都有人跑通过,但张力是真的:他的路径能在几周内拿到"省了两成时间"这种可量化证据,你的路径在拿到可验证证据之前投入已经很大——而你自己最挂心的正是"agent 产出的可观测、可验证"。这里不替你下结论,只把问题摆出来:**如果只允许你保留链路里的一环去单独跑通并拿数字,你会选哪一环?**如果答不上来,可能说明这条链路目前还没有一个能独立证明自己的环节。

对你的镜子

你 2021 年写下的操作系统里有一句"问『该不该做』先于『做多快』"。always be scoping 是这句话的工程版,但它比你原来的表述多了一个关键区别:这不是一次性的。你可能一直把"该不该做"理解成年初定方向、季度定优先级这种阶段性动作——他讲的是每一个请求进来的那一秒,都要重做一次这个判断。你不缺这个原则,你缺的是把它从"决策时刻的原则"降级成"每天几十次的条件反射"。


所以呢

可迁移的思维模型:

  • 【耐用】「这个急,到底是谁在急」——把紧急感拆成"别人的日历压力"和"真实的业务后果"。这条跟 AI、跟岗位都无关,十年后照样成立,而且对你这种多线单兵的价值比对 Ramp 还大。
  • 【耐用】把单点请求放回队列里称重——不是判断这件事值不值得做,而是判断它相对于队列里其他事值不值得做。你缺的从来不是好想法,是把好想法互相比较的纪律。
  • 【耐用】最基本的假设最该验——越是没人怀疑的前提,越容易一路带到交付日才炸(Android 那一半)。
  • 【会过期】"前沿模型能一把做出中等规模功能,所以最后一段容易了"——这是 2026 年这个时点的能力快照,半年后"中等规模"的边界会再往上移一格;他自己也是这么讲的("6 到 12 个月后")。别把它当结论,当仪表读数。
  • 【会过期】"中间那段最难"——今天成立,但正因为所有人都在攻它,它也是最可能被下一代工具吃掉的一段。真正耐用的是它下面那句:最终产出的品味和判断,责任仍然在人身上。

判断更新。 如果你原来的判断是"agent 化要从建完整条链路开始",这一期提供了一个反例:Ramp 从最脏、最耗时、最标准化的那一环单点切入,几周就拿到了可量化的回报。至少值得把"先建完整链路"从默认答案降级成两个选项之一。

这周一个赌注。 选一件事:给你的想法入口装一道称重。不用写代码——在想法库里加三个必填字段:「谁在急 / 不做会怎样 / 它只服务哪几个项目」。这周所有进来的新想法都必须填完这三行才准往下走,周末数一下:填不满的有几条?那个数字就是你这周省下来的精力。

接着读