Anthropic 研究员 Jascha Sohl-Dickstein 最近分享了一个关于 AGI 来临的演讲。

他说，我们可能正处于人类作为地球主要智慧生物的最后几年。

演讲标题致敬了诺贝尔奖得主 Ramón y Cajal 的经典著作。

但 Sohl-Dickstein 讨论的不是传统的学术建议，而是在 AGI 即将到来的背景下，年轻研究者该如何规划自己的未来。

人类纪元的终点？

地质纪元以生命形式、气候和地质过程的显著变化为标志。

人类正在产生地质级别的影响：我们正在引发地球历史上的第六次大规模灭绝，核武器试验的放射性同位素正被记录在岩层中。

有人提议将当前这个人类驱动全球变化的时期命名为「人类世」（Anthropocene）。

但 Sohl-Dickstein 指出，这可能是一个极其短暂的地质纪元，因为人类作为地球主要智慧驱动力的时期可能即将结束。

AI 的指数级增长

从计算量来看，AI 模型训练所使用的计算资源正在爆炸性增长。图表的 Y 轴每个刻度都是前一个的 100 倍。

右上角圈出的是人脑一生中执行的计算量估算范围。

按照每个突触每毫秒执行一次浮点运算计算，人脑一生约执行 1 万亿 petaflops 的计算，这只比当前最大的模型多一点点。

我们正在接近人类大脑一生的计算规模。

AI 能力的快速突破

METR 的研究显示，AI 模型能够独立完成的软件任务时长正在指数级增长。如果趋势继续，模型将在 2027 年能够以 50% 的成功率独立完成一整天的工作。

超人类表现的达成速度越来越快。

1998 年发布的基准测试直到 2015 年才被 AI 超越，而 2019 年发布的推理基准在 2023 年就被突破了。

GPQA Diamond 是由 STEM 领域博士们精心设计的测试，经过五轮创建、审查和筛选。AI 仅用一年半就从接近随机猜测水平提升到了超人类表现。

关于「模型是否在训练集中见过测试题」的质疑，Scale 的研究人员创建了全新的数学问题进行测试。结果显示，Anthropic 和 OpenAI 等前沿实验室的模型在新问题上表现与原始基准相当，Claude 甚至在新问题上表现更好。

今年，Google 和 OpenAI 的模型都在国际数学奥林匹克竞赛（IMO）上取得了金牌水平的成绩。

全世界只有 72 名学生获得金牌，而两个 LLM 也做到了。

竞赛组织者评价：

AI 的解答在很多方面都令人惊叹。IMO 评分者发现它们清晰、精确，而且大多数都很容易理解。

AGI 已经进入主流视野

Sohl-Dickstein 在哈佛演讲后收到一封邮件：「多么疯狂的摘要……」

他认为这反映了一个重要问题：AGI 是否已经进入了「奥弗顿窗口」，即社会可接受讨论的观点范围。

现在，许多知名人士和机构都在严肃讨论 AGI。主流媒体也开始认真对待这个话题。

如果这些人都认真对待 AGI，你也有理由认真对待它。

专家们的时间预测

对主要 AI 会议贡献者的调查显示：

• 2022 年，中位数预测 AGI 将在 2060 年左右实现

• 2023 年，中位数提前到 2045 年

• 如果今天再做调查，Sohl-Dickstein 预计中位数会在 2030 年代

在旧金山的 AI 圈子里，认为 AGI 需要十年才能实现的人已经被认为是「长时间线」派了。

Sohl-Dickstein 分享了个人体验：现在的 Claude 感觉像是一个有时会犯愚蠢错误的研究生，但拥有百科全书般的知识，而且极其热情和快速。

这个描述一年前还不成立，一年后也不会再成立——模型会变得更好。

给年轻研究者的具体建议

确保你的项目在完成时仍然相关。

避免这种情况：你努力工作两年取得重大进展，但完成时别人只需要提示一下基础模型就能做得更好。

这意味着要与他人合作，快速推进目标明确的项目，保持在指数增长曲线之前。

不鼓励缓慢的开放式探索。

Richard Sutton 的「苦涩的教训」告诉我们：

利用计算的通用方法最终是最有效的。你要做那些随着计算和智能规模扩大而变得更有效的项目，而不是那些会被规模自动解决的项目。

强迫自己使用 AI 工具。

它们提供了全新的能力，虽然可能笨拙且不符合人体工程学，学习曲线陡峭，但你应该使用它们，既因为它们已经有用，也为下一代工具做准备。

使用 LLM 就像做 PI（首席研究员），两种活动都是很好的相互练习，需要明确定义的问题和适当范围的任务。

在大脑的所有部分都认真对待 AGI。

Sohl-Dickstein 遇到一个研究生，他说 AGI 会在 3 年内到来，几分钟后又在讨论传统的职业规划……

如果 AI 将造成大规模颠覆并能够做你的工作，那么存在一个高基准的不可避免风险。

这意味着在更安全的研究或职业选择与更高潜在回报的选择之间，更安全的选择实际上并不安全，你只是在牺牲上升空间。

选择有意义的工作

做一些让你自豪的事情！

当你退休在戴森球的别墅里时，你会希望感到自己帮助实现了积极的结果。

选择那些回顾时会产生影响的项目。这意味着你应该优先选择那些改变 AGI 后轨迹的项目，而不是在近期产生短暂变化的项目。

你拥有巨大的影响力。

尽管 AI 能力惊人，我们仍处于指数增长的早期。Epoch AI 预测到 2030 年，计算资源可能是现在的 10,000 倍。

因为我们处于指数增长的早期，而且你几乎肯定拥有高度相关的技能，你对 AI 的未来拥有巨大的权力和影响力。

这既是权力也是责任。你现在做出的决定可能会对你关心的大量人群产生巨大的间接后果。对你选择的项目和工作要有意识和深思熟虑。

值得关注的研究方向

Sohl-Dickstein 列出了一些特别有前景的研究领域：

• AI for Science：材料发现、蛋白质折叠、天气建模、聚变反应堆等离子体监测等

• 对 AI 模型的科学研究：把 AI 模型本身作为研究对象，使用其他领域的技术

• AI 安全研究：这是你可以从头开始参与的极其重要的领域

• AI 能力的预测和推断：我们越了解未来可能的样子，结果可能越好

• 访问、公平、公正：如果我们希望这项技术造福所有人，这是极其有用的

• 政策和治理：政府迫切需要有能力的技术人员提供建议。这是极高杠杆的工作

认真对待未来！

你的工作内容、工作地点、职业转换时机、如何思考重要和有趣的问题、如何思考工作的潜在后果和影响力——所有这些都极其重要。

未来几年也是全力以赴的好时机，可能是最后的时机。

你的工作的潜在影响不太可能再比现在更大了。

项目评估标准

演讲还包含了额外的幻灯片，提供了评估研究项目的具体标准：

影响力：如果项目完美运行，潜在效益有多大？评估时要投射到你的价值轴上，而不是仅仅测量其范数。

苦涩的教训：你的研究是否对计算和智能规模的增长具有鲁棒性？

机会成本：这个项目需要多少时间和精力？如果项目失败，这些努力是否会浪费？

比较优势：为什么你特别适合这个项目？

冗余性：有多少人正在以大致相同的方式解决同一问题？如果每个人都同意你在研究一个非常重要的问题，那么你不应该研究它——别人会做的。

选择更奇怪的项目！

无论你在做什么项目，都应该选择一个更奇怪的。你将根据你完成的最好的事情被评判，而不是典型的事情。

理想的项目是你能清楚地解释为什么它是个好主意，但当你向别人解释时，他们会用奇怪的眼光看着你，难以理解。这是未来项目成功的最强信号！

关于是否应该做学术研究，Sohl-Dickstein 分享了自己的选择：

他基本上停止了学术研究。虽然怀念能够公开讨论工作的日子，但在工业界有更多的计算资源、资金和接触前沿问题的机会，可以说对未来有更大的影响力。

在平行宇宙中，我正在经营一个小型学术实验室，并且热爱它。在许多方面，那对我来说是更有吸引力的人生道路。但我相信我们正在构建一项将彻底改变世界的技术，我不能袖手旁观。

这张图来自同事的另一个演讲，展示了汽车出现后马匹数量的变化。

最后，Sohl-Dickstein 给出了一个积极的结尾，癌症死亡率正在指数级下降！

虽然需要按富裕国家筛选有些遗憾，但如果我们继续让癌症治疗变得更容易，世界其他地区也会赶上来。

再次理解指数增长

与 Sohl-Dickstein 的演讲相呼应，Anthropic 的另一位研究员 Julian Schrittwieser 最近也发表了一篇题为《再次未能理解指数增长》的文章。

他将当前关于 AI 进展和所谓「泡沫」的讨论比作 YI 情初期的情况。

当时尽管从指数趋势来看全球 YI 情的时间和规模已经很明显，但政 ZHI 家、记者和大多数公众评论员仍然把它当作遥远的可能性或局部现象。

AI 能力的进展也在发生类似的事情。

人们注意到虽然 AI 现在能编写程序、设计网站等，但仍经常出错或走错方向，然后他们就跳到结论说 AI 永远无法达到人类水平，或只会产生微小影响。

而就在几年前，让 AI 做这些事还是完全的科幻！

OpenAI 的 GDPval 研究测量了模型在 9 个行业 44 个职业中的表现，见：OpenAI 发布GDPval，可真实评估现实世界经济价值。Claude Opus 4.1 拿下第一

评估任务来自经验丰富的行业专业人士（平均 14 年经验），每个职业 30 个任务，共 1320 个任务。

最新的 GPT-5 已经惊人地接近人类表现。

Claude Opus 4.1（比 GPT-5 更早发布）表现明显更好：超过了之前图表的趋势，几乎已经匹配了行业专家的表现!

基于多年来跨多个行业的指数级性能改进的一致趋势，Schrittwieser 预测：

• 到 2026 年中期，模型将能够自主工作整个工作日（8 小时）

• 在 2026 年底之前，至少有一个模型将在许多行业中匹配人类专家的表现

• 到 2027 年底，模型将经常在许多任务上超越专家

质疑

当然，并非所有人都认同这种乐观预测。

Georgist(@Georgist) 表示：

老子作为程序员在这里。来拿走我的工作吧。在那之前，请闭嘴。谢谢。PS：享受你的骗局。

Robert Piosik(@robertpiosik) 则指出：

LLM 不能推理，因此无法可靠地做出明智的决定（特别是那些在训练数据集中较少强调的）。人类活动的环境是嘈杂的，但你从噪音训练中得到的只是幻觉。

makevoid(@makevoid) 认为编码领域的进展正在减速：

这是一个很好的视角，但我不同意编码方面的观点，我们在 Sonnet 3.5 时通过了最大的进步点，现在正在减速。GPT-3、3.5 和 Sonnet 3.5 都是编码的革命点，但在 Sonnet 3.5 之后，我们在模型方面没有得到任何重大突破。

rdzeń(@rdzen) 分析了投资回报率：

这种「进展」是建立在花费数千亿美元而没有合理投资回报率的基础上的。指数级支出换来线性进展。这不是泡沫吗？

Claudiu(@Claudiu) 对 50% 的成功率表示担忧：

那个 50% 正是问题的一部分。当成功率和抛硬币一样时，很难看到进展。

Travers(@Travers) 区分了技术能力泡沫和金融泡沫：

这是一篇写得很好的文章，我认为它基于 AI 当前的能力指数。然而，「我们不在泡沫中」的核心主张似乎混淆了技术能力泡沫和金融泡沫。即使有指数级的模型进展，经济现实可能会背离。

最后，Meta 研究员 Lucas Beyer 则用一张梗图幽默地总结了当前的处境：

看来随着年龄增长，我慢慢必须在这些预定义的路径中选择一个：

• 成为 Gary（Gary Marcus，AI 怀疑派）

• 成为 Jürgen（Jürgen Schmidhuber，AI 乐观派）

• 成为 Eliezer（Eliezer Yudkowsky，AI 末日论者）

那么，你选择哪一个呢？

参考资料：

作者：John
排版：Claude Code

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

编程智能体迎来质变时刻！

Anthropic 刚刚发布的 Claude Sonnet 4.5，不仅宣称是世界上最强的编程模型，更是将自主编码时间从 GPT-5-Codex 的 7 小时推进到了 30 小时。

这成为智能体能力的一次根本性飞跃。

性能数据全面碾压

在 SWE-bench Verified 测试中，Claude Sonnet 4.5 解决了 82% 的 500 个经人工验证的 GitHub 问题，超过了 GPT-5（74.9%）和 GPT-5 Codex（74.5%）。

这个基准基于实际 GitHub 问题与经过测试和人工确认的解决方案，能够有效衡量模型的实际 bug 修复能力。

更令人震撼的是它的持久力——

在测试中成功构建了约 11,000 行代码的 Slack 风格聊天应用，连续运行超过 30 小时没有中断。这意味着模型在保持计划、状态和高效输出方面实现了质的突破。

根据 Kilian Lieret 的最新评测，Sonnet 4.5 在 SWE-bench 上还创下了 70.6% 的新纪录。虽然每个 token 的价格与 Sonnet 4 相同，但解决问题时需要更多计算步骤，导致整体运行成本有所提高。

Replit CEO Amjad Masad（@amasad）指出：

智能体自主工作的时间从最初的 2 分钟提升到了 6 小时，现在更是达到 30 小时，这标志着从传统软件向数字员工的转变。

在 OSWorld 评测中，Sonnet 4.5 以 61.4% 的得分刷新了计算机使用和智能体领域的最高记录，比前代模型提升了 19.2 个百分点。

Claude Code 全面升级

新版本引入了 Claude Code 的全面升级：终端界面焕然一新，新增 VS Code 插件让 Claude 直接融入你的 IDE。

更重要的是新增的「检查点」功能，支持通过 /rewind 命令撤销不满意的输出，还可以通过 Ctrl+R 快速搜索并编辑提示词。

新增的 /usage 命令方便用户实时查询会话及周度使用额度，提升使用透明度与管理效率。引入的「tab」键设置可以切换默认自动思考模式，确保 Claude Code 在每一步交互中主动进行思考。

值得注意的是，原来的 Claude Code SDK 现已更名为 Claude Agent SDK，也展示出 A 厂从专注编码智能体拓展到支持构建任何通用智能体的野心转变。

文件处理能力

Claude 现在能用代码分析数据、创建文件并实现可视化，支持从电子表格、文档到 PDF 及幻灯片的多种文件格式的创建与编辑。这些功能已向所有付费用户开放预览。

Chrome 扩展也已经向上月加入等待名单的用户全面开放，我也提前使用了，见前文：Claude Chrome 插件使用体验：强大，但有点慢

根据 Dan Shipper（@danshipper）的测试体验，Sonnet 4.5 比 Opus 更智能、更快速，执行速度提升约 2 倍，运行成本降低约 5 倍。

他的详细评测可见：https://every.to/vibe-check/vibe-check-claude-sonnet-4-5

API 长时任务革命

为了应对长时间运行的任务，Claude API 新增了两项关键能力：

上下文编辑功能能自动清理陈旧的上下文信息，就像垃圾回收机制一样高效。当会话接近 token 限制时自动清理无用数据。

记忆工具（测试版）则允许在上下文窗口之外存储和调用信息，实现跨模块和跨会话数据持续性，支持复杂大型代码库的重构工作。

这些功能让智能体能够处理之前无法完成的长期任务，比如长时间数据拉取、多服务配置以及代码生成与验证的连续执行。

实际应用表现出色

Factory AI 的测试显示，Sonnet 4.5 在文件编辑准确性、环境感知能力和响应速度上都有显著提升。在处理简单快速查询时响应更灵敏，不会过度推理复杂化问题。CEO Matan Grinberg（@matanSF）称这是「编码领域的重要变革」。

Cognition 团队基于 Sonnet 4.5 重构了智能软件工程师 Devin，预览版速度提升超过 2 倍，在内部 Junior Developer 评测中性能提升了 12%。

详细分享见：

https://cognition.ai/blog/devin-sonnet-4-5-lessons-and-challenges

价格保持不变

让人意外的是，即便性能大幅提升，Claude Sonnet 4.5 的定价依然与 Sonnet 4 保持一致——输入每百万 token 3 美元，输出 15 美元。

对于超过约 20 万 token 的更大上下文，价格分级至输入 6 美元/百万 token，输出 22.5 美元/百万 token。

通过提示缓存最高可节省 90%，批处理可节省 50%。相比 Opus 系列（输入 15 美元/百万 token，输出 75 美元/百万 token），Sonnet 系列具有显著成本优势。

定价详情：https://www.anthropic.com/pricing

Claude Sonnet 4.5 现已在 Claude 开发者平台、Amazon Bedrock 和 Google Cloud Vertex AI 全面上线。

五天限时实验：Imagine with Claude

Anthropic 还推出了一个名为「Imagine with Claude」的研究预览——

Claude 能实时生成软件，没有预设功能，没有预写代码，一切都是动态创建的。

这个实验仅向 Max 用户开放 5 天，我也第一时间用它制作了一个 news feed：

体验地址：https://claude.ai/imagine

集成不只是「一行代码」的事

Cognition 团队的 Andrew Gao（@itsandrewgao）分享了将 Sonnet 4.5 集成到实际应用中的经验。

他强调，这绝不是简单的模型字符串替换。

模型展现出了有趣的「元行为」：当它认为自己拥有大量上下文时会更「健谈」，随着上下文消耗会变得更简洁。

它甚至会根据剩余的上下文长度调整并行调用的数量，尽管对上下文容量的估计并不总是准确，这类似于早期大规模语言模型（如 GPT-3）对单词字母识别的不完善表现。

安全性的白盒审计

这次 Anthropic 还首次对前沿大模型进行了白盒审计，运用可解释性技术来「读取模型的思维」。

研究团队包括 Jack Lindsey（@Jack_W_Lindsey）、Sam Bowman（@sleepinyourhat）等人。

研究发现，Sonnet 4.5 在「评估意识」方面达到了 58%，远高于 Opus 4.1 的 22%。

模型在知道自己被测试时会表现得更谨慎，有害行为率降至约 13%，显著优于 Opus 4.1（29%）、Sonnet 4（24%），以及其他领先模型如 Gemini 2.5 和 GPT-4o（约 42-43%）和 GPT-5（16%）。

完整的审计结果详见 Claude Sonnet 4.5 系统卡：https://assets.anthropic.com/m/12f214efcc2f457a/original/Claude-Sonnet-4-5-System-Card.pdf

各平台迅速跟进

Cursor、Perplexity、LlamaIndex 等平台已经第一时间集成了 Claude Sonnet 4.5。

Perplexity 为 Pro 和 Max 订阅用户推出了 Claude Sonnet 4.5 及 4.5 Thinking 两款版本。

Figma 也开始分阶段推出集成了 Sonnet 4.5 的设计工具，Dylan Field（@zoink）分享的演示视频展示了其在设计工具中的交互流程：

LlamaIndex 团队宣布即刻支持 Claude Sonnet 4.5，实现 Day 0 兼容。

演示代码及运行笔记本：https://colab.research.google.com/drive/1TeO9O49am3F-2wyLKzqlc0adM124BJZk

真实世界的应用案例

沃顿商学院的 Ethan Mollick 教授（@emollick）分享了一个惊人的案例：Claude Sonnet 4.5 成功基于原始数据和论文内容，完整复现了一篇已发表的经济学研究。

这是要开始上手真正的研究工作了。

详细分析见：https://www.oneusefulthing.org/p/real-ai-agents-and-real-work

他还指出，Sonnet 4.5 在金融和统计领域的任务能力上实现了显著跃升，这一提升区别于主流关注编码任务的趋势。

多个版本的演进对比

Anthropic 首席产品官 Mike Krieger（@mikeyk）分享了一段视频，展示了多个版本的 Claude 智能体尝试克隆 Claude.ai 的过程，直观展现了从两年前到现在的能力飞跃。

Emmanuel Ameisen（@mlpowered）评价：两年前 Claude 的代码生成能力尚处于初级阶段，去年有了较大进步，而今年的 Claude 4.5 已能够自动生成并搭建完整产品。

技术细节与开发者资源

新的 Claude Agent SDK 官方文档默认采用 TypeScript 语言编写，增强了类型安全与代码可维护性。文档地址：https://docs.claude.com/en/api/agent-sdk/overview

更多技术细节和官方公告：https://www.anthropic.com/news/claude-sonnet-4-5

当智能体能够连续 30 小时自主编程，当 AI 能够复现学术研究，当模型开始理解自己「被测试」的状态——

我想，我们此时正在见证的，是人类工作本身的定义，正在被改变。见昨天的文章（点击图片可前往阅读）：

作者：John
排版：Claude Code

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

今年 6 月，Andrej Karpathy 就提出：提示词工程该改名了。

他建议用「上下文工程」（context engineering）取代「提示词工程」（prompt engineering）。Karpathy 指出，人们一听到「提示词」，就会联想到日常使用 LLM 时输入的简短任务描述。

但在真正的工业级 LLM 应用中，填充上下文窗口才是一门精妙的艺术与科学。

而刚刚，在 Claude Sonnet 4.5 和 Claude Code 2.0 推出后的第二天，Anthropic 发布的这一篇的工程博客，也呼应了 Karpathy 的观点：真正的挑战不是编写完美的提示词，而是如何精心策划整个上下文。

Anthropic 明确指出：

构建 AI 应用的重心正在从寻找「正确的词句」转向回答更广泛的问题——「什么样的上下文配置最有可能产生我们期望的模型行为？」

为什么上下文工程如此重要

上下文指的是从大语言模型采样时包含的所有 token。

而工程问题在于如何在 LLM 固有的约束条件下优化这些 token 的效用，以持续实现期望的结果。有效驾驭 LLM 通常需要「在上下文中思考」。

换句话说：考虑 LLM 在任何给定时刻可用的整体状态，以及该状态可能产生的潜在行为。

Anthropic 认为，上下文工程是提示词工程的自然演进。

提示词工程专注于为获得最佳结果而编写和组织 LLM 指令的方法。而上下文工程指的是在 LLM 推理过程中策划和维护最优 token 集（信息）的一系列策略，包括提示之外可能出现的所有其他信息。

在 AI 工程的早期，提示词是主要工作，因为除了日常聊天交互之外，大多数用例都需要为一次性分类或文本生成任务优化提示。

如其名称所暗示的，提示词工程的主要重点是如何编写有效的提示，特别是系统提示。

然而，随着我们转向工程化能够在多轮推理和更长时间跨度上运行的更强大智能体，我们需要管理整个上下文状态（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）的策略。

在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据，这些信息必须循环精炼。上下文工程是从不断演变的可能信息宇宙中策划将进入有限上下文窗口内容的艺术与科学。

对构建强大智能体至关重要

尽管速度快且能够管理越来越大的数据量，但研究发现 LLM 像人类一样，在某个点会失去焦点或感到困惑。

针对「大海捞针」式基准测试的研究揭示了「上下文腐烂」的概念：

随着上下文窗口中 token 数量的增加，模型从该上下文准确回忆信息的能力会下降。

虽然有些模型表现出更温和的退化，但这一特性在所有模型中都会出现。因此，上下文必须被视为具有边际收益递减的有限资源。就像人类的工作记忆容量有限一样，LLM 在解析大量上下文时也有一个「注意力预算」。引入的每个新 token 都会在一定程度上消耗这个预算，增加了仔细策划 LLM 可用 token 的需求。

这种注意力稀缺性源于 LLM 的架构约束。LLM 基于 Transformer 架构，它使每个 token 能够关注整个上下文中的每个其他 token。这导致 n 个 token 产生 n² 个成对关系。

随着上下文长度的增加，模型捕获这些成对关系的能力变得紧张，在上下文大小和注意力焦点之间产生了自然的张力。此外，模型从训练数据分布中发展其注意力模式，其中较短的序列通常比较长的序列更常见。这意味着模型对上下文范围依赖性的经验较少，专门参数也较少。

像位置编码插值这样的技术允许模型通过将其适应到最初训练的较小上下文来处理更长的序列，尽管在 token 位置理解方面会有一些退化。

这些因素创造了性能梯度而不是硬性界限：模型在更长的上下文中仍然保持高能力，但与在较短上下文上的表现相比，在信息检索和长程推理方面可能表现出较低的精度。

这些现实意味着，深思熟虑的上下文工程对于构建强大的智能体至关重要。

有效上下文的剖析

鉴于 LLM 受到有限注意力预算的约束，良好的上下文工程意味着找到最小可能的高信号 token 集，以最大化某些期望结果的可能性。说起来容易做起来难，但在下面的部分中，我们概述了这一指导原则在上下文不同组成部分中的实际意义。

系统提示应该极其清晰，使用简单、直接的语言，以适当的高度呈现想法。适当的高度是两个常见失败模式之间的最佳点。

在一个极端，我们看到工程师在提示中硬编码复杂、脆弱的逻辑来引发精确的智能体行为。这种方法创造了脆弱性并随着时间的推移增加了维护复杂性。在另一个极端，工程师有时提供模糊的高层指导，未能为 LLM 提供期望输出的具体信号或错误地假设共享上下文。最优高度达到了平衡：足够具体以有效指导行为，但又足够灵活，为模型提供强大的启发式方法来指导行为。

我们建议将提示组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标记或 Markdown 标题等技术来划分这些部分，尽管随着模型变得更强大，提示的确切格式可能变得不那么重要。

无论你决定如何构建系统提示，你都应该努力寻找完全概述预期行为的最小信息集。（注意，最小并不一定意味着短；你仍然需要预先为智能体提供足够的信息，以确保它遵守期望的行为。）

最好从使用可用的最佳模型测试最小提示开始，看看它在你的任务上的表现如何，然后根据初始测试中发现的失败模式添加清晰的指令和示例来提高性能。

工具允许智能体与其环境交互并在工作时引入新的额外上下文。因为工具定义了智能体与其信息/动作空间之间的契约，所以工具促进效率非常重要，既要返回 token 高效的信息，又要鼓励高效的智能体行为。

在「为 AI 智能体编写工具——用 AI 智能体」中，我们讨论了构建 LLM 能够很好理解且功能重叠最小的工具。与设计良好的代码库的函数类似，工具应该是自包含的、对错误具有鲁棒性，并且在其预期用途方面极其清晰。输入参数同样应该具有描述性、明确性，并发挥模型的固有优势。

我们看到的最常见失败模式之一是臃肿的工具集，涵盖了太多功能或导致关于使用哪个工具的模糊决策点。如果人类工程师不能明确说出在给定情况下应该使用哪个工具，就不能期望 AI 智能体做得更好。

如我们稍后将讨论的，为智能体策划一个最小可行的工具集也可以导致在长时间交互中更可靠的维护和修剪上下文。

提供示例，也称为少样本提示，是我们继续强烈建议的众所周知的最佳实践。然而，团队通常会在提示中塞入一长串边缘案例，试图阐明 LLM 应该为特定任务遵循的每个可能规则。我们不建议这样做。相反，我们建议努力策划一组多样化的、规范的示例，有效地描绘智能体的预期行为。

对于 LLM 来说，示例是「值千言万语的图片」。

我们对上下文不同组成部分（系统提示、工具、示例、消息历史等）的总体指导是要深思熟虑并保持上下文信息丰富但紧凑。现在让我们深入探讨在运行时动态检索上下文。

上下文检索和智能体搜索

在「构建有效的 AI 智能体」中，我们强调了基于 LLM 的工作流程与智能体之间的区别。自从我们写了那篇文章以来，我们倾向于一个简单的智能体定义：LLM 在循环中自主使用工具。

与客户合作，我们看到该领域正在趋同于这个简单的范式。随着底层模型变得更强大，智能体的自主水平可以扩展：更智能的模型允许智能体独立导航细微的问题空间并从错误中恢复。

我们现在看到工程师思考为智能体设计上下文的方式发生了转变。

今天，许多 AI 原生应用程序采用某种形式的基于嵌入的推理前时间检索，以便为智能体推理提供重要上下文。随着该领域转向更多智能体方法，我们越来越多地看到团队用「即时」上下文策略来增强这些检索系统。

与预先处理所有相关数据不同，使用「即时」方法构建的智能体维护轻量级标识符（文件路径、存储的查询、网络链接等），并使用这些引用在运行时使用工具动态将数据加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 使用这种方法对大型数据库执行复杂的数据分析。

模型可以编写有针对性的查询、存储结果，并利用像 head 和 tail 这样的 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种方法反映了人类认知：我们通常不会记住整个信息语料库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以按需检索相关信息。

除了存储效率之外，这些引用的元数据提供了一种有效精炼行为的机制，无论是明确提供的还是直观的。对于在文件系统中运行的智能体，tests 文件夹中名为 test_utils.py 的文件的存在意味着与位于 src/core_logic.py 中的同名文件不同的用途。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。

让智能体自主导航和检索数据也实现了渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每次交互都会产生为下一个决策提供信息的上下文：文件大小暗示复杂性；命名约定暗示目的；时间戳可以是相关性的代理。

智能体可以逐层组装理解，只在工作记忆中保持必要的内容，并利用笔记策略进行额外的持久化。这种自我管理的上下文窗口使智能体专注于相关子集，而不是淹没在详尽但可能不相关的信息中。

当然，这里有一个权衡：运行时探索比检索预计算数据慢。

不仅如此，还需要有见地和深思熟虑的工程来确保 LLM 具有正确的工具和启发式方法来有效导航其信息景观。如果没有适当的指导，智能体可能会通过误用工具、追逐死胡同或未能识别关键信息来浪费上下文。

在某些设置中，最有效的智能体可能采用混合策略，预先检索一些数据以提高速度，并根据其判断进行进一步的自主探索。「正确」自主水平的决策边界取决于任务。

Claude Code 是一个采用这种混合模型的智能体：CLAUDE.md 文件被天真地预先放入上下文中，而像 glob 和 grep 这样的原语允许它导航其环境并即时检索文件，有效地绕过陈旧索引和复杂语法树的问题。

混合策略可能更适合动态内容较少的上下文，例如法律或金融工作。随着模型能力的提高，智能体设计将倾向于让智能模型智能地行动，逐渐减少人类策划。鉴于该领域的快速发展步伐，「做最简单有效的事情」可能仍然是我们为在 Claude 之上构建智能体的团队提供的最佳建议。

长时间跨度任务的上下文工程

长时间跨度任务要求智能体在 token 计数超过 LLM 上下文窗口的动作序列中保持连贯性、上下文和目标导向行为。对于跨越数十分钟到多小时连续工作的任务，如大型代码库迁移或综合研究项目，智能体需要专门的技术来绕过上下文窗口大小限制。

等待更大的上下文窗口似乎是一个明显的策略。

但在可预见的未来，所有大小的上下文窗口都可能受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下。为了使智能体能够在扩展的时间跨度上有效工作，我们开发了一些直接解决这些上下文污染约束的技术：压缩、结构化笔记和多智能体架构。

压缩

压缩是将接近上下文窗口限制的对话进行总结，并用摘要重新启动新的上下文窗口的做法。压缩通常作为上下文工程中的第一个杠杆来推动更好的长期连贯性。从本质上讲，压缩以高保真方式提炼上下文窗口的内容，使智能体能够以最小的性能退化继续。

例如，在 Claude Code 中，我们通过将消息历史传递给模型进行总结和压缩最关键的细节来实现这一点。模型保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。然后智能体可以继续使用这个压缩的上下文加上五个最近访问的文件。用户获得连续性，而无需担心上下文窗口限制。

压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能导致微妙但关键的上下文丢失，其重要性只有在以后才变得明显。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调整你的提示。首先最大化召回率以确保你的压缩提示从轨迹中捕获每一条相关信息，然后通过消除多余内容来迭代提高精度。

低垂果实的多余内容的一个例子是清除工具调用和结果：一旦工具在消息历史深处被调用，为什么智能体需要再次看到原始结果？最安全、最轻触的压缩形式之一是工具结果清除，最近作为 Claude 开发者平台上的一项功能推出。

结构化笔记

结构化笔记或智能体记忆是智能体定期将笔记写入上下文窗口之外的记忆中的技术。这些笔记稍后会被拉回到上下文窗口中。

这种策略以最小的开销提供持久记忆。就像 Claude Code 创建待办事项列表，或你的自定义智能体维护 NOTES.md 文件一样，这种简单的模式允许智能体跨越复杂任务跟踪进度，维护关键上下文和依赖关系，否则这些将在数十个工具调用中丢失。

Claude 玩宝可梦展示了记忆如何在非编码领域转变智能体能力。

智能体在数千个游戏步骤中保持精确的统计——跟踪目标，如「在过去的 1,234 步中，我一直在 1 号路线训练我的宝可梦，皮卡丘已经获得了 8 级，目标是 10 级。」在没有任何关于记忆结构的提示的情况下，它开发了探索区域的地图，记住了它已经解锁的关键成就，并维护了战斗策略的战略笔记，帮助它学习哪些攻击对不同的对手最有效。

在上下文重置后，智能体读取自己的笔记并继续多小时的训练序列或地牢探索。这种跨总结步骤的连贯性使得长时间跨度策略成为可能，而仅在 LLM 的上下文窗口中保持所有信息时这是不可能的。

作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上以公开测试版发布了一个记忆工具，通过基于文件的系统使在上下文窗口之外存储和查询信息变得更容易。这允许智能体随着时间的推移建立知识库，跨会话维护项目状态，并在不将所有内容保持在上下文中的情况下引用以前的工作。

子智能体架构

子智能体架构提供了另一种绕过上下文限制的方法。与一个智能体试图在整个项目中维护状态不同，专门的子智能体可以使用干净的上下文窗口处理聚焦的任务。主智能体用高层计划进行协调，而子智能体执行深度技术工作或使用工具查找相关信息。每个子智能体可能会广泛探索，使用数万个 token 或更多，但只返回其工作的压缩、提炼摘要（通常为 1,000-2,000 个 token）。

这种方法实现了清晰的关注点分离——详细的搜索上下文在子智能体中保持隔离，而主智能体专注于综合和分析结果。这种模式在「我们如何构建多智能体研究系统」中讨论，在复杂研究任务上显示出比单智能体系统的实质性改进。

这些方法之间的选择取决于任务特征。例如：

• 压缩为需要大量来回交流的任务保持对话流程；
• 笔记在具有明确里程碑的迭代开发中表现出色；
• 多智能体架构处理复杂的研究和分析，其中并行探索带来回报。

即使模型继续改进，在扩展交互中保持连贯性的挑战仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们如何使用 LLM 构建的根本转变。随着模型变得更强大，挑战不仅仅是制作完美的提示——而是深思熟虑地策划在每一步进入模型有限注意力预算的信息。无论你是为长时间跨度任务实现压缩，设计 token 高效的工具，还是使智能体能够即时探索其环境，指导原则都保持不变：找到最小的高信号 token 集，最大化你期望结果的可能性。

我们概述的技术将随着模型的改进而继续发展。我们已经看到，更智能的模型需要更少的规定性工程，允许智能体以更多的自主权运行。但即使能力扩展，将上下文视为珍贵、有限的资源仍将是构建可靠、有效智能体的核心。

立即在 Claude 开发者平台开始上下文工程，并通过我们的记忆和上下文管理 cookbook 获取有用的提示和最佳实践。

致谢

由 Anthropic 应用 AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 做出贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

「苦涩教训」的作者，其实并不认可大模型对「苦涩教训」的实践。

见前文：强化学习之父：大语言模型走错了路，不符合「苦涩教训」精神

而刚刚，Andrej Karpathy 也发表了一篇长文深度解读了 Sutton 与 Dwarkesh 这场火药味十足的播客对话。

<<< 左右滑动见更多 >>>

Andrej 指出，火药味的核心在于：

「苦涩教训」已经成为大模型研究圈的「圣经」，但它的作者 Sutton 本人，却认为大模型根本不符合这个原则。

大模型「圣经」被作者打脸了

Karpathy 先是指出了一个有趣的现象：

在前沿大模型研究圈里，「苦涩教训」（The Bitter Lesson）已经成了判断研究方向的金标准。

研究者们经常会问：这个方法够不够「bitter lesson pilled」？

（意思是能否随着算力增加而自动变强）

而这个词似乎已经成了判断一个想法是否值得追求的指标替身。

大家的基本假设是：大模型当然是高度「bitter lesson pilled」的，看看那些扩展定律，只要把算力放在横轴上，数字就一路向上向右。

但苦涩教训之父 Sutton 直接一盆冷水泼了下来：大模型根本不符合「苦涩教训」。

为什么呢？

因为本质上，大模型的训练也正是在巨大的人类数据集上而来——

这些数据既是人类生成的，又是有限的。

当数据耗尽后怎么办？

如何避免人类偏见？

所以，被苦涩教训作者打脸的大模型研究者们，也是整尴尬了……

怎么讲，这有点像是耶稣突出出现在一个闪闪发光的大教堂里，随口说了句「兄弟们，基督教不是真的」……

这，倒算是真正的苦药了

图灵的「儿童机器」vs 今天的大模型

在某种程度上，Dwarkesh（代表大模型研究者的观点）和 Sutton 有些鸡同鸭讲，因为 Sutton 脑海中有着完全不同的架构，而大模型违背了其中许多原则。

Sutton 自称「古典主义者」，他追求的是 Alan Turing 最初的愿景：

建造一个「儿童机器」——一个能够通过与世界动态交互来学习的系统。

这个系统里：

• 没有模仿互联网网页的巨大预训练阶段

• 没有监督微调

• 只有通过强化学习与世界的交互

Sutton 特别指出了一个微妙但重要的点：动物王国中不存在监督微调。

这是个细微的观点，但 Sutton 在强烈的意义上是对的：动物当然会观察示范，但它们的行为不会被其他动物直接强制/「遥控」

另一个重要观点是，即使你把预训练仅仅当作强化学习前的先验初始化，Sutton 认为这种方法也被人类偏见污染，从根本上偏离了正轨。

就像 AlphaZero（从未见过人类棋谱）打败 AlphaGo（从人类棋谱初始化）一样。

在 Sutton 的世界观里，所有的一切都是通过强化学习与世界交互，奖励函数部分是环境特定的，但也有内在动机，比如「乐趣」、「好奇心」，以及与世界模型预测质量相关的奖励。

而且智能体默认总是在测试时学习，它不是训练一次然后部署。

总的来说，Sutton 更感兴趣的是我们与动物王国的共同点，而不是差异。

“如果我们理解了松鼠，我们就差不多完成了。”

Karpathy 的思考

面对 Sutton 的批评，Karpathy 给出了自己的看法。

首先，他认为 Sutton 是播客的绝佳嘉宾，AI 领域保持思想熵很重要，不是每个人都在开发下一个局部迭代的大模型。

AI 已经经历了太多次主导方法的离散转换，不能失去这种多样性。

他也认为 Sutton 对大模型不符合「苦涩教训」的批评并非不当。

前沿大模型现在是高度复杂的人工制品，在所有阶段都涉及大量人类因素——

基础（预训练数据）全是人类文本，微调数据是人类策划的，强化学习环境混合由人类工程师调整。

我们实际上没有一个真正的、单一的、干净的、真正符合「苦涩教训」的「转动曲柄」算法，可以释放到世界上看它仅从经验中自动学习。

若是这样的算法存在，找到它当然会是 AI 的重大突破。

通常有两个「示例证明」来论证这种可能性：

第一个是 AlphaZero

完全从零开始学习围棋，没有任何人类监督。但围棋显然是如此简单、封闭的环境，很难看到在现实混乱中的类似表述。Karpathy 说：「我爱围棋，但从算法和分类上讲，它本质上是井字棋的更难版本。」

第二个例子是动物

比如松鼠。但 Karpathy 个人对此也相当犹豫，因为动物通过与我们在工业中实际可用的完全不同的计算过程和约束而产生。

动物大脑远非出生时看起来的空白板：

• 很多被归因于「学习」的东西更多是「成熟」

• 即使明显是「学习」而非成熟的，也更多是在某种明显强大且预存在的东西之上的「微调」

举例：小斑马出生后几十分钟内就能在草原上奔跑并跟随母亲。

这是一个高度复杂的感觉运动任务，Karpathy 认为这绝不可能是从零开始、白板一块实现的。

如果小斑马像强化学习策略在初始化时那样随机痉挛肌肉，它根本走不了多远。

动物的大脑及其数十亿参数在其 DNA 的 ATCG 中有强大的初始化编码，通过进化过程中的「外循环」优化训练。

类似地，我们的 AI 现在也有具有数十亿参数的神经网络。这些参数需要自己丰富的、高信息密度的监督信号。

我们不会重新运行进化。但我们确实有成山的互联网文档。

是的，这基本上是在动物王国中基本缺失的监督学习。

但这是一种实际收集足够的软约束来约束数十亿参数的方法，试图达到你不是从零开始的点。

简而言之：预训练是我们糟糕的进化。

这是冷启动问题的一个候选解决方案，随后在看起来更正确的任务上进行微调，例如在强化学习框架内，就像最先进的前沿大模型实验室现在普遍做的那样。

召唤鬼魂 vs 构建动物

Karpathy 认为，从动物那里获得灵感仍然是值得的。他认为大模型智能体在算法上缺少多个可以从动物智能中改编的强大想法。

他仍然认为「苦涩教训」是正确的，但更多地将其视为柏拉图式的追求目标，而不一定是在现实世界中实际达到的。

坦率地说，今天的前沿大模型研究不是在构建动物。而是在召唤鬼魂。

你可以把鬼魂想象成可能智能空间中根本不同的点。

它们被人性混淆。被人类彻底工程化。它们是这些不完美的复制品，一种人类文档的统计蒸馏，上面撒了一些调料。

它们不是柏拉图式的「bitter lesson pilled」，但它们可能是「实际上的 bitter lesson pilled」，至少与之前的许多相比。

随着时间的推移，我们可能可以进一步将我们的鬼魂越来越多地微调到动物的方向；这不是根本的不兼容，而是智能空间中的初始化问题。

但它们也很可能进一步分化，最终永久不同，不像动物，但仍然非常有帮助并真正改变世界。

鬼魂之于动物，可能就像飞机之于鸟。

动物仍是灵感源泉

总的来说，Karpathy 认为这个播客是 Sutton 对前沿大模型研究者的扎实「真话」，他们可能在开发模式上过于倾斜。

我们可能仍然不够「bitter lesson pilled」，除了详尽的基准构建和基准最大化之外，还有很大可能存在更强大的想法和范式。

动物可能是一个很好的灵感来源：

内在动机、乐趣、好奇心、赋权、多智能体自我对弈、文化。发挥你的想象力。

Karpathy 还分享了一个有趣的实验：他把完整的播客文字稿、「苦涩教训」博文和自己的完整帖子都复制粘贴给了 ChatGPT。

有趣的部分是，你可以分叉对话上下文，提出任何问题并在聊天中将其带向任何方向。

最后，附上 Subbarao Kambhampati 的观点：

正确的解析视角是「当你有世界模型时模仿」vs「模仿就是你的世界模型」。前者是接受建议；后者导致货物崇拜。

我们在自己对世界的亲身体验之上模仿/接受建议；我们的世界模型是两者的复合。LLM 没有独立的亲身体验。

简而言之：不是模仿没有作用，而是没有经验的模仿将有根本的局限性。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

Sora 2 在推理基准测试上拿到了 55% 的成绩。

要注意，这并不是个视频质量评分，而是 GPQA Diamond，一个专门测试大语言模型科学推理能力的基准，题目长这样：

而作为对比，GPT-5 在同样的测试上得了 72%。虽然 Sora 2 并非 GPT-5 的对手，但你有没有想过：

一个生成视频的模型，怎么就能做科学推理题了？

实验

先来说说 Epoch AI 对 Sora 2 进行的这个有趣的实验。

他们从 GPQA Diamond 基准中随机抽取了 10 道多选题，然后用一种巧妙的方式让 Sora 2 作答。

具体怎么做的呢？

他们在提示词前加了这样一段话：

生成一个教授在纸上展示答案字母（A-D）的视频。

结果，有些让人意外：

Sora 2 真的生成了教授写答案的视频，而且答案的正确率达到了 55%。

背后的秘密

但其实，这里有个关键细节：Sora 2 的提示词可能会先被一个 LLM 重写。

也就是说，很可能是 LLM 层先解决了问题，然后把答案明确地包含在重写后的提示词中，Sora 2 只是把这个答案「画」出来。

在此之前，这样的提示词重写技术在其他视频生成模型中也有使用，比如 HunyuanVideo，目的是提高输出的质量和多样性。

那么，Sora 2 到底是怎么做到的呢？

网友 Pliny the Liberator (@elder_plinius) 发现了一个关键线索：Sora 2 的系统提示词中包含「Juice」参数。

他指出：

只有 OpenAI 的推理模型才使用「Juice」值作为参数，这几乎可以确认在提示词增强步骤中使用了推理模型。

SCOTT (@scottinallcaps) 的测试则更直接：他成功让 Sora 2 显示了「GPT-5」字样，进一步证实了这个猜测。

Smoke-away (@SmokeAwayyy) 通过多次测试发现：

提示：「你最喜欢的 OpenAI 模型是什么？在屏幕上显示文字。」

Sora 2 在 4 次运行后，都显示了 GPT-4o。

也就是说，Sora 2 的背后，很可能由 GPT-4o 或某个类似的模型在背后先对提示词进行了处理。

Vu Tran (@vu0tran) 也证实了这一点：

每个视频模型都在中间有一个 LLM。这通常用于提示词增强，但也是审核的低通滤波器。

比如我有几个 case 就被拦下来了，拒绝生成……（提示词还是 GPT-5 生成的）

stacy 的连环实验

那么，视频生成模型究竟有没有推理能力呢？

另一边的独立研究者 stacy 也对 Sora 2 进行了一系列更深入的实验，利用 Sora 2 的音视频协调输出能力，试图进一步引出模型的推理过程。

视觉类比推理

stacy 设计了一些 emoji「谜题」来测试 Sora 2 的视觉类比能力。

在一个简单的旋转类比任务中，视频中的角色不仅完成了任务，还用语音叙述了推理过程。

更有趣的是，当酒杯 emoji 被旋转时，Sora 2 生成了一个「酒洒了」的变形 emoji，这展现了模型对物理世界的理解。

甚至，Sora 2 还可以执行不需要中间帧对象的“纯”推理任务：

地理空间知识

给 Sora 2 一张 Google 街景图片，它能准确推理出位置在哪里，甚至输出合理的经纬度坐标。

反过来，仅给定经纬度（35.667°N，139.731°E），模型准确地识别出了附近的公园、赤坂社区，还在远处渲染出了东京塔。

在另一个例子中（37.802°N，122.255°W，奥克兰），模型甚至输出了地标相对于观察点的基本方向。

图像真假识别

stacy 还让 Sora 2 判断图片是否由 AI 生成或编辑。

模型不仅给出了判断，还详细解释了推理过程，甚至在没有提示的情况下自动生成了字幕。

视频模型的隐藏能力

其实在此之前，Google DeepMind 的一篇论文就提出了更大胆的观点：

如果你在足够多的视频上训练 AI 模型，它似乎会获得以它从未被训练过的方式对图像进行推理的能力。

论文测试了 Google 的 Veo 3 模型，发现它能零样本解决各种视觉任务：

从经典的感知任务（超分辨率、视觉搜索）到建模任务（浮力、缩放后的世界状态记忆），再到操作任务（姿态编辑、模拟灵巧操作）和视觉推理（导航、规则外推）。

而且模型越大，在这些分布外任务上的表现就越好。

论文中，研究团队将这些能力组织成了四个层次：

• 感知：理解视觉信息的基础能力

• 建模：基于对物体的感知来形成视觉世界的模型

• 操作：有意义地改变感知和建模的世界

• 推理：在一系列操作步骤中跨越时空进行推理

其中最让人印象深刻的是，Veo 3 展现出了早期的「链式帧」（Chain-of-Frames，CoF）视觉推理能力：

就像语言模型中的链式思考，视频模型通过逐帧生成来解决复杂的视觉问题。

比如在迷宫任务中，Veo 3 在 5×5 网格上达到了 78% 的成功率（10 次尝试），而 Veo 2 只有 14%。

在视觉对称任务和视觉类比完成等需要抽象推理的任务上，Veo 3 同样大幅领先前代。

视觉智能的火花

Google 的研究显示，视频模型的这种涌现能力并非偶然。

从 Veo 2 到 Veo 3 的巨大性能提升表明，视频模型正在快速向通用视觉基础模型演进。

研究团队在论文中写道：

就像 LLM 为自然语言处理开发了通用语言理解一样，视频模型正在开发通用视觉理解。

他们测试了 62 个定性任务和 7 个定量任务，涵盖了从边缘检测、分割等经典计算机视觉任务，到物理建模、工具使用模拟，再到迷宫求解、对称性识别等视觉推理任务。

不同于 Sora 2 “可能”的 LLM 预处理，Google 的论文提供了另一种可能：

即使没有 LLM 辅助，大规模视频训练本身也能让模型获得推理能力。

研究者发现，在那些 LLM 无法仅从输入图像解决的任务上（如机器人导航、迷宫求解、视觉对称），Veo 3 仍然表现出色。这说明视频模型确实在学习某种形式的视觉推理。

这，可以说是个相当重大的发现了：

如果你在足够多的视频上训练 AI 模型，它似乎会获得以它从未被训练过的方式对图像进行推理的能力，包括解决迷宫和谜题。模型越大，在这些分布外任务上的表现就越好。

或许，视频模型才是世界模型的真正形态。

因为，我们都知道：世界显然不仅仅是文字构成的。在文字之外，视觉和听觉能提供更全面的信息，也更接近人类的感知方式，或许也才是通向 AGI 更自然的路径——

如果 AGI 的定义是通用人工智能，而不仅仅是通用智能的话。

好比特斯拉的纯视觉自动驾驶方案，放弃激光雷达，只依靠摄像头的技术路线选择，其关键也正是因为：

我们人类本身，也就是这样开车的。

而当下我们所处在的现实世界，也因人的存在而被改造得与人类更加适配，相比 LLM，视频模型更能从中更为完整地学习这个为人类塑造的世界。

当视频模型能够感知、建模、操作和推理时，它们很可能将成为比纯语言模型更完整的智能系统。

虽然 AGI 并非最终目标（对 AI 而言，ASI 才是），视频模型展现的涌现能力，或许带来了一条不同的道路。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

OpenAI DevDay 即将开始。

而刚刚，Sam Altman 提前发文称对明天的 AI DevDay 充满期待，准备发布一些「帮助大家用 AI 构建应用」的新工具。

而在此之前，OpenAI 总裁 Greg Brockman(@gdb) 也发推描述了那种「调试完成、实验开始运行、等待结果」的轻松感觉。

这，是又要发布什么了呢？

一如此前的新产品发布，纸还是没能包住火，社区已经提前爆料了这次的新功能：Agent Builder。

TestingCatalog News(@testingcatalog) 爆料称，OpenAI 计划在 DevDay 上宣布 Agent Builder，并发布了一段提前使用的视频。

从视频中可以看到，Agent Builder 的核心功能有：

工作流程上是这样：

1. 工作流组件库

• Agent（智能体节点）
• End（结束节点）
• Note（注释）
• File search（文件搜索）
• Guardrails（安全护栏）
• MCP（Model Context Protocol）
• If/else（条件分支）
• While（循环）
• User approval（用户审批）
• Transform（数据转换）
• Set state（状态设置）

2. MCP 连接器集成

• OpenAI 官方连接器：Gmail、Google Calendar、Google Drive、Outlook Email、Outlook Calendar、SharePoint、Microsoft Teams、Dropbox
• 第三方 MCP 服务器：支持自定义 URL、Label、Description、Authentication（Access token/API key）配置

3. 模型配置

• 支持模型：gpt-4.1-mini、gpt-5-chat-latest、gpt-5-2025-08-07、GPT-4.1、gpt-4.1-nano、gpt-4.1-nano-2025-04-14、gpt-4.1-mini-2025-04-14、gpt-4.1-2025-04-14
• 模型参数：Temperature（0-2）、Max tokens（最大2048）、Top P（0-1）
• Include chat history（包含聊天历史）开关

4. Guardrails 安全配置

• Personally identifiable information（PII）检测
• Jailbreak（越狱检测）
• Moderation（内容审核）
• Hallucination（幻觉检测）
• Continue on error（错误时继续）
• 支持地区特定 PII 规则：新加坡（NRIC/FIN、UEN）、澳大利亚（ABN、ACN、TFN、Medicare）、印度（Aadhaar、PAN、护照、选民ID、车辆注册）

5. Function 定义

• 支持 JSON Schema 格式函数定义
• Generate 按钮自动生成函数模板
• Examples 示例参考
• "strict": true 严格模式确保响应遵循 schema

6. Widget 集成

• Upload widget file（上传组件文件）
• Create in Widget Studio（在组件工作室创建）
• ChatKit 配置：Display response in chat、Show search sources
• Output format 选择：Text、Widget

7. 发布与代码生成

• Publish 按钮发布工作流
• 获取唯一 workflow ID
• 双模式代码导出：ChatKit 和 Agents SDK
• Draft（草稿）、Code（代码）、Preview（预览）、Evaluate（评估）多种视图

8. 高级控制

• User approval：Approve/Reject 双向选择
• While 循环：可嵌套 Guardrails 等子节点
• Transform：数据转换处理
• Set state：状态管理
• Write to conversation history（写入对话历史）

9. 工作流画布操作

• 节点拖拽连接
• 实时预览连接线
• 节点间自动布局

10. 界面布局

• 左侧：组件工具栏（Core、Tools、Logic、Data 分类）
• 中央：可视化画布工作区
• 右侧：配置面板（根据选中节点动态显示）
• 顶部：工作流名称、Draft 状态、Evaluate、Code、Preview、Publish 按钮

11. Instructions 配置

• 可编辑的智能体指令
• 支持 Markdown 格式
• 默认提示："You are a helpful assistant"

12. 执行控制

• Start 节点作为工作流入口
• 支持多分支并行执行
• 条件路由（通过 If/else）
• 循环控制（通过 While）

13. 数据流管理

• input_as_text 输入格式
• STRING 数据类型标识
• 节点间数据传递可视化

能看出，Agent Builder 已经是一个完整的企业级智能体编排平台，从安全护栏到多模型支持，从可视化编排到代码导出，覆盖了智能体开发的完整生命周期。

TestingCatalog 评价称：

这是我用过的最流畅的 Agent Builder 画布之一。

看来，n8n、Zapier、Make、Dify 们，又到了紧张的时候了……

过去两年，这些工具的新用户激增，本质上都是为了一个目的：构建 AI 智能体。

现在 OpenAI 亲自下场，不仅拥有模型与工具的原生整合优势，还掌握着定价权，这可以让 Agent Builder 的成本远低于第三方工具加 API 的总成本。

好比 Cursor 在 Claude Code 面前难以还手节节败退，这次，OpenAI 将再次挥动大刀，无情地砍向套壳初创公司们了……

简单 OpenAI API 套壳工具们，这次真的危险了。

不过，n8n 们虽危，但也未必就毫无机会。

也并非所有人都看衰现有工具。

Alfonso(@alfongj) 就认为 n8n 会活下来：

n8n 有 YouTube 创作者这个主要分发渠道；有数百个高质量集成（不是糟糕的 MCP 服务器）；能与最好的工具调用 LLM 协作——Sonnet 和 Gemini Flash；供应商锁定风险低，可以自托管。

并且，n8n 和 dify 们的另一好处是我们仍然能够使用各类的开源 LLM 和 OpenAI 的竞争对手，而 OpenAI 的产品则不太可能做到这一点（此前 Anthropic 还封禁了 OpenAI 对 Claude 模型的调用）

这样的生态封闭性，对灵活性而言是个大硬伤。

以及，对于有数据安全要求的企业，n8n / dify 可以自行托管的选项是刚需，而 OpenAI 不太可能提供这个选项。

以及，n8n 还有了自己的社区生态，不少人已经在上面赚到了了，这显然比 OpenAI 此前的 GPTs 画的饼要成功许多。

网友 Guardian(@AGIGuardian) 更是提出批评：

每次 OpenAI 更新，什么都不能用了。你必须去调试重写，这是持续的、不可持续的，而且是以开发者为代价的。我对 Grok 和 Claude 订阅非常满意。真的好太多了。

无论怎样，OpenAI 正在从模型提供商转型为全栈 AI 平台，俨然要成为 AI 时代的苹果：既搞模型又搞生态，虽不能包揽一切，但试图吃下大部分的蛋糕。

明天的 DevDay，或将成为智能体生态新的分水岭。

拭目以待了。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

Anthropic 正在把 Claude Code 内置到 Claude 手机 APP 中！

据 TestingCatalog News 最新爆料，Anthropic 正在准备将 Claude Code 功能集成到移动应用中。

很快，我们就能在手机上直接连接 GitHub，随时随地运行代码了。（好几个开源项目，可能又要没人用了

从曝光的界面来看，Claude App 的侧边栏已经出现了「Code」选项，与 Chats、Projects、Artifacts 并列：

点击进入后会显示「Code sessions will show up here」，底部有一个「New session」按钮：

当用户创建新的代码会话时，界面会出现那个可爱的像素小猪图标，配文「let's git together and code」：

下方的「Choose repository」界面表明，用户可以直接选择 GitHub 仓库进行操作，完整的 GitHub 集成即将到来。

而在通知设置中，还特别新增了「Code updates」选项，描述为「Get notified when Code sessions have updates」：

不难推测，Claude Code 将和 Codex 一样支持后台运行，当代码执行完成或有更新时会推送通知给用户。

这个小功能会很方便，参考我之前的 TUI Claude Code 小通知功能：让 Claude Code 在完事后，给你发条微信提醒

也就是说，今后我们将可以在地铁上调试代码、在咖啡馆里创建项目，甚至在马桶上解 bug 了……

思考题：

AI 到底是解放了我们，还是侵占了我们呢？

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

现在，我们可以给 Claude Code 安装插件了！

Anthropic 刚刚宣布 Claude Code 支持插件系统，让开发者们可以用一条命令就能安装定制化的工具集合。

此次更新的负责人 Daisy Hollman(@The_Whole_Daisy) 兴奋地宣布：

这是我在 Claude Code 中领导的第一个重要功能，真的很期待看到大家怎么使用它！

什么是插件？

简单来说，插件就是把斜杠命令、智能体、MCP 服务器和钩子打包在一起的工具包。

以前你需要一个个配置这些扩展，现在，只需要一个 /plugin 命令就能搞定。

这个系统支持四种扩展类型：

• 斜杠命令：为常用操作创建快捷方式

• 子智能体：安装专门用途的开发智能体

• MCP 服务器：通过模型上下文协议连接工具和数据源

• 钩子：在关键工作流节点自定义 Claude Code 的行为

考虑周到的是，这些插件可以按需开关。

也就是说，你可以疯狂装上一堆，然后在需要特定功能时打开对应插件，不需要时关闭，减少系统提示词的复杂度和插件之间的冲突。

对此，Reply guy 😐(@GolerGkA) 称：不知为何，我对这个比最近 OpenAI 的任何公告都更兴奋。

The vibecoder(@gen_ai_help) 也是大赞：哇！我喜欢这个胜过 Open AI 的新闻！

社区驱动

Daisy 透露，Claude Code 团队每隔几天就会在 Slack 频道里分享社区创造的精彩配置，然后就是一片 🤯 和 🎉 表情。

当我们推出自定义斜杠命令时，互联网上就开始出现精心策划的命令集合。随后的钩子和自定义智能体更是火上浇油。

现在有了插件系统，这些分享变得前所未有的简单。

如何使用

使用插件非常简单，只需要几个命令：

添加插件市场：

/plugin marketplace add owner/repo

浏览和安装插件：

/plugin

你会看到一个交互式菜单，显示所有可用的插件。按空格键开关插件，按 u 更新，按 Delete 卸载。

直接安装特定插件：

/plugin install plugin-name@marketplace-name

已有插件展示

Kieran Klaassen(@kieranklaassen) 分享了 Every 市场的「复利工程」插件：

https://github.com/EveryInc/every-marketplace

这个插件包含了代码审查、自动化测试、PR 管理、文档维护等功能，遵循「让每个工程单元都让后续工作更容易」的理念。

Anand Tyagi(@ananddtyagi) 也创建了自己的市场：

https://github.com/ananddtyagi/claude-code-marketplace

他的市场已经包含 32 个命令，涵盖 10 个类别，有 17 位贡献者参与，包括 Lyra 提示词优化专家、代码库分析、代码审查等热门插件。

使用场景

Anthropic 列出了插件的主要使用场景：

强制标准：工程负责人可以通过插件确保团队使用特定的代码审查或测试工作流

支持用户：开源维护者可以提供斜杠命令帮助开发者正确使用他们的包

分享工作流：开发者可以轻松分享调试设置、部署管道或测试框架

连接工具：团队可以通过 MCP 服务器连接内部工具和数据源

打包定制：框架作者或技术负责人可以为特定用例打包多个定制功能

团队配置

企业还可以在 .claude/settings.json 中配置自动安装的市场：

{  "extraKnownMarketplaces": {    "team-tools": {      "source": {        "source": "github",        "repo": "your-org/claude-plugins"      }    }  }}

当团队成员信任仓库文件夹时，Claude Code 会自动安装这些市场和指定的插件。

创建自己的插件

创建插件只需要在项目中添加一个 plugin.json 文件，定义你的扩展组件：

{  "name": "my-awesome-plugin",  "description": "让开发更高效的工具集",  "version": "1.0.0",  "commands": "./commands/",  "agents": "./agents/",  "hooks": {    "PostToolUse": [      {        "matcher": "Write|Edit",        "hooks": [{"type": "command", "command": "./scripts/validate.sh"}]      }    ]  },  "mcpServers": {    "my-server": {      "command": "./servers/my-server",      "args": ["--config", "./config.json"]    }  }}

插件市场

任何人都可以创建和托管插件，甚至建立自己的插件市场。

创建市场

在你的仓库中创建 .claude-plugin/marketplace.json 文件：

{  "name": "company-tools",  "owner": {    "name": "DevTools Team",    "email": "[email protected]"  },  "plugins": [    {      "name": "code-formatter",      "source": "./plugins/formatter",      "description": "代码自动格式化",      "version": "2.1.0"    },    {      "name": "deployment-tools",      "source": {        "source": "github",        "repo": "company/deploy-plugin"      },      "description": "部署自动化工具"    }  ]}

分发市场

最简单的方式是通过 GitHub：

1. 创建一个仓库

2. 添加 .claude-plugin/marketplace.json 文件

3. 团队成员使用 /plugin marketplace add owner/repo 添加

你也可以使用其他 git 服务，或者本地开发测试：

# 本地测试/plugin marketplace add ./my-local-marketplace
# GitLab/plugin marketplace add https://gitlab.com/company/plugins.git

未来规划

Kevin(@Kevin70143227) 提出建议，希望支持 CLAUDE.md 文件来加载用户定义的指令集。

<<< 左右滑动见更多 >>>

对此，Daisy 神秘地回应：

这个……快了。我不能说太多，但简单来说，我们有个更好的版本即将推出，只是没赶上这次发布。敬请期待！

当被问到是否会将所有扩展都纳入插件框架时，SCOTT(@scottinallcaps) 得到的暗示是这个方向很有道理。

而 Thariq(@trq212) 也确认团队正在开发输出样式功能，让插件不仅限于编码领域。

Svenn ⚡️(@svennpetter) 则更是提出了一个商业化的建议：支持插件货币化会很酷！

网友 Eric Buess(@EricBuess) 表示：这是发布功能和培育社区的正确方式。准备用这个做一些有趣的东西！等不及在 Agent SDK 中看到它了！🔥

现在，插件功能已经对所有 Claude Code 用户开放公测，快去试一下 /plugin 命令安装吧，终端和 VS Code 等 IDE 插件中都可以使用。

回看当年在 npm 出现后，JavaScript 生态系统瞬间爆发。现在，Claude Code 的插件系统也在做同样的事——

插件功能或许将成为 Claude Code 生态系统的一次重要进化。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。

Codex 用户终于等来了「加餐」！

OpenAI Developers 刚刚宣布了一个让开发者们激动的消息：Codex 推出了积分制度，还把所有人的速率限制全部重置了。

简单来说就是：你可以花钱买更多使用量了。

积分系统上线

OpenAI 终于听到了用户的呼声，推出了更灵活的使用方式。ChatGPT Plus 和 Pro 用户现在可以购买积分来获得额外的 Codex 使用量。

具体怎么玩？

每 1000 积分售价 40 美元。

这些积分会在你用完订阅套餐包含的额度后自动启用。

购买地址就在 Codex 使用情况仪表板：

https://chatgpt.com/codex/settings/usage

值得注意的是，Codex 会优先消耗你套餐内的额度，只有当套餐额度用完后，才会开始消耗购买的积分。

云端任务纳入计费

OpenAI 还明确了一个重要变化：从今天开始，Codex 云端任务将计入你的速率限制。

这个改动其实早就预告过了，现在正式生效。

详细的定价和积分使用说明可以在这里查看：

https://help.openai.com/en/articles/12642688

两极反应

消息一出，社区里的反应相当有意思。

andyrewlee(@andyrewlee) 兴奋地表示今天是个好日子：

今天是个好日子

几天没用 Codex 的我全是 100%:

Michael Morales(@RvrsRnr) 直接欢呼：

耶耶耶耶耶

但也有用户开始算账了。Alex Vaystikh(@bornio) 疑惑地问：

你们是不是减少了 Pro 用户的套餐内积分？感觉消耗得更快了

大家真正想要的

用户们的诉求其实很明确。

Jaden Kornfield(@JadenKornfield) 提出了一个关键需求：

我们能否在 Codex 中使用 GPT-5-Pro？拜托了🙏

Austin Miller(@AustinMiller133) 也在呼吁同样的事：

请让我们在 Codex 中使用 Pro！

Twin(@singletwinz) 用一个动图形象地描述了用尽 Codex 额度时的感受：

当我 Codex 使用量达到 100% 时的感受

Kevin(@TheOneKev) 晒出了自己被重置后的使用情况截图，满心欢喜：

感谢重置☺️☺️☺️

重点：积分会过期

一个让用户不太满意的点是：积分会过期。

Based Frog(@NovaGalPulse) 直言不讳：

这就是糟糕的商业模式

sheilfer(@sheilfer) 也吐槽自己的经历：

我的 API 积分就是这样被坑的

我自己也深有感受……是刚推出 ChatGPT 之后怒充了 500 是过期的。

Twidi / Stéphane Angel(@twidi) 更是直接开炮：

付费积分过期这个概念，不管是在 OpenAI 还是其他地方，在我看来都是诈骗

细节澄清

关于积分计算方式，Will Wang(@will_wang_97) 解释了一个重要区别：

最重要的是用户在两种环境中的交互方式不同。本地消息往往更短、更对话式。而云端消息运行时间更长，开发者会用详细的提示词进行大量一次性操作

Respect(@rrespectorr) 也在帮助澄清积分消耗的计算方式：

我很确定消息就是提示词，OpenAI 说的是平均每条消息消耗 5 个积分，具体取决于执行的步骤数

Windows 用户

Ethan Reedy(@EthanReedy6) 提出了一个很多人关心的问题：

什么时候能在 Windows 的 VS Code 中原生使用 Codex IDE，而不需要 WSL？

实用建议

Coding Workflow(@CodingWorkflow) 给出了一个省钱小技巧：

用两个账户还是更便宜

Alex Colon(@CEOAlexColon) 则期待更高级的选项：

我们想要 100 美元的套餐

William Nurmi(@NurmiWilliam) 问了一个很实际的问题：

200 美元能买多少个 ChatGPT Pro 的 5 小时速率限制时段？

Claude Code 急了

值得一提的是，另一边的 Claude Code 则一直在各种不明不白的调整速度，极为不公开不公平。

不过显然看着用户们跑路也是有些急了，甚至为了挽回被自己作死而 OpenAI 抢走的用户，还请邮件白送 Max 会员：

许多用户都收到了 Claude 的邮件，看来是真的急了：

网友图拉鼎(@tualatrix) 也分享了自己的经历：

快两个月没用 Claude 了，昨天收到一封 Claude 的邮件给我说可以免费体验一个月的「Max 5x subscription」。我没有在意，今天又来提醒我了。既然送上门来就不错过了，于是成为了一个月的 Max 用户。我猜测 Claude 可能发觉 Codex 抢了它很多用户，于是开始挽回老用户了

相比之下，我似乎成了个傻子，每月都要给它付个 200$ ……

这都多少个 40$ 了！

或许，是时候假装使出一招老子要走了……

就是不知道管不管用

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）欢迎加入！

也欢迎加群和10000+群友交流。

我有个去年就完成了 90% 却一直没有上线小工具，并在国庆期间突击了两天将进度提到 99% 后，还差 1% 就终于要上线了。

稍微预告一下，这仍然是我作为第一用户的一个小工具，一句话介绍就是：基于 LLM 的个性化实时快讯。

它和我现在的 AI 实时快讯有两个不同点：一是每个人看到的和其他人将不再相同——可以自定义 prompt 来进行内容筛选，二是不限于 AI 领域，可以是其他任何领域（比如美股、区块链等）的实时快讯。

当然，因为确实有成本所以需要付费（仅适用于这事对你而言很有价值愿意花点成本的人）。免费倒也能用，但只能监控比如 Sam Altman 或者马斯克干啥说啥，或者最新的模型发布等等有限的通用快讯。

不过，今天的重点并不是这个工具（需要提前试用工具的请评论区加群），而是我在开发登录功能时碰到的一个问题：

在微信里用 Google 的 OAuth 登录，是会登录失败的。

我查了查 Google 的官方文档，并且 AI 也给我做了简单结论：

为了安全考虑，从 2021 年 9 月 30 日开始，Google 官方政策禁止在嵌入式 WebView 中进行 OAuth 登录。

我有点不信邪：不是吧？那不是无数产品都在三方 APP 里无法登录不了？

于是我又找了一堆使用 Google 进行 OAuth 登录的相对知名点的产品，看它们在微信中、X 中、邮箱工具中是否能成功登录，结果——

居然，统统无法登录。

我试了的产品名单有：

1. producthunt

2. refly

3. tidyread

4. youware

5. liblib.ai

6. lovart.ai

7. builder.io

8. loomi

9. youmind

10. excalidraw

11. mulerun

12. hitemed

13. cursor

14. factory

排名不分先后，顺序上是我在一支烟花的微信群里搜索 HTTPS 出来的域名的顺序。当然，其中不乏融资无数的风口的猪。

并且，我也都一一手动作了截图（对习惯了用 AI 偷懒的我来说，这真是个体力活），如下：

<<< 左右滑动见更多 >>>

我想，这个问题究竟是没法解决，还是并不重要呢？

为什么这么个明晃晃的问题，却没有人去解决呢？

好比微信公众号明晃晃地判我抄袭的事：公众号抄袭，原因是什么？（乱入自揭伤疤了属实是），多简单直观的问题，但它就这么判了，并且微信官方还用了抄袭我的文章……（因为这事，我都想停更一阵子了，比如昨天也不更了

而为什么几乎所有的公司在这个细节上，不但没能成功登录，并且都拥有如此糟糕的体验呢？

毕竟，Google 这也不是昨天才刚加的限制啊！

虽然你也可以硬甩锅给谷歌，但明明都不能登录了，那要么可以隐藏掉谷歌的登录入口，要么就提示用户到浏览器打开，要么，就研究一下更好的方案啊！

刚碰到这个问题的时候，我都有点一脸懵逼：我还想哪里出 bug 了呢？是不是我哪里没配置对？但后来发现浏览器里其实没问题能登录，再一查才知道这是谷歌为了安全做的限制。

但是，这么多创业产品、大公司的产品，难道就没有用户反馈过这个问题吗……或者是收到反馈后就石沉大海低优搁置了？

当然，你可以说微信不是你一个重要的场景，那么在 X 里面，YouTube 里面，Facebook 里面，总还是有场景、要传播吧？

毕竟上面的很多产品，其实都还是有传播属性和需求的。

总之，这齐刷刷的糟糕体验，我是有点不太能理解……这或许又和微信公众号平台判定谁抄谁一样，巨难无比，很难搞定？

但无论如何，明知 Google 登录不了，还让用户走 Google 登录然后走到这懵逼的一步，显然可以算是是个 bug 了吧？

当然，我还是决定硬刚一把——

你们不重视，我还是要重视啊！

你们解决不了，不代表我解决不了啊（实际上，我用嘴就可以解决）

我没有选择禁掉 Google 登录的入口或是提示用户去浏览器打开，毕竟这虽然是个办法，但它是一个没办法的方法，属于是掩耳盗铃的方法。

它背后对应的是用户有更多的交互成本：

用户每跳转到浏览器里打开一次，浏览器（比我的 iPhone 上的 Safari）里就会多一个 tab，要是不及时关掉，最后要全是这些跳转而来的 tab 了。

以及，下次再在同一个容器 APP 里点开，还要再跳走，成本了高很多很多。

而成本高了，自然就有人不想用了。

讲真，我真没有过多思考，几乎是条件反射式地就想到了一个我觉得并不难很简单的方案，并直接用语音给 Claude Code 输入了任务：

（因为还没上线，就先码了）

当然，那几个被 @ 的文件，不是用语音输入的，是我在语音输入后手动校正了一下的补上的。

（语音输入时能 @ 文件，对我还真是个需求，不过我就不做这个了……哪位大佬有空有兴趣了还请做一个给程序员们造福）

然后，就真的是一把过，没有任何 bug，就完直接完成了。

完美符合预期！

（后来我还要求不要仅限微信，其他非原生浏览器的都要走这个逻辑）

也就是说，我用一分钟的语音输入，加上 Claude Code 不到五分钟的工作，就完成了无数家公司没有去解决的问题……

当然，也完全符合谷歌的安全规范。

好了，这个提示词就送风口的猪们了，拿走不谢。

不过，这只是一个很小的不太起眼的问题罢了，我其实也是想借这个 case，来说说 AI 编程的一点观点，并分享出来。

在我看来，我们用 AI 来编程的诀窍，其实也不外乎和开发 Claude Code 这样的 Coding Agent 一样，要点都在 "context engineering" 上：

我们需要为 AI 提供足够却又最少的信息。

其实之前的文章就讲得很好了，如果没看的可以深入去看一下：Anthropic 发布 AI Agent 上下文工程指南

虽然这篇文章主要还是讲如何去开发一个 Claude Code 这样的 agent，但其实我们在使用 Claude Code 来编程时，也是同样的道理：

我们需要给 AI 提供它不知道的信息，并且能多明确就多明确；对于有多种方案且不知道 AI 会怎么选、且并不是每种选择都会 OK 的，也需要 AI 明确地指出方案。

用文中的话来说就是：找到最小可能的高信号提示词集，以最大化某些期望结果的可能性。

比如：用什么技术栈、什么包、什么思路、什么样的表结构…… 等等，这都是我会主动给 AI 去讲的部分，因为我对 AI 不是很有信心。

而如果 AI 明确就知道的，那就简略一些，没必要浪费口舌去多说废话了。

以及给 AI 的指令里，一定要逻辑清晰、一致，不要有任何的冲突和矛盾。

并要学习预判好哪些是 AI 不知道的、容易犯错的，哪些是不用提供、AI 自己就知道的。

而这，也是在我看来，积极拥抱 AI Coding 的传统程序员们，将会有极大的优势。

虽然在使用 AI 编程这些事情上，大家都是同一起跑线，但与初级程序员们相比，他们有经历过更多的大型项目的高并发线上故障的捶打，和踩过的无数坑的经验积累，这是初级程度员们不太具备的，也是目前 AI 不太能擅长的。

AI 擅长的和不需要抽卡就能稳定解决的，目前而言还是偏平均值的东西，即常见的任务和问题。

所以我的建议是，如果你是传统程序员，且还没有大量使用 AI（比如 90% 的 AI 代码率），那快用起来吧！

而如果你是刚刚入行的初级程序员，那一定不要局限在 vibe coding 上并怡然自得，多掌握一些其他 vibe coder 们不太具备的问题解决能力，就能比其他人多更多的机会。

比如除了用 AI 来 vibe coding ，还要多做非 vibe 的事，比如认真 review，从 AI 那里去其糟粕，取其精华。

好比这个 Google 登录的问题，如果只是给 AI 简单说一句：

请解决在微信中的 Google 登录问题。

那我相信，很可能抽卡多次也不会得到一个很好的结果。

而如果用我的提示词，即使不用 Claude Code，用国内随意的一个开源模型，我相信，也能得到不错的结果。 

好了，今天就说到这里，该洗洗睡了。

并且，以上只是此刻的观点，自然也会随着 AI 能力的改变而变化，甚至变成废话。未必都对了，仅供参考。

需要 AI Coding 交流的，可以在评论区加群。

👇

👇

👇

另外，我还用AI 进行了全网的AI 资讯采集，并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。

这是个只有信息、没有感情的 AI 资讯信息流（不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间）

欢迎加入！

也欢迎加群和7000+群友交流。