即刻App年轻人的同好社区
下载
如果你想认真学习 AI，而且之前没有什么基础，那我只推荐一个内容，就 YouTube 上的 Riley Brown。
这哥们是 Vibe Code 的创始人，频道里有非常多通俗易懂的 AI 入门教程。基本上我们知道的工具，他都会做一期。
比如最近 Codex 比较火，他刚刚就推出了一期教程，标题是《30 分钟带你吃透 Codex 的 95%》。我昨天也看了，评论区大家都说讲的非常清楚。确实，这是我见过的对初学者最友好的AI 教程。
Codex 这期内容，他会从零到一手把手演示怎么用 Codex 开发一个小工具。再往前，他也录过 Claude Code、OpenClaw 这些流行产品的视频教程。
这么讲吧，每一个重要的 AI 产品或者 AI 概念，他都会用大白话讲清楚具体怎么用。而且不来虚的，不会泛泛地铺一堆概念，而是直接带着大家上手做一个项目。
我非常喜欢他的内容。我之前自己做过教育，深知视频教程其实非常考验一个老师的魅力。有的博主一打开，神态就很老气，或者明显是在念稿子，我就关了。这哥们看着舒服，PPT 做得也好看，听他讲东西不费劲，能听进去。
当然我知道很多人会问，YouTube 上面是英文怎么办，听不懂啊。我想说，现在 AI 已经把语言的鸿沟基本填平了，英语稀烂也绝对不是问题。浏览器上装一个翻译插件，视频内容直接就能转成中文，跟着看就好。
而且这哥们的英文发音非常标准，如果还想顺便学一下英语，那看他的内容就更划算了。看完一期视频，AI 学到了，英语也跟着练了一遍，一举两得。
频道地址在这里：
www.youtube.com
前两天我写了一期 Claude Code 的教程，评论区有同学一直让我推荐好的学习资源。说实话，如果让我只推荐一个博主的话，那一定就是 Riley Brown。这哥们的表达和内容水准，超过了互联网上百分之九十的人。
他的频道中，如果要学 Codex，我最推荐这几期入门教程：
1、Learn 95% of Codex in 30 minutes
2、Codex Full Course 2026: The NEW Best AI Coding Tool
3、Codex Replaced Claude for Me… Here’s Why
如果要学 Claude Code，可以看：
1、The Complete Claude Code Workflow (to Build Anything)
2、How to Design With Claude Code (It's OVER for Figma)
如果你想学 Skill，可以看：
Claude Code Skills just Built me an AI Agent Team (2026 Guide)
现在如果想尝试最新的 Agent 技术，我优先推荐 Codex。
它有比较完整的图形界面，对没什么基础的同学很友好。像 Claude Code 这种在终端里跑的方式，好处当然很多，但很多人一看要敲命令行就劝退了，门槛确实高。
而且买 ChatGPT 会员会送 Codex 的额度，整体也划算。最近这一轮迭代完之后，我感觉这个产品已经做得非常好了。
关于 AI 的教程，我看到小红书上还有人推荐斯坦福大学的 CS135 课程，说实话这门课我真的不推荐给入门的小白。
前面放出来的几节课大家可以打开瞄一眼，讲的都是 AI 的基础设施和底层架构。
这玩意对零基础的人来说根本没必要看，也很难看懂。这门课本来就是讲给斯坦福学生听的，预设的知识背景跟普通人不一样。
最后多说一句今年我自己在实践的学习方法。
跟二十年前比，我们现在面对的是一个彻头彻尾的信息爆炸时代。每天早上一睁眼，要看的东西实在太多了。每个人好像都有自己的观点，洋洋洒洒一篇就发出来了。
要是每一篇都点进去读，那场面估计就跟小时候课文里那只小猴子下山差不多。见了桃子丢玉米，见了西瓜又丢桃子，到家两手空空。时间全花在切换上了。
我现在的做法很简单。忍住不去看那些浮在面上的内容，每天挑一个质量足够高的信息源，老老实实精读一遍，然后实践。
教程也一样，看的多没用，最聪明的方法就是找一个讲的好的视频，快速看完，然后实践。
共勉。
这哥们是 Vibe Code 的创始人，频道里有非常多通俗易懂的 AI 入门教程。基本上我们知道的工具，他都会做一期。
比如最近 Codex 比较火，他刚刚就推出了一期教程，标题是《30 分钟带你吃透 Codex 的 95%》。我昨天也看了，评论区大家都说讲的非常清楚。确实，这是我见过的对初学者最友好的AI 教程。
Codex 这期内容，他会从零到一手把手演示怎么用 Codex 开发一个小工具。再往前，他也录过 Claude Code、OpenClaw 这些流行产品的视频教程。
这么讲吧，每一个重要的 AI 产品或者 AI 概念，他都会用大白话讲清楚具体怎么用。而且不来虚的，不会泛泛地铺一堆概念，而是直接带着大家上手做一个项目。
我非常喜欢他的内容。我之前自己做过教育，深知视频教程其实非常考验一个老师的魅力。有的博主一打开，神态就很老气，或者明显是在念稿子，我就关了。这哥们看着舒服，PPT 做得也好看，听他讲东西不费劲，能听进去。
当然我知道很多人会问，YouTube 上面是英文怎么办，听不懂啊。我想说，现在 AI 已经把语言的鸿沟基本填平了，英语稀烂也绝对不是问题。浏览器上装一个翻译插件，视频内容直接就能转成中文，跟着看就好。
而且这哥们的英文发音非常标准，如果还想顺便学一下英语，那看他的内容就更划算了。看完一期视频，AI 学到了，英语也跟着练了一遍，一举两得。
频道地址在这里：
www.youtube.com
前两天我写了一期 Claude Code 的教程，评论区有同学一直让我推荐好的学习资源。说实话，如果让我只推荐一个博主的话，那一定就是 Riley Brown。这哥们的表达和内容水准，超过了互联网上百分之九十的人。
他的频道中，如果要学 Codex，我最推荐这几期入门教程：
1、Learn 95% of Codex in 30 minutes
2、Codex Full Course 2026: The NEW Best AI Coding Tool
3、Codex Replaced Claude for Me… Here’s Why
如果要学 Claude Code，可以看：
1、The Complete Claude Code Workflow (to Build Anything)
2、How to Design With Claude Code (It's OVER for Figma)
如果你想学 Skill，可以看：
Claude Code Skills just Built me an AI Agent Team (2026 Guide)
现在如果想尝试最新的 Agent 技术，我优先推荐 Codex。
它有比较完整的图形界面，对没什么基础的同学很友好。像 Claude Code 这种在终端里跑的方式，好处当然很多，但很多人一看要敲命令行就劝退了，门槛确实高。
而且买 ChatGPT 会员会送 Codex 的额度，整体也划算。最近这一轮迭代完之后，我感觉这个产品已经做得非常好了。
关于 AI 的教程，我看到小红书上还有人推荐斯坦福大学的 CS135 课程，说实话这门课我真的不推荐给入门的小白。
前面放出来的几节课大家可以打开瞄一眼，讲的都是 AI 的基础设施和底层架构。
这玩意对零基础的人来说根本没必要看，也很难看懂。这门课本来就是讲给斯坦福学生听的，预设的知识背景跟普通人不一样。
最后多说一句今年我自己在实践的学习方法。
跟二十年前比，我们现在面对的是一个彻头彻尾的信息爆炸时代。每天早上一睁眼，要看的东西实在太多了。每个人好像都有自己的观点，洋洋洒洒一篇就发出来了。
要是每一篇都点进去读，那场面估计就跟小时候课文里那只小猴子下山差不多。见了桃子丢玉米，见了西瓜又丢桃子，到家两手空空。时间全花在切换上了。
我现在的做法很简单。忍住不去看那些浮在面上的内容，每天挑一个质量足够高的信息源，老老实实精读一遍，然后实践。
教程也一样，看的多没用，最聪明的方法就是找一个讲的好的视频，快速看完，然后实践。
共勉。
106 1287
真的，Google DeepMind 的 CEO Demis Hassabis 每一期访谈我觉得值得都花时间看看。这哥们讲东西很实在，而且通俗易懂。
早上边跑步边听完了他和 YC CEO Garry Tan 的最新一期播客。
刚刚把笔记写完，也给大家分享下。
多说一句，好多人问我这种笔记是不是 AI 写的。我说下自己的流程。
我会先完整听完播客，然后用语音输入法把感触尽量充分地讲出来，再让 AI 帮着整理初稿，最后自己逐字修改优化。
如果全部交给 AI 做总结，那等于把思考和理解的能力让渡给了 AI，对自己理解这件事其实没有任何价值。
OK，咱们进正题。
1
Demis 的态度非常明确，现在的大模型范式（大规模预训练 + RLHF + CoT）一定会是 AGI 最终架构的一部分，他不认为这会是条死路。
但要实现 AGI，还有几个关键问题要解决。这几个问题包括：持续学习、长程推理和记忆系统。
先从最容易看到的现象讲起，Context Window。
现在大模型处理长信息，最常用的招就是把 Context Window 一直撑大。一开始 8k，后来 32k，再后来 100 万 Token。听起来很厉害，但本质上是暴力堆砌。
Context Window 其实就相当于人脑里的 Working Memory，工作记忆。人的工作记忆能同时装多少东西？心理学里有个经典数字，7 个左右。背电话号码能记住 7 位上下，再多就溢出了。
大模型呢？已经做到 100 万 Token。
按理说，模型的工作记忆比人大几十万倍，应该比人聪明几十万倍才对。但显然不是。
问题也恰恰就出现在这。把所有东西都塞进 Context Window 里，里面包含了不重要的东西、错的东西、过时的东西。看起来信息很多，其实是一团乱麻。
那人为什么 7 个数字的工作记忆就够用？
因为人脑背后还有另一套机制在工作。我们记得几年前的事，记得童年的事，记得几小时前发生的事。这些都不塞在工作记忆里，而是另一套系统。
具体来说这套系统是海马体，大脑里负责把新知识整合进已有知识库的那个部分。
研究发现，人睡觉的时候，特别是 REM 睡眠阶段，大脑会重放白天重要的片段，让大脑从中学习。新东西在睡觉的过程里，温柔地融进了旧的知识体系。
这个把新东西融进旧知识库的过程，就是持续学习。
模型现在没有这套机制。每一次对话结束，刚学到的东西就会忘记。下次重新打开，还是上次那个模型，没长进。
2
再聊聊长程推理的问题。英文表达是 Long-term Reasoning。我翻译为了长程。
长程推理这个词太抽象了。Demis 讲了一个特别具体的故事，听完会立刻明白他说的是什么。
他说自己喜欢跟 Gemini 下国际象棋。下棋的过程里能看到模型的 thinking trace，也就是它在那里到底想了什么。
然后他发现一件怪事。
模型考虑一步棋的时候，思考链里清清楚楚写着，这步是个昏招。但接下来，它没找到更好的走法，于是又走回这步昏招。
明明知道是错的，还是把错的那一步走出去了。
这个细节比任何 benchmark 数据都说明问题。因为它暴露的是模型缺少对自己思考过程的某种内省能力。
正常人下棋，意识到一步是昏招之后，脑子里会有一个反应，停一下，再想想。停一下、再想想这个能力，模型现在没有。它能在每一步局部判断对错，但没法基于整盘棋的局势去调整整体策略。
这就是长程推理还没搞定的样子。模型可以一步一步往前走，每一步看起来都合理，但走到后面整盘棋的方向其实是错的。它没有那种退回到当前思考的上一层、重新审视一下的能力。
说到底，模型缺的是一种内省。
3
学习、长程推理、记忆，这是 Demis 在播客里点出来的三个 AGI 鸿沟。
除此之外，他还反复提到了创造力。
2016 年 AlphaGo 跟李世石下棋，第二局走出了著名的 Move 37。那一步棋走出来的瞬间，全世界的围棋高手都看呆了。
所有人类几千年下围棋积累的经验都告诉它不该下那里，但 AlphaGo 下了。下完之后大家发现，是一步神来之笔。
很多人觉得，这就是 AI 的创造力来了。
但 Demis 说，对他自己来说，Move 37 只是起点。他真正想看到的是另一件事。AI 能不能发明围棋这件事本身。
这两件事的区别非常关键。
Move 37 是在围棋这个现成的规则里，找到了一步人类没想到的招。但围棋的规则、棋盘的形状、黑白子的对弈方式，是人类发明出来的。AI 在已有的框架里非常厉害，但能不能自己造一个框架，是另外一回事。
Demis 给了一个具体的设想。
如果给 AI 一个高层次的描述。造一个游戏，五分钟能学会规则，要好几辈子才能精通，棋局有审美，一下午能下完一局。AI 能不能根据这个描述，自己倒推出围棋？
目前做不到。
为了把这件事讲得更清楚，Demis 还提了一个测试，他自己叫爱因斯坦测试。
用 1901 年人类已有的全部知识训练一个模型，看它能不能在 1905 年那个时间点，自己推出狭义相对论。
爱因斯坦在 1905 年那一年里，连写了几篇改变物理学的论文，后来叫爱因斯坦奇迹年。那些工作不是从已有的物理学论文里通过拼接得到的，是基于已有材料做了一次全新的概念跳跃。
爱因斯坦测试想问的就是这件事。AI 能不能做这种跳跃。
目前的大模型主要在做两件事，pattern matching 和 extrapolation。一个是从大量数据里找规律，一个是把规律往外延伸一点。但发现新东西需要的是类比推理的能力。从一个领域里抽出深层结构，搬到另一个全新的领域去用。
这个能力，模型现在还没有。也可能是有，但用法不对所以激发不出来。
4
除此之外，Demis 还分享了一个让我特别出乎意料的判断，他说未来 6 到 12 个月，真正的价值不在更大的模型，在更小的模型。
这一部分内容我反复听了好几次，确实突破我的已有认知。
不知道大家的想法，反正我自己，这一年来并没有怎么关注小模型的进展。毕竟行业的焦点就是把模型做大嘛。
那小模型的价值到底在哪？
最直接的是成本。同样一个任务，小模型的推理价格可能只是前沿模型的十分之一甚至更少。
但 Demis 说，比成本更重要的其实是速度。
这里有一个前提得先说清楚。Demis 不是在说速度可以替代智能。
他的原话是，当小模型的能力已经达到前沿模型的 90% 到 95%，也就是已经相当不错的时候，剩下那 5% 到 10% 的能力差距，比不上速度带来的好处。
比如现在工程师用 AI 写代码，已经形成了一种新的工作节奏。一个想法冒出来，几秒之内就能看到结果，不行就改，再不行再改。
这个一改再改的循环跑得越快，做出来的东西就越好。如果每次调用都要等十秒，整个工作流就被打断了。
更关键的是，快到一定程度，工程师在这种节奏里能进入心流。一个想法、一次尝试、一个反馈、再来一个想法，思维不被打断。
这件事写过代码的人都懂，进入心流和频繁掉出心流，产出的差距是数量级的。
Agent 也是同样的逻辑。一个 Agent 跑完一个任务可能要调几十次模型，每次慢一秒，整个任务就慢一分钟。慢到一定程度，Agent 就从一个能用的东西变成鸡肋。
小模型不是大模型的廉价替代品。有些事只有小模型能做。
比如手机、眼镜、家用机器人，需要的就是一个能在本地跑起来的模型。本地跑除了反应快，还有一个特别重要的好处，隐私。
家里机器人看到的视频、听到的对话，全部在设备本地处理，根本不上云。这件事对很多用户来说不是加分项，是底线。
成本、速度、边缘部署，这是小模型的价值。
5
讲完小模型的价值，接下来一个更关键的问题是，能力被压到这么小的参数里，会不会有上限？
Demis 的判断是，目前没看到信息密度有任何理论上限。小模型的智能天花板还远没看到。
支撑这个判断的，是 DeepMind 在蒸馏这件事上的积累。蒸馏简单说就是先训练一个超大的模型，然后用这个超大模型去教一个小模型。教完之后，小模型用极少的参数，能复现原来 95% 以上的能力。
为什么 DeepMind 这么重视蒸馏？因为要把 AI 能力放进谷歌的头部产品中，前提是低延迟、低成本。前沿模型再强，每次推理花几秒钟、花几毛钱...这条路，恐怕很难走得通。
一个前沿模型发布之后，6 到 12 个月内，他们就能把这个模型的能力蒸馏到边缘设备能跑的小模型上去。这个时间表比很多人想的要快。
在很多场景中，小模型和大模型会相互配合。
举个例子，一个端到端的智能助手，绝大部分日常任务在本地的小模型上跑。智能眼镜看到的画面、家里机器人听到的对话、手机里的私人助理，模型直接在设备里读懂，不需要往云端传一遍。
只有遇到特别复杂、本地搞不定的问题，才向云端的前沿模型发起请求。
也就是说小模型在边缘做主力，前沿模型在云端做后援。
不过，这个构想对小模型的要求也比较高，它不能只会处理文字，还得能理解物理世界。
这就是为什么 Gemini 从一开始就坚持多模态，不光处理文字，也处理图像、视频、声音。
一开始这么做比只做文本要难得多，但眼镜也好，机器人也好，需要的是一个能看懂周围世界的模型，不是一个只会聊天的模型。
讲到这里，小模型这条路的轮廓就完全清楚了。它独立成立，不是前沿模型的廉价替代品，而是另一条同样重要的路。
嗯，很有启发。
早上边跑步边听完了他和 YC CEO Garry Tan 的最新一期播客。
刚刚把笔记写完，也给大家分享下。
多说一句，好多人问我这种笔记是不是 AI 写的。我说下自己的流程。
我会先完整听完播客，然后用语音输入法把感触尽量充分地讲出来，再让 AI 帮着整理初稿，最后自己逐字修改优化。
如果全部交给 AI 做总结，那等于把思考和理解的能力让渡给了 AI，对自己理解这件事其实没有任何价值。
OK，咱们进正题。
1
Demis 的态度非常明确，现在的大模型范式（大规模预训练 + RLHF + CoT）一定会是 AGI 最终架构的一部分，他不认为这会是条死路。
但要实现 AGI，还有几个关键问题要解决。这几个问题包括：持续学习、长程推理和记忆系统。
先从最容易看到的现象讲起，Context Window。
现在大模型处理长信息，最常用的招就是把 Context Window 一直撑大。一开始 8k，后来 32k，再后来 100 万 Token。听起来很厉害，但本质上是暴力堆砌。
Context Window 其实就相当于人脑里的 Working Memory，工作记忆。人的工作记忆能同时装多少东西？心理学里有个经典数字，7 个左右。背电话号码能记住 7 位上下，再多就溢出了。
大模型呢？已经做到 100 万 Token。
按理说，模型的工作记忆比人大几十万倍，应该比人聪明几十万倍才对。但显然不是。
问题也恰恰就出现在这。把所有东西都塞进 Context Window 里，里面包含了不重要的东西、错的东西、过时的东西。看起来信息很多，其实是一团乱麻。
那人为什么 7 个数字的工作记忆就够用？
因为人脑背后还有另一套机制在工作。我们记得几年前的事，记得童年的事，记得几小时前发生的事。这些都不塞在工作记忆里，而是另一套系统。
具体来说这套系统是海马体，大脑里负责把新知识整合进已有知识库的那个部分。
研究发现，人睡觉的时候，特别是 REM 睡眠阶段，大脑会重放白天重要的片段，让大脑从中学习。新东西在睡觉的过程里，温柔地融进了旧的知识体系。
这个把新东西融进旧知识库的过程，就是持续学习。
模型现在没有这套机制。每一次对话结束，刚学到的东西就会忘记。下次重新打开，还是上次那个模型，没长进。
2
再聊聊长程推理的问题。英文表达是 Long-term Reasoning。我翻译为了长程。
长程推理这个词太抽象了。Demis 讲了一个特别具体的故事，听完会立刻明白他说的是什么。
他说自己喜欢跟 Gemini 下国际象棋。下棋的过程里能看到模型的 thinking trace，也就是它在那里到底想了什么。
然后他发现一件怪事。
模型考虑一步棋的时候，思考链里清清楚楚写着，这步是个昏招。但接下来，它没找到更好的走法，于是又走回这步昏招。
明明知道是错的，还是把错的那一步走出去了。
这个细节比任何 benchmark 数据都说明问题。因为它暴露的是模型缺少对自己思考过程的某种内省能力。
正常人下棋，意识到一步是昏招之后，脑子里会有一个反应，停一下，再想想。停一下、再想想这个能力，模型现在没有。它能在每一步局部判断对错，但没法基于整盘棋的局势去调整整体策略。
这就是长程推理还没搞定的样子。模型可以一步一步往前走，每一步看起来都合理，但走到后面整盘棋的方向其实是错的。它没有那种退回到当前思考的上一层、重新审视一下的能力。
说到底，模型缺的是一种内省。
3
学习、长程推理、记忆，这是 Demis 在播客里点出来的三个 AGI 鸿沟。
除此之外，他还反复提到了创造力。
2016 年 AlphaGo 跟李世石下棋，第二局走出了著名的 Move 37。那一步棋走出来的瞬间，全世界的围棋高手都看呆了。
所有人类几千年下围棋积累的经验都告诉它不该下那里，但 AlphaGo 下了。下完之后大家发现，是一步神来之笔。
很多人觉得，这就是 AI 的创造力来了。
但 Demis 说，对他自己来说，Move 37 只是起点。他真正想看到的是另一件事。AI 能不能发明围棋这件事本身。
这两件事的区别非常关键。
Move 37 是在围棋这个现成的规则里，找到了一步人类没想到的招。但围棋的规则、棋盘的形状、黑白子的对弈方式，是人类发明出来的。AI 在已有的框架里非常厉害，但能不能自己造一个框架，是另外一回事。
Demis 给了一个具体的设想。
如果给 AI 一个高层次的描述。造一个游戏，五分钟能学会规则，要好几辈子才能精通，棋局有审美，一下午能下完一局。AI 能不能根据这个描述，自己倒推出围棋？
目前做不到。
为了把这件事讲得更清楚，Demis 还提了一个测试，他自己叫爱因斯坦测试。
用 1901 年人类已有的全部知识训练一个模型，看它能不能在 1905 年那个时间点，自己推出狭义相对论。
爱因斯坦在 1905 年那一年里，连写了几篇改变物理学的论文，后来叫爱因斯坦奇迹年。那些工作不是从已有的物理学论文里通过拼接得到的，是基于已有材料做了一次全新的概念跳跃。
爱因斯坦测试想问的就是这件事。AI 能不能做这种跳跃。
目前的大模型主要在做两件事，pattern matching 和 extrapolation。一个是从大量数据里找规律，一个是把规律往外延伸一点。但发现新东西需要的是类比推理的能力。从一个领域里抽出深层结构，搬到另一个全新的领域去用。
这个能力，模型现在还没有。也可能是有，但用法不对所以激发不出来。
4
除此之外，Demis 还分享了一个让我特别出乎意料的判断，他说未来 6 到 12 个月，真正的价值不在更大的模型，在更小的模型。
这一部分内容我反复听了好几次，确实突破我的已有认知。
不知道大家的想法，反正我自己，这一年来并没有怎么关注小模型的进展。毕竟行业的焦点就是把模型做大嘛。
那小模型的价值到底在哪？
最直接的是成本。同样一个任务，小模型的推理价格可能只是前沿模型的十分之一甚至更少。
但 Demis 说，比成本更重要的其实是速度。
这里有一个前提得先说清楚。Demis 不是在说速度可以替代智能。
他的原话是，当小模型的能力已经达到前沿模型的 90% 到 95%，也就是已经相当不错的时候，剩下那 5% 到 10% 的能力差距，比不上速度带来的好处。
比如现在工程师用 AI 写代码，已经形成了一种新的工作节奏。一个想法冒出来，几秒之内就能看到结果，不行就改，再不行再改。
这个一改再改的循环跑得越快，做出来的东西就越好。如果每次调用都要等十秒，整个工作流就被打断了。
更关键的是，快到一定程度，工程师在这种节奏里能进入心流。一个想法、一次尝试、一个反馈、再来一个想法，思维不被打断。
这件事写过代码的人都懂，进入心流和频繁掉出心流，产出的差距是数量级的。
Agent 也是同样的逻辑。一个 Agent 跑完一个任务可能要调几十次模型，每次慢一秒，整个任务就慢一分钟。慢到一定程度，Agent 就从一个能用的东西变成鸡肋。
小模型不是大模型的廉价替代品。有些事只有小模型能做。
比如手机、眼镜、家用机器人，需要的就是一个能在本地跑起来的模型。本地跑除了反应快，还有一个特别重要的好处，隐私。
家里机器人看到的视频、听到的对话，全部在设备本地处理，根本不上云。这件事对很多用户来说不是加分项，是底线。
成本、速度、边缘部署，这是小模型的价值。
5
讲完小模型的价值，接下来一个更关键的问题是，能力被压到这么小的参数里，会不会有上限？
Demis 的判断是，目前没看到信息密度有任何理论上限。小模型的智能天花板还远没看到。
支撑这个判断的，是 DeepMind 在蒸馏这件事上的积累。蒸馏简单说就是先训练一个超大的模型，然后用这个超大模型去教一个小模型。教完之后，小模型用极少的参数，能复现原来 95% 以上的能力。
为什么 DeepMind 这么重视蒸馏？因为要把 AI 能力放进谷歌的头部产品中，前提是低延迟、低成本。前沿模型再强，每次推理花几秒钟、花几毛钱...这条路，恐怕很难走得通。
一个前沿模型发布之后，6 到 12 个月内，他们就能把这个模型的能力蒸馏到边缘设备能跑的小模型上去。这个时间表比很多人想的要快。
在很多场景中，小模型和大模型会相互配合。
举个例子，一个端到端的智能助手，绝大部分日常任务在本地的小模型上跑。智能眼镜看到的画面、家里机器人听到的对话、手机里的私人助理，模型直接在设备里读懂，不需要往云端传一遍。
只有遇到特别复杂、本地搞不定的问题，才向云端的前沿模型发起请求。
也就是说小模型在边缘做主力，前沿模型在云端做后援。
不过，这个构想对小模型的要求也比较高，它不能只会处理文字，还得能理解物理世界。
这就是为什么 Gemini 从一开始就坚持多模态，不光处理文字，也处理图像、视频、声音。
一开始这么做比只做文本要难得多，但眼镜也好，机器人也好，需要的是一个能看懂周围世界的模型，不是一个只会聊天的模型。
讲到这里，小模型这条路的轮廓就完全清楚了。它独立成立，不是前沿模型的廉价替代品，而是另一条同样重要的路。
嗯，很有启发。
69 1043
推荐所有做产品的朋友都抽时间看一下 Claude Code 产品负责人 Cat Wu 的这次访谈。我还是非常有启发，毕竟，Claude Code 可能是今年最成功的 AI 产品之一。
访谈中，Cat Wu 分享了非常多我从没听过的产品认知，而且她还讲了 Anthropic 目前的产品发布流程，以及团队的结构。
一个感触是，我们确实应该主动求变。无论是团队的协同流程、结构，还是个人的工作习惯。
1
Cat 说，现在 Anthropic 的节奏，是把原来 6 个月的功能压缩到 1 个月，甚至 1 周、1 天上线。听起来确实很疯狂。
怎么做到的？可以从目标的定义、发布策略和流程说起。
他们对目标的定义非常清晰。Anthropic 的信条是，这个时代做一个谁都能用、但没人用得爽的功能，已经没有任何意义。
如果一个产品什么任务都能做一点，但每一个都做得很浅，那团队的方向就会特别模糊。方向一模糊，大家就得在十几个局部上分散精力，天天都觉得自己很忙，但每一件事都无法做精，做到极致。
Claude Code 团队的解法是把目标写的非常具体。比如，前段时间他们有个产品功能目标是这么写的：
帮助企业中的专业开发者减少权限弹窗，让他们在安全前提下尽可能做到零权限弹窗。
这里面每一个修饰词都在砍支路。用户不是所有人，是企业里的专业开发者。场景限定在保证安全的前提下。目标也不是减少一点。
能做的事情很多，要做的事情也很多。好 PM 最重要的能力之一，就是帮团队把目标定义到这种程度，一定要具体到一两类核心用户的几个典型任务，具体到一个可以被衡量的结果上。千万不要面面俱到。
目标定清楚之后，他们的第二个认知是要尽快把东西交到真实用户手里。
我们可以看到，Claude Code 几乎所有新功能一开始都以 Research Preview 形态上线，明确标注这是早期版本，随时会改，甚至可能下线。
这样做有两个好处。
一个是团队心理负担变小，不用一上来就搞得像 GA 那样一锤定音。另一个是可以在真实环境下快速收集反馈，再决定是做深还是砍掉。
大家想想，大公司里一个功能上线通常要开会、对齐、排期、做最终评审，摩擦力非常大。但 Claude Code 团队几乎把这些摩擦降到了零。大家可以快速从真实的用户那里收集反馈。
流程方面，他们也不是彻底放弃流程，而是保留了少数几个关键机制。
比如每周一起过指标，所有人都要对业务的关键数据、趋势和影响因素都有基本理解。再比如有一套团队原则文档，写清楚核心用户是谁、为什么是他们、愿意在什么地方做取舍。
2
Claude Code 团队还极度重视自动化。
他们的一个惯常思路是：盯住日常工作中每天都要重复做的事，选一件最烦的，用 AI 工具把它自动化到 100% 可以放心不管的程度。
关键词是 100%。
一个特别普遍的现象是，很多人把一个自动化做到 90% 或者 95% 成功率就停手了，觉得差不多够用。这根本不叫自动化，这叫半吊子工具。
为什么？因为剩下那 5% 的异常，反过来吃掉最多的注意力。
想象一个场景。搭了一个自动整理邮件的工作流，95% 的邮件能正确归类，5% 会分错。那 5% 会发生什么？每次打开邮箱都要把所有分类扫一眼确认没分错。哪怕只看一秒钟，这个动作已经占据了注意力。
结果就是理论上自动化了 95%，实际心力消耗可能只减少了 30%。花一堆时间搭的工作流，没真正解放出来。
那怎么做到 100%？Cat 有三条经验。
第一条，选对任务。
从每天真的在做、而且频率很高的事情下手，而不是那些听起来很酷、其实没那么刚需的活。
她自己试过用 Cowork 帮忙处理邮件，比如让 AI 帮她识别垃圾邮件、总结往来、生成回复草稿。结果搞了一阵发现，教模型怎么分类、怎么处理边界情况，比她自己点点归档还费时间，而且效果离完全不用管还差一截。
我知道，很多人经常被 X 上那些炫酷 workflow 带偏，去自动化一个月才做一两次的事情。即使你把这种自动化打磨到 100% 成功率，能省的时间也有限，还得多维护一个系统。
第二条，把整个工作都交给 AI，而不是让它只做某个局部。
举个例子，做大会的演讲 PPT。以前一份 20 页的演讲 PPT 手搓要花几个小时，AI 只能帮忙查一些资料。
但现在，她的做法是先把 Slack、Gmail、Calendar、Google Drive 全部接入 Cowork，然后把任务描述写清楚。
比如，这是演讲主题，这是产品营销同事的要点草稿，这是之前做过的一个不满意的旧版，这是公司的标准模板，请先给我一个大纲提案。
Cowork 花了大概一个小时，翻了 Twitter 上团队的产品发布记录，翻了 Claude Code 内部的 demo 频道，翻了发布间的公告，把一份 20 页的 PPT 搭了出来。第二天早上起床，只需要改风格、删字、选 demo。
她再三提醒，现在用 AI，关键点绝对不是某个酷炫的 Prompt，而是要给足上下文。
第三条，是别沉迷折腾工具本身。
现在大家很容易掉进一个坑。打开 X，一堆人在晒自己的 AI 工作流。屏幕上堆满了各种能力模块，接了一堆外部工具，配置看起来很复杂，像一个很厉害的系统。
但真正在用的人会发现，这种东西很容易变成另一个负担。
Cat 其实给了一个很简单的判断标准。
如果你做的这个东西，不能每天稳定帮你省下一点时间，那它就没什么价值。哪怕看起来再复杂，再高级，也只是个展示品。
真正有效的，反而是那种很朴素的东西。流程简单，能长期用，不需要频繁维护。可能没有那么炫，但每天都在帮你少做一小时重复工作。
3
PM 这个角色本身，正在被重新定义。Cat 观察到三个正在发生的现象：
第一个现象，角色边界在糊。
现象大致是这样的。PM 在做工程的事，工程师在做 PM 的事，设计师在做 PM 的同时还顺手写代码。
Claude Code 团队里几乎所有 PM 都当过工程师或者在产品里写过代码，设计师也全是前端工程师背景。一个工程师看到用户在 Twitter 上的反馈，一路自己改代码、写文案、交付，中间基本不经过 PM。
这跟很多大公司的情况完全相反。传统公司里角色分工很刚性，PM 写 PRD、工程师写代码、设计师画图，谁也别碰谁的地盘。Claude Code 团队反过来，大家都是混合体，没有明确的分工。
当然这种咬合在一起的状态能跑起来，前提是每个人都具备足够的产品品味。不然就变成一锅乱炖了。所以他们在招人时更在意的是：
1、你能不能端到端的把一个想法推到上线。
2、你有没有 Product Taste，而不是你曾经的职称是 Engineer / PM / Designer。
第二个现象，招聘逻辑跟着变了。
现在很多团队都会遇到一个选择。
是多招一些有产品感觉的工程师，让他们自己把很多 PM 的活一起做了，还是保持工程师规模不变，多招 PM，帮忙做筛选、对齐、推进。
表面上这是在调整团队结构，但本质上都是希望能够让团队中越来越多的人具备产品 Taste。因为真正决定效率和上限的，是这种能力的总量，而不是岗位比例。
Claude Code 走的是第一条路。
他们更偏好那种既能写代码，又能做产品判断的人。团队里的 PM 基本都有工程背景，设计师也能直接写前端。
这样一来，很多环节自然被压缩了。一个想法可以在一个人手里完成，从最初的构思，一路走到上线。中间少了大量沟通、对齐和反复确认的过程。
这也顺带解释了一个大家一直在问的问题。
PM 这个角色不会消失，但形态已经在变。单纯做协调、写文档、维护 roadmap 的空间在变小。更受欢迎的是那种有判断力、能动手、可以跨角色把事情推进到结果的人。
到了这个阶段，岗位名称本身已经不那么关键了。
第三个现象，人的软性能力越来越重要。因为 AI 越来越强，所以，大家不免说，那我们的价值是什么？Cat 的答案是：
1、理解真实世界里人和组织的关系网。谁是关键卡点、他们的偏好是什么、什么场合说什么话合适、哪些历史包袱不能碰。
这种社会智能、情境智能，目前的模型做不到。产品发布涉及的非结构化信息太多，这部分还是要人来做。沟通能力，以及让别人支持、信任我们的能力，会变得弥足珍贵。
2、承受和驾驭持续混沌。比如 Anthropic 很多时候的节奏是这样：周末冒出来一个 P0 的问题，然后周一上午升级成 P00，周一下午变 P000。这种环境里每个问题都焦虑就会崩溃。
Anthropic 特意招那种能在混乱里保持冷静和乐观的人，能看到问题的难度但不会被吓住，能接受暂时的粗糙。
3、看清什么事值得自己亲自做。任务爆炸的时候，残酷地优先级排序反而变得更值钱。承认自己做不了所有事，允许一些功能不够完美，只要不会伤到底层目标。
4
即便有些公司的招聘要求还很老套，但我也可以基本确定，他们已经不是一家 AI First 的公司。
在 Anthropic 看来，未来 PM 的核心技能有几个：
第一，学会看用户怎么滥用产品。
在任何一个 AI 产品里，都有一小批用户在做非常奇怪的事。写奇怪的 Prompt、拼脚本、绕开限制、把工具用出设计者没想到的花样。这些看起来是边角料的操作，其实是下一代功能最早的信号。
一个简单的例子。如果一部分用户一直在用复杂的 Prompt 让模型先列 To Do List 再逐条完成，这本身就说明他们需要一个原生的任务管理能力。
把它变成产品功能，用户就能得到更顺手的体验。不变，就只能一直看着用户在产品里打补丁。
最好的 PM 能从用户怎么在现有产品里打补丁里，看出下一代产品长什么样。
第二，学会把今天这个模型榨到极限。
Cat 特意说，这件事跟给超级 AGI 设计产品完全是两回事。给超级 AGI 设计产品非常简单。一个大输入框、什么都能干、模型自己判断、自己调用、自己完成。整个产品就是一个聊天窗。
难的是反过来。怎么用系统提示、工具设计、UI 引导，把用户行为限制在模型的优势区间里。怎么用流程、提示词、辅助工具（to-do list 就是一个典型例子）去弥补模型在记忆、坚持、验证上的弱点。
这件事的本质是知道模型哪强、哪弱，然后给用户铺一条路径。让用户在不知不觉中走到模型最擅长的地方去。
产品一旦能做到这一点，体验会立刻拉开和同行的差距。这也是为什么同样基于 Claude 的产品，有的跑得飞快，有的总显得笨笨的。差的不是模型，是有没有人在中间做这层铺垫。
第三，会和模型对话，不要只把它当黑盒。
大部分人用模型是这样的：给一个 Prompt，看一个结果，不满意就骂两句，或者改一改 Prompt 再试一次。这是把模型当成一个不会说话的黑盒。
Cat 的用法完全不一样。她会让模型自我反省。发现模型改了前端代码但没打开 UI 验证，她会让模型解释为什么没去点 UI。
是被系统提示误导了，还是 delegate 给 sub-agent 出了问题，然后反过来改 Harness（提示词、工具、工作流）。
这种对话的价值很大。因为模型其实能告诉 PM 哪里出了问题，只要 PM 肯问。大部分人之所以不会问，是因为从心态上就没把模型当成一个可以协作的对象。
把它当工具的人，永远在工具外面看。把它当协作者的人，能看到工具内部正在发生什么。
在新时代的 PM 工具箱里，和模型对话可能是最容易被忽视、但回报最高的一项技能。
第四，学会写 Eval。
Eval 听起来很工程师化，本质却很朴素：把一个模糊的目标变成一套可以自动化打分的测试。
好的 Eval 要能回答清楚三个问题：什么情况下算完成任务，差多少算不及格，新模型相比老模型到底好在哪里。
或者这么说吧，写 Eval 的真正意义，是在倒逼 PM 把产品目标想清楚。
因为一个写不出 Eval 的目标，大概率本身就是模糊的。
Cat 自己在某些不好衡量的功能上（比如 memory 那种没有明确对错的场景）会亲自下场设计 Eval，把产品目标直接写进自动化测试。
挺有启发的，大家可以去 Lenny 的频道找到这期播客。
访谈中，Cat Wu 分享了非常多我从没听过的产品认知，而且她还讲了 Anthropic 目前的产品发布流程，以及团队的结构。
一个感触是，我们确实应该主动求变。无论是团队的协同流程、结构，还是个人的工作习惯。
1
Cat 说，现在 Anthropic 的节奏，是把原来 6 个月的功能压缩到 1 个月，甚至 1 周、1 天上线。听起来确实很疯狂。
怎么做到的？可以从目标的定义、发布策略和流程说起。
他们对目标的定义非常清晰。Anthropic 的信条是，这个时代做一个谁都能用、但没人用得爽的功能，已经没有任何意义。
如果一个产品什么任务都能做一点，但每一个都做得很浅，那团队的方向就会特别模糊。方向一模糊，大家就得在十几个局部上分散精力，天天都觉得自己很忙，但每一件事都无法做精，做到极致。
Claude Code 团队的解法是把目标写的非常具体。比如，前段时间他们有个产品功能目标是这么写的：
帮助企业中的专业开发者减少权限弹窗，让他们在安全前提下尽可能做到零权限弹窗。
这里面每一个修饰词都在砍支路。用户不是所有人，是企业里的专业开发者。场景限定在保证安全的前提下。目标也不是减少一点。
能做的事情很多，要做的事情也很多。好 PM 最重要的能力之一，就是帮团队把目标定义到这种程度，一定要具体到一两类核心用户的几个典型任务，具体到一个可以被衡量的结果上。千万不要面面俱到。
目标定清楚之后，他们的第二个认知是要尽快把东西交到真实用户手里。
我们可以看到，Claude Code 几乎所有新功能一开始都以 Research Preview 形态上线，明确标注这是早期版本，随时会改，甚至可能下线。
这样做有两个好处。
一个是团队心理负担变小，不用一上来就搞得像 GA 那样一锤定音。另一个是可以在真实环境下快速收集反馈，再决定是做深还是砍掉。
大家想想，大公司里一个功能上线通常要开会、对齐、排期、做最终评审，摩擦力非常大。但 Claude Code 团队几乎把这些摩擦降到了零。大家可以快速从真实的用户那里收集反馈。
流程方面，他们也不是彻底放弃流程，而是保留了少数几个关键机制。
比如每周一起过指标，所有人都要对业务的关键数据、趋势和影响因素都有基本理解。再比如有一套团队原则文档，写清楚核心用户是谁、为什么是他们、愿意在什么地方做取舍。
2
Claude Code 团队还极度重视自动化。
他们的一个惯常思路是：盯住日常工作中每天都要重复做的事，选一件最烦的，用 AI 工具把它自动化到 100% 可以放心不管的程度。
关键词是 100%。
一个特别普遍的现象是，很多人把一个自动化做到 90% 或者 95% 成功率就停手了，觉得差不多够用。这根本不叫自动化，这叫半吊子工具。
为什么？因为剩下那 5% 的异常，反过来吃掉最多的注意力。
想象一个场景。搭了一个自动整理邮件的工作流，95% 的邮件能正确归类，5% 会分错。那 5% 会发生什么？每次打开邮箱都要把所有分类扫一眼确认没分错。哪怕只看一秒钟，这个动作已经占据了注意力。
结果就是理论上自动化了 95%，实际心力消耗可能只减少了 30%。花一堆时间搭的工作流，没真正解放出来。
那怎么做到 100%？Cat 有三条经验。
第一条，选对任务。
从每天真的在做、而且频率很高的事情下手，而不是那些听起来很酷、其实没那么刚需的活。
她自己试过用 Cowork 帮忙处理邮件，比如让 AI 帮她识别垃圾邮件、总结往来、生成回复草稿。结果搞了一阵发现，教模型怎么分类、怎么处理边界情况，比她自己点点归档还费时间，而且效果离完全不用管还差一截。
我知道，很多人经常被 X 上那些炫酷 workflow 带偏，去自动化一个月才做一两次的事情。即使你把这种自动化打磨到 100% 成功率，能省的时间也有限，还得多维护一个系统。
第二条，把整个工作都交给 AI，而不是让它只做某个局部。
举个例子，做大会的演讲 PPT。以前一份 20 页的演讲 PPT 手搓要花几个小时，AI 只能帮忙查一些资料。
但现在，她的做法是先把 Slack、Gmail、Calendar、Google Drive 全部接入 Cowork，然后把任务描述写清楚。
比如，这是演讲主题，这是产品营销同事的要点草稿，这是之前做过的一个不满意的旧版，这是公司的标准模板，请先给我一个大纲提案。
Cowork 花了大概一个小时，翻了 Twitter 上团队的产品发布记录，翻了 Claude Code 内部的 demo 频道，翻了发布间的公告，把一份 20 页的 PPT 搭了出来。第二天早上起床，只需要改风格、删字、选 demo。
她再三提醒，现在用 AI，关键点绝对不是某个酷炫的 Prompt，而是要给足上下文。
第三条，是别沉迷折腾工具本身。
现在大家很容易掉进一个坑。打开 X，一堆人在晒自己的 AI 工作流。屏幕上堆满了各种能力模块，接了一堆外部工具，配置看起来很复杂，像一个很厉害的系统。
但真正在用的人会发现，这种东西很容易变成另一个负担。
Cat 其实给了一个很简单的判断标准。
如果你做的这个东西，不能每天稳定帮你省下一点时间，那它就没什么价值。哪怕看起来再复杂，再高级，也只是个展示品。
真正有效的，反而是那种很朴素的东西。流程简单，能长期用，不需要频繁维护。可能没有那么炫，但每天都在帮你少做一小时重复工作。
3
PM 这个角色本身，正在被重新定义。Cat 观察到三个正在发生的现象：
第一个现象，角色边界在糊。
现象大致是这样的。PM 在做工程的事，工程师在做 PM 的事，设计师在做 PM 的同时还顺手写代码。
Claude Code 团队里几乎所有 PM 都当过工程师或者在产品里写过代码，设计师也全是前端工程师背景。一个工程师看到用户在 Twitter 上的反馈，一路自己改代码、写文案、交付，中间基本不经过 PM。
这跟很多大公司的情况完全相反。传统公司里角色分工很刚性，PM 写 PRD、工程师写代码、设计师画图，谁也别碰谁的地盘。Claude Code 团队反过来，大家都是混合体，没有明确的分工。
当然这种咬合在一起的状态能跑起来，前提是每个人都具备足够的产品品味。不然就变成一锅乱炖了。所以他们在招人时更在意的是：
1、你能不能端到端的把一个想法推到上线。
2、你有没有 Product Taste，而不是你曾经的职称是 Engineer / PM / Designer。
第二个现象，招聘逻辑跟着变了。
现在很多团队都会遇到一个选择。
是多招一些有产品感觉的工程师，让他们自己把很多 PM 的活一起做了，还是保持工程师规模不变，多招 PM，帮忙做筛选、对齐、推进。
表面上这是在调整团队结构，但本质上都是希望能够让团队中越来越多的人具备产品 Taste。因为真正决定效率和上限的，是这种能力的总量，而不是岗位比例。
Claude Code 走的是第一条路。
他们更偏好那种既能写代码，又能做产品判断的人。团队里的 PM 基本都有工程背景，设计师也能直接写前端。
这样一来，很多环节自然被压缩了。一个想法可以在一个人手里完成，从最初的构思，一路走到上线。中间少了大量沟通、对齐和反复确认的过程。
这也顺带解释了一个大家一直在问的问题。
PM 这个角色不会消失，但形态已经在变。单纯做协调、写文档、维护 roadmap 的空间在变小。更受欢迎的是那种有判断力、能动手、可以跨角色把事情推进到结果的人。
到了这个阶段，岗位名称本身已经不那么关键了。
第三个现象，人的软性能力越来越重要。因为 AI 越来越强，所以，大家不免说，那我们的价值是什么？Cat 的答案是：
1、理解真实世界里人和组织的关系网。谁是关键卡点、他们的偏好是什么、什么场合说什么话合适、哪些历史包袱不能碰。
这种社会智能、情境智能，目前的模型做不到。产品发布涉及的非结构化信息太多，这部分还是要人来做。沟通能力，以及让别人支持、信任我们的能力，会变得弥足珍贵。
2、承受和驾驭持续混沌。比如 Anthropic 很多时候的节奏是这样：周末冒出来一个 P0 的问题，然后周一上午升级成 P00，周一下午变 P000。这种环境里每个问题都焦虑就会崩溃。
Anthropic 特意招那种能在混乱里保持冷静和乐观的人，能看到问题的难度但不会被吓住，能接受暂时的粗糙。
3、看清什么事值得自己亲自做。任务爆炸的时候，残酷地优先级排序反而变得更值钱。承认自己做不了所有事，允许一些功能不够完美，只要不会伤到底层目标。
4
即便有些公司的招聘要求还很老套，但我也可以基本确定，他们已经不是一家 AI First 的公司。
在 Anthropic 看来，未来 PM 的核心技能有几个：
第一，学会看用户怎么滥用产品。
在任何一个 AI 产品里，都有一小批用户在做非常奇怪的事。写奇怪的 Prompt、拼脚本、绕开限制、把工具用出设计者没想到的花样。这些看起来是边角料的操作，其实是下一代功能最早的信号。
一个简单的例子。如果一部分用户一直在用复杂的 Prompt 让模型先列 To Do List 再逐条完成，这本身就说明他们需要一个原生的任务管理能力。
把它变成产品功能，用户就能得到更顺手的体验。不变，就只能一直看着用户在产品里打补丁。
最好的 PM 能从用户怎么在现有产品里打补丁里，看出下一代产品长什么样。
第二，学会把今天这个模型榨到极限。
Cat 特意说，这件事跟给超级 AGI 设计产品完全是两回事。给超级 AGI 设计产品非常简单。一个大输入框、什么都能干、模型自己判断、自己调用、自己完成。整个产品就是一个聊天窗。
难的是反过来。怎么用系统提示、工具设计、UI 引导，把用户行为限制在模型的优势区间里。怎么用流程、提示词、辅助工具（to-do list 就是一个典型例子）去弥补模型在记忆、坚持、验证上的弱点。
这件事的本质是知道模型哪强、哪弱，然后给用户铺一条路径。让用户在不知不觉中走到模型最擅长的地方去。
产品一旦能做到这一点，体验会立刻拉开和同行的差距。这也是为什么同样基于 Claude 的产品，有的跑得飞快，有的总显得笨笨的。差的不是模型，是有没有人在中间做这层铺垫。
第三，会和模型对话，不要只把它当黑盒。
大部分人用模型是这样的：给一个 Prompt，看一个结果，不满意就骂两句，或者改一改 Prompt 再试一次。这是把模型当成一个不会说话的黑盒。
Cat 的用法完全不一样。她会让模型自我反省。发现模型改了前端代码但没打开 UI 验证，她会让模型解释为什么没去点 UI。
是被系统提示误导了，还是 delegate 给 sub-agent 出了问题，然后反过来改 Harness（提示词、工具、工作流）。
这种对话的价值很大。因为模型其实能告诉 PM 哪里出了问题，只要 PM 肯问。大部分人之所以不会问，是因为从心态上就没把模型当成一个可以协作的对象。
把它当工具的人，永远在工具外面看。把它当协作者的人，能看到工具内部正在发生什么。
在新时代的 PM 工具箱里，和模型对话可能是最容易被忽视、但回报最高的一项技能。
第四，学会写 Eval。
Eval 听起来很工程师化，本质却很朴素：把一个模糊的目标变成一套可以自动化打分的测试。
好的 Eval 要能回答清楚三个问题：什么情况下算完成任务，差多少算不及格，新模型相比老模型到底好在哪里。
或者这么说吧，写 Eval 的真正意义，是在倒逼 PM 把产品目标想清楚。
因为一个写不出 Eval 的目标，大概率本身就是模糊的。
Cat 自己在某些不好衡量的功能上（比如 memory 那种没有明确对错的场景）会亲自下场设计 Eval，把产品目标直接写进自动化测试。
挺有启发的，大家可以去 Lenny 的频道找到这期播客。
160 13117
昨天下午听了一场具身智能的分享，只有 45 分钟，非常精彩，基本把整个行业目前的情况讲清楚了。我建议对具身智能感兴趣的朋友都找回放看一下。
分享人是明星创业公司自变量机器人的 CEO 王潜和 CTO 王昊。虽然是一场新模型的发布会，但他们都很实诚，实实在在把当下行业里的问题、自家的思路都摆在了台面上。
王潜开场的话让我印象很深。他说，我们每个人都期待，一觉醒来，家里的机器人能把房间打扫的干干净净。但目前没有任何一台机器人可以在没有遥控操作的情况下搞定这事。
AI 在数字世界的进展快得惊人，但到了物理世界，离我们想要的状态还很远。
这时候肯定有人要追问：机器人都能表演武术、跳舞、后空翻了，做点家务真的有这么难吗？再说，工厂里那些机器人上个世纪就已经非常成熟，难道家里的活儿，比工厂蓝领的工作还难干？
答案是：对，确实更难。
我们刷到的那些酷炫机器人视频，本质上都是预设动作。工程师提前把程序编好，机器人按部就班跑一遍就行。它看起来灵活聪明，其实根本不理解自己在干什么。
工厂机器人也类似，做的事情是重复。制衣厂的机械臂卡在一个环节，比如钉纽扣，每天把同一个动作重复一万次，精度是够的，但也仅此而已。
但家务活完全是另一回事。
今天餐桌的杯子，明天可能放在了卧室床头柜。昨天下午光线很亮，今天阴天光线就变了。极端一点讲，做家务的过程中，没有任何一次情况是跟上一次完全一致的。机器人必须当下识别、当下判断、当下执行。
那行业里现在是怎么解决这个问题的？
整体的思路，叫 VLA 架构。V 是视觉，L 是语言，A 是动作。把这三样打通，机器人就具备了基础的感知和执行能力。这条路已经跑了一段时间，我们现在看到的绝大多数具身智能模型，基本都是 VLA 架构。
但 VLA 有个本质问题，它的核心范式是模仿。
具体怎么运作？举个例子。想让机器人学会叠衣服，得先喂给它大量叠衣服的数据。模型在这个过程里，把看到的画面和对应的动作一点点记下来，形成一套反应模式。再遇到叠衣服的任务，它就调出这套模式来执行。
这套方法在实验室里跑得很漂亮。只要测试环境和训练时差不多，衣服能叠得整整齐齐。但场景一换，光线变了、衣服款式不一样了、桌子高一点矮一点，它就容易当场崩溃。
问题出在哪儿？它没有真正理解环境背后的规律。它学会了拿杯子这个动作，但不知道杯子为什么会掉下来；它知道盘子要放桌上，但不知道半个盘子悬空就要摔了。它记住的是动作的样子，不是动作背后的因果。一旦环境跟训练数据对不上，它立马就懵。
话说回来，VLA 这套思路并不是走错了路，反而是目前行业能找到的最好的方向。
在 VLA 出现之前，机器人的各项能力都是分家的。VLA 第一次把视觉、语言、动作这三件事连到了一起，让机器人具备了综合意义上的感知加执行能力。
这是一次很关键的跃迁，也正因为有这个突破，行业才愿意在这条路上投入这么多年。
只是跃迁归跃迁，短板还是在那儿。自变量之前发布的 WALL-A 模式，其实也是类似的 VLA 架构。
那怎么办？
在聊自变量的新模型之前，先说一下行业里其他公司在 VLA 基础上探索新的思路。
很多团队的做法，是在 VLA 之外再加一个世界模型模块，让两套系统协作。世界模型的核心能力是预测环境，就像我们人在伸手拿杯子之前，脑子里其实已经预演过一遍整个动作了。所以大家想，把世界模型加进去，机器人的理解能力不就上来了吗？
听起来挺合理，但其实不是这么回事。这种模块化拼接的方式，还是会损失信息，本质上只是一个过渡方案。
打个比方。苹果在自研芯片出来之前，电脑里的 CPU、GPU、内存是分开的几块芯片。用过那代 Intel 芯片 Mac 的人都有体会，卡顿、发烫是家常便饭。
核心问题就出在，信息要在几个芯片之间来回倒腾，损耗很大。后来 Apple Silicon 干了什么？把这些东西统一集成，数据不用再跨模块搬运，性能和能耗立刻上了一个台阶。
这次自变量发布的 WALL-B，干的就是类似 Apple Silicon 的事情。
WALL-B 的架构叫世界统一模型，英文缩写 WUM。思路其实很简单，不再把视觉、语言、动作拆成三块分开处理，也不靠模块之间传话，而是从训练的第一天起，就把所有这些能力放进同一个模型里一起训练。
相当于以前是多芯片架构，数据要在不同模块之间来回切换；现在是统一架构，所有能力在同一个系统里直接协同。
这样做带来的好处有三点。
第一是原生多模态。机器人不再是先看、再理解、再行动这种流水线式的操作，而是看的同时在理解，理解的同时在决定怎么动。整件事是同时发生的，跟我们人看到一张图不需要先翻译一遍是一个道理。
第二是对物理世界的理解。机器人不再只是识别出一个物体，而是开始理解物体背后的物理规律。
比如重力、惯性、摩擦力。这些都是底层的物理规律，不管家里什么布局、桌子什么材质，规律都一样。
盘子悬在桌边会掉下来，这件事跟盘子长什么样、桌子是木头还是大理石没关系。
第三是自我进化。机器人跟真实世界交互的过程中，能自动调整。比如杯子第一次没抓紧，它能立刻反应过来，下一次就知道该用多大的力。
架构说得差不多了，还有一个绕不开的问题，就是数据。因为模型最后的天花板，很大程度上是由数据决定的。
具身智能行业的数据大致分两类。一类是实验室里的干净数据，摆拍得整整齐齐，光线灯光都安排好。
另一类是家庭环境里的真实数据，乱的，复杂的，充满意外的。前一类数据不缺。后一类稀缺，而且难收集。
过去很长一段时间，行业里大家都在琢磨，能不能想办法绕开家庭真实数据这一关，比如用合成数据、用虚拟环境代替。
自变量给出的判断是，真实数据绕不开。也许最难的那条路，恰恰是最简单的路。想让机器人更快迭代，只有一个办法，尽可能多地收集真实环境的数据。
所以他们现在做的事，就是把机器人直接带进家庭，在真实的家里采集数据，用这种复杂、混乱、不可预测的环境去训练模型。
按他们的时间表，下个月新机器人就会正式进入首批用户家里，长期运行，收集真实世界的反馈。
首批体验用户的招募现在已经对外开放，感兴趣的朋友可以去关注一下，说不定你就是第一批家里有机器人保姆的人。
不过具体到机器人进家庭，其实很多人的第一反应是隐私。王潜在现场也专门讲了这一点。他说自己能理解这种担心，换做他自己，也怕一个会动会听会说话的东西进到家里，偷看到晚上11点穿着睡衣坐在沙发上吃方便面的样子。
所以他们也针对性做了处理。比如机器人看到的画面，在设备里就直接打码处理了，原始图像根本不往外传，也不上传云端。
要不要开机，也得主人自己按下同意键，不会偷偷启动。每台机器人只认自己的主人，察觉到奇怪的指令就会自动锁定。
最后再说两句感性的话。
我在现场看到自变量团队做的机器人发展史。在 2010 年之前的几十年里，机器人舞台上重要的创新，都是美国公司和日本公司主导。到了 2010 年之后，我才零星看到了中国公司出现。
然后在 2020 年之后，中国公司开始密集出现。当时我对着那张图看完，还是非常有冲击感，我能感觉到在这么重要的领域，中国的创业公司开始深度参与到创新的洪流当中，还是蛮兴奋。
分享人是明星创业公司自变量机器人的 CEO 王潜和 CTO 王昊。虽然是一场新模型的发布会，但他们都很实诚，实实在在把当下行业里的问题、自家的思路都摆在了台面上。
王潜开场的话让我印象很深。他说，我们每个人都期待，一觉醒来，家里的机器人能把房间打扫的干干净净。但目前没有任何一台机器人可以在没有遥控操作的情况下搞定这事。
AI 在数字世界的进展快得惊人，但到了物理世界，离我们想要的状态还很远。
这时候肯定有人要追问：机器人都能表演武术、跳舞、后空翻了，做点家务真的有这么难吗？再说，工厂里那些机器人上个世纪就已经非常成熟，难道家里的活儿，比工厂蓝领的工作还难干？
答案是：对，确实更难。
我们刷到的那些酷炫机器人视频，本质上都是预设动作。工程师提前把程序编好，机器人按部就班跑一遍就行。它看起来灵活聪明，其实根本不理解自己在干什么。
工厂机器人也类似，做的事情是重复。制衣厂的机械臂卡在一个环节，比如钉纽扣，每天把同一个动作重复一万次，精度是够的，但也仅此而已。
但家务活完全是另一回事。
今天餐桌的杯子，明天可能放在了卧室床头柜。昨天下午光线很亮，今天阴天光线就变了。极端一点讲，做家务的过程中，没有任何一次情况是跟上一次完全一致的。机器人必须当下识别、当下判断、当下执行。
那行业里现在是怎么解决这个问题的？
整体的思路，叫 VLA 架构。V 是视觉，L 是语言，A 是动作。把这三样打通，机器人就具备了基础的感知和执行能力。这条路已经跑了一段时间，我们现在看到的绝大多数具身智能模型，基本都是 VLA 架构。
但 VLA 有个本质问题，它的核心范式是模仿。
具体怎么运作？举个例子。想让机器人学会叠衣服，得先喂给它大量叠衣服的数据。模型在这个过程里，把看到的画面和对应的动作一点点记下来，形成一套反应模式。再遇到叠衣服的任务，它就调出这套模式来执行。
这套方法在实验室里跑得很漂亮。只要测试环境和训练时差不多，衣服能叠得整整齐齐。但场景一换，光线变了、衣服款式不一样了、桌子高一点矮一点，它就容易当场崩溃。
问题出在哪儿？它没有真正理解环境背后的规律。它学会了拿杯子这个动作，但不知道杯子为什么会掉下来；它知道盘子要放桌上，但不知道半个盘子悬空就要摔了。它记住的是动作的样子，不是动作背后的因果。一旦环境跟训练数据对不上，它立马就懵。
话说回来，VLA 这套思路并不是走错了路，反而是目前行业能找到的最好的方向。
在 VLA 出现之前，机器人的各项能力都是分家的。VLA 第一次把视觉、语言、动作这三件事连到了一起，让机器人具备了综合意义上的感知加执行能力。
这是一次很关键的跃迁，也正因为有这个突破，行业才愿意在这条路上投入这么多年。
只是跃迁归跃迁，短板还是在那儿。自变量之前发布的 WALL-A 模式，其实也是类似的 VLA 架构。
那怎么办？
在聊自变量的新模型之前，先说一下行业里其他公司在 VLA 基础上探索新的思路。
很多团队的做法，是在 VLA 之外再加一个世界模型模块，让两套系统协作。世界模型的核心能力是预测环境，就像我们人在伸手拿杯子之前，脑子里其实已经预演过一遍整个动作了。所以大家想，把世界模型加进去，机器人的理解能力不就上来了吗？
听起来挺合理，但其实不是这么回事。这种模块化拼接的方式，还是会损失信息，本质上只是一个过渡方案。
打个比方。苹果在自研芯片出来之前，电脑里的 CPU、GPU、内存是分开的几块芯片。用过那代 Intel 芯片 Mac 的人都有体会，卡顿、发烫是家常便饭。
核心问题就出在，信息要在几个芯片之间来回倒腾，损耗很大。后来 Apple Silicon 干了什么？把这些东西统一集成，数据不用再跨模块搬运，性能和能耗立刻上了一个台阶。
这次自变量发布的 WALL-B，干的就是类似 Apple Silicon 的事情。
WALL-B 的架构叫世界统一模型，英文缩写 WUM。思路其实很简单，不再把视觉、语言、动作拆成三块分开处理，也不靠模块之间传话，而是从训练的第一天起，就把所有这些能力放进同一个模型里一起训练。
相当于以前是多芯片架构，数据要在不同模块之间来回切换；现在是统一架构，所有能力在同一个系统里直接协同。
这样做带来的好处有三点。
第一是原生多模态。机器人不再是先看、再理解、再行动这种流水线式的操作，而是看的同时在理解，理解的同时在决定怎么动。整件事是同时发生的，跟我们人看到一张图不需要先翻译一遍是一个道理。
第二是对物理世界的理解。机器人不再只是识别出一个物体，而是开始理解物体背后的物理规律。
比如重力、惯性、摩擦力。这些都是底层的物理规律，不管家里什么布局、桌子什么材质，规律都一样。
盘子悬在桌边会掉下来，这件事跟盘子长什么样、桌子是木头还是大理石没关系。
第三是自我进化。机器人跟真实世界交互的过程中，能自动调整。比如杯子第一次没抓紧，它能立刻反应过来，下一次就知道该用多大的力。
架构说得差不多了，还有一个绕不开的问题，就是数据。因为模型最后的天花板，很大程度上是由数据决定的。
具身智能行业的数据大致分两类。一类是实验室里的干净数据，摆拍得整整齐齐，光线灯光都安排好。
另一类是家庭环境里的真实数据，乱的，复杂的，充满意外的。前一类数据不缺。后一类稀缺，而且难收集。
过去很长一段时间，行业里大家都在琢磨，能不能想办法绕开家庭真实数据这一关，比如用合成数据、用虚拟环境代替。
自变量给出的判断是，真实数据绕不开。也许最难的那条路，恰恰是最简单的路。想让机器人更快迭代，只有一个办法，尽可能多地收集真实环境的数据。
所以他们现在做的事，就是把机器人直接带进家庭，在真实的家里采集数据，用这种复杂、混乱、不可预测的环境去训练模型。
按他们的时间表，下个月新机器人就会正式进入首批用户家里，长期运行，收集真实世界的反馈。
首批体验用户的招募现在已经对外开放，感兴趣的朋友可以去关注一下，说不定你就是第一批家里有机器人保姆的人。
不过具体到机器人进家庭，其实很多人的第一反应是隐私。王潜在现场也专门讲了这一点。他说自己能理解这种担心，换做他自己，也怕一个会动会听会说话的东西进到家里，偷看到晚上11点穿着睡衣坐在沙发上吃方便面的样子。
所以他们也针对性做了处理。比如机器人看到的画面，在设备里就直接打码处理了，原始图像根本不往外传，也不上传云端。
要不要开机，也得主人自己按下同意键，不会偷偷启动。每台机器人只认自己的主人，察觉到奇怪的指令就会自动锁定。
最后再说两句感性的话。
我在现场看到自变量团队做的机器人发展史。在 2010 年之前的几十年里，机器人舞台上重要的创新，都是美国公司和日本公司主导。到了 2010 年之后，我才零星看到了中国公司出现。
然后在 2020 年之后，中国公司开始密集出现。当时我对着那张图看完，还是非常有冲击感，我能感觉到在这么重要的领域，中国的创业公司开始深度参与到创新的洪流当中，还是蛮兴奋。
4 01
斯坦福大学这个 AI 的讲座简直太好了。
比我们见过所有 Claude 或者 Prompt 相关的教程都要实用得多。
这门课的标题是 Beyond LLM，光这个标题就很有意思，它没有教大家怎么用某个模型，而是在回答一个更本质的问题：拿到一个大模型之后，怎么才能真正把它用好？
课上有一个实验特别有冲击力。哈佛商学院联合几所大学，找了一批波士顿咨询公司（BCG）的咨询顾问做实验。
BCG 是全球顶级的管理咨询公司，这些顾问本身就是高知人群。实验把他们分成三组：第一组完全不用 AI，第二组可以用 GPT-4，第三组也用 GPT-4 但额外接受了提示词工程的培训。
结果第三组全面碾压。更扎心的发现是，第二组在部分任务上的表现，竟然比完全不用 AI 的第一组还差。
换句话说，一群顶尖咨询顾问，拿到了 AI 却不会用，还不如没有。
这个结论值得展开聊一聊。
1
那个 BCG 实验里最有价值的概念，叫 JAG 边界线。
简单来说就是，AI 的能力有一条看不见的边界。在这条线以内的任务，AI 确实能大幅提升人的效率和质量。但一旦任务超出了这条线，AI 不仅帮不上忙，还会拖后腿。
为什么会拖后腿？因为人在这种情况下容易出现一种状态，研究者形容得很生动，叫 falling asleep at the wheel，方向盘上睡着了。
就是人一旦觉得 AI 能搞定，就会放松警惕，不再仔细审查输出。而那些恰好超出 AI 能力范围的任务，AI 会给出看起来很像那么回事、实际上有问题的答案。
人没有 review，直接提交了。最终效果比自己独立完成还差。
这件事最值得深想的地方在于：很多人评估自己和 AI 的关系时，关注的是模型够不够强。
但这个实验证明，真正拉开差距的，是使用者能不能判断一件事到底在不在 AI 的能力圈内。
实验还发现了两种截然不同的人机协作风格。一种叫半人马 Centaur，把一整块任务打包丢给 AI，等它输出成果。
比如一个咨询顾问要做 PPT，直接写一大段 Prompt 描述清楚要求，让 AI 生成，回来就用。
另一种叫赛博格 Cyborg，完全嵌入式协作，一句一句跟 AI 来回交锋，随时纠偏、随时追问，像融为一体那样工作。学生群体天然更偏赛博格，喜欢高频互动。
企业场景更偏半人马，因为需要把一段流程整块外包出去。两种模式没有优劣之分，但知道自己当前处于哪种模式，什么场景该切换，这个意识很重要。
那具体到使用层面，差距从哪里开始拉开？最基础的一步其实就是上下文。
同样是让 AI 总结一篇文章，一个人写的 Prompt 是：总结这篇文章。
另一个人写的是：把这篇 10 页的可再生能源论文，用 5 个要点总结，聚焦核心发现和对政策制定者的启示。
两者的产出质量完全不在一个级别。差别就在于后者提供了受众、格式和关注重点。
再往上一层，是 few-shot，也就是在 Prompt 里给几个例子来校准模型。
课上有个特别贴切的场景：让模型判断一条产品评论是正面、负面还是中性。那条评论的内容大意是，产品还行但我期望更高。
有人觉得这是中性，有人觉得是负面。在某些高端行业，这算严重差评；在某些行业，这已经算不错了。
如果不提供示例来校准，模型按自己的理解判断，大概率对不上业务需求。加了两三个标注过的例子之后，模型就会按照给定的标准去分类，准确率大幅上升。
这就是 few-shot 的本质：它不是在教模型新知识，是在告诉模型，在我这个场景里，标准长什么样。
有些做得更精细的 AI 创业公司，甚至会持续维护 few-shot 示例库，把用户反馈和人工标注过的 case 追加到 Prompt 里，在不碰模型参数的前提下，持续把模型往自己的业务标准上拉。
2
上面聊的都是单条 Prompt 层面的优化，核心解决的是怎么问的问题。但真实业务场景中，很多任务一条 Prompt 搞不定。
举个课上的例子。假设要给一条客户差评写一封专业回复，最直接的做法是把所有要求全塞进一条 Prompt：读这条评论，写一封专业回复，要承认问题、解释原因、提供解决方案。
模型确实能输出，但如果质量不行，根本不知道哪个环节出了毛病。是没抓住关键问题？是回复结构不好？还是语气不对？全部混在一起，没法定位。
提示链 Chaining 的思路就是把这一条 Prompt 拆成三条。第一条：从评论中提取关键问题。
第二条：基于这些问题，草拟回复大纲。第三条：按照大纲写正式回复。每一步的输入输出都是独立的，哪一步效果不好，就单独优化哪一步。
这个思路就像把一个巨大的单体应用拆成微服务，每个模块可以独立测试、独立迭代。
课上有学生问：三条 Prompt 各自验证过了，能不能再合回一条来减少延迟？答案是：合回去之后中间步骤的输出就看不到了。
那些中间输出恰恰是最有调试价值的东西。比如第一步提取的关键问题是否准确，直接决定了后面两步的天花板。在追求质量控制的场景里，中间可见性比省一两秒延迟重要得多。
那拆完之后，怎么知道每一步到底好不好？这就到了评估 Evals 的问题。最直接的方式当然是人工打分，但不可能大规模用。
更实用的做法是自动化评测：用一个 LLM 来当裁判，做 pairwise comparison，或者设定一套评分标准 rubric，从长度、覆盖率、格式、准确性这几个维度让模型打分。
这个思路之所以重要，是因为它把 AI 工作流从感觉还不错推向了可以量化衡量。有了评估体系，每次改动都有数据支撑，这才算是工程化。
到这里，提示词和提示链本质上都是在优化怎么问。但有一类问题，不管怎么问都没用，因为模型自己脑子里就没有那些知识。
企业内部文档、垂直行业的细分规则、最近刚发生的事件，模型在训练时根本没见过。这时候需要解决的是知道的不够的问题。
这就是 RAG 检索增强生成出场的地方。
RAG 的逻辑很直觉：与其改造模型的大脑，不如给模型配一个随时可查的资料库。具体做法是把文档切块、向量化，存进向量数据库。
用户提问时，先把问题也向量化，去数据库里找到最相关的几段文档，拼接到 Prompt 里一起发给模型。模型基于检索到的内容来回答，既减少了幻觉，又能标注信息来源。
那为什么不直接微调模型，让它从根上学会这些知识？课上的态度非常明确：大多数情况下不建议微调。
微调需要大量标注数据，成本高；容易过拟合，通用能力反而下降，课上有人拿 Slack 消息微调模型，聊天风格学得很像了，别的任务水平却明显变差；
最现实的一点是，模型迭代速度太快，等花几个月完成微调，新一代基座模型已经发布了，原始能力可能已经超过微调过的旧模型，之前的投入全部沉没。
关于 RAG 有一个特别好的讨论：如果未来算力无限，RAG 是不是就没用了？理论上模型可以直接读完所有文档再回答。
这个设想在逻辑上成立，但延迟问题无解，总不能每次回答一个问题就把整个文档库从头到尾读一遍。
就像搜索引擎一样，即便有能力爬下整个互联网的内容，依然需要索引和检索系统来快速定位信息。RAG 解决的是效率和精度问题，跟算力是否充足关系不大。
在具体方法上，RAG 也在持续进化。比如 chunking，不只存整篇文档的向量，也把章节、段落级别的向量单独存起来，检索时能定位到更精确的位置。
还有一个巧妙的方法叫 HIDE：用户的问题往往很短，跟文档库里的长文本在向量空间里距离可能很远。
HIDE 的做法是先让模型根据问题生成一个假想的回答文档，再拿这个假想文档去做检索，因为格式和长度跟真实文档更接近，召回效果会更好。
3
到目前为止聊的所有方法，提示词解决怎么问，提示链解决怎么拆，RAG 解决知道的不够。但它们有一个共同特点：本质上都还是人发起指令，AI 执行。
真实业务里的很多流程是动态的，步骤之间有依赖关系，有些步骤还需要调用外部系统、向用户追问信息才能往下走。这就是 Agent 智能体要解决的问题：一步搞不完的任务。
课上的例子特别直观。一个客服场景，用户问：我能退款吗？如果只用 RAG，模型查完退款政策会回复一句：购买 30 天内可以退款。
标准答案，但对话就断了。换成 Agent 工作流，Agent 先检索退款政策，然后主动追问订单号，调用订单系统 API 查询详情，确认符合条件，最后回复退款将在 3 到 5 个工作日内处理。这已经不是在回答问题了，这是在完成任务。
Agent 在技术上有三个核心组件：提示词定义角色和行为边界，上下文管理系统负责维持状态和记忆，工具层连接外部 API 让 Agent 能跟真实世界交互。
关于工具层，课上区分了 API 和 MCP（Model Context Protocol）。
API 需要提前硬编码调用方式和参数格式，每个系统写一份。MCP 把模型和外部系统的连接标准化了，Agent 可以自己理解一个端点能提供什么数据、需要什么输入。
打个比方，API 像是给 Agent 一份操作手册，MCP 像是给了 Agent 一种通用能力，看到新系统就能自己搞清楚怎么用。单个 Agent 时差别不大，但涉及多 Agent 通信时，MCP 的价值就凸显了。
这就自然过渡到多 Agent 系统。课上用智能家居做例子：一个 Agent 负责温控，一个负责照明，一个负责安防，一个负责能源管理，上面加一个总指挥 orchestrator 来统筹。
用户只跟总指挥对话，总指挥调度各专项 Agent。好处很直接：每个 Agent 专注一件事，调试简单，而且可以并行运行。
当温控 Agent 需要跟能源 Agent 直接沟通时，比如要开暖气但电费太贵，它们之间的通信方式本质上就是 MCP，一个 Agent 把另一个当工具来调用。
不过课上对多 Agent 保持了克制：单 Agent 和多 Agent 都只是结构选择，关键看任务本身适合什么形态。
把视角拉远一点，Agent 带来的变化远超技术本身。传统软件处理结构化数据，输入输出确定。
Agent 软件处理自由文本、图片、语音，输出带有不确定性。课上有个很精准的总结：最厉害的工程师，是那些能在确定性思维和模糊性思维之间自如切换的人。
设计 Agent 系统的思路也不同，传统按技术模块划分前端后端数据层，Agent 更像在管理一个团队，按业务角色拆分，每个 Agent 负责一个角色。
但落地最难的部分往往跟技术无关。McKinsey 做过一个案例：一家金融机构的信用风险备忘录，传统流程需要一到四周，客户经理从 15 个以上数据源收集信息，信贷分析师花 20 小时以上写初稿，再反复修改。
引入 Agent 工作流后，客户经理直接和 AI 协作，Agent 把任务分给专项子 Agent，从多数据源收集分析、生成初稿，流程时间缩短 20% 到 60%。
技术验证很漂亮。但课上紧接着做了一个非常清醒的判断：想让一万个信贷分析师和客户经理真正改变工作流程，可能需要十年甚至二十年。
改流程就是改人。改人的习惯、改组织的惯性、改绩效考核的标准，每一项的难度都远超技术本身。
4
聊到这里，我们其实已经走完了从提示词到多 Agent 的整条路。值得停下来回头看一看，这五层东西到底在解决什么层次的问题，彼此之间是什么关系。
提示词和 few-shot 解决的是怎么问。模型能力就在那里，但如果不把上下文、受众、格式、示例说清楚，输出大概率不是想要的。这一层做的是校准。
提示链解决的是怎么拆。复杂任务拆成几步，每一步可以独立优化和调试。这一层做的是流程控制。
RAG 解决的是知道的不够。前两层不管怎么优化，如果模型脑子里就没有需要的知识，再好的 Prompt 也问不出正确答案。这一层做的是知识补给。
Agent 解决的是一步搞不完。多步骤自主行动，中间要调 API、追问用户、判断条件再决定下一步。这一层做的是任务执行。
多 Agent 解决的是一个角色管不过来。拆成多个专项角色，并行运行、分工协作。这一层做的是组织分工。
五层之间的递进关系很清楚：校准 → 流程控制 → 知识补给 → 任务执行 → 组织分工。每一层都是在上一层搞不定的时候才需要往上走。
这个递进意识很关键，因为现实中很多团队的问题恰恰是跳层。提示词层面的优化还没做到位，补充上下文和示例就能解决的事情，直接跳到搭 Agent。
Agent 的复杂度比提示词高了好几个数量级，维护成本、调试难度、出错概率都会上升。
相反，也有团队死磕提示词，把一条 Prompt 改了 50 版，其实模型本身就缺少必要的领域知识，该上 RAG 了。
判断该不该升级到下一层，有一些实用的信号。改措辞和格式还能提升效果，说明提示词层还有空间。
中间步骤总出错但定位不了，说明该拆成链。事实层面经常出错或缺少关键信息，说明该引入 RAG。任务需要多步动态决策和外部交互，说明该上 Agent。
一个 Agent 职责太杂开始频繁出错，说明该拆成多 Agent。每往上走一层，系统复杂度都会显著增加，所以好的工程判断力，是在当前层把事情做透之后，准确识别出该往上走的时机。
课上的设计理念本身就体现了这种思路。这门课刻意没有深入讲第 17 种 RAG 优化方法，也没有手把手教每一个 Agent 框架怎么用。
原因很直接：技能的半衰期太短了。今天花大量时间学透的某个具体技术细节，两年后很可能已经被淘汰。
所以课程的策略是先给一张足够宽的认知地图，让学生知道这些方向的存在和彼此的关系，需要的时候能快速冲刺去深入。
这个思路对所有跟 AI 打交道的人都适用。
与其追着每一个新工具跑，不如先搞清楚提示词、提示链、RAG、Agent、多 Agent 系统各自在解决什么层次的问题，它们之间是什么递进关系。
有了这张地图，再去追具体技术，速度会快得多，也不容易在信息洪流里迷路。
比我们见过所有 Claude 或者 Prompt 相关的教程都要实用得多。
这门课的标题是 Beyond LLM，光这个标题就很有意思，它没有教大家怎么用某个模型，而是在回答一个更本质的问题：拿到一个大模型之后，怎么才能真正把它用好？
课上有一个实验特别有冲击力。哈佛商学院联合几所大学，找了一批波士顿咨询公司（BCG）的咨询顾问做实验。
BCG 是全球顶级的管理咨询公司，这些顾问本身就是高知人群。实验把他们分成三组：第一组完全不用 AI，第二组可以用 GPT-4，第三组也用 GPT-4 但额外接受了提示词工程的培训。
结果第三组全面碾压。更扎心的发现是，第二组在部分任务上的表现，竟然比完全不用 AI 的第一组还差。
换句话说，一群顶尖咨询顾问，拿到了 AI 却不会用，还不如没有。
这个结论值得展开聊一聊。
1
那个 BCG 实验里最有价值的概念，叫 JAG 边界线。
简单来说就是，AI 的能力有一条看不见的边界。在这条线以内的任务，AI 确实能大幅提升人的效率和质量。但一旦任务超出了这条线，AI 不仅帮不上忙，还会拖后腿。
为什么会拖后腿？因为人在这种情况下容易出现一种状态，研究者形容得很生动，叫 falling asleep at the wheel，方向盘上睡着了。
就是人一旦觉得 AI 能搞定，就会放松警惕，不再仔细审查输出。而那些恰好超出 AI 能力范围的任务，AI 会给出看起来很像那么回事、实际上有问题的答案。
人没有 review，直接提交了。最终效果比自己独立完成还差。
这件事最值得深想的地方在于：很多人评估自己和 AI 的关系时，关注的是模型够不够强。
但这个实验证明，真正拉开差距的，是使用者能不能判断一件事到底在不在 AI 的能力圈内。
实验还发现了两种截然不同的人机协作风格。一种叫半人马 Centaur，把一整块任务打包丢给 AI，等它输出成果。
比如一个咨询顾问要做 PPT，直接写一大段 Prompt 描述清楚要求，让 AI 生成，回来就用。
另一种叫赛博格 Cyborg，完全嵌入式协作，一句一句跟 AI 来回交锋，随时纠偏、随时追问，像融为一体那样工作。学生群体天然更偏赛博格，喜欢高频互动。
企业场景更偏半人马，因为需要把一段流程整块外包出去。两种模式没有优劣之分，但知道自己当前处于哪种模式，什么场景该切换，这个意识很重要。
那具体到使用层面，差距从哪里开始拉开？最基础的一步其实就是上下文。
同样是让 AI 总结一篇文章，一个人写的 Prompt 是：总结这篇文章。
另一个人写的是：把这篇 10 页的可再生能源论文，用 5 个要点总结，聚焦核心发现和对政策制定者的启示。
两者的产出质量完全不在一个级别。差别就在于后者提供了受众、格式和关注重点。
再往上一层，是 few-shot，也就是在 Prompt 里给几个例子来校准模型。
课上有个特别贴切的场景：让模型判断一条产品评论是正面、负面还是中性。那条评论的内容大意是，产品还行但我期望更高。
有人觉得这是中性，有人觉得是负面。在某些高端行业，这算严重差评；在某些行业，这已经算不错了。
如果不提供示例来校准，模型按自己的理解判断，大概率对不上业务需求。加了两三个标注过的例子之后，模型就会按照给定的标准去分类，准确率大幅上升。
这就是 few-shot 的本质：它不是在教模型新知识，是在告诉模型，在我这个场景里，标准长什么样。
有些做得更精细的 AI 创业公司，甚至会持续维护 few-shot 示例库，把用户反馈和人工标注过的 case 追加到 Prompt 里，在不碰模型参数的前提下，持续把模型往自己的业务标准上拉。
2
上面聊的都是单条 Prompt 层面的优化，核心解决的是怎么问的问题。但真实业务场景中，很多任务一条 Prompt 搞不定。
举个课上的例子。假设要给一条客户差评写一封专业回复，最直接的做法是把所有要求全塞进一条 Prompt：读这条评论，写一封专业回复，要承认问题、解释原因、提供解决方案。
模型确实能输出，但如果质量不行，根本不知道哪个环节出了毛病。是没抓住关键问题？是回复结构不好？还是语气不对？全部混在一起，没法定位。
提示链 Chaining 的思路就是把这一条 Prompt 拆成三条。第一条：从评论中提取关键问题。
第二条：基于这些问题，草拟回复大纲。第三条：按照大纲写正式回复。每一步的输入输出都是独立的，哪一步效果不好，就单独优化哪一步。
这个思路就像把一个巨大的单体应用拆成微服务，每个模块可以独立测试、独立迭代。
课上有学生问：三条 Prompt 各自验证过了，能不能再合回一条来减少延迟？答案是：合回去之后中间步骤的输出就看不到了。
那些中间输出恰恰是最有调试价值的东西。比如第一步提取的关键问题是否准确，直接决定了后面两步的天花板。在追求质量控制的场景里，中间可见性比省一两秒延迟重要得多。
那拆完之后，怎么知道每一步到底好不好？这就到了评估 Evals 的问题。最直接的方式当然是人工打分，但不可能大规模用。
更实用的做法是自动化评测：用一个 LLM 来当裁判，做 pairwise comparison，或者设定一套评分标准 rubric，从长度、覆盖率、格式、准确性这几个维度让模型打分。
这个思路之所以重要，是因为它把 AI 工作流从感觉还不错推向了可以量化衡量。有了评估体系，每次改动都有数据支撑，这才算是工程化。
到这里，提示词和提示链本质上都是在优化怎么问。但有一类问题，不管怎么问都没用，因为模型自己脑子里就没有那些知识。
企业内部文档、垂直行业的细分规则、最近刚发生的事件，模型在训练时根本没见过。这时候需要解决的是知道的不够的问题。
这就是 RAG 检索增强生成出场的地方。
RAG 的逻辑很直觉：与其改造模型的大脑，不如给模型配一个随时可查的资料库。具体做法是把文档切块、向量化，存进向量数据库。
用户提问时，先把问题也向量化，去数据库里找到最相关的几段文档，拼接到 Prompt 里一起发给模型。模型基于检索到的内容来回答，既减少了幻觉，又能标注信息来源。
那为什么不直接微调模型，让它从根上学会这些知识？课上的态度非常明确：大多数情况下不建议微调。
微调需要大量标注数据，成本高；容易过拟合，通用能力反而下降，课上有人拿 Slack 消息微调模型，聊天风格学得很像了，别的任务水平却明显变差；
最现实的一点是，模型迭代速度太快，等花几个月完成微调，新一代基座模型已经发布了，原始能力可能已经超过微调过的旧模型，之前的投入全部沉没。
关于 RAG 有一个特别好的讨论：如果未来算力无限，RAG 是不是就没用了？理论上模型可以直接读完所有文档再回答。
这个设想在逻辑上成立，但延迟问题无解，总不能每次回答一个问题就把整个文档库从头到尾读一遍。
就像搜索引擎一样，即便有能力爬下整个互联网的内容，依然需要索引和检索系统来快速定位信息。RAG 解决的是效率和精度问题，跟算力是否充足关系不大。
在具体方法上，RAG 也在持续进化。比如 chunking，不只存整篇文档的向量，也把章节、段落级别的向量单独存起来，检索时能定位到更精确的位置。
还有一个巧妙的方法叫 HIDE：用户的问题往往很短，跟文档库里的长文本在向量空间里距离可能很远。
HIDE 的做法是先让模型根据问题生成一个假想的回答文档，再拿这个假想文档去做检索，因为格式和长度跟真实文档更接近，召回效果会更好。
3
到目前为止聊的所有方法，提示词解决怎么问，提示链解决怎么拆，RAG 解决知道的不够。但它们有一个共同特点：本质上都还是人发起指令，AI 执行。
真实业务里的很多流程是动态的，步骤之间有依赖关系，有些步骤还需要调用外部系统、向用户追问信息才能往下走。这就是 Agent 智能体要解决的问题：一步搞不完的任务。
课上的例子特别直观。一个客服场景，用户问：我能退款吗？如果只用 RAG，模型查完退款政策会回复一句：购买 30 天内可以退款。
标准答案，但对话就断了。换成 Agent 工作流，Agent 先检索退款政策，然后主动追问订单号，调用订单系统 API 查询详情，确认符合条件，最后回复退款将在 3 到 5 个工作日内处理。这已经不是在回答问题了，这是在完成任务。
Agent 在技术上有三个核心组件：提示词定义角色和行为边界，上下文管理系统负责维持状态和记忆，工具层连接外部 API 让 Agent 能跟真实世界交互。
关于工具层，课上区分了 API 和 MCP（Model Context Protocol）。
API 需要提前硬编码调用方式和参数格式，每个系统写一份。MCP 把模型和外部系统的连接标准化了，Agent 可以自己理解一个端点能提供什么数据、需要什么输入。
打个比方，API 像是给 Agent 一份操作手册，MCP 像是给了 Agent 一种通用能力，看到新系统就能自己搞清楚怎么用。单个 Agent 时差别不大，但涉及多 Agent 通信时，MCP 的价值就凸显了。
这就自然过渡到多 Agent 系统。课上用智能家居做例子：一个 Agent 负责温控，一个负责照明，一个负责安防，一个负责能源管理，上面加一个总指挥 orchestrator 来统筹。
用户只跟总指挥对话，总指挥调度各专项 Agent。好处很直接：每个 Agent 专注一件事，调试简单，而且可以并行运行。
当温控 Agent 需要跟能源 Agent 直接沟通时，比如要开暖气但电费太贵，它们之间的通信方式本质上就是 MCP，一个 Agent 把另一个当工具来调用。
不过课上对多 Agent 保持了克制：单 Agent 和多 Agent 都只是结构选择，关键看任务本身适合什么形态。
把视角拉远一点，Agent 带来的变化远超技术本身。传统软件处理结构化数据，输入输出确定。
Agent 软件处理自由文本、图片、语音，输出带有不确定性。课上有个很精准的总结：最厉害的工程师，是那些能在确定性思维和模糊性思维之间自如切换的人。
设计 Agent 系统的思路也不同，传统按技术模块划分前端后端数据层，Agent 更像在管理一个团队，按业务角色拆分，每个 Agent 负责一个角色。
但落地最难的部分往往跟技术无关。McKinsey 做过一个案例：一家金融机构的信用风险备忘录，传统流程需要一到四周，客户经理从 15 个以上数据源收集信息，信贷分析师花 20 小时以上写初稿，再反复修改。
引入 Agent 工作流后，客户经理直接和 AI 协作，Agent 把任务分给专项子 Agent，从多数据源收集分析、生成初稿，流程时间缩短 20% 到 60%。
技术验证很漂亮。但课上紧接着做了一个非常清醒的判断：想让一万个信贷分析师和客户经理真正改变工作流程，可能需要十年甚至二十年。
改流程就是改人。改人的习惯、改组织的惯性、改绩效考核的标准，每一项的难度都远超技术本身。
4
聊到这里，我们其实已经走完了从提示词到多 Agent 的整条路。值得停下来回头看一看，这五层东西到底在解决什么层次的问题，彼此之间是什么关系。
提示词和 few-shot 解决的是怎么问。模型能力就在那里，但如果不把上下文、受众、格式、示例说清楚，输出大概率不是想要的。这一层做的是校准。
提示链解决的是怎么拆。复杂任务拆成几步，每一步可以独立优化和调试。这一层做的是流程控制。
RAG 解决的是知道的不够。前两层不管怎么优化，如果模型脑子里就没有需要的知识，再好的 Prompt 也问不出正确答案。这一层做的是知识补给。
Agent 解决的是一步搞不完。多步骤自主行动，中间要调 API、追问用户、判断条件再决定下一步。这一层做的是任务执行。
多 Agent 解决的是一个角色管不过来。拆成多个专项角色，并行运行、分工协作。这一层做的是组织分工。
五层之间的递进关系很清楚：校准 → 流程控制 → 知识补给 → 任务执行 → 组织分工。每一层都是在上一层搞不定的时候才需要往上走。
这个递进意识很关键，因为现实中很多团队的问题恰恰是跳层。提示词层面的优化还没做到位，补充上下文和示例就能解决的事情，直接跳到搭 Agent。
Agent 的复杂度比提示词高了好几个数量级，维护成本、调试难度、出错概率都会上升。
相反，也有团队死磕提示词，把一条 Prompt 改了 50 版，其实模型本身就缺少必要的领域知识，该上 RAG 了。
判断该不该升级到下一层，有一些实用的信号。改措辞和格式还能提升效果，说明提示词层还有空间。
中间步骤总出错但定位不了，说明该拆成链。事实层面经常出错或缺少关键信息，说明该引入 RAG。任务需要多步动态决策和外部交互，说明该上 Agent。
一个 Agent 职责太杂开始频繁出错，说明该拆成多 Agent。每往上走一层，系统复杂度都会显著增加，所以好的工程判断力，是在当前层把事情做透之后，准确识别出该往上走的时机。
课上的设计理念本身就体现了这种思路。这门课刻意没有深入讲第 17 种 RAG 优化方法，也没有手把手教每一个 Agent 框架怎么用。
原因很直接：技能的半衰期太短了。今天花大量时间学透的某个具体技术细节，两年后很可能已经被淘汰。
所以课程的策略是先给一张足够宽的认知地图，让学生知道这些方向的存在和彼此的关系，需要的时候能快速冲刺去深入。
这个思路对所有跟 AI 打交道的人都适用。
与其追着每一个新工具跑，不如先搞清楚提示词、提示链、RAG、Agent、多 Agent 系统各自在解决什么层次的问题，它们之间是什么递进关系。
有了这张地图，再去追具体技术，速度会快得多，也不容易在信息洪流里迷路。
3 15
今天刷到一期特别好的播客，嘉宾叫 Jyothi Nookula，在 AI PM 这个领域干了 13 年半，拿过 12 项 AI 专利，先后在 Meta、Amazon、Netflix 担任 AI 产品负责人。
这期节目聊到了 AI 产品经理和传统产品经理的区别，AI PM 的分类，以及怎么一步步走进这个领域。
内容足够具体。不是那种泛泛的趋势分析，而是实打实的认知框架和决策方法。我把核心内容整理成三个部分，从认知到落地逐步展开。希望对大家有启发。
同样，这期内容也送给我的好朋友阿蚁。他最近正在焦灼的准备 AI 产品经理的面试。我想这篇文章，应该能给他带来一些新的视角。
1
AI 产品经理这个岗位，在不同的公司，工作内容差异特别大。所以大家在选择的时候，一定要看清楚。
整体来看，AI 产品经理可以分成两类。
第一类，其实还是传统 PM，只是产品里加了 AI 功能。比如给客服系统加个聊天机器人，给文档工具加个摘要功能。这类岗位占大头，大概 80%。产品本身原来就存在，AI 更像一个增强层，一个外挂。
第二类，才是真正的 AI 原生 PM。这类岗位大概只占 20%。这里的产品从底层就是 AI，AI 不是功能点，而是产品本体。像 ChatGPT、Claude、Copilot、Cursor、Perplexity 这种，都属于这个范畴。它们的共同点是，离开 AI，这个产品根本没法成立。
这两类岗位的能力要求完全不同。前者更像是在已有产品上做增量，后者要从零理解 AI 的边界和可能性。很多人冲着第二类去投简历，但绝大多数机会其实在第一类。
同时，按照技术栈来划分，又可以大致分为三类：
最上面是应用层 PM，占 60%。这群人关注的是用户怎么跟 AI 交互，怎么建立信任，怎么让 AI 在日常场景里好用。这一层是传统 PM 转型最容易切入的地方，因为它需要的技能组合跟原来最接近：用户洞察、体验设计、需求优先级。
中间是平台层 PM，占 30%。做的是给其他团队用的工具和系统，比如模型编排平台、评估框架、可观测性工具。需要懂技术架构，也要懂开发者体验。
最底下是基础设施层 PM，只有 10%。向量数据库、GPU 调度、模型推理优化，都是这群人的地盘。技术门槛最高，岗位也最少。
越往底层走，技术要求越高。转型最现实的路径是从应用层开始，不是因为它简单，而是因为它最接近原有的技能基础，学习曲线平滑一些。在这一层站稳了，再决定要不要往下探。
2
我一个朋友前两天跟我聊，他想转型做 AI 产品经理，因为 AI 是明确的趋势，如果自己做的事跟 AI 不沾边，就没办法赶上这一波红利。而所以他的思路是尽快转到 AI 相关的产品经理岗位上。
想法没问题，但紧接着就有一个很现实的问题：怎么让别人相信自己能胜任这份工作？
这期播客里提到一个特别实在的思路：做产品，别做项目。
这两个词听起来差不多，区别其实很大。项目是完成就结束了，做完打个勾，写进简历。产品是要有人用的，要上线，要面对真实用户的反馈。
很多人学 AI PM 的方式是看课程、做练习、拿证书。这些都有用，但不够。因为面试的时候能说的只有概念和流程，没有体感和判断。
更好的方式是找一个自己真实的痛点，用 AI 来解决它。做出来之后，让朋友和家人用起来。这时候突然就有了真实用户，开始处理真实的反馈，要做真实的迭代决策。这些经历才是面试时有底气的来源。
一个不错的入门 portfolio 是三样东西：一个解决真实痛点的 AI 应用，一个 Agent，一个 RAG 系统。不用很复杂，用 Vibe Coding 的方式，结合云平台的能力。关键是完整走一遍从想法到上线的过程。
很多人觉得先学完、准备好了，再去做东西。顺序应该反过来。在做的过程中学，遇到不懂的再去补。这样学到的东西是长在骨头里的，不是飘在空中的概念。
而且做产品有一个额外的好处：它会逼着人思考真正重要的问题。这个场景真的需要 AI 吗？用什么技术方案？怎么评估效果？这些问题在课程里是习题，在真实产品里是必须回答的。
3
接下来说说 AI PM 这个角色最核心的思维转变。
传统产品是确定性的，AI 产品是概率性的。这是根本区别。
确定性的意思是，一个按钮点下去，每次都打开同一个页面。一个表单提交之后，每次都走同一个流程。输入和输出之间有稳定的映射关系，可以预测，可以复现。
AI 产品不是这样。同样的问题问两遍，答案可能不一样。同样的图片识别两次，置信度可能有波动。这不是 bug，这是大模型的本质特征。
对产品经理来说，这意味着不能再用对错二元来思考问题了。传统产品里，一个功能要么 work 要么不 work。AI 产品里，要开始想质量分布：大多数情况下表现怎么样，极端情况下会出什么问题，用户能接受的错误率是多少。
举个例子。一个客服机器人，90%的时候能正确回答问题，10%的时候会犯错。这个表现能不能上线？取决于那 10%的错误会带来什么后果。如果只是回答不够完美，用户可能会宽容。如果错误会导致财务损失或者安全问题，10%就太高了。
AI PM 需要建立一套新的评估框架。不是问这个功能行不行，而是问这个功能的表现分布是什么样的，哪些情况下表现好，哪些情况下会退化，退化的时候怎么兜底。
还有一个变化：数据变成了一等公民。
传统产品里，数据更多是用来做分析的，帮助理解用户行为、优化转化漏斗。AI 产品里，数据直接就是产品体验的一部分。模型是用数据训练出来的，数据质量差，模型表现就差。Garbage in, garbage out.
AI PM 必须关心数据从哪里来、质量怎么样、有没有偏差、够不够用。数据策略不是工程师的事情，这是产品设计的一部分。在动手做任何 AI 项目之前，得先把数据问题想清楚。
4
思维转变之后，最后说说具体怎么做决策。
第一个要判断的：这个问题应该用 AI 解决，还是用规则就够了？
现在有一种风气，好像什么问题都要往 AI 上靠。但知道什么时候对 AI 说 No，是 AI PM 很重要的能力。
适合用 AI 的情况：复杂数据里有模式，但人很难手动定义规则；有几年的历史数据，想预测未来趋势；需要给成千上万的用户提供个性化体验，靠人根本做不过来。
适合用规则的情况：可解释性是刚需，必须说清楚为什么做这个决定；业务逻辑很明确，写成 if-then 就能搞定；数据量太小，不够训练一个靠谱的模型；开发速度是第一优先级，没时间折腾。
第二个要判断的：如果要用 AI，选哪种技术？
AI 技术可以分成三个桶。
传统机器学习，包括回归、随机森林、XGBoost 这些。成熟稳定，现在依然支撑着大量 AI 应用。适合结构化数据，能放进电子表格那种，想预测一个数字或者一个类别。欺诈检测、用户流失预测，都是它的强项。
深度学习，包括神经网络、计算机视觉、语音识别。适合感知类任务，输入是图像、视频、音频。一个判断标准是：人类做这个任务很容易，但写规则很难。比如认出一张脸是谁，人眼一看就知道，但让工程师写代码描述什么特征构成这张脸，几乎不可能。
生成式 AI，包括大语言模型、图像生成模型。适合理解或生成自然语言，跨多个信息源做推理和综合，用户要用对话方式跟产品交互。
这三类技术不是竞争关系，是工具箱里的不同工具。最好的 AI 产品往往会混合使用。
第三个要判断的：要不要做 Fine-tuning？
Fine-tuning 永远不应该是第一选择，甚至不应该是第二选择。
正确的顺序是这样的。先优化 Prompt，设计好系统提示词，提供几个好的示例。然后做 Context Engineering，搞清楚该往模型里塞什么信息、什么时候塞。再然后是 RAG，从知识库里动态检索相关内容，让模型基于企业自己的数据来回答。
这三步走完，80%的用例都能解决。只有这些都不够用的时候，才考虑 Fine-tuning。因为 Fine-tuning 成本高、周期长，而且一不小心就会把模型调坏。性价比非常低。所以，非必要，非老板拍板，别轻易做微调。
5
AI 产品经理其实是个新行当。有点像十多年前移动互联网刚起来的时候，大家都在招客户端产品经理、移动端产品经理。那时候这个岗位也很新，大家对它的理解差异也很大，技术栈也在快速变化。
几点建议。
第一，紧跟技术前沿。要知道当下最新的趋势是什么，硅谷有哪些有意思的产品。这个边界每隔几个月就会移动一次，得跟上。
第二，尝试用 AI Native 的方式去解决问题。同样是做一个数据分析，以前的习惯是打开 Excel 自己算。现在能不能让 AI 来算？同样是写一份报告，以前是从空白文档开始敲字。现在能不能先让 AI 出个初稿，再在上面改？这个思维方式的切换，比学任何具体工具都重要。
第三，Build Something。看再多文章、听再多播客，不如自己动手做一个东西出来。做出来的东西就是作品，作品会替人说话。
早点建立作品思维。如果我们做成的那些事情中，其中有一件的产出是一个可以称为“作品”的东西，能够持续、深度影响到很多人，那这件事就会成为我们人生的杠杆、思想的放大器。
这期节目聊到了 AI 产品经理和传统产品经理的区别，AI PM 的分类，以及怎么一步步走进这个领域。
内容足够具体。不是那种泛泛的趋势分析，而是实打实的认知框架和决策方法。我把核心内容整理成三个部分，从认知到落地逐步展开。希望对大家有启发。
同样，这期内容也送给我的好朋友阿蚁。他最近正在焦灼的准备 AI 产品经理的面试。我想这篇文章，应该能给他带来一些新的视角。
1
AI 产品经理这个岗位，在不同的公司，工作内容差异特别大。所以大家在选择的时候，一定要看清楚。
整体来看，AI 产品经理可以分成两类。
第一类，其实还是传统 PM，只是产品里加了 AI 功能。比如给客服系统加个聊天机器人，给文档工具加个摘要功能。这类岗位占大头，大概 80%。产品本身原来就存在，AI 更像一个增强层，一个外挂。
第二类，才是真正的 AI 原生 PM。这类岗位大概只占 20%。这里的产品从底层就是 AI，AI 不是功能点，而是产品本体。像 ChatGPT、Claude、Copilot、Cursor、Perplexity 这种，都属于这个范畴。它们的共同点是，离开 AI，这个产品根本没法成立。
这两类岗位的能力要求完全不同。前者更像是在已有产品上做增量，后者要从零理解 AI 的边界和可能性。很多人冲着第二类去投简历，但绝大多数机会其实在第一类。
同时，按照技术栈来划分，又可以大致分为三类：
最上面是应用层 PM，占 60%。这群人关注的是用户怎么跟 AI 交互，怎么建立信任，怎么让 AI 在日常场景里好用。这一层是传统 PM 转型最容易切入的地方，因为它需要的技能组合跟原来最接近：用户洞察、体验设计、需求优先级。
中间是平台层 PM，占 30%。做的是给其他团队用的工具和系统，比如模型编排平台、评估框架、可观测性工具。需要懂技术架构，也要懂开发者体验。
最底下是基础设施层 PM，只有 10%。向量数据库、GPU 调度、模型推理优化，都是这群人的地盘。技术门槛最高，岗位也最少。
越往底层走，技术要求越高。转型最现实的路径是从应用层开始，不是因为它简单，而是因为它最接近原有的技能基础，学习曲线平滑一些。在这一层站稳了，再决定要不要往下探。
2
我一个朋友前两天跟我聊，他想转型做 AI 产品经理，因为 AI 是明确的趋势，如果自己做的事跟 AI 不沾边，就没办法赶上这一波红利。而所以他的思路是尽快转到 AI 相关的产品经理岗位上。
想法没问题，但紧接着就有一个很现实的问题：怎么让别人相信自己能胜任这份工作？
这期播客里提到一个特别实在的思路：做产品，别做项目。
这两个词听起来差不多，区别其实很大。项目是完成就结束了，做完打个勾，写进简历。产品是要有人用的，要上线，要面对真实用户的反馈。
很多人学 AI PM 的方式是看课程、做练习、拿证书。这些都有用，但不够。因为面试的时候能说的只有概念和流程，没有体感和判断。
更好的方式是找一个自己真实的痛点，用 AI 来解决它。做出来之后，让朋友和家人用起来。这时候突然就有了真实用户，开始处理真实的反馈，要做真实的迭代决策。这些经历才是面试时有底气的来源。
一个不错的入门 portfolio 是三样东西：一个解决真实痛点的 AI 应用，一个 Agent，一个 RAG 系统。不用很复杂，用 Vibe Coding 的方式，结合云平台的能力。关键是完整走一遍从想法到上线的过程。
很多人觉得先学完、准备好了，再去做东西。顺序应该反过来。在做的过程中学，遇到不懂的再去补。这样学到的东西是长在骨头里的，不是飘在空中的概念。
而且做产品有一个额外的好处：它会逼着人思考真正重要的问题。这个场景真的需要 AI 吗？用什么技术方案？怎么评估效果？这些问题在课程里是习题，在真实产品里是必须回答的。
3
接下来说说 AI PM 这个角色最核心的思维转变。
传统产品是确定性的，AI 产品是概率性的。这是根本区别。
确定性的意思是，一个按钮点下去，每次都打开同一个页面。一个表单提交之后，每次都走同一个流程。输入和输出之间有稳定的映射关系，可以预测，可以复现。
AI 产品不是这样。同样的问题问两遍，答案可能不一样。同样的图片识别两次，置信度可能有波动。这不是 bug，这是大模型的本质特征。
对产品经理来说，这意味着不能再用对错二元来思考问题了。传统产品里，一个功能要么 work 要么不 work。AI 产品里，要开始想质量分布：大多数情况下表现怎么样，极端情况下会出什么问题，用户能接受的错误率是多少。
举个例子。一个客服机器人，90%的时候能正确回答问题，10%的时候会犯错。这个表现能不能上线？取决于那 10%的错误会带来什么后果。如果只是回答不够完美，用户可能会宽容。如果错误会导致财务损失或者安全问题，10%就太高了。
AI PM 需要建立一套新的评估框架。不是问这个功能行不行，而是问这个功能的表现分布是什么样的，哪些情况下表现好，哪些情况下会退化，退化的时候怎么兜底。
还有一个变化：数据变成了一等公民。
传统产品里，数据更多是用来做分析的，帮助理解用户行为、优化转化漏斗。AI 产品里，数据直接就是产品体验的一部分。模型是用数据训练出来的，数据质量差，模型表现就差。Garbage in, garbage out.
AI PM 必须关心数据从哪里来、质量怎么样、有没有偏差、够不够用。数据策略不是工程师的事情，这是产品设计的一部分。在动手做任何 AI 项目之前，得先把数据问题想清楚。
4
思维转变之后，最后说说具体怎么做决策。
第一个要判断的：这个问题应该用 AI 解决，还是用规则就够了？
现在有一种风气，好像什么问题都要往 AI 上靠。但知道什么时候对 AI 说 No，是 AI PM 很重要的能力。
适合用 AI 的情况：复杂数据里有模式，但人很难手动定义规则；有几年的历史数据，想预测未来趋势；需要给成千上万的用户提供个性化体验，靠人根本做不过来。
适合用规则的情况：可解释性是刚需，必须说清楚为什么做这个决定；业务逻辑很明确，写成 if-then 就能搞定；数据量太小，不够训练一个靠谱的模型；开发速度是第一优先级，没时间折腾。
第二个要判断的：如果要用 AI，选哪种技术？
AI 技术可以分成三个桶。
传统机器学习，包括回归、随机森林、XGBoost 这些。成熟稳定，现在依然支撑着大量 AI 应用。适合结构化数据，能放进电子表格那种，想预测一个数字或者一个类别。欺诈检测、用户流失预测，都是它的强项。
深度学习，包括神经网络、计算机视觉、语音识别。适合感知类任务，输入是图像、视频、音频。一个判断标准是：人类做这个任务很容易，但写规则很难。比如认出一张脸是谁，人眼一看就知道，但让工程师写代码描述什么特征构成这张脸，几乎不可能。
生成式 AI，包括大语言模型、图像生成模型。适合理解或生成自然语言，跨多个信息源做推理和综合，用户要用对话方式跟产品交互。
这三类技术不是竞争关系，是工具箱里的不同工具。最好的 AI 产品往往会混合使用。
第三个要判断的：要不要做 Fine-tuning？
Fine-tuning 永远不应该是第一选择，甚至不应该是第二选择。
正确的顺序是这样的。先优化 Prompt，设计好系统提示词，提供几个好的示例。然后做 Context Engineering，搞清楚该往模型里塞什么信息、什么时候塞。再然后是 RAG，从知识库里动态检索相关内容，让模型基于企业自己的数据来回答。
这三步走完，80%的用例都能解决。只有这些都不够用的时候，才考虑 Fine-tuning。因为 Fine-tuning 成本高、周期长，而且一不小心就会把模型调坏。性价比非常低。所以，非必要，非老板拍板，别轻易做微调。
5
AI 产品经理其实是个新行当。有点像十多年前移动互联网刚起来的时候，大家都在招客户端产品经理、移动端产品经理。那时候这个岗位也很新，大家对它的理解差异也很大，技术栈也在快速变化。
几点建议。
第一，紧跟技术前沿。要知道当下最新的趋势是什么，硅谷有哪些有意思的产品。这个边界每隔几个月就会移动一次，得跟上。
第二，尝试用 AI Native 的方式去解决问题。同样是做一个数据分析，以前的习惯是打开 Excel 自己算。现在能不能让 AI 来算？同样是写一份报告，以前是从空白文档开始敲字。现在能不能先让 AI 出个初稿，再在上面改？这个思维方式的切换，比学任何具体工具都重要。
第三，Build Something。看再多文章、听再多播客，不如自己动手做一个东西出来。做出来的东西就是作品，作品会替人说话。
早点建立作品思维。如果我们做成的那些事情中，其中有一件的产出是一个可以称为“作品”的东西，能够持续、深度影响到很多人，那这件事就会成为我们人生的杠杆、思想的放大器。
8 312
一篇文章讲清楚爆火的 DESIGN.md 怎么用
Vibe Coding 界最近有一个很重要的创新，叫 DESIGN.md。
出自 Google 之手。准确说是 Google Stitch 团队做的。Stitch 是 Google 最近推出的一个 AI 设计工具，可以用自然语言或截图生成界面设计，非常好用。
玩 Vibe Coding 的同学都知道，AI 写代码已经很厉害了。但在界面层面，审美和一致性还差点意思。
很多 Vibe Coding 出来的产品，功能能跑，逻辑也对，但界面总有一股说不出的廉价感。颜色怪怪的，间距松松垮垮，字体层级乱七八糟。
行业里给这种东西起了个名字，叫 AI slop。
问题出在哪？不是 AI 写代码的能力不行。GPT 也好，Claude 也好，写一个登录页、写一个仪表盘，代码层面完全没问题。
问题在于：它知道怎么写代码，但不知道这个项目应该长什么样。
DESIGN.md 要解决的就是这个问题。
1
先把问题说清楚。
AI 能生成代码，但生成不出品味。让它写一个登录页，它能写出来。但颜色用什么？间距留多少？按钮是圆角还是直角？这些问题，它凭什么做决定？
没有依据，只能猜。
猜的结果就是：每次生成的东西风格都不一样。第一个页面用了蓝色主色调，第二个页面可能就变成紫色了。
按钮这里是 8px 圆角，另一处又变成 4px。整个应用看起来像是五个不同的人做的。
过去的解决方案是组件库。Tailwind、Shadcn、Material UI，这些东西确实有用。
它们提供了一套预制的零件：按钮长这样，卡片长那样，输入框有这几种状态。
但组件库解决不了风格统一的问题。
打个比方。组件库像是宜家的家具目录，里面有沙发、有桌子、有椅子。
但怎么搭配？客厅走北欧风还是工业风？墙面刷什么颜色？这些问题，目录本身回答不了。
AI 拿到组件库，依然在盲猜。它知道有哪些零件可以用，但不知道这个项目想要什么感觉。
真正缺失的，是一份设计系统的共识文档。或者我们的先验经验。
设计系统这个概念存在很久了。大公司都有自己的设计系统：Google 有 Material Design，Apple 有 Human Interface Guidelines，Shopify 有 Polaris。
这些文档定义了一切：颜色怎么用，字体怎么配，组件怎么交互，什么该做什么不该做。
但这些文档本来是给人看的。设计师能读懂，开发者能参考，但 AI 没法直接拿来用。因为格式太复杂，散落在各种地方，没有一个统一的、机器可读的形式。
DESIGN.md 要做的事情就是：把设计系统写成一个 AI 能直接理解的文件。
2
DESIGN.md 很简单，就是一个 Markdown 文件，结构很清晰，分成六个部分：
Overview 描述整体风格。比如：温暖的配色，专业但不冰冷，适合 B2B SaaS 产品。这些模糊但有意义的描述，帮 AI 理解这个项目的调性。
Colors 列出配色方案。不只是罗列色值，还要说明每个颜色的用途。主色调用在哪，强调色用在哪，错误状态用什么红。
Typography 定义字体层级。标题用什么字体，正文用什么字体，大小怎么递进，行高怎么设。
这里有个细节：标题和正文用同一个字体家族会显得统一，混用不同字体会制造对比。AI 会根据这个信息做判断。
Elevation 说明阴影和层次。有些设计走扁平风，完全不用阴影。有些设计用卡片阴影来区分层级。这个板块告诉 AI 该往哪个方向走。
Components 是组件样式规则。按钮有几种变体，圆角多大，内边距多少，悬停状态怎么变。输入框、芯片、列表、弹窗，每个组件都可以在这里定义。
Do's and Don'ts 是设计边界。什么该做，什么不该做。比如：保持 8px 间距倍数，按钮必须用主色调，不要混用超过三种字体。这些规则像护栏一样，防止 AI 跑偏。
大家可以把 DESIGN.md 看成和 AGENTS.md 一样的东西。只不过，AGENTS.md 是帮助 Coding Agent 理解怎么构建项目，而 DESIGN 是帮助 Design Agent 理解产品应该呈现怎么样的外观和感觉。
3
知道它是什么了，怎么用？
第一种方式是在 Stitch 里从零开始。上传截图，或者写一段描述，Stitch 会生成设计稿，同时生成对应的 DESIGN.md。这个文件可以导出，放进代码项目里。
第二种方式更实用：从现有网站反向生成。
Google Stitch 支持输入一个 URL，直接提取那个网站的设计系统。
比如喜欢 Linear 的风格，把 Linear 的网址丢进去，Stitch 会分析它的配色、字体、间距、组件样式，生成一份 DESIGN.md。
这对于想模仿某种风格的人来说太方便了。不用自己从头定义，找一个喜欢的参考，让 AI 帮忙提取就行。
拿到 DESIGN.md 之后怎么办？
放进项目根目录，告诉 AI coding tool：按照这个设计系统来做。Claude Code、Cursor 这些工具都能读取 Markdown 文件。
它们会把 DESIGN.md 当作约束条件，生成代码的时候遵循里面的规则。
Stitch 还提供了 MCP Server，可以让 Claude Code 直接访问 Stitch 里的设计稿。
不只是读取 DESIGN.md，还能看到具体的页面设计，拿到每个元素的 HTML 和 CSS。这样生成的代码会更接近原始设计。
实测下来，也没那么邪乎，AI 不会百分之百还原设计稿。字体可能有偏差，某些细节还需要手动调。
但这不是重点。重点是：有了 DESIGN.md，至少有了一个基准。以前让 AI 做界面，每次都从零开始猜。
现在有了共识文档，AI 知道该往哪个方向走。即使没做到完美，也是在正确的方向上微调，比盲猜强太多。
最后分享一个开源项目，叫 Awesome DESIGN.md。大家可以去 GitHub 搜索。
这个项目收集了几十个知名网站的 DESIGN.md 文件，包括 Claude、Vercel、Stripe、Linear、Notion、Figma、Airbnb 等等。
每一份都是从真实网站提取的，包含完整的设计系统。
用法很简单。找一个喜欢的风格，把对应的 DESIGN.md 复制到项目里，告诉 AI 按这个来。
想要 Linear 那种极简精确的感觉，或者 Stripe 标志性的紫色渐变优雅感，直接拿来用。
从更大的视角看，DESIGN.md 改变的是整个协作方式。
之前做产品，产品经理负责写需求文档，设计师在 Figma 里出设计稿，开发者对着设计稿写代码。三个人，三套工具，两次交接。
每次交接都是一次翻译，翻译就有损耗。开发者问这个间距是 16px 还是 20px，设计师说你看的不是最新版，产品经理说这个交互不是我想要的。来来回回，效率很低。
交接本身就是 Bug。每个团队都在各自的工具里维护各自的版本，没有一个共同的真相来源。
DESIGN.md 直接放在代码仓库里。改了这个文件的配色，AI Coding Tool 立刻能读到。
不需要导出 Figma，不需要写规格文档，不需要开会对齐。它是一个 Living File，跟着代码一起迭代。
Markdown 正在成为人机协作的通用语言。
Vibe Coding 界最近有一个很重要的创新，叫 DESIGN.md。
出自 Google 之手。准确说是 Google Stitch 团队做的。Stitch 是 Google 最近推出的一个 AI 设计工具，可以用自然语言或截图生成界面设计，非常好用。
玩 Vibe Coding 的同学都知道，AI 写代码已经很厉害了。但在界面层面，审美和一致性还差点意思。
很多 Vibe Coding 出来的产品，功能能跑，逻辑也对，但界面总有一股说不出的廉价感。颜色怪怪的，间距松松垮垮，字体层级乱七八糟。
行业里给这种东西起了个名字，叫 AI slop。
问题出在哪？不是 AI 写代码的能力不行。GPT 也好，Claude 也好，写一个登录页、写一个仪表盘，代码层面完全没问题。
问题在于：它知道怎么写代码，但不知道这个项目应该长什么样。
DESIGN.md 要解决的就是这个问题。
1
先把问题说清楚。
AI 能生成代码，但生成不出品味。让它写一个登录页，它能写出来。但颜色用什么？间距留多少？按钮是圆角还是直角？这些问题，它凭什么做决定？
没有依据，只能猜。
猜的结果就是：每次生成的东西风格都不一样。第一个页面用了蓝色主色调，第二个页面可能就变成紫色了。
按钮这里是 8px 圆角，另一处又变成 4px。整个应用看起来像是五个不同的人做的。
过去的解决方案是组件库。Tailwind、Shadcn、Material UI，这些东西确实有用。
它们提供了一套预制的零件：按钮长这样，卡片长那样，输入框有这几种状态。
但组件库解决不了风格统一的问题。
打个比方。组件库像是宜家的家具目录，里面有沙发、有桌子、有椅子。
但怎么搭配？客厅走北欧风还是工业风？墙面刷什么颜色？这些问题，目录本身回答不了。
AI 拿到组件库，依然在盲猜。它知道有哪些零件可以用，但不知道这个项目想要什么感觉。
真正缺失的，是一份设计系统的共识文档。或者我们的先验经验。
设计系统这个概念存在很久了。大公司都有自己的设计系统：Google 有 Material Design，Apple 有 Human Interface Guidelines，Shopify 有 Polaris。
这些文档定义了一切：颜色怎么用，字体怎么配，组件怎么交互，什么该做什么不该做。
但这些文档本来是给人看的。设计师能读懂，开发者能参考，但 AI 没法直接拿来用。因为格式太复杂，散落在各种地方，没有一个统一的、机器可读的形式。
DESIGN.md 要做的事情就是：把设计系统写成一个 AI 能直接理解的文件。
2
DESIGN.md 很简单，就是一个 Markdown 文件，结构很清晰，分成六个部分：
Overview 描述整体风格。比如：温暖的配色，专业但不冰冷，适合 B2B SaaS 产品。这些模糊但有意义的描述，帮 AI 理解这个项目的调性。
Colors 列出配色方案。不只是罗列色值，还要说明每个颜色的用途。主色调用在哪，强调色用在哪，错误状态用什么红。
Typography 定义字体层级。标题用什么字体，正文用什么字体，大小怎么递进，行高怎么设。
这里有个细节：标题和正文用同一个字体家族会显得统一，混用不同字体会制造对比。AI 会根据这个信息做判断。
Elevation 说明阴影和层次。有些设计走扁平风，完全不用阴影。有些设计用卡片阴影来区分层级。这个板块告诉 AI 该往哪个方向走。
Components 是组件样式规则。按钮有几种变体，圆角多大，内边距多少，悬停状态怎么变。输入框、芯片、列表、弹窗，每个组件都可以在这里定义。
Do's and Don'ts 是设计边界。什么该做，什么不该做。比如：保持 8px 间距倍数，按钮必须用主色调，不要混用超过三种字体。这些规则像护栏一样，防止 AI 跑偏。
大家可以把 DESIGN.md 看成和 AGENTS.md 一样的东西。只不过，AGENTS.md 是帮助 Coding Agent 理解怎么构建项目，而 DESIGN 是帮助 Design Agent 理解产品应该呈现怎么样的外观和感觉。
3
知道它是什么了，怎么用？
第一种方式是在 Stitch 里从零开始。上传截图，或者写一段描述，Stitch 会生成设计稿，同时生成对应的 DESIGN.md。这个文件可以导出，放进代码项目里。
第二种方式更实用：从现有网站反向生成。
Google Stitch 支持输入一个 URL，直接提取那个网站的设计系统。
比如喜欢 Linear 的风格，把 Linear 的网址丢进去，Stitch 会分析它的配色、字体、间距、组件样式，生成一份 DESIGN.md。
这对于想模仿某种风格的人来说太方便了。不用自己从头定义，找一个喜欢的参考，让 AI 帮忙提取就行。
拿到 DESIGN.md 之后怎么办？
放进项目根目录，告诉 AI coding tool：按照这个设计系统来做。Claude Code、Cursor 这些工具都能读取 Markdown 文件。
它们会把 DESIGN.md 当作约束条件，生成代码的时候遵循里面的规则。
Stitch 还提供了 MCP Server，可以让 Claude Code 直接访问 Stitch 里的设计稿。
不只是读取 DESIGN.md，还能看到具体的页面设计，拿到每个元素的 HTML 和 CSS。这样生成的代码会更接近原始设计。
实测下来，也没那么邪乎，AI 不会百分之百还原设计稿。字体可能有偏差，某些细节还需要手动调。
但这不是重点。重点是：有了 DESIGN.md，至少有了一个基准。以前让 AI 做界面，每次都从零开始猜。
现在有了共识文档，AI 知道该往哪个方向走。即使没做到完美，也是在正确的方向上微调，比盲猜强太多。
最后分享一个开源项目，叫 Awesome DESIGN.md。大家可以去 GitHub 搜索。
这个项目收集了几十个知名网站的 DESIGN.md 文件，包括 Claude、Vercel、Stripe、Linear、Notion、Figma、Airbnb 等等。
每一份都是从真实网站提取的，包含完整的设计系统。
用法很简单。找一个喜欢的风格，把对应的 DESIGN.md 复制到项目里，告诉 AI 按这个来。
想要 Linear 那种极简精确的感觉，或者 Stripe 标志性的紫色渐变优雅感，直接拿来用。
从更大的视角看，DESIGN.md 改变的是整个协作方式。
之前做产品，产品经理负责写需求文档，设计师在 Figma 里出设计稿，开发者对着设计稿写代码。三个人，三套工具，两次交接。
每次交接都是一次翻译，翻译就有损耗。开发者问这个间距是 16px 还是 20px，设计师说你看的不是最新版，产品经理说这个交互不是我想要的。来来回回，效率很低。
交接本身就是 Bug。每个团队都在各自的工具里维护各自的版本，没有一个共同的真相来源。
DESIGN.md 直接放在代码仓库里。改了这个文件的配色，AI Coding Tool 立刻能读到。
不需要导出 Figma，不需要写规格文档，不需要开会对齐。它是一个 Living File，跟着代码一起迭代。
Markdown 正在成为人机协作的通用语言。
6 03