← Home NO.113

第 113 期 · 产品 · 收录于 2026 年 8 月 15 日

伪装成交付的产品战略

Vinoo Ganesh · AI Engineer

视频 22:03 原文约 2.3 万字预计阅读 19 分钟来源视频 ↗ 中英对照全文

双人对谈 · 本期速读电台 00:00 / 38:37

TL;DR · 三句话

一FDE（forward deployed engineer，前置部署工程师）不是一个岗位，更不是销售动作，而是一套产品战略。 判断一个 FDE 干得好不好，不看他签了多大合同，而看他"能不能成为产品团队的延伸、识别出机会点、把解法泛化成产品"——这是 Palantir 现任 CTO Shyam（当年给 FDE 起名的人）的原话。→ 详细
二真相只在现场，而且客户描述的永远是解法、不是问题。 一家航运公司给了 47 页需求文档、14 个指标、三个月工期，团队照单全收做了四个月范围界定；直到有人真去了现场问一句"周一早上你拿到这些信息第一件事干什么"，答案是"看有没有车晚点"——4 小时，一条 Slack 告警，闭环关掉。→ 详细
三但"快"不等于"糙"：每一个 hack 最后都会进生产。 工程里最危险的一句话是"这只是临时的"——Vinoo 随手写的一个 Groovy 脚本跑了 12 个月、进了十万人规模的客户、最后成了他的外号（婚礼上有人穿印着 vinoo.groovy 的 T 恤）。交付时就当它要跑 18 个月来建，才能把补丁转成产品杠杆，而不是背一辈子的债。→ 详细

讲者是谁：从伊拉克、阿富汗一路做到 Kepler

Vinoo Ganesh 在 Palantir 从软件工程师起步，做的是"水平可扩展的存储方案"（简单说：数据涨了就靠加机器扛住，而不是换更贵的机器）。他本人被前置部署到伊拉克、阿富汗——照片是他在 Bagram 基地，那个基地现在已经没了。"forward deployed（前置部署）本来就是个军事术语，我们当年是当真的"：把软件搬进最要命的环境里去造，让它真正对最需要它的人管用。→ 详细
他最拿得出手的一件事叫 Project Frontline——一个把软件工程师"改造"成 FDE 的轮岗计划。今天在 OpenAI、Anthropic、xAI 看到的那些 FDE，大概 350 号人跑过这套培训体系。后来他在对冲基金 Citadel 又搭了一套同样的东西：怎么做出对的数据产品，帮投资经理挣到 alpha（超额收益）。现在他在 Kepler 和创始工程师之一 Susanna 一起，第三次搭这个职能。→ 详细

核心命题：FDE 是产品战略，不是 go-to-market 策略

他一上台就在拆前面几场演讲的台：Palantir 对 FDE 的强调后来变成了一套 go-to-market（进入市场 / 销售打法）策略，但一开始根本不是那么回事。2013 年他们摸索怎么把 Foundry 做出来，用的是产品战略这个镜头——而正是这个平台，才成了后来所有人能在上面继续搭东西的底座。→ 详细
他引用了当年在 Palantir 给 forward deployed engineering 起名的那个人、现任 CTO Shyam 的原话来定调："FDE 的第一条根本真理是——这不是一个岗位，这是一套产品战略。" 真正的内核洞察是：评判一个 FDE，看的是他能不能成为产品团队的延伸，能不能识别出机会点，并把解法泛化成产品。 至于"盯着公司市值倒推合同能签多大"的那套打法——他直说：那不是当年真实发生的事。→ 详细
这场分享的全部目的只为说服你一件事：当 FDE 是产品职能的延伸，不是 go-to-market 职能的延伸。 接下来他讲四个亲历的真实故事，以及这些故事怎么反过来塑造了他在每一家机构里搭 FDE 的方式。→ 详细

反面教材 Phoenix（2013）：一个在真空里设计、出生即死亡的存储系统

早年 Palantir 刚想切进大数据，2013 年冒出个想法要存交易数据，做出来的产品叫 Phoenix。他的原话是："Phoenix 完全是在真空里造出来的。我们没跟客户聊过，不了解我们的金融、银行客户，什么都不了解。" 他们在完美隔离的条件下设计了一个系统——它在特定条件下跑得天衣无缝，一撞上真实数据就当场炸了。→ 详细
设计本身听起来很合理：给一家大型金融客户把数据按分桶的 keyspace（键空间，可以理解成一个个独立的数据分区）存起来，这样滚动淘汰旧数据、做数据留存都很省事。翻车链条是这么一环扣一环炸开的——很多银行和金融机构的数据并不干净，一碰到空值，时间戳就默认落到 epoch，也就是 1970 年 1 月 1 日；而他们的留存策略是把 1970-01-01 到 2013 年之间每 10 分钟切一段、每段起一个时间分桶的窗口；于是生成了 230 万个 keyspace；而底层的 Cassandra 每个文件句柄要 5 MB——算下来光把服务器启动起来就要 14 TB 内存。→ 详细
结果就是他说的四个字："出生即死亡"（dead on arrival）。而且当时没有别人可以求助——屋里就他们这一拨人、就他们这一家机构，没有前人踩过这个坑。→ 详细
复盘出来的教训不是"我们没做用户调研"这么表面。他把话说得很准："真正的缺口，并不在于我们没去打听客户是怎么用我们产品的。缺口在于：我们在没有真正嵌进客户现场的情况下，就把『和客户共同打造一个软件』这件事的所有权给认领了。" ——你可以远程收需求，但你不能远程认领"共建"这个身份。→ 详细

故事一：47 页需求文档 vs 一条 Slack 告警

Palantir 当时在导入一家大型调度和航运公司。跟他们的运营 VP 坐下来谈，对方产出了一份 47 页的需求文档：要一个定制看板、14 个指标、下钻、告警，一整套庞大的 BI 工具，一个预估三个月的开发项目。→ 详细
"这过程里挺搞笑的一点是，我们照单全收了。"——团队花了四个月做范围界定，想彻底搞清楚客户到底要什么。直到他们中有个人真的跑到了现场（纯粹因为他家人正好住那边，不是什么精心设计的流程），当面问了一句："周一早上，你拿到这些信息之后干的第一件事是什么？" → 详细
那个调度员的回答是："我看看有没有车晚点，然后打电话给调度，安排把新的库存调过去、或者换一家。" 整件事其实可以简化成一条再普通不过的 Slack 告警——最后他们做的就是这个。4 个小时，把这个问题从头到尾解决掉了。 47 页 / 14 个指标 / 三个月，对上的是 4 小时 / 一条消息。→ 详细
从这里提炼出的第一招是：识别出真正的问题，交付真正该交付的东西。"绝大多数时候，人们并不需要庞大的 BI 看板，不需要一整套从头设计到尾、完整成型的软件。他们有一个问题，他们要的是这个问题真的被解决。" → 详细

动手前必问的三个问题，以及 XY 问题

在你动手造任何东西之前，作为产品团队的延伸，你得先搞清三件事：→ 详细
1. 你到底想达成什么？ 也就是解决这个问题的核心目标是什么。
2. 拿到解法之后会发生什么？（客户手里有了这个东西，下一步的动作链条长什么样）
3. 客户今天是怎么解决它的？（今天没有你，他靠什么活下来的）
他把这归为一个 XY 问题（用户来问 Y，其实真正卡住他的是 X）。这一段是全场最短、也最狠的一句——"客户描述的是解法，不是问题。你作为 FDE 的活儿，是搞清楚问题到底是什么。客户也不知道下一步会发生什么，你作为 FDE 的活儿，是把它定义出来。" → 详细
顺带一提：他也点出现在 OpenAI 这类做 FDE 交付的公司，路子跟当年 Palantir 稍有不同——Palantir 当年的做法就是"派人去现场造东西"，那么问题只剩一个：造什么。 → 详细

一天之内能解掉的，就直接做掉：谁定义问题，谁拥有解法

他的操作准则非常直白："如果解决这个问题的工作量不到一天，那就直接做出来、上线、把这个闭环关掉。别把它搞成什么产品战略，别急着去扩展产品愿景、把 PM 拉进来、走一整套流程。" 这就是 Palantir 最初的起步方式。→ 详细
而这么干的真正回报，藏在一句他称为"秘密"的话里："谁定义了问题，谁才真正拥有这个解法。" 因为他们能亲眼看到那位航运运营人员的问题、能定义解法、能把真正的解法交付出去，他们就永远是那套系统的主人，也就有资格去描述后续的解法该长什么样。掌握了要造什么、也掌握了围绕这个解法的叙事，你的位置就会变得非常有力量。→ 详细

FDE 在早期销售里值钱，靠的不是嘴皮子

"这不是因为他们特别擅长跟客户打交道，也不是像有些人说的那样——我们这群软件工程师并不社恐。" 真正的原因是：用一小口一小口、能消化得下的方式解决客户的问题，赢得信任；而信任让你拿到接触真问题的入场券——之后才谈得上从产品战略角度把它泛化出去。→ 详细
Foundry 就是这么长出来的：一个能横跨众多行业的通用产品解法，背后是在一线做了成千上万小时这类小事沉淀出来的东西。→ 详细

故事二：抗拒 Parquet 的工程师，与当晚写出来的那个查看器

场景：他们每天要往某个客户的 S3 存储桶里扔大约 1 TB 数据，给自家数据管道造成很大压力。解法很简单——别扔一大堆 CSV，全迁到 Parquet（一种列式存储格式，体积小、读得快），对管道友好、对成本友好、对算力也划算。→ 详细
但有一位数据质量工程师近乎生理性地抗拒这件事。这事前后提了差不多一年，每次她都顶回来，理由永远是那句："Parquet 差多了，根本不好使，我理解不了。" → 详细
于是他们去现场看她把这个流程从头到尾走一遍。看到的是：她在手动把 CSV 从 S3 下载到自己的 Windows 电脑上，双击打开，肉眼抽检数据质量。这套动作在 Parquet 文件上做不了——当时 Parquet 没有一个能双击打开直接看的原生阅读器。他自己都觉得好笑："她抗拒得那么本能，其实根本没搞清楚这件事能给她带来什么好处。"→ 详细
那天晚上他们就写了一个 Parquet 查看器。两天之内她就批准了这次迁移。 数据成本大幅下降，管道执行时间从 17 小时降到大约 2 小时。一年的口头拉锯，输给了一个晚上的现场观察 + 一个小工具。→ 详细

现场观察清单：哪些动作在告诉你"这里有机会"

跟用户一起工作时，你本质上是现场的观察者，而行动比嘴上说的有说服力得多。他给了一份可以直接照着扫的信号清单：→ 详细
- 用户做了不止一次的任务——同一天重复做、一周做好几次、一小时做好几次，那就是一个模式，是"这里有问题也有机会"的提示。
- 在工具之间复制粘贴——把东西从一个工具搬到另一个工具，一定是机会。
- 那句无奈的回答——你问"你觉得这个问题怎么样"，对方回"我也没办法，只能这么干"，带着由内而外的无奈，那里就有机会。
- 切换工具或标签页。
- 任务做到一半掏出手机——要么这问题很烦人，要么这软件太慢了。
起手式只有一句话："你早上最烦的那件事是什么？" 而 FDE 的目标是：让他们的明天跟今天不一样。→ 详细
他再次把它拉回主线："你是靠解决一个个小而重复的问题，才赢得了挖掘用户痛点、定义产品战略的资格。"——这个资格是挣来的，不是岗位说明书给的。→ 详细

真相只在现场：门禁卡和邮箱就是你的"数据开采许可证"

"最有价值的情报，永远不会写在文档里。" 他们之所以能看到那位工程师（Maria）的困境，是因为刷卡进了对方的办公楼，人就在现场——阿富汗、伊拉克、Soho、Palo Alto、旧金山，都是这样。→ 详细
一个很好用的比喻："你在客户现场的门禁卡，还有你那个外部合作方身份的邮箱地址，就是你的数据开采许可证。" 每个 FDE 要做的第一件事，就是进到真正发生事情的那个房间里。这种东西没法靠发问卷调查出来。→ 详细
他也顺手扎了一刀："挂个名当 forward deployed engineer 太容易了——坐在纽约一间漂亮的会议室里就行——但真正的问题不在那儿，解法也不在那儿。" Palantir 内部的说法是：residents get the truth（住在当地的人才拿得到真相）。去现场。 → 详细

故事三：定义了语言，就掌握了叙事——ontology 是怎么被撞出来的

一个几乎每家公司都存在的现象：同一个实体，不同团队叫法完全不同——销售叫 customers，运营叫 clients，财务叫计费主体（billing entities），开发叫 org ID。后果是巨大的痛苦：集成会崩、会有数据质量问题、管道不停出故障。→ 详细
但他的判断不是"这些人应该统一术语"，而是更宽容也更准确的一句："我们都是人。我们定义事物的方式不同，是因为我们各自身处不同的环境，习惯用跟自己同类的人能听懂的方式去谈论问题。这是特性，不是 bug。" → 详细
所以 ontology（本体 / 领域语言体系）这个概念，某种程度上是 Palantir 无意中撞上的——它的来源不是"把所有东西塞进 Elasticsearch、把一切都定好 schema 就能解决所有问题"，而是一个朴素念头：让人能在他自己最熟悉的那套领域语言里工作。→ 详细
具体怎么做？"任何一个组织都由两样东西构成：名词和动词。名词定义实体，动词定义操作。" FDE 后来逐渐在干的活，就是把这些名词和动词搭出来，并弄清楚该用哪套术语。而关键收益在于：在很多大企业里，用户不只是采用你的产品，他们其实也在采用你的语言。 → 详细

术语天然是"定义不清"的：DAU、skills、MCP

那个案例最后统一叫 customers；换个场景，可能就统一到 ID 上。他举了个所有人都以为自己懂的词：DAU（日活跃用户）——对产品团队来说是"高质量的 DAU"，对 InfoSec（信息安全）的人来说就只是"登录过的人数"。所有这些我们习以为常的说法，本质上都是定义不清的。→ 详细
他当场把这个镜头对准了现场观众（这是 AI Engineer 大会）："现在有多少人在把东西叫做 skills？又有多少人把『带 prompt 的函数调用』叫成 MCP？"——这些一年前还没人当回事的词，今天已经是整个生态的日常口语。谁定义了它们，谁就拿到了地基。 → 详细

摸 ontology 的四道扫描题

FDE 摸清一家企业的语言体系，靠的是四个问题：→ 详细
1. 哪些短语、名词、术语是被"重载"的？（同一个词被不同的人拿去描述不同概念，或不同词描述同一概念）
2. 系统里的集成点都在哪里？——数据是从 Snowflake 流向 Databricks？从 Palantir 流向 Tableau？从 Anthropic 流向 SAP？中间那层"翻译层"是什么，一个术语怎么变成另一个术语的？→ 详细
3. 系统边界在哪里？哪些是你永远换不掉的记录系统（system of record）？
4. 客户描述自己问题的时候用的是哪些词？——比如"我的 agent 老是失败"，那 agent 到底是什么？他自嘲道："我们连 FDE 都定义不清楚，居然还想去定义 agent，对吧？它是一句 prompt？还是一串步骤？" 把这些搞到有切身体感，非常重要。
结论："你的活儿就是去定义这些词。如果你能在自己的方案里把术语定义下来，你就能搭出 ontology，就能让客户用你的词去回答问题、用你的词去思考。" → 详细

成为语言地基 = 锁死位置

"一旦你成了语言层面的地基，你就锁死了这个位置。" 当你能定义用户使用的词汇、并把它固化进你的平台，之后所有的方案和工具都建在你上面。→ 详细
这就是那条完整因果链：Foundry 让这套 ontology 得以被构建出来，而这又让下一代 FDE——那批偏 go-to-market 的 FDE——能出去只管做数据集成、卖产品。 换句话说，先有产品战略版的 FDE 挖出地基，才有销售版的 FDE 可以站着卖；顺序反了就什么都没有。→ 详细

故事四：vinoo.groovy——那个印上婚礼 T 恤的"临时脚本"

有个客户需要做数据保留（data retention）。他决定飞快写个脚本，用 Groovy 写的，本来只是个临时补丁——"它压根就不是奔着上生产去设计的，我就是随手糊了个东西解决眼前的问题——结果它就这么上去了。"→ 详细
12 个月后，这玩意儿到处都在跑，客户是个差不多十万人规模的组织，脚本在好多地方跑着。它后来干脆成了他在 Palantir 的外号——vinoo.groovy；他结婚那天，有人穿着印着 vinoo.groovy 的 T 恤来参加婚礼。→ 详细
好笑之处也正是痛处："我们用一种非常糙的方式解决了问题，确实把问题解决了，但我们没有把它产品化，没有想清楚终局是什么。结果我们被迫在之后好几年里，一直去支撑一个从来没被产品化的、极其糙的东西。" → 详细
所以他反过来否掉了一个流行定义："当有人说 FDE 就是前置部署的软件工程师、面向客户的软件工程师，说你的工作就是让客户成功——这不对。" 脚本和 hack 能解决问题，但推不动你的产品战略；那就意味着作为 FDE 你没把本职工作干好。"让客户成功这件事，我们有专门的人负责，那叫解决方案架构师（solutions architect）。" → 详细

校准"你到底交付什么"的四问

这是他眼中 FDE 最后也最重要的一项能力，四个自问：→ 详细
1. 六个月后，我会不会因为这东西在凌晨两点被电话叫醒？ 如果会，那你大概就不该交付它。
2. 为了快速解决这个问题，我付出的代价是什么？ 这个决定对整个产品是对的吗？还是只解了这一个客户的痛点、短期赢一点小的、长期不断累积负面复利？
3. 我离开客户现场的时候，这东西交接给谁？ 交给客户？另一家机构？还是下一个 FDE？
4. 它坏了会怎样，我要为此负责吗？ 我是不是在做一个关键到不能出事的东西——一旦挂了所有人都会恨我？
一句话总括：必须去解决问题，但同时要清楚——什么时候该把这些方案收进核心产品，什么时候该干脆利落地把它扔掉。 → 详细

每个 hack 都会进生产："这只是临时的"是最危险的一句话

"每一个 hack 最后都会进生产。只要它让某个人的日子变轻松了，它就一定会进生产，而你将永远要为这个 hack 提供支持。" 在工程领域，最危险的一句话就是"这只是临时的"。→ 详细
证据摆在那儿：我们到今天还在某台 IBM 大机上跑着四十年前的 COBOL 代码，就因为当年打了个补丁。"只要它解决了问题，它就不是临时的，它会一直活下去。" 所以他给的操作口径是：交付的每样东西，都当作它要跑 18 个月来做——因为它大概率真会跑那么久。 → 详细
用"我在建产品"这个镜头去看，你就会很清楚：哪些东西该进核心产品，哪些只是帮你赢来客户的好感——两者不是一回事，混为一谈就会背债。→ 详细

速查表：大多数人搭 FDE 团队为什么搭错

Project Frontline 让所有一线同事都过一遍的那份速查表，核心是一组对照。做错的那一半：大多数想搭 FDE 团队的人，把它当成产品经理的活儿 + 客户成功的运营活儿来做——收需求、排用户调研、加洞察、跑流程，却从来没想明白怎么把这些洞察真正转成对产品方向的操控。→ 详细
做对的那一半（催生出 Foundry 的那批 FDE）：重新定义问题；拿到客户现场的门禁牌驻场，飞去阿富汗、伊拉克、索马里（他有个朋友当时在大洋中间一座石油钻井平台上干活）；在离开客户现场之前就把补丁交付出去赢下好感，但在产品生态里对这个补丁端到端负全责；把补丁转化成产品杠杆——把亲眼看到的问题翻译成一套名词和动词，再用这套名词动词去定义之后每一个问题的解决地基；最后，东西真出事时接电话的是他们，跳上飞机飞去下一个地方的还是他们。→ 详细
检验标准也随之换了一把尺："问题不是『他们在这个过程里学到了什么』，而是『从产品角度看，他们交付出了什么』。" → 详细

收尾：产品杠杆是唯一能赢下客户的东西

"产品杠杆是唯一能帮你赢下客户的东西。" Citadel 里每一个操盘上亿美元的组合经理，背后撑着他的只有产品杠杆；Palantir 在作战人员生态、在客户生态里做的每一个决策，背后撑着的也只有产品杠杆。FDE 的工作，就是把它当作产品职能的延伸，用它做出真正有黏性、真正解决问题的产品。 → 详细
最后一句是给早期公司的忠告，也是全场落点："千万别把 FDE 当成 go-to-market 的延伸。等你成了 Palantir、攒了二十年、有花不完的钱，你可以那么干。但你是一家早期公司的时候不能这么干——你得先想明白，什么样的产品才能让你把这些 FDE 的价值榨到最大。" → 详细

🎯 于你何益为你定制 · 非通用结论

这一期跟你的关联度很高，而且是罕见的"多个项目同时命中"——它讲的不是"怎么当 FDE"，而是**"怎么在没人告诉你该造什么的时候，自己找出该造什么"**。这恰好是你 app_incubator 的头号痛点、Holdwell ERP 的跨线术语难题、也是 onehuman_company 最缺的那种"有来龙去脉、有数字、有翻车"的选题素材。下面按项目来。

app_incubator（7-Agent 造 App 链路）

① 把「动手前三问」焊成 agent 链路的第一道闸

怎么做的：Vinoo 给的是一个极简的三问——你到底想达成什么 / 拿到解法之后会发生什么 / 客户今天是怎么解决它的。第三问最狠：今天没有你，这个人是怎么活下来的？航运那个客户"今天是怎么解决的"的答案是"我看看有没有车晚点，然后打个电话"，于是 47 页需求文档、14 个指标、三个月工期，全部塌缩成一条 Slack 告警、4 小时交付。而他们此前已经花了四个月做范围界定——四个月的精细化，方向是错的。
你可以怎么做：你说 app_incubator 的痛点是"把该做什么前移到 agent"。这三问就是"该做什么"最便宜的可执行形态——不是让 agent 写更长的 PRD，而是在链路最前面加一个不肯往下走的 gate：任何一个功能进入设计/工程之前，必须先填满这三格，第三格（"今天怎么解决的"）留空就不许过。你现在的链路是"设计稿即工程强制契约"，强在下游；这一条是给上游装同款强制契约。做法很轻：给 7-Agent 里最靠前那个 agent 加一段固定输出——三问 + 一句"如果这题的答案是『打个电话/复制粘贴一下』，那本次交付的默认形态就是一条通知，不是一个界面"。

② 「一天能解掉的，就直接做掉、关掉闭环」——你的 agent 天然适合这个尺度

怎么做的：他的准则是"如果解决这个问题的工作量不到一天，那就直接做出来、上线、把闭环关掉。别把它搞成什么产品战略，别急着扩展产品愿景、把 PM 拉进来"。而这么干的回报是那句"秘密"：谁定义了问题，谁才真正拥有这个解法——因为你亲手交付了它，你才有资格描述后续的解法长什么样。
你可以怎么做：你的 9+1 Agent 把"一天"压缩成了"一小时"，所以这条对你不是"降低标准"，而是改变默认档位：把 app_incubator 的默认产出从"一个 App"改成"一次能关掉闭环的最小交付"——可能是一条推送、一个脚本、一张自动生成的表。你现在的痛点里有"激活/首屏体验"，本质就是你造的东西比用户的问题大，用户还没走到你精心设计的首屏就已经不需要你了。反过来用这条准则：先交付那条"Slack 告警级"的东西，等它被反复用，再往上长界面。

③ 「每个 hack 都会进生产」——这是 AI 造 App 时代被放大十倍的风险

怎么做的：他随手用 Groovy 写的一个数据保留脚本，"压根不是奔着上生产去设计的"，12 个月后到处都在跑，客户是十万人规模，最后成了他的外号——婚礼上有人穿着印着 vinoo.groovy 的 T 恤来。教训不是"别写脚本"，而是"没产品化、没想清终局，就得被迫支撑它好几年"。他给的口径是：交付的每样东西都当作它要跑 18 个月来建，因为它大概率真会跑那么久。
你可以怎么做：agent 写代码最大的诱惑就是"反正是 AI 生成的，糙一点无所谓，回头重写"——这就是"这只是临时的"的 2026 年版本。给你的造 App 链路加一条交付前的自问（他的四问里最好用的两条就够）："六个月后我会不会因为这东西在半夜被叫醒？" 和 "我离开这个项目时，它交接给谁——下一个我，还是下一个 agent？"。答案不体面的，要么当场按生产标准补上，要么明确标记成"到期即删"并写上删除条件——一人公司最贵的不是开发成本，是你一个人要维护的东西的总数。

onehuman_company（一人公司 build-in-public）

① 「47 页 vs 一条 Slack 告警」是你「造 App 决策复盘」支柱的现成教具

怎么做的：这个案例的完整来龙去脉本身就是一篇内容——客户（运营 VP）要的是定制看板 + 14 个指标 + 下钻 + 告警 + 一整套 BI 工具 + 三个月工期；团队照单全收，花了四个月做范围界定；一个人偶然去了现场（纯粹因为他家人住那边，不是什么严谨流程），问了句"周一早上你拿到这些信息第一件事干什么"；答案是"看有没有车晚点，然后打电话调库存"；最后 4 小时、一条 Slack 告警，从头到尾解决。数字对比极其锋利，而且每个数字都是真的。
你可以怎么做：这条能直接过你的弹药库闸门——不是因为它是个好故事，而是因为你能拿 drizzle tech 实测它。选题形态很清楚：从你自己的 App 需求池里挑一个"我本来打算做一整个模块"的功能，先老老实实问自己那三问，把"如果只做一条通知会怎样"的版本先做出来跑一周，然后写复盘：我原计划几天、实际几小时、砍掉了什么、砍错了没有。这就同时踩中你四支柱里的两个——造 App 决策复盘 + 大佬说 X 我试了——而且删掉你的判断和实测之后它就不成立，闸门稳过。
补一句给标题/封面前置：这期最抓人的三个数字组合是 47 页 → 4 小时、230 万个 keyspace → 14 TB 内存、17 小时 → 2 小时。你的痛点里写着"标题封面前置"，这类"两个数字之间的落差"是最省力的封面文案模具。

② 「产品杠杆是唯一能赢下客户的东西」——一人公司版本的翻译

怎么做的：他的收尾是一句斩钉截铁的话：产品杠杆是唯一能帮你赢下客户的东西。而 FDE 里"做对的那一半"和"做错的那一半"的分界线也在这儿——做错的人收需求、排调研、加洞察、跑流程，却从没想明白怎么把洞察转成对产品方向的操控；做对的人在离开客户现场前就把补丁交付出去赢下好感，但在产品生态里对它端到端负全责，并把补丁转化成产品杠杆。他给的检验尺子是：问题不是"他们学到了什么"，而是"从产品角度看，他们交付出了什么"。
你可以怎么做：你现在处在 Phase 0 存稿期（要攒 6-8 篇、≥4 篇验证体），最容易滑向的失败模式恰恰是"学到了很多但没交付"——读了一堆、总结了一堆、账号还没开张。把他那把尺子直接搬过来当你每周的自检问句：这周我"交付"了什么，而不是"学到"了什么？ 更具体一点：你有个"每篇要有可抄物"的要求——"可抄物"就是你的产品杠杆。一篇没有可抄物的复盘 = 一个没产品化的 hack，看着热闹，攒不下资产。

③ 「vinoo.groovy」是"AI 员工管理成本账"支柱的极佳类比

怎么做的：那个脚本的成本从来不是写它的那一小时，而是之后好几年的支撑。他把这归结为"我们没把它产品化，没想清楚终局"。
你可以怎么做：你的第四类内容是"AI 员工管理成本账"。这条给你一个别人很少算的成本项：agent 产出的"临时件"的长期维护成本。你可以做一期实打实的盘点——drizzle tech 至今生成了多少个"本来只是临时用一下"的脚本/配置/prompt，现在还有几个在跑、几个已经没人敢删。这个数字只有 build-in-public 的人拿得出来，天然是独家。

Codex Holdwell ERP work（ERP 产品知识库 + 多-Agent PRD 工厂）

① 术语重载那一段，几乎是照着 ERP 的痛处写的

怎么做的：同一个实体，销售叫 customers，运营叫 clients，财务叫"计费主体"，开发叫 org ID。后果他列得很具体：集成会崩、数据质量出问题、管道不停出故障。但他的判断很关键——不是"这些人应该统一术语"，而是"我们都是人，各自身处不同环境，习惯用同类人听得懂的方式说话，这是特性不是 bug"。所以 ontology（那套名词+动词的语言体系）的目的不是逼所有人改口，而是让人能在自己最熟悉的领域语言里工作，同时在系统底层把它们对齐。他还给了一条更强的：在很多大企业里，用户不只是采用你的产品，他们也在采用你的语言——一旦你成了语言地基，位置就锁死了。
你可以怎么做：你的痛点表里明明白白写着跨线对齐——六条产品线强耦合，同一个实体各线各叫各的。这一期给了你两件可直接照抄的东西。第一，沉淀共享实体定义的方法：不是从数据库表结构反推，而是从"哪些词被重载了"入手——跨境电商 ERP 里的"订单"（销售侧的订单 / 仓储侧的出库单 / 财务侧的应收单 / 平台侧的 order id）就是最典型的一组。第二，四道扫描题可以直接变成实体定义的填写模板：哪些词被重载？集成点在哪、翻译层怎么把 A 术语变成 B 术语？系统边界和"永远换不掉的记录系统"是哪些？各业务方描述问题时实际用的词是什么？——最后这条最容易被跳过，也最值钱。
顺带：他这套"名词定义实体、动词定义操作"的框架，等于给你的 PRD 工厂一个天然的地基格式——名词进共享实体定义，动词进流程/状态机。跨线对不齐的时候，先把名词表填出来比先写规范更快见效。

② 「行动比嘴上说的有说服力」+ 现场观察清单，专治"手上拿不出一手证据"

怎么做的：那位数据质量工程师抗拒 Parquet 抗拒了整整一年，理由永远是"Parquet 差多了，我理解不了"。团队去现场看她走一遍流程，才发现真相：她在手动把 CSV 从 S3 下到自己的 Windows 电脑，双击打开肉眼抽检——而 Parquet 当时没有能双击直接看的阅读器。当晚写了个查看器，两天后她批准迁移，管道执行时间从 17 小时降到约 2 小时。 一年的口头拉锯，输给了一个晚上的现场观察。他还给了一份可直接照扫的信号清单：用户重复做的动作 / 在工具间复制粘贴 / 切换工具或标签页 / 任务做到一半掏出手机 / 那句"我也没办法，只能这么干"的无奈。
你可以怎么做：你在 8 人 PM 团队里做 ERP，最缺的不是需求，是**"用户到底怎么用"的一手证据**——这正是你手上总拿不出硬证据的根子。把这份清单变成你去客服/运营/仓库工位旁边坐半天时的观察表，只记动作、不问观点：他一天里重复了几次同一个操作？哪两个系统之间在人肉搬数据？哪一步他会切到 Excel？哪一步他叹气？带回来的每一条都比一份需求文档更硬。他那句"最有价值的情报永远不会写在文档里，你在客户现场的门禁卡就是你的数据开采许可证"，对内部 PM 同样成立——你的"门禁卡"就是你愿不愿意离开工位。
还有一句该贴在墙上："你是靠解决一个个小而重复的问题，才赢得了挖掘用户痛点、定义产品战略的资格。" 你的碰撞协议难推行、真人评审意见难闭环，很大程度是"资格"没被承认——先用几个 4 小时级别的小交付换信任，比再写一版更严密的流程规范管用。

StockHelp（投资 + 看板产品）

① 「看板该显示什么信号」这题，他其实已经替你答了

怎么做的：47 页需求文档里要的是定制看板 + 14 个指标 + 下钻 + 告警，而真正需要的是一条"车晚点了"的告警。区别在哪？前者是"把所有可能有用的信息摆出来"，后者是"回答周一早上第一个动作"。
你可以怎么做：你的 StockHelp 现在 Phase 1 只看数据（12 只票的 PE、5 年分位、基本面比率、公允价），Phase 2/3 才做信号——这个顺序本身是对的，但你要小心 Phase 1 越长越像那 14 个指标。给自己做一次"周一早上问诊"：收盘后我打开这个看板，第一个动作是什么？ 如果答案是"扫一眼有没有哪只跌进我的安全边际区间"，那 Phase 2 的信号就已经定义完了——一条通知，而不是更多列。你既是产品经理又是唯一用户，这是你比 Vinoo 当年幸运的地方：不用飞去现场，你就住在现场。

② 「成为语言地基就锁死位置」是一条可以拿去看公司的护城河镜头

怎么做的：他说 "一旦你成了语言层面的地基，你就锁死了这个位置"——用户不只采用你的产品，还采用你的词汇；Foundry 把 ontology 固化进平台之后，之后所有方案和工具都建在它上面。他还当场举了现场观众都在用的例子：skills、MCP，这些一年前没人当回事、今天已是整个生态日常口语的词。
你可以怎么做：作为价值投资者，这给了你一个很具体的护城河识别问法：这家公司有没有定义行业词汇？客户是不是在用它的名词开会、写流程、招人（岗位 JD 里直接写它的术语）？这类"语言层锁定"比转换成本更隐蔽，也更持久——迁移数据是钱的问题，改口是全公司几千人的习惯问题。下次更新 watchlist 的定性判断时，加一栏"它有没有让客户改口"。

xiaohongshu_momorain（家居号「决策型生活记录者」）

怎么做的：整场演讲最可迁移的一句是 "客户描述的是解法，不是问题"——用户张口要的永远是"我要一个 XX"，而不是"我卡在 YY"。
你可以怎么做：你的痛点里写着"PM 思维这张牌没打"。这就是那张牌最好打的一种打法：家居内容里，评论区问的全是解法（"这个柜子哪买的"），真正的问题是"我家玄关一进门就乱"。把选题从"我买了什么"改成"我当时卡在什么，考虑过哪几种解法，为什么选了这个，花了多少钱，后悔没有"——这就是"决策型生活记录者"的定义本身，而 Vinoo 这套 XY 问题正好给了它一个可复用的提问模具。你选题矿池里那些还没动的条目，可以先用"这条讲的是解法还是问题"过一遍筛。

更深三角度

该反着用：Vinoo 的整套方法建立在**"你能去现场"**这个前提上——飞阿富汗、刷门禁卡、在钻井平台上待着，靠的是 Palantir 的人力和预算。你是一个人扛正职加多个副业，精力才是最稀缺资源，你飞不起也坐不住。所以对你，正确的反用是：别追求"去更多现场"，而是把"你已经身处的现场"榨干——你自己就是 StockHelp 的用户、是 momorain 内容的生活者、是 ERP 那 8 人 PM 团队的内部人。他要花四个月才能拿到的一手观察，你在自己的工位和自己的家里天天免费产生，问题只是你没记。用记录代替出差。

和你现在做法冲突：这一期跟你正在建的东西存在一处真实张力。你的方法论重心是**"把该做什么前移到 agent"、三驾马车 PRD 工厂、六步碰撞协议**——本质是用更强的流程和更早的规划来提高判断质量。而 Vinoo 明确点名了这条路的失败模式："大多数想搭 FDE 团队的人，把它当成产品经理的活儿加客户成功的运营活儿来做——收需求、排用户调研、加洞察、跑流程，却从来没想明白怎么把这些洞察转成对产品方向的操控。" 他给的替代路径是"上手 4 小时把它解掉，你就拥有了定义权"——用交付换判断，而不是用流程换判断。这跟你"问该不该做先于做多快"的操作系统也有摩擦：他的主张是，有些"该不该做"你问不出来，只能做出来才知道。这个张力我不替你收口，但值得你在下一次给流程再加一道关之前，先问一句：这道关能不能被"直接做一版丢出去看"替代？

对你的镜子：这场演讲真正的主角不是 FDE，是那句"我们在没有真正嵌进现场的情况下，就把『共建』这件事的所有权认领了"。你的第二大脑、你的 PRD 工厂、你的两个内容号，都是"在真空里设计的系统"的候选——它们都很精致，都在特定条件下跑得天衣无缝。Phoenix 也是。它翻车不是因为设计得不好，恰恰是因为设计得太好、太自洽，好到没人想起去看一眼真实数据长什么样。你判断力很强，而判断力强的人最容易造出 Phoenix。

所以呢

可迁移思维模型

【耐用】"今天你是怎么解决的？"——所有需求判断里性价比最高的一问。它同时给你三样东西：真实工作流、砍需求的底气、以及那个"最小可交付形态"的形状。
【耐用】谁定义问题，谁拥有解法。定义权不是被授予的，是被交付换来的。适用于产品、内容、职场，也适用于你和你的 agent 之间。
【耐用】每个 hack 都会进生产，"这只是临时的"是最危险的一句话。判断一样东西要不要按生产标准做，只需问"六个月后我会不会为它半夜被叫醒"。
【耐用】语言即地基——谁定义了词汇，谁就成了别人方案的底座。既是产品护城河，也是投资视角下的定性指标。
【会过期】"必须人在现场、刷门禁卡" 这个具体形态。远程协作、屏幕录制、以及你自己就是用户的一人公司结构，都能部分替代"物理在场"；但它替代不掉的内核——观察行为而不是采集观点——是耐用的。

判断更新：你原来的默认是"想清楚再动手，判断力 > 努力"。这一期不否定它，但补了一个边界条件：当你对"客户今天怎么活"一无所知时，再多的思考都是在真空里加精度。这种时候，最高杠杆的动作不是想得更久，而是用最小的交付去换一次真实反馈——四小时的 Slack 告警，胜过四个月的范围界定。

这周一个赌注：从 app_incubator 或 StockHelp 里挑一个你原本打算做成"完整模块"的东西，只做那条"Slack 告警级"的最小版本，本周内跑起来，然后把这次决策写成 onehuman_company 的一篇存稿（原计划 vs 实际、砍了什么、砍错没有）。一次动作，同时喂三个项目：验证方法、产出内容、还顺便试了"把该做什么前移"到底能前移多少。

接着读

NO.112 · 思维模型 Ramp的持续划范围 Leo Mehr · 10 分钟 NO.111 · Agent 工程 Cognition怎么量交付价值 Jia Wu · 13 分钟