推荐这篇文章，Anthropic 的 Eugene Yan（前 Amazon/Alibaba ML 团队负责人）把他个人 AI 工作流写成了一份实操指南。不是抽象理念，是具体到你明天就能复制的方法：怎么组织目录让模型更容易检索、怎么写 CLAUDE.md 当行为契约、怎么把每周重复做的事变成 skill、怎么让模型“看模型“来防止跑偏。最后一句话道破了这篇文章的另一个层次——这不只是个人工具，也是设计 agent harness、设定团队规范、构建组织基础设施的方式。

如何与 AI 协作并让工作复利

如何有效地与 AI 协作？工作流是什么样的，如何规模化，以及如何随着时间改善你的系统？理想情况下，它应该是复利的——每一个完成的制品（代码、文档、分析、决策）都成为下一次 session 的上下文。每一次修正都更新了一个配置，减少了未来的错误。

如果你经常使用 AI，你很可能已经在应用很多这些实践了。但基本原则是通用的：提供好的上下文、把你的品味编码为配置、让验证变得容易、委托更大的任务、以及关闭反馈循环。如果你仔细看，会发现这些原则并不是 AI 专用的——它们只是你如何“入职和与任何新合作者协作“的方法。

上下文即基础设施

帮助模型导航你的上下文。 比如，我的所有代码都在 ~/src，所有知识工作都在 ~/vault（组织成 projects/、notes/、kb/ 等目录）。当工作组织有序时，模型用 grep 或 glob 检索上下文就更容易。干净的目录树也让模型更容易导航、找到并依赖之前的代码、项目文档和分析，来改善正在进行的工作。

把模型连接到组织的上下文中。 模型可以从组织知识中受益——这些知识通常存在于 Slack、Drive、邮件里。大多数平台有对应的 MCP 连接器。除此之外，我还维护一个项目级的 INDEX.md。它是一个带注释的相关文档和频道索引，每条都有 URL、负责人、以及一段简短说明。注释非常关键——裸的 URL 清单会强制模型打开所有链接来搞清楚什么相关，浪费时间和上下文。提前做注释，我们一次性做完了这件事。

像入职新人一样引导每个新 session。 每个新 session，模型从一张白纸开始。因此，把项目级的 CLAUDE.md 当成你给一个新同事第一天发的入职文档非常有用。Claude 扫描了我的 CLAUDE.md 并发现在它们中有缩写词汇表、项目代号、重名同事的区分方式。我还有一个推荐阅读顺序——告诉模型先扫 INDEX.md，再扫 TODOS.md，最后是特定主题的笔记。

建立你的记忆层。 默认情况下，模型不记得上一个 session 发生了什么，所以任何值得持久化的东西都应该写到磁盘上。我把记忆层分成两个桶。/vault 存事实：项目状态、制品、领域知识；/.claude（以及其中的 CLAUDE.md、skills/、guides/）包含我的偏好、工作流和个人品味——前者提供上下文，后者提供配置。

品味即配置

从 ~/.claude/CLAUDE.md 开始。 Claude 在每个 session 开始时读取它。我把它看作行为契约。我的 CLAUDE.md 包含偏好，比如要多直接、什么时候反驳、怎么处理错误、怎么教我等等。

按目录分层：全局 → 仓库 → 项目。 把适用于所有地方的偏好（行为、长期目标、教学风格）放在 ~/.claude/CLAUDE.md。把特定仓库的约定放在仓库根目录。把项目特定的上下文（目录布局、领域知识）放在项目目录。当你从子目录启动 Claude Code 时，它会沿着树向上走，加载每个 CLAUDE.md。

当 CLAUDE.md 变得太长时，拆出来。 一个太长的 CLAUDE.md 变成上下文税。它每个 session 加载所有内容，即使 session 不需要。解决方法是把大块重构成懒加载的 guide。不要在 CLAUDE.md 里直接引用它们（那会内联全部内容）——而是告诉它“当相关时去读“。这样，构建 evals 的 session 就跳过了写文档的 guide。

如果你每周做某件事一次以上，把它变成 skill。 一个 skill 就是一个带有名字、触发词和步骤的 markdown 文件。把它们看作用 markdown 写的工作流。可以包含逻辑。比如说，我的 /polish skill 会看制品 diff——如果产生了指标就运行评估，如果在浏览器渲染就用 Claude in Chrome 检查输出，都没有就运行代码读输出或错误。skill 既编码了步骤，也编码了判断适用哪种步骤的逻辑。

通过做一次任务然后让模型把它变成 skill 来引导。 这就是我构建大部分 skill 的方式。先在一个正常 session 里交互式地做一次任务。然后让模型把我们刚刚做的变成一个 skill。接着在相似的或同一个任务上运行这个 skill。不可避免的，我需要修正输出——我在同一个 session 里修正，这样反馈就记录在 transcript 中。最后让模型根据修正和反馈更新 skill。

通过 transcript 精炼 skill，而不是直接改文件。 skill 第一版很少有完美的，因为它在原始 session 上过拟合了。这是正常的。运行它、需要修正输出时，在 session 里修正。不要打开文件编辑 SKILL.md。在 session 里反馈给模型提供了前后对比——这里我们做了什么，这里我想要什么，为什么——这些积累在 transcript 里。输出对了后，让模型把反馈合并进 skill。几轮之后，skill 收敛了，你几乎不需要进一步编辑最终输出。

并不是每个任务都需要这么重的上下文。 对于头脑风暴、探索和草稿，我喜欢用 simple 模式。CLAUDE.md 仍然加载，但 agentic harness——hook、skill、重工具 loop——不运行。这让我更接近模型，也就是我大声思考而不是“交付“时想要的状态。

验证驱动自主

把验证往左移；在写的时候就抓住错误。 我把验证看作梯子。底部便宜且确定性；顶部昂贵且需要判断力。我们要在尽可能低的阶梯上解决问题。靠近底部的是编辑后 hook，在模型刚改过的文件上运行 ruff format。这确定性地发生、不消耗 token。往上是测试、evals、LLM 审查等等。

让模型验证自己的工作变得容易。 给模型反馈循环来改善自己的输出。如果系统产生指标，让模型运行 eval 并优化它。如果制品在浏览器中渲染，让模型通过 Claude in Chrome 检查。都没有，就让模型运行它、读错误。比如，构建 Docker 镜像时，我让模型构建、读错误、编辑 Dockerfile、重新构建。如果我在调 harness，模型跑 evals、读 transcript、修复失败。构建仪表盘时，模型在 Chrome 中检查 tooltip 是否渲染、标签不重叠、叙述匹配数字。

对于长任务，让模型看模型。 长 session 可能跑偏，错误积累。解决方案是运行一个“带着新鲜上下文“的副 session，读取原始 spec 和主 session 最近几轮。我最简单的设置是双 tmux pane——一个主 dev、一个 pair programmer（结对编程者）。初始指令和后续 prompt 追加到共享文件中。结对编程者定期启动，对照 spec 检查主 session 的 transcript，发现偏差则提供反馈以纠正方向。

这意味着检查两种跑偏：执行跑偏（模型做任务的方式对吗？）和方向跑偏（模型在做正确的任务吗？）。前者频繁查，后者偶尔查。

通过委托规模化

委托越来越大的工作块。 有时候，我们和模型结对编程：短任务、快反馈。这对快速迭代、探索性分析、原型制作很好。但是随着模型越来越强，我们应该着眼于委托更大的任务。提前解释意图、约束和成功标准，然后让模型工作。你不能委托你无法验证的东西，所以这要求先定义成功标准和指标。这个转变是——从一次给一个指令，到把一个计划展开，让模型端到端执行：

“给定这些 eval 套件，为每个套件构建隔离容器，烟雾测试每个是否可构建。然后全量运行，记录 eval 指标和 transcript，用子 agent 读 transcript 确认 eval 正确运行。每个 eval 跑 n 次求置信区间。最后生成报告，验证是否符合报告 guide，把结果和报告 URL slack 给我。”

并行运行 session，找到瓶颈。 委托更大的任务意味着可以同时跑多个。我通常同时跑 3-6 个 session。瓶颈已从“做“转移到了“写出清晰的 spec 并快速审核输出以保持管道流动“——中间正在空心化。如果并行 session 共享同一个 repo，使用 git worktree 来让每个 session 获得自己的 checkout，互不覆盖。

让 session 易于观察。 同时跑多个 session 时，我需要知道每个的状态和哪个需要注意力。我的 stop hook 在 session 完成时播放声音。我的 tmux 窗口标题用状态 emoji 和 Haiku 生成的简短标签来告诉我每个 pane 在做什么。Claude Code 的状态栏显示上下文用量和当前模式。

可以在 AFK 时查看。 Claude Code 的 /remote-control 让这变得很容易。通勤或排队时，用 Claude 手机 app 打开 code 标签，看什么在跑、什么被阻塞了，如果需要就解封一个卡住的 session。

闭环积累

通过在公开空间中工作来保持上下文丰富。 当我们在共享文档、仓库、频道里工作时，这使所有人——包括模型——都更容易检索和受益于上下文。我们今天分享的东西明天就成为组织上下文的一部分。试试这个简单测试：一个新队友能否仅用共享上下文复制你上周的工作？能，说明你在为组织上下文做贡献；不能，说明那些宝贵的上下文卡在你脑子里。我通过 CLAUDE.md 里的指令自动化了部分——每次完成一个实质性任务时，发一条简短更新到 worklog 频道，带上制品 PR 或文档的链接。

挖掘你的 transcript 找配置更新。 让模型读过去的 session transcript 来找到缺口。当我扫描了约 2500 条过去的用户轮次时，相当大比例包含“你还能也……““你查了……”“仍然不对“之类的短语。这些说明模型应该在没有提示的情况下做什么，而我应该更新 CLAUDE.md 或 skill，或者说明某验证步骤缺失/坏了。出现次数说明了多频繁，transcript 展示了到底哪里出了问题。

定期重构和裁剪。 随着配置增多，它们可能重叠或相互冲突。结果是如果模型忽略了一条规则，可能是因为另一条规则与之冲突。通过定期重构来修复。每条规则或偏好应该只存在于一个位置（尽管关键指令可以在主 CLAUDE.md 中重复）。也检查是否有零散的目录级 settings.json，合并回 ~/.claude。

具体的设置会随着模型变得更好而改变，但原则会一直相关：提供好的上下文，编码你的品味，让验证便宜，委托更多，以及闭环积累。我们做的是培养一个合作者，一次一个反馈。而且仔细想想，这些原则也适用于和人类团队的合作。

此外，这不是只关乎个人工具。它也是你设计 agent harness、设定团队规范、构建组织基础设施的方式。试试用那些层面再读一遍。

原文：https://eugeneyan.com/writing/working-with-ai/…

#AI工作流 #Agent工程 #Skill实践

How to Work and Compound with AI

Source: https://eugeneyan.com/writing/working-with-ai/

Translations:Koreanby DG Hong

How can we work effectively with AI? What’s the workflow, how does it scale, and how do we improve our systems over time? And ideally, it should compound. Every finished artifact—code, docs, analysis, decisions—becomes context for the next session. And each correction updates a config that reduces future errors. While I’m still learning, I’ve repeated my answers often enough that I’m writing it here so the next time I’m asked I can share a link instead.

If you use AI regularly, you likely already apply many of these practices. Nonetheless, I believe the underlying principles apply broadly: provide good context, encode your taste as config, make verification easy, delegate bigger tasks, and close the loop. If a practice does not fit, adapt the principle and invent your own. Also notice, as you read, that none of this is specific to AI. It’s simply how you onboard and work with any new collaborator.

• • •

Context as infrastructure

**Help models nagivate your context.**For example, all my code lives in~/srcand all my knowledge work lives in~/vault(organized intoprojects/,notes/,kb/and so on). When our work is organized, it makes it easier for the model to retrieve context usinggreporglob. And by having a clean directory tree, it’s more straightforward to navigate the directory, and find and lean on prior code, project docs, analysis, etc. to improve the work being done.

**Connect models to your organization’s context.**Models can benefit from organizational knowledge which likely lives in Slack, Drive, Mail, etc. Most haveMCPsfor Claude Code, Cowork, Claude.ai. On top of these, I also maintain aINDEX\.mdper project. It’s an annotated index of the relevant docs and channels, and each entry includes the URL, owner, and a brief paragraph explaining what’s inside and when to read it. The annotation helps a lot. A bare list of URLs forces the model to open every link to figure out what’s relevant, wasting time and context. By annotating upfront, we do the heavy lifting once and store it in the index.

**Onboard each new session like a new hire.**With each new session, the model starts with a blank slate. Thus, it helps to treat the per-projectCLAUDE\.mdlike the onboarding doc we’d hand to a new teammate on day one. Claude scanned my per-projectCLAUDE\.mdfiles and highlighted that they included glossaries for acronyms, project code names, and teammates with the same first name. I also have a suggested reading order in theCLAUDE\.md, like telling the model to skimINDEX\.mdfirst, thenTODOS\.md, and finally specific topic notes.

**Build your memory layer.**By default, models don’t remember what happened in the last session, so anything worth persisting should be written to disk. I split my memory layer into two buckets.~/vaultholds facts such as project state, artifacts, and domain knowledge;~/\.claude(along with itsCLAUDE\.md,skills/,guides/) contains my preferences, workflows, and personal taste. The former provides context while the latter provides configuration.

Taste as configuration

**Start with~/\.claude/CLAUDE\.md.**Claude reads this at the start of every session. I think of it as a behavioral contract. MyCLAUDE\.mdcontains preferences like how direct to be, when to push back, how to handle mistakes, what to teach me, etc. Here’s a trimmed version:

<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>

**Scope it by directory: global, then repo, then project.**Put preferences that apply everywhere (e.g., behavior, long-term goals, teaching) in~/\.claude/CLAUDE\.md. Put conventions for a specific a repo (e.g., linting, naming, pull requests) in the repo’s root. Put project-specific context (i.e., directory layout, domain knowledge) in the project directory. When you start Claude Code in a subdirectory, it walks up the tree and loads eachCLAUDE\.md. And when the model navigates into a subdirectory mid-session, the model picks up that directory’sCLAUDE\.mdtoo. More in thedocs.

**When CLAUDE.md gets too long, split it out.**A longCLAUDE\.mdcan become a context tax. It loads everything every session even if the session doesn’t need it. To fix this, refactor chunks into guides that load lazily. Don’t@importthem (because that just inlines them). Instead, tell yourCLAUDE\.mdto read them when relevant. This way, a session that’s building evals skips the guide on writing docs. Here’s an example guide section:

<guides>
- Docs, 1-pagers, any writing: ~/.claude/guides/writing.md
- Eval building and reports: ~/.claude/guides/evals.md
- Dashboards: ~/.claude/guides/dashboards.md
...
</guides>

**If you do something ≥ once a week, make it a skill.**A skill is a markdown file with a name, trigger, and procedure that the model loads on demand. Think of skills as workflows written in markdown. They can include logic. For example, my/polishskill looks at the artifact diff. If it produces a metric, it runs the associated eval. If it renders in a browser, it checks the output via Claude in Chrome. If neither, it runs the code and reads the output or error. Skills encode both the steps and the judgment of which steps apply. A few I have include:

• /polish: checks for bugs, simplifies the code, verify the output (via evals, Claude in Chrome, or something else), iterate until no critical feedback, draft the PR
• /write: interviews me for the outline, spawn research subagents, writes the draft, gives feedback via adversarial critic, iterate until no critical feedback
• /daily: reads my calendar, slack, PRs, yesterday’s log, etc and writes today’s priorities

I tend to keepSKILL\.mdsmall and focused on the workflow and routing. The knowledge, like templates and scripts, are separate files that the model reads and runs only when needed, just like lazy-loaded guides.

**Bootstrap skills by doing the task once and then asking the model to make it a skill.**This is how I build most skills. First, I do the task once, interactively, in a normal session. Then, I ask the model to turn what we just did into a skill. Next, I run the skill on the same or similar task. Inevitably, I’ll need to correct the output, which I do in the same session so feedback is logged in the session transcript. Finally, I ask the model to update the skill based on the corrections and feedback. You can also seed a skill with exapmles of the desired output. Ask the model to extract the patterns, like how you organize your code, or the structure and tone of your docs.

**Refine skills via the transcript, not the file directly.**The first version of the skill rarely works perfect because it overfits the original session. This is normal. When you run it and need to update the output, correct it within the session. Try not to open and editSKILL\.mddirectly. Providing feedback in the session gives the model before-and-after pairs which accumulate in the transcript—here’s what we did, here’s what I wanted, and why. Once the output is right, ask the model to merge the feedback into the skill. After a few rounds, the skill converges and you barely have to edit the final output.

**Nonetheless, not every task needs this context.**For brainstorming, exploration, and rough drafts, I enjoy using simple mode (CLAUDE\_CODE\_SIMPLE=1 claude). Here,CLAUDE\.mdstill loads but the agentic harness—hooks, skills, tool-heavy loops—doesn’t. This gets me closer to the model, which is what I want when I’m thinking out loud rather than shipping.

Verification for autonomy

**Shift verification left; catch errors at write time.**I think of verification as a ladder. The bottom is cheap and deterministic; the top is expensive and requires judgement. We want to address issues at the lowest possible rung. Near the bottom are post-edit hooks that runruff format,ruff check \-\-fixon files the model just updated. This happens deterministically and doesn’t cost tokens. Higher on the ladder are tests, evals, LLM reviews, etc.

**Make it easy for the model to verify the work.**Give the model feedback loops to improve its output. If the system produces a metric, let the model run the eval and optimize it. If the output renders in a browser, let the model inspect it via Claude in Chrome. If neither, let the model run it and read the error. For example, when building Docker images, I let the model build, read the error, edit the Dockerfile, and rebuild. If I’m tuning a harness, the model runs evals, reads the transcripts, and fixes failures. When building a dashboard, the model checks in Chrome that tooltips render, labels don’t overlap, and the narrative matches the numbers.

**For long-running tasks, have models watch models.**Long sessions can drift as errors build up. One fix is to run a secondary session with fresh context to read the original spec and the recent turns of the primary session. My minimal setup uses two tmux panes, one for the primary dev, one for the pair programmer. Initial instructions and follow-up prompts are appended to a shared file. Periodically, the pair programmer spins up, checks the spec against the primary’s recent transcript, and if something’s off, provides feedback to course correct.

We can do this in various ways. For example, the pair programmer can watch for execution drift—is the model doing the task right? This is local and tactical, like ignoring an error, reporting a bad metric, or diverging from the spec. There’s also direction drift—is the model doing the right task? These are bigger picture and strategic, and occur when the model misinterprets the original intent and spends hours building the wrong thing. Check for execution drift often and direction drift occasionally.

Scaling via delegation

**Delegate increasingly bigger chunks of work.**Sometimes, we pair-program with models: short tasks, fast feedback, staying in the loop. This well works for fast iterations, exploratory analysis, and prototyping. But with increasingly stronger models, we should aim to delegate bigger tasks. Explain your intent, constraints, and success criteria upfront, then let the model work. You can’t delegate what you can’t verify, so this requires first defining success criteria and metrics. The shift is from giving instructions, one at a time, to fleshing out plans and letting the model execute them end to end:

“Given these eval suites, build isolated containers per suite and smoke-test that each builds. Then, do the full run, log the eval metrics and transcripts, and use subagents to read the transcripts and confirm the evals ran correctly. Run each eval n times for confidence intervals. Finally, generate the report, verify it follows the report guide, and slack me the results and report URL.”

**Run sessions in parallel and find the bottleneck.**Delegating bigger tasks means we can run more at once. Claude says I typically run three to six sessions simultaneously. The bottleneck has shifted from doing the work to writing clear specs and reviewing outputs fast enough to keep the pipeline moving—the middle is hollowing out. If parallel sessions share a repo, use git worktrees so each session gets its own checkout and don’t overwrite each other’s changes.

**Make sessions easy to observe.**When running multiple sessions, I need to know their state and which one needs attention. On my mac, a stop hook plays a sound when a session finishes (example below). My tmux window titles use a status emoji (⏳ working; 🟢 complete) and a short Haiku-generated label so I know what each pane is doing. The Claude Code status line shows context usage and the current mode. Together, the stop-hook sound signals a finished task, the tmux titles shows which one, and the status line provides the details.

# 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"
        }
    ]
}

You can check in even if AFK./remote\-controlin Claude Code makes this easy. While commuting or waiting in line, I open the code tab in the Claude app to see what’s running and what’s blocked, and if needed, unblock a stalled session with additional context or new instructions. This keeps sessions moving instead of sitting idle for hours. Only do this if there’s something urgent though, not when you’re trying to be present or touch grass.

Closing the loop

**Keep the context rich by working in the open.**When we do our work in shared docs, repos, and channels, it makes it easier for everyone—including models—to retrieve and benefit from the context. What we share today becomes part of the org context tomorrow. Try this simple test: could a new teammate replicate your work from last week using only the shared context? If yes, you’re contributing well to the org context; if not, that precious context is stuck in your head. I automate this somewhat via instructions in myCLAUDE\.mdto post short updates in a worklog channel whenever I finish a substantial task, with links to the artifact PR or doc.

**Mine your transcripts for config updates.*Have the model read past session transcripts to find gaps. When I scanned ~2,500 of my past user turns, a sizable percentage contained phrases like“can you also…“,“did you check…“,“still wrong”*, etc. These suggest that the model should have done something unprompted, and I should update theCLAUDE\.mdor skill, or that a verification step is missing or broken. Hit counts show how often a correction happens and the transcripts show exactly what failed. This is why I make corrections within the session, so I can use the transcript as input for my nextCLAUDE\.mdor skills update.

**Refactor and prune periodically.**As configs grow, they can overlap or conflict with each other. As a result, if the model ignores a rule, it can be because another rule contradicts it. Fix this by refactoring periodically. Each rule or preference should live in exactly one place (though critical instructions can be repeated in the mainCLAUDE\.md). I also check for stray directory-levelsettings\.jsonand consolidate them back into~/\.claude.

• • •

While the specific setup will likely change as models get better, I think the principles will remain relevant: provide good context, encode your taste, make verification cheap, delegate more, and close the loop. What we’re doing is training a collaborator, one feedback at a time. And if you think about it, these principles apply to how we work with a human team too.

To get started, have your model read thisSETUP.txtand help you apply it. Also, I’d love to learn what practices or principles you’ve found valuable—please comment below orreach out!

p.s. This isn’tjustabout personal tooling. It’s also how you’d design agent harnesses, set team norms, and build org infrastructure. Try reading it again with those layers in mind.

If you found this useful, please cite this write-up as:

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

or

@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/}
}

Share on:

Join**11,800+**readers getting updates on machine learning, RecSys, LLMs, and engineering.