> 来源：Useful AI Lab（实用 AI / Useful AI）— https://usefulai.cloud/insights/claude-code-beyond-basics/
> 作者：CarryChang · 最近更新：2026-07-30 · 语言：zh-CN

[实用 AI 指南](https://usefulai.cloud/) › [深度阅读](https://usefulai.cloud/insights/)

Claude
Daisy Holman
Claude Code
Team Workflow

# Claude Code：基础用法之外，Agent 要进团队工作流

Daisy Holman 是 Claude Code 团队工程师，早期参与 Claude Code、plugins 和 agent teams 相关工作。她这次没有讲"怎么让 Claude Code 写一个小功能"，而是把问题放到更硬的现场：几百、几千甚至上万名工程师共用一个代码库时，Agent 怎样才能进入真实工程系统。这篇里我认为「上下文窗口是预算」的比喻是全场最实用的一个框架，它把一堆零散的工具选型问题，收进了同一套记账逻辑。

### 从编程任务到工程任务

Daisy 开场把边界划清：Claude Code 对简单编程任务已经够顺手，零到一项目都能推进。但团队里的软件工程很快会遇到另一套现实——**代码有债务，功能有上下游，改动要满足产品、合规、运维、客户等一串外部约束**。

> Claude Code 对很简单的编程任务开箱可用；但复杂度上来、靠近软件工程任务时，你需要给它一些旋钮和定制。 — — Daisy Holman

**我的看法：**这个边界划得很准。行业里常见的说法是「Claude Code 能不能干工程活」，这其实是个假问题——它一直都能，只是「开箱可用」和「靠旋钮撑起来」是两种完全不同的成本结构，前者几乎零配置，后者需要专门投入设计上下文、权限和验证。Daisy 后面讲的全部内容，本质都是在给这句话填细节。

### 把 Agent 当同事，接触同事的信息

工程判断很少只藏在源码里：API 为什么不能改可能写在设计文档，边界为什么保留可能来自 Slack 线程，事故处理方式可能在 runbook 和会议纪要里。

> 专业软件工程里的大部分工作并不在实际源码里。我们写设计文档，写邮件，也在 Slack 上讨论。 — — Daisy Holman

Daisy 的建议朴素但可执行：**把 Agent 当同事，就要让它接触同事能接触的信息**。试着用 Claude Code 完成一整天工作，每一次不得不切到别的工具复制信息，都说明 Agent 缺了一块工作现场。

她甚至建议会议刚结束就把纪要喂给 Claude，一场会议后能拿到两三个 PR。这个建议我认同方向，但要提一个现实的顾虑：会议纪要里往往混着敏感信息（薪资讨论、人事变动、未公开的商业决定），把这些无差别喂给 Agent，等于扩大了敏感信息的暴露面。Daisy 没有在演讲里提到访问控制或信息分级，这是我认为「把 Agent 当同事」这个类比里被回避的部分——同事之间也不是无条件互相看所有信息的。

### 上下文窗口：MCP、Skill、Hooks 的 token 账——这是全篇最扎实的部分

定制问题拉回一个基础约束：**上下文窗口的上限并没有以模型能力同样的速度扩张**。她比喻为"在 Arduino 上跑 NPM"——空间小但信息多，工程问题变成包装与加载：哪些常驻、哪些按需读取、哪些压缩成最小版本。

> 你不能把整个代码库、整个 wiki、所有内部文档都塞进上下文窗口。你需要在正确时间放入正确信息。 — — Daisy Holman

**MCP 适合向外集成，内部流程先看 CLI + skill**。Claude Code 本身有 shell，把内部部署脚本重新封成 MCP server 维护成本很快上来；MCP 工具的名字、描述、schema 都要进入系统提示词——20 个 server × 15 个 tool，窗口很快就被工具定义塞满。

Skill 虽轻，但 description 永远会被加载，触发规则写 300-400 tokens 才可靠时，十万份叠起来就不再轻。Daisy 明显更看重 **hooks**：在 Agent 循环外触发本机程序做类型检查、lint、诊断。

> 它在上下文窗口外运行，所以没有 token 成本。你不为没有用到的东西付费。 — — Daisy Holman

取舍原则：**把稀缺资源从 context window 移到更宽裕的本机计算上**。而**耐用的信息靠前，临时内容靠后**——位置本身就是内存布局。这条我完全认同，而且我认为它比「MCP vs Skill 怎么选」的具体建议更有长期价值：具体建议会随模型窗口变大而过时，但「稀缺资源要精打细算地分配」这条原则不会过时，窗口再大，总有更贵的东西想往里塞。

**图解 18**：
上下文窗口是一份预算：MCP、Skill、Hooks 都在从同一个池子里扣
（适合：工程师向）

模型能力涨得比上下文窗口快，所以窗口是**真正的稀缺资源**——Daisy 的比喻是「在 Arduino 上跑 NPM」。这张图想说清一件事：**MCP 工具定义、Skill、Hooks 输出、代码文件、对话历史都在从同一个池子里扣**，扣完剩下的才是留给推理的余量。所以工程问题变成了包装与加载：哪些常驻、哪些按需读、哪些压成最小版本；**耐用的信息靠前，临时的靠后**，位置本身就是内存布局。

### 异步与并行：Agent 可以过夜工作——这里我想提一句风险

团队另两个主题是**异步与并行**：异步意味着走开让 Agent 继续，并行意味着同时让多个 Agent 推进不同分支。工程师从八小时 flow state 变成更像调度中心的一天。

> 如果你想做高质量、高效率的工程，你的工作日很可能不会再长成过去那样。 — — Daisy Holman

基础做法是 **worktrees**：为不同 Agent 保留长期工作树，避免重复初始化；每个 Agent 维持自己的身份、分支和上下文，再通过消息工具互相传递。

托起异步与并行的是权限与监控：Auto Mode 背后有 classifier agent 与对抗式检查工具调用的另一个 agent。

> 这基本上就是不再有权限提示。它让 loop 可用，让 agent teams 可用，也让过夜工作可用。 — — Daisy Holman

Cloud agents 开发者过去一个月推进了大约一千个 PR——**软件工程的杠杆，正在变成"能否安全地让一群 Agent 持续推进"**。

一千个 PR 这个数字听起来惊人，但我想问一句没被问到的问题：这一千个 PR 里有多少被合并、多少被 review 打回、多少是重复劳动？「能否安全地让 Agent 持续推进」这句话把安全的判断标准放在了「能不能过夜跑」，我认为更该放在「过夜跑完之后，需要几个人花几小时清理」。产出数量和产出质量在这类叙事里经常被悄悄画上等号，而这正是这篇演讲和第三篇 Boris/Cat 访谈共同的盲区。

#### Daisy 说了什么

- 编程任务开箱可用，工程任务需要旋钮和定制

- 把 Agent 当同事，让它接触同事能接触的信息

- 上下文窗口是硬边界，需要设计"内存布局"

- 异步 + 并行，Agent 可以过夜推进上千个 PR

#### 原视频

观看 Daisy Holman 讲解如何让 Claude Code 进入团队级工程系统。

[▶ 观看演讲](https://www.youtube.com/watch?v=tuY2ChJIx48)

#### 我的评论

- 「上下文窗口是预算」是全场最耐用的框架，比具体工具选型更长寿

- 把会议纪要无差别喂给 Agent，回避了信息分级和访问控制问题

- 一千个 PR 的产出数字，没说清楚有多少最终真正被合并

## 继续阅读

[如何从零构建你自己的大语言模型：GPT 和 Claude 背后的 5 阶段流水线 → 所有前沿模型都由同样的五个阶段构建：数据 → 预训练 → 监督微调 → 奖励建模 → 强化学习。学会这套骨架，你就不会再把模型当作魔法。](https://usefulai.cloud/insights/how-llms-are-built/)
[Anthropic 工程师：我们日常如何使用 Claude Code → 用一个真实 repo 演示 Anthropic 工程师怎样配置 Claude Code、让它问问题、生成 HTML 规格稿，再把验证流程做进 React 组件和浏览器。](https://usefulai.cloud/insights/anthropic-how-we-use-claude-code/)
[深度阅读 → 6 篇 AI 长文的完整中文解读：Claude Code、Skill、Agent、大模型原理。](https://usefulai.cloud/insights/)