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

Claude Code：基础用法之外，Agent要进团队工作流丨Claude Claude Code：基础用法之外，Agent要进团队工作流丨Claude Modified June 11 🔗 原文链接： https://mp.weixin.qq.com/s/zCX5fX2h... 原创 Capihom Capihom 晚点再听LaterCast2026年6月10日 21:01 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "我更想谈智能体软件工程，而非智能体编程。" "全规模软件工程需要大量信息。" "给它访问权限，注意上下文窗口，选择能规模化的抽象。" 这期视频来自 Claude 官方频道，主讲人 Daisy Holman 是 Claude Code 团队工程师。她早期参与 Claude Code，也参与过 plugins 和 agent teams 相关工作；在加入这条产品线之前，她的背景是编程语言，还曾担任 C++ 委员会主席。她这次没有讲“怎么让 Claude Code 写一个小功能”，而是把问题放到更硬的现场：几百、几千甚至上万名工程师共用一个代码库时，Agent 怎样才能进入真实工程系统。官方简介把主题写得很直白：CLAUDE.md 如何做好、MCP 怎样接入、团队知识怎样包装成 skills、auto mode 如何安全使用。已经把 Claude Code 放进日常开发的人，这期更像第二阶段操作手册。 基础用法之外，工程任务要加旋钮 Daisy 开场就把边界划清：Claude Code 对简单编程任务已经够顺手，打开仓库、让它改代码、跑命令，很多零到一项目都能推进。但团队里的软件工程很快会遇到另一套现实，代码有债务，功能有上游下游，改动要满足产品、合规、运维、客户等一串外部约束。 当任务从“写代码”升级为“交付工程结果”，Agent 需要被接进团队自己的信息和工具。 "Claude Code 对很简单的编程任务开箱可用；但复杂度上来、靠近软件工程任务时，你需要给它一些旋钮和定制。" 她用“agentic software engineering”来区分这件事。编程任务看的是局部代码能否改对，工程任务看的是 Agent 能否理解团队为什么这样做、哪些约定不能破、哪些失败要自己修。Claude Code 的下一步，不在多背几个提示词，而在让 Agent 拥有类似工程同事的工作环境。比如同一个改动，写完代码只是第一步；它还要看 CI、读失败日志、知道回滚规程，必要时从内部文档里找产品约束。没有这些“旋钮”，Agent 很容易在小任务里惊艳，在大系统里迷路。 Agent 做不好，常因它看不见为什么 在大型公司里，工程判断很少只藏在源码里。一个 API 为什么不能改，可能写在设计文档；某个边界为什么要保留，可能来自 Slack 线程；一次线上事故的处理方式，可能留在 runbook、看板和会议纪要里。Daisy 的建议很朴素：把 Agent 当成同事，就要让它接触同事能接触的信息。 "专业软件工程里的大部分工作并不在实际源码里。我们写设计文档，写邮件，也在 Slack 上讨论。" 她还给了一个很可执行的检查法：试着用 Claude Code 终端或桌面端完成一整天工作，每一次你不得不切到别的工具、复制信息再贴回来，都说明 Agent 缺了一块工作现场。 很多“Claude 走错路”的时刻，根源常在信息落差：你脑子里那段上下文没有给它。 她甚至建议会议刚结束就把纪要喂给 Claude，问有没有可以顺手处理的低垂果实；在她的经验里，一场会议后能拿到两三个 PR。这里的重点很具体：让 Agent 看见决策来路，它才更可能选中团队愿意接受的路径。 她点名了几类应该接入的工作面：团队聊天、CI/CD、dashboard、内部文档、设计文档、runbook。线上故障发生时，Agent 如果能同时拉日志、看指标、读事故手册，就能更快把信息拼成处理路径。把这些入口补齐，比反复改 prompt 更接近团队级生产力。 上下文窗口，是团队级使用的硬边界 Daisy 把 Claude Code 的定制问题拉回一个基础约束：上下文窗口。她提到，前沿模型这一年能力变强很多，但上下文窗口的上限并没有以同样速度扩张。团队想让 Agent 更懂业务，只能通过上下文学习、工具、技能和文档，把相关信息放进窗口里。 "你不能把整个代码库、整个 wiki、所有内部文档都塞进上下文窗口。你需要找到更好的办法，在正确时间放入正确信息。" 她用了一个很有画面感的比喻：这有点像在 Arduino 上跑 NPM。空间很小，要放的信息很多，所以工程问题变成了包装和加载问题。哪些内容必须常驻，哪些内容可以按需读取，哪些内容要被压缩成最小版本，决定了 Agent 能不能留出空间继续推理和修改。Daisy 还把 in context learning 开玩笑地称作“听起来很聪明，其实就是文本文件”。玩笑背后是硬约束：团队无法把公司内部知识训练进模型权重，只能设计更好的上下文供给方式。 她还提到上下文里的位置也有讲究。耐用、长期有效的信息可以靠前；容易被淘汰、临时性的内容放得更靠后，清出去时损失更小。工程团队做 CLAUDE.md、skill 和工具描述时，其实是在替 Agent 设计“内存布局”。 MCP 适合公开集成，内部流程先看 CLI 谈到 MCP，Daisy 没有把它当成万能答案。她的判断更细：如果一家公司要向公众发布 Claude 集成，MCP 往往是好的起点，因为它处理传输、认证和工具暴露，也适合没有 shell、不能跑本地 CLI 的聊天机器人环境。但 Claude Code 本身有 shell，可以跑命令，内部开发者工作流就要重新权衡。 "如果你已经有一个 CLI，除非要交付给非技术客户，否则把它包进 MCP 往往没有太大意义。通常写一个 skill 告诉 Claude 怎么用 CLI，会容易得多。" 这点对工程团队尤其现实。公司里已经有部署脚本、诊断命令、日志查询、CI 工具、内部平台 CLI。把每一套都重新封成 MCP server，维护成本会很快上来。用 skill 写清楚命令何时运行、参数怎么传、失败后看哪里，反而更贴近开发者每天的路径。她还提醒了一个容易被忽视的成本：MCP 工具的名字、描述和 schema 都要进入系统提示词。20 个 server、每个 15 个 tool，窗口里很快塞满工具定义，留给真实工作的空间被挤掉。Claude 团队正在做 tool search，只把名字放进去，需要时再查细节。 这并不削弱 MCP 的位置。Slack、邮件、外部服务和面向客户的公开集成，仍然适合用 MCP 打开通道。Daisy 的分界线在“谁来用”：给公众和非技术用户，MCP 更稳；给内部工程师和已有命令体系，skill 加 CLI 往往跑得更快。 Skill 很轻，但十万份会变重 Skill 的魅力在于轻。Daisy 把它形容成“懒加载的系统提示词”：前置描述放进系统提示词，Claude 需要时再读取完整的 SKILL.md、脚本和资源。一个团队要把发布流程、代码规范、调试套路沉淀下来，用文件夹就能开始。 "从根上说，一个 skill 只是一个文件夹，里面有一个 markdown 文件，并且带着某种摘要。" 轻也带来治理压力。她提醒，已经有公司在 monorepo 里拥有数万甚至数十万个 skills，开始撞上规模边界。skill 正文按需付费，但 description 永远会被加载；如果触发规则要写 300 到 400 tokens 才可靠，十万份叠起来就不再轻。 团队沉淀知识时，也要管理知识的入口成本。 这也解释了为什么 CLAUDE.md 不能被无限滥用。一个插件如果能无条件塞一段说明进上下文，每个插件都会想塞一点，最后用户每次启动都在为“看起来很便宜”的文本付费。 她还说 skills 暂时没有清晰的层级机制，无法天然地把子 skill 懒加载出来。规模小时，文件夹越多越像知识库；规模大后，触发描述、命名规范、淘汰机制、评估流程都会变成工程管理问题。Agent 时代的知识库，不能只追求“多”。 Hooks 把成本挪出上下文窗口 在几种抽象里，Daisy 明显更看重 hooks 的可扩展性。hook 的机制很直接：Agent 循环里发生某个事件，触发本机程序运行；程序判断是否要把结果塞回上下文。它可以是类型检查、lint、诊断脚本，也可以是更细的规则匹配。 "它在上下文窗口外运行，所以没有 token 成本。你不为没有用到的东西付费。" 她举了 JavaScript 和 Rust 的对比：如果你写 Rust，JavaScript skill 的描述仍然可能占一点系统提示词；但一个检查 JavaScript 的 hook 可以运行后发现目标文件不匹配，然后什么也不返回。被节省下来的不只是钱，更是宝贵的上下文空间。大型工程里，零开销抽象会变成生产力基础设施。Daisy 也承认 hook 不是银弹，它常常要靠解析命令、匹配文件名或正则判断，遇到复杂语义时可能要请 subagent 帮忙，成本又会上来。她给出的取舍原则是：把稀缺资源从 context window 移到更宽裕的本机计算上。 并行工作后，工程师要学会切换 视频后半段，Daisy 讲 Claude Code 团队自己怎样使用 Claude Code。她归纳出两个主题：异步和并行。异步意味着你可以走开，让 Agent 继续工作；并行意味着你同时让多个 Agent 推进不同分支。工程师曾经追求八小时 flow state，现在要面对更像调度中心的一天。 "如果你想做高质量、高效率的工程，你的工作日很可能不会再长成过去那样。" 她提到的基础做法是 worktrees：为不同 Agent 保留长期存在的工作树，避免每次重新初始化依赖、符号链接和环境。每个 Agent 维持自己的身份、自己的分支和上下文，再通过消息工具把信息传给另一个 Agent。 工程师的产出方式开始从亲手连续编码，转向管理多个可恢复的工作现场。 Claude 之间互相发消息也在这个框架里变得自然：一个 Agent 正在研究模块 A，另一个要改模块 B，中间的知识不该只停留在人的脑子里。经过许可后，Agent 之间也要能共享一段解释、一条结论或一个待验证假设。 自动模式让 Agent 可以过夜工作 把异步和并行托起来的，是权限和监控。Daisy 提到 slash loop 会按固定间隔运行提示，CI 跑两小时也可以让 Agent 后续继续看失败、修问题。她同时强调，自己不推荐危险地跳过权限；Claude Code 的 auto mode 背后有 classifier agent，还有另一个 agent 对工具调用做对抗式检查。 "这基本上就是不再有权限提示。它让 loop 可用，让 agent teams 可用，也让过夜工作可用。" 她还展示了 Cloud agents 和 remote control：一个视图里能看到所有运行中的 Agent，哪些在工作，哪些被卡住；可以跳进 session、偷看进度、发新提示。remote control 能在手机和桌面端做 30 秒检查，晚饭后确认 Agent 没卡在“蠢问题”上。软件工程的杠杆，正在变成“能否安全地让一群 Agent 持续推进”。她顺带提到，auto mode 会多消耗 token，可能在 30% 到 40% 量级，但她也提醒现场不要引用成精确数字。Claude 团队正在把成本压下来；在那之前，团队要用安全性和吞吐量去衡量这笔账。 她还补了一句很能说明产品方向的细节：做出 Cloud agents 的工程师，过去一个月用它自己推进了大约一千个 PR。这个数字不该被当成普遍承诺，但能看出 Claude 团队正在用 Claude Code 改造 Claude Code。Agent 不再只是编辑器旁边的助手，它开始有自己的队列、状态、远程入口和协作界面。 写在最后 Daisy 最后的三句话很适合作为团队清单：给它访问权限，注意上下文窗口，选择能规模化的抽象。Claude Code 的基础用法已经足够让人惊讶，下一段差距会出现在工程系统里。先从一条 CLI、一个 skill、一次 CI 修复开始，把 Agent 放进真实工作流，团队才会知道哪些地方可以交给它。 内容来源："Beyond the basics with Claude Code"丨Claude 原视频：https://www.youtube.com/watch?v=tuY2ChJIx48 No access 4279c7c83d454a7ab7be77cbe1a06ecb 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/zCX5fX2h... 🔗 原文链接： https://mp.weixin.qq.com/s/zCX5fX2h... https://mp.weixin.qq.com/s/zCX5fX2h... 原创 Capihom Capihom 晚点再听LaterCast2026年6月10日 21:01 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "我更想谈智能体软件工程，而非智能体编程。" "全规模软件工程需要大量信息。" "给它访问权限，注意上下文窗口，选择能规模化的抽象。" 这期视频来自 Claude 官方频道，主讲人 Daisy Holman 是 Claude Code 团队工程师。她早期参与 Claude Code，也参与过 plugins 和 agent teams 相关工作；在加入这条产品线之前，她的背景是编程语言，还曾担任 C++ 委员会主席。她这次没有讲“怎么让 Claude Code 写一个小功能”，而是把问题放到更硬的现场：几百、几千甚至上万名工程师共用一个代码库时，Agent 怎样才能进入真实工程系统。官方简介把主题写得很直白：CLAUDE.md 如何做好、MCP 怎样接入、团队知识怎样包装成 skills、auto mode 如何安全使用。已经把 Claude Code 放进日常开发的人，这期更像第二阶段操作手册。 基础用法之外，工程任务要加旋钮 Daisy 开场就把边界划清：Claude Code 对简单编程任务已经够顺手，打开仓库、让它改代码、跑命令，很多零到一项目都能推进。但团队里的软件工程很快会遇到另一套现实，代码有债务，功能有上游下游，改动要满足产品、合规、运维、客户等一串外部约束。 当任务从“写代码”升级为“交付工程结果”，Agent 需要被接进团队自己的信息和工具。 "Claude Code 对很简单的编程任务开箱可用；但复杂度上来、靠近软件工程任务时，你需要给它一些旋钮和定制。" 她用“agentic software engineering”来区分这件事。编程任务看的是局部代码能否改对，工程任务看的是 Agent 能否理解团队为什么这样做、哪些约定不能破、哪些失败要自己修。Claude Code 的下一步，不在多背几个提示词，而在让 Agent 拥有类似工程同事的工作环境。比如同一个改动，写完代码只是第一步；它还要看 CI、读失败日志、知道回滚规程，必要时从内部文档里找产品约束。没有这些“旋钮”，Agent 很容易在小任务里惊艳，在大系统里迷路。 Agent 做不好，常因它看不见为什么 在大型公司里，工程判断很少只藏在源码里。一个 API 为什么不能改，可能写在设计文档；某个边界为什么要保留，可能来自 Slack 线程；一次线上事故的处理方式，可能留在 runbook、看板和会议纪要里。Daisy 的建议很朴素：把 Agent 当成同事，就要让它接触同事能接触的信息。 "专业软件工程里的大部分工作并不在实际源码里。我们写设计文档，写邮件，也在 Slack 上讨论。" 她还给了一个很可执行的检查法：试着用 Claude Code 终端或桌面端完成一整天工作，每一次你不得不切到别的工具、复制信息再贴回来，都说明 Agent 缺了一块工作现场。 很多“Claude 走错路”的时刻，根源常在信息落差：你脑子里那段上下文没有给它。 她甚至建议会议刚结束就把纪要喂给 Claude，问有没有可以顺手处理的低垂果实；在她的经验里，一场会议后能拿到两三个 PR。这里的重点很具体：让 Agent 看见决策来路，它才更可能选中团队愿意接受的路径。 她点名了几类应该接入的工作面：团队聊天、CI/CD、dashboard、内部文档、设计文档、runbook。线上故障发生时，Agent 如果能同时拉日志、看指标、读事故手册，就能更快把信息拼成处理路径。把这些入口补齐，比反复改 prompt 更接近团队级生产力。 上下文窗口，是团队级使用的硬边界 Daisy 把 Claude Code 的定制问题拉回一个基础约束：上下文窗口。她提到，前沿模型这一年能力变强很多，但上下文窗口的上限并没有以同样速度扩张。团队想让 Agent 更懂业务，只能通过上下文学习、工具、技能和文档，把相关信息放进窗口里。 "你不能把整个代码库、整个 wiki、所有内部文档都塞进上下文窗口。你需要找到更好的办法，在正确时间放入正确信息。" 她用了一个很有画面感的比喻：这有点像在 Arduino 上跑 NPM。空间很小，要放的信息很多，所以工程问题变成了包装和加载问题。哪些内容必须常驻，哪些内容可以按需读取，哪些内容要被压缩成最小版本，决定了 Agent 能不能留出空间继续推理和修改。Daisy 还把 in context learning 开玩笑地称作“听起来很聪明，其实就是文本文件”。玩笑背后是硬约束：团队无法把公司内部知识训练进模型权重，只能设计更好的上下文供给方式。 她还提到上下文里的位置也有讲究。耐用、长期有效的信息可以靠前；容易被淘汰、临时性的内容放得更靠后，清出去时损失更小。工程团队做 CLAUDE.md、skill 和工具描述时，其实是在替 Agent 设计“内存布局”。 MCP 适合公开集成，内部流程先看 CLI 谈到 MCP，Daisy 没有把它当成万能答案。她的判断更细：如果一家公司要向公众发布 Claude 集成，MCP 往往是好的起点，因为它处理传输、认证和工具暴露，也适合没有 shell、不能跑本地 CLI 的聊天机器人环境。但 Claude Code 本身有 shell，可以跑命令，内部开发者工作流就要重新权衡。 "如果你已经有一个 CLI，除非要交付给非技术客户，否则把它包进 MCP 往往没有太大意义。通常写一个 skill 告诉 Claude 怎么用 CLI，会容易得多。" 这点对工程团队尤其现实。公司里已经有部署脚本、诊断命令、日志查询、CI 工具、内部平台 CLI。把每一套都重新封成 MCP server，维护成本会很快上来。用 skill 写清楚命令何时运行、参数怎么传、失败后看哪里，反而更贴近开发者每天的路径。她还提醒了一个容易被忽视的成本：MCP 工具的名字、描述和 schema 都要进入系统提示词。20 个 server、每个 15 个 tool，窗口里很快塞满工具定义，留给真实工作的空间被挤掉。Claude 团队正在做 tool search，只把名字放进去，需要时再查细节。 这并不削弱 MCP 的位置。Slack、邮件、外部服务和面向客户的公开集成，仍然适合用 MCP 打开通道。Daisy 的分界线在“谁来用”：给公众和非技术用户，MCP 更稳；给内部工程师和已有命令体系，skill 加 CLI 往往跑得更快。 Skill 很轻，但十万份会变重 Skill 的魅力在于轻。Daisy 把它形容成“懒加载的系统提示词”：前置描述放进系统提示词，Claude 需要时再读取完整的 SKILL.md、脚本和资源。一个团队要把发布流程、代码规范、调试套路沉淀下来，用文件夹就能开始。 "从根上说，一个 skill 只是一个文件夹，里面有一个 markdown 文件，并且带着某种摘要。" 轻也带来治理压力。她提醒，已经有公司在 monorepo 里拥有数万甚至数十万个 skills，开始撞上规模边界。skill 正文按需付费，但 description 永远会被加载；如果触发规则要写 300 到 400 tokens 才可靠，十万份叠起来就不再轻。 团队沉淀知识时，也要管理知识的入口成本。 这也解释了为什么 CLAUDE.md 不能被无限滥用。一个插件如果能无条件塞一段说明进上下文，每个插件都会想塞一点，最后用户每次启动都在为“看起来很便宜”的文本付费。 她还说 skills 暂时没有清晰的层级机制，无法天然地把子 skill 懒加载出来。规模小时，文件夹越多越像知识库；规模大后，触发描述、命名规范、淘汰机制、评估流程都会变成工程管理问题。Agent 时代的知识库，不能只追求“多”。 Hooks 把成本挪出上下文窗口 在几种抽象里，Daisy 明显更看重 hooks 的可扩展性。hook 的机制很直接：Agent 循环里发生某个事件，触发本机程序运行；程序判断是否要把结果塞回上下文。它可以是类型检查、lint、诊断脚本，也可以是更细的规则匹配。 "它在上下文窗口外运行，所以没有 token 成本。你不为没有用到的东西付费。" 她举了 JavaScript 和 Rust 的对比：如果你写 Rust，JavaScript skill 的描述仍然可能占一点系统提示词；但一个检查 JavaScript 的 hook 可以运行后发现目标文件不匹配，然后什么也不返回。被节省下来的不只是钱，更是宝贵的上下文空间。大型工程里，零开销抽象会变成生产力基础设施。Daisy 也承认 hook 不是银弹，它常常要靠解析命令、匹配文件名或正则判断，遇到复杂语义时可能要请 subagent 帮忙，成本又会上来。她给出的取舍原则是：把稀缺资源从 context window 移到更宽裕的本机计算上。 并行工作后，工程师要学会切换 视频后半段，Daisy 讲 Claude Code 团队自己怎样使用 Claude Code。她归纳出两个主题：异步和并行。异步意味着你可以走开，让 Agent 继续工作；并行意味着你同时让多个 Agent 推进不同分支。工程师曾经追求八小时 flow state，现在要面对更像调度中心的一天。 "如果你想做高质量、高效率的工程，你的工作日很可能不会再长成过去那样。" 她提到的基础做法是 worktrees：为不同 Agent 保留长期存在的工作树，避免每次重新初始化依赖、符号链接和环境。每个 Agent 维持自己的身份、自己的分支和上下文，再通过消息工具把信息传给另一个 Agent。 工程师的产出方式开始从亲手连续编码，转向管理多个可恢复的工作现场。 Claude 之间互相发消息也在这个框架里变得自然：一个 Agent 正在研究模块 A，另一个要改模块 B，中间的知识不该只停留在人的脑子里。经过许可后，Agent 之间也要能共享一段解释、一条结论或一个待验证假设。 自动模式让 Agent 可以过夜工作 把异步和并行托起来的，是权限和监控。Daisy 提到 slash loop 会按固定间隔运行提示，CI 跑两小时也可以让 Agent 后续继续看失败、修问题。她同时强调，自己不推荐危险地跳过权限；Claude Code 的 auto mode 背后有 classifier agent，还有另一个 agent 对工具调用做对抗式检查。 "这基本上就是不再有权限提示。它让 loop 可用，让 agent teams 可用，也让过夜工作可用。" 她还展示了 Cloud agents 和 remote control：一个视图里能看到所有运行中的 Agent，哪些在工作，哪些被卡住；可以跳进 session、偷看进度、发新提示。remote control 能在手机和桌面端做 30 秒检查，晚饭后确认 Agent 没卡在“蠢问题”上。软件工程的杠杆，正在变成“能否安全地让一群 Agent 持续推进”。她顺带提到，auto mode 会多消耗 token，可能在 30% 到 40% 量级，但她也提醒现场不要引用成精确数字。Claude 团队正在把成本压下来；在那之前，团队要用安全性和吞吐量去衡量这笔账。 她还补了一句很能说明产品方向的细节：做出 Cloud agents 的工程师，过去一个月用它自己推进了大约一千个 PR。这个数字不该被当成普遍承诺，但能看出 Claude 团队正在用 Claude Code 改造 Claude Code。Agent 不再只是编辑器旁边的助手，它开始有自己的队列、状态、远程入口和协作界面。 写在最后 Daisy 最后的三句话很适合作为团队清单：给它访问权限，注意上下文窗口，选择能规模化的抽象。Claude Code 的基础用法已经足够让人惊讶，下一段差距会出现在工程系统里。先从一条 CLI、一个 skill、一次 CI 修复开始，把 Agent 放进真实工作流，团队才会知道哪些地方可以交给它。 内容来源："Beyond the basics with Claude Code"丨Claude 原视频：https://www.youtube.com/watch?v=tuY2ChJIx48 No access 4279c7c83d454a7ab7be77cbe1a06ecb 00:00 No access 4279c7c83d454a7ab7be77cbe1a06ecb 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣