用上下文、配置与反馈让 AI 工作流复利

推荐这篇文章，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://t.co/iKoAyelIk8 #AI工作流 #Agent工程 #Skill实践