从编程任务到工程任务

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 都在从同一个池子里扣 工程师向
上下文窗口的预算分配示意：工具定义、Skill、Hooks 输出、代码文件、对话历史与留给推理的余量 上下文窗口是一份共享预算，MCP 工具定义、Skill、Hooks 输出、代码与文件、对话历史都在从同一个池子里扣，剩下的才是留给推理的余量。原则是耐用的信息靠前、临时内容靠后，并把能移走的负担交给本机计算，而不是占用窗口。 一次请求的上下文预算（示意比例） 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 访谈共同的盲区。