摘要：Anthropic 技术成员 Eugene Yan 把 AI 当成能持续协作的同事：管理上下文、编码偏好、让验证可执行、逐步委派任务，并把每一次纠正沉淀成可复用的配置。
本文编译自 Eugene Yan 于 2026 年 5 月 3 日发布的文章《How to Work and Compound with AI》。
Eugene Yan 目前是 Anthropic 的 Member of Technical Staff（技术成员），关注如何让安全、可靠的 AI 系统在真实场景中规模化落地；此前曾在 Amazon、Alibaba、Lazada 等公司带领 ML/AI 团队。本文整理的是他的个人工作方法，不代表 Anthropic 的官方观点或产品指南。
我们怎样才能高效地与 AI 协作？工作流应该是什么样，它如何扩展，我们又如何随着时间推移改进自己的系统？理想情况下，它应该能够产生复利：每一件完成的产出，包括代码、文档、分析和决策，都会成为下一次会话的上下文；每一次纠正都会更新某项配置，从而减少未来的错误。
我仍在学习，但这些问题已经被问到足够多次，所以我把答案写在这里。下次再有人问时，就可以直接分享这篇文章。
如果你经常使用 AI，很可能已经在采用其中的许多做法。不过，我相信其背后的原则有着广泛适用性：提供好的上下文，把自己的偏好编码成配置，让验证变得容易，委派更大的任务，并形成闭环。
如果某项做法不适合你，就调整这条原则，创造自己的做法。阅读时也请留意：这里没有任何一点是 AI 独有的。这不过是让任何一位新协作者入职、并与之共同工作的方式。
上下文是基础设施
帮助模型在你的上下文中导航。 例如，我的全部代码都放在 ~/src，全部知识型工作都放在 ~/vault，其中又分为 projects/、notes/、kb/ 等。工作内容组织有序时，模型就更容易用 grep 或 glob 检索上下文。
清晰的目录树也让模型更容易在目录中穿行，找到并利用既有代码、项目文档和分析资料，改进眼下正在完成的工作。
把模型接入组织的上下文。 模型可以利用组织知识，而这些知识通常散落在 Slack、Google Drive、邮件等地方。许多系统都为 Claude Code、Cowork 和 Claude.ai 提供了 MCP（模型上下文协议）接入。
除此之外，我还为每个项目维护一个 INDEX.md。它是相关文档和频道的带注释索引；每一条都包含 URL、负责人，以及一段简短说明，解释里面有什么、何时应当阅读。注释的帮助非常大。
如果只给一串 URL，模型就不得不逐个打开链接，才能判断哪些内容相关，白白耗费时间和上下文。预先写好注释，就能把这项费力的工作做一次，并把结果存进索引。
让每个新会话像新员工一样入职。 每次新会话开始时，模型都是一张白纸。因此，不妨把每个项目的 CLAUDE.md 当作第一天交给新同事的入职文档。
Claude 扫描过我各项目的 CLAUDE.md，并指出其中包含缩略语、项目代号，以及同名同事的词汇表。我还会在 CLAUDE.md 里给出建议的阅读顺序，例如先让模型略读 INDEX.md，再读 TODOS.md，最后再看特定主题的笔记。
建立你的记忆层。 默认情况下，模型不会记得上一次会话发生了什么，因此凡是值得保留的内容，都应该写入磁盘。我把记忆层分成两类：~/vault 存放项目状态、产物和领域知识等事实；~/.claude 连同其中的 CLAUDE.md、skills/、guides/，存放我的偏好、工作流和个人品味。
前者提供上下文，后者提供配置。
把品味写进配置
从 ~/.claude/CLAUDE.md 开始。 Claude 会在每次会话开始时读取它。我把它视为一份行为契约。我的 CLAUDE.md 包含诸如表达该有多直接、何时应当反驳、怎样处理错误、该教我什么等偏好。下面是一个精简版本：
<behavior>
- Be direct and push back when you disagree; if my approach has problems, say so.
- When unsure about something, say you're unsure rather than guessing confidently.
- When something fails, investigate the root cause before retrying.
- Keep diffs scoped to the task: no drive-by reformats or unrelated refactors.
...
</behavior>
<teaching>
I'm always picking up new systems and domains. When a key term surfaces that I
likely haven't internalized, explain it in 1-2 sentences and then move on. Format:
> 💡 followed by 1 - 2 sentence explanation
...
</teaching>
按目录划分作用范围：先全局，再仓库，后项目。 把到处都适用的偏好，例如行为方式、长期目标、教学，放到 ~/.claude/CLAUDE.md；把某个仓库的约定，例如 lint（静态检查）、命名、拉取请求，放在仓库根目录；把项目特有的上下文，也就是目录布局和领域知识，放在项目目录。
你在子目录启动 Claude Code 时，它会沿目录树向上查找，并加载每一份 CLAUDE.md。模型在一次会话中途进入某个子目录时，也会读取该目录中的 CLAUDE.md。
当 CLAUDE.md 变得太长，就把它拆出去。 过长的 CLAUDE.md 会形成上下文税：即使当前会话用不到，它也会在每次会话中加载全部内容。解决方法是把其中的片段重构为按需加载的指南。
不要用 @import 导入它们，因为那会直接把内容内联进去；应当让 CLAUDE.md 在相关时机再去读取。这样，一个正在构建 eval（评估）的会话就可以跳过写文档的指南。下面是一个示例指南段落：
<guides>
- Docs, 1-pagers, any writing: ~/.claude/guides/writing.md
- Eval building and reports: ~/.claude/guides/evals.md
- Dashboards: ~/.claude/guides/dashboards.md
...
</guides>
如果一件事每周至少做一次，就把它做成 skill。 skill（按需加载的工作流）是一份带有名称、触发条件和步骤的 Markdown 文件，模型会按需加载。可以把 skill 看成用 Markdown 写成的工作流；它也可以包含逻辑。
例如，我的 /polish skill 会查看产物的 diff（变更差异）：如果产出的是指标，它会运行关联的 eval；如果输出会在浏览器中渲染，它会通过 Claude in Chrome 检查结果；如果两者皆非，它就运行代码并读取输出或错误。
skill 同时编码了步骤，以及判断哪些步骤适用的准则。我拥有的一些 skill 包括：
/polish：检查 bug，简化代码，验证输出，通过 eval、Claude in Chrome 或其他方式迭代到没有关键反馈为止，然后起草 PR（拉取请求）。/write：就大纲采访我，生成研究子 Agent，撰写草稿，通过对抗式批评者给出反馈，迭代到没有关键反馈为止。/daily：读取我的日历、Slack、PR、昨天的日志等，写出当天的优先事项。
我倾向于让 SKILL.md 保持简短，只聚焦工作流和路由。模板、脚本等知识内容放在单独文件里，模型只在需要时才会读取和运行它们，就像按需加载的指南一样。
通过先做一遍任务，再让模型把它变成 skill，来启动 skill 的构建。 我大多数 skill 都是这样做出来的。首先，我在普通会话中以交互方式完成一次任务；然后，请模型把刚刚完成的工作变成一项 skill；接着，在相同或类似任务上运行这项 skill。
不可避免地，我会需要纠正它的输出；我会在同一会话中完成纠正，让反馈被记录进会话转录。最后，我会请模型根据这些纠正和反馈更新 skill。
你也可以用期望输出的示例来为 skill 打底。让模型提取其中的模式，例如你怎样组织代码，或你的文档采用什么样的结构和语气。
通过会话转录而不是直接编辑文件来打磨 skill。 skill 的第一个版本几乎从不完美，因为它会对最初那次会话过拟合。这很正常。当你运行它、需要更新输出时，请在会话内直接纠正。尽量不要直接打开并编辑 SKILL.md。
在会话中给出反馈，能为模型提供不断积累的前后对：这是我们做过的事，这是我想要的结果，以及原因。当输出正确后，请模型把反馈合并进 skill。经过几轮之后，skill 会逐步收敛，最终几乎不需要再编辑输出。
不过，并非每项任务都需要这些上下文。对于头脑风暴、探索和粗略草稿，我喜欢使用 simple mode（简洁模式，CLAUDE_CODE_SIMPLE=1 claude）。在这种模式下，CLAUDE.md 仍会加载，但智能体 harness（运行框架），包括 hook（自动触发脚本）、skill 和重度使用工具的循环，不会加载。
这样我会更接近模型本身；当我在出声思考而不是交付成果时，这正是我想要的。
用验证支撑自主运行
把验证前移：在写入时捕获错误。 我把验证看成一架梯子：底部成本低且是确定性的，顶部昂贵且需要判断。我们希望在尽可能低的台阶上解决问题。
靠近底部的是编辑后 hook，它们会对模型刚更新的文件运行 ruff format、ruff check --fix。这会以确定性的方式发生，也不消耗 token。梯子更高处则是测试、eval、LLM（大语言模型）审阅等。
让模型容易验证自己的工作。 给模型提供反馈闭环，让它能改进输出。如果系统会产生指标，就让模型运行 eval 并加以优化；如果输出会在浏览器中渲染，就让模型通过 Claude in Chrome 检查它；如果两者都不是，就让模型运行它并读取错误。
例如，构建 Docker 镜像时，我会让模型构建、读取错误、编辑 Dockerfile，然后重新构建。如果我在调优一个 harness，模型会运行 eval、读取会话转录并修复失败项。构建仪表盘时，模型会在 Chrome 中检查工具提示是否正常渲染、标签是否重叠、叙事是否与数字一致。
对于长时间运行的任务，让模型监看模型。 随着错误不断累积，长会话可能会偏航。一种解决办法是开一个拥有全新上下文的辅助会话，让它读取原始规格和主会话最近几轮的记录。我的最简设置是两个 tmux 窗格：一个给主开发者，一个给结对程序员。初始指令和后续提示会追加到一份共享文件中。
结对程序员会定期启动，将规格与主开发者最近的会话转录对照；一旦发现问题，就给出反馈，把工作拉回正轨。
这件事可以用很多方式完成。例如，结对程序员可以监看执行偏移：模型是否正在把任务做对？这是局部且战术性的偏移，例如忽略某个错误、报告了错误指标，或偏离规格。
还有方向偏移：模型是否正在做正确的任务？这更具全局和战略性，发生在模型误解原始意图、花数小时构建了错误东西的时候。应当经常检查执行偏移，偶尔检查方向偏移。
通过委派扩大规模
逐渐委派更大的工作块。 有时，我们会和模型结对编程：任务短、反馈快、始终保持参与。这很适合快速迭代、探索性分析和原型开发。但随着模型越来越强，我们应当力求委派更大的任务。
预先说明你的意图、约束和成功标准，然后让模型开始工作。无法验证的事就无法委派，所以这要求先定义成功标准和指标。
这种转变，是从一次只下达一条指令，变为把计划充实好，并让模型端到端地执行。作者给出的任务说明是：
「根据这些 eval 套件，为每个套件构建独立容器，并做冒烟测试，确认每个容器都能构建。接着，做完整运行，记录 eval 指标和会话转录；再用子 Agent 阅读会话转录，确认 eval 都正确运行。每个 eval 运行 n 次，以得到置信区间。最后，生成报告，验证它遵循报告指南，并通过 Slack 把结果和报告 URL 发给我。」
并行运行会话，并找出瓶颈。 委派更大的任务意味着我们可以同时运行更多任务。Claude 显示，我通常会同时运行三到六个会话。瓶颈已从完成工作本身，转移到写出清晰的规格，以及足够快地审阅输出、让流水线持续向前；中间的执行环节所占比重正在下降。
如果并行会话共享一个仓库，请使用 git worktree（独立工作目录），让每个会话都有自己的检出副本，避免互相覆盖改动。
让会话易于观察。 运行多个会话时，我需要知道它们的状态，以及哪一个需要关注。在我的 Mac 上，会话完成时，stop hook 会播放声音，示例如下。我的 tmux 窗口标题使用状态 emoji（⏳ 工作中；🟢 已完成）和一个由 Haiku 生成的简短标签，这样我就能知道每个窗格在做什么。Claude Code 的状态栏会显示上下文使用量和当前模式。
三者结合起来：stop hook 的声音表示有任务已完成，tmux 标题说明是哪个任务，状态栏则提供细节。
# Example stop hook alert
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi"
}
]
}
即使离开电脑，也可以随时查看。 Claude Code 的 /remote-control 让这件事很容易。通勤或排队时，我会打开 Claude app 中的代码标签，看看哪些任务正在运行、哪些任务被阻塞；如有需要，就补充上下文或给出新指令，解除停滞会话的阻塞。
这样会话就会继续前进，而不会闲置数小时。不过，只有在事情紧急时才这样做；当你想专注于当下或出去放松时，不要这么做。
形成闭环
通过公开协作保持上下文丰富。 当我们在共享文档、代码仓库和频道中完成工作时，每个人，包括模型，都会更容易检索并从这些上下文中获益。我们今天分享的内容，会成为明天组织上下文的一部分。
试试这个简单的检验：一位新同事能否只凭共享上下文，复现你上周的工作？如果可以，说明你很好地为组织上下文做出了贡献；如果不可以，那些宝贵上下文仍被困在你的脑海里。
我也通过 CLAUDE.md 中的指令，对这件事做了一些自动化：每当完成一项重要任务，就在工作日志频道发布一条简短更新，并附上产物 PR 或文档的链接。
从会话转录中挖掘配置更新。 让模型阅读过去的会话转录，找出缺口。我扫描了约 2,500 条过往用户轮次，其中相当一部分包含「你能不能也……」「你检查过……吗」「还是不对」等说法。
这些话表明，模型本该在无需提醒时就做某件事；我应当更新 CLAUDE.md 或 skill，或者某个验证步骤缺失或失效。命中次数显示纠正发生得多频繁，会话转录则精确展示了哪里出了问题。
这就是我为什么会在会话内进行纠正：这样我就能把会话转录作为下一次更新 CLAUDE.md 或 skill 的输入。
定期重构和修剪。 随着配置增长，它们可能彼此重叠或冲突。因此，如果模型忽略某条规则，原因可能是另一条规则与它矛盾。定期重构可以解决这个问题。
每条规则或偏好都应只存在于一个地方，尽管关键指令可以在主 CLAUDE.md 中重复。我还会检查零散的目录级 settings.json，并把它们统一收回 ~/.claude。
虽然具体设置会随模型变强而改变，但我认为这些原则仍会适用：提供好的上下文，编码你的品味，让验证便宜，更多地委派，并形成闭环。
我们做的，是一次次通过反馈来训练一位协作者。仔细想想，这些原则同样适用于我们和人类团队的协作方式。
要开始实践，可以先让你的模型阅读一份项目设置说明，然后帮助你把这些原则应用到自己的环境中。
附言：这并不只关乎个人工具。它同样关乎如何设计 Agent harness、设定团队规范、构建组织基础设施。带着这些层面再读一遍，或许会有新的收获。
参考资料
Eugene Yan：《How to Work and Compound with AI》，eugeneyan.com，2026 年 5 月 3 日 Eugene Yan：About，eugeneyan.com，访问于 2026 年 7 月 11 日 Model Context Protocol：What is the Model Context Protocol (MCP)?，官方文档，访问于 2026 年 7 月 10 日 Anthropic：How Claude remembers your project，Claude Code 官方文档，访问于 2026 年 7 月 10 日
资讯来源：微信公众号
