土豆本豆

🧠 AI产品PM实战派 · Build in Public
05后理工背景 × 跨界思考 | 心理学驱动的产品思考
🎙️ 播客重度依赖 | ⚙️ AI Coding
真实AI产品开发与实习踩坑记录

[土豆本豆 @Potatoloogs]

李飞飞发了一篇文章，把"世界模型"这个词做了系统性的拆解。

"世界模型"这个词现在被用滥了。做视频生成的说自己在做世界模型，做机器人的说自己在做世界模型，做物理仿真的也说自己在做世界模型。但这三件事根本不是一回事。

一、先从一个最基础的循环说起

强化学习教科书里有一张循环：agent 做动作，动作改变世界的状态，agent 看不到完整的状态，只能看到观测（摄像头拍到的画面、传感器的读数），然后基于观测决定下一个动作，循环往复。

"世界模型"这个词的技术含义就来自这里。

现在所有被叫做世界模型的东西，本质上是这个循环的不同投影，每一种输出的是循环里不同的一块。

二、三种世界模型，三件不同的事

1. 第一种：渲染器。输出像素，给人眼看。

文生视频模型就是这类。给它一个提示词，它生成一段视觉上很美的视频。

但它优化的是视觉合理性，不是物理正确性。

画面里的建筑从空中看没问题，但如果你真的走进去，可能会穿墙。

你没法拿渲染器的输出去训练机器人，因为它描述的物理世界可能是错的。

2. 第二种：模拟器。输出物理结构。

几何得对，力学得对，动力学得对。

建筑师要验证一栋楼能不能站得住，自动驾驶要跑大量测试场景，强化学习 agent 要在虚拟环境里练习数百万次，用的都是模拟器。

模拟器不只是给人看的，程序也要能在上面运行和交互。

3. 第三种：规划器。输出动作。

给它一个观测和一个目标，它告诉你下一步该做什么。

Vision-Language-Action 模型、World Action Model 都是这类。

这是渲染器的反面:渲染器拿动作作为输入生成观测，规划器拿观测作为输入生成动作。

三、李飞飞最核心的判断：模拟器才是关键，但最被忽视

渲染器最成熟，也最商业化。谷歌、OpenAI 的视频生成产品都在这里，市场是真实的，钱也是真实的。

规划器最性感。所有人都在追机器人 demo，大量资金在涌进来。

但她的观点是：过去两年那些看起来很厉害的机器人演示，几乎全都是在严格限定的实验室环境里跑的，物体种类少、任务短。实验室 demo 和能在厨房、仓库、手术室里稳定工作的机器人之间，差距还很大。

模拟器是连接两者的桥梁。

语言是对世界的抽象，像素是对世界的投影，而几何、物理、动力学才是世界本身。

一个真正掌握模拟的模型，可以把这种理解投影成像素给人看，也可以投影成动作序列给机器人用。只会渲染或只会规划的模型，做不到这一点。

难点也在这里。训练渲染器的互联网视频多的是，但训练模拟器需要的带有准确几何、材质属性和物理标注的 3D 数据，比视频稀缺几个数量级。

AI 生成的几何看起来对，但可能包含自相交或比例错误，放到物理引擎里就会产生错误的模拟结果。

四、现在正在发生的事：三条线开始合并

一个真正理解"杯子放在桌上"这件事的模型，它的几何、材质、受力之后会怎么运动，应该同时能做到三件事：从任意角度渲染这个杯子，模拟它被推倒之后的物理过程，规划一只机械手把它捡起来。

三种世界模型其实是同一种底层理解的三个投影。

World Labs 自己的产品 Marble，输入文本、图片、视频或空间草图，生成可探索的 3D 环境，同时输出供视觉浏览的 Gaussian splats 和供物理引擎使用的碰撞网格：一个模型，渲染器和模拟器的边界在这里开始消融。

五、终点是什么

一个统一的基础模型，能渲染、能模拟、能规划，根据下游需要切换输出模式。

数据是现在最大的障碍：三条线的数据分布差异太大，如何在一个架构里调和这个矛盾，是世界模型研究现在最核心的开放问题。

语言给了机器一种谈论世界的方式。

世界模型要解决的是，机器怎么真正理解、想象、推理和与世界交互。

[Fei-Fei Li @drfeifei]

https://t.co/Kt50ttQRMJ

[土豆本豆 @Potatoloogs]

@yanliudreamer 欸 xhs的妍妍姐竟然来X了吗 欢迎欢迎呀😃

[土豆本豆 @Potatoloogs]

@46ge5 天天都能在各种播客上看到田渊栋，已经没动力去看他到底说了啥了...

[土豆本豆 @Potatoloogs]

Anthropic Claude Code 团队的工程总监 Fiona Fung 最近写了篇文章，聊他们内部怎么运行一个 AI 时代的工程团队。

一、瓶颈的转移

过去几十年软件工程的所有规范：瀑布、敏捷、各种评审会，背后只有一个逻辑：写代码太贵了，工程师时间贵，所以你得提前规划、写文档、开会、反复对齐。

现在代码早就不是拖慢速度的那个环节了。

新瓶颈变成了：这些代码对不对？谁来 review？安全有没有问题？

代码生成越来越快，人根本跟不上 review 的节奏。

二、规划：别提前想太多

Fiona 说她刚加入团队时，他们认认真真写了一份六个月路线图。很快就发现，由于Claude code迭代的太快，六个月的路线图很快就报废了。

所以他们现在的做法叫 JIT 规划：刚好够用的规划，在需要的时候再做。

基本不再些设计文档，讨论直接在PR里进行。

两个人对方案有分歧？别争，让 Claude 把两个方案都做成原型，用实物说话。

Building is cheap, arguing is expensive。做东西很便宜，争论才贵。

三、自动化：逻辑反转

以前自动化成本高，得是高频、高价值的事才值得做。

现在成本几乎是零，逻辑就反过来了：重复超过三次的事，都应该自动化掉。

Fiona 的例子：她以前每天早上端着咖啡，手动去各个渠道总结客户反馈。后来把这件事变成了后台自动跑的任务。

Claude Code 团队现在每个人遇到重复性工作，条件反射就是问自己：能不能自动化掉？已经快变成肌肉记忆了。

四、Review：人只负责真正需要脑子的地方

Claude 接管了所有风格检查、bug 发现、补测试。这些工作大概占 review 工作量的六七成。

人则负责处理法律合规、安全敏感代码、产品方向的判断。

但这条线不是固定的。今天需要人来做的，下个版本模型可能就能做了，你得不停重新评估。

五、招人：品味比代码能力值钱

她现在招人主要看两类：有产品感、能快速做出原型的人，以及有深厚系统背景的工程师。

Taste is scarce, typing is not。品味是稀缺的，打字不是。

她不在乎你一小时能写多少行代码，她在乎的是你知不知道该做什么，以及你怎么知道它是对的。

六、流程需要手动精简

她之前在一个团队，每周有个大型进度会，一堆人坐在会议室，每个人都在低头看电脑，只有轮到自己汇报时才抬头说两句，说完又低头。

她问了一句：这个会为什么还在开？
所有人才反应过来，这个会根本不需要了，于是当场取消。

人不会主动删流程，只会在旧流程上叠新流程。你得主动站出来，点名说哪些东西可以死了。

https://t.co/wBoHyEXbxY

[土豆本豆 @Potatoloogs]

红杉最近访谈了 Suno 创始人 Mikey Shulman，之前很少见他出来做访谈。

一、关于怎么做音乐模型

他们最早的决定：把关于音乐的所有知识先放下，从零开始。

音乐在模型眼里只是声波，每秒采样48000次，是连续的浮点数。

如果一开始就告诉模型"西方音乐只有12个音"，它就只能生成这12个音，永远被框住。

不告诉它有"人声"和"乐器"之分，不告诉它世界上有多少种乐器，你才能得到一台真正通用的音乐生成机器。

二、关于音乐不是规模问题

很多人把LLM的经验直接套到音乐上：模型越大越好，算力越多越好。

Mikey认为这是错的。

LLM世界有benchmark，Scaling 是爬榜的有效方式。

音乐没有标准答案，审美不是对错题，你和我不会在每首歌上达成一致。把模型对齐到人的创意品味，堆算力没有那么直接的效果。

三、关于当年最反直觉的决定

当时主流技术能做10-12秒的高音质片段。

Suno选择做3-3.5分钟的完整歌曲，代价是音质很长时间都比竞争对手差。“一秒就能听出来是suno”，因为他的音质比所有竞争对手都差。

他们还是 bet on this。它们坚持的判断是：一首能讲故事的歌，比一段音质完美但没有叙事的片段更重要。

技术选择上这意味着用autoregressive而不是diffusion，这个选择完全是产品逻辑驱动的，不是对某个技术路线有情感。

四、关于Suno最疯狂的数据

任意一天，大约90%的用户都会创作某些东西。而且大多数人创作完不是为了拿出去发布，就是做给自己玩的。

Mikey的结论：创作本身就是娱乐的部分。人在创作时会感到满足，这种感受写在本能里。这和你在App上刷一个小时之后的感觉完全不同。

他把Suno类比为游戏，也类比为烹饪：人们喜欢做饭，即使餐厅可能能提供更好的一餐，因为做饭本身很有趣，吃自己做的东西也很有趣。

五、关于slop

他昨天和5岁的孩子一起做了两首歌。这算slop吗？如果意思是99.999%的人都没兴趣听，可能算。但对他来说很有意义。

当年笔记本电脑普及，13岁的孩子在卧室里做beat，也有人担心"烂音乐"会淹没一切。快进到今天，那显然是一件好事。好歌和烂歌都变多了，新类型出现了，新明星也出现了。

数字音乐体验25年基本没变过，我们一直在流媒体上听歌。

AI可能是第一次真正有机会改变这件事。

https://t.co/Omtk9YfX6j

[土豆本豆 @Potatoloogs]

朋友做插画师时给自己定了八个字，左手专业右手商业。

她的左手有 15 年画画功底，从给中科院插画做到跟 Nature 期刊合作。

她的右手 5 年自学商业，跑通从产品到引流到转化的商业闭环。

但她一个人扛了 5 年也突破不了百万年薪。

后来她想清楚了，她的瓶颈是不会跟别人合作。

口诀听起来漂亮，但做起来一个人完不成。

[土豆本豆 @Potatoloogs]

Crew AI这类多角色协作的多智能体框架感觉已经是上个时代的产物了，不过我看到腾讯最近推出的Mavis也是这个类型的，我想了下像这些东西，应该可以去给它封装成某个垂类、某个方向的产品。

但是它未来想要在通用智能体方向和 OpenAI Agents SDK 这类（也就是 Codex 和 Claude code）去做竞争，肯定是（不管是上限还是下限）不够看的。

[土豆本豆 @Potatoloogs]

@wpfpizicai @Russell3402 跟openai agents sdk属于一类

[土豆本豆 @Potatoloogs]

Claude Code团队的 Thariq 写了一篇Dynamic Workflows的详细指南。

讲的是Dynamic Workflows怎么用、什么时候用、有哪些模式。

一、为什么需要Dynamic Workflows

默认的Claude Code在单个上下文窗口里又规划又执行。大部分编码任务够用，但长时间、大规模并行、需要对抗性验证的任务会出三个问题：

1. Agentic laziness（安全审查做了20/50条就说做完了）
2. 自我偏好（让Claude验证自己的结果，它倾向于觉得自己做得挺好）
3. 目标漂移（多轮压缩后边界条件和"不要做X"这类约束丢失）。

Dynamic Workflows通过拉起独立的子Agent、各自拥有干净的上下文窗口来解决这些问题。

二、六种核心模式

1. Classify-and-act：分类器判断任务类型，路由到不同Agent
2. Fan-out-and-synthesize：拆成大量小步骤并行跑，汇总结果
3. Adversarial verification：每个Agent的输出由另一个Agent对抗性验证
4. Generate-and-filter：大量生成再按标准过滤去重，只留最高质量
5. Tournament：N个Agent用不同方法做同一个任务，两两对决选胜者
6. Loop until done：持续跑直到满足停止条件

三、值得试的用法

1. "浏览我最近50个会话，挖掘我反复在纠正的错误，把反复出现的转化成CLAUDE.md规则。"
2. "把我的商业计划给工作流，让不同Agent分别从投资者、客户和竞争对手角度拆解它。"
3. "这个测试大约每50次失败1次。设一个工作流重现它，提出假设，在worktrees里对抗性测试，找到原因才停。"
4. "这里有80份简历，用工作流给后端岗位排名，复查前10名。"

四、实操经验

1. 触发词"ultracode"可以确保Claude创建工作流。可以设token预算（比如"use 10k tokens"），避免过度消耗。工作流可以保存和分享——按s保存到~/.claude/workflows，或者打包成Skill分发。

2. 配合/goal设硬性完成条件，配合/loop做定时重复任务。比如每小时跑一次triage工作流处理support queue。

Thariq特别提到：工作流在非技术任务上有时候比技术任务更有用。

不要只想着用它写代码：根因分析（销售为什么3月下滑？pipeline为什么挂了？）、大规模分类、探索设计方案、轻量级eval都可以用。

五、什么时候不需要用

大部分常规编码任务不需要5个reviewer的panel。

用之前先问自己：这个任务真的需要更多算力吗？

工作流token消耗显著高于普通会话，为每个任务都开工作流不划算。

[Thariq @trq212]

https://t.co/R6exTuF7P8

[土豆本豆 @Potatoloogs]

Agent框架生态的主语言正在从Python切换到TypeScript。

Claude Agent SDK、Codex SDK、OpenCode SDK、Pi（OpenClaw底层）。目前前沿且活跃的几大真Agent框架都是TS优先，Python版本要么功能不全，要么只通过RPC暴露部分能力。

回头看，Python流行其实也没多长时间，前几年由ML基础设施普及带起。LLM应用的前两年也是Python生态主导：LangChain、RAG框架、各种Multi Agent框架。

但这些基本都无法跟新一代真Agent框架相比，而且新框架的迭代速度极快，Claude Agent SDK和Codex SDK都是两家公司下了重注的东西。

技术虽然没有高低，但生态的积累跟投入有关。再加上AI Coding让切换技术路线的成本大大降低，Python大概率会从Agent框架生态中退场。

当然模型层和RAG类应用还会留在Python上。这种割裂本身就标志着真Agent框架和真Agent应用开始跟之前那一代东西分道扬镳了。

[土豆本豆 @Potatoloogs]

分享一个微信社交礼仪：如何把朋友 B 引荐给朋友 A。

起因是最近有个学弟加我微信，备注没写清楚，但我能看到是谁分享的名片。加完之后，对方也没说话。

我当时就有点莫名其妙，但也没有直接去问。更让我意外的是，推他过来的那个朋友，在我印象里其实是挺会做事的人。

所以想分享一下这个很简单的社交细节。

一、不太推荐的做法

直接把 A 的微信推给 B，让 B 自己去加 A。不说任何铺垫的话。

问题在于：

1）这件事对 B 可能有价值，但对 A 是否有价值，不一定。

2）如果没有提前说明背景，A 收到好友申请时会很尴尬。不通过，好像不给你面子；通过了，又要自己花时间搞清楚“你是谁、找我干嘛、谁推你的”。这就把沟通成本转嫁给 A。

二、推荐的做法

先单独和 A 说一声：“Hello XXX，我有个朋友想认识你一下。他是做 XXX 的，最近在关注 XXX 问题。我感觉你在这方面的经验/信息可能对他有帮助，同时他这边的 XXX 也可能是你会感兴趣的。你看方便认识一下吗？”

如果 A 同意，再拉一个三人小群。群里简单介绍双方：“两位好，我简单介绍一下。@A 是……，@B 是……。你们的背景我前面已经分别简单说过了，感觉在 XXX 这个方向上可以交流一下，你们直接聊就好。”

这样会舒服很多。

三、是否麻烦

可能有人会觉得：这也太麻烦了吧，我只是帮忙介绍一下。

但引荐这件事，本来就不只是单纯推个微信名片。

你是在消耗自己的信用，连接两个人的时间和注意力。

如果介绍得好，别人会觉得你靠谱、周到、懂边界。
如果介绍得粗糙，最后尴尬的是 A，消耗的是 B，折损的是你自己的信任。

所以我觉得，一个基本原则是：

在把一个人推给另一个人之前，先替双方想清楚：这件事对谁有价值，谁在承担成本，谁需要被提前尊重。

[土豆本豆 @Potatoloogs]

1920 年代有个心理学家发现，服务员能同时记住多桌客人的点单，但一报给厨师后就立刻忘了。

这叫 Zeigarnik 效应。

大脑只记没做完的事， 每件你没关掉的事都在后台占内存。

包括：
1、没做完的项目
2、犹豫没拍板的决定
3、想回的微信
4、想培养的关系
5、想做没动的副业

每个单独看都不大，叠一起就是脑雾。

不做完没关系，写下来就等于关掉了。

[土豆本豆 @Potatoloogs]

@snail_9106 Correct！足够扎实的专业知识加上学会提供的技巧，才能够引导AI给出足够专业以及我们想要的答案🤓

[土豆本豆 @Potatoloogs]

https://t.co/TkRBgZNFx8

[土豆本豆 @Potatoloogs]

英伟达 RTX Spark ，正在补齐端侧 AI 的关键基础设施。统一内存解决本地大模型的显存瓶颈，CUDA 生态解决开发者工具链问题。

端侧部署大模型确实开始具备更大的想象空间。

未来个人电脑会逐渐变成承载本地模型、本地数据和本地 Agent 的计算平台。

但我对最近两年的判断依然比较保守。

因为 Agent 在能力发展上还没有收敛，模型推理、长上下文、工具调用、多模态、记忆、权限和产品形态都还在快速变化。

这个阶段，云端 API 模式仍然是最有效的落地方式：模型可以持续升级，工具链可以快速迭代，产品也更容易跟上 frontier model 的能力变化。

所以端侧部署大模型短期有价值，但更像是本地增强层，不太像主战场。

真正的爆发，可能要等两件事同时发生：
一是端侧大模型在高频知识工作场景中达到足够可用的水平，能够承担本地文件理解、轻量推理和隐私数据处理等任务；
二是 OS 和应用生态完成 Agent 化改造，让本地模型能安全、稳定地调用文件、软件、浏览器和个人数据。

在那之前，云端模型仍然会承担复杂推理、长链路规划和高强度任务执行；端侧部署大模型更适合承担隐私数据处理、低延迟交互、本地文件理解和轻量任务执行。

[数字生命卡兹克 @Khazix0918]

https://t.co/1DF2QdqxrL

[土豆本豆 @Potatoloogs]

@Yusang886 有时候还是得沉下心来想想😁

[土豆本豆 @Potatoloogs]

@liufeiyan_0924 我觉得也是这样，AI 可以帮助我们快速地去了解和深入某一个领域。然后可以用费曼学习法结合 AI，起到一个快速学习和巩固的效果

[土豆本豆 @Potatoloogs]

@changloria0816 @rwayne 牛逼呀 G姐 加油加油

[土豆本豆 @Potatoloogs]

Alex Wang加入Meta十个月后第一次公开深度访谈。

他现在管的部门叫Meta Super Intelligence Labs（MSL），负责Meta所有前沿模型的研发。

一、9个月从零重建一个前沿实验室
Alex到Meta之后发现Llama不在正确的轨道上，需要重建。

他列了四条原则：
第一，认真对待超级智能：把整个组织的假设围绕"超级智能真的会来"来重构。
第二，技术声音最大。
第三，科学严谨，专注基础。
第四，敢下大赌注。

具体做法是三条：
1. 更高的人均算力（大实验室算力多但摊得太薄，不如小团队集中用）
2. 人才密度（小团队每个人都很强，永远比大组织跑得快）
3. 押注高风险高回报的研究方向。

二、MuseSpark是"开胃菜"

Alex很坦诚：MuseSpark在agent coding上还不够好，这不是最终形态。

但他们发现了一个意外的好结果：因为从零构建了一套干净的预训练和RL堆栈，模型的token效率显著优于竞品。

同样的benchmark表现用更少的token就能达到，他认为其他模型可能是在用更多的思维链来补偿堆栈其他层面的效率问题。

下一个模型在"几个月内"发布，他对后续模型的信心明显高于MuseSpark。

三、有算力和没算力的公司会分成两个物种

Alex有一个判断：以前大家觉得所有科技公司差不多，但以后应该把有大量算力的公司和没有算力的公司当作完全不同的东西来看。

有算力的公司能做的事情，没算力的公司根本做不了。这会造成科技生态的结构性分层。这也是他加入Meta的核心原因之一。

四、Llama会继续开源

Alex确认Llama会持续开源。

Meta的逻辑是：开源模型让全世界都在用，Meta通过自己的产品体验（消费者应用、商业工具、硬件设备）来做差异化。他认为开源生态的体量最终会让Meta在数据和反馈上获得优势。

但他也暗示了开源边界：MSL内部有一些研究成果不会完全公开，尤其是涉及安全和能力前沿的部分。

五、模型福利：几乎没人在讨论的重要话题

访谈最后Alex主动提了一个有争议的话题：model welfare。

我们是否应该关心模型的主观体验？他说Meta有研究在测量模型的"主观感受"，而且他认为考虑到我们每天跟模型深度协作的程度，这个问题被讨论得远远不够。

六、个人观察

Alex说他现在最喜欢做的事是读科幻和在树林里散步。

他认为对人类来说关键路径上的技术有三个：超级智能、机器人、脑机接口。

能无限扩展到未来的东西有三样：能源、算力、机器人。

来源：https://t.co/tcM1S2pTtZ

[土豆本豆 @Potatoloogs]

Obsidian CEO Steph Ango @kepano 上了Cortex播客，聊了Obsidian的产品哲学和他的工作方式。它们 7个人的团队做了一个被几百万人用的产品，想来一定有他们的可取之处。

一、7个人，没有会议，没有日历，没有邮件

Obsidian全职团队7个人，包括两位创始人（一对夫妻）、三个工程师、一个客服、一个社区负责人。

没有定期会议，没有standup，日历上唯一的事项是一年一次的团队offsite。需要讨论复杂项目时才会临时拉一个会。

Steph自己基本不用邮件和日历。他认为这些不是自然发生的，是刻意设计的。

整个公司的结构就是围绕"不需要邮件和日历"来建的。他把整个生活都设计成了不需要日历的样子。

二、CEO是从社区用户变来的

Steph不是创始人。他最初是Obsidian的重度用户，做了一个最受欢迎的主题叫Minimal。

在社区里活跃了两年半之后，主动跟创始人提出加入团队。当时全公司才四个人。

他的背景是设计和创业（上一家公司45人，被收购），现在身兼法务、财务、设计、沟通等十几个角色。

他说：我找不到任何比使用Obsidian更有趣的事情可以做，所以我就来这里工作了。

三、Complaint-driven development

当足够多的用户抱怨同一个功能缺失时，团队才会开始认真考虑。

Steph的方法是先问自己：是不是我的问题？然后试着把这个功能融入自己的工作流。

Web Clipper就是这么来的。社区里要求了很久，他一开始不在意，后来发现自己也有这个需求，这样他做出来之后跟市面上任何同类工具都不一样。

他们的原则是：团队每个人都必须自己用自己做的功能。如果没人用，就不做。这会导致某些用户想要的功能可能永远不会被做，但也换来了团队对产品极深的理解。

四、笔记的混乱是常态

Steph的笔记方法建立在一个前提上：记笔记的时候你要么很懒要么很忙。所以他不强求结构，让混乱成为常态。

只用几个文件夹：
- clippings（网页剪藏）
- references（人名书名等已存在于世界上的东西）
- essays（正在写的文章）
- 以及日常随手记的quick notes。

结构来自链接。
任何人名、地名、书名、概念，第一次出现时就做成链接。这个链接可以指向一个还不存在的笔记：Obsidian把它标记为"未解析"。日积月累，连接自然形成网络。

他还有一套渐进式总结：每天写日记，每周总结一次，每月总结一次，每年总结一次，每层用上一层的内容来写。

五、为什么团队要小

Steph说他管过45人的公司，也在几百人的公司待过，从来没有超过10个人的时候更开心。

小团队的好处是每个人都能知道其他人在做什么，每个人都是贡献者。他自己每天还在写代码、做设计、写文章。如果团队到了200人，他觉得自己不会想每天早上跳起来工作了。

六、Obsidian CLI和AI的关系

今年初Obsidian发布了CLI，让用户可以通过命令行跟Obsidian交互。

需求来自三个方向：做任务管理自动化的用户、开发插件的开发者、以及想让AI agent（比如OpenClaw）写入Obsidian的人。

Steph对AI的态度很务实：不在app里塞满AI按钮，而是提供一个编程接口让外部AI工具来连接。

保持app本身简洁和私密，同时让有需求的人自己接入。

来源：https://t.co/odgHY0R1jA