土豆本豆

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

[土豆本豆 @Potatoloogs]

@kfk_ai 我没考上 我的梯子考上了😃

[土豆本豆 @Potatoloogs]

Anthropic 发了一篇文章，讲他们内部怎么用 Claude 接管 95% 的数据分析请求，整体准确率稳定在 95% 左右。

他们一开始直接把 Claude 接到数据仓库上让它自己跑，准确率不超过 21%。

一、为什么数据分析比代码生成难

写代码有文档、有测试，模型出错会被发现。

数据分析不一样：往往只有一个正确答案，来自一个正确的数据源，而且没有任何确定性的方式验证答案是对的。

他们总结出三类主要失败：

一是映射模糊。数据仓库里可能有几百万个字段，Agent 不知道"活跃用户"到底对应哪个字段，什么行为算活跃，要不要排除欺诈用户，时间窗口用多长。

二是数据过期。数据源和业务定义一直在变，Agent 掌握的知识随之过期，开始给出表面合理、实际有偏差的答案。

三是检索失败。正确的信息就在仓库里，也有完整的注释，但搜索空间太大，Agent 就是找不到它。

二、他们的解法：三层结构

数据基础层解决映射模糊。

核心原则是：每个概念只有一个权威答案。维护少量受强治理的逻辑模型，坚决废弃那些近似的重复数据集。当 Agent 搜索某个概念时，只找到一个结果。

但是光有原则不够，还得用工具强制执行，绕过权威模型的改动无法通过 CI，下游团队必须基于权威层构建。没有执行机制的治理，会很快退化。

可信数据源层解决检索失败。

按可信程度从高到低分四类：
1. 语义层（编译好的指标定义，Agent 被强制要求优先用这个）
2. 数据血缘图（语义层覆盖不到时，推断应该从哪个上游模型聚合）
3. 查询语料库（历史 SQL，但直接给 Agent 访问数千条历史查询，准确率变化不到一个百分点，要先提炼成结构化参考文档才有用）
4. 业务上下文（路线图、决策记录、组织架构，Agent 不知道这些就只会回答你问的问题，而不是你想要的答案）。

Skill 层解决三类失败的最后一公里。Skill 是 Agent 按需读取的 Markdown 文件，告诉它按什么顺序查哪些数据源、如何处理模糊的数据。

加了 Skill 之后，准确率从 21% 涨到 95%。某些领域能到 99%。

这里有几个关键做法：成对创建 Skill，一个做轻量路由器缩小搜索范围，一个编码资深分析师的分析流程。参考文档要面向模型检索来写，描述粒度、范围、排除条件和注意事项，不要写容易过期的操作步骤。

最容易被忽视的一点是：Skill 文档和数据模型放在同一个代码库，改模型的 PR 就是更新 Skill 文档的 PR，用 CI 钩子强制执行。他们曾经亲眼看到上线时准确率 95%，一个月后跌到 65%，才意识到 Skill 维护是工程问题，不是文档问题。

三、一个有意思的负面结论

他们给 Agent 开放了对整个数仓所有 SQL 的 grep 访问，数千个文件。

验证了 Agent 每次回答前确实读了这些文件，但准确率变化不到一个百分点。

进一步检查：答错的问题，正确答案在语料库里有吗？约 80% 的情况下有。Agent 看了，但就是用不上。

结论：瓶颈不是能不能访问信息，而是能不能把问题映射到正确的结构。

这个发现重新调整了好几个月的工作优先级。

四、还没解决的问题

静默失败：答案是错的，但看起来合理，没人提出异议就被直接用了。

他们现在用来源标注页脚、对高层汇报内容要求人工确认来缓解，但也承认还没有完善的解决方案。

https://t.co/LgeuXMQiBQ

[土豆本豆 @Potatoloogs]

@rwayne 可别全信了AI，回过头来怪医生治的不好

[土豆本豆 @Potatoloogs]

Codex 这次更新了三个功能。

一、插件

核心逻辑是让 Codex 适配你的角色和工具，不用写代码。

这次按场景分了六类：设计、开发者工具、日常生活、效率工具、研究、安全，目前 62 个热门插件、110 项技能。

每个插件把对应领域常用的应用、工作流打成一个包，随用随调。举个例子：GitHub 插件直接处理 PR 和 Issues，Computer Use 让 Codex 操控电脑，Remotion 直接制作视频，Zotero 访问本地文献库。

OpenAI 的意图很明确，他们在搭开放生态，让合作伙伴直接在 Codex 和 ChatGPT 里部署自己的插件。

二、站点（sites）

工作里很多东西塞不进文档或表格。

Sites 干的事是让 Codex 把你的想法、分析、计划，直接变成一个托管的可交互网站，给你一个 URL，团队里谁都能点开用。

有两个具体场景：
1. 让它给客户评审建个站点，它生成交互网页，把产品更新、未解决问题、使用趋势全摆进去。
2. 让它拿财务模型搭个情景规划器，领导直接拖参数比较假设，不用翻文档里一个个标签页。

有人说这要杀死所有 AI 建站工具： Webflow、Framer、Lovable等等。

还有个有趣的角度：OpenAI 一边自己做站点，一边把 Wix、Replit、Lovable、Figma 拉进来当早期合作伙伴。站在 Figma 们的角度看，多少有点与虎谋皮的感觉。

目前是预览版，只对 Business 和 Enterprise 开放。

三、批注

Codex 本来就能在应用里直接打开文档、幻灯片、表格、站点。

批注的意思是，你可以指着想改的那一块，告诉它具体改什么。选中导航栏让它换字体，高亮一条主张问它来源，圈住图表要更清楚的标签。

它只动你点的那块，不重做你已经满意的部分。

[OpenAI @OpenAI]

Building apps has never been easier.

With Sites, Codex can turn your work, ideas, and plans into an interactive website or app your team can explore, use, and share with a URL.

Rolling out to Business and Enterprise plans, before expanding more broadly.

[土豆本豆 @Potatoloogs]

OpenAI 后训练团队负责人 Yann Dubois 最近接受了一次访谈，聊了一些我们平时看不到的内部视角。

一、为什么 AI 进展突然感觉像在跳跃

能力提升其实一直是连续的，但有一个可靠性门槛：只有过了这个门槛，工具才能真正被信任去做实际工作。AI 大概在去年 12 月跨过了这个门槛。

感觉像阶梯式跳跃，是因为在那之前工具有用但不可靠，在那之后你才敢真的把工作交给它。

另一个原因是：一旦模型足够好，你可以用它来加速自己，包括用它来训练下一个模型、搭建研究工具。这种加速是自我强化的，所以最近几个月感觉越来越快。

二、RL 从竞赛题走向真实工作

O1 刚出来的时候，RL 主要用在有标准答案的任务上：数学题、编程竞赛，因为这些方向的对错容易判断。

过去一年他们做的最重要的事，是把这套方法迁移到真实的、模糊的工作场景里。以前是优化竞赛题，现在是优化用户真正觉得有用的东西。

三、可靠性如何提升

一个很直接的模型：每两分钟有一定概率出错，任务越长，最终答案出错的概率越高。

提升可靠性就是不断压低这个每步出错的概率。

这就是 agentic 系统最核心的问题。

四、AI 的构建更像是手艺，而不像科学

训练模型的过程通常是：先有人凭直觉和经验摸索出有效的东西，然后才回去补科学解释。

先是手艺，再是科学。

例子：他自己当初看到 ChatGPT 用了 RL，第一反应是这太复杂了，用 SFT 就够了。直到他们用这个思路做了 Alpaca。结果证明在模型规模到了一定程度之后，RL 就是能用、而且效果更好。

五、Harness 的边界在哪

他说针对具体垂直场景的 Harness 短期内是有价值的，
能帮你从 80% 可靠性推到 85%。但你做的时候得知道，
模型在持续变好，Harness 需要不断重新调整。

想做一个能长期稳定的通用 Harness，他认为这个路走不通。

六、持续学习还没解决

三年前 ChatGPT 刚出来的时候，他和朋友还在讨论要不
要创业做持续学习和个性化记忆，但当时他们认为：
“OpenAI 六个月内就会搞定"，所以最终没做。

三年后，他在 OpenAI 了，这个问题还没真正解决。

现在 AI 模型的问题是：第一天入职比大多数新员工有
用，但之后基本保持不变，因为它不会随时间在具体环境
里变得越来越懂你、越来越高效。

而人类学得很快。把这条曲线从平的变成持续上升的，他
认为是接下来最重要的问题之一。

七、还有空间做垂直应用

有，而且很大。

真正的瓶颈从来不是智能本身，而是最后一公里：权限、数据接入、和具体业务的连接。

如果今天把现有模型冻住、只是认真做好 Harness 和垂直应用，大部分领域就已经能感受到 AGI 了。

https://t.co/m64N5N7ECr

[土豆本豆 @Potatoloogs]

@coldsake_ woc 我想过他们黑 没想过他们这么黑啊

[土豆本豆 @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