Claude Code 有意思的一点是，它能配合你现有的所有工具，你不需要改变工作流，不需要把整套东西换掉才能开始用。不管你用什么 IDE——VS Code、Xcode、JetBrains 系列都行。Anthropic 内部有些人的 IDE 你是撬都撬不走的，但他们照样用 Claude Code，因为 Claude Code 能配合市面上任何一个 IDE、任何一个终端。本地能跑，远程 SSH 能跑，tmux 里也能跑——不管你在什么环境里，都能跑起来。

它是通用工具。如果你以前没用过这类自由形态的编程助手，可能会有点不知道从哪儿下手——因为你一打开，看到的就是一个输入框，你会想：我该拿它干嘛？我该输入什么？

它是一把「重型工具」，能干的事很多。也正因为它能干的事太多，我们不去把你往某一种特定工作流上引导——因为作为工程师，你本来就该按自己的方式去用它。

首次配置

第一次打开 Claude Code 时，我们建议做几件事来配好环境，都很直接：

/terminal-setup —— 让 Shift+Enter 可以换行，这样你就不用打反斜杠来换行了，用起来舒服一点。

/theme —— 设置浅色模式、深色模式，或者色盲友好（daltonized）主题。

/install-github-app —— 我们今天发布了一个 GitHub app，你可以在任何 GitHub issue 或 pull request 里 @Claude。要安装的话，在终端里跑这条命令就行。

自定义允许的工具（allowed tools） —— 你可以配置一批默认允许的工具，这样就不会每次都被询问。这挺方便的。对于那些老是弹确认的操作，我肯定会这么配一下，省得每次都要点同意。

用语音输入 —— 我很多 prompt 其实不是手打进 Claude Code 的。如果你用 macOS，可以进「系统设置 → 辅助功能 → 听写」把它打开。然后双击听写快捷键，直接说出你的 prompt 就行。prompt 写得具体是很有帮助的，所以这招其实相当好用——你可以像跟另一个工程师说话那样直接跟 Claude Code 讲，不用敲那么多字。

技巧一：从「代码库问答」开始

刚上手 Claude Code 的时候——它这么自由，什么都能干——你到底该从哪儿开始？

我最推荐的一件事，就是从**代码库问答（codebase Q&A）**开始。就是单纯地对着你的代码库提问。

这也是我们教新人的方式。在 Anthropic，新人入职第一天的技术 onboarding 里，你会了解 Claude Code、把它装上、配好，然后立刻开始对代码库提问。

以前做技术 onboarding 对团队消耗是很大的：你得去问团队里其他工程师，得自己在代码里翻，这要花不少时间；你还得搞清楚各种工具怎么用，这个过程很长。

有了 Claude Code，你直接问它就行，它会自己去探索代码库、回答这类问题。在 Anthropic，技术岗的 onboarding 以前大概要两三周，现在大概两三天。

代码库问答还有一点很棒：我们不做任何索引。没有一个存着你代码的远程数据库，我们不会把你的代码上传到任何地方，你的代码留在本地。我们也不用你的代码去训练生成式模型。代码就在那儿，由你掌控，没有什么索引之类的东西。这也意味着零配置：你下载 Claude Code、启动它，没有索引过程，不用等，马上就能用。

可以问哪些问题

这是一场技术分享，所以我会给出一些很具体的 prompt 和代码示例，希望能帮你把 Claude Code 用得更好。

「这段代码是怎么被使用的？」或者「这个东西该怎么实例化？」—— Claude Code 不会只做个文本搜索就来回答你。它常常会再深挖一层，去找这个类实际是怎么被实例化、怎么被使用的例子，然后给你一个深得多的答案——那种你本该从 wiki 或文档里才拿得到的答案，而不是简单的 Cmd+F。

问 git 历史。 比如：「这个函数为什么有 15 个参数？这些参数名为什么起得这么奇怪？」我敢打赌，我们每个人的代码库里都有这样一个函数或者类。Claude Code 能翻 git 历史，去搞清楚这些参数是怎么被加进来的、是谁加的、当时是什么情况、那些 commit 关联了哪些 issue。它会把这些都翻一遍然后总结给你。

你不需要把这些细节一条条告诉它，你就直接问。你只要说「去翻一下 git 历史」，它就知道该怎么做。顺便说一句，它知道这么做并不是因为我们在 prompt 里教了它——system prompt 里根本没有任何关于翻 git 历史的内容。它之所以知道，是因为模型本身就很强。你让它用 git，它就知道怎么用 git。我们很幸运能建立在这么好的模型之上。

问 GitHub issue。 它可以用 WebFetch 去抓取 issue、查上下文，这也相当好用。

每周站会的小技巧。 我每周一在周会上都会做一件事：问它「我这周 ship 了什么？」Claude Code 去看 log，它知道我的用户名，然后就给我一份漂亮的清单，列出我 ship 的所有东西。我直接复制粘贴进文档就完事了。

为什么要从这里开始

对于没用过 Claude Code 的人——如果你是第一次演示给别人看，或者在带团队上手——我们强烈建议从代码库问答开始。别一上来就用花哨的工具，别一上来就改代码。就先从对代码库提问开始。

这能教会大家怎么写 prompt，也能让他们开始建立起边界感：Claude Code 能做什么？它的能力到哪里？相对地，哪些事情需要你多牵着它一点？什么任务能一次搞定？什么需要两轮、三轮？什么时候需要用交互模式、在 REPL 里做？

技巧二：让它改代码

等你对问答比较熟了，就可以进入改代码这一步了。

以 agentic 的方式使用 LLM，最妙的一点是：你把工具给它，它就自己搞明白怎么用了，简直像变魔术。而 Claude Code 拿到的工具集其实很小，真的不多：一个改文件的工具，一个跑 bash 命令的工具，一个搜文件的工具。它会把这几样串起来去探索代码、头脑风暴，最后落地成修改。

你不需要专门告诉它「先用这个工具、再用那个工具」。你就说「把这件事做了」，它自己会想明白怎么做，会用合理的方式把这些串起来。

先让它做计划

有时候在让 Claude 直接动手写代码之前，我喜欢先让它头脑风暴一下，或者先做个计划。这一点我们非常推荐。

我有时候会看到这种情况：有人打开 Claude Code 就说「嘿，把这个 3000 行的大功能实现了」。有时候它一次就做对了。但有时候的结果是，它做出来的东西完全不是你想要的。

想拿到你要的结果，最简单的办法就是先让它思考：

你不需要用 plan mode，也不需要任何特殊工具。你只要这么跟 Claude 说，它就知道该怎么做。就一句「写代码之前先做个计划」，就这样。

「commit push PR」

这个我想单独拎出来讲。**「commit push PR」**是我用得非常多的一句咒语。它本身没什么特别的，但 Claude 聪明到足以理解它：它会做一个 commit，推到分支上、建分支，然后在 GitHub 上给我开一个 pull request。

你什么都不用解释。它会自己去看代码、看历史、看 git log，搞清楚 commit 的格式之类的所有细节，然后用正确的方式提交和推送。

再强调一次，我们没有在 system prompt 里教它做这件事，它自己就知道怎么做。模型很强。

技巧三：接入你们团队的工具

再往进阶走一点，你会想开始把团队自己的工具接进来。这才是 Claude Code 真正开始发光的地方。

工具大致分两类：

Bash 工具。 举个例子，我随手编了一个 CLI——这个不是真的存在的东西。但你可以说「用这个 CLI 去做某件事」，你可以把这个工具告诉 Claude Code，还可以让它用比如 --help 去自己搞清楚怎么用。这个方式很高效。如果你发现自己经常用它，还可以把这些写进你的 CLAUDE.md（一会儿会讲），这样 Claude 跨会话都能记住。这是我们在 Anthropic 常用的模式，也看到外部客户在这么用。

MCP 工具。 MCP 也是一样。Claude Code 能用 bash 工具，也能用 MCP 工具。你只要把工具告诉它——把 MCP 工具加上，告诉它怎么用，它就会开始用了。

这个能力极其强大：当你在一个新代码库上开始用 Claude Code 时，你可以把你所有的工具、把你团队本来就在这个代码库上用的所有工具，一股脑给它，然后 Claude Code 就能替你去用这些工具。

几种常见工作流

有几种常见的工作流。一种我前面已经讲过了：先做一点探索，再做一点计划，写代码之前先找我确认。

另外两种威力极大。当 Claude 有办法检验自己的工作成果时——比如写单元测试、用 Puppeteer 截图、给 iOS 模拟器截图——它就能迭代。这一点非常惊人。比如你给它一张设计稿说「把这个 Web UI 做出来」，它一次能做到不错的水平；但如果你让它迭代个两三轮，往往就能做到几乎完美。

所以诀窍是：给它某种能拿到反馈、能检验自己成果的工具。有了这个，它就会自己迭代，你拿到的结果会好得多。不管你的领域是什么——单元测试、集成测试、App 或 Web 的截图，什么都行——只要让它能「看见」自己做出来的结果，它就会迭代、就会越做越好。

下一步： 教会 Claude 使用你的工具，并且找到合适的工作流。你是想让 Claude 直接开写？还是想让它先头脑风暴、先做计划？还是想让它迭代？心里有个数，你才知道该怎么给 Claude 写 prompt 来拿到你要的东西。

技巧四：给 Claude 更多上下文

再深入一层，除了工具之外，你要开始给 Claude 更多上下文。上下文越多，它的决策就越聪明——因为作为一个在代码库里干活的工程师，你脑子里装着关于这套系统的大量上下文、所有的历史脉络等等。把这些交给 Claude 的方式有好几种，而你给 Claude 的上下文越多，它表现就越好。

CLAUDE.md

最简单的方式就是我们叫做 CLAUDE.md 的东西。CLAUDE.md 是一个特殊的文件名。

最简单的放法是放在项目根目录——也就是你启动 Claude 的那个目录。它会在每次会话开始时被自动读入上下文。本质上，第一轮用户输入里就会包含 CLAUDE.md 的内容。

你也可以有一个本地版 CLAUDE.md，这个通常不提交到版本控制里。也就是说：CLAUDE.md 你应该提交到版本控制、和团队共享，写一次大家都能用；而本地那份不提交，只给你自己用。

CLAUDE.md 里该写什么： 常用的 bash 命令、常用的 MCP 工具、架构决策、重要文件——凡是在这个代码库里干活通常需要知道的东西。

要写短。 如果写得太长，它只会白白吃掉一大堆上下文，而且通常也没那么有用。尽量写短。比如我们的代码库里就放了常用 bash 命令、一份代码风格指南、几个核心文件，大概这类东西。

嵌套的 CLAUDE.md。 你可以在下级子目录里放 CLAUDE.md，Claude 会按需把它们拉进来——当 Claude 在那些目录里干活时，它们会被自动读入。

企业级 CLAUDE.md。 如果你是一家公司，也许你想要一份在所有代码库之间共享、由你统一为员工管理的 CLAUDE.md。你可以把它放在企业级根位置，它会被自动读入。

其他注入上下文的方式

注入上下文的方式非常多。做这页 slide 的时候我其实挺头疼的，就是想把这些方式的广度讲清楚。

CLAUDE.md —— 自动读入。

斜杠命令（slash commands） —— 放在 .claude/commands 里，可以在你的 home 目录下，也可以提交进项目里。Claude Code 自己就有几个这样的斜杠命令。比如说，如果你在 Claude Code 的仓库里看到 issue 被自动打上标签，那其实就是这个工作流在跑——一个 label-github-issues 斜杠命令。我们跑了一个 GitHub Action（就是今天上午讲的那个），让 Claude Code 去执行这条命令，它就会去给 issue 打标签，人就不用干这活了。省了我们一大堆时间。

@ 引用文件 —— 把文件拉进上下文。

嵌套的 CLAUDE.md —— 当 Claude 在那个目录里干活时会被拉进来。

给 Claude 更多上下文——花时间去调优上下文绝对是值得的。你可以把它丢给 prompt improver 优化一遍。想清楚这份上下文是给谁的：你希望它每次都被读入，还是按需读入？你想和团队共享，还是这只是你个人的偏好？一定要花时间去调。只要做对了，性能提升会非常明显。

配置的层级体系

再进阶一点，你会想更仔细地考虑这套「层级」——不只是 CLAUDE.md，还包括配置，基本上关于 Claude 的一切都可以按层级注入：

项目级（Project） —— 针对你的 git 仓库。可以提交进去，也可以只给自己用。

全局级（Global） —— 跨所有项目生效的配置。

企业策略（Enterprise policies） —— 本质上就是一份你为全体员工、全团队自动下发的全局配置。

这页 slide 信息密度很高，但重点是：这套机制适用于很多东西。

斜杠命令 适用这套机制。

权限（permissions） 适用。比如你有一条所有员工都会跑的 bash 命令——比如某个测试命令——你可以直接把它写进企业策略文件，那么任何员工跑这条命令时都会被自动批准，相当方便。

屏蔽命令 也适用。比如说有个 URL 永远不该被抓取，把它加进这份配置里，员工就无法覆盖这条规则，那个 URL 永远抓不了。这既方便给人放行，也方便保护你的代码库安全。

MCP server 同样适用。在代码库里提交一份 .mcp.json，这样任何人在你的代码库里跑 Claude Code 时，都会被提示安装这些 MCP server，从而和团队共享。

如果你不确定该用哪一种——这确实是个有点吓人的矩阵，因为我们支持的东西很多，工程师的工作流又非常灵活，每家公司还都不一样，所以我们基本上想把所有情况都支持到。如果你不知道从哪儿开始，我建议从「共享的项目级上下文」开始。你写一次，然后分享给团队里所有人，就能形成网络效应：一个人做了一点点工作，团队里所有人都受益。

管理 memory

Claude 内置了不少工具来管这些。比如你跑 /memory，就能看到当前被读入的所有 memory 文件——可能有一份企业策略、我的用户级 memory、项目的 CLAUDE.md，还可能有一份只在特定目录下才读入的嵌套 CLAUDE.md。用 /memory 你还可以去编辑具体某一份 memory 文件。而当你打 # 让它记住某件事时，你可以选择让它写进哪一份 memory。

下一步： 花时间把 CLAUDE.md、MCP server 以及你团队用的所有东西配好——配一次，然后分享给所有人。

举个例子，Anthropic 有个 apps 仓库，我们所有 Web 和 App 的代码都在里面。里面有个 Puppeteer MCP server，我们和团队共享它。仓库里提交了一份 .mcp.json，这样任何在这个仓库里干活的工程师都能用 Puppeteer 去驱动端到端测试、自动截图、迭代——不用每个工程师自己再装一遍。

插播：你可能不知道的快捷键

这是一场讲进阶技巧的分享，所以我想插播一下，聊几个大家可能不知道的常用快捷键。

给终端做产品是很难的，但也很有意思——感觉像在重新发现一套新的设计语言。不过终端这东西极其简约，所以这些快捷键有时候很难被发现。这里给一份速查表：

按键	作用
Shift+Tab	接受编辑 —— 切换到「自动接受编辑」模式。bash 命令仍然需要确认，但文件编辑会被自动接受。你随时可以让 Claude 之后撤销。我一般在确定 Claude 走在正确路上时会这么做，或者它在写单元测试、反复迭代测试的时候——我就切到自动接受模式，省得每一处改动都要点一遍同意。
`#`	记住某件事。如果 Claude 某个工具用得不对，你希望它以后都用对，就打 `#` 然后告诉它要记住什么。它会自动把这条写进 CLAUDE.md。
`!`	进入 bash 模式。输入你的命令，它会在本地执行——但同时也会进入上下文窗口，所以 Claude 下一轮就能看到。这对于长时间运行的命令很好用，或者当你非常清楚自己要干什么、又或者你想把某条命令塞进上下文的时候。Claude 会同时看到命令和它的输出。
`@`	引用文件和文件夹。
Esc	中断 Claude 正在做的事。不管 Claude 在干什么，你随时都可以安全地按 Esc。它不会损坏会话，也不会搞乱任何东西。比如 Claude 正在改一个文件，我按 Esc，然后告诉它换个做法。或者它给出了一处 20 行的修改，其中 19 行看着完全没问题、只有一行要改，我就按 Esc、告诉它这一点，然后让它重做这处编辑。
Esc Esc	跳回历史记录。
Ctrl+R	查看更多输出 —— 展示完整输出，也就是 Claude 在它上下文窗口里看到的同一份内容。

一段会话结束之后，你可以用 --resume 启动 Claude 来恢复那段会话，或者用 --continue。

技巧五：Claude Code SDK

接下来我想讲 Claude Code SDK。开头提过一句。这场结束之后，Sid 会在——我记得是走廊对面——讲一场，他会把 SDK 讲得非常深。

如果你还没玩过：你如果用过 Claude 的 -p 参数，那个就是 SDK。过去几周我们规划了一批功能让它变得更好。你可以基于它去构建、去做很酷的东西。Claude Code 自己用的就是这个东西——完全是同一套 SDK。

举个例子，claude -p——这就是 CLI 形态的 SDK。你可以传一个 prompt，可以传一组允许使用的工具（其中可以包含特定的 bash 命令），还可以指定你想要的输出格式——比如 JSON，或者流式 JSON（如果你想对它做进一步处理的话）。

拿它来做二次开发非常棒。我们在 CI 里一直用它，我们用它做事故响应（incident response），我们在各种 pipeline 里用它。真的很方便。

你就把它当成一个 Unix 工具来想。 你给它一个 prompt，它给你 JSON，然后你想怎么用都行。你可以往里管道输入，也可以从它管道输出。

管道这块也挺酷的。比如你可以用 git status 把结果管道进去，再用 jq 去挑出你要的结果。组合方式是无穷的。这算是一种新思路——它就像一个超级智能的 Unix 工具，而我觉得我们对它的用法才刚刚触到皮毛，我们自己也还在摸索。

你可以从 GCP bucket 里读——读一份巨大的日志，管道进去，让 Claude 告诉你这份日志里有什么值得注意的。

你可以从 Sentry CLI 拉数据，管道进去，让 Claude 拿它做点什么。

技巧六：并行（进阶）

最后一件事——这大概是我们见过的最进阶的用法了。

我自己算是个 Claude「普通用户」。我一般同时只跑一个 Claude，最多开几个终端标签页，对应几个不同的仓库同时跑着。

但当我去看 Anthropic 内外的重度用户时，他们几乎清一色都会开 SSH 会话，会用 tmux 挂着他们的 Claude 会话；他们会把同一个仓库 check out 好几份，这样就能在这个仓库上并行跑一堆 Claude；或者他们会用 git worktree 来做某种隔离。

我们正在积极地让这件事变得更好用。但眼下，这些是一些可以参考的思路，让你能用 Claude 并行做更多事。你想开多少个会话就开多少个，并行能做完的事情非常多。

好，就到这里。我也想留点时间做 Q&A。我想这是我最后一页 slide 了。如果大家有问题，两边都有麦克风——我们很乐意回答。谢谢。

问答环节

问：构建 Claude Code 的过程中，实现上最难的部分是什么？

我觉得棘手的地方挺多的。其中特别棘手的一块，是我们为了让 bash 命令变得安全所做的那些事。

bash 本身就是相当危险的东西，它可能以意料之外的方式改变系统状态。但与此同时，如果每一条 bash 命令都要你手动批准，作为工程师会烦到不行——你根本没法专注干活，因为你一直在点同意。

要在安全的前提下把这件事做好，还要能适配大家五花八门的代码库形态——毕竟不是每个人都在 Docker 容器里跑代码——这一点相当棘手。

我们最后落地的方案大致是：有一部分命令是只读的；我们会做一些静态分析，来判断哪些命令可以被安全地组合在一起；然后我们有一套相当复杂的分层权限系统，让你可以在不同层级上对命令做白名单和黑名单。

问：Claude Code 有多模态能力吗？怎么给它传图片？

是的——Claude Code 是完全多模态的，从第一天起就是。因为它在终端里，所以这个能力有点不好被发现。但你可以拿一张图直接拖拽进去，可以用；你可以给它一个文件路径，可以用；你也可以直接复制粘贴图片进去，同样可以用。

我自己经常用这个。比如我手上有一张设计稿，我就把稿子拖进去，让它照着实现，再给它一个 Puppeteer server 让它能对照着迭代。它就是完全多模态的。

问：为什么做成 CLI 工具，而不是 IDE？

这是个好问题。我觉得大概有两个原因。

第一： 我们是在 Anthropic 内部起步的，而 Anthropic 的人用的 IDE 五花八门。有人用 VS Code，有人用 Zed、Xcode、Vim、Emacs。要做一个对所有人都合适的东西太难了——而终端是那个最大公约数。

第二： 在 Anthropic，我们能近距离看到模型进步得有多快。我觉得很有可能到今年年底，大家就不再用 IDE 了。所以我们想为这个未来做好准备，也想避免在 UI 和上层的其他东西上过度投入——按照模型现在的演进速度，那些工作可能很快就没什么用了。

问：你们用 Claude Code 做机器学习建模、类似 AutoML 那种体验的程度有多少？

这个问题是：我们用 Claude Code 做机器学习和建模的程度有多少？

我们其实用得挺多的。Anthropic 的工程师和研究员每天都在用 Claude Code。我估计 Anthropic 大约 80% 的技术岗员工每天都在用 Claude Code——希望你们能从产品里感受到这一点，感受到我们投入的心血和自用打磨（dogfooding）的量。

这里面也包括研究员，他们会用像 notebook 工具这样的东西来编辑和运行 notebook。

本场分享结束。

把 NanoBot 跑起来了：本地聊 Discord，代理走远程，Grok 4.5 能聊天能生图。踩了几个坑，记一下。

装完终端才是开始：8 个 bug，每一个的第一反应都是错的

Last update: 2026-08-24

🎉跨境电商技术支持团队🎉

--感谢您的认可与信赖--

Shopify官网注册-获取本人免费使用支持

👏有需要欢迎资讯👏学习、交流亦可