最近这段时间，大模型发布就跟下饺子似的，一个接一个往外冒。

前脚 Gemini 3 Pro 刚抢了两周风头，后脚 Claude Opus 4.5 刚刚就正式发布，还是主打编程，还是那个熟悉的味道。

Anthropic 官方宣称 Opus 4.5 整体更聪明、更省心。遇到编程、搭 agents、操控电脑这些「系统级任务」依然是全球数一数二的水平。日常的研究、做 PPT、处理表格这些案头活，也都明显变强了。

今天起，Opus 4.5 已经全面开放，可以通过应用、API，还有三大主流云平台用起来。开发者只要在 Claude API 里调用 claude-opus-4-5-20251101 就行。

随发布而来的，是一整个工具链升级。开发者平台、Claude Code、Chrome 插件、Excel、桌面端改造，还有「长对话不卡顿」。从应用到 API，再到云平台，这次是真的全线铺开。

Anthropic’s New Claude Opus 4.5 Reclaims the Coding Crown – The New Stack

大模型集体「上新季」，Opus 4.5 强势压轴

从官方和测试者的反馈看，Claude Opus 4.5 对「模糊需求」的理解力得到了明显提升，复杂 bug 自行定位也更稳，不少提前试用的客户觉得 Opus 4.5 是真的能「理解」他们想要啥。

在真实场景的软件工程测试 SWE-Bench Verified 里，它是头一个拿到 80% 以上分数的模型。

Opus 4.5 的代码质量全面升级，在 SWE-bench Multilingual 涵盖的八种编程语言里，它在其中七种都拔得头筹，表现相当亮眼。

而举例而言，Anthropic 团队把 Opus 4.5 扔进了公司招性能工程师时用的高难度测试题里，结果在规定的两小时内，Claude Opus 4.5 的得分超过了所有人类候选人。

虽然编程测试只能衡量技术能力和时间压力下的判断力，那些多年经验积累出来的直觉、沟通协作能力，这些同样重要的素质并不在考察范围内。

除却软件工程，Claude Opus 4.5 的整体能力也迎来了全面开花，在视觉、推理和数学方面都比前代模型强，并且在多个重要领域都达到了业界领先水平：

更关键的是，模型的能力甚至开始超越现有的一些评测标准了。

在智能体能力测试 τ²-bench 里就出现了这么个场景：测试设定模型扮演航空公司客服，帮一位焦虑的乘客。

按照规则，基础经济舱机票是不能改的，所以测试预期模型会拒绝乘客的请求。结果 Opus 4.5 想出了一个巧妙方案：先把舱位从基础经济舱升级到普通经济舱，然后再改航班。

这办法完全符合航空公司政策，却不在测试的预期答案范围内。从技术角度说，这算是测试失败了，但这种创造性解决问题的方式，恰恰展现了 Opus 4.5 的独特之处。

当然了，在另一些场景下，这种「钻规则空子」的行为可能就不那么受欢迎了。如何防止模型以非预期方式偏离目标，这是 Anthropic 安全测试重点关注的方向。

Claude 无处不在，桌面、浏览器、Excel 全接入

随着 Opus 4.5 的推出，Claude Code 获得了两项重大更新。

计划模式（Plan Mode）现在能生成更精确的执行计划了，Claude 会在操作前主动提澄清性问题，然后生成一个用户可编辑的 plan.md 文件，再根据这计划执行任务。

此外，Claude Code 现在已经登陆桌面应用了。你可以同时跑多个本地或远程会话，比如一个智能体负责修代码错误，另一个负责在 GitHub 上检索资料，第三个就更新项目文档。

对于 Claude 应用用户来说，长对话不会再被打断了。Claude 会在需要的时候自动总结早期上下文，让对话持续下去。

Anthropic 研究产品管理负责人 Dianne Na Penn 在接受采访时表示：

「我们在 Opus 4.5 的训练过程中提升了对长上下文的整体处理能力，但光有更长的上下文窗口是不够的。知道哪些信息值得记住，同样非常关键。」

这些改进也实现了 Claude 用户长期呼吁的一项功能：「无尽对话」。这功能能够让付费用户在对话超过上下文窗口限制时也不会中断，模型会自动压缩上下文记忆，而不用提醒用户。

Claude for Chrome 也已经向所有 Max 用户开放了，可以让 Claude 直接在浏览器多个标签页之间执行任务。

Claude for Excel 的 Beta 测试范围已经扩展到 Max、Team 和 Enterprise 用户了。

对于能使用 Opus 4.5 的 Claude 和 Claude Code 用户，Anthropic 已经取消了和 Opus 相关的使用上限。
对于 Max 用户和 Team Premium 用户，Anthropic 也提高了整体使用限额，用户可使用的 Opus token 数量与之前使用 Sonnet 时大致相同。随着未来更强模型的出现，配额也会根据情况相应更新。

让模型「更聪明也更省」，Opus 4.5 迎来底层大升级

随着模型变得更聪明，它们能用更少的步骤解决问题：减少反复试错、降低冗余推理、缩短思考过程。

Claude Opus 4.5 和前代模型比，在实现相同甚至更优结果的情况下，用的 tokens 数量明显少了。

当然了，不同任务需要不同的平衡。

有时开发者希望模型能持续深入思考，有时又需要更快速灵活的响应。

所以，API 里新加了一个叫 effort 的参数，让你可以根据需求选：要么优先省时间和成本，要么最大化模型能力。任君选择。
当设置为中等 effort 等级时，Opus 4.5 在 SWE-bench Verified 测试中和 Sonnet 4.5 的最佳成绩持平，但输出 tokens 数减少了 76%。

而在最高 effort 等级下，Opus 4.5 的表现比 Sonnet 4.5 高出 4.3 个百分点，同时还减少了 48% 的输出量。

凭借 effort 控制、上下文压缩（context compaction）和高级工具调用能力，Claude Opus 4.5 能跑更久、完成更多任务，而且需要的人工干预更少了。

此外，真正的 AI 智能体需要在成百上千种工具之间无缝协作。

想象一个 IDE 助手集成了 Git、文件管理、测试框架和部署流程，或者一个运营智能体同时连着 Slack、GitHub、Google Drive、Jira 和几十个 MCP 服务器。

问题在于，传统方式会把所有工具定义一次性塞进上下文。拿连接五个服务器的系统来说，GitHub 需要 26K tokens，Slack 需要 21K tokens，Sentry、Grafana、Splunk 加起来又是 8K tokens。

对话还没开始呢，就已经占了 55K tokens 了。要是再加上 Jira，轻松突破 100K tokens。更麻烦的是，当工具名字相似时，模型容易选错工具或者传错参数。

Anthropic 推出了三项新功能来解决这些问题。

Tool Search Tool 让 Claude 按需动态发现工具，只加载当前任务需要的部分，token 使用量能减少约 85%。

Programmatic Tool Calling 让 Claude 在代码里直接调用工具，避免每次调用都要完整推理一遍。

Tool Use Examples 则提供统一标准，通过示例而不是 JSON schemas 来展示工具的正确用法。

内部测试显示，启用 Tool Search Tool 后，Opus 4 在 MCP 测试中的准确度从 49% 提升到 74%，Opus 4.5 从 79.5% 提升到 88.1%。
Claude for Excel 就是利用 Programmatic Tool Calling 来处理几千行数据，而不会让上下文窗口过载。

Anthropic 的上下文管理和记忆能力明显提升了模型在智能体（agent）任务中的表现。

Opus 4.5 还能高效管理多个子智能体（subagents），从而搭建复杂且协调良好的多智能体系统。在测试中，结合这些技术后，Opus 4.5 在深度研究类评估中的表现提升了将近 15 个百分点。

开发者平台（Developer Platform）也在持续变得更具可组合性，希望提供灵活的「模块化构建」能力，让你能根据具体需求自由控制模型的效率、工具使用和上下文管理，搭建出理想的智能系统。

虽然这次 Opus 4.5 的升级足够亮眼，但一个越来越清晰的趋势是：不同模型的「性格」差异正在被放大。

从 Claude 过往的产品线来看，Opus 这类「超大杯」依旧最擅长编程、系统级操作、结构化推理；但如果是文案工作，Sonnet 的表现和性价比往往更对路。

这次发布，也再次印证了这一点。

未来选模型，不光要看跑分榜，还得看它的「做事」方式是不是跟你合拍。换句话说，选择模型，倒是越来越像挑同事了。

附上官方博客地址：
https://www.anthropic.com/news/claude-opus-4-5

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

yuesir6:

Claude Code Max 20x 拼车 加上我拼成三人车 目前寻找两位车友 已经稳定了半年多了 从 claude code 开始就开始使用 Max 20x 的周限额约为 800-900 刀 按照额度每人均分（已经部署 CRS 每个人的用量公开透明） 大概一周每人 270 刀的 sonnet 同时我还开通有一个 Pro 账户用于进一步冗余和应急 价格：人均 500 人民币（包含一个 max 20x 账号和一个 pro 账号） 欢迎需要的车友评论区或者私信我

Diagnosing problems using the Unified log is a complicated business that requires understanding, insight, experience and a systematic approach. As few of us feel competent to wade through thousands of log entries trying to spot where things go wrong, this might seem an ideal opportunity for the use of AI. I’m very grateful to one of our regular readers for the opportunity to demonstrate how Claude coped with diagnosing a troublesome problem they’ve been having with the Clock app in Tahoe.

Signs and symptoms

When you’re diagnosing any problem, you should start with a clear account of its signs and symptoms before even thinking of resorting to the log. A good physician may take an hour or more obtaining a full history and examining a patient before they start thinking about performing any special investigations. Even though signs and symptoms may not lead you to a diagnosis, they should help you direct your investigations to best effect.

In this case, although the Clock app is launching, when displaying some views the content is missing. We therefore agreed to capture the log from the moment of launch from the Finder until one of the problematic views displayed. That’s easy to achieve by double-clicking the app when the menu bar clock has just turned to display 00 seconds, then checking the time again when the view has been displayed. Add a couple of seconds to the latter to determine the period to view in LogUI.

What’s normal?

Recognising what’s abnormal in the log is only possible if you know what the normal looks like. It’s often perfectly normal to see error messages, but knowing which are relevant is more difficult. In this case, I cheated and obtained a matching log extract from launching the Clock app on another Mac running the same version of Tahoe, making it simple to compare the two.

An interesting exercise for the reader is to submit a perfectly normal log extract to AI, with a vague description like “problems starting the app”, and seeing if it reports that as being normal. I doubt that it would.

Preparing a log extract for submission to AI

LogUI can provide log extracts saved to Rich Text Format, preserving the entry fields, although I doubt whether any AI will be able to interpret those correctly. Perhaps the best route is to save the extract in RTF, and save that in turn as plain text. A longer way round is to:

• Save the whole extract as a JSON file, to preserve the whole record.
• Use the Search tool to display the entries you want to submit for analysis.
• Click on the Reduce tool to remove the unwanted entries.
• Save the remaining entries in Rich Text, then save that in plain text format.

That also allows you to submit a shorter extract.

Claude’s report

AIs like Claude are thoroughly professional in their reporting, even when they’re utterly incorrect. In this case, Claude’s report is headed Complete Analysis of the Problem, and appears a confident and detailed assessment presented logically. It first establishes:

• The App DOES Launch Successfully
• Main Issue: Continuous Assertion Invalidation
• Infinite State Loop
• Critical Errors Identified

supporting those with digested “quotations” from the log, although in fact most of them are rendered in Claude’s words, not those in the log entries themselves.

It then leaps on to give the Final Diagnosis that the Clock app:

• Launches
• Creates its scenes and interfaces
• Registers functionalities (alarm, stopwatch, timer)
• Fails to maintain the assertions necessary to remain active
• The system continuously invalidates its resource requests.

Those are embellished with appropriate and emoji.

Following those conclusions, it cites what it terms Key Log Evidence in support of that diagnosis. Among those are the following.

Critical Error at Launch

For this, it quotes part of the message from
00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)
and a similar entry.

However, it doesn’t point out that those are rapidly followed by
00.969966 com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] set Memory Limits to Soft Inactive (800)
00.970684 com.apple.launchservices LAUNCH: Successful launched 0x0-0x3b03b pid=1921 com.apple.clock '[private]'
which would appear to contradict this being a “critical error”.

Kernel Warning

Claude’s report next misquotes one of the log entries as reporting
Clock[19237] triggered unmask of range (1 of 16384:0000->0x1ce000000 of DVLD shared region in VM map 0x5c946dd8d4c72dbbf
when in fact the full entry reads
10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.
It gives no reason for changing unnest to unmask, DYLD (which makes sense) to DVLD (which is nonsense), or changing the range given.

For interest, I used LogUI’s Gloss feature to submit that entry to ChatGPT for its explanation:
This log entry is a system notice from the kernel indicating that a portion of the DYLD shared region in the virtual memory (VM) map has been unnested. […] In short: The macOS kernel is reporting that the process Clock caused a part of the shared dynamic library cache to become private memory. This is expected behaviour when certain debugging or memory operations occur, but it will temporarily use more RAM until the process exits.

Continuous Assertion Cycle and Scene Management Loop

Claude then claims that the perfectly normal entries made by RunningBoard and FrontBoard demonstrate a continuous assertion cycle and scene management loop. Anyone who has read my account of RunningBoard would realise that is a misreading of what is both common and normal.

Claude’s Possible Solutions

Nearing the end of the report, Claude recommends four possible solutions:

• Reset system permissions: sudo tccutil reset All com.apple.clock
• Rebuild launch services cache: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
• Verify system integrity: sudo /usr/libexec/repair_packages --verify --standard-pkgs
• If everything fails: This could be a specific bug in macOS Tahoe with the Clock app that requires a system update.

The first is misleading, as TCC has nothing to do with system permissions, but privacy controls. Although Claude has made no comments at all on entries by TCC, I have checked through those thoroughly and there’s no evidence of any problem with that subsystem. The command recommended isn’t likely to do anything useful, either.

Despite Claude having provided no evidence of any problem with LaunchServices, its second solution is to perform a full reset of the LaunchServices registry (not cache), although I’m not sure the command given is correct for that. This used to be a popular panacea in the past, but is now more trouble than it’s likely to be worth. The last time I reviewed this for Sequoia, I wrote:
“Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.”

Yet Claude gives no warnings of any adverse effects.

The third solution given is the most puzzling. repair_packages was used to repair System permissions in versions of macOS up to El Capitan. It hasn’t been used since, makes no sense at all in Tahoe with SIP and the SSV, and that command no longer exists anyway. I find it surprising that Claude should be recommending a course of action from ten years ago.

The final recommendation is manifestly ineffective, as this problem has persisted across updates from 26.0 to 26.0.1 and now 26.1.

Nowhere does Claude recommend the obvious course of action to contact Apple Support.

Claude’s Summary

The slick summary rounding off Claude’s Complete Analysis of the Problem states confidently that its root cause “appears to be either:”

1. “A system-level bug in macOS Tahoe’s memory status handling for this specific app”
2. “Corruption in the app’s entitlements or sandbox configuration”
3. “A conflict between the app’s resource requirements and what the system is willing to grant”

with the parting comment:
The error code 22 (EINVAL – Invalid argument) in the memorystatus call suggests the app is requesting memory limits or priority settings that the kernel considers invalid for its configuration.

None of those comments is supported in reality, nor by the evidence in the log extract.

My final test was to compare the log entries that Claude singled out as being diagnostic of the problem it has ‘completely analysed’, with those from my Mac mini M4 Pro, whose Clock app works perfectly. You won’t be surprised to learn that, in those respects at least, the two logs are identical. For the avoidance of doubt, that includes the “Kernel Warning” and “Critical Error at Launch” entries that Claude considered diagnostic.

My Summary

When presented with a log extract, Claude misidentified and misread log entries, and introduced errors in reporting what it claimed were the most important diagnostic entries. Its recommended solutions were ineffective, unwise, or a decade out of date. Neither did it give any warnings for their adverse effects, or recommend contacting Apple Support.

This doesn’t say that AI can’t help interpret macOS Unified log entries, and can’t do better in the future. But I hope it demonstrates the reality of what it will do today.

Postscript

Following up on Claude’s suggested solutions, I can confirm that the suggested tccutil command is ineffective, and that Tahoe has removed the -kill option from lsregister “because it was dangerous and no longer useful”. As the third solution was removed years ago, that leaves only the last of its suggestions that is valid.

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

CLAUDE.md 是代码库的根目录中最重要的文件，它是代理理解你项目运作方式的核心规则。如何维护它，取决于使用场景。

正确示例:
“对于复杂的…用法，或当您遇到 FooBarError 错误时，请参阅 path/to/docs.md 以获取高级故障排除步骤。”

你需要向代理建议阅读这份文档的理由和时机。

正确示例:
“不要使用 --foo-bar，请优先选择 --new-baz。”

建议在编码会话中至少运行一次 /context，以了解你的 200k 令牌上下文窗口是如何被消耗的。

在一个大型单体仓库中，一次新的会话基本消耗可能就高达约 20k 令牌（10%），剩下的 180k 会很快被填满。

你可以将上下文窗口想象成磁盘空间，它会随着你的工作而填满。几分钟或几小时后，你需要清理（紫色部分）来腾出空间。

小提醒：
不要信任自动压缩。
使用 /clear 进行简单任务，并利用存储方法为复杂任务创建持久的外部记录。

我将斜杠命令视为常用提示词的快捷方式，仅此而已。我的设置非常精简：

小提醒：
如果你发现自己有一长串复杂的自定义斜杠命令，那你可能过度思考了。
AI 代理的魅力在于自然语言交互，一旦你开始强迫自己和团队去记一堆指令，就违背了初衷。
将斜杠命令用作简单的个人快捷方式，而不是用来替代构建更直观的 CLAUDE.md 和更完善的工具。

子代理听起来很美：把特定任务（比如跑测试）外包给专门的代理，只返回最终结果，从而保持主上下文的清洁。

然而，在实践中，自定义子代理会带来两个问题：

我更喜欢使用 Claude 内置的 Task(...) 功能来生成通用代理的副本。

这既能享受到子代理节省上下文的好处，又避免了其缺点。代理能够动态地管理自己的任务编排，而不是遵循固定的模式。

我经常使用 claude --resume 和 claude --continue 来重启出问题的终端或快速恢复旧会话。

我甚至会恢复几天前的会话，只为让代理总结它是如何解决某个特定错误的，然后用这些信息来优化改进 CLAUDE.md 和内部工具。

更进一步，Claude Code 将所有会话记录存储在 ~/.claude/projects/ 中。可以使用脚本定期对这些原始日志进行元分析，寻找常见的异常、权限请求和错误模式，以帮助优化改进给 AI 的上下文。

钩子 (Hooks) 是确定性的“必须做”规则，与 CLAUDE.md 中“应该做”的建议形成互补。在复杂的任务代码库里，这东西至关重要。

小提醒：
不要在“写入时”（比如 Edit 或 Write 操作）阻止。
打断它的思考过程会让它出现不明所以的判断。更好的方式是让它完成整个工作，然后在最后提交时检查结果。

对于任何大型功能变更，使用规划模式至关重要。

技能（Skills）可能是比 MCP 更好用。

智能体模型三个阶段：

Agent Skills
正是“脚本化”阶段的正式产品化。如果你像我一样，倾向于使用 CLI 而非 MCP，那么你其实一直在享受 Skills 带来的好处。
SKILL.md 文件就是一个更规范、可共享的方式来告诉 AI 它能用哪些脚本和 CLI。

Skills 的出现并不意味着 MCP 已死，而是使其更加聚焦。

与其成为一个包含几十个工具、镜像 REST API 的臃肿接口，MCP 应该是一个简单、安全、提供少数强大高阶工具的网关。比如：

MCP 的工作会是管理认证、网络和安全边界，然后让开。为代理提供入口点，代理则利用其脚本化能力和上下文来完成实际工作。

Claude Code 不仅仅是一个交互式 CLI，它还是一个强大的 SDK，可用于构建全新的通用代理框架。

Claude Code GitHub Action 是最被低估的功能之一。概念很简单：在 GHA 中运行 Claude Code。

它比 Cursor 的后台代理 或 Codex 的托管 Web UI 更具可定制性。你完全控制容器和环境，拥有更强的数据访问权限、沙盒能力和审计控制。

我们可以用它来打造智能 PR 的工具：从 Slack、Jira 或者监控警报触发一个 GHA，让 AI 自动修复 bug 或添加功能，然后提交一个测试通过的 PR。

GHA 的日志就是 AI 的完整工作记录。我们可以定期分析这些日志，以发现常见的错误和不一致的工程实践，然后优化我们的 CLAUDE.md 和 CLI，形成一个数据驱动的飞轮

最后，分享几个常用的 settings.json 配置：

klykq111:

bast64 : aHR0cHM6Ly9jbGF1ZGVjb2RlOC5jb20=

小月卡 大概 5.7×10⁹ token

[奖品 1]： 小月卡 × 10 张
[奖品 2]： 新用户 3k 积分 1 约等于 3.8 约等于 114M token 

参与方式

跟帖 UID

帖在 活动在 帖不在 我能看到 活动在 帖不在 group 发密语 "vv" 活动在 帖不在 发 v 友回复截图/争取 活动子啊

双重福利

新用户 注册 3000 , group 发密语 v +2000 （对看完的 v 友福利)

确保稳定 不玩虚的

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

针对 Claude 模型的专业提示词工程技术，涵盖 Sonnet 4.5, Sonnet 4, Haiku 4.5, Opus 4.1, 和 Opus 4 等型号，以助你在各类应用中获得卓越性能。相较于前代 Claude 模型，新一代模型经过专门训练，能够更精确地遵循指令。

Anthropic 于周三发布了 Claude Haiku 4.5，这是一款紧凑型 AI 模型，其编码性能与 5 月份的 Sonnet 4 相当，运行速度是其两倍多，成本约为三分之一。

该模型输入令牌每百万美元 1 美元，输出令牌每百万美元 5 美元。并向所有用户免费提供 Haiku 4.5。

https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices

Claude 4 模型对清晰、明确的指令响应极佳。具体说明你期望的输出，有助于显著提升结果质量。
如果用户期望获得前代模型中那种“超越期待”的主动发挥行为，在 Claude 4 中可能需要更明确地提出此类要求。

示例：创建数据分析页面

低效案例：

高效案例：

提供指令背后的上下文或动机，例如向 Claude 解释为何某个行为至关重要，能帮助 Claude 4 模型更好地理解你的目标，并给出更具针对性的回应。Claude 足够智能，能够从你的解释中进行泛化。

示例：格式化偏好

低效案例：

高效案例：

作为其精确指令遵循能力的一部分，Claude 4 模型会密切关注你提供的细节和示例。

请确保你的示例与你希望鼓励的行为保持一致，并尽量减少你希望避免的行为。

Claude Sonnet 4.5 在需要长期推理的任务中表现卓越，具备出色的状态追踪能力。它通过专注于增量进展（一次稳步推进几件事，而非一次性尝试所有事）来在扩展会话中保持方向感。

此能力在跨越多个上下文窗口或任务迭代时尤为突出，Claude 可以在一个复杂任务上工作，保存其状态，然后在新的上下文窗口中继续。

Claude Sonnet 4.5 具备上下文感知能力，使其能在整个对话中追踪剩余的上下文窗口（即“token 预算”）。这使得 Claude 能够通过了解其可用空间来更有效地执行任务和管理上下文。

如果你在代理框架（Agent Harness）中使用 Claude，且该框架会压缩上下文或允许将上下文保存到外部文件（如 Claude Code），建议你将此信息添加到提示词中，以便 Claude 采取相应行动。否则，Claude 在接近上下文限制时，有时会自然地尝试结束工作。

示例提示词：

对于跨越多个上下文窗口的复杂任务，请遵循以下策略：

示例：状态追踪文件

与前代模型相比，Claude Sonnet 4.5 的沟通风格更为简洁和自然：

这种沟通风格能准确反映已完成的工作，而无不必要的赘述。

Claude Sonnet 4.5 倾向于高效，可能会在调用工具后跳过口头总结，直接进入下一步行动。虽然这创造了流畅的工作流，但你可能希望更多地了解其推理过程。

Claude Sonnet 4.5 经过训练，能精确遵循指令，因此明确指示其使用特定工具会带来更好的效果。如果你说“你能建议一些修改吗？”，它有时只会提供建议而不是实施它们，即使你的意图是让它直接修改。

低效案例 (Claude 只会建议)：

高效案例 (Claude 会直接修改)：

以下几种方法在 Claude 4 模型中被证明对引导输出格式特别有效：

Claude Sonnet 4.5 展示了卓越的代理搜索能力，能有效地从多个来源查找和综合信息。为获得最佳研究结果：

Claude Sonnet 4.5 在原生子代理编排能力上有了显著提升。模型能够识别出哪些任务可以从委托给专门的子代理中受益，并主动这样做，无需明确指示。

若希望 Claude 在你的应用中正确地识别自己或使用特定的 API 字符串：

Claude 4 提供的“思考”能力，对于需要在工具使用后进行反思或进行复杂多步推理的任务特别有帮助。
你可以引导其初始思考或交错思考以获得更好的结果。

Claude Sonnet 4.5 擅长创作演示文稿、动画和视觉文档，其表现与 Claude Opus 4.1 相当甚至更优，具有令人印象深刻的创造力和更强的指令遵循能力。在大多数情况下，该模型能一次性产出精良、可用的成果。

Claude 4 模型擅长并行执行工具，其中 Sonnet 4.5 在同时启动多个操作方面尤为积极。模型会：

这种行为是可引导的。虽然模型在没有提示的情况下并行调用工具的成功率很高，但你可以通过提示将其提升至接近 100% 或调整其积极程度。

Claude 4 模型有时会为测试和迭代目的创建新文件，尤其是在处理代码时。这种方法允许 Claude 将文件（特别是 python 脚本）用作“临时草稿”，然后再保存最终输出。使用临时文件可以改善代理编码用例的结果。

Claude 4 模型能生成高质量、视觉独特且功能齐全的用户界面。然而，若无引导，前端代码可能默认为缺乏视觉趣味的通用模式。为获得卓越的 UI 结果：

Claude 4 模型有时可能过分专注于让测试通过，而牺牲了更通用的解决方案，或者可能使用辅助脚本等变通方法进行复杂重构，而不是直接使用标准工具。

为防止此行为并确保解决方案的健壮性和通用性：

Claude 4 模型更不易产生幻觉，能基于代码给出更准确、有根据、智能的答案。为进一步鼓励此行为并最小化幻觉：

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

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

尽管不完美也要分享原型

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

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

前几天最近随着 Claude Code 这个命令行 AI 代码工具的火爆，谷歌也耐不住寂寞推出了自己的同类产品 Gemini CLI，而且完全免费，非常顶。

下面会教你用 Gemini CLI 实现哪些能力：

首先他们是没有界面的，所有的操作都是在终端以命令行的方式展示。

然后就是也是 Agents 可以自动执行任务处理本地文件，同时内置了非常多的工具，比如谷歌搜索、阅读文件、查找文件、搜索文字、写入文件、保存记忆等，你输入 /tools 然后回车就可以让他列出目前支持的工具。

另外 Gemini CLI 也是支持 MCP 的，你可以安装其他的 MCP 工具帮助模型扩充上下文。

很多朋友说命令行是不是很复杂啊，我不会编程是不是会很难用。

其实并没有，如果你的网络环境正常，能够正常登录 Gemini CLI 的话，跟使用 Cursor 没有本质区别。

因为核心交互的时候还是主要为提示词输入框，命令行又不用你写，Gemini 写就行。

从这里开始我所有的演示都基于 Mac OS 的自带终端进行，Windows 大部分操作都是通用的，但是可能出问题概率比 Mac 复杂。

首先要做的第一步就是进入到我们的启动台，搜索终端两个字，搜到之后打开。

这时候你就看到一个空白界面里面写了些你看不懂的字，不要担心。

这里我建议我们想好要进行的任务之后，新建一个文件夹把需要的任务素材扔进去，然后按住 option 按键鼠标右键选择“将 XXXX 文件夹拷贝为路径名称”，这时候你就快速获得了这个文件夹的路径。

然后我们回到我们的终端窗口，输入 cd + 空格 + 你刚才复制的路径，接下来你终端的所有操作都只会影响这个文件夹的内容，不用担心把电脑搞坏。

到这一步我们终于开始安装 Gemini CLI 了，非常简单，你只需要输入下面的内容然后回车就行。

安装成功你就会看到这个界面，应该会先让你选择命令行的颜色主题，然后让你选择登录方式。

这里需要注意：终端的操作大部分时间需要用上下左右方向键来操作选项，选中之后按回车确认。

你只需要选择一个自己喜欢的主题之后，选择正常的谷歌账号登录，在拉起网页登录后关掉就行。

我这个这里已经登录了，所以没有这些选项，然后你就能看到提示词输入框了。

恭喜你到这里，你已经完成了 Gemini 的安装。

由于用的 NPX 的安装方式，所以你以后每次关掉终端重新使用 Gemini CLI 的时候都需要输入开始的那个命令，不过不用登录了，直接就能用。

另一种方法是输入下面这个命令，但是对于不会编程的人来说很麻烦，启动就是少输入点东西，输入 Gemini 就能启动。

最后由于命令行本身都是英文的，可能很多人会望而却步，这个时候你可以装个 Bob 这个翻译软件，支持划词翻译，看不懂的选项直接选中划词翻译就行。

装好之后我们可以来点基础用法了。

由于 Gemini 可以看到你的文件并且操作，而且它还有生成能力，本身模型还是多模态的，所以即使只用本身的工具也可以有很多用法。

首先是 Gemini CLI 本身支持谷歌搜索，你可以让他搜索指定内容给你写成文档，也可以对你本身的文档进行编辑。

当然搜索工具经常会限额，这个有点恶心，比如让他搜索歸藏的信息并且整理一个介绍文档。

你也可以让他分析你保存在本地的文章之后进行改写，生成新的文章。

比如我这里就让他把 Karpathy 的软件 3.0 文章改写成适合发布的博客文章，同时生成对应的推特发布版本，也可以对于会议总结之类的文档进行分析和处理。

记得我之前写的用 Curosr 这种 IDE 帮助分析 Obsidian ，把 Obsidian 当做本地知识库的方法吗，Gemini CLI 也可以，甚至更加强大。

你可以找到你的 Obsidian 文件夹打开之后启动 Gemini CLI，然后让 Gemini CLI 查找相关的内容。

比如我这里就让他检索我所有的剪藏文件，找到 MCP 相关的文章，然后给我生成一个带反向链接的《MCP 剪藏内容索引》文档，可以看到他完成的很好。

每个无序列表都有文件标题以及文章的总结，最后还有链接可以直达那个文章。

提到反向链接了，就不得不提 Obsidian 的一个知识图谱的功能，它可以把所有有反向链接的相关文档都链接起来，形成你自己的网状笔记网络，方便你学习和回顾。

但是反向链接需要你自己手动加，大部分人都没这个毅力，现在有了 Gemini CLI 问题解决了，可以让他帮你给你文件夹中的相关文档加反向链接。

不过这个需要的时间比较长，如果内容多的话可能得等一段时间。

由于本身 Gemini CLI 是多模态的的，所以你的图片也可以让他帮忙处理。

比如我打开了一个全是图片的文件夹，里面的图片名字乱七八糟的，这时候就可以让他分析图片内容之后根据图片内容给图片重新命名。

再重新命名之后我们也不能浪费他分析的图片内容。

我们都知道在训练图像模型或者 Lora 的时候需要对图像进行标注，大部分训练工具都是把标注放在一个跟图片命名一样的文本文件里，现在我们就可以让 Gemini CLI 来做这件事了。

可以看到他执行的非常完美，以往这些你还得找对应的工具，而且不好自定义要求，现在提示词就行。

Gemini CLI 除了可以读取文件和修改文件外也是可以控制系统设置的。

比如我们就可以写好自己日常对于软件和系统设置在不同工作时间的喜好，需要的时候一键完成所有操作的更改。

这里我就让他给我关掉浏览器，然后打开 Obsidian，降低系统音量，直接进入工作模式。

更进一步让他把操作写成脚本，之后你就可以直接双击脚本完成系统设置了。

我们肯定也有很多时候桌面或者文件没有整理乱七八糟。

这个时候就可以让 Gemini CLI 新建文件夹进行分类和整理。

但是这里得注意，不要让他整理过大的过于重要的文件夹，不然误删了就痛苦了。

这里我就让他把刚才的图像和标注文件新建了两个文件夹分别整理了。

上面都是些基本用法，你最近可能也看到了一些。

但是我发现结合一些本地软件，Gemini CLI 能实现对各种文件更加高级的处理，比如视频转 gif、youtube 视频下载、加水印、文档格式转换等。

这些就非常牛皮了，而且我们日常内容创作大部分都非常需要。

前面我们有了文档了，但是很多时候演示的时候总不能真给人看 Markdown 文档吧，能不能生成 PPT 呢？

可以的，朋友，必须可以，比如我这里就把前面我那个 MCP 索引文档的内容直接转换为 PPT 了。

这个依赖一个叫 Slidev 的项目，它可以用类似 Markdown 文档的格式将内容变成带有丰富样式的 PPT。

你不需要知道这个项目的细节，直接用我下面的提示词生成文件之后，复制文件到这个页面（https://stackblitz.com/github/slidevjs/new?file=slides.md）预览就行。

上面的 Slidev 不需要本地安装直接预览就行，接下来我们介绍一些需要本地安装的项目，这些本地的软件，非常强大，但是由于本身他们是没有界面的，阻碍的很多用户使用。

但是有了 Gemini 之后一切都解决了，提示词可以直接转换为驱动他们的命令行，也可以用提示词直接安装他们，你直接用就行。

首先先介绍一下 ffmpeg 这个项目，给予他你可以实现非常强的视频编辑能力，理论上剪映之类的视频编辑软件都是基于这个完成的。

你可以对本地的视频进行拼接、剪辑、增加文字、转换格式、转换分辨率、增加音乐，基本上你能想到的视频编辑能力他都能做到。

首先我们需要大概你需要处理视频的的文件夹，然后启动 Gemini CLI 第一个命令是让他安装 Homebrew。

然后安装完成后，让他用 Homebrew 帮你安装 ffmpeg。

看到没，跟网页哪些乱七八糟的要求都没关系，你只需要说两句话，就全部安装了。

然后我们就可以爽用了，先给我们指定的视频加个水印试试。

可以看到新的视频右上角果然有了一个水印，这种言出法随的感觉谁不喜欢，你不需要了解原理，你就只需要知道所有的视频编辑他都能帮你搞定。

然后我想要给视频配乐也可以，你只需要告诉他视频文件和音乐文件的名字就行，我甚至让他给音乐加上了淡入和淡出。

他先是获取了一下视频的时长，然后就开始操作了，然后搞定了，非常完美，严丝合缝，淡入淡出也加上了，可以看剪映界面预览的频谱。

我们很多时候需要把视频转换为序列帧，然后拿其中一帧进行处理，或者处理所有的帧，以前你是不是还得到处找这种工具，而且转换效果不一定好。

Gemini CLI 一句话就能搞定，处理的又快又好，而且节省了用网页工具上传下载的时间。

另一个常见的任务就是视频转 gif，尤其公众号有 10 个视频的限制，很多时候迫不得已得转成 gif 发布。

Gemini 捕捉到了高品质这个关键词还制作了调色板保证颜色还原度，最后处理的非常完美。

像 ffmpeg 这种宝藏项目还有很多，比如 yt-dlp 这个项目跟 ffmpeg 配合几乎可以下载你能想到的所有视频平台的视频。

我们还是可以让 Gemini CLI 帮我们安装 yt-dlp 这个项目就行。

然后直接提供视频链接他就会帮你下载，甚至可以批量下载多个视频或者一起连封面和视频一起下载，再也不需要忍受那些工具的垃圾网速了。

处理视频我们有 ffmpeg 这种项目，当然图片也有。

ImageMagick 是一个极其强大的工具集，你可以用它来转换格式、缩放、裁剪、旋转、添加滤镜、组合图片等等。

依然是老一套，先让 Gemini 帮我们安装

先来一个常见任务，我们设计师做外包经常用，在没结款之前给甲方低分辨率和带水印的图片，现在就可以直接批量完成。

这里我让他把所有图片宽边调整为 800 PX，然后统一加上带“内部资料”文字的水印。

中文的水印有些问题，后来改成英文就 OK 了，而且出错之后他自己开始用多模态能力检查修改后的图像了，发现 10% 不透明度的文字不明显，又自己重新改了一下，太聪明了。

然后再来一个常见的图像拼接需求，这种在媒体上发消息的时候经常需要，尤其是推特。

搞得不错，这几张图比例不同，所以没有对齐，可以在命令上加上统一比例这种要求就行。

文档格式转换也是常见的需求，相当多的公司工作文档还是 word，很多时候我发过去 .md 文件那边都不知道怎么办。

首先还是让 Gemini CLI 帮我们安装。

这个时候我们就可以利用 Pandoc 这个项目进行各种文档格式之间的互相转换，当然批量转换也是可以的。

可以看到转的很好，Markdown 的一些基本格式也都迁移了，不管是加粗还是无序列表有序列表。

好了教程到这里就结束了。

你可以用 Gemini CLI 控制这些已经非常成熟的命令行项目，基本上你所有的需求都能找到对应的项目。

不是只有 MCP 才能做 Agent，这些传统工具在有了 LLM 加持之后会更加强大。

看到这里，你可能会突然意识到：原来那些让我们望而却步的专业工具，其实一直都在那里等着我们。

史蒂夫·乔布斯说过的一句话：”技术应该是隐形的。” 今天的 Gemini CLI，正是让那些强大的命令行工具变得”隐形”——你不需要理解它们的工作原理，只需要说出你的需求。

更重要的是，这种改变不仅仅是效率的提升，而是创作门槛的彻底消失。

所以，如果你还在犹豫要不要试试 Gemini CLI，我想说：别让”我不会编程”成为你探索新世界的借口。 因为在这个新世界里，你需要的不是编程能力，而是想象力。

那些曾经高高在上的专业工具，现在都在静静等待着你的一句话。而你要做的，就是勇敢地说出你的需求。

因为最好的工具，是让你忘记它是工具的工具。