即刻App年轻人的同好社区
下载
国外一位 25岁的年轻播客主，这两年把 OpenAI、Anthropic、DeepMind 这些顶级 AI 实验室的核心人物挨个访谈过一遍。Karpathy、Hassabis、Dario Amodei、Ilya Sutskever 这些圈内大佬都坐在他对面跟他聊过几个小时。他公开过自己每次访谈前「准备一周」的工作流，全程大量用 AI 辅助。这套工作流泛化出来，是一个普通人能用的东西：怎么用 AI 在一周之内深度搞懂一个完全陌生的主题。
我看了一下，也有很多值得我学习的地方，也想推荐给大家。
他靠这套方法把「准备一周」做到了「跟顶级专家对话不掉档」。这种深度以前只有学界博士生熬几年才能积累。
他叫 Dwarkesh Patel，2000年生在印度，8岁跟家人去了美国。本科在德州大学奥斯汀分校学计算机，2020年读书时开始做播客。这两年他迅速成为英文 AI 圈引用率最高的长访谈节目主持人，国外一家有名的财经周刊形容他「从无名变成了硅谷最爱的播客主」，Time 杂志2024年把他列进了「AI 100 人」。
他自己讲过很多次他的方法逻辑：「我没法问出好问题，除非我对这个领域有完整的心理模型。」每次准备的目标不是「列出能问的问题」，而是「在一周之内把自己变成半个内行」。
他每次准备的第一步是问自己一个问题：「我应该读哪些东西？哪些是绕不开的？谁是这个领域的关键人物？」这一步他交给 AI 做。把嘉宾的领域、核心概念、最新动态丢给 Claude（或者其他大模型），让它列出「该读哪5篇核心论文加哪两本书加哪几个人物的观点必看」。这一步看起来简单，但他强调，「在真正开始读之前先识别该读什么」是最容易省时间的一步。很多人一头扎进资料堆里，三天后才发现读错方向。
读资料的时候，他不是「读完就过」，是边读边在脑子里追踪：「我哪儿没懂？我以为懂了但没懂的是什么？」他举过一个具体例子。访谈强化学习领域的开山祖师 Richard Sutton 之前，他读了好几天才意识到，自己不懂「深度学习和强化学习怎么结合」这件事。他说，这种「以为懂了，结果没懂」的窟窿，越早发现越好。深度调研最怕的就是带着假理解去问问题。
具体到看不懂的地方怎么办，他直接把那段难懂的资料丢给 Claude，问「为什么」「这一段在说什么」「这个概念跟前面那个怎么连」。但他用 AI 不止在「读不懂时问」，更高一层的用法是让 AI 帮你「绘制全景图」。
比如他跟 Karpathy 聊之前，把 Karpathy 过去几年发过的所有公开内容（演讲、博文、长访谈逐字稿）全部丢给 Claude 做了一个项目，再问「Karpathy 在 X 这个观点上前后有没有变化？哪几条是他反复强调的？哪几条他后来明显改了立场？」这种问题靠人自己读完所有材料几乎不可能整理出来，AI 三十秒就能给你一份。这是他每次准备时最重的一招。
最重的另一招是「自己动手实现」。他原话讲：「让我真懂一个东西的最好方式，是把它从零做一遍。」访谈某个 AI 研究者之前，他会自己写代码实现那篇论文里的核心算法。访谈一位航天加电动车圈的国外科技大亨之前，他自己做过散热器和卫星轨道的电子表格模型。
这一步对普通读者门槛最高，但他说背后的逻辑是普世的：能「自己做出一个简化版」的领域，理解就一定是结构化的。如果不是技术领域，可以替换成「自己写一篇综述」「自己画一张全景图」「自己列一份提纲」。要有一个「我自己产出了点什么」的东西。
最后一招是心态。他在准备和访谈时一直在做一件事：「盯紧自己具体哪儿没懂，然后追问。」不下断言、不假装懂、不急着表达自己的看法。他有一句话特别形象——研究的大多数时间是在 confusion 里游泳，偶尔有一刻「哦，原来是这么回事」，那一刻就是上岸。
这套工作流泛化出来，对任何要「一周吃透一个陌生主题」的人都管用。把「访谈嘉宾」换成「调研一个新行业」「准备一次重要会议」「研究一个全新的产品方向」「啃一个完全陌生的学科」，每一步都对得上。
只是大部分人在做这些事的时候，没意识到自己漏了哪一步。要么没在动手前先想清楚「该读什么」，要么读完不追踪自己具体哪儿没懂，要么不去看「目标人物前后说法的矛盾点」，要么从头到尾只是「看过」，没有产出物。
补上这几步，普通人吃一个陌生主题的速度，可以快上一档。
我看了一下，也有很多值得我学习的地方，也想推荐给大家。
他靠这套方法把「准备一周」做到了「跟顶级专家对话不掉档」。这种深度以前只有学界博士生熬几年才能积累。
他叫 Dwarkesh Patel，2000年生在印度，8岁跟家人去了美国。本科在德州大学奥斯汀分校学计算机，2020年读书时开始做播客。这两年他迅速成为英文 AI 圈引用率最高的长访谈节目主持人，国外一家有名的财经周刊形容他「从无名变成了硅谷最爱的播客主」，Time 杂志2024年把他列进了「AI 100 人」。
他自己讲过很多次他的方法逻辑：「我没法问出好问题，除非我对这个领域有完整的心理模型。」每次准备的目标不是「列出能问的问题」，而是「在一周之内把自己变成半个内行」。
他每次准备的第一步是问自己一个问题：「我应该读哪些东西？哪些是绕不开的？谁是这个领域的关键人物？」这一步他交给 AI 做。把嘉宾的领域、核心概念、最新动态丢给 Claude（或者其他大模型），让它列出「该读哪5篇核心论文加哪两本书加哪几个人物的观点必看」。这一步看起来简单，但他强调，「在真正开始读之前先识别该读什么」是最容易省时间的一步。很多人一头扎进资料堆里，三天后才发现读错方向。
读资料的时候，他不是「读完就过」，是边读边在脑子里追踪：「我哪儿没懂？我以为懂了但没懂的是什么？」他举过一个具体例子。访谈强化学习领域的开山祖师 Richard Sutton 之前，他读了好几天才意识到，自己不懂「深度学习和强化学习怎么结合」这件事。他说，这种「以为懂了，结果没懂」的窟窿，越早发现越好。深度调研最怕的就是带着假理解去问问题。
具体到看不懂的地方怎么办，他直接把那段难懂的资料丢给 Claude，问「为什么」「这一段在说什么」「这个概念跟前面那个怎么连」。但他用 AI 不止在「读不懂时问」，更高一层的用法是让 AI 帮你「绘制全景图」。
比如他跟 Karpathy 聊之前，把 Karpathy 过去几年发过的所有公开内容（演讲、博文、长访谈逐字稿）全部丢给 Claude 做了一个项目，再问「Karpathy 在 X 这个观点上前后有没有变化？哪几条是他反复强调的？哪几条他后来明显改了立场？」这种问题靠人自己读完所有材料几乎不可能整理出来，AI 三十秒就能给你一份。这是他每次准备时最重的一招。
最重的另一招是「自己动手实现」。他原话讲：「让我真懂一个东西的最好方式，是把它从零做一遍。」访谈某个 AI 研究者之前，他会自己写代码实现那篇论文里的核心算法。访谈一位航天加电动车圈的国外科技大亨之前，他自己做过散热器和卫星轨道的电子表格模型。
这一步对普通读者门槛最高，但他说背后的逻辑是普世的：能「自己做出一个简化版」的领域，理解就一定是结构化的。如果不是技术领域，可以替换成「自己写一篇综述」「自己画一张全景图」「自己列一份提纲」。要有一个「我自己产出了点什么」的东西。
最后一招是心态。他在准备和访谈时一直在做一件事：「盯紧自己具体哪儿没懂，然后追问。」不下断言、不假装懂、不急着表达自己的看法。他有一句话特别形象——研究的大多数时间是在 confusion 里游泳，偶尔有一刻「哦，原来是这么回事」，那一刻就是上岸。
这套工作流泛化出来，对任何要「一周吃透一个陌生主题」的人都管用。把「访谈嘉宾」换成「调研一个新行业」「准备一次重要会议」「研究一个全新的产品方向」「啃一个完全陌生的学科」，每一步都对得上。
只是大部分人在做这些事的时候，没意识到自己漏了哪一步。要么没在动手前先想清楚「该读什么」，要么读完不追踪自己具体哪儿没懂，要么不去看「目标人物前后说法的矛盾点」，要么从头到尾只是「看过」，没有产出物。
补上这几步，普通人吃一个陌生主题的速度，可以快上一档。
5 14
看到一个不错的ai 深度文章聚合地方www.traeai.com
4 03
自学 Vibe Coding 看这三个开源项目就够，不用买课
很多 AI Coding 课程的素材都从这里来，原始版本反而更系统
1. Easy-Vibe
DataWhale 出品的系统教程，5k stars。分三阶段：从 AI 编程小游戏入门，到产品创意 + Web 原型，再到桌面应用和多 Agent 协作。零基础友好，中文为主
github.com
2. vibe-coding-cn
原 EnzeD/vibe-coding 的中文翻译版，11k stars。三块内容：Prompt 提示词、Skill 技能库、Workflow 工作流。强调规划先行、模块拆分、接口在前，把 vibe coding 从随性即兴变成可重复工程
github.com
3. awesome-vibe-coding
最全的 Vibe Coding 资源 awesome list，4k stars。覆盖浏览器工具、IDE、移动端 App、插件、CLI 工具。所有主流 vibe coding 工具的总目录
github.com
先把这三个读完，你对AI Coding 会有一个全新的认知
很多 AI Coding 课程的素材都从这里来，原始版本反而更系统
1. Easy-Vibe
DataWhale 出品的系统教程，5k stars。分三阶段：从 AI 编程小游戏入门，到产品创意 + Web 原型，再到桌面应用和多 Agent 协作。零基础友好，中文为主
github.com
2. vibe-coding-cn
原 EnzeD/vibe-coding 的中文翻译版，11k stars。三块内容：Prompt 提示词、Skill 技能库、Workflow 工作流。强调规划先行、模块拆分、接口在前，把 vibe coding 从随性即兴变成可重复工程
github.com
3. awesome-vibe-coding
最全的 Vibe Coding 资源 awesome list，4k stars。覆盖浏览器工具、IDE、移动端 App、插件、CLI 工具。所有主流 vibe coding 工具的总目录
github.com
先把这三个读完，你对AI Coding 会有一个全新的认知
403 20385
OpenAI 官方点赞认可的 Codex 学习教程，还是 2026 年全新版本。
一个从入门到进阶的学习指南，内容非常丰富，目录见图 2 和图 3。
传送门：www.youtube.com/watch?v=KXIdYEdOPys
一个从入门到进阶的学习指南，内容非常丰富，目录见图 2 和图 3。
传送门：www.youtube.com/watch?v=KXIdYEdOPys
1 05
微软刚开源了一套完整的 Rust 学习体系：
👉 github.com
↳
不是普通教程，而是工程级训练课程：
从 Python / C++ / C# 迁移路径
async / 并发 / patterns 深度拆解
生产级工程实践（CI/CD、性能、安全）
一共 7 本“系统课程”，直接拉满学习曲线 📈
👉 这可能是目前最体系化的 Rust 学习资源之一
👉 github.com
↳
不是普通教程，而是工程级训练课程：
从 Python / C++ / C# 迁移路径
async / 并发 / patterns 深度拆解
生产级工程实践（CI/CD、性能、安全）
一共 7 本“系统课程”，直接拉满学习曲线 📈
👉 这可能是目前最体系化的 Rust 学习资源之一
0 12
a16z大佬们推荐的非共识书单：人生只需要读25本书。
他们的核心观点：“作为一个门外汉，如果你想在某个领域击败专家，其实只需要读对 25 本书。”
这些书有些在畅销榜，也有些是小众冷门，是a16z的创始人、合伙人和 CEO 们（比如 Databricks、Flock Safety 的创始人）压箱底的“非共识”读物。
他们的核心观点：“作为一个门外汉，如果你想在某个领域击败专家，其实只需要读对 25 本书。”
这些书有些在畅销榜，也有些是小众冷门，是a16z的创始人、合伙人和 CEO 们（比如 Databricks、Flock Safety 的创始人）压箱底的“非共识”读物。
4 13
想象一下，一个软件团队在做一个大项目，但有个奇怪的规定：每个工程师只能工作几十分钟，最多几小时，干完就要换一个新的工程师。所以让这个团队完成简单项目任务还行，复杂一点需要长时间运行的项目，比如你让它克隆一个 claude .ai，它就做不到。
这其实就是 Coding Agent 的现状：没有记忆，上下文窗口长度有限。所以要它执行长时间任务，它还做不好。
Anthropic 的这篇博客：《Effective harnesses for long-running agents》，专门讨论了如何让 Agent 在跨越多个上下文窗口时依然能持续推进任务。
先看 Agent 在长任务中遇到的主要问题是什么？
主要三种：
第一种叫一口气干太多。比如你让 Agent 克隆一个 claude .ai 这样的网站，它会试图一次性搞定整个应用。结果上下文还没用完，功能写了一半，代码乱成一锅粥。下一个会话进来，面对半成品只能干瞪眼，花很多时间猜测前面到底做了什么。
第二种叫过早宣布胜利。项目做了一部分，后来的 Agent 看看环境，觉得好像差不多了，就直接收工。功能缺一大堆也不管。
第三种叫测试敷衍。Agent 改完代码，跑几个单元测试或者 curl 一下接口就觉得万事大吉，根本没有像真实用户那样端到端走一遍流程。
这三种失败模式的共同点是 Agent 不知道全局目标，也不知道该在哪里停下来、该留下什么给下一位。
那么 Anthropic 的解决方案是什么呢？
其实就是软件工程的一些现成的解决方案：引入类似人类团队的分工协作机制，将复杂任务拆解成小的可跟踪验证的任务，清晰的交接机制，并严格验证任务结果
一个初始化 Agent，它只在项目启动时出场一次，任务是搭好项目运行环境：有点像架构师的角色，写一个 init .sh 脚本方便后续启动开发服务器，建一个 claude-progress.txt 记录进度，做第一次 git 提交，最关键的是生成一份功能清单。
这份功能清单有多细？在克隆 claude .ai 的案例中，列了超过 200 条具体功能，比如用户能打开新对话、输入问题、按回车、看到 AI 回复。每一条初始状态都标记为失败，后续 Agent 必须逐条验证通过才能改成成功。
而且这里有个细节，这个清单不是用 Markdown 来写的，是一个 JSON 数组，因为 Anthropic 实验发现，相比 Markdown，模型在处理 JSON 时更不容易随意篡改或覆盖文件。
另一个是编码 Agent。在初始化项目后，后续就是它干活了，核心行为准则只有两条：一次只做一个功能，做完要留下干净的环境。
什么叫干净的环境？想象你往主分支提交代码的标准：没有严重 bug，代码整齐有文档，下一个人接手能直接开始新功能，不用先替你收拾烂摊子。
每次开工前，它先做几件事：
– 运行 pwd 看看自己在哪个目录
– 读 Git 日志和进度文件，搞清楚上一轮干了啥
– 看功能清单，挑一个最高优先级的未完成功能
– 跑一遍基础测试，确保 App 还能用
然后专心做一个功能，做完后：
– 写清楚的 Git commit message
– 更新 claude-progress.txt
– 只改功能清单里的状态字段，绝不删改需求本身
这个设计的巧妙之处在于，它把“记忆”外化成了文件和 Git 历史。每一轮的 Agent 不需要依赖上下文窗口里的碎片信息，而是模仿靠谱的人类工程师每天上班会做的事。先同步进度，确认环境正常，再动手干活。
测试环节的改进值得单独说。
原来 Agent 只会用代码层面的方式验证，比如跑单元测试或者调接口。问题是很多 bug 只有用户真正操作页面时才会暴露。
解决方案是给 Agent 配上浏览器自动化工具，比如 Puppeteer MCP。Agent 现在能像真人一样打开浏览器、点按钮、填表单、看页面渲染结果。Anthropic 放了一张动图，展示 Agent 测试克隆版 claude .ai 时自己截的图，确实是在像用户那样操作。
这招大幅提升了功能验证的准确率。当然也有边界，比如浏览器原生的 alert 弹窗，Puppeteer 捕捉不到，依赖弹窗的功能就容易出 bug。
这套方案还留了一些开放问题。
比如，到底是一个通用 Agent 全包好，还是搞专业分工？让测试 Agent 专门测，代码清理 Agent 专门收拾，也许效果更好。
再比如，这套经验是针对全栈 Web 开发优化的，能不能迁移到科研或金融建模这类长周期任务？应该可以，但需要实验验证。
响马
@xicilion
说：
> ai 的尽头依旧是软件工程。
AI Agent 也不是魔法，它一样需要从人类软件工程中汲取经验，它也需要将复杂的任务进行分解成简单的任务，要有一个结构化的工作环境和清晰的交接机制。
人类工程师为什么能跨团队、跨时区协作？因为有 Git、有文档、有 Code Review、有测试。AI Agent 要想长时间自主工作，也得把这些东西搬过来。
Anthropic 的方案，不过是把软件工程的最佳实践变成了 Agent 能理解的提示词和工具链。不是让模型变得更聪明，而是给它提供更好的脚手架。
Anthropic 的思路值得借鉴。无论你用的是 Claude、GPT 还是别的模型，在设计多轮长任务时，都要想清楚，怎么让下一轮的 Agent 快速进入状态，怎么避免它重复造轮子或者把代码搞成一团乱麻。即使是单轮任务，也要清楚它是没有记忆的，你需要通过外部文件来帮助它“想起来”之前做过的事。
以现在模型的能力，Coding Agent 已经能做很多事情了，核心还是在于你是不是能像软件工程中那样，去分解好任务，设计好工作的流程。
原文：Effective harnesses for long-running agents anthropic.com
这其实就是 Coding Agent 的现状：没有记忆，上下文窗口长度有限。所以要它执行长时间任务，它还做不好。
Anthropic 的这篇博客：《Effective harnesses for long-running agents》，专门讨论了如何让 Agent 在跨越多个上下文窗口时依然能持续推进任务。
先看 Agent 在长任务中遇到的主要问题是什么？
主要三种：
第一种叫一口气干太多。比如你让 Agent 克隆一个 claude .ai 这样的网站，它会试图一次性搞定整个应用。结果上下文还没用完，功能写了一半，代码乱成一锅粥。下一个会话进来，面对半成品只能干瞪眼，花很多时间猜测前面到底做了什么。
第二种叫过早宣布胜利。项目做了一部分，后来的 Agent 看看环境，觉得好像差不多了，就直接收工。功能缺一大堆也不管。
第三种叫测试敷衍。Agent 改完代码，跑几个单元测试或者 curl 一下接口就觉得万事大吉，根本没有像真实用户那样端到端走一遍流程。
这三种失败模式的共同点是 Agent 不知道全局目标，也不知道该在哪里停下来、该留下什么给下一位。
那么 Anthropic 的解决方案是什么呢？
其实就是软件工程的一些现成的解决方案：引入类似人类团队的分工协作机制，将复杂任务拆解成小的可跟踪验证的任务，清晰的交接机制，并严格验证任务结果
一个初始化 Agent，它只在项目启动时出场一次，任务是搭好项目运行环境：有点像架构师的角色，写一个 init .sh 脚本方便后续启动开发服务器，建一个 claude-progress.txt 记录进度，做第一次 git 提交，最关键的是生成一份功能清单。
这份功能清单有多细？在克隆 claude .ai 的案例中，列了超过 200 条具体功能，比如用户能打开新对话、输入问题、按回车、看到 AI 回复。每一条初始状态都标记为失败，后续 Agent 必须逐条验证通过才能改成成功。
而且这里有个细节，这个清单不是用 Markdown 来写的，是一个 JSON 数组，因为 Anthropic 实验发现，相比 Markdown，模型在处理 JSON 时更不容易随意篡改或覆盖文件。
另一个是编码 Agent。在初始化项目后，后续就是它干活了，核心行为准则只有两条：一次只做一个功能，做完要留下干净的环境。
什么叫干净的环境？想象你往主分支提交代码的标准：没有严重 bug，代码整齐有文档，下一个人接手能直接开始新功能，不用先替你收拾烂摊子。
每次开工前，它先做几件事：
– 运行 pwd 看看自己在哪个目录
– 读 Git 日志和进度文件，搞清楚上一轮干了啥
– 看功能清单，挑一个最高优先级的未完成功能
– 跑一遍基础测试，确保 App 还能用
然后专心做一个功能，做完后：
– 写清楚的 Git commit message
– 更新 claude-progress.txt
– 只改功能清单里的状态字段，绝不删改需求本身
这个设计的巧妙之处在于，它把“记忆”外化成了文件和 Git 历史。每一轮的 Agent 不需要依赖上下文窗口里的碎片信息，而是模仿靠谱的人类工程师每天上班会做的事。先同步进度，确认环境正常，再动手干活。
测试环节的改进值得单独说。
原来 Agent 只会用代码层面的方式验证，比如跑单元测试或者调接口。问题是很多 bug 只有用户真正操作页面时才会暴露。
解决方案是给 Agent 配上浏览器自动化工具，比如 Puppeteer MCP。Agent 现在能像真人一样打开浏览器、点按钮、填表单、看页面渲染结果。Anthropic 放了一张动图，展示 Agent 测试克隆版 claude .ai 时自己截的图，确实是在像用户那样操作。
这招大幅提升了功能验证的准确率。当然也有边界，比如浏览器原生的 alert 弹窗，Puppeteer 捕捉不到，依赖弹窗的功能就容易出 bug。
这套方案还留了一些开放问题。
比如，到底是一个通用 Agent 全包好，还是搞专业分工？让测试 Agent 专门测，代码清理 Agent 专门收拾，也许效果更好。
再比如，这套经验是针对全栈 Web 开发优化的，能不能迁移到科研或金融建模这类长周期任务？应该可以，但需要实验验证。
响马
@xicilion
说：
> ai 的尽头依旧是软件工程。
AI Agent 也不是魔法，它一样需要从人类软件工程中汲取经验，它也需要将复杂的任务进行分解成简单的任务，要有一个结构化的工作环境和清晰的交接机制。
人类工程师为什么能跨团队、跨时区协作？因为有 Git、有文档、有 Code Review、有测试。AI Agent 要想长时间自主工作，也得把这些东西搬过来。
Anthropic 的方案，不过是把软件工程的最佳实践变成了 Agent 能理解的提示词和工具链。不是让模型变得更聪明，而是给它提供更好的脚手架。
Anthropic 的思路值得借鉴。无论你用的是 Claude、GPT 还是别的模型，在设计多轮长任务时，都要想清楚，怎么让下一轮的 Agent 快速进入状态，怎么避免它重复造轮子或者把代码搞成一团乱麻。即使是单轮任务，也要清楚它是没有记忆的，你需要通过外部文件来帮助它“想起来”之前做过的事。
以现在模型的能力，Coding Agent 已经能做很多事情了，核心还是在于你是不是能像软件工程中那样，去分解好任务，设计好工作的流程。
原文：Effective harnesses for long-running agents anthropic.com
35 417
初学者上手了解AI Agent，推荐看这个微软的Github：
github.com
github.com
4 00