如何与 AI 高效协作并形成复利效应¶

原文：How to Work and Compound with AI 作者：Eugene Yan · 发布时间：2026 年 5 月 · 阅读时长：13 分钟已有翻译：韩文版 by DG Hong

我们如何与 AI 高效协作？工作流是什么样的？如何规模化？如何随着时间推移不断改进我们的系统？理想情况下，这一切应该形成复利效应——每一件完成的产出物（代码、文档、分析、决策）都成为下一次会话的上下文；每一次纠错都更新一项配置，减少未来的错误。虽然我仍在学习中，但我的回答已经被问过足够多次，所以我把它写在这里，下次有人问起时直接分享链接即可。

如果你经常使用 AI，很可能已经在应用其中许多做法了。不过，我相信这些底层原则具有普适性：提供良好的上下文，将你的品味编码为配置，让验证变得简单，委托更大的任务，形成闭环。如果某个具体做法不适用，就适配原则并创造你自己的做法。另外，在阅读过程中你会发现，这一切并非专门针对 AI——这只是你与新协作者进行上手引导和协作的基本方式。

上下文即基础设施¶

帮助模型导航你的上下文。 举个例子，我所有的代码都在 ~/src 中，所有知识类工作都在 ~/vault 中（按 projects/、notes/、kb/ 等分类组织）。当我们的工作井井有条时，模型就能更容易地通过 grep 或 glob 检索上下文。拥有一个清晰的目录树，也让导航目录、查找和复用之前的代码、项目文档、分析等变得更加直观，从而提升当前的工作质量。

将模型连接到你的组织上下文。 模型可以从组织知识中受益——这些知识通常分散在 Slack、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>
- 直接表达，当你不同意时反驳我；如果我的方案有问题，直接说出来。
- 对不确定的事情直接承认，而不是自信地猜测。
- 当某件事失败时，先排查根因再重试。
- 修改范围严格限定在当前任务：不做顺手重排格式或无关重构。
...
</behavior>

<teaching>
我一直在学习新系统和领域。当出现我可能尚未掌握的关键术语时，
用 1-2 句话解释它然后继续。格式：

> 💡 后跟 1-2 句解释
...
</teaching>

按目录划分作用域：全局 → 仓库 → 项目。 将适用于所有地方的偏好（如行为风格、长期目标、教学偏好）放在 ~/.claude/CLAUDE.md 中。将特定仓库的约定（如代码检查规则、命名规范、PR 流程）放在该仓库的根目录下。将项目特定的上下文（如目录布局、领域知识）放在项目目录中。当你在子目录中启动 Claude Code 时，它会向上遍历目录树并加载每个 CLAUDE.md。而且，当模型在会话中途导航到子目录时，也会自动加载该目录下的 CLAUDE.md。更多细节见官方文档。

当 CLAUDE.md 太长时，拆分开来。 冗长的 CLAUDE.md 会变成一种上下文税——每个会话都会加载全部内容，即使本次会话并不需要。解决方式是将大块内容重构为按需懒加载的指南。不要使用 @import 引入（那只是在原地内联展开），而是在 CLAUDE.md 中告诉模型在相关时去读对应的指南文件。这样一来，构建评估指标的会话就不会加载写文档的指南。以下是示例指南部分：

<guides>
- 文档、单页文稿、任何写作：~/.claude/guides/writing.md
- 评估指标构建和报告：~/.claude/guides/evals.md
- 仪表盘：~/.claude/guides/dashboards.md
...
</guides>

如果某件事每周至少做一次，就把它做成技能（skill）。 技能是一个 Markdown 文件，包含名称、触发条件和操作流程，模型按需加载。可以把技能理解为用 Markdown 写的工作流——它们可以包含逻辑。例如，我的 /polish 技能会查看产出物的变更差异（diff），如果产出的是指标就运行关联的评估，如果在浏览器中渲染就通过 Claude in Chrome 检查输出，如果以上都不是就直接运行代码并读取输出或错误信息。技能既编码了步骤，也编码了判断哪些步骤适用的逻辑。我常用的几个技能包括：

/polish：检查 bug、简化代码、验证输出（通过评估、Claude in Chrome 或其他方式），迭代直到没有严重反馈，起草 PR
/write：采访我确定大纲，生成研究子 Agent，撰写草稿，通过对抗性评论给出反馈，迭代直到没有严重反馈
/daily：读取我的日历、Slack、PR、昨日日志等，撰写今日优先级

我倾向于让 SKILL.md 保持短小精悍，聚焦于工作流和路由逻辑。知识（如模板和脚本）则放在单独的文件中，模型只在需要时读取和运行，就像懒加载指南一样。

通过先完整做一次任务再让模型将其转化为技能，来引导创建技能。 这是我构建大多数技能的方式。首先，我在一个普通会话中交互式地完成一次任务。然后，我让模型将我们刚才所做的转化为一个技能。接着，我用这个技能处理相同或类似的任务。几乎不可避免地，我需要纠正输出——我会在同一个会话中进行纠正，这样反馈就会被记录在会话转录中。最后，我让模型根据这些纠正和反馈更新技能。你也可以用期望输出的样例来播种技能：让模型提取其中的模式，比如你组织代码的方式、或文档的结构和语气。

通过会话转录而非直接编辑文件来优化技能。 技能的第一个版本很少完美，因为它会过拟合于最初的会话。这很正常。当你运行技能并需要调整输出时，在会话中进行纠正。尽量不要直接打开和编辑 SKILL.md。在会话中提供反馈会给模型留下前后对比——我们之前做了什么、我想要什么、为什么——这些会累积在转录中。一旦输出正确，再让模型将反馈合并到技能中。经过几轮迭代，技能就会收敛，你几乎不需要再手动编辑最终输出。

并非每个任务都需要这些上下文。 对于头脑风暴、探索和初稿，我更喜欢使用简单模式（CLAUDE_CODE_SIMPLE=1 claude）。在这种模式下，CLAUDE.md 仍然会加载，但 Agent 框架——钩子（hooks）、技能（skills）、工具密集型循环——不会被加载。这让我更接近裸模型本身，而这正是我在做思维发散而非交付成品时想要的体验。

验证即自主¶

将验证左移：在写入时就捕获错误。 我把验证看作一个阶梯。底部是低成本的确定性检查，顶部是高成本、需要人工判断的审查。我们的目标是在尽可能低的阶梯上解决问题。靠近底部的是编辑后钩子（post-edit hooks），比如对模型刚更新过的文件运行 ruff format、ruff check --fix——这些是确定性的，不消耗 token。阶梯更高处是测试、评估指标和 LLM 审查等。

让模型容易验证自己的工作。 给模型提供反馈循环来改进其输出。如果系统生成了一个指标，让模型运行评估并优化它。如果输出在浏览器中渲染，让模型通过 Claude in Chrome 检查它。如果两者都不是，就让模型运行代码并读取错误信息。例如，当构建 Docker 镜像时，我会让模型构建、读取错误、编辑 Dockerfile、再重新构建。当我调优 Agent 框架时，模型运行评估指标、阅读转录、修复失败项。当构建仪表盘时，模型在 Chrome 中检查提示信息是否正确渲染、标签是否重叠、数据叙事是否与数字匹配。

对于长时间运行的任务，让模型监督模型。 长时间会话会随着错误的累积而漂移。一种解决方法是运行一个带有全新上下文的辅助会话，让它阅读原始规格说明和主会话的近期对话记录。我的最小化设置是使用两个 tmux 面板：一个给主开发者（primary），一个给结对程序员（pair programmer）。初始指令和后续提示都追加到一个共享文件中。结对程序员周期性地启动，将规格说明与主会话的近期转录进行对照检查，如果发现偏差，就提供反馈来纠偏。

实现方式有多种。例如，结对程序员可以监控执行漂移——模型是否在执行正确的任务？这是局部的、战术性的问题，比如忽略某个错误、报告了错误的指标、或偏离了规格说明。还有方向漂移——模型是否在做正确的任务？这是更宏观的、战略性的问题，发生在模型误解了最初意图、花数小时构建了错误的东西时。应当频繁检查执行漂移，偶尔检查方向漂移。

规模化委托¶

委托越来越大的工作块。 有时候，我们与模型结对编程：短任务、快速反馈、始终在循环中。这适用于快速迭代、探索性分析和原型开发。但随着模型越来越强，我们应该致力于委托更大的任务。预先说明你的意图、约束和成功标准，然后让模型放手去做。你无法委托自己无法验证的事情，所以这要求首先定义成功标准和指标。转变在于：从一次给一条指令，到充实完整的计划，然后让模型端到端地执行：

"基于这些评估套件，为每个套件构建隔离容器，冒烟测试确保每个都能成功构建。然后进行完整运行，记录评估指标和转录，用子 Agent 读取转录确认评估运行正确。每个评估运行 n 次以获得置信区间。最后，生成报告，验证它遵循报告指南，并通过 Slack 把结果和报告 URL 发给我。"

并行运行会话，找到瓶颈。 委托更大的任务意味着我们可以同时运行更多的会话。Claude 说我通常同时运行三到六个会话。瓶颈已经从执行工作转移到了编写清晰的规格说明和足够快地审查输出以保持流水线运转——中间环节被掏空了。如果并行会话共享同一个仓库，使用 Git 工作树（git worktrees），让每个会话拥有自己的检出副本，避免互相覆盖对方的修改。

让会话易于观察。 当运行多个会话时，我需要知道它们的状态以及哪个需要关注。在 Mac 上，停止钩子会在会话完成时播放声音（示例如下）。我的 tmux 窗口标题使用状态 emoji（⏳ 工作中；🟢 已完成）和一个由 Haiku 生成的简短标签，这样我知道每个面板在做什么。Claude Code 的状态栏显示上下文使用情况和当前模式。三者结合：停止钩子的声音告知任务完成，tmux 标题显示是哪个任务，状态栏提供细节信息。

# 停止钩子告警示例
"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 应用中打开代码标签页，看看什么在运行、什么被阻塞了，如果需要，就用额外的上下文或新指令解除停滞会话的阻塞。这能让会话持续运转而不是闲置数小时。不过，只有有急事时才这么做，而不是在你试图保持当下状态或放下手机放松的时候。

形成闭环¶

通过开放式工作保持上下文丰富。 当我们在共享文档、仓库和频道中工作时，所有人——包括模型——都能更容易地检索并从中受益。我们今天分享的内容，就是明天的组织上下文。试试这个简单的检验：一个新队友能否仅凭共享上下文复现你上周的工作？如果能，说明你在很好地为组织上下文做贡献；如果不能，说明那些宝贵的上下文被困在了你的脑子里。我通过 CLAUDE.md 中的指令来自动化这个过程——每当我完成一个实质性任务，就让模型在工作日志频道发布简短更新，附带产出物 PR 或文档的链接。

挖掘你的会话转录来更新配置。 让模型阅读过去的会话转录来找出缺口。当我扫描大约 2,500 条我的历史用户对话轮次时，发现相当大比例包含这样的短语："你能不能也……""你检查过……""还是不对"，等等。这些暗示模型本应自动完成某些事情，而我应该更新 CLAUDE.md 或技能，或者说明某个验证步骤缺失或已损坏。命中次数显示了某项纠正发生的频率，转录则精确展示了哪里出了问题。这就是为什么我在会话中进行纠正——这样我就可以将转录作为下一次更新 CLAUDE.md 或技能的输入。

定期重构与剪枝。 随着配置不断增长，它们可能重叠或相互冲突。因此，如果模型忽略了一条规则，可能是因为另一条规则与之矛盾。通过定期重构来解决这个问题。每条规则或偏好应该只存在于一个位置（虽然关键指令可以在主 CLAUDE.md 中重复）。我还会检查散落的目录级 settings.json 并将它们合并回 ~/.claude。

尽管具体的操作方式会随着模型变强而改变，但我认为这些原则将持续有效：提供良好的上下文，将你的品味编码为配置，让验证变得低成本，委托更多的任务，形成闭环。我们正在做的，是一次一个反馈地培养一个协作者。而且仔细想想，这些原则同样适用于我们与人类团队协作的方式。

要开始上手，可以让你的模型阅读这份 SETUP.txt 并帮你应用其中的内容。另外，我也很想知道你发现了哪些有价值的实践或原则——欢迎在下方评论或联系我！

p.s. 这不仅仅关乎个人工具链。这也关乎如何设计 Agent 框架、设定团队规范以及构建组织基础设施。试着带着这些层面重新读一遍。

如果你觉得这篇文章有用，请按以下格式引用：

Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.

或

@article{yan2026default,
  title   = {How to Work and Compound with AI},
  author  = {Yan, Ziyou},
  journal = {eugeneyan.com},
  year    = {2026},
  month   = {May},
  url     = {https://eugeneyan.com/writing/working-with-ai/}
}

相关标签： #ai #productivity #mechanism