看完这份《How Anthropic teams use Claude Code》操作手册，最大的感受不是模型多强，而是谁先把自己的团队工作流整理成 Claude Code 能读、能跑、能验证的形态，谁就先拿到这波红利。

Data Infrastructure：把自然语言变成数据流程

Data Infrastructure 团队的 Kubernetes cluster 出过一次问题，新 pod 调度失败。

他们的做法是把 dashboard 截图扔给 Claude Code，让它带着人一层层翻 Google Cloud UI，最后定位到 pod IP 地址耗尽。Claude Code 顺手给出创建新 IP pool、挂到 cluster 上的命令——一个原本需要拉 networking specialist 进来的流程，就这么被绕过去了。

更有意思的是，他们把这套能力开放给了 Finance 团队。没写过代码的人写一个 plain text 文件，描述自己要跑的数据流程（查 dashboard、取信息、执行 query、产出 Excel），Claude Code 就能按步骤跑下来，缺日期之类的输入会主动追问。

这里被产品化的其实不是 AI，而是团队知识。Data Infrastructure 会持续维护 Claude.md，把工具、流程、预期、已有模式都写进去。每次 session 结束，再让 Claude Code 复盘一下做了什么、建议怎么改文档。文档越用越厚，下一次调用就越稳。

工程团队最先省下的，是找上下文的时间

API Knowledge 团队把 Claude Code 当成每个任务的「第一站」。修 bug、做 feature、分析问题之前，先问它该看哪些文件、系统架构怎么连、某段逻辑在哪里被调用。不用再在 repo 里摸半天，也不用等同事回 Slack。

Inference 团队管理的是 Claude 读 prompt 和生成回答时用到的 memory system。团队里有人本来没 ML 背景，以前理解一个 model-specific function 要 Google 一小时，现在让 Claude Code 解释函数和设置，10 到 20 分钟搞定，研究时间直接砍掉 80%。

Security Engineering 的玩法是把 stack trace 和文档喂进去，让 Claude Code 沿代码库追 control flow。原本手动扫 10 到 15 分钟才能判断的问题，现在 5 分钟出结论。做 Terraform 变更审查时，他们干脆把 plan 贴进去，直接问一句「what's this going to do? Am I going to regret this?」——Claude Code 先把 infrastructure change 的影响讲明白，安全审批的堵塞就少了一截。

异步能跑多远，取决于任务本身

Claude Code 产品团队会直接开 auto-accept mode，让 Claude Code 自己写代码、跑测试、继续改，人最后接手一个完成度 80% 的方案。Vim key bindings 就是这么做出来的，最后大约 70% 的代码来自 Claude 的自主实现，只经过几轮迭代。

但他们没有把所有东西都丢给异步模式。边缘 feature、prototype、低风险修复适合放手，靠近核心业务逻辑和架构约束的功能，还是得人同步盯着写。

RL Engineering 团队的说法更克制一些：做小中型 PR 先让 Claude Code 试一次 one-shot，成功率大概三分之一。成了省时间，没成就切回协作模式。他们也会频繁 checkpoint，跑偏了就回滚。Claude.md 里写了非常具体的偏好，比如 run pytest、不要 cd 来 cd 去、直接用正确路径——这种细节才是真正让模型「听话」的地方。

设计师和增长团队开始直接改系统

Product Design 团队的变化最直观。设计师以前要在 Figma 里画图、写说明、等工程师排期、来回对齐视觉细节。现在他们用 Claude Code 直接改 typeface、color、spacing，甚至做比较大的 state management changes。

他们把 mockup 图片贴进 Claude Code，生成能跑的 prototype。工程师拿到的不是一张静态稿，而是一个已经能交互的实现，中间的「翻译」成本被砍掉了一大半。一个具体例子：移除整个 codebase 里的 research preview 文案，Claude Code 帮他们找出所有出现位置、检查周围 copy、配合法务实时改——原本要来回沟通一周的事，最后用了两次 30 分钟的 call。

Growth Marketing 团队更夸张，只有一个非技术成员，却跑出来好几条完整 workflow：

  • Google Ads 创意生成系统：读取几百条现有广告和表现数据，挑出表现差的，生成符合字符限制的新版本（headline 30 字符、description 90 字符）。他们拆成两个 sub-agent，一个管 headline 一个管 description，几分钟生成几百条新广告。
  • Figma plugin：识别 frame 后程序化生成最多 100 个 ad variation，每批半秒，创意产出提高 10 倍。
  • Meta Ads MCP server：把 campaign performance、spend、ad effectiveness 接进 Claude Desktop 直接查。

Legal 团队：AI 已经彻底离开工程部门了

Legal 团队的案例更像普通人用 AI 做点小工具。

一个成员用 Claude Code 给有语言障碍的家人做了沟通辅助工具，1 小时搞定——speech-to-text 推荐回复，再用 voice bank 念出来。他们还做过法律部门内部的 phone tree prototype（帮员工找到该联系哪位 lawyer），也做过 G Suite 应用整理每周团队 update、追踪产品 legal review 状态。

他们的流程值得抄：先在 Claude.ai 里聊清楚需求，再让 Claude.ai 把对话总结成 step-by-step prompt，最后交给 Claude Code 实现。实现时要求它慢一点、一步一步来，方便复制粘贴和检查。UI 想法基本都靠截图传达。

真正的红利在「工作环境」，不在 prompt

把这 10 个团队的案例放一起看，能看出一个清晰的转向：Claude Code 进入组织之后，重点已经从「怎么写 prompt」滑向「怎么搭工作环境」。

  • 代码库要有文档（Claude.md 不是装饰）
  • 工具要有权限边界
  • 重复动作要有命令封装
  • 敏感数据要通过 MCP 控制访问
  • 长任务要能 checkpoint 和回滚

模型当然重要，但这些案例几乎都在说同一件事：模型能力是地板，环境组织度才是天花板。一个不写 Claude.md、不收敛工具集、不切分 sub-agent 的团队，再强的模型也只能当聊天机器人用。

如果你是一个人或者一个小团队，可以从最小的一步开始：写一份 Claude.md，把你做事的偏好、工具、流程列清楚，每次 session 结束让 Claude Code 帮你补一笔。文档越厚，AI 越好使——这个复利，比换模型管用多了。