Eugene Yan 2小时前 · 2026-09-07 03:30:40 · 4 阅读

如何与 AI 协作并产生复利效应

翻译：韩文版，由 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>
- 直言不讳，意见不合时勇于反驳；如果我的方案有问题，直接指出来。
- 不确定时，坦承不懂，不要自信地猜测。
- 遇到失败时，先调查根本原因再重试。
- 控制 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>

如果某件事每周至少做一次，就把它做成技能。技能是一个带有名称、触发条件和执行流程的 Markdown 文件，模型会在需要时按需加载。可以把技能理解为用 Markdown 编写的.workflow，它们甚至可以包含逻辑判断。例如，我的 /polish 技能会检查工件差异：如果生成了指标，就运行对应的评估；如果在浏览器中可渲染，就用 Chrome 中的 Claude 验证输出；否则直接运行代码并读取输出或错误信息。技能既编码了步骤，也编码了“哪些步骤适用”的判断逻辑。我有以下几个技能：

/polish：检查 bug、简化代码、验证输出（通过评估、Chrome 中的 Claude 或其他手段）、迭代至无关键反馈、起草 PR
/write：与我访谈以确定大纲、启动研究子代理、撰写初稿、通过对抗性评论者提供反馈、迭代至无关键反馈

/daily：读取我的日历、Slack、PR、昨天的日志等，然后写下今天的优先事项

我倾向于让 SKILL.md 保持精简，只关注工作流和路由。具体知识（比如模板和脚本）放在单独的文件里，模型只在需要时才读取和执行，就像懒加载的指南一样。

把任务做一遍，然后让模型把它变成一个 skill，以此启动 skills。我的大部分 skill 都是这么建的。先在正常会话中交互式地把任务完整做一遍，然后让模型把我们刚才做的事情写成 skill。接着用这个 skill 跑同样或类似的任务，结果难免需要修正——修正也在同一个会话里进行，这样反馈会记录在会话记录中。最后让模型根据修正和反馈更新 skill。你也可以用期望输出的示例来初始化 skill，让模型提炼其中的模式，比如你组织代码的方式，或者文档的结构和语气。

通过会话记录来打磨 skill，不要直接改文件。skill 的第一版很少能完美工作，因为它过拟合了最初的会话。这很正常。运行后如果需要调整输出，就在会话里纠正它，尽量不要直接打开 SKILL.md 编辑。在会话中提供反馈，能让模型获得前后对照的样本对，不断累积在会话记录里：我们做了什么、我想要什么、为什么。等输出正确了，再让模型把这些反馈合并进 skill。几轮下来，skill 就会收敛，最终输出几乎不用再改。

不过，不是所有任务都需要这些上下文。做头脑风暴、探索和粗略草稿时，我喜欢用简单模式（CLAUDE_CODE_SIMPLE=1 claude）。这种模式下 CLAUDE.md 仍然会加载，但 agentic harness（hooks、skills、大量工具调用的循环）不会。这让我更贴近模型本身——当我是在思考而不是在交付时，这正是我想要的。

用验证换取自主性

验证环节尽量前置，在编码阶段就发现问题。 我把验证过程视为一架梯子：底层成本低且确定性强，顶层昂贵且需要主观判断。我们应在尽可能低的层级上解决问题。靠近底部的是后编辑钩子，对模型刚更新过的文件自动运行 ruff format 和 ruff check --fix。这些操作是确定性的，不消耗 token。再往上则是测试、评估、LLM 审查等。

让模型能轻松验证自己的产出。 给模型提供反馈回路以提升输出质量。如果系统能生成指标，就让模型运行评估并优化该指标；如果输出可在浏览器中渲染，就让模型通过 Chrome 中的 Claude 进行检查；如果以上都没有，就让模型运行代码并读取报错。例如，构建 Docker 镜像时，我让模型执行构建、读取错误、修改 Dockerfile 并重新构建；调试测试框架时，模型运行评估、查看日志并修复失败项；开发仪表盘时，模型在 Chrome 中检查 tooltip 是否正常显示、标签是否重叠、叙述是否与数据一致。

对于长时间运行的任务，安排模型监控模型。 长会话中错误可能逐渐累积导致偏离。一种解决方案是启动一个带最新上下文的辅助会话，阅读原始需求说明以及主会话近期的交互记录。我的极简方案使用两个 tmux 窗口：一个用于主开发者，一个用于配对程序员。初始指令和后续提示都追加到一个共享文件中。定期让配对程序员启动，对照主会话近期记录检查需求规格，若发现偏差则提供纠正反馈。

我们可以多种方式实现这一点。例如，配对程序员可以关注执行漂移——模型是否正确执行了任务？这类问题属于本地战术层面，如忽略错误、报告异常指标或偏离需求规格。另一种是方向漂移——模型是否在做正确的任务？这类问题更宏观且具战略性，通常发生在模型误解原始意图、花费数小时构建错误方案时。应频繁检查执行漂移，偶尔检查方向漂移。

通过委派实现规模化

委托越来越大的工作块。 有时我们会与模型结对编程：简短任务、快速反馈、全程参与。这在快速迭代、探索性分析和原型制作中效果不错。但随着模型能力不断增强，我们应致力于委托更大的任务。 upfront 说明你的意图、约束条件和成功标准，然后让模型自行工作。无法验证的就无法委托，因此这需要先定义成功标准和指标。工作模式应从逐一给出指令，转变为制定详细计划并让模型端到端地执行：

“根据这些评估套件，为每个套件构建隔离的容器并进行冒烟测试，确保构建成功。接着运行完整流程，记录评估指标和转录文本，并使用子智能体读取转录文本以确认评估正确执行。为计算置信区间，每个评估重复运行 n 次。最后生成报告，校验其是否符合报告指南，并将结果和报告 URL 发到我的 Slack。”

并行运行会话，找出瓶颈。 委托更大任务意味着我们可以同时运行更多工作。Claude 表示我通常同时运行三个到六个会话。瓶颈已从执行工作转移到能否足够快地编写清晰规格并审查输出，以保持流水线运转——中间环节正在空心化。如果并行会话共享同一个仓库，请使用 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 里的指令做一定程度的自动化：每完成一个重要任务，就往 worklog 频道发一条简短更新，附上对应的 PR 或文档链接。

从历史会话记录中挖掘配置更新点。让模型读取过去的会话记录，找出其中的缺口。我扫描了自己约 2,500 条历史对话，相当一部分包含诸如 “能不能顺便……”、“你检查过……吗”、“还是不对” 这类表述。这说明模型本应主动完成某些操作，需要我更新 CLAUDE.md 或 skill，或者某个验证步骤缺失或失效了。命中的次数反映了纠正出现的频率，而记录本身则完整呈现了失败的过程。这也是我坚持在会话内做纠正的原因——这样这些记录就能作为下一次更新 CLAUDE.md 或 skills 的输入。

定期重构和精简配置。随着配置不断增长，各项规则之间可能重叠甚至冲突。结果就是，模型忽略某条规则，可能只是因为另一条规则与之矛盾。解决办法是定期重构：每条规则或偏好只应存在于一处（关键指令可以在主 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/}
}

原始来源： Eugene Yan