Cowork 五条规则背后的同一件事

最近这半年，Anthropic 在做一件不太显眼但方向很清楚的事：把原本只有开发者会写的 CLAUDE.md、MEMORY.md、skills 这一整套工程化写法，整体搬到 Web 端给非开发者用。这个新产品叫 Claude Cowork，4 月 GA，目标用户是没碰过命令行的知识工作者。

Jeff Su 在他最新一期视频 Top 5 Claude Cowork Tips I Wish I Knew from Day One 里给了 5 条上手规则，他在 Cowork 里跑了 5 个月，靠它管自己整个 newsletter 业务，所以这 5 条是踩过坑的。

我看完之后的判断是：这 5 条规则讲的其实是同一件事，把上下文当稀缺资源管理。区分”每个 session 都要看的东西”和”用到才查的东西”，前者压得越薄越好，后者按主题摊开放好。Cowork 把这条原则做成了开箱即用的工程实践，但它并不只属于 Cowork。Claude Code 老用户读这份清单会有强烈的既视感，因为内核是一样的。

下面按视频的顺序过一遍。

一、用 Obsidian 当 .md 文件的”显示器”

Cowork 的所有规则和记忆都写在 .md 文件里。在 Cowork 网页端直接打开这些文件就是源码视图，难读也难改。Jeff 的建议是装一个免费的 Obsidian，用 Open folder as vault 指到 Cowork 的 workspace 目录，所有 .md 立刻渲染成带标题、加粗、列表的格式，要改就直接改，Cowork 那边自动就能读到。

他特别提了一点：不用学 Obsidian 的其他功能，只把它当显示器和编辑器用。设置里把 Show all file types 打开，还能在侧栏里看到 PDF、表格、图片这些非 .md 文件。

我自己就是 Obsidian 重度用户，这条对我属于零成本。但这里有个更普遍的判断：Cowork 把状态都落到本地 .md，意味着工作上下文是可读、可备份、可版本控制的，不被 Anthropic 锁在云端账户里。这其实是个相当大的取舍——它放弃了云端 Notion 那种实时多端同步，换来了文件系统的可移植性。

二、root CLAUDE.md 的 300 行规则

Cowork 每次启动 session 都会把 root CLAUDE.md 完整加载进上下文。文件越胖，每次对话 token 越多，输出还容易变差。Jeff 说他从 600 多行砍到 250 行后，token 用量直接掉了 25% 左右。

他给的目标线是 200-250 行，绝对上限 300 行。要做到这个数字，他给了三条战术。

第一条：root CLAUDE.md 只放 6 个 section：

• Memory system：让 Cowork 在 session 开始时读 MEMORY.md
• Preferences：怎么沟通（语气、长度、格式）
• Rules：always / never 类的行为护栏
• Routing map：根据任务类型加载哪个 workstation 的表
• References：一行指针，指向那些”用到才加载”的文件
• Creating new workstations：怎么新建一个工作站

第二条：把任务专用的规则迁出去。判断标准是一句话：”Cowork 每个 session 都需要这个，还是只在某个任务出现时才需要？”

Jeff 举的例子是文件创建规则。他原本在 root 里塞了 22 条文件命名和组织规则，但他不是每个 session 都在创建文件。所以他让 Cowork 把这一整段抽到一个独立的 reference 文件，root 里只留一行指针：”创建新文件前读这个”。一句话就完成了从”每次都看”到”用到才查”的转换。

第三条：写在正确的位置。视频里给了两个简洁测试：

• 这条规则带 always / never 之类的祈使语气吗？→ 属于 CLAUDE.md
• 这条记录的是一个”明天可能就变”的事实？→ 属于 MEMORY.md

“我公司用的是 Microsoft Copilot”是事实，明天可能换掉，所以放 MEMORY.md。”起草新邮件前先检查是否已有相关线程”是行为规范，所以放 CLAUDE.md。

这条测试我觉得是整个视频最干净的贡献。我自己在 Claude Code 上用的是另一个角度——”是不是 prescriptive”——但”明天会不会变”这个时间维度的提问更直白，特别适合非工程背景的用户。

Jeff 还顺手给了一个可以马上跑的 prompt：让 Cowork 同时审计 root CLAUDE.md 和 MEMORY.md，对里面每一条都做这个二分类，给出搬家建议。这是个值得抄走的小自动化。

三、MEMORY.md 的”瘦身食谱”

root MEMORY.md 跟 CLAUDE.md 一样，每次 session 都会被加载。Jeff 给了三条规则。

先把结构钉死。他的 root MEMORY.md 固定三块：

• Active projects and work：当前在做的事 + 每件事一句话的状态
• Scheduled tasks：所有 schedule 出去的自动化任务（防止重复创建）
• Cowork-y：关于”我”的持久事实，比如职业背景、LinkedIn、公司地址

150 行设为硬上限。在 memory system rules 里写死一条：”root MEMORY.md 上限 150 行，触顶时永远靠压缩和归档解决，不允许把上限往上抬。” 同时规定每条记忆 1-2 句话以内。这两条配合起来，避免了”为了多记一点就把上限放宽”的滑坡。

单独建一个 archive.md。MEMORY.md 是白板，记当下活跃的东西；archive.md 是档案柜，记所有发生过的事。关键差别是：archive.md 不在 session 开始时加载，只有你问”三个月前那次邮件活动是什么情况”时 Cowork 才会去查。归档因此不再有 token 成本，可以无限存。

更细的优化：每个 workstation 和每个 project 都自己单独建一个 memory.md。问”最近那次邮件活动”的时候，Cowork 先查 root MEMORY.md 看项目存不存在，再跳到对应项目的 memory 里去拿细节。Jeff 说他这么做之后 root MEMORY.md 长期稳定在 100 行以内。

我的补充：这套层级折叠模型本质和 Karpathy 的 LLM 知识库思路是同构的——把时间维度（archive）和主题维度（workstation memory）拆开折叠，让上下文窗口永远只装”现在用得到的”。300 行和 150 行这两个具体数字不是普适的，但”区分常驻 / 按需 / 归档”这个三段结构是普适的。

四、把 Claude Projects 迁成 workstation

很多人在用 Cowork 之前已经在 Claude.ai 上建了一堆 Projects，里面有 instructions、有知识文件、还有自动生成的 project memory。Jeff 的判断很直接：能搬就全搬到 Cowork。

理由是 Claude Projects 有几个硬伤：

• Instructions 只能手动编辑，没法让 Claude 自己改
• Project memory 是 AI 生成的散文段落，结构不可控也不好直接编辑
• 链接进来的 Google Doc，Claude 没办法直接往里写，得人肉粘贴

迁过来之后，project instructions 变成 workstation 的 CLAUDE.md，project memory 变成 MEMORY.md，knowledge files 摊到 resources/ 文件夹里。视频里给了一个 prompt 让 Cowork 一键完成迁移：你把项目的 instructions、memory 导出成两个 .md 文件，再加上 Google Doc 导出的 markdown，全部喂给 Cowork，它会自己建文件夹、写 CLAUDE.md 和 MEMORY.md、把资料分类放进 resources。

迁完之后还有一个细节：Cowork 会顺手在 root CLAUDE.md 的 Routing map 里加一条新路由，下次你说”我要写 newsletter”，它就知道该加载哪个 workstation。

这件事的产品判断：Claude Projects 是上一代 Anthropic 给非开发者用户的”轻量项目空间”，文件结构封闭，AI 不能自己写入。Cowork 是直接把”文件系统是底层”这件事讲给非开发者听了。从这个迁移路径能看出来，Anthropic 内部已经把 Projects 当历史包袱在收口。

五、workstation 还是 skill，看一个简单的问题

Jeff 用一个例子讲清楚了这两者的差别。

他问 Cowork：”我要做下一期 newsletter，从哪儿开始？” Cowork 加载 newsletter workstation，给出工作流。但里面每一步都需要他做判断：这周选哪个工具？要不要换角度？这种工作流跑不了自动驾驶，人必须在回路里。这是 workstation。

写完稿之后，他触发一个叫 newsletter subject line 的 skill，把最终稿喂进去。这个 skill 是一份 checklist，每次输出 5 个评分过的标题选项，结构完全一样，只是内容随稿子变。这种他每次想要同样做法的东西，是 skill。

视频里那个核心测试我觉得值得抄出来：

Is this a place I work, or a thing I do?
这是我”工作的地方”，还是我”做的一件事”？

如果是一块持续推进、有自己语气和积累上下文的领域 → workstation
如果是一个你希望每次都按同样方式跑一遍的可重复流程 → skill

我的补充：我之前总结过一份 Skill 设计五层模型，核心一句话是”description 解决能不能被叫到，contract 解决叫到以后会不会做对”。Jeff 这个 place vs thing 的测试，正好是判断”该不该做成 skill”的第 0 步——如果它本身需要人做判断，做成 skill 也只是把判断又推回给人，那就该留在 workstation 当工作流。

这套规则不只属于 Cowork

5 条规则全部过完之后，回头看会发现它们指向的是同一件事：LLM 的上下文窗口是稀缺资源，工作流是为这个稀缺性服务的。常驻文件越薄越好（300 行规则、150 行规则），按需文件按主题摊开（references、resources），事实按时间折叠（archive），重复流程沉淀成可独立调用的单元（skill），有自己语气的领域留作工作的地方（workstation）。

这恰好就是 Claude Code 那一套 CLAUDE.md + skills + .claude/commands/ 用了一年多的做法。Anthropic 现在把它端到端封装成 Cowork 给非开发者用，背后是一个统一战略：把开发者的工程化习惯，当成 LLM agent runtime 的通用法则。

如果你已经在 Claude Code 上玩过这一套，Cowork 对你不会有学习曲线，只是换了一个外壳；如果你是从 Cowork 入门的非开发者，恭喜，你现在掌握的是一份通用能力，回头去看 Claude Code 也只是换个界面。

原视频：https://www.youtube.com/watch?v=4wvLHFgnQZQ