How to Work and Compound with AI
TL;DR · AI 摘要
文章提供了关于如何有效利用AI工作的原则和实践，但信息密度较低。
核心要点
- 提供良好上下文很重要
- 编码个人偏好作为配置
- 建立记忆层以保存重要信息
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 如何有效利用AI工作
金句 / Highlights
值得收藏与分享的关键句。
当我们的工作有组织时，模型更容易检索上下文。
默认情况下，模型不会记住上次会话发生的事情，因此任何重要的事情都应该写入磁盘。
如何与AI协作并积累知识
- [x]
[eugeneyan](https://eugeneyan.com/)
- [开始阅读](https://eugeneyan.com/start-here/ "开始阅读")
- [写作](https://eugeneyan.com/writing/ "写作")
- [演讲](https://eugeneyan.com/speaking/ "演讲")
- [原型设计](https://eugeneyan.com/prototyping/ "原型设计")
- [关于](https://eugeneyan.com/about/ "关于")
- 
如何与AI协作并积累知识
我们如何有效地与AI合作？工作流程是什么样的？它如何扩展？随着时间的推移，我们如何改进我们的系统？理想情况下，它应该能够累积。每个完成的作品——代码、文档、分析、决策——都成为下一次会话的背景。每次修正都会更新一个配置文件，从而减少未来的错误。虽然我仍在学习中，但我已经多次回答过这些问题，所以我在这里写下它们，以便下次有人问我时，我可以分享一个链接。
如果你经常使用AI，你可能已经在应用许多这些实践了。尽管如此，我认为这些原则具有广泛的应用性：提供良好的上下文，将你的品味编码为配置，使验证变得容易，委派更大的任务，并形成闭环。如果某个实践不适合你，可以调整原则并发明自己的方法。同时请注意，所有这些都不是特定于AI的。这仅仅是与任何新同事合作的方式。
• • •
上下文作为基础设施
帮助模型导航你的上下文。例如，我的所有代码都存放在
~/src中，而所有知识工作则存放在
~/vault中（组织成
projects/、
notes/、
kb/等）。当我们的工作有条理时，模型可以更容易地使用
grep或
glob检索上下文。通过拥有一个干净的目录树结构，导航目录变得更加简单，找到并依赖先前的代码、项目文档、分析等来改进正在进行的工作也更加容易。
连接模型到你的组织上下文。模型可以从组织知识中受益，这些知识可能存在于Slack、Drive、Mail等中。大多数都有MCPs用于Claude Code、Cowork、Claude.ai。在此之上，我还为每个项目维护了一个
INDEX.md。这是一个包含相关文档和频道的注释索引，每个条目包括URL、所有者以及一段简短的描述，解释里面的内容以及何时阅读。注释非常有用。一个简单的URL列表会让模型不得不打开每个链接以确定哪些是相关的，浪费时间和上下文。通过预先注释，我们可以一次性完成繁重的工作并将结果存储在索引中。
像新员工一样启动每次新会话。每次新的会话开始时，模型都从一张白纸开始。因此，将每个项目的
CLAUDE.md视为第一天向新同事提供的入职文档是有帮助的。Claude扫描了我的每个项目的
CLAUDE.md文件，并指出其中包含了缩写词表、项目代号以及同名队友的信息。我还建议在
CLAUDE.md中设置阅读顺序，比如告诉模型先浏览
INDEX.md，然后是
TODOS.md，最后是特定主题的笔记。
构建你的记忆层。默认情况下，模型不会记住上一次会话发生的事情，因此任何值得持久保存的东西都应该写入磁盘。我把记忆层分成两个桶。
~/vault保存事实，如项目状态、作品和领域知识；
~/.claude（连同其
CLAUDE.md、
skills/、
guides/）包含我的偏好、工作流程和个人品味。前者提供上下文，后者提供配置。
当 CLAUDE.md 变得太长时，将其拆分出来。一个很长的
CLAUDE.md可能会成为一种上下文税。即使会话不需要它，每次会话都会加载所有内容。为了解决这个问题，可以将部分内容重构到按需懒加载的指南中。不要
@import它们（因为那样只是内联了它们）。相反，告诉你的
CLAUDE.md在相关时读取它们。这样，构建评估的会话就可以跳过编写文档的部分。这里是一个示例指南部分：
<guides>
- 文档、一页纸、任何写作: ~/.claude/guides/writing.md
- 评估构建和报告: ~/.claude/guides/evals.md
- 仪表板: ~/.claude/guides/dashboards.md
...
</guides>如果你每周做某事不止一次，就把它做成一项技能。 技能是一个包含名称、触发器和程序的 Markdown 文件，模型会在需要时按需加载。可以把技能看作用 Markdown 编写的流程。它们可以包括逻辑。例如，我的
/polish技能会查看工件差异。如果生成了一个指标，就会运行相关的评估。如果在浏览器中渲染，就会通过 Claude 在 Chrome 中检查输出。如果没有上述情况，则运行代码并读取输出或错误。技能编码了步骤以及判断哪些步骤适用的逻辑。我有几个技能包括：
- ```plaintext
/polish
: 检查错误、简化代码、验证输出（通过评估、Claude 在 Chrome 中或其他方式）、迭代直到没有关键反馈、草拟 PR
* ```plaintext
/write: 对我进行访谈以获取大纲、生成研究子代理、撰写初稿、通过对抗性批评提供反馈、迭代直到没有关键反馈
- ```plaintext
/daily
: 阅读我的日历、Slack、PRs、昨天的日志等，并撰写今天的优先事项
我倾向于保持SKILL.md
小而专注，专注于工作流程和路由。知识，比如模板和脚本，是单独的文件，模型只在需要时读取和运行，就像懒加载的指南一样。
**通过执行任务一次然后让模型将其做成技能来启动技能。** 这是我创建大多数技能的方式。首先，我在正常会话中交互式地完成任务一次。然后，我让模型将我们刚刚做的事情变成一个技能。接下来，在相同或类似的任务上运行该技能。不可避免地，我需要纠正输出，我会在同一会话中进行，以便反馈记录在会话记录中。最后，我让模型根据纠正和反馈更新技能。你也可以用预期输出的例子来初始化一个技能。让模型提取模式，比如你如何组织代码，或者文档的结构和语气。
**通过会话记录而不是直接编辑文件来完善技能。** 技能的第一个版本很少完美，因为它过度拟合了原始会话。这是正常的。当你运行它并需要更新输出时，在会话中进行更正。尽量不要直接打开和编辑SKILL.md
。在会话中提供反馈会给模型提供前后对，这些对会在记录中积累——这是我们的做法，这是我希望的，为什么。一旦输出正确，让模型将反馈合并到技能中。经过几轮后，技能会收敛，你几乎不需要编辑最终输出。
**尽管如此，并非每个任务都需要这种上下文。** 对于头脑风暴、探索和粗略草稿，我喜欢使用简单模式（CLAUDE_CODE_SIMPLE=1 claude
）。在这里，CLAUDE.md
仍然加载，但代理框架——钩子、技能、工具密集型循环——不会加载。这让我更接近模型，当我大声思考而不是发布时，这就是我想要的。
## 自主性的验证
**向左移动验证；在编写时捕获错误。** 我认为验证是一个梯子。底部是廉价且确定性的；顶部是昂贵的并且需要判断。我们希望在尽可能低的层级解决这些问题。底部附近的是在模型刚更新的文件上运行ruff format
,ruff check --fix
的后编辑钩子。这会确定性地发生，而且不会消耗令牌。梯子更高处是测试、评估、LLM 审核等。
**让模型轻松验证工作。** 给模型提供反馈回路以改进其输出。如果系统生成了一个指标，让模型运行评估并优化它。如果输出在浏览器中渲染，让模型通过 Claude 在 Chrome 中检查它。如果两者都不是，让模型运行它并读取错误。例如，在构建 Docker 镜像时，我让模型构建、读取错误、编辑 Dockerfile 并重新构建。如果我在调整框架，模型会运行评估、读取记录并修复失败。在构建仪表板时，模型会检查 Chrome 中的提示是否显示、标签是否重叠以及叙述是否与数字匹配。
**对于长时间运行的任务，让模型监视模型。** 长时间的会话可能会因为错误累积而偏离轨道。一种解决方案是运行一个带有新鲜上下文的次要会话，以读取原始规范和主要会话的最新回合。我的最小设置使用两个 tmux 分区，一个用于主要开发人员，另一个用于配对程序员。初始指令和后续提示附加在一个共享文件中。定期，配对程序员启动，检查规范是否与主要会话的最近记录一致，如果有问题，提供反馈以纠正方向。
我们可以用各种方式做到这一点。例如，配对程序员可以监控执行漂移——模型是否正确执行任务？这是局部和战术性的，比如忽略错误、报告不良指标或偏离规范。还有方向漂移——模型是否在正确执行任务？这是更大的图景和战略性的问题，发生在模型误解原始意图并花费数小时构建错误的东西时。经常检查执行漂移，偶尔检查方向漂移。
逐步委派更大的工作块。有时，我们与模型结对编程：短任务、快速反馈、保持参与。这种方法非常适合快速迭代、探索性分析和原型设计。但对于越来越强大的模型，我们应该致力于委派更大的任务。提前解释意图、约束条件和成功标准，然后让模型自行工作。你不能委派你无法验证的工作，因此这需要首先定义成功标准和指标。这种转变是从一次给出指令到制定计划并让模型从头到尾执行这些计划：
> “根据这些评估套件，为每个套件构建隔离的容器，并测试它们是否能正确构建。然后，进行全面运行，记录评估指标和转录，使用子代理读取转录并确认评估是否正确运行。每个评估运行n次以获得置信区间。最后，生成报告，确保它遵循报告指南，并通过Slack发送结果和报告URL。”
**并行运行会话并找到瓶颈。** 委派更大的任务意味着我们可以同时运行更多任务。Claude说他通常同时运行三到六个会话。瓶颈已经从执行工作转移到了编写清晰的规范和快速审查输出，以便保持流水线的顺畅——中间环节正在变空。如果并行会话共享一个仓库，使用git工作树，这样每个会话都能有自己的检出，不会互相覆盖更改。
**使会话易于观察。** 当运行多个会话时，我需要知道它们的状态以及哪个会话需要关注。在我的Mac上，当会话完成时，停止钩子会播放声音（见下例）。我的tmux窗口标题使用状态表情符号（⏳进行中；🟢已完成）和一个简短的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" } ] }
**即使不在场也可以检查。**/remote-control
在Claude Code中使这变得容易。在通勤或排队等候时，我会打开Claude应用中的代码标签页，查看哪些任务正在运行以及哪些任务被阻塞，如果需要，可以使用附加的上下文或新指令来解除阻塞。这可以让会话继续运行而不是闲置数小时。只有在有紧急情况时才这样做，而不是当你试图专注或接触自然环境时。
## 闭环
**通过公开工作保持丰富的上下文。** 当我们在共享文档、仓库和频道中进行工作时，这使得每个人——包括模型——更容易检索和利用上下文。今天分享的内容将成为明天组织的一部分上下文。尝试这个简单的测试：一位新同事能否仅凭共享的上下文重现你上周的工作？如果是，你很好地为组织上下文做出了贡献；如果不是，那些宝贵的上下文就卡在你的脑子里。我通过在 CLAUDE.md
中添加指令，部分实现了这一点，每当完成一个重要任务时，自动在工作日志频道发布简短更新，并附上指向工件PR或文档的链接。
**从转录中挖掘配置更新。** 让模型阅读过去的会话转录，找出缺失的部分。当我扫描了大约2,500个过去用户的回合时，相当大比例的转录包含诸如“你能也……”、“你检查过……”、“仍然不对”等短语。这些表明模型应该未提示就做了某些事情，我应该更新 CLAUDE.md
或技能，或者缺少或损坏了一个验证步骤。命中次数显示纠正发生的频率，而转录则显示具体哪里失败了。这就是为什么我在会话中进行纠正，以便我可以将转录作为输入用于下一次 CLAUDE.md
或技能更新。
**定期重构和修剪。** 随着配置的增长，它们可能会重叠或冲突。结果，如果模型忽略了某个规则，可能是因为另一个规则与其矛盾。通过定期重构来解决这个问题。每个规则或偏好应只存在于一个地方（尽管关键指令可以在主要 CLAUDE.md
中重复）。我还检查是否有零散的目录级 settings.json
并将其合并回 ~/.claude
。
---
虽然具体的设置可能会随着模型的进步而改变，但我认为这些原则将会保持相关性：提供良好的上下文，编码你的品味，使验证变得廉价，委派更多工作，并闭环。我们所做的就是在一次反馈接一次反馈的基础上训练一个合作者。如果你仔细想想，这些原则同样适用于我们与人类团队合作的方式。
要开始，请让你的模型阅读这篇
[SETUP.txt](https://eugeneyan.com/assets/SETUP.txt)
并帮助你应用它。此外，我很乐意了解你发现有价值的做法或原则——请在下面评论或
[联系我们！](https://x.com/eugeneyan)
附注：这不仅仅是关于个人工具。这也是如何设计代理套件、设定团队规范以及构建组织基础设施。尝试带着这些层面重新阅读这篇文章。
如果你觉得这篇文章有用，请引用：
> Yan, Ziyou. (May 2026). 如何与AI协作和积累。eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.
或
@article{yan2026default, title = {如何与AI协作和积累}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2026}, month = {May}, url = {https://eugeneyan.com/writing/working-with-ai/} }
分享到：
* * *
浏览相关标签: [ [ai](https://eugeneyan.com/tag/ai/)[productivity](https://eugeneyan.com/tag/productivity/)[mechanism](https://eugeneyan.com/tag/mechanism/) ] 或 [搜索](https://eugeneyan.com/search/ "搜索")
[« 2025 年度回顾](https://eugeneyan.com/writing/2025-review/)
* * *
加入 **11,800+** 读者，获取有关机器学习、RecSys、LLM 和工程的更新。
获取电子邮件更新
* * *
* [Twitter](https://twitter.com/eugeneyan "Twitter")
* [LinkedIn](https://www.linkedin.com/in/eugeneyan/ "领英")
* [GitHub](https://github.com/eugeneyan/ "GitHub")
我是 Anthropic 的技术人员。我致力于弥合领域与前沿之间的差距，并帮助构建可扩展的安全、可靠的 AI 系统。我在亚马逊、阿里巴巴、Lazada 和一家健康科技 A 轮公司领导过 ML/AI 团队，并在 [eugeneyan.com](https://eugeneyan.com/) 上撰写关于 LLM、RecSys 和工程的文章。
© Eugene Yan 2015 - 2026 • [反馈](https://eugeneyan.com/site-feedback/) • [RSS](https://eugeneyan.com/rss/)