用好 Claude：控制上下文与任务交接

把 Claude 接进研发流程，难点不只是提示词写得好不好。作者的主张是：控制上下文、拆清任务、按需开放工具，再用测试和业务指标验收，才能让 Agent 持续做对事。

原文先列出 8 个使用习惯，再用「每位活跃用户每周内容产出从 200 提升到 206」串起完整流程。它最有价值的部分是任务交接和验证机制。不过，文章没有给出最终增长结果，不能把这套流程当成已经证明有效的增长案例。

上下文要管理，但别把 40% 当成红线

作者把长对话中的能力下降称为「dumb zone」。上下文窗口（context window）可以理解为 Claude 当前工作的资料桌：消息、回复、文件、搜索结果都占地方，堆得越满，越容易漏掉关键条件。

原文引用 HumanLayer 的 Dex Horthy 在《No Vibes Allowed》中的经验判断，把约 40% 的窗口占用作为提醒点；同时引用 Chroma 的研究，称测试的 18 个模型都随输入增长出现表现下降。

这里要分开看。输入变长会影响效果，是文章引用的研究结论；40% 则是经验阈值。原文没有提供足够的实验条件，不能据此推导所有 Claude 任务都该在同一个位置重开。

真正可执行的是三件事：换任务就换会话，只给当前任务必需的文件，在阶段完成后主动整理交接材料。

连接器也属于上下文成本。作者指出，Claude Code 已经能按需加载工具详情，启动时主要加载简短名称，但连接越多，仍会增加占用和选错工具的机会。可以用 /context 查看空间分配，再决定保留哪些连接。

输出同样会占空间。作者建议用 ASD-STE100 Simplified Technical English 约束表达，强调短句、主动语态、一句一事；但这套标准主要改善清晰度，不能保证回答更短。Claude app 可选「Concise」，Claude Code 则通过 /output-style 选择「Concise」。降低 effort 设置并不等于缩短回复，长度要求应直接写明，也可以放进 CLAUDE.md。

比等窗口快满更有用的，是在得到满意结果后主动压缩。原文给出的命令是：

/compact Keep the final approach, the decisions we made, and the test results. Drop the failed attempts and error logs.

关键在 Keep 后保留什么：最终方案、决策、测试结果，才是下一阶段需要的资产。不过，仍未解决的错误和已经确认的限制，也应明确留下，不能因为删掉日志就当作问题消失。

多 Agent 的收益，来自任务可以独立完成

作者要求任务交代清楚五项内容：Goal、How、Watch out for、How to check、Tools，也就是目标、步骤、限制、验收方式和可用工具。最容易被遗漏的是验收：只要求「实现功能」，模型很难判断做到什么程度才算完成。

示例先固定一个目标：每位活跃用户每周产出从 200 增加到 206，提升 3%。接着让四个 Agent 分别收集互不依赖的材料：

• 用户说了什么：NPS、工单、邮件，以及 Granola 或 Dovetail 中的访谈。
• 用户做了什么：Hotjar 中的会话录像。
• 产品如何被使用：数仓里的内容类型和来源，按国家、州、语言、组织拆分。
• 外部有什么信号：竞品、公开反馈和需求，通过 Tavily、Reddit、Google、X 调研。

每个 Agent 把结果写进自己的工作文件。录像单独分配，是因为作者认为屏幕内容比文本消耗更多上下文。最后由 program manager agent 只读摘要，汇总成带图表和来源的报告，并解释每个方案可能贡献多少新增内容。

并行的前提是任务之间不用互相等待。

作者用 1967 年提出的 Amdahl's law 解释这一点：能并行的调研可以提速，最后的汇总仍必须等待材料完成。增加 Agent 数量，并不能消除依赖关系。

原文还提醒，agent teams 当时属于 Claude Code 的实验功能，每个队友都是完整会话，会更快消耗使用额度，也不应让两个 Agent 同时编辑同一个文件。其收益不能只看等待时间，还要考虑额度、协调和汇总成本。

作者将协调 Agent 的指令放在 .claude/agents 下的 Markdown 文件中，要求每项主张都能追溯到工单、访谈、录像或查询。这个要求很实用：摘要让人读得快，来源让人查得回去。

从调研到上线，每次交接都要换成可验收的材料

作者接下来把报告交给 Claude Design，并通过 Storybook MCP server 读取真实组件；没有这条连接，也可以用 Markdown 描述设计系统。设计以 artifact 分享，收集同事评论后再修改。

这一步对前端团队的价值很直接：按钮、颜色和布局有现成依据，生成方案更容易接近实际工程约束。

随后启动新的工程会话，只带最终报告和已批准设计，再通过 CLAUDE.md 提供团队规范，包括测试方式、无状态组件、共享数据 store、hooks 或 composables，以及新 API 的实现模式。调查过程中的大量材料不必继续跟着代码任务走。

工具权限则随职责开放。BigQuery、Metabase 用于数据，CI/CD 用于开发环境部署，Sentry、Grafana 用于观测。作者建议默认使用只读账号，并在连接器中分别设置「Always allow」「Needs approval」「Blocked」。需要修改数据时，再开放对应动作。

工程 Agent 完成代码后，要运行主要用户路径的端到端测试（E2E），由人到 dev 环境检查体验，生产发布前还要有人审阅。上线后，定时任务（routine）收集错误和慢点，再交回工程 Agent 处理。

作者区分了运行在 Anthropic 服务器上的 Cloud routines 和依赖本机文件的 Local routines，并特别指出 Cloud routines 运行时不会临时请求批准，所以连接器应保持只读。这也限制了自动闭环的边界：自动收集问题，不等于可以无限制自动修改生产系统。

最后，复用四个调研 Agent 拉取新数据，对照 A/B 分组检查是否接近 206，并判断差异是否足够可信，结果可以放进 artifact 或 Metabase 看板。

功能测试通过，只能证明功能可用，不能证明 3% 的业务目标已经实现。

执行中，原文还给出 /btw 处理旁支问题、普通消息纠偏，以及连按两次 Esc 回到检查点的操作。按作者说明，检查点能撤销 Claude 的文件编辑，却不能完整撤销终端命令或删除等副作用，不能当成整个运行环境的回滚。

我的判断

我认同这套流程里三个安排：开工前写验收标准，交接时提供精简且可追溯的材料，发布后继续核对业务目标。它们能约束「看起来完成了」的错觉，也适用于普通团队。

但原文的完整方案有明显前提：团队已经有访谈、录像、数仓、设计系统、CI/CD 和观测工具，而且这些数据可访问、口径一致。一般团队可能先卡在数据缺失、账号权限和工具连接上。自然语言能降低操作门槛，不能替代权限配置和数据治理。

与单 Agent 顺序执行相比，多 Agent 更适合材料来源独立、可以分别交付的调查任务。若只是修改一个共享组件，协调成本可能超过收益。原文没有给出两种做法在耗时、费用和质量上的对照，因此这里仍是经验之谈。

增长部分也缺证据。文章没有报告最终是否达到 206，没有给出样本量、实验时长或统计方法。让 Claude 判断结果是否可信可以辅助分析，但前提仍是指标和实验设计足够清楚。

能拿来做什么

• 给下一次 AI 编程任务补上验收方式。除了描述页面或接口，还写清关键用户路径、错误状态和可运行的检查，让 Claude 有依据判断任务是否结束。
• 在调研、设计、编码之间做一次交接。保留最终决策、来源、相关文件、测试结果和未解决问题，再开新会话继续，减少反复探索造成的干扰。
• 只在任务可独立交付时拆 Agent。例如分别调查工单、数据和竞品，再统一汇总；涉及同一文件的修改，应明确由一个 Agent 负责。
• 把开发验收和效果验收分开。前者检查代码、E2E 和实际体验，后者回到预先约定的业务指标；接入数据工具时先用只读权限，让自动化先承担收集和报告工作。