2025-08-01 08:00:05
原文： https://every.to/working-overtime/ai-turned-me-into-a-content-agency-of-one-561948be-5370-4306-a433-b352a572705e
作者： Katie Parrott
译者： Gemini 2.5 Pro
我是如何做到的——以及它如何改变了游戏规则。
As AI races ahead, we try to step back from the fray every once in a while. Each quarter, we gather for a "think week” to reflect on our work from the previous quarter and come up with new ideas that we can build to keep delivering an incredible experience for our readers. In the meantime, we’re re-republishing five pieces by Katie Parrot with insights on how AI is changing our professional lives. Yesterday we re-upped her piece on how using vibe coding tools inspired her to want to learn to write her own software. Today we’re running her in-depth look at how she uses AI to amplify her skills as a content creator.—Kate Lee
随着 AI 的飞速发展，我们偶尔会尝试从喧嚣中抽身。每个季度，我们都会举办一次“思考周”，反思上一季度的工作，并构思新的想法，以便继续为读者提供卓越的体验。在此期间，我们将重新发布五篇由 Katie Parrot 撰写的文章，其中包含了关于 AI 如何改变我们职业生活的深刻见解。昨天我们重发了她关于使用 Vibe 编程工具如何激发她学习编写自己软件的文章。今天，我们将分享她深入探讨如何利用 AI 来放大自己作为内容创作者技能的文章。——Kate Lee
作为一名内容策略师和写作者，我很少停下来计算自己到底产出了多少东西——直到我真的去算了，那些数字让我开始怀疑自己是否活在现实中。
几周前，我坐在电脑前，为我的一个自由职业客户规划下个月要做的所有事情，突然间，我意识到我需要负责的内容数量简直多到离谱：
过去，当我在一家营销代理公司任职时，每周产出两篇文章就已经算满负荷工作了。而我刚刚列出的工作量，足够让一个小型内容营销工作室里的三四个写手忙活两到三个月。
然而，这些都是我一个人完成的。大约只用了两周。在 AI 的帮助下。
没错：我正在使用那些让许多人——尤其是创意专业人士——担心会抢走我们工作的工具，去实实在在地抢走别人的工作。
我不禁思考：我对此感到心安理得吗？
理论上听说 AI 会扼杀工作是一回事。亲眼目睹它的发生——并且在“凶器”上看到自己的指纹——则是另一回事。但我不仅仅是在与负罪感作斗争。我还在努力理解以这种方式工作意味着什么——AI 赋予了我力量，让我能做得更多、更快，并且达到几年前无法想象的规模。因为眼前的任务不仅仅是跟上节奏，更是要决定我想参加一场什么样的比赛。而这，正是事情变得有趣的地方。
我开始使用 AI，并不是为了取代谁。和我们中的许多人一样，我最初只是出于好奇开始尝试这些工具。它们真的能让我的工作更轻松吗？能帮我工作得更快或更好吗？
我从一些小事做起，让 ChatGPT 建议博客文章的标题、总结研究报告或生成粗略的大纲。起初，它仅仅是一个工具。不过是这个推崇效率的行业里又一个生产力技巧罢了。
在我使用 AI 的两年多时间里，我必须承认：AI 不仅仅是帮我更快地生产内容——它从根本上改变了我能做的事情的规模。我过去常常碰到的那些限制——时间、精力、能力——的门槛被大大降低了。那些琐碎乏味的工作，比如重新格式化草稿、插入相关链接、或为了清晰而调整措辞，都变得更容易管理了，我的精神负担减轻了，在不同任务间切换的认知成本也降低了。我可以用更少的时间和精力，交付更多的内容。
但速度并不是我 AI 赋能工作流的唯一好处。我还能交付更高质量的工作，因为我不再因那些繁杂的体力活而心力交瘁。我可以专注于策略，专注于理解客户的需求，专注于打造独特的角度和观点——所有这些，在过去的生活里，我可能因为赶着截止日期和被交付物淹没而不得不偷工减料。说 AI 让你能专注于真正重要的人类元素，这听起来可能有点老套……但 AI 确实让我能专注于那些真正重要的人类元素。
我开始将 AI 在我工作中的角色分为六个部分，这与我工作流程的六个环节相对应：
（如果你好奇，我使用的具体工具栈是：
我们来看看这一切是如何协同工作的。
如果说我学到了什么，那就是：如果你想直接开箱即用 AI，你的体验会很糟糕。这些工具很强大，但它们并没有预装那些能让内容变得“好”的上下文。如果你想让 AI 产出的作品符合你的目标——无论是高质量的思想领导力内容、与品牌一致的营销文案，还是其他东西——你必须先给它喂入正确的输入。
这意味着要预先花时间在那些重要的特定元素上训练 AI。对我来说，这些资源包括：
比如说，我在为一个客户开发一个思想领导力活动。如果没有 AI，这可能需要数周的研究、多次的草稿修改和无休止的调整。有了 AI，整个过程既更快也更有条理——但前提是我已经花时间正确地设置了它。
我首先将品牌的定位、受众画像和过往内容喂给 ChatGPT。然后，我问一些有针对性的问题，比如：
AI 会发现我可能没有注意到的空白——帮助我像一个策略家一样思考，而不仅仅是一个写作者。
基于策略性的洞见，我使用 Claude 来生成大纲。AI 确保了结构逻辑清晰，与品牌信息一致，并涵盖所有关键点。
我将粗略的想法口述给 AI 驱动的文字处理器 Lex，它会将这些想法扩展成结构化的段落。这消除了面对白纸的恐惧，并加快了写作进程。
AI 会在我提交工作成果前帮我进行审查。例如，我会这样提问：
AI 会标记出我可能忽略的薄弱环节、不一致之处和潜在机会。
一旦文章完成，我使用 Spiral 将其转换成一篇 LinkedIn 帖子、一封电子邮件和一条 Twitter 推文——所有这些都使用品牌既定的语调。
项目完成后，我让 ChatGPT 将所有东西打包成一个可复用的框架，包括交付物、工作流程，甚至定价和打包选项。这样，我就可以将相同的流程应用于未来的客户，而无需从头开始，从而将一次性的工作转变为一个可规模化的系统。
通过这些步骤，我可以在一天内完成一篇思想领导力文章，而不是三天。我可以在几次专注的工作时段里，批量生产出整整一个月的内容。
AI 不仅仅是在加速我的工作流程——它正在重新定义作为一个单枪匹马的运营者的可能性。这很令人兴奋：它促使我更大胆地去思考我能创造什么，以及我能对我合作的组织产生怎样的影响。
但它也引出了一个我无法回避的问题：当每个自由职业者、代理公司和营销团队都开始这样工作时——当一个人能完成五个人的工作时——会发生什么？如果 AI 让我如此高效，它是否也让其他人变得多余？
还有另一种看待这个问题的方式。如果 AI 让一个人能做五个人的工作，这不仅仅意味着更大的压力——也意味着更多的机会。通过降低内容生产的成本，AI 为新项目、新业务和新型创意工作打开了大门。一个单枪匹马的创业者现在可以建立一个成熟的媒体品牌。一个营销团队可以达到曾经只有财富 500 强公司才能达到的创作水平。而且从历史上看，技术进步所创造的工作岗位通常比它们取代的要多。
然而，历史并不能保证未来，我们如何将 AI 融入工作，不仅仅是关于可能性——更是关于我们的选择。
理论上，AI 可能成为那个最终能让我们实现不同工作方式的工具。它本可以让我减少工作量，用更少的时间实现财务目标，并腾出时间来关注真正重要的事情——人际关系、休息，以及我书架上越堆越高的没玩过的桌游。
在某些方面，它确实做到了。曾经需要几天才能完成的任务，现在只需要几个小时。一个曾经可能需要一个团队来执行的完整内容日历，现在我一个人就能大规模地制作出来。曾经让人不堪重负的工作，现在变得流程化、结构化、高效化。
那么，如果 AI 让我如此高效，为什么我还在工作这么长时间？
经济学家约翰·梅纳德·凯恩斯在 1930 年代预测，技术进步将带来每周 15 小时的工作制。从那以后，每一次效率的重大飞跃都会引发人们的猜测——是时候了吗？我们终于要实现了吗？每一次，答案都是一样的：还没有。
因为，对我们大多数人来说，工作并不是那样运作的。
效率并不一定会减少我们的工作量——它会扩大工作量。我们能产出的越多，我们对自己和他人的期望就越高。当产出变得更多时，对于“足够”的标准也会被推得更远。
我不再是每周写两篇文章，而是可以写八篇。
我不再是每月发几条 LinkedIn 帖子，而是可以创建 24 条。
我没有用 AI 来减轻我的工作量，而是用它来承担更多。
作为一名自雇者，理论上我有退后一步的自由——将效率提升转化为更多的休息时间，而不是更多的产出。但当我审视整个工作环境时，我知道单靠效率并不能保证稳定。市场会调整。曾经看起来令人印象深刻的工作，最终会变成基线水平。这才是促使我不断前进的真正原因。不是因为我在追逐无尽的增长，而是因为知识工作的根基正在发生变化。
我们创造的这些工具非常强大。它们让高质量的产出变得大众化，使得个体运营者、小企业和大型公司都能比以往任何时候都更容易地进行大规模创作。在许多方面，这都是一个净利好——门槛降低了，机会增多了，执行宏大想法的能力也变得前所未有地触手可及。
它们也把我们推入了一个过渡时期。AI 赋予了我们不可思议的能力，但它也创造了一种新的跑步机。问题不仅仅在于 AI 是否会为我们节省时间，而在于我们是否真的会允许自己把那些时间拿回来。
我愿意相信，我们可以用这些工具来设计更好的工作方式，而不仅仅是更快的方式。不是让 AI 来设定节奏，而是我们可以停止追逐无尽的生产力增长，并为我们自己定义生产力的真正含义。
目前，我正在进行实验：测试我使用 AI 的边界，弄清楚在哪些地方速度是有用的，又在哪些地方它只是为了工作而创造更多的工作。我知道这些工具不会消失——所以真正的挑战不在于是否使用它们，而在于如何有意识地去使用。
因为知识工作的未来，不仅仅在于谁能产出最多。而在于谁能为自己的生产力设定规则。
2025-08-01 08:00:04
原文： https://lucumr.pocoo.org/2025/7/30/things-that-didnt-work/
作者： Armin Ronacher
译者： Gemini 2.5 Pro
使用 Claude Code 和其他 agentic coding 工具已经变得风靡一时。它不仅获得了数百万的下载量，而且这些工具也在不断增加新功能以简化工作流程。如你所知，我在五月份时对 agentic coding 感到非常兴奋，并尝试了许多新增的功能。我花了相当多的时间来探索我能接触到的一切。
但奇怪的是，我尝试过的东西，最终很少能坚持用下来。我的大多数尝试都半途而废了，我想分享一下哪些东西没能奏效可能会有点意思。这不代表这些方法行不通或是坏主意；它只意味着我没能让它们为我所用。或许其他人能从这些失败中学到点什么。
思考我使用方法的最佳方式是：
无效的自动化其实相当普遍。要么是我没法让自己去用它们，要么是我忘了它们，要么是我最终陷入了无休止的微调。对我来说，删除一个失败的工作流辅助工具至关重要。你不会希望一堆没用的 Claude 命令把你的工作区搞得一团糟，还让别人感到困惑。
所以，大多数时候我最终会做最简单的事情：多和机器对话，给它更多上下文，保持音频输入，把我的思路一股脑儿地丢进 prompt。这就是我 95% 的工作流。剩下的部分可能是对复制/粘贴的善用。
斜杠命令允许你预加载 prompt，以便在会话中随时可用。我曾期望它们会比实际情况更有用。我确实在使用它们，但我添加的很多命令最终都从未使用过。
斜杠命令的一些限制使其用途打了折扣。一个限制是，传递参数的方式只有一种，而且是非结构化的。在我的实践中，这被证明并非最佳选择。我一直遇到的另一个关于 Claude Code 的问题是，如果你使用斜杠命令，其参数出于某种原因不支持基于文件的自动补全。
为了让它们更好地工作，我经常让 Claude 使用当前的 Git 状态来决定要操作哪些文件。例如，我在这篇博客中有一个修复语法错误的命令。它几乎完全基于当前的 git status 上下文进行操作，因为在没有自动补全的情况下，显式地提供文件名很麻烦。
这是我实际使用的少数几个斜杠命令之一：
## Context
- git status: !`git status`
- Explicitly mentioned file to fix: "$ARGUMENTS"
## Your task
Based on the above information, I want you to edit the mentioned file or files
for grammar mistakes. Make a backup (eg: change file.md to file.md.bak) so I
can diff it later. If the backup file already exists, delete it.
If a blog post was explicitly provided, edit that; otherwise, edit the ones
that have pending changes or are untracked.
我现在的工作流假设 Claude 几乎每次都能从 Git 状态中判断出我指的是哪些文件，这使得显式参数在很大程度上变得多余。
以下是我曾经创建但最终没有使用的一些斜杠命令：
/fix-bug：我曾有一个命令，指示 Claude 通过从 GitHub 拉取 issue 并添加额外上下文来修复 bug。但我发现，与简单地提及 GitHub issue URL 并说出我关于如何修复它的想法相比，并没有看到任何有意义的改进。
/commit：我试过让 Claude 写出好的 commit message，但它们从来都不符合我的风格。我停止使用这个命令，尽管我还没有完全放弃这个想法。/add-tests：我真的希望这个能奏效。我的想法是让 Claude 在开发过程中跳过测试，然后在最后使用一个精心设计的可复用 prompt 来正确地生成它们。但是这种方法并不比自动测试生成效果更好，而且我对自动测试生成整体上仍不满意。
/fix-nits：我曾有一个命令用来修复 linting 问题和运行格式化工具。我不再使用它，因为它从未成为我的肌肉记忆，而且 Claude 已经知道如何做这件事了。我只需在 CLAUDE.md 文件中告诉它“fix lint”即可，不需要斜杠命令。
/next-todo：我在一个 to-do.md 文件中追踪一些小事项，并有一个命令来拉取下一个事项并处理它。即使是在这里，工作流自动化也没多大帮助。我使用这个命令的频率远低于预期。那么，如果我用更少的斜杠命令，我转而做什么呢？
复制/粘贴真的非常有用，因为 LLM 是模糊的。例如，我维护了一些链接集合，在需要时粘贴进去。有时我会主动获取文件，把它们放到一个被 git 忽略的文件夹里，然后提及它们。这很简单、容易且有效。你仍然需要有所选择，以避免过多地污染你的上下文，但与让它在错误的地方乱翻相比，多提供一些文本并没有那么大的害处。
我努力尝试让 hooks 发挥作用，但至今没有看到任何效率提升。我认为部分问题在于我使用了 yolo mode。我希望 hook 能够真正地操纵将要执行的内容。如今指导 Claude 的唯一方法是通过 denies（拒绝），但这在 yolo mode 下不起作用。例如，我曾试图用 hooks 让它使用 uv 而不是常规的 Python，但我没能做到。最后，我通过在 PATH 中预加载可执行文件来覆盖默认的程序，从而引导 Claude 使用正确的工具。
例如，这其实是我让它更可靠地使用 uv run python 而非 python 的一个 hack：
#!/bin/sh
echo "This project uses uv, please use 'uv run python' instead."
exit 1
I really just have a bunch of these in .claude/interceptors and preload that
folder onto PATH before launching Claude:
我其实只是在 .claude/interceptors 文件夹里放了一堆这样的脚本，并在启动 Claude 之前把这个文件夹预加载到 PATH 中：
CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 \
PATH="`pwd`/.claude/interceptors:${PATH}" \
claude --dangerously-skip-permissions
我还发现很难在恰当的时机触发 hook。我希望我能在一个漫长的编辑会话结束时运行格式化工具。目前，你必须在每次 Edit 工具操作后都运行格式化工具，这常常迫使 Claude 重新读取文件，浪费了上下文。即使有了 Edit 工具的 hook，我也不确定是否会继续使用它。
我其实很好奇大家是否能把 hook 用好。我在 Twitter 上看到一些讨论，似乎有一些很好的方法能让它们奏效，但我自己最终选择了简单得多的解决方案。
我最初非常看好 Claude 的 print mode。我努力让 Claude 生成内部使用 print mode 的脚本。例如，我让它创建一个模拟数据加载脚本——大部分是确定性代码，只带有一个小的推理部分，用 Claude Code 生成测试数据。
挑战在于实现可靠性，这一点我还没能做好。Print mode 很慢，而且难以调试。所以，尽管我非常喜欢这种大部分是确定性、只带少量推理组件的脚本概念，但我使用它的频率远低于我的期望。无论使用 Claude SDK 还是命令行的 print 标志，我都没有达到我所希望的效果。
我被 Print Mode 所吸引，因为推理太像一台老虎机了。许多编程任务实际上是相当刻板和确定性的。我们喜欢 linter 和格式化工具，因为它们毫不含糊。任何我们能完全自动化的事情，都应该自动化。在我看来，将 LLM 用于不需要推理的任务是错误的方法。
这就是 print mode 的吸引力所在。只可惜它要是能更好用就好了。用 LLM 来写 commit message，但用常规脚本来执行 commit 和 gh pr 命令。让模拟数据加载做到 90% 的确定性，只留 10% 用于推理。
我仍在使用它，但我看到的潜力比我目前所利用的要大得多。
我经常使用 task 工具来进行基本的并行化和上下文隔离。Anthropic 最近推出了一个旨在简化这个过程的 agents 功能，但我并没有发现它更容易使用。
子任务和子 agent 可以实现并行，但你必须小心。那些不易并行的任务——尤其是混合了读和写的任务——会造成混乱。除了调查性任务外，我得不到好的结果。虽然子 agent 应该能更好地保留上下文，但我发现通过开启新会话、将想法写入 Markdown 文件，甚至在聊天界面切换到 o3，往往能得到更好的结果。
关于工作流自动化的有趣之处在于，如果你作为开发者没有一套严格且始终遵循的规则，那么花时间与机器交谈、给出清晰的指令，其效果会优于精心预设的 prompt。
例如，我不使用表情符号或 commit 前缀。我也不强制使用 pull request 模板。因此，我能教给机器的结构就更少。
我也缺乏时间和动力去彻底评估我创建的所有工作流。这使我无法对它们的价值建立信心。
上下文工程和管理仍然是主要的挑战。尽管我努力帮助 agent 从各种文件和命令中提取正确的数据，但它们尚未能可靠地成功。它们要么提取得太多，要么太少。长时间的会话会导致遗忘最初的上下文。无论是手动操作还是使用斜杠命令，结果都感觉太随机了。用临场发挥的方式已经够难了，而静态的 prompt 和命令让事情变得更难。
我现在遵循的规则是，如果我确实想自动化某件事，我必须已经做过好几次了，然后我再评估通过我的自动化，agent 是否能得到更好的结果。这其中没有精确的科学，但我目前的衡量方式主要是让它做同样任务三次，然后手动观察其结果的差异，衡量的标准是：我是否会接受这个结果。
强迫自己去评估自动化还有另一个好处：我不太可能盲目地假设它对我有帮助。
因为通过 LLM 实现自动化存在一个巨大的隐藏风险：它会助长思维上的“脱离”。当你不再像工程师一样思考时，质量就会下降，时间会被浪费，你也不会去理解和学习。LLM 本身就已经够糟糕了，但每当我倾向于自动化时，我注意到“脱离”变得更加容易。随着时间的推移，我倾向于高估 agent 的能力。那里真的有恶龙！
你仍然可以在事情完成时进行审查，但事后审查会变得越来越难。虽然 LLM 正在降低重构的成本，但这个成本并没有降到零，而且出现回归是常有的事。
2025-08-01 08:00:03
原文： https://blog.val.town/vibe-code
作者： Steve Krouse
译者： Gemini 2.5 Pro
尽管存在普遍的 困惑，Andrej Karpathy 创造“vibe coding”这个词时，指的是一种 AI 辅助编程，在这种状态下你 “甚至都忘了代码的存在”。
We already have a phrase for code that nobody understands: legacy code.
对于谁也看不懂的代码，我们已经有了一个词：legacy code (遗留代码)。
Legacy code is universally despised, and for good reason. But why? You have the code, right? Can’t you figure it out from there?
遗留代码是人见人嫌的东西，这不无道理。但为什么呢？代码不就在那儿吗？你不能从代码本身搞懂它吗？
Wrong. Code that nobody understands is tech debt. It takes a lot of time to understand unfamiliar code enough to debug it, let alone introduce new features without also introducing bugs.
错了。没人能看懂的代码就是技术债。要花大量时间去理解陌生的代码，才能进行调试，更别提在不引入新 bug 的前提下增加功能了。
Programming is fundamentally theory building, not producing lines of code. We know this. This is why we make fun of business people who try to measure developer productivity in lines of code.
编程的本质是理论构建，而不是产出代码行。我们都懂这个道理。所以我们才会嘲笑那些试图用代码行数来衡量开发者生产力的商业人士。
When you vibe code, you are incurring tech debt as fast as the LLM can spit it out. Which is why vibe coding is perfect for prototypes and throwaway projects: It’s only legacy code if you have to maintain it!
当你进行 vibe code 时，你积累技术债的速度，和 LLM 输出代码的速度一样快。这也正是为什么 vibe code 完美适用于原型和一次性项目：只有当你需要维护它时，它才算是遗留代码！
I’ve happily vibe coded apps to:
我愉快地用 vibe code 写过一些应用，用来：
I don’t needed to continue developing those apps, so it hasn’t been a problem that I don’t understand their code. These apps are also very small, which means that I haven’t incurred that much debt if I need to jump in and read the code at some point. I was able to vibe code these apps way faster than I could’ve built them, and it was a blast.
我不需要持续开发这些应用，所以看不懂它们的代码也没什么问题。这些应用也很小，这意味着即便我将来需要回头读代码，欠下的债也不多。用 vibe code 的方式构建这些应用，比我自己动手快得多，而且乐趣无穷。
Vibe coding is on a spectrum of how much you understand the code. The more you understand, the less you are vibing.
Vibe code 存在于一个光谱之上，取决于你对代码的理解程度。你理解得越多，vibe 的成分就越少。
Simply by being an engineer and asking for a web app with a persistent database, you are already vibing less than than a non-programmer who asks for an “app” without understanding the distinction between a web app and a native app, or how persistent data storage works.
仅仅因为你是一名工程师，在要求一个带持久化数据库的 Web 应用时，你的 vibe 程度就已经低于一个非程序员了。那个非程序员可能只是想要一个“app”，却不明白 Web 应用和原生应用的差别，也不知道持久化数据存储是怎么回事。
The worst possible situation is to have a non-programmer vibe code a large project that they intend to maintain. This would be the equivalent of giving a credit card to a child without first explaining the concept of debt.
最糟糕的情况，莫过于让一个非程序员用 vibe code 的方式来做一个他们打算长期维护的大项目。这就好比把信用卡交给一个孩子，却没先向他解释什么是债务。
As you can imagine, the first phase is ecstatic. I can wave this little piece of plastic in stores and take whatever I want!
你可以想象，第一阶段是欣喜若狂的。我可以在商店里挥舞这张小塑料片，想要什么拿什么！
Which is a lot like AI can build anything now! Nobody needs to learn how to code! Look at what it just made for me!
这很像——AI 现在什么都能做了！谁都不用学编程了！快看它刚给我做的东西！
But if you wait a month, you’ll get the credit card bill. Did I actually need to buy all those things? How will I get myself out of this hole?
但等上一个月，信用卡账单就来了。我真的需要买那些东西吗？我该怎么把自己从这个坑里拉出来？
It’s similar for the vibe coder. My code broken. What do all these files and folders even do? How will I ever get this fixed? Can I get a refund for the $400 I spent vibe coding?
Vibe coder 的情况也类似。我的代码坏了。这些文件和文件夹到底是干什么的？我怎么才能修好它？我 vibe code 花掉的 400 美元能退款吗？
If you don’t understand the code, your only recourse is to ask AI to fix it for you, which is like paying off credit card debt with another credit card.
如果你看不懂代码，唯一的办法就是让 AI 帮你修复，这就像用一张信用卡去还另一张信用卡的债。
If you’re building something serious that you intend to maintain in 2025, Andrej has the right of it:
如果你在 2025 年要构建一个需要长期维护的严肃项目，Andrej 的看法是对的：
[Keep] a very tight leash on this new over-eager junior intern savant with encyclopedic knowledge of software, but who also bullshits you all the time, has an over-abundance of courage and shows little to no taste for good code. And emphasis on being slow, defensive, careful, paranoid, and on always taking the inline learning opportunity, not delegating.
— Andrej Karpathy, twitter
你得紧紧牵住这个新来的实习生，他过分积极，是个天才，拥有百科全书般的软件知识，但同时又总是对你胡说八道，勇气过剩，而且对好代码几乎毫无品味。重点是要慢下来，采取防御姿态，小心、多疑，并且总是抓住机会在实践中学习，而不是把任务全权委托出去。
— Andrej Karpathy, twitter
At Val Town, we’ve built AI into our product in dozens of ways. Townie is our AI asisstant that agentically reads & writes code, runs it, views the logs, and keeps iterating until it’s done.
在 Val Town，我们以几十种方式将 AI 融入了我们的产品。Townie 是我们的 AI 助手，它能像一个智能体一样读取和编写代码、运行代码、查看日志，并不断迭代直到任务完成。
Townie is an awesome tool for vibe coding. I heartily recommend it to folks who understand these tradeoffs. I use it to vibe code sometimes. Other times I keep in on a tight leash as it makes surgical edits to a project I care about. Both are fun and useful.
Townie 是一个很棒的 vibe code 工具。我衷心向那些理解其中利弊的人推荐它。我有时用它来 vibe code。其他时候，我会紧紧地控制它，让它对我关心的项目进行外科手术式的精确修改。这两种用法都很有趣，也很有用。
Coding with AI is changing so quickly that it’s hard to know what tomorrow will bring, but I’m confident that theory building will remain central to the activity of building complex software. Our technical expertise will still be relevant! And I’m optimistic that AI will continue to make programming better in suprising ways.
用 AI 编程这个领域变化太快，很难说未来会怎样，但我相信，理论构建依然会是构建复杂软件的核心活动。我们的技术专长仍然至关重要！而且我乐观地认为，AI 将继续以令人惊喜的方式让编程变得更好。
But if you know any non-programmers spending thousands of dollars vibe coding their billion dollar app idea today, please send them this post. Vibe coding is not going to get them where they want to go. They’re going to have to learn to use their human eyes to read the code 😱, and learn that sometimes it’s easier to start over with building a well-written code base from scratch than to fix a legacy one that nobody understands.
但是，如果你认识哪个非程序员，今天正花着成千上万美金，用 vibe code 的方式实现他们价值十亿美金的应用想法，请把这篇文章发给他们。Vibe code 并不能带他们到达想去的地方。他们将不得不学会用自己的肉眼去读代码 😱，并且要明白，有时候，从头开始构建一个编写良好的代码库，要比修复一个谁也看不懂的遗留系统更容易。
This essay is a distillation of a talk I gave last month, The Role of the Human Brain in Programming. Thanks to my fiance Emily for listening to me rant about these topics for months, and for filming my talk. Thanks Malte and Rippling for hosting the talk.
这篇文章是我上个月一次演讲的精炼版本，演讲题目是“编程中人脑的角色”。感谢我的未婚妻 Emily 几个月来听我喋喋不休地谈论这些话题，并为我拍摄了演讲视频。感谢 Malte 和 Rippling 主办了这次演讲。
Thanks Geoffrey Litt, Jimmy Koppel, Max McDonnell, Tom MacWright, Charmaine Lee, Brent Jackson, and Dan Shipper for feedback on this post. Thanks Simon Willison and Andrej Karpathy for being voices of reason amidst all the AI hype and naysayers.
感谢 Geoffrey Litt, Jimmy Koppel, Max McDonnell, Tom MacWright, Charmaine Lee, Brent Jackson, 和 Dan Shipper 对本文的反馈。感谢 Simon Willison 和 Andrej Karpathy 在所有 AI 的炒作和唱衰声中，成为理性的声音。
2025-08-01 08:00:02
原文： https://vercel.com/blog/ai-sdk-5
作者： Lars Grammel, Nico Albanese, Josh
译者： Gemini 2.5 Pro
为全栈 AI 应用引入类型安全的聊天和 Agentic 循环控制
AI SDK 每周下载量超过 200 万次，是 TypeScript 和 JavaScript 领域领先的开源 AI 应用工具包。它统一的 provider API 让你能使用任何语言模型，并能与主流 Web 框架进行强大集成。
“当客户问我该如何构建他们的 agent 时，我总是推荐 AI SDK。这个行业发展太快，一切都在不断变化。AI SDK 是我迄今为止见过的唯一完美的抽象。v5 延续了这一记录。你可以看出来，它是由一群对 Typescript 痴迷的人构建的。一切都恰到好处。”
Ben Hylak, raindrop.ai
用 TypeScript 构建应用，就是为 Web 构建应用。今天，我们发布 AI SDK 5，这是首个为 React、Svelte、Vue 和 Angular 提供完全类型化、高度可定制的聊天集成的 AI 框架。
AI SDK 5 引入了：
让我们深入了解细节。
在 AI SDK 5 中，我们从头开始重建了聊天功能。我们采用了开发者们喜爱的、用于处理 LLM 的强大原语，并在其之上构建了一个世界级的 UI 集成，为你的整个应用提供了端到端的类型安全。从服务器到客户端，每一份数据、每一次工具调用和元数据都是完全类型化的。这代表了 Web AI 库的下一次进化。
在之前版本的 AI SDK 中，开发者面临的一大挑战是管理不同类型的消息，以及弄清楚如何正确地持久化聊天记录。
这是我们重建 useChat 时的核心考量，并由此创建了两种截然不同的消息类型：
我们在 API 中明确了这一区别：
// 显式地将你的 UIMessages 转换为 ModelMessages
const uiMessages: UIMessage[] = [ /* ... */ ]
const modelMessages = convertToModelMessages(uiMessages);
const result = await streamText({
model: openai('gpt-4o'),
// 将富含信息的 UIMessage 格式转换为 ModelMessage 格式
// 这里可以用任何返回 ModelMessage[] 的函数替代
messages: modelMessages,
});
// 完成时：获取完整的 UIMessage 数组用于持久化
return result.toUIMessageStreamResponse({
originalMessages: uiMessages,
onFinish: ({ messages, responseMessage }) => {
// 保存完整的 UIMessage 数组——你的全部事实来源
saveChat({ chatId, messages });
// 或者只保存响应消息
saveMessage({ chatId, message: responseMessage })
},
});
这种 UI 消息和模型消息的分离，让持久化变得直截了当。onFinish 回调以你需要的格式提供了所有消息，无需任何显式转换。
想看用 AI SDK 实现消息持久化的完整示例，请查阅我们的聊天机器人持久化文档和持久化模板仓库。
使用 AI SDK 5，你可以定制 UIMessage，创建你自己的类型，其数据、工具和元数据的结构完全为你自己的应用量身打造。你可以将这个类型作为泛型参数传递给服务器端的 createUIMessageStream 和客户端的 useChat，从而实现全栈类型安全。
// 只需定义一次你的自定义消息类型
import { UIMessage } from 'ai';
// ... 导入你的工具和数据部分类型
export type MyUIMessage = UIMessage<MyMetadata, MyDataParts, MyTools>;
// 在客户端使用它
const { messages } = useChat<MyUIMessage>();
// 并在服务器端使用它
const stream = createUIMessageStream<MyUIMessage>(/* ... */);
要了解更多，请查阅 UIMessage 文档。
现代 AI 应用需要从服务器向客户端发送的，远不止是 LLM 的纯文本响应（例如，从状态更新到部分工具结果）。如果没有恰当的类型定义，流式传输自定义数据会把你的前端变成一团乱麻，到处都是运行时检查和类型断言。Data parts 通过提供一种一流的方式，从服务器向客户端流式传输任意、类型安全的数据，从而解决了这个问题，确保你的代码在应用增长时依然可维护。
在服务器端，你可以通过指定你的部分类型（例如 data-weather）然后传递数据来流式传输一个数据部分。你可以通过指定一个 ID 来更新同一个数据部分：
// 在服务器端，创建一个 UIMessage 流
// 用你的自定义消息类型为流指定类型
const stream = createUIMessageStream<MyUIMessage>({
async execute({ writer }) {
// 如果没有 LLM 调用，则手动写入开始步骤
const dataPartId = 'weather-1';
// 1. 发送初始的加载状态
writer.write({
type: 'data-weather', // 根据 MyUIMessage 进行类型检查
id: dataPartId,
data: { city: 'San Francisco', status: 'loading' },
});
// 2. 稍后，用最终结果更新同一个部分（相同 id）
writer.write({
type: 'data-weather',
id: dataPartId,
data: { city: 'San Francisco', weather: 'sunny', status: 'success' },
});
},
});
在客户端，你就可以渲染这个特定的部分了。当你使用相同的 ID 时，AI SDK 会用新的数据部分替换现有的：
// 在客户端，数据部分是完全类型化的
const { messages } = useChat<MyUIMessage>();
{
messages.map(message =>
message.parts.map((part, index) => {
switch (part.type) {
case 'data-weather':
return (
<div key={index}>
{/* TS 知道 part.data 有 city、status 和可选的 weather 属性 */}
{part.data.status === 'loading'
? `正在获取 ${part.data.city} 的天气...`
: `${part.data.city} 的天气是：${part.data.weather}`}
</div>
);
}
}),
);
}
还有些情况，你希望发送一些不想持久化的数据，只是用来传达状态更新，或者对 UI 做其他更改——这就是瞬时数据部分和 onData 钩子发挥作用的地方。
瞬时部分会被发送到客户端，但不会被添加到消息历史中。它们只能通过 onData useChat 处理器访问：
// 服务器端
writer.write({
type: 'data-notification',
data: { message: '处理中...', level: 'info' },
transient: true, // 不会被添加到消息历史中
});
// 客户端
const [notification, setNotification] = useState();
const { messages } = useChat({
onData: ({ data, type }) => {
if (type === 'data-notification') {
setNotification({ message: data.message, level: data.level });
}
},
});
要了解更多，请查阅 data parts 文档。
useChat 中的工具调用已经被重新设计，使用了特定于类型的部件标识符。现在每个工具都会创建一个像 tool-TOOLNAME 这样的部件类型，而不是使用通用的 tool-invocation 部件。
AI SDK 5 在此基础上进行了三项改进：
inputSchema）和输出（工具的 outputSchema）都获得端到端的类型安全。这些功能结合在一起，使你能够构建可维护的 UI，向用户精确展示整个工具执行过程中的情况——从初始调用、流式更新，到最终结果或错误：
// 在客户端，工具部分使用新结构完全类型化
const { messages } = useChat<MyUIMessage>();
{
messages.map(message => (
<>
{message.parts.map(part => {
switch (part.type) {
// 具有特定（`tool-${toolName}`）类型的静态工具
case 'tool-getWeather':
// 用于流式传输和错误处理的新状态
switch (part.state) {
case 'input-streaming':
// 自动流式传输的部分输入
return <div>正在获取 {part.input.location} 的天气...</div>;
case 'input-available':
return <div>正在获取 {part.input.location} 的天气...</div>;
case 'output-available':
return <div>天气是: {part.output}</div>;
case 'output-error':
// 带有信息的明确错误状态
return <div>错误: {part.errorText}</div>;
}
}
})}
</>
));
}
聊天功能还支持动态工具（下文有更多介绍）。动态工具（例如，来自 MCP 服务器的工具）在开发时是未知的，可以使用 dynamic-tool 部分来渲染：
const { messages } = useChat<MyUIMessage>();
{
messages.map(message => (
<>
{message.parts.map(part => {
switch (part.type) {
// 动态工具使用通用的 `dynamic-tool` 类型
case 'dynamic-tool':
return (
<div key={index}>
<h4>工具: {part.toolName}</h4>
{part.state === 'input-streaming' && (
<pre>{JSON.stringify(part.input, null, 2)}</pre>
)}
{part.state === 'output-available' && (
<pre>{JSON.stringify(part.output, null, 2)}</pre>
)}
{part.state === 'output-error' && (
<div>错误: {part.errorText}</div>
)}
</div>
);
}
})}
</>
));
}
要了解更多信息，请参阅下方的动态工具部分或查阅工具调用文档。
对于关于消息的信息，例如时间戳、模型 ID 或 token 数量，你现在可以为消息附加类型安全的元数据。你可以用它来附加与你的应用相关的元数据。
从服务器发送元数据：
// 在服务器端
const result = streamText({
/* ... */
});
return result.toUIMessageStreamResponse({
messageMetadata: ({ part }) => {
if (part.type === "start") {
return {
// 这个对象会根据你的元数据类型进行检查
model: "gpt-4o",
};
}
if (part.type === "finish") {
return {
model: part.response.modelId,
totalTokens: part.totalUsage.totalTokens,
};
}
},
});
然后你可以在客户端访问它：
// 在客户端
const { messages } = useChat<MyUIMessage>();
{
messages.map(message => (
<div key={message.id}>
{/* TS 知道 message.metadata 可能有 model 和 totalTokens */}
{message.metadata?.model && (
<span>模型: {message.metadata.model}</span>
)}
{message.metadata?.totalTokens && (
<span>{message.metadata.totalTokens} tokens</span>
)}
</div>
));
}
当你在消息生命周期的不同点更新元数据值时，客户端总是显示最新的值。
要了解更多信息，请查阅消息元数据文档。
新的 useChat hook 以模块化为核心进行了重新设计，支持三种强大的扩展模式：
fetch 的传输层换成自定义实现。你可以使用 WebSockets 进行实时通信，或者在没有后端的情况下直接连接到 LLM 提供商，这适用于纯客户端应用、浏览器扩展和注重隐私的场景。要了解更多，请查阅传输层文档。useChat 的所有强大功能。AbstractChat 类为任何框架构建你自己的聊天 hook。你可以创建自定义集成，同时保持与 AI SDK 生态系统的完全兼容。AI SDK 5 将重新设计的聊天体验带到了所有主流 Web 框架。Vue 和 Svelte 现在与 React 的功能完全对等，我们还引入了对 Angular 的支持。
现在所有框架都获得了同样强大的功能：满足你应用特定需求的自定义消息类型、用于流式传输任意类型化数据的 data parts、带有自动输入流的完全类型化工具调用，以及类型安全的消息元数据。无论你是在 React 中使用 useChat，还是使用 Vue 的组合式 API、Svelte 的 stores，或 Angular 的 signals，你都在使用同样强大的原语和端到端的类型安全。
要了解更多，请查看 Vue、Svelte 和 Angular 示例。
AI SDK 现在使用服务器发送事件 (SSE) 作为从服务器到客户端流式传输数据的标准。所有主流浏览器和环境都原生支持 SSE。这一变化使我们的流式协议更健壮，更容易用标准浏览器开发工具进行调试，也更易于在其上构建。
构建可靠的 AI agent 需要对执行流程和上下文进行精确控制。在 AI SDK 5 中，我们引入了一些原语，让你能完全控制 agent 的运行方式以及它们在每一步拥有的上下文和工具。
AI SDK 5 引入了三个用于构建 agent 的功能：
generateText 和 streamText。当你使用 generateText 和 streamText 发出请求时，默认只运行一步。stopWhen 参数将你的单个请求转换为一个工具调用循环，该循环会持续进行，直到：
stopWhen 条件被满足，或常见的停止条件包括：
stepCountIs(5) - 最多运行 5 步hasToolCall('finalAnswer') - 当某个特定工具被调用时停止import { openai } from "@ai-sdk/openai";
import { generateText, stepCountIs, hasToolCall } from "ai";
const result = await generateText({
model: openai("gpt-4o"),
tools: {
/* 你的工具 */
},
// 在 5 步后停止工具调用循环，或者
// 当 weather 工具被调用时
stopWhen: [stepCountIs(5), hasToolCall("weather")],
});
stopWhen 让你的 agent 持续运行，而 prepareStep 则让你能控制每一步的设置。
在每一步执行前，你可以调整：
const result = await streamText({
model: openai('gpt-4o'),
messages: convertToModelMessages(messages),
tools: {
/* 你的工具 */
},
prepareStep: async ({ stepNumber, messages }) => {
if (stepNumber === 0) {
return {
// 第一步使用不同的模型
model: openai('gpt-4o-mini'),
// 强制选择一个特定工具
toolChoice: { type: 'tool', toolName: 'analyzeIntent' },
};
}
// 对于较长的对话，压缩上下文
if (messages.length > 10) {
return {
// 使用一个具有更大上下文窗口的模型
model: openai('gpt-4.1'),
messages: messages.slice(-10),
};
}
},
});
Agent 类提供了一种面向对象的方法来构建 agent。它不增加新功能——所有你能用 Agent 做的事，都可以用 generateText 或 streamText 完成。它的作用是让你能够封装你的 agent 配置和执行过程：
import { openai } from "@ai-sdk/openai";
import { Experimental_Agent as Agent, stepCountIs } from "ai";
const codingAgent = new Agent({
model: openai("gpt-4o"),
system: "你是一个编程 agent。你专注于 Next.js 和 TypeScript。",
stopWhen: stepCountIs(10),
tools: {
/* 你的工具 */
},
});
// 调用 `generateText`
const result = codingAgent.generate({
prompt: "构建一个 AI 编程 agent。",
});
// 调用 `streamText`
const result = codingAgent.stream({
prompt: "构建一个 AI 编程 agent。",
});
AI SDK 5 将我们统一的 provider 抽象扩展到了语音领域。就像我们对文本和图像生成所做的那样，我们为语音生成和转录都带来了同样一致、类型安全的接口。无论你使用 OpenAI、ElevenLabs 还是 DeepGram，你都使用同样熟悉的 API 模式，并且只需修改一行代码就能切换 provider。
import {
experimental_generateSpeech as generateSpeech,
experimental_transcribe as transcribe,
} from 'ai';
import { openai } from '@ai-sdk/openai';
// 文本转语音：从文本生成音频
const { audio } = await generateSpeech({
model: openai.speech('tts-1'),
text: '你好，世界！',
voice: 'alloy',
});
// 语音转文本：将音频转录为文本
const { text, segments } = await transcribe({
model: openai.transcription('whisper-1'),
audio: await readFile('audio.mp3'),
});
AI SDK 5 通过全面的改进增强了工具能力，包括动态工具、provider 执行的函数、生命周期钩子以及贯穿整个工具调用过程的类型安全。
在 AI SDK 5 中，我们通过重命名关键概念，使我们的工具定义接口更紧密地与模型上下文协议 (MCP) 规范保持一致：
AI SDK 5 还引入了一个可选的 outputSchema 属性，它与 MCP 规范保持一致，并为客户端工具调用提供了类型安全。
这些变化使工具定义更直观，并与新兴的行业标准保持一致：
// 之前 (v4)
const weatherTool = tool({
name: 'getWeather',
parameters: z.object({ location: z.string() }),
execute: async ({ location }) => {
return `在 ${location} 的天气：晴，72°F`;
}
});
// 之后 (v5)
const weatherTool = tool({
description: '获取一个地点的天气',
inputSchema: z.object({ location: z.string() }),
outputSchema: z.string(), // v5 新增 (可选)
execute: async ({ location }) => {
return `在 ${location} 的天气：晴，72°F`;
}
});
AI 应用常常需要处理一些无法预先知道的工具：
动态工具和 dynamicTool 函数使得工具的输入输出类型可以在运行时而非开发时确定。动态工具与静态工具是分开的，从而同时为你提供类型安全和灵活性。
import { dynamicTool } from 'ai';
import { z } from 'zod';
const customDynamicTool = dynamicTool({
description: '执行一个自定义的用户定义函数',
inputSchema: z.object({}),
// input 的类型是 'unknown'
execute: async input => {
const { action, parameters } = input as any;
// 执行你的动态逻辑
return {
result: `用 ${JSON.stringify(parameters)} 执行了 ${action}`,
};
},
});
const weatherTool = tool({ /* ... */ })
const result = await generateText({
model: 'openai/gpt-4o',
tools: {
// 具有已知类型的静态工具
weatherTool,
// 动态工具
customDynamicTool,
},
onStepFinish: ({ toolCalls, toolResults }) => {
// 类型安全的迭代
for (const toolCall of toolCalls) {
if (toolCall.dynamic) {
// 动态工具：input 是 'unknown'
console.log('动态:', toolCall.toolName, toolCall.input);
continue;
}
// 静态工具：完整的类型推断
switch (toolCall.toolName) {
case 'weather':
console.log(toolCall.input.location); // 类型为 string
break;
}
}
},
});
要了解更多信息，请查阅动态工具文档。
许多 AI provider 都引入了由 provider 执行的工具。当这些工具被调用时，provider 会执行该工具并将工具结果作为响应的一部分返回（例如 OpenAI 的网页搜索和文件搜索，xAI 的网页搜索等）。
AI SDK 现在原生支持由 provider 执行的工具，会自动将结果附加到消息历史中，无需任何额外配置。
import { openai } from '@ai-sdk/openai';
import { generateText } from 'ai';
const result = await generateText({
model: openai.responses('gpt-4o-mini'),
tools: {
web_search_preview: openai.tools.webSearchPreview({}),
},
// ...
});
AI SDK 5 引入了精细的工具生命周期钩子（onInputStart、onInputDelta、onInputAvailable），可以与数据部分配合使用，将与输入相关的信息（例如状态更新）发送回客户端。
const weatherTool = tool({
description: 'Get the weather for a given city',
inputSchema: z.object({ city: z.string() }),
onInputStart: ({ toolCallId }) => {
console.log('Tool input streaming started:', toolCallId);
},
onInputDelta: ({ inputTextDelta, toolCallId }) => {
console.log('Tool input delta:', inputTextDelta);
},
onInputAvailable: ({ input, toolCallId }) => {
console.log('Tool input ready:', input);
},
execute: async ({ city }) => {
return `Weather in ${city}: sunny, 72°F`;
},
});
AI SDK 5 增加了对工具级 provider 选项的支持。例如，你可以用它来为多步 agent 缓存 Anthropic 的工具定义，从而减少 token 使用量、处理时间和成本：
const result = await generateText({
model: anthropic('claude-3-5-sonnet-20240620'),
tools: {
cityAttractions: tool({
inputSchema: z.object({ city: z.string() }),
// 将特定于 provider 的选项应用于单个工具
providerOptions: {
anthropic: {
cacheControl: { type: 'ephemeral' },
},
},
execute: async ({ city }) => {
// 实现
},
}),
},
});
AI SDK 的基础是规范层，它标准化了不同的语言模型、嵌入模型等如何接入像 streamText 这样的函数。规范层是 AI SDK provider 架构的基石。
在 AI SDK 5 中，我们已将所有规范更新到 V2。这些新规范包含了底层 API 能力的变化（如 provider 执行的工具），并具备了像 provider 元数据和选项这样的可扩展机制。它们将成为 AI SDK 5 及未来的基础。
要了解更多关于 V2 规范的信息，请访问自定义 provider 文档。
AI SDK 5 包含一个全局 provider 功能，让你仅用一个普通的模型 ID 字符串就能指定模型：
import { streamText } from 'ai';
const result = await streamText({
model: 'openai/gpt-4o', // Uses the global provider (defaults to AI Gateway)
prompt: 'Invent a new holiday and describe its traditions.',
});
默认情况下，全局 provider 设置为 Vercel AI Gateway。
你可以设置自己偏好的全局 provider：
import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
// 在启动时初始化一次：
globalThis.AI_SDK_DEFAULT_PROVIDER = openai;
// 在你代码库的其他地方：
const result = streamText({
model: 'gpt-4o', // 使用 OpenAI provider，无需前缀
prompt: '发明一个新的节日并描述它的传统。',
});
这简化了 provider 的使用，让你在切换 provider 时更容易，而无需在整个代码库中更改模型引用。
当你需要完全控制，或想在官方支持前实现新功能时，AI SDK 提供了对原始请求和响应数据的完整访问。这个“逃生通道”对于调试、实现特定于 provider 的功能或处理边缘情况来说，非常宝贵。
使用 AI SDK 5，你可以通过流式函数访问从 provider 接收到的原始数据块：
import { openai } from "@ai-sdk/openai";
import { streamText } from "ai";
const result = streamText({
model: openai("gpt-4o-mini"),
prompt: "发明一个新的节日并描述它的传统。",
includeRawChunks: true,
});
// 通过 fullStream 访问原始数据块
for await (const part of result.fullStream) {
if (part.type === "raw") {
// 访问特定于 provider 的数据结构
// 例如，OpenAI 的 choices、usage 等
console.log("原始数据块:", part.rawValue);
}
}
你还可以访问发送给 provider 的确切请求和收到的完整响应：
const result = await generateText({
model: openai("gpt-4o"),
prompt: "写一首关于调试的俳句",
});
// 访问发送给 provider 的原始请求体
// 查看确切的提示格式、参数等
console.log("请求:", result.request.body);
// 访问来自 provider 的原始响应体
// 包含元数据的完整 provider 响应
console.log("响应:", result.response.body);
AI SDK 5 支持 Zod 4。你可以在所有启用验证的 API 中，使用 Zod 3 或新的 Zod 4 mini schema 来进行输入和输出验证。
我们建议新项目使用 Zod 4。请遵循 Zod v4 文档上的建议。
AI SDK 5 包含一些破坏性变更，移除了已弃用的 API。我们通过自动化的迁移工具简化了迁移过程。你可以运行我们的自动化 codemod 来处理部分变更。
npx @ai-sdk/codemod upgrade
要详细了解所有变更以及可能需要的手动步骤，请参阅我们的 AI SDK 5 迁移指南。该指南包含分步说明和示例，以确保平稳更新。
有了重新设计的聊天、agentic 控制和新的规范，现在是开始使用 AI SDK 构建 AI 应用的最佳时机。
2025-08-01 08:00:01
原文： https://om.co/2025/07/30/decoding-zucks-superintelligence-memo/
作者： Om Malik
译者： Gemini 2.5 Pro
2025年7月30日
Mark Zuckerberg, the chief executive of Meta (aka the company formerly known as Facebook), has published a memorandum about “superintelligence” and what it will mean not only for his company but for the world and society at large. It has had a wide variety of reactions ranging from delight to derision. As is normally the case, every single time I come across a memo such as one published by any chief executive (or a founder), I ask myself a few simple questions:
Meta（也就是以前的 Facebook）的 CEO 马克·扎克伯格，发表了一份关于“superintelligence”（超级智能）的备忘录，阐述了它不仅对他的公司，也对整个世界和社会意味着什么。这份备忘录引发了各种各样的反应，从欣喜到嘲讽，不一而足。通常，每当我读到任何 CEO（或创始人）发布的这类备忘录时，我都会问自己几个简单的问题：
I am in the unique position to dig into Zuck’s words — I was one of the earliest reporters to write about a nascent and burgeoning Facebook (when it was called TheFacebook) and was a campus-only phenomenon. I have followed Facebook (now Meta) long enough to distinguish between what the company says and what it really means.
我有一个独特的视角来解读扎克伯格的言辞——当 Facebook 还叫 TheFacebook，还只是一个校园现象时，我就是最早报道这个新生事物的记者之一。我关注 Facebook（现在的 Meta）已经很久了，足以分辨出这家公司所说的，和它真正想表达的。
And over almost two decades of following the company, I have come to a conclusion that Zuck is one of the best “chief executives” to come out of Silicon Valley. And this is coming from someone who has no qualms about viewing him with moral disdain. In the past, I have referred to the company as “amoral” for a reason. Not only is Zuckerberg paranoid and Machiavellian, he is also willing to go to any extreme to survive and thrive.
在近二十年对这家公司的跟踪中，我得出一个结论：扎克伯格是硅谷最顶尖的“CEO”之一。说这话的我，是一个在道德上对他毫不掩饰地鄙夷的人。过去，我曾称这家公司为“非道德”（amoral），这是有原因的。扎克伯格不仅偏执多疑，信奉马基雅维利主义，而且为了生存和发展，他愿意不择手段。
The newest memo is very much on point for Zuck and in keeping with every single time his company has faced an existential crisis.
这份最新的备忘录非常符合扎克伯格的风格，也与他公司每次面临生存危机时的做法如出一辙。
***
The formula in all these memos is exactly the same:
所有这些备忘录的套路都完全一样：
There is even a pattern to the context. Each memo coincides with major competitive threats:
甚至连发布的背景都有一种模式。每一份备忘录都恰逢重大的竞争威胁：
Compared to all founders and CEOs, Zuck does seem to have a great understanding of when he needs to bet the farm on an idea and a behavioral shift. Each time he does that, it is because he sees very clearly Facebook is at the end of the product life and the only real value in the company is the attention of his audience. If that attention declines, it takes away the ability to really extend the company’s life into the next cycle.
与所有创始人和 CEO 相比，扎克伯格似乎对何时需要押上全部赌注去抓住一个新想法和行为转变，有着深刻的理解。他每次这么做，都是因为他清楚地看到，Facebook 正处于产品生命周期的末端，公司唯一真正的价值就是用户的注意力。如果这种注意力下降，公司就失去了将生命延续到下一个周期的能力。
Let’s look back at the company’s history.
让我们回顾一下公司的历史。
In 2012, when Zuck saw “the stunning, hard shift of users from desktop to mobile,” Facebook went into “lockdown” mode to shift from desktop to mobile. Zuck was willing to sacrifice short-term profits and rebuild the entire platform.
2012年，当扎克伯格看到“用户从桌面端到移动端惊人而决绝的转变”时，Facebook 进入了“封锁”模式，全力转向移动。扎克伯格愿意牺牲短期利润来重建整个平台。
A few years later, when Instagram and WhatsApp threatened to undermine its social platforms with visual social networks and comms-first network effects, it went ahead and bought those two companies.
几年后，当 Instagram 和 WhatsApp 以视觉社交网络和通信优先的网络效应威胁到其社交平台时，它果断收购了这两家公司。
In 2021, when the Facebook brand was at its nadir, he came up with the Metaverse strategy and renamed the company Meta. An expensive way to reinvent a tarnished brand, but nonetheless, it allowed him to talk about the future instead of being constantly on the defensive. Giving Zuck the benefit of the doubt, I am okay with companies with insane profits experimenting with insane ideas. I mean, unless we had that approach, we wouldn’t have Waymo.
2021年，当 Facebook 的品牌声誉跌至谷底时，他提出了 Metaverse 战略，并将公司更名为 Meta。这是一个重塑受损品牌的昂贵方式，但它确实让他能够谈论未来，而不是总是处于守势。就算我们姑且相信扎克伯格，对于那些利润高得离谱的公司去尝试一些疯狂的想法，我也可以接受。我的意思是，如果没有这种做法，我们就不会有 Waymo。
And now Super Intelligence. I mean, what’s $65 billion if you can reinvent society itself?
现在是超级智能。我的意思是，如果你能重塑整个社会，650亿美元又算得了什么？
Most CEOs defend their existing moats. Zuckerberg systematically abandons them. He understands that Facebook’s real asset isn’t the blue app. Instead, it is the graph of human attention and relationships. Each pivot is about preserving that graph while migrating it to new interfaces.
大多数 CEO 会捍卫自己现有的护城河。而扎克伯格则系统性地抛弃它们。他明白 Facebook 真正的资产不是那个蓝色的 App，而是人类注意力和关系的总和图谱。每一次战略转型都是为了在将这个图谱迁移到新界面的同时，保护好它。
When viewed through that framework, here is how I have attempted to decode Zuckerberg’s 625-word corporate speak.
通过这个框架来看，我是这样尝试解读扎克伯格那625字的商业辞令的。
There is about 25 percent genuine strategic content, the rest is aspirational marketing and corporate positioning. For instance, infrastructure commitments and device strategy show the seriousness of the effort. However, claims about superintelligence being “in sight” are inflated for competitive reasons.
其中大约有25%是真正的战略内容，其余的都是愿景式营销和公司定位。例如，对基础设施和设备战略的承诺显示了他们是认真的。然而，声称超级智能“已近在眼前”则是出于竞争目的的夸大其词。
More than anything, this is a positioning document in the AI arms race. By using “super intelligence” as a marketing phrase, Zuck is making his efforts feel superior to the mere “Artificial Intelligence” of OpenAI, Anthropic, and Google. It is him saying we will empower individuals, a remarkably positive message compared to the “AI will replace jobs” narrative that competitors like OpenAI have been painted with.
最重要的是，这是一份在 AI 军备竞赛中的定位文件。通过使用“super intelligence”（超级智能）这个营销术语，扎克伯格让自己的努力听起来比 OpenAI、Anthropic 和 Google 的“Artificial Intelligence”（人工智能）更高级。他想说的是，我们将赋能个人——与 OpenAI 等竞争对手被贴上的“AI 将取代工作”的负面论调相比，这是一个非常积极的信息。
Zuck has competitive anxiety. By repeatedly talking about being “distinct from others in the industry” he is tipping his hand. He is worried that Meta is being seen as a follower rather than leader. Young people are flocking to ChatGPT. Programmers are flocking to Claude Code.
扎克伯格有竞争焦虑。他反复强调自己“与业内其他人不同”，这暴露了他的底牌。他担心 Meta 被视为追随者而非领导者。年轻人正涌向 ChatGPT，程序员正涌向 Claude Code。
What does Meta AI do? Bupkiss. And Zuck knows that very well. You don’t do a company makeover if things are working well.
Meta AI 能做什么？什么也做不了。扎克伯格对此心知肚明。如果一切顺利，你根本不需要对公司进行彻底改造。
He is also trying to frame his competitors as un-American. He paints centralized AI as creating a “dole” system. Is he trying to appeal to American individualist values while making competitors sound authoritarian and dystopian? By talking about the transition from farmers to modern times, he says he knows how to free humanity to be bigger than itself.
他还在试图将竞争对手描绘成“非美国”的。他把中心化的 AI 描绘成一种创造“救济金”的系统。他是不是想通过迎合美国的个人主义价值观，同时让竞争对手听起来像专制和反乌托邦的？通过谈论从农民到现代的转变，他想表达的是，他知道如何解放人性，让其变得更伟大。
It would be easier to believe him if his three vectors of influence — Instagram, WhatsApp, and increasingly aging Facebook — were anything more than vehicles for an advertising-based attention economy.
如果他的三大影响力载体——Instagram、WhatsApp 和日益老化的 Facebook——不仅仅是基于广告的注意力经济的工具，那么相信他会更容易一些。
With a broader AI context, despite some notable successes, Meta’s efforts to spearhead open-source AI have been unsuccessful in positioning it ahead of rivals such as OpenAI. I would argue that they have been so unsuccessful that they have inspired others, particularly from China, to aggressively pursue the same open-source path and take the mantle of leadership away from Meta. And they are doing it cheaper, faster, and some experts think, better.
在更广阔的 AI 背景下，尽管取得了一些显著的成功，但 Meta 引领开源 AI 的努力并未能使其在与 OpenAI 等对手的竞争中占据领先地位。我认为，这些努力是如此不成功，以至于激励了其他国家，特别是来自中国的公司，积极走上同样的开源道路，并从 Meta 手中夺走领导地位。而且他们做得更便宜、更快，一些专家甚至认为，做得更好。
A less cynical way of looking at Meta’s open source efforts is that LLaMA succeeded too well at being open source. It created a vibrant ecosystem but struggled to capture value from it. The open source AI model presents inherent business model challenges for the company.
用一种不那么愤世嫉俗的眼光来看待 Meta 的开源努力，那就是 LLaMA 作为开源项目太成功了。它创造了一个充满活力的生态系统，却难以从中获取价值。开源 AI 模型给公司带来了固有的商业模式挑战。
Meanwhile, OpenAI and others were building billion-dollar businesses with closed models. Meta has to somehow justify that $65 billion spending on “AI,” especially to the Wall Street community. They’re playing catch-up after ChatGPT. Anyone who has used either ChatGPT, Claude, or Gemini knows that Meta AI is lacking.
与此同时，OpenAI 和其他公司正在用闭源模型建立价值数十亿美元的业务。Meta 必须以某种方式向华尔街证明，那 650 亿美元花在“AI”上是值得的。他们在 ChatGPT 之后一直处于追赶状态。任何用过 ChatGPT、Claude 或 Gemini 的人都知道，Meta AI 差得远。
Meta’s AI efforts, despite some notable wins with LLaMA, are not enough. And Zuck knows it. If this was not the case, he wouldn’t be dangling hundreds of millions in front of AI researchers. His decision to buy Scale AI was as much for Meta as it was for delaying the efforts of its AI rivals.
Meta 在 AI 上的努力，尽管 LLaMA 取得了一些显著的胜利，但还远远不够。扎克伯格也知道这一点。如果不是这样，他就不会在 AI 研究人员面前晃悠着数亿美元的支票。他决定收购 Scale AI，既是为了 Meta 自身，也是为了拖延 AI 对手们的进程。
With that said, in the new post-ChatGPT era, attention and relationships are redefined. On the positive side, since Meta has the richest dataset of human preferences, relationships, and behavioral patterns, it can help craft a “personal intelligence” system with an individual’s social context. AI assistants require unprecedented personal access, and Meta has that. There is a reason why Zuck was going on and on about “personal superintelligence.”
话虽如此，在后 ChatGPT 时代，注意力和关系被重新定义了。从积极的一面看，由于 Meta 拥有关于人类偏好、关系和行为模式最丰富的数据集，它可以帮助打造一个融入个人社交背景的“个人智能”系统。AI 助手需要前所未有的个人数据访问权限，而 Meta 拥有这些。这就是为什么扎克伯格喋喋不休地谈论“个人超级智能”的原因。
The memo’s emphasis on “personal empowerment” suggests Zuckerberg understands this distinction. However, in this new AI-first internet era, AI is your attention manager. So how does Meta translate its past business model of “capture and monetize attention” to “optimize and enhance attention?” The attention economy business model of “endless scroll for ad revenue” fundamentally breaks in the new AI reality.
备忘录对“个人赋能”的强调表明，扎克伯格理解这种区别。然而，在这个新的 AI 优先的互联网时代，AI 是你的注意力管理者。那么，Meta 如何将其过去“捕获并变现注意力”的商业模式，转变为“优化并提升注意力”呢？那种“通过无限滚动换取广告收入”的注意力经济模式，在新的 AI 现实中，从根本上被打破了。
What’s interesting is what is omitted in the memo. All the talk about personal AI assistants is in sharp contrast to the lack of any conversation about socially-aware AI. I mean, if anything, that has been Meta’s historical competitive advantage.
有趣的是备忘录中省略了什么。所有关于个人 AI 助手的讨论，与对社交感知 AI 的只字不提形成了鲜明对比。我的意思是，如果说有什么是 Meta 的历史竞争优势，那恰恰就是这个。
I am not sure why the relationship aspect is intentionally understated. Does this reflect concerns about privacy backlash or regulatory scrutiny? Or does it portend a society that is going to be increasingly singular, interacting with machines rather than humans?
我不确定为什么关系这个方面被有意地淡化了。这是否反映了对隐私反弹或监管审查的担忧？或者，这是否预示着一个日益孤立的社会，人们更多地与机器而不是与人互动？
So what do I think about this memo, and all the efforts of Meta? I remain skeptical of his ability to invent a new future for his company. In the past, he has been able to buy, snoop, or steal other people’s ideas. It has been hard for him and his company to actually develop a new market opportunity.
那么，我对这份备忘录以及 Meta 的所有努力有何看法？我仍然对他为公司开创一个新未来的能力持怀疑态度。在过去，他能够购买、窥探或窃取别人的想法。但对他和他的公司来说，真正开发一个新的市场机会一直很难。
Zuckerberg also tends to overpromise on timelines and underestimate execution challenges. The metaverse is strugglingafter over $50 billion in investments. This “superintelligence” memo has the same breathless, reality-distorting tone. It would be interesting to see how Meta can avoid the metaverse’s fate of burning massive resources while competitors (Chinese models) deliver equivalent value far more efficiently.
扎克伯格也倾向于在时间表上过度承诺，并低估执行的挑战。在投入超过500亿美元后，Metaverse 仍在挣扎。这份“超级智能”备忘录带有同样令人窒息、扭曲现实的腔调。看看 Meta 如何避免重蹈 Metaverse 的覆辙——在竞争对手（中国模型）以远高于其的效率交付同等价值的同时，自己却在燃烧巨额资源——将会很有趣。
The memo reads like someone trying to convince shareholders that this time the moonshot will work. However, I have learned not to underestimate Zuckerberg and his CEO skills.
这份备忘录读起来，就像有人在拼命说服股东，这次的“登月计划”一定能成功。但是，我早已学会，永远不要低估扎克伯格和他的 CEO 技能。
July 30, 2025. San Francisco.
2025-08-01 08:00:00
原文： https://www.meta.com/superintelligence/
作者： Mark Zuckerberg
译者： Gemini 2.5 Pro
Over the last few months we have begun to see glimpses of our AI systems improving themselves. The improvement is slow for now, but undeniable. Developing superintelligence is now in sight.
在过去的几个月里，我们开始看到我们的 AI 系统进行自我提升的迹象。虽然目前进展缓慢，但趋势毋庸置疑。开发超级智能（superintelligence）已近在眼前。
It seems clear that in the coming years, AI will improve all our existing systems and enable the creation and discovery of new things that aren’t imaginable today. But it is an open question what we will direct superintelligence towards.
显而易见，在未来几年，AI 将会改进我们所有现有的系统，并促成今天无法想象的新事物的创造和发现。但我们将引导超级智能走向何方，这仍是一个悬而未决的问题。
In some ways this will be a new era for humanity, but in others it’s just a continuation of historical trends. As recently as 200 years ago, 90% of people were farmers growing food to survive. Advances in technology have steadily freed much of humanity to focus less on subsistence and more on the pursuits we choose. At each step, people have used our newfound productivity to achieve more than was previously possible, pushing the frontiers of science and health, as well as spending more time on creativity, culture, relationships, and enjoying life.
从某些方面说，这将是人类的一个新纪元，但从另一些方面看，这只是历史趋势的延续。就在 200 年前，90% 的人还是为了生存而种地的农民。技术的进步稳步地将大部分人从生存的重负中解放出来，让我们能更多地专注于自己选择的事业。每一步，人们都利用新获得的生产力去实现比以往更多的可能，推动科学和健康的边界，同时也花更多时间在创造、文化、人际关系和享受生活上。
I am extremely optimistic that superintelligence will help humanity accelerate our pace of progress. But perhaps even more important is that superintelligence has the potential to begin a new era of personal empowerment where people will have greater agency to improve the world in the directions they choose.
我非常乐观，相信超级智能将帮助人类加速进步的步伐。但也许更重要的是，超级智能有潜力开启一个个人赋能的新时代，人们将拥有更大的自主权，朝着他们自己选择的方向去改善世界。
As profound as the abundance produced by AI may one day be, an even more meaningful impact on our lives will likely come from everyone having a personal superintelligence that helps you achieve your goals, create what you want to see in the world, experience any adventure, be a better friend to those you care about, and grow to become the person you aspire to be.
AI 带来的富足有朝一日可能会非常深刻，但对我们生活意义更为深远的影响，可能来自于每个人都拥有一个个人超级智能，它能帮助你实现目标，创造你想看到的世界，体验任何冒险，成为你在乎的人的更好朋友，并成长为你渴望成为的人。
Meta’s vision is to bring personal superintelligence to everyone. We believe in putting this power in people’s hands to direct it towards what they value in their own lives.
Meta 的愿景是将个人超级智能带给每一个人。我们相信应该将这种力量交到人们手中，让他们引导它去实现自己生活中所珍视的价值。
This is distinct from others in the industry who believe superintelligence should be directed centrally towards automating all valuable work, and then humanity will live on a dole of its output. At Meta, we believe that people pursuing their individual aspirations is how we have always made progress expanding prosperity, science, health, and culture. This will be increasingly important in the future as well.
这与业内其他一些观点不同，他们认为超级智能应该由中心化机构主导，用于自动化所有有价值的工作，然后人类靠其产出的福利过活。在 Meta，我们相信，人们追求个人理想，一直是我们推动繁荣、科学、健康和文化进步的方式。这一点在未来也会愈发重要。
The intersection of technology and how people live is Meta’s focus, and this will only become more important in the future.
技术与人们生活方式的交汇点是 Meta 的焦点，这一点在未来只会变得更加重要。
If trends continue, then you’d expect people to spend less time in productivity software, and more time creating and connecting. Personal superintelligence that knows us deeply, understands our goals, and can help us achieve them will be by far the most useful. Personal devices like glasses that understand our context because they can see what we see, hear what we hear, and interact with us throughout the day will become our primary computing devices.
如果趋势延续，你可以预见人们会花更少时间在生产力软件上，而花更多时间去创造和连接。一个深度了解我们、理解我们目标并能帮助我们实现的个人超级智能，将是迄今为止最有用的工具。像眼镜这样的个人设备，因为能看到我们所见、听到我们所闻，并与我们全天互动，所以能理解我们的处境，它们将成为我们的主要计算设备。
We believe the benefits of superintelligence should be shared with the world as broadly as possible. That said, superintelligence will raise novel safety concerns. We’ll need to be rigorous about mitigating these risks and careful about what we choose to open source. Still, we believe that building a free society requires that we aim to empower people as much as possible.
我们相信，超级智能的益处应该尽可能广泛地与世界分享。话虽如此，超级智能也会带来新的安全问题。我们需要严格地去减轻这些风险，并对我们选择 open source 的内容保持谨慎。尽管如此，我们相信，建立一个自由的社会，要求我们尽可能地去赋能于人。
The rest of this decade seems likely to be the decisive period for determining the path this technology will take, and whether superintelligence will be a tool for personal empowerment or a force focused on replacing large swaths of society.
这个十年的剩余时间，很可能将是决定这项技术发展道路的关键时期，也将决定超级智能究竟是成为个人赋能的工具，还是一股专注于取代社会大部分岗位的力量。
Meta believes strongly in building personal superintelligence that empowers everyone. We have the resources and the expertise to build the massive infrastructure required, and the capability and will to deliver new technology to billions of people across our products. I’m excited to focus Meta’s efforts towards building this future.
Meta 坚信要构建赋能于每个人的个人超级智能。我们拥有构建所需大规模基础设施的资源和专业知识，也有能力和意愿通过我们的产品将新技术带给数十亿人。我很高兴能将 Meta 的精力集中在构建这个未来上。
– Mark
July 30, 2025
