如何与AI协作并实现复利

我们如何高效地与 AI 协作？工作流是怎样的，如何规模化，以及如何持续改进我们的系统？理想情况下，这种改进应该是复利式的。每一个完成的产物——代码、文档、分析、决策——都会成为下一次会话的上下文。每一次修正都会更新配置，从而减少未来的错误。虽然我仍在学习，但我的回答已经重复得足够多，所以我把它们写在这里，这样下次有人问起时，我就可以直接分享一个链接。

如果你经常使用 AI，你可能已经在应用许多这些实践。尽管如此，我相信底层原则具有广泛的适用性：提供良好的上下文，将你的品味编码为配置，让验证变得简单，委派更大的任务，并形成闭环。如果某个实践不适用，请根据原则进行调整并创造你自己的方法。同时请注意，在阅读过程中，你会发现这些都不是 AI 特有的。这本质上就是如何让任何新协作者入职并与之共事的方法。

• • •

上下文即基础设施

帮助模型导航你的上下文。 例如，我所有的代码都存放在 ~/src 中，所有知识工作都存放在 ~/vault 中（按 projects/、notes/、kb/ 等组织）。当我们的工作组织有序时，模型就能更容易地使用 grep 或 glob 来检索上下文。通过拥有一个清晰的目录树，导航目录、查找并依赖先前的代码、项目文档、分析等来改进当前工作，也会更加直接。

将模型连接到你组织的上下文。 模型可以从组织知识中受益，这些知识可能存在于 Slack、Drive、Mail 等平台中。大多数平台都有适用于 Claude Code、Cowork、Claude.ai 的 MCPs。除此之外，我还为每个项目维护一个 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>
- 要直接，并在你不同意时提出异议；如果我的方法有问题，请指出来。
- 当对某事不确定时，要说不确定，而不是自信地猜测。
- 当某件事失败时，在重试之前先调查根本原因。
- 保持 diff 范围仅限于任务本身：不要附带重新格式化或不相关的重构。
...
</behavior>

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

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

按目录划分范围：全局，然后是仓库，最后是项目。 将适用于所有地方的偏好（例如，行为、长期目标、教学）放在 ~/.claude/CLAUDE.md 中。将特定仓库的约定（例如，linting、命名、pull request）放在该仓库的根目录下。将项目特定的上下文（即目录布局、领域知识）放在项目目录中。当你在子目录中启动 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。 Skill 是一个 markdown 文件，包含名称、触发条件和流程，模型会按需加载。可以把 skill 想象成用 markdown 编写的工作流。它们可以包含逻辑。例如，我的 /polish skill 会查看产物 diff。如果它产生了一个指标，就会运行相关的评估。如果它在浏览器中渲染，就会通过 Claude in Chrome 检查输出。如果两者都不是，它就会运行代码并读取输出或错误。Skill 既编码了步骤，也编码了判断哪些步骤适用的逻辑。我拥有的一些 skill 包括：

• /polish：检查 bug，简化代码，验证输出（通过评估、Claude in Chrome 或其他方式），迭代直到没有关键反馈，起草 PR
• /write：就大纲对我进行访谈，生成研究子 agent，起草草稿，通过对抗性批评家提供反馈，迭代直到没有关键反馈
• /daily：读取我的日历、slack、PR、昨天的日志等，并写下今天的优先事项

我倾向于保持 SKILL.md 小巧且专注于工作流和路由。知识，比如模板和脚本，是单独的文件，模型只在需要时读取和运行，就像懒加载的指南一样。

通过先执行一次任务，然后让模型将其制作为 skill 来引导 skill。 这就是我构建大多数 skill 的方式。首先，我在一个普通会话中交互式地执行一次任务。然后，我让模型将我们刚刚做的事情变成一个 skill。接着，我在相同或类似的任务上运行这个 skill。不可避免地，我需要修正输出，我会在同一个会话中进行，这样反馈就会被记录在会话记录中。最后，我让模型根据修正和反馈更新 skill。你也可以用期望输出的示例来初始化一个 skill。让模型提取模式，比如你如何组织代码，或者你的文档的结构和语气。

通过会话记录来优化 skill，而不是直接编辑文件。 skill 的第一个版本很少能完美运行，因为它过度拟合了原始会话。这很正常。当你运行它并需要更新输出时，在会话中进行修正。尽量不要直接打开和编辑 SKILL.md。在会话中提供反馈，会给模型提供前后对比对，这些会累积在记录中——这是我们做的，这是我想要的，以及原因。一旦输出正确，就让模型将反馈合并到 skill 中。经过几轮之后，skill 会收敛，你几乎不需要再编辑最终输出。

尽管如此，并非每个任务都需要这种上下文。 对于头脑风暴、探索和草稿，我喜欢使用简单模式（CLAUDE_CODE_SIMPLE=1 claude）。在这里，CLAUDE.md 仍然会加载，但 agent 框架——hooks、skills、大量工具的循环——不会加载。这让我更接近模型本身，这正是我在大声思考而不是交付时想要的。

为自主性而验证

将验证左移；在写入时捕获错误。 我把验证看作一个梯子。底部是廉价且确定性的；顶部是昂贵且需要判断的。我们希望尽可能在最低的梯级上解决问题。接近底部的是编辑后 hooks，它们会在模型刚刚更新的文件上运行 ruff format、ruff check --fix。这是确定性地发生的，不消耗 token。梯子更高处是测试、评估、LLM 审查等。

让模型更容易验证工作。 给模型提供反馈循环以改进其输出。如果系统产生了一个指标，让模型运行评估并优化它。如果输出在浏览器中渲染，让模型通过 Claude in Chrome 检查它。如果两者都不是，让模型运行它并读取错误。例如，在构建 Docker 镜像时，我让模型构建、读取错误、编辑 Dockerfile 并重新构建。如果我在调整一个框架，模型会运行评估、读取记录并修复失败。在构建仪表盘时，模型会在 Chrome 中检查 tooltip 是否渲染、标签是否重叠、叙述是否与数字匹配。

对于长时间运行的任务，让模型监控模型。 长时间的会话可能会因为错误的累积而偏离轨道。一个解决方法是运行一个具有新鲜上下文的辅助会话，来读取原始规范以及主会话最近的轮次。我的最小设置使用两个 tmux 窗格，一个用于主要开发，一个用于结对编程。初始指令和后续提示被追加到一个共享文件中。结对编程者会定期启动，根据规范检查主会话最近的记录，如果发现偏差，就提供反馈以纠正方向。

我们可以通过多种方式实现这一点。例如，结对编程者可以监控执行漂移——模型是否正确地执行了任务？这是局部和战术性的，比如忽略一个错误、报告一个糟糕的指标或偏离规范。还有方向漂移——模型是否在执行正确的任务？这些是更大范围和战略性的，发生在模型误解了原始意图并花费数小时构建错误的东西时。经常检查执行漂移，偶尔检查方向漂移。

通过委派实现规模化

委派越来越大的工作块。 有时，我们与模型结对编程：短任务、快速反馈、保持参与。这对于快速迭代、探索性分析和原型设计很有效。但随着模型能力的不断增强，我们应该致力于委派更大的任务。预先解释你的意图、约束和成功标准，然后让模型工作。你无法委派你无法验证的事情，因此这首先需要定义成功标准和指标。这种转变是从一次一个指令，到充实计划并让模型端到端执行：

“给定这些评估套件，为每个套件构建隔离的容器，并进行冒烟测试确保每个都能构建。然后，进行完整运行，记录评估指标和记录，并使用子 agent 读取记录以确认评估正确运行。每个评估运行 n 次以获得置信区间。最后，生成报告，确认其遵循报告指南，并通过 slack 将结果和报告 URL 发送给我。”

并行运行会话并找到瓶颈。 委派更大的任务意味着我们可以同时运行更多任务。Claude 说我通常同时运行三到六个会话。瓶颈已经从执行工作转移到了编写清晰的规范和足够快地审查输出以保持流水线运转——中间部分正在被掏空。如果并行会话共享一个仓库，请使用 git worktrees，这样每个会话都有自己的检出，不会互相覆盖更改。

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

# 停止 hook 警报示例
"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"
        }
    ]
}

即使 AFK 也可以查看状态。 Claude Code 中的 /remote-control 让这变得很容易。在通勤或排队时，我打开 Claude 应用中的代码标签页，查看正在运行什么以及什么被阻塞了，如果需要，可以通过提供额外的上下文或新指令来解除停滞的会话。这能让会话持续进行，而不是闲置数小时。不过，只有在有紧急事情时才这样做，而不是在你想要专注当下或接触自然的时候。

形成闭环

通过在开放环境中工作来保持上下文的丰富性。 当我们在共享文档、仓库和频道中完成工作时，每个人——包括模型——都能更容易地检索和受益于这些上下文。我们今天分享的内容明天就会成为组织上下文的一部分。试试这个简单的测试：一个新队友能否仅使用共享上下文复制你上周的工作？如果能，说明你为组织上下文做出了良好贡献；如果不能，说明那些宝贵的上下文还停留在你的脑子里。我通过 CLAUDE.md 中的指令在一定程度上自动化了这一点，指示它在每次完成重要任务后，在工作日志频道中发布简短更新，并附上产物 PR 或文档的链接。

挖掘你的记录以更新配置。 让模型阅读过去的会话记录以发现差距。当我扫描了大约 2,500 条我过去的用户轮次时，相当大比例包含诸如“你还能否也……”、“你检查过……吗”、“还是错的”等短语。这表明模型本应主动做一些事情，我应该更新 CLAUDE.md 或 skill，或者某个验证步骤缺失或损坏了。命中次数显示了修正发生的频率，而记录则精确显示了失败的原因。这就是为什么我在会话中进行修正，这样我就可以将记录作为下一次 CLAUDE.md 或 skill 更新的输入。

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

• • •

虽然随着模型变得更好，具体的设置可能会改变，但我认为这些原则将保持相关：提供良好的上下文，编码你的品味，使验证变得廉价，委派更多任务，并形成闭环。我们正在做的是一次次地通过反馈来训练一个协作者。如果你仔细想想，这些原则也适用于我们与人类团队合作的方式。

要开始，让你的模型阅读这个 SETUP.txt 并帮助你应用它。另外，我很想了解你觉得有价值的实践或原则——请在下方评论或联系我！

附注：这不仅仅是关于个人工具。这也是你设计 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/}
}

分享到：

加入 11,800+ 位读者，获取关于机器学习、推荐系统、LLM 和工程的最新资讯。