Eugene Yan 详解如何与 AI 协作并建立可复利的工作流

其他语言版本：韩语版（DG Hong 译）

如何高效地与 AI 协作？工作流该如何设计，怎样才能规模化扩展，又该如何随时间推移持续优化我们的系统？最理想的情况是，这种协作能够形成复利效应。每一个完成的产出物——无论是代码、文档、分析还是决策——都会成为下一次会话的上下文；而每一次纠错，都会沉淀到配置中，从而避免日后重蹈覆辙。虽然我自己也还在摸索，但类似的问题回答得多了，索性写成这篇文章，下次再有人问起，直接发个链接就好。

如果你经常使用 AI，很可能已经在践行其中的不少做法。但我认为，底层的核心原则具有普遍意义：提供充分的上下文、将你的个人品味固化为配置、让验证变得轻而易举、委派更大规模的任务，以及形成闭环。如果某个具体做法不合手，不妨活用这些原则，摸索出属于你自己的套路。另外读下去你也会发现，这里没有哪一条是 AI 所独有的。带新同事入职、与任何新伙伴协作，遵循的也是同样的逻辑。

• • •

上下文即基础设施

帮模型理清上下文路径。举个例子，我所有的代码都存放在 ~/src，所有的知识类工作成果则放在 ~/vault（并进一步整理进 projects/、notes/、kb/ 等目录）。把工作梳理得井井有条，模型通过 grep 或 glob 检索上下文就会容易得多。清晰的目录树让它在浏览目录、查找并借鉴以往的代码、项目文档和分析时更顺畅，从而提升眼下工作的质量。

让模型接入团队的组织上下文。散落在 Slack、Google Drive、邮件等处的组织知识，能为模型带来很大助益。大部分工具都针对 Claude Code、Cowork、Claude.ai 提供了 MCP。除此以外，我还会为每个项目单独维护一份 INDEX.md。这是一份带有注释的相关文档与频道索引，每条条目都包含链接、负责人，以及一段简明扼要的说明，交代内容概述与阅读时机。这些注释能帮上大忙。如果只扔一长串裸链接，模型就得逐个点开确认相关性，白白浪费时间和上下文窗口。提前写好注释，脏活累活一次性搞定并沉淀在索引里，后续便一劳永逸。

把每次新会话都当作新员工入职来带。每次开启新会话，模型都是从零起步。因此，把各个项目的 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。特定代码仓库的规范（如代码检查、命名规则、PR 流程）放在仓库根目录。具体项目的专属上下文（如目录结构、领域知识）则放在项目目录下。在子目录中启动 Claude Code 时，它会向上遍历目录树并加载沿途的每个 CLAUDE.md。而在会话过程中，如果模型切换进入某个子目录，也会自动读取该目录下的 CLAUDE.md。详情参见官方文档。

当 CLAUDE.md 内容过多时，及时拆分。臃肿的 CLAUDE.md 会变成沉重的“上下文税”，即使当前会话用不上，每次也会把所有内容一股脑全加载进来。要解决这个问题，可以把大段内容重构为按需加载的指南文件。不要用 @import 引入它们（因为这会直接将其内联进来），而应在 CLAUDE.md 里告诉模型在相关场景下再去读取。这样一来，构建评估集（evals）的会话就能直接跳过文档编写指南。下面是一个指南部分的示例：

<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）。技能是一个包含名称、触发条件和执行步骤的 Markdown 文件，由模型按需加载。你可以把技能看作是用 Markdown 编写的工作流，其中还可以包含分支逻辑。例如，我的 /polish 技能会检查产物差异（diff）：如果生成了量化指标，就运行对应的 eval；如果内容在浏览器中渲染，就通过 Chrome 中的 Claude 检查页面输出；若两者都不是，就直接运行代码并读取输出或报错。技能不仅固化了操作步骤，还沉淀了“何时该采取哪些步骤”的判断逻辑。我常用的几个技能包括：

• /polish：排查 Bug、简化代码、验证输出（通过 eval、Chrome 中的 Claude 或其他方式）、反复迭代直到没有关键反馈、起草 PR
• /write：通过访谈帮我梳理大纲、启动调研子智能体、撰写初稿、通过对抗式评审机制提出修改意见、反复迭代直到没有关键反馈
• /daily：读取我的日历、Slack、PR 以及昨天的日志等，整理出今天的优先级任务

我倾向于让 SKILL.md 保持轻量，专注于工作流程与调度逻辑。而具体的知识资产（如模板和脚本）则作为独立文件保存，模型只在需要时才读取和运行，就像按需加载的指南一样。

冷启动技能的秘诀：先手动跑通一次，再让模型将其固化为技能。我的大部分技能都是这么做出来的。首先，在普通会话中以交互方式完整执行一次任务；然后，让模型把刚才的操作提炼成一个技能；接着，在相同或类似的任务上运行这个技能。过程中难免需要修正输出，直接在同一个会话里纠正即可，这样反馈就能被完整记入会话记录；最后，让模型根据这些修正和反馈更新技能。你也可以用理想输出的示例作为参考样本，让模型提炼其中的规律，比如代码组织方式，或是文档的结构与语调。

通过对话记录打磨技能，不要直接改文件。技能初版往往很难做到尽善尽美，容易对最初的对话过度拟合，这很正常。当你运行技能需要调整输出时，直接在当前对话中纠正它，尽量不要去打开并直接编辑 SKILL.md。在对话中给反馈，模型就能在记录里积累对比样本——我们之前做了什么、我实际想要什么，以及为什么这么要。等输出满意后，再让模型把这些反馈整合进技能里。经过几轮迭代，技能就会逐渐收敛，产出的最终结果也基本不再需要手动修改。

但话说回来，并不是所有任务都需要这么重的上下文。如果是头脑风暴、初步探索或者写草稿，我更喜欢用简单模式（CLAUDE_CODE_SIMPLE=1 claude）。这种模式下依然会加载 CLAUDE.md，但不会引入钩子、技能和重度依赖工具的循环等智能体框架。这样能让我与模型的交互更直接——在理清思路而非交付代码时，这正是我想要的状态。

保障自主运行的验证机制

验证环节左移：在写入时就捕获错误。我习惯把验证比作梯子：底层的验证成本低且确定性强；顶层则代价高昂，需要依赖主观判断。我们要尽量把问题解决在梯子的最底层。靠近梯子底部的，是在模型刚改完的文件上运行 ruff format 和 ruff check --fix 等编辑后钩子。这种验证是确定性的，而且不消耗 token。再往上走，才是测试、评估、大模型代码审查等手段。

让模型能够轻松验证自己的工作。为模型提供反馈闭环，方便它优化产出。如果系统能输出量化指标，就让模型运行评测并自行优化；如果产物可以在浏览器中渲染，就让模型通过 Claude in Chrome 亲自检查；要是两者都不行，至少让模型运行代码并读取报错。比如在构建 Docker 镜像时，我会让模型自行构建、查看报错、修改 Dockerfile 并重新构建；调试测试框架时，模型会运行评测、阅读记录并修复失败用例；搭建仪表盘时，模型则会在 Chrome 中确认工具提示是否正常显示、标签有没有重叠，以及文字描述是否与数据吻合。

处理耗时较长的任务时，让模型互相监督。会话时间一长，错误不断累积就容易偏离目标。一种解决思路是启动一个拥有全新上下文的辅助会话，让它对照最初的需求说明，审查主会话最近几轮的交互。我最精简的方案是用两个 tmux 窗格，一个给主力开发模型，另一个给结对编程模型。最初的指令和后续的提示词都会追加到一个共享文件中。结对模型会定期启动，比对需求说明与主模型的最新对话记录，一旦发现苗头不对，立刻给出反馈纠正方向。

实现这种机制的方式有很多。例如，结对模型可以监督“执行偏差”——模型把事情做对了吗？这属于局部、战术层面的问题，比如忽略了某处报错、报告了错误指标，或是偏离了具体规范。它还可以监督“方向偏差”——模型在做对的事情吗？这关乎全局和战略层面，往往是模型误解了最初的意图，结果花了好几个小时却南辕北辙。因此，执行偏差要频繁检查，方向偏差则需定期校准。

通过任务委派实现能力扩展

逐步将更大的任务委托出去。有时，我们会与模型结对编程：任务简短、反馈迅速，人始终参与其中。这种模式非常适合快速迭代、探索性分析和原型开发。但随着模型能力越来越强，我们的目标应该是放手让它承担更大的任务。事先讲清楚你的意图、限制条件和成功标准，然后让模型自行处理。无法验证的事情就无法放手委托，因此必须先定义好成功标准和衡量指标。这种转变在于：不再是一条一条指令零敲碎打地喂给模型，而是把计划细化完善后，交由模型端到端独立执行：

“根据这些评测套件，为每个套件构建独立的容器，并进行冒烟测试以确认都能正常构建。接着完整运行评测，记录评测指标与交互记录，并调用子智能体查阅记录，确认评测执行无误。每个评测运行 n 次以计算置信区间。最后生成报告，检查是否符合报告规范，并通过 Slack 把结果和报告链接发给我。”

并行运行多个会话，找准瓶颈所在。把更大的任务委托出去，意味着我们可以同时推进更多事情。据 Claude 统计，我通常会同时跑 3 到 6 个会话。现在的瓶颈不再是亲自动手干活，而是如何写出清晰的规范，以及足够快地审查产出以保证流水线顺畅运转——中间的执行环节正在被抽空。如果并行会话共用一个代码仓库，可以使用 git worktrees，让每个会话拥有独立的代码检出目录，避免互相覆盖改动。

让会话状态一目了然。同时跑多个会话时，我需要随时掌握它们的状态，清楚哪个需要介入。在我的 Mac 上，会话结束时会通过 stop hook 播放提示音（见下方示例）。我的 tmux 窗口标题会显示状态 Emoji（⏳ 处理中；🟢 已完成）以及一段由 Haiku 模型生成的简短标签，方便我了解每个窗格正在做什么。Claude Code 的状态栏则会显示上下文用量和当前模式。这样一来，提示音提醒我有任务完成，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 里打开代码标签页，查看哪些任务正在运行、哪些遇到了阻碍；如有需要，还能补充上下文或下达新指令，帮卡住的会话排除障碍。这样能让会话持续推进，而不是白白闲置数小时。不过，只有遇到紧急情况时再这么做——该享受当下、亲近自然时就别看了。

形成闭环

公开透明地工作，保持丰富的上下文。当我们在共享文档、代码仓库和公共频道中开展工作时，所有人（包括 AI 模型）都能更轻松地检索并利用这些上下文。我们今天分享的内容，明天就会沉淀为组织上下文的一部分。不妨做个简单的测试：新入职的同事仅凭共享出来的上下文，能否复现你上周的工作？如果能，说明你很好地为组织的上下文库做出了贡献；如果不能，就意味着这些宝贵的上下文全被闷在你的脑子里。我在 CLAUDE.md 中配置了相关指令，在一定程度上实现了自动化：每当我完成一项实质性任务，它就会自动在工作日志频道发布简短动态，并附上成果对应的 PR 或文档链接。

从对话记录中挖掘配置更新。让模型通读以往的会话记录，找出遗漏与不足。检索了自己过去约 2,500 轮用户发言后，我发现相当一部分都带有类似 “你能不能顺便……”、“你检查过……了吗”、“还是不对” 这样的说法。这说明有些事情本该由模型主动完成，需要我更新 CLAUDE.md 或技能；又或者表明某个验证步骤缺失或失效了。命中次数能反映纠错发生的频率，对话记录则能精准还原究竟是哪里出了问题。正因如此，我都会在会话中直接纠错，这样就能把记录作为下一次更新 CLAUDE.md 或技能的输入素材。

定期重构与精简。随着配置项越来越多，规则之间难免会出现重叠或冲突。导致的结果就是，模型一旦忽略某条规则，很可能是因为另一条规则与其产生了冲突。解决这一问题的办法就是定期重构。每条规则或偏好原则上都应该只存放在一个地方（不过核心指令可以在主 CLAUDE.md 中重复强调）。我还会检查那些散落在各目录层级的 settings.json，并把它们重新整合回 ~/.claude 中。

• • •

尽管随着模型能力的提升，具体的配置方式很可能会发生改变，但我认为底层原则始终适用：提供充分的上下文、将你的品味编码化、降低验证成本、尽可能放权，并形成闭环。我们实际上是在通过一次又一次的反馈，来磨合培养一位合作伙伴。仔细想想，这些原则同样适用于我们与人类团队的协作。

要开始尝试，可以让你的模型阅读这份 SETUP.txt 并协助你部署应用。此外，我也很想了解你在实践中总结出了哪些有价值的做法或原则——欢迎在下方评论，或随时与我交流！

顺便提一句：这并不仅仅关乎个人工具。它同样适用于智能体运行框架的设计、团队规范的制定，乃至整个组织基础设施的搭建。不妨带着这些层面的思考，再读一遍这篇文章。

如果你觉得本文对你有帮助，引用本文请标注：

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+ 名读者的行列，获取机器学习、推荐系统、大语言模型及工程领域的最新动态。