Claude Code 实战：如何用一个工具支撑整个小团队丨Aakash Gupta

Claude Code 实战：如何用一个工具支撑整个小团队丨Aakash Gupta Claude Code 实战：如何用一个工具支撑整个小团队丨Aakash Gupta Modified April 9 🔗 原文链接： https://mp.weixin.qq.com/s/gdi9AbCG... 原创 Capihom Capihom 晚点再听LaterCast2026年4月9日 00:29 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 4100 字，如果你现在没有时间，试试转成播客稍后再听 "我用了 1500 小时，还在每天迭代自己的工作流。" "上下文不是越多越好——思考空间才是核心。" "Claude Code 不是写代码用的，是做知识工作用的。" Hannah Stulberg 是 DoorDash 的 PM，前 Google APM，写出了那篇广泛传播的《Claude Code for Everything》。她在 Claude Code 上已经投入超过 1500 个小时，而且至今仍在每天改进自己的工作流。这期 Aakash Gupta 的播客里，她把自己的「Team OS」完整拆解给了所有人——一个让 PM 一个人撑起 20 人团队的共享知识库系统。如果你是 PM、工程师或设计师，正在思考如何用 AI 真正放大自己的工作效率，这篇文章值得认真读完。 什么是 Team OS：不是个人 AI 助理，是全队的共享上下文系统 Team OS（团队操作系统）的核心逻辑很简单： 把团队所有的共享上下文放进一个代码仓库，让每个人——工程师、设计师、分析师、运营——都能在不打扰 PM 的情况下自助获取所需信息。 Hannah 的 Team OS 仓库有三个主要部分： 文件夹（放共享的 agents、commands 和 skills）、产品开发文件夹（按职能分子目录）、团队文件夹（onboarding 指南、复盘文档等）。过去一个 PM 可能只需要支持三四个工程师，现在往往要支持十个，还要对接销售、市场、客服。角色边界正在模糊，PM 需要做数据分析、做原型、写设计，每个人都开始参与产品决策。Team OS 就是应对这种变化的基础设施。这套系统并不绑定 Claude——它同样可以在 Cursor、Codex 或者任何 coding agent 里运行。本质上它是一套知识管理协议，而不是一个工具。任何团队都可以从这一周最烦你的那个重复查询开始，把答案写进 CLAUDE.md，这就是 Team OS 的第一块砖。 "我不把 Team OS 看成帮助大家成为更好 PM 的工具——我把它看成帮助团队每个人放大自己能力、并且借助队友知识的系统。" 根 CLAUDE.md：越精简越有力，超过一页就是负担 根目录的 CLAUDE.md 是整个系统的核心导航，在每次会话时自动加载，所以这里放的内容会消耗每次会话的上下文预算。Hannah 的根 CLAUDE.md 只包含三类信息：文档索引（告诉 Claude 去哪里找什么信息）、团队成员名单（含每人在核心工具里的 handle，比如 Slack ID）、关键 Slack 频道列表。 有了团队名单，你直接写「把这个 bug 发给 Alex」，Claude 就知道 Alex 的 Slack ID，通过 Slack MCP 直接发送，不需要每次解释「Alex 是我的工程师」。 有了频道地图，你写「发进产品频道」，Claude 知道去哪里。类似地，当会议记录里出现「Taylor 说」，Claude 知道 Taylor 是你的设计合伙人，能够在不额外解释的情况下正确理解这条反馈的权重和背景。根 CLAUDE.md 的核心原则只有一条：保持在一页以内，超过这个限制，你就在每次会话开始时白白消耗上下文预算。 "很多人对 CLAUDE.md 的理解是反的——你不想在里面放很多东西。CLAUDE.md 应该极度精简，这是大多数人用错的地方。" 嵌套索引与上下文 101：为什么只用了 3% 的上下文窗口 Hannah 专门讲了「上下文 101」，这是理解整个系统设计的底层理论。上下文是当前会话中 LLM 能访问的信息总量；上下文窗口是它能容纳的上限（约 100 万 tokens，相当于七八本小说）；压缩（Compaction）是上下文窗口满了之后触发的信息压缩，大量细节会丢失；而思考空间（Thinking Room）是上下文窗口减去已用量之后剩余的空间，这才是模型真正用来推理的地方。 信息越堆越多，模型能思考的空间就越少——这跟人完全一样。 整个仓库的设计目标只有一个：让 Claude 在正确的时间读取正确的信息，不多不少。做到这一点的机制是嵌套的 CLAUDE.md 索引：仓库里的每个子目录都有自己的 CLAUDE.md，内容只是一个文档导航索引，告诉 Claude 这个文件夹里有什么。Hannah 在直播演示里提问「谁是我的头部客户」，Claude 通过索引精准定位到客户文件夹，只读了相关文件，整个查询只用了 3% 的上下文窗口。 "CLAUDE.md 的艺术，就是最小化回答每个问题所需的上下文消耗。如果你在问客户问题，Claude 不应该去读任何一行 SQL 查询。" 三层 Token 架构：让 Claude 永远只读「该读的」 Hannah 的系统里有一个精心设计的三层信息架构：第一层是始终加载的根 CLAUDE.md，约 500 tokens，每次会话自动载入；第二层是各子目录的索引 CLAUDE.md，每个 200 500 tokens，按需进入时才加载；第三层是实际内容文件，1000 10000 tokens 不等，只在真正需要时才读取。这个设计有一个重要的反直觉推论： 更多的文件结构，反而意味着更少的上下文消耗。 把客户信息按每个客户单独建文件，比把所有客户信息堆在一个大文件里，让 Claude 的检索效率高得多。举个具体的例子：如果你有 50 个客户，把所有人的资料堆进一个文件，Claude 每次查询都要加载全部 50 份；而如果按客户分文件存放，配合索引 CLAUDE.md，Claude 只会读取那一个相关客户的文件。上下文消耗可能差了 50 倍。Hannah 还提到，她在状态栏里实时显示上下文占用率，随时知道当前会话还剩多少「思考空间」。这不是炫技，是工程师本能——你不会在不知道内存占用的情况下部署服务。 "每个文件夹都有一个导航 CLAUDE.md——这是告诉 Claude 如何在整个仓库里找路的地图，而不是让它到处乱搜索。" 分析师知识入库：把数据能力从人身上解耦出来 Team OS 里最能体现杠杆效应的部分，是 analytics 文件夹的设计。Hannah 把分析能力拆成三个独立层：指标定义（Metrics，每个指标是什么、如何计算）、SQL 查询（Queries，对应的查询语句）、表结构（Schemas，支撑指标的数据表）。这三层按产品模块独立存放，而非混在一起。好处是：如果你只想查某个指标的定义，Claude 不会顺带把相关的 SQL 和表结构都加载进来，避免无效的上下文消耗。 工程师凌晨 on call，不需要等数据分析师醒来，可以直接查询功能的关键指标。 PM 写 PRD 的时候，可以让 Claude 从仓库里找出所有相关指标，判断哪些需要更新、哪些需要新增。如果仓库接入了 Snowflake MCP 或其他数据分析 MCP，Claude 甚至可以直接执行查询、返回实时数据，而不只是告诉你怎么查。Hannah 和她的数据科学家同事有一个明确的协作协议：每次新功能上线前，两人必须对齐好指标定义、查询、表结构，全部 check in 到仓库——然后功能才能发布。这是他们的发布门控。 "这就等于我拥有了分析师大脑里所有的精华——所有正确的查询方式，让我能用正确的方法做分析，不依赖猜测，不产生幻觉。" Playbook 与技能标准化：从「祈祷不出错」到「系统性保证正确」 如果你只是把 Claude 指向数据库说「帮我分析一下用户流失」，它可能会自己发明分析方法，产生错误结论。Team OS 的解法是：由分析师或数据科学家提前把正确的分析方法写进 Playbook，存入仓库。当 Hannah 查询「用户在哪个环节流失」时，Claude 会先找到对应的 Playbook，按照已被人工审核过的方法论执行分析，而不是即兴发挥。 这是从「祈祷 Claude 不出错」到「系统性保证分析正确」的本质跳跃。 Playbook 的价值不只是防止幻觉，它还在把专家知识编码进系统——即便那个分析师离职了，正确的分析方法依然留在仓库里，不会随人走。同样的逻辑也应用在技能文件（Skills）上。团队所有人的客户通话总结都遵循同一个模板，哪怕十个不同的客户经理以各自的方式整理通话，最终所有总结都会以完全相同的格式输出。当你需要跨二十个客户做交叉分析时，数据已经结构化一致，Claude 可以高效处理，不需要你先花时间统一格式。 "哪怕 10 个不同的客户经理以不同方式整理了通话，所有总结都会以完全相同的格式输出——这就是技能文件的杠杆所在。" Plan Mode 写策略文档：五阶段让文档质量提升十倍 Hannah 的策略文档写作流程是这期播客里最让人意外的部分。她不是「发一个 prompt 让 Claude 写文档」，而是把整个写作过程分成五个阶段执行：加载上下文（让 Claude 读取仓库里所有相关文件）、提问环节（Claude 主动向你提问，澄清所有模糊的地方）、构建计划（生成详细的写作计划文件，包含每个 agent 将使用什么 prompt、读哪些文件）、逼迫反思（让 Claude 从不同角度追问你，帮你发现论证里的漏洞）、最后由主 agent 汇编各子 agent 的输出。 长文档必须拆分给多个并行 agent 分别写，每个 agent 只写一节，输出到临时文件，最后由主 agent 合并——否则单个 agent 的上下文会溢出，辛苦生成的内容全部丢失。 Hannah 还强调：计划文件本身也要存入仓库。你两个月后可能需要写类似的文档，不需要从零开始设计流程；或者你的队友要做类似的事，可以直接参考你的计划。Claude 内置的计划文件会在 24 到 72 小时内被清除，所以把重要的计划手动存进仓库是必要的习惯。 "如果你要让一个员工花费大量时间和 token 做一件事，你至少应该先知道这个员工打算怎么做——就像你不会在不知道下属计划的情况下让他放手去干。" 1500 小时的学习飞轮：先自动化一件事，腾出时间继续学 Hannah 分享了让整个系统持续进化的底层方法：飞轮。 不是先学会所有技能再开始用，而是先自动化一件让你烦的事，释放出时间，用这个时间去学新东西。 她建议：如果你只有两小时，不要去搭一个完整的 Team OS，而是问自己「我能自动化什么，给自己下周腾出六小时的学习时间」。找到那一件事，做掉，然后用腾出来的时间继续学。Aakash 补充了他自己的学习提示词：先让 Claude 爬取 Anthropic 最近 90 天发布的所有功能，再读取 Claude Code 头部用户最近的热帖，然后和自己当前的工作流对比，输出一份「如何把我的工作流提升 10 倍」的报告。这个提示词有效是因为模型的训练数据截止于 2024 年，它甚至不总是了解自己的最新功能，需要主动给它喂进来。关于工具选择，Hannah 的答案很简单：需要高上下文、复杂推理的任务，用某种 coding agent；只是快速问一个问题、不需要太多上下文，用 Chat。但她认为绝大多数 PM 的工作——写文档、做分析、做原型、整理客户反馈——都应该在 coding agent 里完成。最后，她说了一句最反直觉的话：Claude Code 是迄今为止最适合做「知识工作」的工具，不是因为它擅长写代码，而是因为它能在正确的上下文里做任何事。她写的那篇文章叫《Claude Code for Everything》，正是这个意思。 "你们都在下载别人的技能和命令，但不知道为什么它们能用——我建议先让 Claude 解释这个东西的逻辑，理解它，然后你才能在它不按预期工作时知道如何迭代。" 内容来源："How this PM Used Claude Code to Support 20 People"丨Product Growth Podcast（嘉宾：Hannah Stulberg） 原视频：https://www.youtube.com/watch?v=0UArKLQ6bXA 如果你喜欢深度好文，可以用「晚点再听 LaterCast 小程序」，将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/gdi9AbCG... 🔗 原文链接： https://mp.weixin.qq.com/s/gdi9AbCG... https://mp.weixin.qq.com/s/gdi9AbCG... 原创 Capihom Capihom 晚点再听LaterCast2026年4月9日 00:29 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 4100 字，如果你现在没有时间，试试转成播客稍后再听 "我用了 1500 小时，还在每天迭代自己的工作流。" "上下文不是越多越好——思考空间才是核心。" "Claude Code 不是写代码用的，是做知识工作用的。" Hannah Stulberg 是 DoorDash 的 PM，前 Google APM，写出了那篇广泛传播的《Claude Code for Everything》。她在 Claude Code 上已经投入超过 1500 个小时，而且至今仍在每天改进自己的工作流。这期 Aakash Gupta 的播客里，她把自己的「Team OS」完整拆解给了所有人——一个让 PM 一个人撑起 20 人团队的共享知识库系统。如果你是 PM、工程师或设计师，正在思考如何用 AI 真正放大自己的工作效率，这篇文章值得认真读完。 什么是 Team OS：不是个人 AI 助理，是全队的共享上下文系统 Team OS（团队操作系统）的核心逻辑很简单： 把团队所有的共享上下文放进一个代码仓库，让每个人——工程师、设计师、分析师、运营——都能在不打扰 PM 的情况下自助获取所需信息。 Hannah 的 Team OS 仓库有三个主要部分： 文件夹（放共享的 agents、commands 和 skills）、产品开发文件夹（按职能分子目录）、团队文件夹（onboarding 指南、复盘文档等）。过去一个 PM 可能只需要支持三四个工程师，现在往往要支持十个，还要对接销售、市场、客服。角色边界正在模糊，PM 需要做数据分析、做原型、写设计，每个人都开始参与产品决策。Team OS 就是应对这种变化的基础设施。这套系统并不绑定 Claude——它同样可以在 Cursor、Codex 或者任何 coding agent 里运行。本质上它是一套知识管理协议，而不是一个工具。任何团队都可以从这一周最烦你的那个重复查询开始，把答案写进 CLAUDE.md，这就是 Team OS 的第一块砖。 "我不把 Team OS 看成帮助大家成为更好 PM 的工具——我把它看成帮助团队每个人放大自己能力、并且借助队友知识的系统。" 根 CLAUDE.md：越精简越有力，超过一页就是负担 根目录的 CLAUDE.md 是整个系统的核心导航，在每次会话时自动加载，所以这里放的内容会消耗每次会话的上下文预算。Hannah 的根 CLAUDE.md 只包含三类信息：文档索引（告诉 Claude 去哪里找什么信息）、团队成员名单（含每人在核心工具里的 handle，比如 Slack ID）、关键 Slack 频道列表。 有了团队名单，你直接写「把这个 bug 发给 Alex」，Claude 就知道 Alex 的 Slack ID，通过 Slack MCP 直接发送，不需要每次解释「Alex 是我的工程师」。 有了频道地图，你写「发进产品频道」，Claude 知道去哪里。类似地，当会议记录里出现「Taylor 说」，Claude 知道 Taylor 是你的设计合伙人，能够在不额外解释的情况下正确理解这条反馈的权重和背景。根 CLAUDE.md 的核心原则只有一条：保持在一页以内，超过这个限制，你就在每次会话开始时白白消耗上下文预算。 "很多人对 CLAUDE.md 的理解是反的——你不想在里面放很多东西。CLAUDE.md 应该极度精简，这是大多数人用错的地方。" 嵌套索引与上下文 101：为什么只用了 3% 的上下文窗口 Hannah 专门讲了「上下文 101」，这是理解整个系统设计的底层理论。上下文是当前会话中 LLM 能访问的信息总量；上下文窗口是它能容纳的上限（约 100 万 tokens，相当于七八本小说）；压缩（Compaction）是上下文窗口满了之后触发的信息压缩，大量细节会丢失；而思考空间（Thinking Room）是上下文窗口减去已用量之后剩余的空间，这才是模型真正用来推理的地方。 信息越堆越多，模型能思考的空间就越少——这跟人完全一样。 整个仓库的设计目标只有一个：让 Claude 在正确的时间读取正确的信息，不多不少。做到这一点的机制是嵌套的 CLAUDE.md 索引：仓库里的每个子目录都有自己的 CLAUDE.md，内容只是一个文档导航索引，告诉 Claude 这个文件夹里有什么。Hannah 在直播演示里提问「谁是我的头部客户」，Claude 通过索引精准定位到客户文件夹，只读了相关文件，整个查询只用了 3% 的上下文窗口。 "CLAUDE.md 的艺术，就是最小化回答每个问题所需的上下文消耗。如果你在问客户问题，Claude 不应该去读任何一行 SQL 查询。" 三层 Token 架构：让 Claude 永远只读「该读的」 Hannah 的系统里有一个精心设计的三层信息架构：第一层是始终加载的根 CLAUDE.md，约 500 tokens，每次会话自动载入；第二层是各子目录的索引 CLAUDE.md，每个 200 500 tokens，按需进入时才加载；第三层是实际内容文件，1000 10000 tokens 不等，只在真正需要时才读取。这个设计有一个重要的反直觉推论： 更多的文件结构，反而意味着更少的上下文消耗。 把客户信息按每个客户单独建文件，比把所有客户信息堆在一个大文件里，让 Claude 的检索效率高得多。举个具体的例子：如果你有 50 个客户，把所有人的资料堆进一个文件，Claude 每次查询都要加载全部 50 份；而如果按客户分文件存放，配合索引 CLAUDE.md，Claude 只会读取那一个相关客户的文件。上下文消耗可能差了 50 倍。Hannah 还提到，她在状态栏里实时显示上下文占用率，随时知道当前会话还剩多少「思考空间」。这不是炫技，是工程师本能——你不会在不知道内存占用的情况下部署服务。 "每个文件夹都有一个导航 CLAUDE.md——这是告诉 Claude 如何在整个仓库里找路的地图，而不是让它到处乱搜索。" 分析师知识入库：把数据能力从人身上解耦出来 Team OS 里最能体现杠杆效应的部分，是 analytics 文件夹的设计。Hannah 把分析能力拆成三个独立层：指标定义（Metrics，每个指标是什么、如何计算）、SQL 查询（Queries，对应的查询语句）、表结构（Schemas，支撑指标的数据表）。这三层按产品模块独立存放，而非混在一起。好处是：如果你只想查某个指标的定义，Claude 不会顺带把相关的 SQL 和表结构都加载进来，避免无效的上下文消耗。 工程师凌晨 on call，不需要等数据分析师醒来，可以直接查询功能的关键指标。 PM 写 PRD 的时候，可以让 Claude 从仓库里找出所有相关指标，判断哪些需要更新、哪些需要新增。如果仓库接入了 Snowflake MCP 或其他数据分析 MCP，Claude 甚至可以直接执行查询、返回实时数据，而不只是告诉你怎么查。Hannah 和她的数据科学家同事有一个明确的协作协议：每次新功能上线前，两人必须对齐好指标定义、查询、表结构，全部 check in 到仓库——然后功能才能发布。这是他们的发布门控。 "这就等于我拥有了分析师大脑里所有的精华——所有正确的查询方式，让我能用正确的方法做分析，不依赖猜测，不产生幻觉。" Playbook 与技能标准化：从「祈祷不出错」到「系统性保证正确」 如果你只是把 Claude 指向数据库说「帮我分析一下用户流失」，它可能会自己发明分析方法，产生错误结论。Team OS 的解法是：由分析师或数据科学家提前把正确的分析方法写进 Playbook，存入仓库。当 Hannah 查询「用户在哪个环节流失」时，Claude 会先找到对应的 Playbook，按照已被人工审核过的方法论执行分析，而不是即兴发挥。 这是从「祈祷 Claude 不出错」到「系统性保证分析正确」的本质跳跃。 Playbook 的价值不只是防止幻觉，它还在把专家知识编码进系统——即便那个分析师离职了，正确的分析方法依然留在仓库里，不会随人走。同样的逻辑也应用在技能文件（Skills）上。团队所有人的客户通话总结都遵循同一个模板，哪怕十个不同的客户经理以各自的方式整理通话，最终所有总结都会以完全相同的格式输出。当你需要跨二十个客户做交叉分析时，数据已经结构化一致，Claude 可以高效处理，不需要你先花时间统一格式。 "哪怕 10 个不同的客户经理以不同方式整理了通话，所有总结都会以完全相同的格式输出——这就是技能文件的杠杆所在。" Plan Mode 写策略文档：五阶段让文档质量提升十倍 Hannah 的策略文档写作流程是这期播客里最让人意外的部分。她不是「发一个 prompt 让 Claude 写文档」，而是把整个写作过程分成五个阶段执行：加载上下文（让 Claude 读取仓库里所有相关文件）、提问环节（Claude 主动向你提问，澄清所有模糊的地方）、构建计划（生成详细的写作计划文件，包含每个 agent 将使用什么 prompt、读哪些文件）、逼迫反思（让 Claude 从不同角度追问你，帮你发现论证里的漏洞）、最后由主 agent 汇编各子 agent 的输出。 长文档必须拆分给多个并行 agent 分别写，每个 agent 只写一节，输出到临时文件，最后由主 agent 合并——否则单个 agent 的上下文会溢出，辛苦生成的内容全部丢失。 Hannah 还强调：计划文件本身也要存入仓库。你两个月后可能需要写类似的文档，不需要从零开始设计流程；或者你的队友要做类似的事，可以直接参考你的计划。Claude 内置的计划文件会在 24 到 72 小时内被清除，所以把重要的计划手动存进仓库是必要的习惯。 "如果你要让一个员工花费大量时间和 token 做一件事，你至少应该先知道这个员工打算怎么做——就像你不会在不知道下属计划的情况下让他放手去干。" 1500 小时的学习飞轮：先自动化一件事，腾出时间继续学 Hannah 分享了让整个系统持续进化的底层方法：飞轮。 不是先学会所有技能再开始用，而是先自动化一件让你烦的事，释放出时间，用这个时间去学新东西。 她建议：如果你只有两小时，不要去搭一个完整的 Team OS，而是问自己「我能自动化什么，给自己下周腾出六小时的学习时间」。找到那一件事，做掉，然后用腾出来的时间继续学。Aakash 补充了他自己的学习提示词：先让 Claude 爬取 Anthropic 最近 90 天发布的所有功能，再读取 Claude Code 头部用户最近的热帖，然后和自己当前的工作流对比，输出一份「如何把我的工作流提升 10 倍」的报告。这个提示词有效是因为模型的训练数据截止于 2024 年，它甚至不总是了解自己的最新功能，需要主动给它喂进来。关于工具选择，Hannah 的答案很简单：需要高上下文、复杂推理的任务，用某种 coding agent；只是快速问一个问题、不需要太多上下文，用 Chat。但她认为绝大多数 PM 的工作——写文档、做分析、做原型、整理客户反馈——都应该在 coding agent 里完成。最后，她说了一句最反直觉的话：Claude Code 是迄今为止最适合做「知识工作」的工具，不是因为它擅长写代码，而是因为它能在正确的上下文里做任何事。她写的那篇文章叫《Claude Code for Everything》，正是这个意思。 "你们都在下载别人的技能和命令，但不知道为什么它们能用——我建议先让 Claude 解释这个东西的逻辑，理解它，然后你才能在它不按预期工作时知道如何迭代。" 内容来源："How this PM Used Claude Code to Support 20 People"丨Product Growth Podcast（嘉宾：Hannah Stulberg） 原视频：https://www.youtube.com/watch?v=0UArKLQ6bXA 如果你喜欢深度好文，可以用「晚点再听 LaterCast 小程序」，将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣