--- url: https://ain.hmgf.hxcn.space/ai/claude-code-team-podcast-notes-202605.md description: >- 从小宇宙第 115 期《Claude Code 深度探秘》与 Anthropic 后续公开资料出发，整理 Claude Code 团队的分工、推进方式与对 AI Agent 团队的启发。 --- # Claude Code 团队是怎么工作的 > 跨国串门儿计划播客：最近听到的非常实用、信息不拖沓的 Claude Code / Anthropic 团队如何运营组织、如何工作的分享。非常适合身处或正在管理构建 AI Agent 产品的团队朋友听。里面有详实故事讲述团队分工、大家的做事方式以及变化，很实用。 结合 Latent Space 原始节目、Lenny's Podcast 访谈和 Anthropic 官方案例，可以看到更多关于团队分工和推进方式的细节。 **播客内容属于团队成员口述经验，不等同于 Anthropic 官方制度文件。** ## 节目与公开资料 播客入口： 小宇宙页显示，这一期是《跨国串门儿计划》第 115 期，发布时间是 **2025 年 5 月 10 日**，标题是《Claude Code 深度探秘：对话 Anthropic 核心团队成员》。节目说明也写明了它是对 Latent Space 那期 *Claude Code: Anthropic's CLI Agent* 的翻译克隆版本。 ![《跨国串门儿计划》第 115 期页面截图](https://gastigado.cnies.org/d/public/xiaoyuzhou-episode-115.png) 播客与补充资料： * 小宇宙页面（播客平台）： * Latent Space 原始节目与转录（播客 / 社媒发布）： * Claude Code 官方总览（官方文档）： * How Anthropic teams use Claude Code（官方案例）： * Running an AI-native engineering org（Anthropic 活动页）： * How Anthropic's product team moves faster than anyone else | Cat Wu（播客）： * 对应的中文翻译播客页（Apple 播客页）： 单独听这一期，侧重在 Claude Code 的功能；结合多份材料，可以看到更多关于团队分工和反馈机制的细节。 ## 团队分工：需求入口不只 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 甚至会用它做内部流程工具原型。 高价值反馈往往来自那些把产品接进自己真实工作流的人。 如果一个团队内部只有产品经理和工程师在试用，你拿到的反馈通常还是功能级的；但当设计、法务、营销、研究、数据团队都在用时，你拿到的就是工作方式级的反馈。 ## 他们怎么决定做什么 ### 自发使用跑出来后，团队才扩大投入 Boris 在原始播客里讲得很直白：Claude Code 一开始没有什么宏大总计划，就是一个实验。后来之所以逐步变成正式产品，是因为内部使用量涨得太快，已经很难忽视。 判断标准是：**真实采用跑出来，团队再扩编。** 做法很直接：让一个足够小的东西先在真实环境里跑，等使用强度自己长出来，再加人、加支持、加发布节奏。 这条逻辑在 Cat Wu 后来的访谈里也能对上。她提到 Anthropic 内部很多产品迭代，不再按半年、一季度那种节奏去算，而是尽可能压到周、甚至天。推动节奏变快的，是**减少了"先证明一切、再允许动手"的组织惯性**。 ### 围着模型三个月后的能力来想路线 Latent Space 里另一个很有意思的点，是 Cat Wu 说团队会一起想：**模型在三个月后会更擅长什么？** 这个问题对 AI 产品团队，因为很多功能如果只按今天的模型能力来设计，三个月后就会显得过度补丁化；反过来，如果完全等模型成熟再做，窗口可能已经过去了。 所以他们想的是基于近期能力跃迁仍能成立的最小设计，尽量少做只对今天有效的局部补丁。 Claude Code 为什么一直强调： * 做简单的事； * 做能工作的最小结构； * 尽量让文本 I/O 成为核心接口； * 不急着把一大堆复杂交互固化进 UI。 因为模型能力变化太快，**结构越轻，越容易跟着模型进化；结构越重，越容易在下一轮能力变化里变成包袱。** ### 优先级讨论，不只看用户想要什么 Cat Wu 在 2026 年那期产品访谈里还提到另一层判断：如果碰到冲突优先级，团队会看哪件事更符合 Anthropic 的总体使命。 常见情况是： * 用户要的很多； * 模型能做的越来越多； * 团队每周都能冒出十几个"马上能做"的方向； * 结果每件都沾一点，节奏却越来越散。 Anthropic 这里用的是使命；小团队未必有这么大的叙事，但至少也该有一条**比单次需求更高的取舍原则**。 ## 他们怎么推进：事情跑起来，流程再跟上 ### 产品推进靠持续清障，不靠完美排期 Cat Wu 在播客中描述的 PM 角色侧重于清除障碍。她说自己更多是在确保 legal、marketing 这些事情不挡路。这个表述背后包含的是一套很成熟的协作观： * 强产品感不只属于 PM； * 工程师可以直接提出产品方向； * PM 的价值不一定在"提出更聪明的点子"，而在"让正确的人推进时不被流程卡住"。 因为很多好功能不是在需求讨论会上想出来的，往往是工程师在真实使用中"顺手发现必须补一个东西"。 ### 并行、自动化、可组合，是他们默认的推进方式 无论是原始播客还是后续 Every 的访谈，Claude Code 团队都强调：他们更愿意把它做成 Unix utility 那类可组合工具。 这个理念会直接影响团队自己的工作方式。 在他们眼里，产品是一组可组合的能力： * 可以并行跑多个 session； * 可以接进 tmux、GitHub Actions、CI、hooks； * 可以通过 slash commands 把高频动作压成短命令； * 可以让 subagents 分工，再互相挑错。 Every 那篇访谈里提到 Boris 会让多个 subagents 并行做 code review：有的查风格，有的看历史实现，有的找明显 bug，之后再开第二轮 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 自己的成长路径是同一条线。最早它也是内部实验，后来因为大家用得越来越多、用法越来越野，才逐渐被认定为值得正式投入。 因为大家还在共同摸索工作界面，很多价值不是从设计图里推出来的，而是在使用中长出来的。 一个团队如果只统计"用户有没有完成既定流程"，往往会错过更大的机会。更应该看的还有： * 用户把它接到了哪些本来没想到的地方； * 哪些职能的人开始自学使用； * 哪些功能起初不在主流程里，却高频出现在边缘工作流里。 ### 工具变了，流程也得重写 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，哪些还只是辅助？ * 如果今天团队规模翻倍，我们的工作方式会不会立刻失稳？ 如果这些问题还没系统聊过，拿这五组问题开一次会，通常比继续补功能列表更有用。