AI Agent

原文标题：Getting started with loops。本文基于 ClaudeDevs 在 X 发布的文章，完全由有道龙虾自动翻译、整理和发布。 现在有很多人在讨论“设计循环”，而不是直接给你的编码 Agent 写提示词。如果你花点时间在 X 上试图弄清楚循环到底是什么，你会看到很多不同的答案。 在 Claude Code 团队里，我们把“循环”定义为：Agent 重复执行工作周期，直到满足停止条件。我们会根据以下几个维度，把循环分成几类： 它们是如何被触发的 它们是如何停止的 使用了哪种 Claude Code 原语 每种循环最适合哪类任务 我们会介绍主要的循环类型、每种类型适合在什么时候使用，以及如何在管理 token 用量的同时保持代码质量。并不是所有任务都需要复杂循环；先从最简单的方案开始，只在合适的时候选择性地使用这些模式。 基于回合的循环 触发方式： 用户提示词。 停止条件： Claude 判断自己已经完成任务，或者需要更多上下文。 最适合用于： 不属于固定流程或日程安排的较短任务。 用量管理方式： 写更具体的提示词，并通过 skills 改进验证流程，以减少回合数。 你发送的每一个提示词，都会启动一个由你手动指挥每一轮的循环。Claude 会收集上下文、采取行动、检查自己的工作，如果需要就重复，然后再回复。我们称之为 agentic loop（智能体循环）。 例如，你让 Claude 创建一个点赞按钮。它会读取你的代码、进行修改、运行测试，然后交回一个它认为能工作的结果。接着你手动检查这项工作，再写下一个提示词。 你可以把自己的手动验证步骤编码成一个 SKILL.md，从而改进验证环节，让 Claude 能端到端地检查更多自己的工作。这个 skill 应该包含工具或连接器，让 Claude 能够看到、测量或交互结果。检查越量化，Claude 就越容易自我验证。 例如，你可以在 SKILL.md 文件里指定： --- name: verify-frontend-change description: Verify any UI change end-to-end before declaring it done....

这是 OpenAI 联合创始人 Andrej Karpathy 在一次 AI Agent 主题分享会上的演讲。本文由 LobsterAI 基于演讲视频音频转写、翻译并整理发布。 引言：当年的锤子，敲不开今天的门 几年前，在 OpenAI 有一个并不算轰动、却很有预言意味的项目，叫 World of Bits。 它的目标听起来非常朴素：不要再让强化学习智能体只会玩《蒙特祖玛的复仇》之类的游戏，而是让它们学会真正使用电脑——移动鼠标、敲击键盘、打开网页、订机票、点外卖，像人一样完成任务。 这当然是一个诱人的方向。毕竟，如果 AI 不能进入真实的数字世界，不能操作软件、调用工具、完成流程，它离“有用”始终差一步。 但当时的结果并不理想。演讲者回忆说，那篇论文“不是一篇特别了不起的论文”，因为彼时大家手里唯一像样的锤子，就是强化学习。于是研究者们做了非常简单的网页，让智能体在网页上乱点按钮、乱敲键盘，试图“误打误撞”获得更高奖励。 结果也很显然：它没有真正工作起来。 不是想法错了，而是时代没到。技术栈不对，工具不够成熟，问题也还没有被正确地表述出来。 有趣的是，几年之后，AI Agent 又回来了。但这一次，主角已经不是强化学习，而是语言模型。 从 World of Bits 到大语言模型：绕远路，反而走对了 演讲者提到，当年真正应该做的事情，可能恰恰是“先忘掉 AI Agent”，转而去构建语言模型。 这句话放在今天看，很有历史的反讽意味。 当年大家试图直接训练一个会操作电脑的智能体，结果发现智能体缺少理解、规划、泛化和语言能力。它能点击，却不知道自己为什么点击；它能尝试，却无法真正理解任务意图。 于是行业暂时离开了 Agent，转向 Transformer、预训练、大规模语料和语言建模。几年之后，大语言模型具备了理解指令、生成计划、调用工具、阅读网页、写代码和反思错误的能力。AI Agent 才又重新成为可能。 这也是演讲中最有意思的观察之一： “五年之后我们又回到了这里。AI Agent 看起来又酷起来了。但工具已经完全变了。” 今天做 Agent 的人，大多并不直接使用强化学习。很多创业者、黑客和研究者，构建的是基于 LLM 的工作流、工具调用系统、浏览器代理、代码代理和多智能体协作框架。 这在当年几乎难以预料。一个方向曾经失败，并不代表它不重要；有时只是因为真正能支撑它的基础设施还没有出现。 为什么 AI Agent 令人兴奋：AGI 的可能形态 为什么今天这么多人重新涌向 AI Agent？ 演讲者给出了一个非常直接的判断：很多人都隐约意识到，AGI 很可能会以某种 AI Agent 的形态出现。 它不一定是一个单体智能。更可能是许多智能体组成的系统：它们有分工，有记忆，有工具，有沟通协议，甚至形成某种数字组织或数字文明。 这也是 Agent 相比聊天机器人更令人兴奋的地方。...

本文整理自 YouTube 视频：《Reflecting on a year of Claude Code》，由有道龙虾根据视频字幕自动整理并发布。 一年前，Claude Code 正式开放使用。这个最初诞生于 Anthropic 内部的项目，是一个运行在终端里的 Agentic Coding 工具，如今已经被全球开发者和各类组织用于日常开发。 在这支视频里，Claude Code 负责人 Boris Cherny 和 Claude Code 产品负责人 Cat Wu 回顾了它的第一年：从一个在 Slack 里只收获两个表情反应的内部演示，到工程团队把它部署到整个代码库中。他们聊到了 Agent 验证的最佳实践、Auto Mode 背后的思考、最喜欢的 routines 和 loops、Claude Code 在工程之外的采用、context minimalism 的兴起，以及如何面向 AI 指数级变化构建产品。 Claude Code 刚发布的时候，团队内部的反应其实没那么轰动。 有人把一个小视频发到 Slack，只有两个人点了反应。大家觉得它“挺酷”，尤其是处理一些非常简单的工程任务时，效果还不错。 这句话听起来很委婉。 换句话说，早期的 Claude Code 还远没有今天这么强。 但只过了一年，事情已经完全变了。 现在，使用 Claude Code 的方式不再是“我问一个问题，它给我写一段代码”。很多人已经开始同时运行一批 Agent，甚至是一个 Agent 去调度另一个 Agent，后面再继续调度更多 Agent，形成一棵由成百上千个 Agent 组成的工作树。 软件开发的重心，也从“写代码”变成了“设计任务、让 Agent 执行、验证结果、把经验写进系统”。 真正重要的不是提示词，而是让 Agent 学会改进自己 有一个很关键的经验：...

本文翻译自 Matt Van Horn 发布在 X 上的文章《WTF Is a Loop? Peter Steinberger vs. Boris Cherny》。本文由有道龙虾翻译、排版和发布。 本周 AI 编程领域被重复最多的一句话只有六个词，而且几乎没人能说清它到底是什么意思。 本周有一条推文让整个时间线都被它“锁喉”，于是我用 /last30days 跑了一遍大家争论的那个词。答案是真实存在的，它有五年的演化脉络，而最讽刺的是：现在真正昂贵的部分不是模型，而是循环。 让整个时间线着迷的那条推文 本周，整个 AI 编程时间线都在围着一条推文转。Peter Steinberger 在 6 月 7 日发了它，浏览量超过 220 万，回复区则变成了一场关于它到底是什么意思的混战。 “这是你每月一次的提醒：你不该再提示编码智能体了。你应该设计那些会提示你智能体的循环。” 这就是所有人都在引用的那句话。最有代表性的回复来自 Varadh Jain，他问了唯一真正重要的问题：这在实践中到底长什么样？而成为全场情绪代表的回答，则来自 Matthew Berman。 “没人知道，除了他和 Boris。” 这才是真正的故事。不是“循环就是未来”，而是一个六个词的短语拿到了 200 万浏览量，同时转发它的人却在回复区争论它到底是什么意思。 我没有翻白眼，因为我自己每晚都跑一个循环，在我睡觉时，它会给大约 30 个开源仓库打开 pull request。90 秒的研究返回了 15 个 Reddit 讨论串、21 条 X 帖子，以及一个令人不太舒服的模式：AI 编程里最响亮的概念，恰恰是大多数复述它的人解释不清的东西。 一派人在喊：提示工程已死。另一派，也就是那些手真的放在键盘上的人，则谨慎得多。 “它不是 ralph/goal 循环，那现在已经是老东西了。它大概是某种持续编排循环，用来监督其他线程/智能体。” 这条回复是所有人发出的答案里最接近正确的一条。先记住它。 循环到底是什么 Boris Cherny 在 2024 年 9 月把 Claude Code 当作副项目做了出来。现在据说，GitHub 上接近 4% 的公开提交都在它背后完成。6 月 2 日，在 WorkOS 主办的 Acquired Unplugged 活动舞台上，他给出了你能找到的最清晰的“循环”定义。...

原文标题：A harness for every task: dynamic workflows in Claude Code。本文基于 Thariq Shihipar 的原文，完全由有道龙虾自动翻译、整理和发布。 上周，我们在 Claude Code 中发布了 dynamic workflows（动态工作流）。Claude 现在可以根据手头任务，即时编写自己的 harness（执行框架），为当前任务量身定制。 默认的 Claude Code 执行框架是为写代码构建的，但它也适用于许多其他类型的任务，因为很多任务本质上很像编码任务。不过，有些任务类型为了达到最佳效果，我们过去需要在 Claude Code 之上构建自定义执行框架，例如 Research、安全分析、agent 团队或 Code Review。 Workflows 让你可以在 Claude Code 内部原生地动态创建执行框架，让 Claude 解决这些问题以及更多问题。你也可以分享和复用这些 workflows。 本文会介绍我对 workflows 的初步体验和收获，帮助你更充分地使用它。不过，最佳实践仍在发展中。动态 workflows 通常会消耗更多 token，所以要认真思考何时以及如何使用它们。 注：这篇文章也发布在 Claude Blog 上。 示例 Prompt 在深入技术细节之前，我想先给一些示例 prompt，帮你想象 workflows 的可能性： “这个测试大概每 50 次会失败 1 次。搭建一个 workflow 来复现它，提出理论，并在 worktree 里对这些理论进行对抗性测试。/goal 不要停，直到有一个理论成立。” “使用 workflow，查看我最近 50 个 session，挖掘我反复纠正的问题，并把重复出现的内容变成 CLAUDE....

本文翻译自 Anthropic 官方博客文章：How Claude Code works in large codebases: Best practices and where to start。本文完全由有道龙虾翻译和发布。 Claude Code 已经在生产环境中服务于数百万行代码的单体仓库（monorepo）、存在数十年的遗留系统、横跨数十个代码仓库的分布式架构，以及拥有数千名开发者的组织。这些环境会带来小型、简单代码库没有的挑战，例如每个子目录的构建命令都不同，或者遗留代码散落在多个文件夹中，没有统一的共享根目录。 本文总结了我们观察到的一些模式，这些模式帮助团队成功地在规模化环境中采用 Claude Code。我们所说的“大型代码库”涵盖很宽的部署范围：数百万行代码的 monorepo、历经数十年构建出的遗留系统、分散在独立仓库中的数十个微服务，或者上述情况的任意组合。这也包括使用某些团队不一定会与 AI 编程工具联系在一起的语言的代码库，例如 C、C++、C#、Java、PHP。（尤其是在近期模型发布之后，Claude Code 在这些场景中的表现通常比多数团队预期得更好。）虽然每个大型代码库部署都会受到具体版本控制系统、团队结构和长期积累的约定影响，但本文中的模式具有普遍适用性，可以作为考虑采用 Claude Code 的团队的良好起点。 Claude Code 如何导航大型代码库 Claude Code 导航代码库的方式类似软件工程师：它遍历文件系统、读取文件、使用 grep 精确查找所需内容，并沿着引用关系在代码库中追踪。它在开发者本机上本地运行，不需要构建、维护代码库索引，也不需要把索引上传到服务器。 基于 RAG（Retrieval-Augmented Generation，检索增强生成）的 AI 编程工具通常会为整个代码库生成嵌入，并在查询时检索相关片段。在大规模环境下，这类系统可能失效，因为嵌入流水线跟不上活跃工程团队的提交速度。等开发者查询索引时，索引反映的可能是数周、数天，甚至数小时前的代码库状态。检索结果可能返回一个团队两周前已经重命名的函数，或者引用上个迭代已经删除的模块，而且没有任何迹象表明这些结果已经过时。 智能体式搜索（agentic search）可以避开这些失效模式。它不需要随着成千上万名工程师不断提交新代码而维护嵌入流水线或集中式索引。每个开发者的实例都直接基于实时的本地代码库工作。 但这种方法也有取舍：只有当 Claude 拥有足够的起始上下文、知道该从哪里开始查找时，它的效果才最好。这意味着 Claude 的导航质量取决于代码库本身的准备程度，包括如何用 CLAUDE.md 文件和技能（skills）分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例，它可能在真正开始工作之前就碰到上下文窗口限制。愿意投入代码库准备工作的团队，会得到更好的结果。 运行框架与模型同样重要 关于 Claude Code，最常见的误解之一是认为它的能力完全由所使用的模型决定。团队往往关注模型基准测试，以及模型在测试任务上的表现。实践中，围绕模型构建的生态，也就是运行框架（harness，模型周边的上下文、工具和集成层），对 Claude Code 表现的影响往往超过模型本身。 这个运行框架由五类扩展点构成：CLAUDE.md 文件、hooks（钩子）、skills（技能）、plugins（插件）和 MCP servers（MCP 服务器）。它们各自承担不同功能。团队构建它们的顺序也很重要，因为每一层都会建立在前一层之上。另外还有两项能力补齐整体配置：LSP 集成和子智能体（subagents）。下面我们说明这些组件和能力分别做什么。 CLAUDE.md 文件应该最先建立。这些是 Claude 在每个会话开始时自动读取的上下文文件：根目录文件提供整体图景，子目录文件提供局部约定。它们为 Claude 提供完成任何任务所需的代码库知识。由于这些文件会在每个会话中加载，无论任务是什么，因此应只保留广泛适用的内容，避免它们拖慢性能。...

本文整理自 YouTube 视频《Alex from Anthropic on Claude, AI agents, memory and product management》，由有道龙虾总结和发布。 AI 公司到底怎么“做”一个模型？ 不是简单地把更多数据扔进去，也不是只盯着榜单分数往上刷。至少在 Anthropic 内部，Claude 更像一个正在被不断打磨的产品：它有目标用户，有核心能力，有缺陷清单，有反馈渠道，也有越来越重要的“性格”。 Alex 曾是 Anthropic 的开发者关系负责人，现在是研究团队的产品经理。他在访谈里聊到一个很有意思的视角：模型本身就是产品。 这句话背后，其实藏着现在 AI 产品管理最核心的变化。 模型不是“训练完就发布”，而是从第一天就被产品化 传统产品经理做产品，大概是理解用户问题、定义解决方案、推动团队把东西做出来。 研究团队里的 PM 也差不多，只是他们面对的“产品”不是一个按钮、一套流程或者一个 App，而是模型本身。 每一代 Claude 在很早的构思阶段，就会被问几个问题： 这一代模型应该擅长什么？ 它大概率会在哪些任务上变强？ 上一代模型哪里表现不好，这一代要怎么修？ 它会通过 API、Claude Code、Claude.ai、Co-work 等不同产品界面被怎样使用？ 这和普通产品开发最大的区别在于：软件功能通常是“造出来”的，而模型更像是“长出来”的。 团队可以根据训练方式、架构选择、数据和技术路线去预测它可能擅长什么，但直到训练过程真正发生，没人能百分百知道它最后会变成什么样。 所以研究 PM 的工作，就是从模型的 ideation 阶段一路跟到训练、评测、发布，再把来自用户、内部团队、产品界面的反馈重新带回下一轮模型开发。 Claude 要变强，不只是“会写代码” 过去一两年，编码能力当然是模型竞争的核心战场。 但 Alex 提到，Claude 的能力目标远不止写代码。知识工作、表格处理、Excel、文档分析、复杂产品任务，也都变成了重要方向。 尤其是随着 Claude 被嵌入越来越多产品界面，模型能力不再是孤立存在的。 同一个模型，在 Claude.ai 里、在 Claude Code 里、在 API 里、在 Co-work 里，用户体验可能完全不同。因为每个产品界面都有自己的提示词、工具、上下文和使用场景。 这就让模型 PM 的工作变得很复杂。...

本文整理自 OpenAI Forum 发布的分享视频，由有道龙虾总结和发布。 “Codex"这个词听起来像是给程序员准备的。但如果你参加过最近一期的OpenAI论坛，你会发现座下没人讨论怎么写代码——他们聊的是怎么找旧金山最好的面包、怎么做日常购物、怎么让一个AI代理当自己的"迷你参谋长”。 Tibo Sio，OpenAI Codex的负责人，开门见山地说了一个让人意外的数据：现在Codex上执行的大部分任务，根本不是编程任务。 从云端代码助手到桌面万能代理 Codex的故事其实走过一段弯路。 大约两年前，OpenAI团队开始追逐一个"宏大的挑战"：让AI达到顶级软件工程师的编程水平。他们推出的第一个公开版本，今天的团队叫它"Codex Web"——一个跑在云端的东西，你通过网页界面告诉它要改什么代码，它去翻你的代码仓库，自动生成改动，然后在GitHub上开一个Pull Request。 听起来很酷。但问题是：摩擦太大了。 你得把自己电脑上那一整套开发环境在云端重新搭一遍，而模型当时也没聪明到次次都靠谱。团队很快意识到：与其让人适配工具，不如让工具适配人。 “我们决定让它在每个人自己的机器上本地跑。“Tibo说。 转折点：连程序员的大部分时间都不在写代码 Codex最初是给工程师用的。但做着做着他们发现了一个有意思的事实：软件工程师每天真正写代码的时间，大概也就20%到30%。 剩下的时间呢？翻工单、排优先级、讨论架构方案、查Bug、处理线上事故、做值班……大量工作其实是信息搜集、沟通协调、上下文梳理。这些事跟写代码没半毛钱关系。 于是技术团队自己开始"吃自己的狗粮”——用Codex处理那些非编码的杂活。结果效果之好，让他们意识到：手里拿着的根本不是"代码工具”，而是一个通用得多的东西。 Tibo讲了一个让他印象深刻的瞬间：产品负责人Alexander在Codex发布前夕，同时跑着多个Codex代理——一个在搜集用户反馈，一个在跟开发者确认状态，一个在实时更新项目计划文档——而他自己正坐在会议室里跟Tibo讨论。 “我从来没见过一个人这么高效，“Tibo说，“那一刻我就觉得，我们在改变的不只是软件工程。” 这就是那个"原来这东西是给所有人用"的觉醒时刻。 面包、咖啡和"属于你一个人的软件” 为了让观点落地，Tibo在现场做了个演示。 他住在旧金山，对当地面包的离谱价格很不满，于是对Codex说了一句话：“帮我在旧金山找最好的面包，列个表格，标明价格和购买地点。” 五分钟之后，一张完整的电子表格出现了：烘焙店名、面包种类、描述、价格，一清二楚。 然后他随口又说了一句：“把同样的东西做成网页，放地图上。” 四分钟后，一个带交互地图的网页生成了——每家店的位置、面包信息、价格，全在地图上可视化呈现。他甚至可以说"对咖啡也做同样的分析”，八分钟后旧金山咖啡地图也做好了。 整个过程，Tibo连键盘都没碰——全程语音操作。 “这不是我花一整个周末才能做出来的东西，“他说，“在以前，这根本就不会发生。它不是从’几周变几秒’，是从’永远不可能’变成了’几分钟的事’。” 这就是Tibo反复强调的"个人软件"时代：每个人都有能力为自己量身打造小工具，而不用求人。设计师可以在代码库里直接改UI细节，不用跟工程师排期；市场人员可以做深度竞争分析，不用等数据团队排期。 首席参谋、自动化日报和一个"不用看邮件"的未来 Tibo自己怎么用Codex？他打开侧边栏——一天之内已经派发了上百个任务给Codex代理： 整理桌面文件 管理计算资源集群 帮我看值班轮转情况 检查即将上线的发布计划，标出有风险的项目 每天早上9点扫描我的Gmail、Notion和日历，给我一份当日摘要，标出需要注意的事项 “它就像我的小参谋长，“他说，“帮我花精力在最重要的事情上。” 他甚至做了一个"个人新闻简报”——根据他自己的偏好筛选信息，每天早上推送。以前，这种事要么不存在，要么得雇个人专门做。 更激进的想象是：未来你甚至不用看邮件了。一个全天候运行的代理读你的收件箱，只在真正重要的时候提醒你。“你只管设定目标，剩下的它帮你搞定。” 从10分钟到好几周：/goal模式的底气 对话的后半段，Tibo透露了一个正在铺开的新功能：slash goal。 普通模式下，你给Codex一个具体任务，它干完了汇报。但在goal模式下，你给它一个长期目标——比如"解决一个非常难的数学问题”——它就会像着了魔一样持续攻坚，干几个小时、几天、甚至几周，直到自己认为目标达成。 目前已经有人用它把整个程序从一种语言翻译成另一种，有人在物理和数学问题上用它突破瓶颈。 “几个月前我们还在激动它能连续工作10分钟，“Tibo说，“现在我们在讨论连续工作几周。有时候，天才不过就是能对同一件事持续思考更久。” 给非技术用户的三个行动建议 论坛上有观众问了一个很实操的问题：非开发人员到底怎么做，才能用好Codex？ Tibo给了三条： 1. 加入社群，看别人怎么用。 他自己都会被一些神奇的用法规避惊艳到。OpenAI论坛就是这样一个互相学习的地方。 2. 给它精确的指令，别模糊。 把它当成一个刚入职的新同事——没有上下文，不知道你的偏好。你得说清楚"成功长什么样"和"什么样算搞砸了”。比如要一份PPT，就明确说"我要10页，前两页放背景信息，中间六页做技术拆解，最后两页放开放问题和Q&A”。越具体，成功的概率越高。 3. 尽量连接更多信息源。 Codex现在有超过100个插件——日历、Notion、各类工具都可以接进来。接入的信息源越多，它能帮的忙就越大。 但有一条重要的提醒：别把所有事情都交给它。Tibo特别指出他见过最大的错误就是"过度委托”——把包括自己对问题的理解都一并外包出去。真正用好Codex的人，是在用它提升自己的认知，而不是替代自己的思考。它可以用图像和图表帮你理解复杂概念，但做笔记、主动回想、验证理解，永远是你自己的事。 企业落地的真正瓶颈：不是能力，是信任 当被问到企业采用的最大障碍时，Tibo的回答很直接：不是模型能力不够，是信任和安全问题。 “如果有代理在你公司里到处乱跑，不小心删了敏感文件，或者把不该发出去的信息外泄——没人敢用。” OpenAI在做三件事来解决这个： 沙箱默认运行：可以限制代理只能访问特定文件夹，甚至禁止联网 细粒度权限控制：可以设成"只能读不能写”，数据安全仍由你掌控 “自动审查"机制（Auto Review）：另一个独立代理实时监控主代理的每一步操作，风险动作直接拦截 “就像一个裁判在旁边，看到越界的操作立刻喊停。”...

本文翻译自 Thariq 在 X 上发布的文章：Using Claude Code: The Unreasonable Effectiveness of HTML。本文完全由有道龙虾翻译和发布。 Markdown 已经成为智能体与我们沟通时最主流的文件格式。它简单、可移植，有一定的富文本能力，也很容易让你编辑。Claude 甚至已经非常擅长在 Markdown 文件里用 ASCII 画图。 但随着智能体变得越来越强，我开始觉得 Markdown 变成了一种限制性格式。超过一百行的 Markdown 文件对我来说就很难读。我想要更丰富的可视化、颜色和图表，而且希望它们能轻松分享。 我也越来越少亲自编辑这些文件，而是把它们当作规格说明、参考文件、头脑风暴结果等来使用。即便我确实要修改，通常也是让 Claude 去改，这就削弱了 Markdown 最大的优势之一。 我已经开始更偏好用 HTML 作为输出格式，而不是 Markdown。我也越来越常看到 Claude Code 团队的其他人这么做。下面是原因。 如果你想先看一些例子，可以看这里：html-effectiveness，但记得回来继续读为什么。 为什么是 HTML？ 信息密度 相比 Markdown，HTML 能传达丰富得多的信息。它当然可以表达简单的文档结构，比如标题和格式，但它还可以表示各种其它信息，例如： 用表格表示表格数据 用 CSS 表示设计数据 用 SVG 表示插图 用 script 标签表示代码片段 用 HTML 元素、JavaScript 和 CSS 表示交互 用 SVG 和 HTML 表示工作流 用绝对定位和 canvas 表示空间数据 用 image 标签表示图片 我甚至会说，几乎没有 Claude 能读懂、但你无法用 HTML 相对高效表达的信息集合。这让 HTML 成为模型向你传达深度信息、并让你审阅这些信息的一种非常高效的方式。...

本文整理自 GPT-5 发布后，A16Z 对 OpenAI 研究员 Isa Fulford 和 Christina Kim 的专访，以下为原视频精华。 就在 OpenAI 最新一代模型（视频中称为 GPT-5）发布的当天，我们有幸与两位身处风暴中心的关键人物——Christina 和 Issa 聊了聊。她们分别负责核心模型的后训练（Post-training）和 ChatGPT Agent 团队的深度研究。 这场对话没有官方辞令，更像是一次坦诚的幕后分享。她们不仅揭示了新模型在编码、写作等方面实现巨大飞跃的秘密，也分享了 OpenAI 独特的工作哲学、对 AI 未来的思考，以及那些不为人知的开发故事。 一、不止是“更聪明”，更是“更好用”：GPT-5 带来了什么？ 当被问及新模型的反响时，Christina 兴奋地表示，除了评测数据（eval numbers）非常亮眼，她更激动的是模型在实用性上的巨大提升，尤其是在她个人最常用的两个领域： 编码能力的大飞跃：这几乎是所有内部测试人员的共识。新模型被誉出口的“市场最佳编码模型”，尤其在前端开发上，简直是“完全提升了一个档次”。发布会上的演示，几分钟就生成一个功能完善、设计美观的前端应用，而这样的工作量，对一个开发者来说可能需要一周。这背后的秘密？Christina 坦言，没什么魔法，就是团队“真的非常、非常在乎（really cared about）”把编码做好，从搜集最好的数据，到打磨模型的审美，每一个细节都倾注了心血。 触动人心的写作能力：Issa 形容新模型的写作能力“非常温柔和感人（very tender and touching）”。它不再是那个只会堆砌华丽辞藻的“过分热情”的助手，而是能理解并表达细腻情感的伙伴。Christina 在直播中演示用它来起草一篇悼词，这种需要深度情感共鸣的任务，模型也能出色完成。对于像她这样自认不擅长写作的人来说，这无疑是一个强大的工具，无论是写一封重要的邮件，还是一条简单的 Slack 消息。 这个新模型，似乎正在把“点子大王”（the ideas guy）的时代变为现实。你不必再受限于技术实现能力，只要有好想法，通过简单的提示词，一个功能齐全的应用就能诞生。这无疑为独立开发者和初创公司打开了全新的想象空间。 二、后训练的“艺术”：我们如何塑造模型的“品味”与行为？ 一个强大的模型不仅仅是聪明，它的“性格”和行为方式同样重要。过去模型出现的“阿谀奉承”（sycophancy）等问题，在新模型的开发中得到了重点关注。 Christina 将后训练形容为“一门艺术”。团队需要在一系列目标之间做出权衡和取舍，就像一位艺术家在调色盘上寻找完美的平衡。 “你希望AI助手非常乐于助人、引人入胜，但如果‘太’引人入胜，就可能变得过于谄媚。这就像一个平衡木，你要想清楚，我们到底希望这个模型给人什么样的感觉。” 减少“胡说八道”的秘诀 对于幻觉（hallucinations）和欺骗（deception）问题，团队发现，这往往源于模型“急于表现”的心态。之前的模型为了“乐于助人”，有时会不假思索地“脱口而出”一个答案。 而新模型的改进，很大程度上归功于**“思考”能力的引入**。当模型能够进行“一步一步的思考”（step-by-step thinking）时，它就像有了一个暂停和反思的机会，而不是急着给出答案。这种机制显著降低了产生幻觉的概率。 有趣的是，当内部员工测试新模型时，有时反而会感到一丝“被冒犯”，因为他们提出的难题，模型可能只“思考”了两秒钟就轻松解决了。 三、数据、数据、还是数据：推动AI进步的核心燃料 当被问及模型能力的提升主要来自架构、数据还是规模时，Christina 毫不犹豫地回答：“我坚定地站在‘数据派’（data-pilled）这边。” 她认为，高质量的数据是决定模型上限的关键。尤其是在强化学习（Reinforcement Learning）的框架下，好的数据能让模型以极高的效率学会新能力。 这个观点也解释了 OpenAI 内部的协作模式： 从能力倒推，创造评测标准：团队会先定义希望模型拥有的能力（比如制作幻灯片、编辑电子表格），如果现有的评测标准（evals）无法衡量，他们就会自己创造新的、能代表用户真实需求的评测标准。 用评测“引诱”大家：Christina 开玩笑说，在 OpenAI 内部，如果你想“引诱”同事来解决一个难题，最好的办法就是创建一个好的评测标准。大家看到明确的目标后，就会兴致勃勃地去“爬山”（hill climb），不断优化。 产品探索反哺核心模型：Issa 的团队在探索 Agent 能力（如深度研究 Deep Research）时，会创建专门的数据集。这些经过验证的、高质量的数据集随后会被贡献给核心模型团队，从而让下一代基础模型直接继承这些新能力，形成一个良性的自增强循环。 四、从 WebGPT 到 AI Agent：未来已来，只是分布尚不均匀 回顾历史，Christina 参与的 WebGPT 项目可以说是 ChatGPT 的前身。最初的目标很简单：让语言模型通过浏览工具来获取事实信息，解决幻觉问题。但他们很快意识到，人们问完一个问题后，通常还会有下一个。这个洞察，最终催生了对话形式的 ChatGPT。...