ENZOMEGA.
Clipping 微信公众号

Anthropic 团队是怎么协作和运转的？

by 傅里叶 原文 ↗
Created: 2026-05-28
#公众号文章

公众号名称：晚点再听LaterCast

作者名称：傅里叶

发布时间：2026-05-28 22:19

以下文章来源于傅里叶

最近有朋友问我：像我们这种小团队，怎么围绕 AI Coding 搭内部协作流程？坦白说，这件事我们也还在摸着石头过河，只是边做边学，尤其会观察更 AI Native 的团队到底怎么工作。Anthropic 最近正好有很多产品、设计、研发负责人出来做公开分享，所以我让 Manus 把他们近期的访谈、官方文档、工程文章和案例做了一次深度整理。希望这篇文章能给大家一些参考。

完整调研报告可以关注公众号后回复：「Anthropic」获取。

—

开头先泼一盆冷水

很多人讲 Anthropic，容易被几个表象吸引：他们好像没什么流程，工程师看到用户反馈当周就能上线，设计师也可以直接改代码。这些观察大多没错，但如果由此得出“Anthropic 靠低流程取胜”，结论就反了。

把 Anthropic 公开访谈、官方文档、工程文章和 PDF 案例放在一起看，你会看到一个几乎相反的画面：Anthropic 不是没有流程，而是把传统流程里大量“开会、写文档、来回交接、人肉传话”的部分，挪进了可运行代码、可审阅 diff、可重复 evals、可触发的 GitHub workflow，以及可被 AI 读取的项目上下文里。

换句话说，会议没有消失，只是被压缩了；PRD 没有消失，只是变薄了，但验收变厚了；Code review 也没有消失，而是变成了 AI 先做、人再做的双层结构。所以模仿 Anthropic，不能模仿“低流程”这个口号。那是结果，不是方法。真正值得学的是：他们怎么把流程改造成一个可执行、可审查、可回滚、可验证的系统。

下面按协作、工程、产品、设计，以及可复制边界五部分拆开。

一、协作：当 builder 就是 user，反馈不需要翻译

Anthropic 的开发者产品，尤其是 Claude Code，有一个非常强的结构性优势：构建者本身就是目标用户。Mike Krieger 在 Lenny 的访谈里说得很直白：当 AI 把“写代码”的速度提上去之后，真正的瓶颈就从“怎么写”转到了“决定做什么、怎么验证、怎么合并、怎么发布”。如果构建者和用户是同一拨人，那么“决定做什么”这一步，几乎不需要再经过翻译流程。

这会形成一条非常短的信号链路：Twitter 上有人抱怨一个 CLI 输出，工程师自己今天早上也刚好被同一个问题烦到，于是让 Claude Code 读相关代码、生成计划、改 diff、跑测试、开 PR，再由 Code Review agents 并行扫一遍，人类 reviewer 看一眼，合并，进入下一轮内部 dogfooding。​整个链路里没有“PM 把需求翻译给工程师”这一环，因为提出需求的人、做实现的人、使用产品的人，往往就是同一个人，或者同一个小队。​

跨职能 pod 才是真正的组织单位。​Joel Lewenstein 是 Anthropic 的设计负责人，他在访谈里有一句话很值得拎出来：他希望每个小型跨职能 pod 里都有设计、PM 和工程，而不是让设计师站在流程末端，作为服务角色接收请求。​“末端服务角色”这个说法很准确，它描述了很多公司里设计团队的实际处境：PM 把需求喂给设计，设计出稿交给工程，后面再被 PM 追着改稿。​Anthropic 想绕开的，正是这条链。​

还有一个更隐蔽、但更重要的变化：Claude Code 不只是写代码工具，它顺带承担了一部分团队知识流转。​官方 PDF 和 GitHub Actions 文档里写得很清楚：团队规则、代码风格、review 标准、命名偏好，写进 CLAUDE.md；高频任务，做成 slash commands；外部系统接入，通过 MCP、hooks、plugins；issue 和 PR 里的常规工作，用 GitHub Actions 触发 Claude 自动处理。​

过去，这些知识可能散在飞书文档、Notion、老员工的脑子里。现在，它们被放进 AI 工具能读取、能执行的上下文里。新人不需要先把 Wiki 全部看完才开始干活，他可以让 Claude Code 先读仓库，再基于仓库上下文进入工作。

二、工程：从“写代码”变成“决定做什么、怎么验证”

公开资料能够比较完整地还原 Anthropic 工程流程的前半段：任务进入、Claude Code 生成计划、修改代码、跑测试、开 PR、自动 review，以及 merge 前检查。生产部署的细节没有公开，所以这里只讲到发布准备。这套流程的关键不是“AI 帮人写代码”，更准确地说，它是把人的注意力从“敲键盘”转移到“做判断”。

把官方 PDF 和 Claude Code 团队访谈里的细节合起来，可以重构出一套很实用的本地开发 SOP：

  1. 保持 clean git baseline。这样才能看清 AI 到底改了什么；不满意时，也能干净回滚。

  2. 装载上下文。让 Claude 读仓库、CLAUDE.md 和相关历史实现，而不是凭空写代码。

  3. 先要计划，不要直接改。先让 Claude 说清楚：准备改哪些文件、为什么这么改、要跑什么测试、风险在哪里。

  4. 分层授权。视觉 polish、文档、边界明确的 bug fix，可以放得更开；核心逻辑、架构、安全相关改动，必须同步监督。

  5. 用 checkpoint 控制风险。长任务要有可恢复、可审查的阶段，不要让 agent 跑到一个不可解释的状态。

  6. 跑测试，并追问失败原因。这一步里有一个细节特别值得说。

Cat Wu 在访谈里提到过一个调试场景：他们发现 Claude 没有跑本该运行的前端验证。正常工程师可能会直接改 prompt、加约束，或者抱怨模型不够可靠；但他们的做法是，直接问模型为什么跳过了。模型自己的解释是：它把验证委托给了子代理，但父代理没有检查子代理的结果。也就是说，问题不在“模型能力不够”，而在 harness 和系统提示的结构。

这个细节很能代表 Anthropic 式 AI 工程：他们不仅修结果，也会调试 agent 为什么会做出某个流程选择。换句话说，他们把 agent 当成一个可以访谈、可以分析的对象，而不是一个完全不可解释的黑盒。

PR、review、merge 的链路，也可以从 Claude Code 官方文档里看到两件清楚的事。​第一，GitHub Actions 让 @claude 进入了 PR 流程。​做法是：安装 GitHub App，给 Contents、Issues、PR 读写权限，把 API Key 放进 Secrets，再把 workflow 复制到 .github/workflows/。​之后，团队成员在 issue 或 PR 评论里 @claude，就能让它读取上下文、修改代码、回复问题，或者创建 PR。​

第二，Code Review 是结构化反馈，不是绝对 gate。​启用后，多个 agents 会并行分析 diff；verification step 会过滤误报；最后结果按严重级排序，并作为 inline comments 发到具体代码行。​但默认情况下，check run 是 neutral 状态，不阻塞合并。​如果团队希望它阻塞合并，需要自己在 CI 里读取机器可读 JSON，再根据 Important finding 的数量定义阈值。​

这一点很重要。Anthropic 把 AI review 放在人类 review 前面，用它来加速反馈；但最终合并责任，仍然明确留给人类团队。这不是不信任 AI，而是很清楚自动化的边界应该画在哪里。

Evals 也不是奢侈品，而是发布门槛。Anthropic 官方 evals 工程文章里，反复出现一个态度：不要等到有完美评估系统以后才开始做 evals，先用 10 个高质量真实场景，把基本回归能力建立起来。Cat Wu 那句“10 个好的 evals 比没有 evals 有用”虽然是二手转述，但和官方立场完全一致。

这套 SOP 也可以直接搬：

  1. PM 或工程师先列出真实用户任务。

  2. 给每个任务定义输入、工具使用、期望行为、不可接受的失败，以及评分标准。

  3. 把这些任务做成可重复运行的 evals。

  4. 每次改模型、prompt、tools、UI 或策略后，都跑一遍。

  5. 最后把 evals 结果、人工 dogfooding 和用户反馈放在一起，判断是否发布。

对 Claude Code 这种 agentic 产品来说，evals 同时承担了两个职责：产品验证，以及回归测试。

三、产品：能力剧本，而不是多年路线图

Anthropic 发现产品机会，不是纯需求驱动，也不是纯研究驱动。它同时看两条线：第一条线来自用户和客户，包括开发者使用 Claude Code 的摩擦、API 客户的真实任务、内部 dogfooding、社区反馈；第二条线来自模型，包括新模型是否具备更强的 coding、agentic behavior、tool use、long context，或者更好的可靠性。

Mike Krieger 在访谈里提到：产品团队嵌入研究团队，和 post-training、fine-tuning 一起工作，比只在模型外层做 UI 更有价值。这句话很关键，因为它说明 AI 产品的机会，不只是“模型出来以后在外面包一层界面”，而是产品、研究、工程要一起判断模型能力会打开什么新动作。

Joel Lewenstein 还提过一个概念，叫 “football playbook”。意思是团队准备一组候选打法，当新模型能力、用户反馈或技术条件出现时，就快速选择合适的 play 执行。这不是没有战略，而是把战略从“固定路线图”，换成了“能力触发型剧本”。原因也很直接：AI 模型能力变化太快。今天定下的 18 个月路线图，可能 6 个月后就有 30% 失效。

公开资料里看不到 Anthropic 使用很厚的 PRD。​它的需求文档，更像是一份压缩跨职能理解差异、同时为 AI 提供可执行上下文的材料。​可以参考的字段包括：关键用户，明确是谁，不是笼统的“所有用户”；核心任务，写用户真正要完成的工作，而不是功能名；模型能力假设，说明哪些行为依赖当前或未来模型能力；失败模式，提前列出模型、工具、UI、权限、文案分别可能怎么失败；验收 evals，用少量真实任务加评分标准定义结果；发布级别，标明 internal / Labs / research preview / beta / GA；上下文文件，则把 issue、Figma、代码路径、CLAUDE.md 放进去。​

这里最值得注意的是两个字段：失败模式，以及发布级别。大多数公司的 PRD 里没有这两个字段。失败模式，是把 AI 产品的不确定性提前结构化；发布级别，是把“发不发”这个二元问题，改成“按什么承诺级别发”。

Lewenstein 反复强调，AI 产品的“魔法”不在静态 UI 外壳，而在模型响应的不确定性里。所以，如果只用几张写死回复的 Figma 屏幕来验证 AI 产品，几乎注定看不到真正的问题。Anthropic 的做法，是尽早把原型接到真实模型、真实数据上去跑。Figma 仍然有用，但它主要用于结构对齐和层级讨论，而不是最终交付物。

这也解释了为什么 research preview / Labs 很重要。Anthropic 官方 Labs 公告里，把 Labs 定义为“探索 Claude 未来可能形态的空间”。这句话背后的意思是：它明确承认实验性质，也明确把早期想法带给用户，并收集反馈。因此，发布不再只有“发”或“不发”两种状态，而是有不同承诺级别：

  • Internal：员工 dogfooding、流程自动化，没有外部承诺。

  • Labs / Experimental：探索新交互或新能力，明确实验性质。

  • Research Preview：模型或产品能力早期开放，稳定性低于 GA。

  • Beta：目标用户可以持续使用，有一定产品承诺。

  • GA：面向广泛客户，进入正式承诺。

不同级别对应不同质量门槛，也对应不同的法律、支持、文档投入。这套机制让团队可以先发布、先验证，再逐步升级承诺，而不是被完美主义挡在 GA 门口。

四、设计：真实环境优先，设计师直接改代码

如果说 Anthropic 公开资料里有一块被反复强调，那就是设计。Lewenstein 给出的核心原则是：AI 产品的体验不能只靠静态 Figma 评估。原因很简单：模型回答不可预测，工具调用行为会变化，长上下文理解会出问题，各种失败模式也只有在真实或接近真实的环境里才会浮出来。

所以，Anthropic 的设计交付不再只是一套高保真稿，而是一组东西：Figma + 可运行原型 + 状态流 + 边界情况清单 + 代码 diff + PR + 用户研究记录 + eval 场景。这里的重点不是 Figma 不重要，而是 Figma 不能独自承担 AI 产品验证。

官方 PDF 里还有一个很明确的现象：设计师不再把所有视觉调整都交给工程师排期。字体、颜色、间距、边界状态、前端 polish，甚至部分状态管理，设计师都可以直接用 Claude Code 操作代码库。大致流程是：

  1. 设计师在产品里发现问题，比如间距不一致、状态缺失、错误文案不清楚、视觉反馈不足。

  2. 把意图写成明确 prompt。

  3. 让 Claude Code 先读相关文件，并解释代码结构。

  4. 要求 Claude 先列修改计划，而不是直接改。

  5. 批准后生成 diff。

  6. 本地运行，截图或录屏检查视觉。

  7. 如果涉及架构、状态管理或复杂逻辑，由工程师 review。

  8. 最后进入 PR，设计和工程共同确认。

这里第 7 步很关键：设计师能改代码，不等于设计师可以全权决定代码。架构、状态管理、安全、可维护性这些边界，仍然由工程师把关。

官方 PDF 里有一个特别值得抄下来的案例：某个功能或页面里，有 research preview / GA 相关文案需要在全代码库中更新。​传统流程通常是：设计或产品写文案变更需求，工程师搜索所有实例，法律逐条审查，设计再检查语气和一致性，整个过程一周左右。​Anthropic 的做法是：设计师用 Claude Code 全仓搜索相关文案，逐个审查上下文，和法律团队直接通电话实时确认措辞，两个 30 分钟电话搞定。​

拆开看，这里省掉的不是“工程师写代码的时间”。真正省掉的是设计到工程的需求传递、工程到法律的异步审查、法律到设计的来回反馈，以及设计再给工程的修改请求。也就是说，省掉的是人和人之间的等待时间。而 Claude Code 把搜索、上下文理解、批量替换、diff 生成这些动作，压缩进了同一个工作现场。

AI 产品还有大量容易被漏掉的边界状态：模型正在思考、调用工具、等待权限、无法访问文件、拒绝执行、部分完成、产生不确定结论、需要用户补充信息……官方 PDF 提到，设计团队会用 Claude Code 来映射 error states、logic flows 和 system statuses，在设计阶段就把 edge cases 找出来。

这套 SOP 也可以直接照抄：

1. 让 Claude Code 读代码、状态机、错误处理，生成所有状态清单。

2. 设计师逐个设计 UI、文案和恢复路径。

3. 工程师确认哪些状态真实存在。

4. PM 判断哪些状态影响发布承诺。

5. 最后让状态清单进入设计稿、代码实现和 eval 用例。

五、Anthropic 为什么能压缩流程，以及别人为什么不能照搬

把前面四块合起来看，Anthropic 的速度不是来自某一个技巧，而是六个机制叠加出来的结果：

1. builder = user，反馈翻译成本接近零。

2. Claude Code 全链路，把定位、计划、实现、测试、PR、review、文档生成压进一个工作流。

3. 设计师可以直接进代码，砍掉设计和工程之间的交接成本。

4. PM 嵌在研究和工程旁边，围绕模型能力定义机会。

5. research preview / Labs 降低了早期发布承诺。

6. Evals + Code Review 让快速迭代不完全依赖主观判断。

但速度有边界，这一点不能跳过。外部对 Cat Wu 访谈的批评指出过：Anthropic 的快速模式，依赖它自己的特殊结构。它控制底层模型；它的构建者就是用户；它做的是开发者产品，反馈循环很短；它还能在内部预期模型能力曲线。

所以，对于不控制模型的公司、用户和构建者差距很大的公司、销售和合规链条更长的 B2B 公司，以及主要服务非技术用户的公司来说，直接照搬“工程师看到反馈就当周上线”是要出事的。真正值得复制的，不是“低流程”，而是这个动作：把流程改造成可执行、可审查、可回滚、可验证的系统。

具体到自己的团队，可以先问几个问题：

我们的 reviewer 是不是产品的真实用户？如果不是，怎么补上这条信号？我们的“团队知识”现在写在哪里，AI 工具能读到吗？我们的 PRD 里有没有“失败模式”和“发布级别”字段？我们有没有 10 个能跑的 evals？我们的设计师能不能直接打开仓库改文案，组织上允许吗？我们的 PR review 里，AI 有没有已经做第一遍？

回答这些问题，比模仿“Anthropic 没流程”有用得多。

本文基于 Anthropic 官方 PDF《How Anthropic teams use Claude Code》、Claude Code GitHub Actions / Code Review / Evals / Long-running Agents 官方文档，以及 Mike Krieger、Joel Lewenstein、Boris Cherny、Cat Wu、Benjamin Mann 等公开访谈整理。​涉及具体内部组织、部署平台、发布审批等未公开的细节，已在原始 14000 字调研报告中明确标注证据边界。​

cover_image

傅里叶 晚点再听LaterCast

内容效果不满意？点此反馈

输入关键词开始搜索