3D环梦工坊编程竞赛组

    Appearance

    Claude Code 团队是怎么工作的 ​

    跨国串门儿计划播客：最近听到的非常实用、信息不拖沓的 Claude Code / Anthropic 团队如何运营组织、如何工作的分享。非常适合身处或正在管理构建 AI Agent 产品的团队朋友听。里面有详实故事讲述团队分工、大家的做事方式以及变化，很实用。

    这篇重点放在节目里那些能落到团队方法的细节，再用 Anthropic 后续公开资料补一层背景。

    播客内容属于团队成员口述经验，不等同于 Anthropic 官方制度文件。

    节目与公开资料 ​

    播客入口：https://www.xiaoyuzhoufm.com/episode/681f316cb7c8a9962c640438

    小宇宙页显示，这一期是《跨国串门儿计划》第 115 期，发布时间是 2025 年 5 月 10 日，标题是《Claude Code 深度探秘：对话 Anthropic 核心团队成员》。节目说明也写明了它是对 Latent Space 那期 Claude Code: Anthropic's CLI Agent 的翻译克隆版本。

    《跨国串门儿计划》第 115 期页面截图

    播客与补充资料：

    如果只听小宇宙这一期，很容易把它当成一档"Claude Code 功能介绍"。几份材料放在一起看，文章更关心一件事：一个 AI 原生团队怎样把产品、工程、研究和内部使用者放进同一条反馈链里。

    团队分工：需求入口不只 PM ​

    按 Latent Space 这期转录，Claude Code 早期核心团队至少可以明确看到几层角色：

    • Boris Cherny：创始工程负责人，最早的原型推动者
    • Cat Wu：产品负责人，负责路线梳理、跨部门清障、对外发布配合
    • Sid、Ben 等早期成员：和 Boris 一起把内部实验推成正式团队
    • 内部研究员与工程师：最早一批高频用户，也是最重要的反馈来源

    播客里有个细节很能说明这支团队是怎么长出来的。团队并没有先把 org chart 画满再去招人。Boris 做了一个能在终端里跑的原型，内部使用数据迅速上涨，团队才逐步补齐 PM 和更多支持角色。Cat Wu 也是因为自己在用早期版本做数据可视化、持续给反馈，后来直接被拉进核心团队。

    不少传统团队会由 PM 定义需求，再排期开发，上线后再收反馈。Claude Code 的起步顺序反过来了：工程师做出一个足够有用的原型，内部高密度使用者很快把问题和机会都暴露出来，PM 再把已经浮现的方向整理清楚，把发布、法务、营销、协同这些障碍清掉。很多新功能，本来就是团队成员给自己补工具时长出来的。

    Cat Wu 在 Latent Space 那期里说自己是 "light touch PM"。她的工作重点不在把 roadmap 层层拆成任务、再逐项下派，而是做三件事：

    • 观察需求有没有持续生命力；
    • 判断哪些方向和模型未来几个月的能力曲线一致；
    • 让工程团队别被非核心障碍拖慢。

    这也是为什么她后来在 Lenny's Podcast 那期里继续强调，Claude Code 团队很多方向都来自最接近问题的人直接动手试出来，再由团队收束。

    反馈入口：研究员、工程师、设计、法务都算"产品用户" ​

    只看播客，你会觉得 Claude Code 主要是给工程师用的。Anthropic 2026 年那篇《How Anthropic teams use Claude Code》把这件事补完整了：在 Anthropic 内部，Claude Code 早就成了跨职能工作界面，不再只是工程团队工具。

    官方案例里能看到的使用群体包括：

    • Product Engineering
    • Product Design
    • Security Engineering
    • Inference team
    • Data Infrastructure
    • Growth Marketing
    • Legal team
    • Data scientists

    这意味着他们拿到的"用户反馈"已经不只局限于 bug 反馈，还包括不同职能的工作流反馈。

    比如：

    • Product Engineering 把它当成排查 bug、定位改动入口的第一站；
    • Product Design 不只让它写测试，还会在设计阶段让它帮忙枚举错误状态、异常情况和逻辑流；
    • Security Engineering 用它处理 incident、写 runbook、推 TDD 流程；
    • Growth Marketing 拿它批量处理广告文案和自动化流程；
    • Legal team 甚至会用它做内部流程工具原型。

    对 AI Agent 团队来说，这里有个很重要的点：高价值反馈，往往来自那些把产品接进自己真实工作流的人。

    如果一个团队内部只有产品经理和工程师在试用，你拿到的反馈通常还是功能级的；但当设计、法务、营销、研究、数据团队都在用时，你拿到的就是工作方式级的反馈。这两种反馈的密度完全不同。

    他们怎么决定做什么 ​

    自发使用跑出来后，团队才扩大投入 ​

    Boris 在原始播客里讲得很直白：Claude Code 一开始没有什么宏大总计划，就是一个实验。后来之所以逐步变成正式产品，是因为内部使用量涨得太快，已经很难忽视。

    这背后是一种很克制的判断标准：真实采用跑出来，团队再扩编。

    做法很直接：让一个足够小的东西先在真实环境里跑，等使用强度自己长出来，再加人、加支持、加发布节奏。

    这条逻辑在 Cat Wu 后来的访谈里也能对上。她提到 Anthropic 内部很多产品迭代，不再按半年、一季度那种节奏去算，而是尽可能压到周、甚至天。推动节奏变快的，是减少了"先证明一切、再允许动手"的组织惯性。

    围着模型三个月后的能力来想路线 ​

    Latent Space 里另一个很有意思的点，是 Cat Wu 说团队会一起想：模型在三个月后会更擅长什么？

    这个问题对 AI 产品团队特别重要，因为很多功能如果只按今天的模型能力来设计，三个月后就会显得过度补丁化；反过来，如果完全等模型成熟再做，窗口可能已经过去了。

    所以他们想的是基于近期能力跃迁仍能成立的最小设计，尽量少做只对今天有效的局部补丁。

    这也解释了 Claude Code 为什么一直强调：

    • 做简单的事；
    • 做能工作的最小结构；
    • 尽量让文本 I/O 成为核心接口；
    • 不急着把一大堆复杂交互固化进 UI。

    因为模型能力变化太快，结构越轻，越容易跟着模型进化；结构越重，越容易在下一轮能力变化里变成包袱。

    优先级讨论，不只看用户想要什么 ​

    Cat Wu 在 2026 年那期产品访谈里还提到另一层判断：如果碰到冲突优先级，团队会看哪件事更符合 Anthropic 的总体使命。

    这类判断在 AI 团队里很有用。常见情况是：

    • 用户要的很多；
    • 模型能做的越来越多；
    • 团队每周都能冒出十几个"马上能做"的方向；
    • 结果每件都沾一点，节奏却越来越散。

    有一个更高层、能压住局部最优的判断标尺，会让很多拉扯少掉。Anthropic 这里用的是使命；小团队未必有这么大的叙事，但至少也该有一条比单次需求更高的取舍原则。

    他们怎么推进：事情跑起来，流程再跟上 ​

    产品推进靠持续清障，不靠完美排期 ​

    Cat Wu 在播客里的角色，很像一个清障型 PM。她说自己更多是在确保 legal、marketing 这些事情不挡路。这个表述背后包含的是一套很成熟的协作观：

    • 强产品感不只属于 PM；
    • 工程师可以直接提出产品方向；
    • PM 的价值不一定在"提出更聪明的点子"，而在"让正确的人推进时不被流程卡住"。

    对 AI Agent 团队来说，这种分工尤其重要。因为很多好功能不是在需求讨论会上想出来的，往往是工程师在真实使用中"顺手发现必须补一个东西"。

    如果 PM 还把自己放在唯一需求入口的位置，速度通常会掉得很快。

    并行、自动化、可组合，是他们默认的推进方式 ​

    无论是原始播客还是后续 Every 的访谈，Claude Code 团队都反复强调一件事：他们更愿意把它做成 Unix utility 那类可组合工具。

    这个理念会直接影响团队自己的工作方式。

    在他们眼里，产品是一组可组合的能力：

    • 可以并行跑多个 session；
    • 可以接进 tmux、GitHub Actions、CI、hooks；
    • 可以通过 slash commands 把高频动作压成短命令；
    • 可以让 subagents 分工，再互相挑错。

    Every 那篇访谈里提到 Boris 会让多个 subagents 并行做 code review：有的查风格，有的看历史实现，有的找明显 bug，之后再开第二轮 agent 专门去质疑第一轮结论，尽量减少误报。

    这说明"多 agent"在他们那里已经是日常工作结构的一部分：并行审阅、相互校验、自动初筛、人类最终把关。

    这对很多 AI Agent 团队是很直接的提醒：别急着把 agent 当万能执行者，更稳的做法往往是把它放进一个有校验、有分工、有人工兜底的链路里。

    团队会把共识写进环境 ​

    Every 那篇访谈里还有两个很实用的点：

    • 用共享 settings.json 预先批准常见命令、拦掉高风险操作；
    • 让 Claude 写 task diary，再蒸馏成可复用的经验。

    这两件事都在做同一件事：把团队经验外化。

    很多 AI 团队内部都有一些 tacit knowledge，比如：

    • 哪些命令可以放行；
    • 哪些路径不要碰；
    • 什么样的日志有价值；
    • 哪类任务适合并行拆；
    • 哪些修改一定要人工过一遍。

    问题是，如果这些经验只留在少数资深成员脑子里，团队规模一扩大，产出就会马上不稳定。

    Claude Code 团队的思路，是尽量把这些东西变成：

    • 配置；
    • slash commands；
    • hooks；
    • 共享记忆文件；
    • 自动 review 流程。

    这比"写一篇大家都不看的 wiki"更有效，因为它直接进入了执行环境。

    他们怎么处理变化 ​

    产品默认会变，所以接口要轻 ​

    Claude Code 的很多设计，都能看出他们默认"变化会非常频繁"。

    例如播客里反复提到的几件事：

    • 记忆用最简单的 Markdown 文件实现；
    • 上下文压缩直接让 Claude 自己总结；
    • 规划能力也尽量用文本接口承载；
    • 工具尽量少而通用，能删就删。

    这种做法是在主动给变化留空位。AI 产品和传统 SaaS 功能树不太一样，很多今天看起来必须存在的中间结构，下一代模型可能直接就吞掉了。

    Apple 播客那页对 Cat Wu 访谈的中文摘要里，把这一点说得很清楚：有些功能在早期像"拐杖"，是为了补模型短板；一旦模型长出来，这些额外结构就该逐步移除。

    他们看重的是功能能不能继续成立。早期可以拿临时结构补短板，模型长出来后就把这些结构撤掉。

    用户的"误用"也是需求线索 ​

    Every 那篇访谈里，Boris 提到一个非常典型的产品判断：把产品做得足够可 hack、足够开放，让用户能拿去做原本没设计过的事情；然后观察这些"误用"，再判断里面有没有稳定需求。

    这和 Claude Code 自己的成长路径是同一条线。最早它也是内部实验，后来因为大家用得越来越多、用法越来越野，才逐渐被认定为值得正式投入。

    对 AI Agent 产品尤其如此。因为大家还在共同摸索工作界面，很多价值不是从设计图里推出来的，而是在使用中长出来的。

    一个团队如果只统计"用户有没有完成既定流程"，往往会错过更大的机会。更应该看的还有：

    • 用户把它接到了哪些本来没想到的地方；
    • 哪些职能的人开始自学使用；
    • 哪些功能起初不在主流程里，却高频出现在边缘工作流里。

    工具变了，流程也得重写 ​

    Fiona Fung 在 Running an AI-native engineering org 那场分享里的简介写得很直接：当 agentic coding 从个人工具变成组织默认方式，流程会先被改写；被打碎的往往是 review、ownership、hiring 这些原本看似稳定的组织规则。

    很多团队会以为"AI 提效"就是同样的人、同样的流程、只是写得更快。但如果产出速度、并行能力、跨角色协作方式都变了，原来的 review、职责边界、招聘标准，很可能就不再适配。

    变化管理更该追问的是：

    • 代码审查还该怎么分层；
    • 谁对 agent 产出的结果负责；
    • 交付周期缩短后，发布机制要不要改；
    • 招人时到底更看重写代码能力、判断力，还是编排 agent 的能力。

    对 AI Agent 团队的启发 ​

    如果要把上面的材料带回自己团队，可以从下面几件事试起。

    1. 内部离不开的原型，比满编团队更重要 ​

    Claude Code 的起点是一个被内部高频采用的原型，组织设计是后补的。对小团队来说，更重要的是证明"有人离不开"，再讨论要不要扩编。

    2. PM 的工作，很多时候是清障 ​

    当工程师、研究员、设计师都在用产品时，很多最好功能来自使用现场。PM 更该做的是提炼方向、处理依赖、协调对外发布，不必把自己卡成唯一需求入口。

    3. 反馈体系要跨职能 ​

    如果你的 AI Agent 只在工程组内流转，你得到的只是工程反馈；如果它进入销售、运营、法务、设计、数据团队，你得到的才是工作流反馈。后者对产品演化更关键。

    4. 用轻结构对冲模型变化 ​

    别太早把大量复杂机制焊死。模型还在快速进化，今天的补丁功能，明天可能会变成负担。能用简单文件、文本接口、可替换模块解决的问题，先别上过重结构。

    5. 把团队经验写进环境 ​

    共享设置、自动 review、slash commands、hooks、任务日志，这些都在做同一件事：让团队能力可复制。AI Agent 团队越早把经验外化，越不容易在规模稍微变大时掉速。

    6. 自动化要能稳定托付 ​

    Apple 播客页对 Cat Wu 访谈的摘要里有一句话很能说明问题：95% 的自动化，很多时候等于没有自动化。因为只要人还得时刻盯着最后那 5%，流程就没有真正交出去。

    这句话是在提醒团队尽快做判断：如果它还只是辅助，就按辅助来设计；如果它要接管流程，就做到能被放心托付。最消耗人的，往往是长期停在中间状态。

    引用说明：这是一组口述资料 ​

    • 小宇宙第 115 期是对外文播客的翻译克隆版；
    • Latent Space 与 Lenny's Podcast 的主体内容，都属于嘉宾口述；
    • Apple 播客页里的中文摘要，是二次翻译与整理；
    • Anthropic 官方文档、官方新闻稿、官方活动页，属于更容易核验的一手公开资料。

    所以这篇文章适合拿来理解 Claude Code 团队的协作方式和产品推进习惯，不适合把某一句话直接上升成 Anthropic 的正式制度。

    比较稳妥的读法是：用播客理解他们怎么想、怎么协作，再用官方资料核对哪些做法已经体现在正式产品与公开案例里；带回自己团队时，只保留那些确实能用的结构。

    一个 AI Agent 团队复盘提纲 ​

    如果你想拿这篇去复盘自己的团队，可以直接照下面这组问题开会：

    一、分工 ​

    • 我们现在的产品方向，主要是谁在提出？
    • 工程、设计、研究、运营、销售里，谁是真正高频使用者？
    • 哪些角色在给反馈，哪些角色其实还没被接进来？

    二、优先级 ​

    • 我们现在决定做什么，靠的是老板判断、客户催促，还是实际使用强度？
    • 有没有一条比单次需求更高的取舍原则？
    • 我们做的功能，有多少是在为三个月后的模型能力做铺垫？

    三、推进方式 ​

    • 哪些工作还在串行推进，本来可以并行？
    • 哪些高频动作已经写成命令、脚本、模板、hook 或共享配置？
    • 现在的 review 机制，适配 agent 产出了吗？

    四、变化管理 ​

    • 我们有哪些"临时补丁"已经该撤掉了？
    • 用户有没有把产品拿去做我们原本没设计过的事？
    • 这些"误用"里，哪些会变成下一步产品机会？

    五、团队能力 ​

    • 团队里哪些经验还只掌握在少数人脑子里？
    • 哪些任务已经能放心托付给 agent，哪些还只是辅助？
    • 如果今天团队规模翻倍，我们的工作方式会不会立刻失稳？

    如果这些问题还没系统聊过，拿这五组问题开一次会，通常比继续补功能列表更有用。