谷歌（Google）在旗下 AI 创作平台 Flow 中，向免费用户开放了最新图像生成模型 Nano Banana 2 的使用权限。目前支持单次并发生成 4 张图像，且不消耗账户积分。对于需要高频测试提示词或调整图像细节的用户而言，这提供了一个比标准 Gemini 网页版更高效的替代方案。

Flow 是 Google Labs 推出的生成式 AI 影像创作平台。不同于传统的基于时间轴的剪辑软件，Flow 整合了 Veo 3.1（视频）、Nano Banana 2（图像）与 Gemini（语义）等核心大模型，允许用户通过自然语言构建包含连贯画面和音效的场景。

现在向所有用户开放了 0 积分使用最新图像生成模型 Nano Banana 2。目前支持单次并发生成 4 张图像，且不消耗账户的积分。

通过浏览器访问Google Flow 平台。进入后，可选择打开历史项目，或点击页面底部的按钮新建项目（New Project）。

进入项目工作区，展开页面底部的聊天框功能菜单。

完成设置后，在文本框中输入描述图像的提示词并发送。

系统将并发展示 4 张生成结果。相较于在普通版 Gemini 中逐张生成，该工作流大幅降低了等待时间。

Nano Banana 2 在生成时支持上传参考图片，以便更精准地控制视觉风格或角色的一致性。

经测试，在连续生成 40+ 张图像后，系统未出现拦截提示，且未扣除任何账户积分。这一配额已显著超出普通版 Gemini 的免费限制。

随着知道的人变多，Google 随时可能更新策略或者加上次数限制。

所以！看到这篇内容，赶紧先去试试！

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

简单来说，GPT-5.1 的核心进化在于在智能和速度之间找到了一个绝佳的平衡点。

GPT-5.1 的可控性是它最大的亮点之一。可以像导演一样，精确塑造智能体的个性、沟通风格和行为模式，扮演每一个细节。

为智能体定义一个清晰的角色，是引导其个性和互动风格最有效的方式。这在需要处理复杂用户动态的客户服务等场景中尤为重要。 以下提示定义了一个注重效率和实用性的客户支持智能体：

通过 verbosity 参数和明确的提示指令，可以对输出的长度和结构进行精确控制。 为编码智能体设定的输出规则示例：

一个通用的输出长度控制指令：

在执行长耗时任务时，让智能体主动提供计划和进度更新，可以有效改善用户体验，并使用户能够监督其工作流。 定义更新频率、内容和时机的指令示例：

为防止智能体在复杂任务中过早结束，可通过提示强化其自主解决问题的持久性。

工具的有效使用，依赖于在定义中清晰描述其功能，并在提示中明确其使用场景。 create_reservation 工具的 JSON 定义：

配套的提示，用以指导模型如何与用户交互并调用该工具：

GPT-5.1 能够高效地并行执行无依赖关系的工具调用。在系统提示中鼓励这种行为可以显著提升任务执行效率。

GPT-5.1 集成了为编码场景设计的专用工具，允许模型直接与开发环境交互。

none 推理模式强制模型不使用内部推理步骤，使其在行为和性能上接近传统的非推理模型。这为低延迟应用和简单的工具调用场景提供了显著的性能优势。

尽管此模式下没有显式的“思考”链，但可以通过提示引导其进行隐式的规划和验证。

当智能体的行为与预期不符时，可以利用模型本身来分析和修正其系统提示。

诊断根本原因

向 GPT-5.1 提供其原始系统提示和一批失败案例的日志，要求它进行根本原因分析。

生成修订方案

基于第一步的分析结果，要求模型提出对原始提示的“外科手术式”修改。

通过这个两步流程，开发者可以利用模型自身的语言和逻辑能力，定位并修复提示中的模糊和矛盾之处，从而生成一个更健壮、行为更可预测的智能体。

总而言之，GPT-5.1 在可控性、效率和工具集成方面提供了新的可能性。掌握其提示工程原则，特别是行为塑造、工具使用规范以及自我修正等高级技巧，是构建下一代复杂 AI 应用的基础。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

第一次看到时，我真的笑出声。但笑着笑着，就觉得有点不对劲了。

这个研究，可能说的就是我们自己。

https://llm-brain-rot.github.io/

首先，这研究不是段子，是来自德州 A&M、德州大学奥斯汀分校和普渡大学的硬核论文。简单来说，他们做了个实验：

把一个正常的 AI 大模型（对照组），和另一个被强迫刷了几个月推特、Reddit 等社交媒体的 AI 模型（实验组）进行对比，他们用了两种标准“垃圾信息”：

结果发现了不得了的事：

喂了垃圾数据后，AI 在推理、长文理解、安全等方面全面降智。

而且，这是一种 “剂量反应”：垃圾数据的比例越高，AI 就“脑损”得越厉害。

看个例子就明白了：

在一项叫“ARC-Challenge”的推理测试中（考验 AI 举一反三的能力），随着提供垃圾数据（M1 型信息标准）的比例从 0%增加到 100%，AI 的准确率从 74.9% 直降到 57.2%。

下面这张表更直观，我从原论文里摘了几个关键数据（红色代表性能变差）：

简单的说：AI 不仅降智了，还变得更不安全、性格更“黑暗”了。

研究人员对 AI 犯的错误进行了分析，发现最关键的是它学会了偷懒，也就是 不思考了。

上图显示，在“脑腐”之后，对比基准，AI 思维的错误显著增多。它不再愿意进行一步一步的严谨推理，而是倾向于直接跳到结论，M1 的影响更是大于 M2。

这不就是我们在信息流里被训练出的习惯吗？

最让人难接受的是，这种“脑腐”基本不能治愈。

研究人员试着用大量高质量的“干净”数据去“修复”那个降智的 AI，结果发现效果相当有限。

即使经过大规模的“高质量训练”，性能也只能部分回升，始终无法恢复到基本水平。

这意味着，AI 的内部认知结构，或者说它的“世界观”，已经被永久性地改变了。

看到这里，你是不是也品出点别的味道了？

虽然研究的是 AI，但你很难不怀疑这个研究是在指桑骂槐。

如果 AI 会因为刷垃圾信息而变傻，那当前互联网信息环境里的我们呢？

仔细想想，我们身边是不是已经有太多迹象了：

“大学教授也可能转发每日口服 7 颗绿豆能够逆转高血压……的文章，学术训练的强度和社交网络垃圾文章洗脑的强度不可同日而语。”

我们以为自己是在驾驭信息，但很可能，我们只是在被网络信息洪流日夜冲刷，以为自己有足够的知识和阅历来抵御侵蚀，但长年累月的垃圾信息轰炸，可能正在不知不觉中重塑我们的大脑。

大脑的认知逻辑正在被悄悄地改变。

去查查那些著名社交平台的创始人，看看他们自己每天花多少时间在手机上？

你会发现一个很有意思的现象：很多产品的设计者，自己反而刻意与产品保持距离。这背后的原因，值得我们每个人深思。

一个小测试：

读到这里，你还记得这篇文章是怎么开头的吗？

…

想不起来也没关系。

这可能就是一个信号，提醒我们是时候让大脑从无休止的信息流中抽离出来，安静一会儿了。

为了保护你的脑子，现在，是不是该对我说声“谢谢”？🙂

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

Anthropic 的内部团队正在利用 Claude Code 彻底改变他们的工作流程。无论是开发者还是非技术人员，都能借助它攻克复杂项目、实现任务自动化，并弥补那些曾经限制生产力的技能鸿沟。

为了深入了解，我们采访了以下团队：

通过这些访谈，我们收集了不同部门使用 Claude Code 的方式、它对工作带来的影响，以及为其他考虑采用该工具的组织提供的宝贵建议。

数据基础设施团队负责为公司内所有团队整理业务数据。他们使用 Claude Code 来自动化常规的数据工程任务、解决复杂的基础设施问题，并为技术和非技术团队成员创建文档化工作流，以便他们能够独立访问和操作数据。

利用截图调试 Kubernetes

当 Kubernetes 集群出现故障，无法调度新的 pod 时，团队使用 Claude Code 来诊断问题。他们将仪表盘的截图喂给 Claude Code，后者引导他们逐个菜单地浏览 Google Cloud 的用户界面，直到找到一个警告，指出 pod 的 IP 地址已耗尽。随后，Claude Code 提供了创建新 IP 池并将其添加到集群的确切命令，整个过程无需网络专家的介入。

为财务团队打造纯文本工作流

工程师向财务团队成员展示了如何编写描述其数据工作流程的纯文本文件，然后将这些文件加载到 Claude Code 中，以实现完全自动化的执行。没有任何编程经验的员工只需描述“查询这个仪表盘，获取信息，运行这些查询，生成 Excel 输出”等步骤，Claude Code 就能执行整个工作流，甚至会主动询问日期等必要输入。

为新员工提供代码库导览

当新的数据科学家加入团队时，他们会被指导使用 Claude Code 来熟悉庞大的代码库。Claude Code 会阅读他们的 Claude.md 文件（文档），识别特定任务所需的相关文件，解释数据管道的依赖关系，并帮助新人理解哪些上游数据源为仪表盘提供数据。这取代了传统的数据目录和发现工具。

会话结束时自动更新文档

在每项任务结束时，团队会要求 Claude Code 总结已完成的工作并提出改进建议。这创建了一个持续改进的循环：Claude Code 根据实际使用情况帮助优化 Claude.md 文档和工作流指令，使后续的迭代更加高效。

跨多个实例并行管理任务

在处理耗时较长的数据任务时，团队会为不同项目在不同的代码仓库中打开多个 Claude Code 实例。每个实例都能保持完整的上下文，因此即使在数小时或数天后切换回来，Claude Code 也能准确地记住他们当时正在做什么以及任务进行到哪里，从而实现了无上下文丢失的真正并行工作流管理。

无需专业知识即可解决基础设施问题

解决了通常需要系统或网络团队成员介入的 Kubernetes 集群问题，利用 Claude Code 诊断问题并提供精确的修复方案。

加速新员工上手

新的数据分析师和团队成员无需大量指导，就能迅速理解复杂的系统并做出有意义的贡献。

增强支持工作流

Claude Code 能够处理比人类手动审查大得多的数据量，并识别异常情况（例如监控 200 个仪表盘），这是人力无法完成的。

实现跨团队自助服务

没有任何编程经验的财务团队现在可以独立执行复杂的数据工作流。

编写详细的 Claude.md 文件

团队表示，你在 Claude.md 文件中将工作流程、工具和期望文档化得越好，Claude Code 的表现就越出色。当你拥有现成的设计模式时，这使得 Claude Code 在设置新数据管道等常规任务上表现卓越。

处理敏感数据时使用 MCP 服务器而非命令行界面

他们建议使用 MCP 服务器而不是 BigQuery 命令行界面，以便更好地控制 Claude Code 的访问权限，尤其是在处理需要日志记录或存在潜在隐私问题的敏感数据时。

分享团队使用心得

团队举办了分享会，成员们互相演示他们使用 Claude Code 的工作流程。这有助于传播最佳实践，并展示了他们自己可能没有发现的各种工具使用方法。

Claude Code 产品开发团队使用自家的产品来为 Claude Code 构建更新，扩展产品的企业级功能和 AI 智能体循环功能。

通过“自动接受模式”快速构建原型

工程师们通过启用“自动接受模式”（Shift+Tab）并设置自主循环，让 Claude 编写代码、运行测试并持续迭代，从而实现快速原型开发。他们将自己不熟悉的抽象问题交给 Claude，让它自主工作，然后在接手进行最后润色前，审查已完成 80% 的解决方案。团队建议从一个干净的 git 状态开始，并定期提交检查点，这样如果 Claude 跑偏了，他们可以轻松回滚任何不正确的更改。

同步编码开发核心功能

对于涉及应用程序业务逻辑的更关键功能，团队会与 Claude Code 同步工作，提供带有具体实现指令的详细提示。他们实时监控过程，确保代码质量、风格指南合规性和正确的架构，同时让 Claude 处理重复的编码工作。

构建 Vim 模式

他们最成功的异步项目之一是为 Claude Code 实现 Vim 快捷键绑定。他们要求 Claude 构建整个功能，最终实现中大约 70% 的代码来自 Claude 的自主工作，只需几次迭代即可完成。

生成测试和修复 bug

在实现功能后，团队使用 Claude Code 编写全面的测试，并处理在代码审查中发现的简单 bug。他们还使用 GitHub Actions 让 Claude 自动处理像格式问题或函数重命名这样的 Pull Request 评论。

代码库探索

在处理不熟悉的代码库（如 monorepo 或 API 端）时，团队使用 Claude Code 来快速理解系统的工作方式。他们不再等待 Slack 上的回复，而是直接向 Claude 提问以获取解释和代码参考，从而大大节省了上下文切换的时间。

更快的功能实现

Claude Code 成功实现了像 Vim 模式这样的复杂功能，其中 70% 的代码由 Claude 自主编写。

提升开发速度

该工具可以快速构建功能原型并迭代创意，而不会陷入实现细节的泥潭。

通过自动化测试提高代码质量

Claude 生成全面的测试并处理常规的 bug 修复，在减少手动工作的同时保持了高标准。

更好的代码库探索

团队成员可以快速熟悉 monorepo 中不熟悉的部分，而无需等待同事的回复。

创建自给自足的循环

设置 Claude 通过自动运行构建、测试和代码检查来验证自己的工作。这使得 Claude 可以更长时间地自主工作并发现自己的错误，尤其是在你要求 Claude 在编写代码之前先生成测试时效果更佳。

培养任务分类的直觉

学会区分哪些任务适合异步处理（外围功能、原型设计），哪些需要同步监督（核心业务逻辑、关键修复）。产品边缘的抽象任务可以用“自动接受模式”处理，而核心功能则需要更密切的监督。

编写清晰、详细的提示

当组件具有相似的名称或功能时，你的请求要极其具体。提示越好、越详细，你就越能信任 Claude 独立工作，而不会对代码库的错误部分进行意外更改。

安全工程团队专注于保障软件开发生命周期、供应链安全和开发环境安全。他们广泛使用 Claude Code 来编写和调试代码。

复杂基础设施调试

在处理事故时，他们将堆栈跟踪和文档喂给 Claude Code，并要求它在代码库中追踪控制流。这大大缩短了生产问题的解决时间，使他们能够在大约 5 分钟内理解问题，而手动扫描代码通常需要 10-15 分钟。

Terraform 代码审查与分析

对于需要安全审批的基础设施变更，团队将 Terraform 计划复制到 Claude Code 中，并提问“这会做什么？我会后悔吗？”。这创建了更紧密的反馈循环，使安全团队能够更快地审查和批准基础设施变更，减少了开发过程中的瓶颈。

文档综合与操作手册

Claude Code 吸收多个文档来源，创建 Markdown 格式的操作手册、故障排除指南和概述。团队将这些精简的文档作为调试实际问题的上下文，创建了比在完整知识库中搜索更高效的工作流程。

测试驱动开发工作流

他们摒弃了以往的“设计文档 → 粗糙代码 → 重构 → 放弃测试”模式，现在他们要求 Claude Code 提供伪代码，引导其进行测试驱动开发，并定期检查以在卡住时进行引导，从而产出更可靠、更易于测试的代码。

上下文切换与项目上手

在为现有项目（如用于安全审批工作流的 Web 应用“dependant”）做贡献时，他们使用 Claude Code 来编写、审查和执行存储在代码库中的 Markdown 格式的规范，从而能够在几天内做出有意义的贡献，而不是花费数周时间。

缩短事故解决时间

通常需要 10-15 分钟手动代码扫描的基础设施调试现在大约需要 5 分钟。

改进安全审查周期

需要安全审批的 Terraform 代码审查速度大大加快，消除了开发人员在等待安全团队批准时的阻塞。

增强跨职能贡献

团队成员可以在几天内为项目做出有意义的贡献，而不是花费数周时间来建立上下文。

更好的文档工作流程

从多个来源综合而成的故障排除指南和操作手册创建了更高效的调试过程。

广泛使用自定义斜杠命令

安全工程团队使用了整个 monorepo 中 50% 的自定义斜杠命令实现。这些自定义命令简化了特定的工作流程，并加快了重复性任务的速度。

让 Claude 先说

他们不再通过提出有针对性的问题来生成代码片段，而是告诉 Claude Code “边做边提交你的工作”，让它在定期检查的情况下自主工作，从而得到更全面的解决方案。

利用它进行文档处理

除了编码，Claude Code 还擅长综合文档和创建结构化输出。团队提供写作样本和格式偏好，以获得可立即在 Slack、Google Docs 和其他工具中使用的文档，避免界面切换带来的疲劳。

推理团队负责管理在 Claude 读取你的提示并生成回复时存储信息的内存系统。团队成员，尤其是那些刚接触机器学习的人，可以广泛使用 Claude Code 来弥补知识差距并加速他们的工作。

代码库理解与新员工上手

在加入一个复杂的代码库时，团队严重依赖 Claude Code 来快速理解其架构。他们不再手动搜索 GitHub 仓库，而是询问 Claude 哪些文件调用了特定的功能，几秒钟内就能得到结果，而不是向同事求助或手动搜索。

包含边界情况的单元测试生成

在编写完核心功能后，他们要求 Claude 为其编写全面的单元测试。Claude 会自动包含被遗漏的边界情况，在几分钟内完成通常需要大量时间和精力的工作，就像一个他们可以审查的编码助手。

机器学习概念解释

没有机器学习背景的团队成员依赖 Claude 来解释模型特定的函数和设置。过去需要一个小时谷歌搜索和阅读文档的工作，现在只需 10-20 分钟，研究时间减少了 80%。

跨语言代码翻译

在用不同编程语言测试功能时，团队向 Claude 解释他们想要测试的内容，Claude 就会用所需的语言（如 Rust）编写逻辑，从而无需为了测试目的而学习新语言。

命令记忆与 Kubernetes 管理

他们不再需要记住复杂的 Kubernetes 命令，而是向 Claude 询问正确的语法，比如“如何获取所有 pod 或部署状态”，然后就能收到他们基础设施工作所需的确切命令。

加速机器学习概念学习

有了 Claude Code，他们的研究时间减少了 80%，历史上需要一个小时谷歌搜索的工作现在只需 10-20 分钟。

更快的代码库导航

该工具可以帮助团队成员在几秒钟内找到相关文件并理解系统架构，而不是依赖同事在几天内分享知识。

全面的测试覆盖

Claude 自动生成包含边界情况的单元测试，在保持代码质量的同时减轻了精神负担。

消除语言障碍

团队可以在不熟悉 Rust 等语言的情况下实现功能，而无需学习它。

首先测试知识库功能

尝试问各种问题，看看 Claude 能否比谷歌搜索更快地回答。如果它更快、更准确，那么它就是你工作流程中一个宝贵的时间节省工具。

从代码生成开始

给 Claude 具体的指令，让它编写逻辑，然后验证其正确性。这有助于在将其用于更复杂的任务之前，建立对该工具能力的信任。

用它来编写测试

让 Claude 编写单元测试可以极大地减轻日常开发工作的压力。利用这个功能来保持代码质量，而无需花费时间手动思考所有测试用例。

数据科学和机器学习工程团队需要复杂的 可视化工具来理解模型性能，但构建这些工具通常需要不熟悉的语言和框架的专业知识。Claude Code 使这些团队能够构建生产质量的分析仪表盘，而无需成为全栈开发人员。

构建 JavaScript/TypeScript 仪表盘应用

尽管对“JavaScript 和 TypeScript 知之甚少”，团队仍使用 Claude Code 构建了完整的 React 应用，用于可视化强化学习（RL）模型的性能和训练数据。他们让 Claude 控制从头开始编写完整的应用程序，比如一个 5000 行的 TypeScript 应用，而无需自己理解代码。这一点至关重要，因为可视化应用相对上下文较少，不需要理解整个 monorepo，从而可以快速构建原型工具，以便在训练和评估期间了解模型性能。

处理重复的重构任务

当遇到合并冲突或半复杂的文件重构时——这些任务对于编辑器宏来说太复杂，但又不足以投入大量开发精力——他们就像玩“老虎机”一样使用 Claude Code：提交当前状态，让 Claude 自主工作 30 分钟，然后要么接受解决方案，要么在不成功时重新开始。

创建持久性分析工具而非一次性笔记本

团队现在不再构建用完即弃的 Jupyter 笔记本，而是让 Claude 构建可重复使用的 React 仪表盘，这些仪表盘可以在未来的模型评估中重复使用。这很重要，因为理解 Claude 的性能是“团队最重要的事情之一”——他们需要了解模型在训练和评估期间的表现，而这“实际上并非易事，简单的工具无法从观察一个数字上升中获得太多信号”。

零依赖任务委托

对于完全不熟悉的代码库或语言中的任务，他们将整个实现委托给 Claude Code，利用其从 monorepo 中收集上下文并执行任务的能力，而无需他们参与实际的编码过程。这使得他们在自己专业领域之外也能保持生产力，而不是花时间学习新技术。

节省了 2-4 倍的时间

过去虽然可以手动完成但很繁琐的常规重构任务现在完成得更快了。

用不熟悉的语言构建了复杂的应用

尽管 JavaScript/TypeScript 经验极少，却创建了 5000 行的 TypeScript 应用。

从一次性工具转向持久性工具

不再使用一次性的 Jupyter 笔记本，而是构建可复用的 React 仪表盘进行模型分析。

直接获得模型改进的洞见

第一手使用 Claude Code 的经验为未来模型迭代中更好的内存系统和用户体验改进提供了信息。

实现了可视化驱动的决策

通过先进的数据可视化工具，更好地理解了 Claude 在训练和评估期间的性能。

把它当作一台老虎机

在让 Claude 工作之前保存你的状态，让它运行 30 分钟，然后要么接受结果，要么重新开始，而不是试图费力去修正。重新开始的成功率通常比试图修复 Claude 的错误要高。

必要时为了简化而打断它

在监督过程中，不要犹豫，停下来问 Claude “你为什么这么做？试试更简单的方法。” 模型默认倾向于更复杂的解决方案，但对于简化方法的请求反应良好。

产品工程团队致力于开发如 PDF 支持、引用和网页搜索等功能，这些功能将额外的知识引入 Claude 的上下文窗口。在大型、复杂的代码库中工作意味着不断遇到不熟悉的代码部分，花费大量时间来理解特定任务需要检查哪些文件，并在进行更改前建立上下文。Claude Code 通过充当向导，帮助他们理解系统架构、识别相关文件并解释复杂的交互，从而改善了这种体验。

第一步工作流规划

团队将 Claude Code 作为任何任务的“第一站”，要求它确定在进行 bug 修复、功能开发或分析时需要检查哪些文件。这取代了传统上在开始工作前手动浏览代码库和收集上下文的耗时过程。

跨代码库独立调试

团队现在有信心处理不熟悉代码库部分的 bug，而无需向他人求助。他们可以问 Claude “你觉得你能修复这个 bug 吗？我看到的行为是这样的”，并经常能立即取得进展，这在以前由于所需的时间投入是不可行的。

通过内部测试进行模型迭代测试

Claude Code 自动使用最新的研究模型快照，使其成为他们体验模型变化的主要方式。这为团队在开发周期中提供了关于模型行为变化的直接反馈，这是他们在之前的发布中从未体验过的。

消除上下文切换的开销

他们不再需要复制粘贴代码片段并将文件拖入 Claude.ai，同时还要详细解释问题，现在可以直接在 Claude Code 中提问，无需额外的上下文收集，从而显著减少了心智负担。

增强了处理不熟悉领域的信心

团队成员可以独立调试 bug 并调查不熟悉代码库中的事故。

在上下文收集中节省了大量时间

Claude Code 消除了复制粘贴代码片段和将文件拖入 Claude.ai 的开销，减轻了心智上的上下文切换负担。

加速轮岗员工上手速度

轮岗到新团队的工程师可以快速熟悉不熟悉的代码库并做出有意义的贡献，而无需与同事进行大量咨询。

提升开发者幸福感

团队报告称，随着日常工作流程中的摩擦减少，他们感到更快乐、更高效。

将其视为迭代伙伴，而非一次性解决方案

不要指望 Claude 能立即解决问题，而是把它当作一个与你一起迭代的合作者。这种方法比试图在第一次尝试中就获得完美的解决方案效果更好。

用它来建立在不熟悉领域的信心

不要犹豫去处理你专业领域之外的 bug 或调查事故。Claude Code 使得在通常需要大量上下文建立的领域独立工作成为可能。

从最少的信息开始

从你需要的最低限度的信息开始，让 Claude 引导你完成整个过程，而不是一开始就提供大量的解释。

增长营销团队专注于在付费搜索、付费社交、移动应用商店、电子邮件营销和 SEO 等领域建立效果营销渠道。作为一个只有一人的非技术团队，他们使用 Claude Code 来自动化重复性的营销任务，并创建通常需要大量工程资源的 AI 智能体工作流。

自动化 Google Ads 广告创意生成

团队构建了一个 AI 智能体工作流，该工作流可以处理包含数百个现有广告及其效果指标的 CSV 文件，识别表现不佳的广告进行迭代，并生成符合严格字符限制（标题 30 个字符，描述 90 个字符）的新变体。通过使用两个专门的子智能体（一个用于标题，一个用于描述），该系统可以在几分钟内生成数百个新广告，而无需在多个广告系列中手动创建。这使他们能够大规模地进行测试和迭代，这是以前需要花费大量时间才能实现的。

用于批量创意制作的 Figma 插件

他们没有手动复制和编辑用于付费社交广告的静态图片，而是开发了一个 Figma 插件，该插件可以识别框架并通过替换标题和描述来以编程方式生成多达 100 个广告变体，将需要数小时复制粘贴的工作缩短为每批半秒。这使得创意产出提高了 10 倍，让团队能够在关键社交渠道上测试数量庞大的创意变体。

用于广告活动分析的 Meta Ads MCP 服务器

他们创建了一个与 Meta Ads API 集成的 MCP 服务器，以便直接在 Claude Desktop 应用内查询广告活动表现、支出数据和广告效果，从而无需在不同平台之间切换进行性能分析，节省了宝贵的时间，因为每一分效率的提升都意味着更好的投资回报率。

利用内存系统进行高级提示工程

他们实现了一个基本的内存系统，该系统记录了广告迭代中的假设和实验，使得系统在生成新变体时能够将之前的测试结果纳入上下文，创建了一个自我改进的测试框架。这使得系统性的实验成为可能，而这些实验是无法手动追踪的。

在重复性任务上节省了大量时间

Claude Code 将广告文案创作时间从 2 小时缩短到 15 分钟，让团队能够专注于更具战略性的工作。

创意产出增加 10 倍

通过自动广告生成和与 Figma 集成以获取最新的视觉设计元素，团队现在可以在各个渠道上测试数量庞大的广告变体。

像一个更大的团队一样运作

团队能够处理传统上需要专门工程资源的大型开发任务。

战略重点转移

团队可以将更多时间用于整体战略和构建 AI 智能体自动化，而不是手动执行。

识别支持 API 的重复性任务

寻找涉及使用带有 API 的工具（如广告平台、设计工具、分析平台）进行重复操作的工作流程。这些是自动化的主要候选对象，也是 Claude Code 提供最大价值的地方。

将复杂工作流分解为专门的子智能体

不要试图在一个提示或工作流中处理所有事情，而是为特定任务创建单独的智能体（比如一个标题智能体和一个描述智能体）。这使得调试更容易，并在处理复杂需求时提高输出质量。

在编码前进行充分的头脑风暴和提示规划

在前期花大量时间使用 Claude.ai 来构思整个工作流，然后让 Claude.ai 为 Claude Code 创建一个全面的提示和代码结构以供参考。此外，要逐步进行，而不是要求一次性解决问题，以避免 Claude 因任务过于复杂而不堪重负。

产品设计团队支持 Claude Code、Claude.ai 和 Anthropic API，专注于构建 AI 产品。即使是非开发人员也可以使用 Claude Code 来弥合设计与工程之间的传统鸿沟，使他们能够直接实现自己的设计愿景，而无需与工程师进行大量的反复迭代。

前端润色和状态管理变更

团队不再为视觉调整（字体、颜色、间距）创建大量的设计文档并与工程师进行多轮反馈，而是直接使用 Claude Code 实现这些变更。工程师们注意到，设计师们正在进行“通常不会看到设计师做的大型状态管理变更”，这使他们能够实现他们所设想的精确质量。

GitHub Actions 自动化工单处理

通过使用 Claude Code 的 GitHub 集成，他们只需提交描述所需更改的问题/工单，Claude 就会自动提出代码解决方案，而无需打开 Claude Code，从而为他们积压的润色任务创建了一个无缝的 bug 修复和功能优化工作流。

快速交互式原型制作

通过将模型图粘贴到 Claude Code 中，他们可以生成功能齐全的原型，工程师可以立即理解并在此基础上进行迭代，这取代了传统的静态 Figma 设计，后者需要大量的解释和转换才能成为可用代码。

发现边界情况和理解系统架构

团队使用 Claude Code 来规划错误状态、逻辑流程和不同的系统状态，使他们能够在设计阶段就识别出边界情况，而不是在开发后期才发现，从而从根本上提高了他们初始设计的质量。

复杂的文案更改和法律合规

对于像在整个代码库中移除“研究预览”信息这样的任务，他们使用 Claude Code 查找所有实例，审查周围的文案，与法务部门实时协调更改，并实施更新。这个过程只用了两次 30 分钟的电话会议，而不是一周的反复协调。

核心工作流程的变革

Claude Code 成为主要的设计工具，80% 的时间里 Figma 和 Claude Code 都是打开的。

执行速度提高 2-3 倍

以前需要与工程师进行大量反复沟通的视觉和状态管理变更，现在可以直接实现。

周期时间从数周缩短到数小时

像 Google Analytics 发布信息这样需要一周协调的复杂项目，现在只需两次 30 分钟的电话会议就能完成。

两种截然不同的用户体验

开发者获得了“增强型工作流”（执行更快），而非技术用户则获得了“天哪，我竟然也成了开发者”的工作流。

改善了设计与工程的协作

Claude Code 促进了更好的沟通和更快的问题解决，因为设计师理解了系统的限制和可能性，而无需与工程师紧密合作。

从工程师那里获得适当的设置帮助

让工程团队的同事帮助进行初始的代码库设置和权限配置——对于非开发人员来说，技术上的上手过程具有挑战性，但一旦配置完成，它将彻底改变日常工作流程。

使用自定义内存文件来引导 Claude 的行为

创建具体的指令，告诉 Claude 你是一个几乎没有编码经验的设计师，需要详细的解释和更小、更增量的更改。这极大地提高了 Claude 回应的质量，使其不再那么令人生畏。

利用粘贴图片进行原型制作

使用 Command+V 将截图直接粘贴到 Claude Code 中。它在读取设计并生成功能性代码方面表现出色，使其在将静态模型图转化为工程师可以立即理解和构建的交互式原型方面非常有价值。

强化学习（RL）工程团队专注于 RL 中的高效采样和跨集群的权重迁移。他们主要使用 Claude Code 来编写中小型功能、进行调试和理解复杂的代码库，并采用一种包含频繁检查点和回滚的迭代方法。

有监督的自主功能开发

团队让 Claude Code 在提供监督的情况下编写大部分中小型功能的代码，例如为权重迁移组件实现认证机制。他们以交互方式工作，允许 Claude 主导，但在其偏离轨道时进行引导。

测试生成和代码审查

在自己实现更改后，团队会要求 Claude Code 添加测试或审查他们的代码。这种自动化的测试工作流程在常规但重要的质量保证任务上节省了大量时间。

调试和错误调查

他们使用 Claude Code 来调试错误，结果好坏参半。有时它能立即识别问题并添加相关测试，而其他时候则难以理解问题，但总的来说，在有效时仍能提供价值。

代码库理解和调用栈分析

他们工作流程中最大的变化之一是使用 Claude Code 来快速获取相关组件和调用栈的摘要，取代了手动阅读代码或生成大量调试输出。

Kubernetes 操作指导

他们经常向 Claude Code 询问 Kubernetes 操作，这些操作否则需要大量谷歌搜索或询问基础设施工程的同事，从而能立即获得配置和部署问题的答案。

实验性方法的实现

他们现在使用一种“尝试并回滚”的方法，频繁提交检查点，以便他们可以测试 Claude 的自主实现尝试，并在需要时进行回滚，从而实现了更具实验性的开发。

文档编写加速

Claude Code 自动添加有用的注释，节省了大量的文档编写时间，尽管他们也指出，它有时会在奇怪的地方添加注释或使用有问题的代码组织方式。

有限制的提速

虽然 Claude Code 可以在他们“相对较少的时间”投入下实现中小型 PR，但他们承认，它在第一次尝试中成功的几率大约只有三分之一，需要额外的指导或手动干预。

为特定模式自定义你的 Claude.md 文件

在你的 Claude.md 文件中添加指令，以防止 Claude 重复犯工具调用错误，例如告诉它“运行 pytest 而不是 run，不要不必要地 cd – 只需使用正确的路径”。这显著提高了一致性。

使用检查点密集的工作流

随着 Claude 进行更改，定期提交你的工作，这样当实验不成功时，你可以轻松回滚。这使得在没有风险的情况下可以采用更具实验性的开发方法。

先尝试一次性解决，然后协作

给 Claude 一个快速的提示，让它先尝试完整的实现。如果成功了（大约三分之一的时间），你就节省了大量时间。如果没有，再切换到更具协作性、引导性的方法。

法务团队通过实验和了解 Anthropic 产品的好奇心，发现了 Claude Code 的潜力。此外，一位团队成员有一个个人用例，即为家人创建无障碍工具和为工作创建原型，这展示了该技术对非开发人员的强大能力。

为家人定制的无障碍解决方案

团队成员为因医疗诊断而有语言障碍的家人构建了沟通助手。在短短一小时内，一个人使用原生的语音转文本功能创建了一个预测性文本应用，该应用可以建议回复并使用语音库将其读出，解决了言语治疗师推荐的现有无障碍工具的不足之处。

法务部门工作流自动化

团队创建了“电话树”系统的原型，帮助团队成员联系到 Anthropic 合适的律师，展示了法务部门如何在没有传统开发资源的情况下为常见任务构建自定义工具。

团队协调工具

经理们构建了 G Suite 应用程序，可以自动化每周的团队更新，并跟踪各产品的法律审查状态，让律师只需通过简单的按钮点击就能快速标记需要审查的项目，而无需管理电子表格。

用于解决方案验证的快速原型制作

他们使用 Claude Code 快速构建功能性原型，然后展示给领域专家（例如向加州大学旧金山分校的专家展示无障碍工具），以验证想法并在投入更多时间之前识别现有解决方案。

在 Claude.ai 中规划，在 Claude Code 中构建

他们使用两步流程：首先在 Claude.ai 中进行头脑风暴和规划，然后转到 Claude Code 进行实现，要求它放慢速度，逐步工作，而不是一次性输出所有内容。

视觉优先的方法

他们经常使用截图向 Claude Code 展示他们想要的界面样子，然后根据视觉反馈进行迭代，而不是用文本描述功能。

原型驱动的创新

他们强调克服分享“傻瓜式”或“玩具级”原型的恐惧，因为这些演示能激励他人看到他们未曾考虑过的可能性。

MCP 集成担忧

产品律师使用 Claude Code 立即识别深度 MCP 集成的安全隐患，并指出随着 AI 工具访问更多敏感系统，保守的安全策略将成为障碍。

合规工具的优先级

他们主张随着 AI 能力的扩展，应迅速构建合规工具，认识到创新与风险管理之间的平衡。

首先在 Claude.ai 中进行详尽规划

在转到 Claude Code 之前，使用 Claude 的对话界面来充实你的整个想法。然后要求 Claude 将所有内容总结成一个分步的实现提示。

增量式和可视化工作

要求 Claude Code 放慢速度，一次实现一个步骤，这样你就可以复制粘贴而不会不知所措。大量使用截图来展示你想要的界面样子。

尽管不完美也要分享原型

克服隐藏“玩具”项目或未完成工作的冲动。分享原型有助于他人看到可能性，并在通常不互动的部门之间激发创新。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

了解何时使用推理模型，以及它们与 GPT 模型有何不同。

OpenAI 目前提供两大类模型：

这两种模型家族在使用和效果上都有所不同。本文将介绍：

与 GPT 模型相比，OpenAI 的 o 系列模型（推理模型）在不同类型的任务上更出色，需要使用不同的提示方式。并非哪一种模型一定「更好」，而是各有擅长的领域。

你可以根据需求，思考下列问题：

如果你的任务优先考虑速度与成本，并且任务本身相对明确、好定义，那么使用 GPT 模型就非常合适。
但如果你更注重准确度和可靠性，而且问题本身很复杂、有多个步骤，那么 O pen AI 建议选择 o 系列模型。

大多数情况下，你也可以把这两种模型结合起来使用：用 o 系列模型进行「智能规划和决策」，再让 GPT 模型去执行具体步骤。

示例：GPT-4o 和 GPT-4o mini 先处理订单信息与客户资料，找出订单问题和退货政策，然后将这些信息提供给 o3-mini，由它根据政策最终决定退货是否可行。

下面列出了一些实际场景，这些案例来自 OpenAI 的客户和 OpenAI 内部，希望能帮助大家更好地理解 o 系列模型（推理模型）适合用在哪些地方。不过，这并不是一个覆盖所有可能用例的完整清单，而是给出一些在测试中行之有效的思路。

准备好使用推理模型了吗？点击这里直达快速入门 →

推理模型特别擅长接收零散、有限的信息，然后根据简单提示去理解用户意图，并处理那些不够明确的指令。它们经常会先问一些澄清性的问题，而不是盲目猜测或随意填补空白。

「o1 的推理能力让 OpenAI 的多智能体平台 Matrix 在处理复杂文档时，能给出详尽且格式良好的回复。举个例子，o1 让 Matrix 可以轻松找出信用协议（Credit Agreement）中受限支付能力（restricted payments capacity）下可以使用的各种『篮子』（baskets），而只需要一个简单提示。过去没有任何模型能这么出色。相比于其他模型，在对密集的信用协议进行复杂提问时，o1 在 52% 的问题上有更好的表现。」

——Hebbia，为法律和金融提供 AI 知识平台

当你需要处理大量无结构信息时，推理模型能很有效地提炼出最相关的部分来回答问题。

「在分析某公司收购案时，o1 审阅了几十份公司文件，比如合同、租约等，去寻找可能影响交易的关键条件。它需要标记重要条款时，甚至在文件脚注中看到了一个非常关键的『变更控制』（change of control）条款：如果公司被出售，那需要立刻偿还 7500 万美元的贷款。o1 的极致细致能力帮助 OpenAI 的 AI 探索工具为金融专业人士找出交易中至关重要的信息。」

——Endex，AI 驱动的金融情报平台

OpenAI 发现，推理模型在处理数百页的复杂文件时（比如法律合同、财务报表或保险索赔等），能很好地分析文件内在逻辑并做出决策。它们擅长挖掘文档之间的对照关系，并据此推断其中暗含的规则。

「在税务研究里，需要同时对多份文件进行综合分析才能得出最终、连贯的结论。OpenAI 把 GPT-4o 换成 o1 后发现，o1 更善于整合多份文件之间的关系并推导出各自交叉影响，让最终的结论比单一文档中能看到的内容更有深度。OpenAI 因此看到终端到终端（end-to-end）性能提升了 4 倍，真的很令人惊讶。」

——Blue J，为税务研究提供 AI 平台

此外，推理模型也很擅长根据各种复杂政策和规则进行推理，并把这些规则应用到实际任务中，得出合理的结论。

「在做金融分析时，分析师常常要面对股东权益方面的复杂情境，还要理解相关法律的细微差别。OpenAI 曾用一个常见但比较棘手的问题来测试了市面上约 10 个模型：如果公司进行融资，对现有股东尤其行使『反摊薄保护』（anti-dilution）的那些股东会有什么影响？这个问题需要推理融资前后估值，还要处理环环相扣的『循环摊薄』，就算优秀的金融分析师也要花 20~30 分钟才能搞清楚。OpenAI 发现 o1 和 o3-mini 在这方面做得近乎完美！模型甚至能给出一张清晰的计算表格，展现对一个投资了 10 万美元的股东有何影响。」

——BlueFlame AI，为投资管理提供 AI 平台

推理模型在做多步骤的「自主」规划和战略制定方面发挥着关键作用。OpenAI 常看到的成功做法是先让推理模型扮演「策划者」，制定详细的多步骤解决方案，再根据每个步骤对「速度/智能」需求的不同，有选择地交给 GPT 模型或 o 系列模型去执行。

「OpenAI 用 o1 来做多智能体系统（agent infrastructure）中的规划者，让它负责指挥其他模型完成多步骤的任务。OpenAI 发现，o1 非常擅长选择要用什么数据类型，也很擅长把大问题拆解成小块，让其他模型聚焦执行。」

——Argon AI，服务于制药行业的 AI 知识平台

「o1 为 OpenAI Lindy 的许多『代理式工作流』提供支持。Lindy 是一个工作助理 AI，能通过函数调用（function calling）去获取你的日历和邮件信息，然后自动帮你安排会议、发邮件、管理日常事务。OpenAI 把一些原本运行不稳定的多步骤流程全部切到 o1 上，结果代理的表现几乎是一夜之间就变得近乎完美！」

——Lindy.AI，一个专注于工作场景的 AI 助手

截至目前，o1 是唯一支持图像理解的推理模型。它与 GPT-4o 的最大区别在于：o1 能处理特别复杂的视觉信息，比如结构不明确的图表或清晰度不佳的照片。

「OpenAI 为线上上架的数百万产品提供风险和合规审核，比如奢侈品仿制、濒危物种、管制品等。GPT-4o 在最难的图像分类任务中只能达到 50% 的准确率，而 o1 能做到 88%，OpenAI 甚至没有对流程做任何修改。」

——Safetykit，负责商家监控的 AI 平台

OpenAI 内部测试也发现：o1 能从复杂的建筑图纸中看出具体的材料和结构信息，进而生成更完整的材料清单。更惊喜的是，o1 还能跨页面匹配，比如先在图纸中的图例（legend）看到「PT」代表「压力处理木材」（pressure treated），然后在图纸的其他页面上正确应用这一概念，尽管并没有明确地告诉它需要这么做。

推理模型在代码审查和改进时也表现出色，往往可以在后台执行代码审阅任务，因为此类需求对延迟的容忍度更高。

「OpenAI 在 GitHub、GitLab 等平台上提供自动化的 AI 代码审阅服务。虽然代码审查过程对延迟不是特别敏感，但却需要理解多文件之间的代码差异。在这方面，o1 表现非常好，它能可靠地识别出对代码库做出的微小改动，而人类审阅者可能会漏掉。切换到 o 系列模型后，OpenAI 的产品转化率提升了 3 倍之多。」

——CodeRabbit，AI 代码审阅初创公司

GPT-4o 和 GPT-4o mini 因为延迟更低，也许更适合写代码，但对于那些不太敏感于执行速度的代码生成需求，o3-mini 有时也能带来更好的复杂性处理。

「o3-mini 写出的代码质量通常很高，而且往往能在明确的问题中得到正确解答，哪怕是非常具有挑战性的编码任务。其他模型也许只能应付小规模、快速的代码迭代，而 o3-mini 在构思、规划和实现复杂软件系统时表现更突出。」

——Codeium，提供 AI 驱动代码插件的初创公司

推理模型还经常被用于对其他模型的输出结果做评测和打分，特别是在需要数据验证的领域里（如医疗保健），保证数据集的质量和可靠性。传统的验证方法通常依赖预先定义的规则和模式，而像 o1 和 o3-mini 这样的高级模型，可以通过理解上下文和推理，对数据做更灵活智能的验证。

「不少客户在 Braintrust 的评测流程中使用了『模型做法官』的功能，比如某个医疗企业先用 GPT-4o 对患者问题进行概要提炼，再用 o1 来给这个概要的质量打分。结果发现，用 GPT-4o 做法官的 F1 分值只有 0.12，而用 o1 做法官，F1 分值达到了 0.74！对这些用户来说，o1 的推理能力在发现微妙差异和复杂场景的评分上表现极好。」

——Braintrust，AI 评估平台

这些模型最适合简洁、直接的提示。一些提示技巧（比如让模型「逐步思考」）不一定能提升性能，有时反而会降低效果。以下是一些提示技巧的最佳实践。

以上就是有关「推理模型」与 GPT 模型的区别、使用场景，以及给推理模型下指令时的一些最佳实践。希望这些指南能帮助你更好地发挥 o 系列和 GPT 系列模型在不同任务中的优势，实现更高效、更准确的 AI 解决方案。