把 Obsidian 旧笔记变成 Claude Code 工作指令的十分钟早间例程

周二早上，我把 Obsidian 里那条「文章重写」笔记原封不动贴给了 Claude Code。三周积累的内容，大概两千字。结果它返回来的第一条建议，是去改一段我上周已经改好的引导文案（按钮上的那句话），还一本正经地说「我们来改一下吧」。

为什么会这样？因为在那条笔记里，三周前写的「免费 PDF 可能不够吸引人」这条假设，和上周写的「确定把免费 PDF 作为主引导」这条决定，用的是同一种平铺直叙的列表项排在一起。在 AI 看来，这俩就是「笔记里两条同样分量的信息」。所以它去怀疑那条早就拍板的决定，又把做完的活儿重新提议了一遍。

不是笔记写得不够，而是过时的假设和已经定下的决定混在一起原样递了过去。今天就聊聊，怎么用早上十分钟把这件事修好。

本文要点

• Obsidian 的长笔记直接粘贴，AI 会把旧假设和已定事项当成同等分量，于是反复翻炒已经做完的活儿。
• 把笔记拆进「今天仍成立的事实 / 已经定下的决定 / 还不清楚的事 / 下一步 / 验证方式」这五个格子，递过去的信息变少了，判断质量反而上来了。
• 拆分十分钟就能搞定。下面放了一段可以直接复制运行的 Node.js 脚本。
• 「这是事实还是假设」由人来判断，「把文字写出来」交给 AI。这两件事混在一起就会出事。
• 入门读者走免费学习路径，公司层面的业务改进走咨询，按读者所处阶段把出口收敛到一个。

为什么「把笔记原样贴过去」会出事

Obsidian 的长处是信息可以一直往里加。但到了递给 AI 的场合，这反而成了短板。

人在读自己笔记的时候，会下意识地给信息标上「这条旧、这条最新」的权重。从日期、从上下文关系里，自动做了取舍。AI 不会替你做这件事。列表里第 3 行和第 30 行，它都同等地当成「当前有效的信息」来接收。

所以三周前那句「也许……」，在今天的请求里被当成了既定事实；反过来，上周刚拍板的事，又被降格成了「众多备选之一」。开头我踩的那个坑，正是这么来的。笔记越多，递出去之前就越需要先做一遍筛选。

十分钟拆分法

每天早上，或者开始干活之前，把要用的那条笔记拆进下面五个格子。最多十分钟。如果花的时间超过这个数，多半是你往格子里塞太多了。

1. 今天仍成立的事实只留 3 条。必须是验证过、且今天依然成立的。
2. 已经定下的决定写 2 条。比如「把免费 PDF 作为主引导」这种不再动摇的方针。
3. 还不清楚的事只写 1 条。是这次想通过 AI 的回复去确认的那一件。
4. 下一步收成一句话。像「重写一段引导文案，并确认发布后的 URL 能正常打开」这样，以动词收尾的具体动作。
5. 验证方式写清楚。凑齐什么才算「做完了」：跑测试、看显示效果、检查死链等等。

格子的数量是写死的，这有它的道理。事实 3 条、决定 2 条、未知 1 条。再往上加，就又退回到「全部都递过去」的老路了。用格子的上限，逼自己拿出「敢删」的勇气。

用这五个格子重写一遍之后，Obsidian 就从「什么都往里扔的仓库」变成了「今天的工作台」。

交给 AI 的部分，和人来判断的部分

这两块混在一起就会出事。先把边界划清楚。

环节	由谁负责	原因
判断是事实还是假设	人	AI 容易把过去的假设当成既定事实
哪条决定今天还有效	人	方针够不够新，只有人知道
重排进五个格子、做摘要	AI（出初稿）	机械性的整理，AI 很快
把工作指令写成文字	AI	生成文字是它的强项
发布、上线的最终拍板	人	不可逆的操作必须叫停

诀窍是，「这是事实」这个拍板的按钮，只让人来按。让 AI 出初稿，但筛选的最终判断权不撒手。光是这一条，决定被反复翻炒的事故就基本绝迹了。

如果你对笔记管理本身还心里没底，建议先读一读 Obsidian 集成基础 和 把 Obsidian 笔记变成 Claude Code 工作指令的方法，再回来看这套拆分法，会顺很多。

可以直接复制的 prompt 模板

如果想让 AI 帮你出拆分的初稿，把下面这段请求文照搬就行。最后把 Obsidian 的笔记正文贴上去即可。

请把下面这段笔记，整理进 5 个格子。每个格子的上限必须严格遵守。

- 今天仍成立的事实：最多 3 条（只放验证过、且今天依然成立的）
- 已经定下的决定：最多 2 条（不再动摇的方针）
- 还不清楚的事：只写 1 条（这次想确认的那一件）
- 下一步：一句话（以动词收尾的具体动作）
- 验证方式：能说「做完了」的条件（跑测试、看显示效果等）

规则：
- 「也许……」「有……的可能」这类，不要放进事实，挪到「还不清楚的事」里去。
- 如果旧决定和新决定相互矛盾，采用新的那条，旧的直接删掉。
- 格子装不下的信息，不要硬留，直接删。

笔记正文：
（在这里贴上 Obsidian 的笔记）

关键是要明确写上「遵守上限」。不写这一句，AI 会出于好心想把所有东西都留下来。要在请求文里就告诉它：你的活儿是删，不是留。

可以直接运行的转换脚本

这段脚本，把拆分好的结果整理成可以直接贴进 Claude Code 第一条请求的格式。Node.js 18 及以上，无需额外安装就能跑。存成 shijisho.mjs，用 node shijisho.mjs 执行。

// 把拆进 5 个格子的笔记，转换成给 Claude Code 的工作指令文本
const note = {
  facts: [
    "手机端显示时 CTA 不换行、能完整放下",
    "Gumroad 的商品 URL 已替换成最新版",
    "访问量靠前的文章面向入门者的搜索意图",
  ],
  decisions: [
    "把免费 PDF 作为主引导",
    "只把卡在配置或权限上的读者，导向付费的配置指南",
  ],
  unknowns: [
    "哪个语言版本的 CTA 点击率最低",
  ],
  nextAction: "重写一段 CTA 文案，并确认发布后的 URL 能正常打开",
  checks: [
    "正文字数满足规定",
    "截一张手机端显示的截图",
    "确认发布页的 h1 和规范 URL 是否符合预期",
  ],
};

// 机械地检查是否超过上限（拆分的自我校验）
function validate(n) {
  const errors = [];
  if (n.facts.length > 3) errors.push("事实太多了（最多 3 条）");
  if (n.decisions.length > 2) errors.push("决定太多了（最多 2 条）");
  if (n.unknowns.length > 1) errors.push("未知太多了（只能 1 条）");
  if (!n.nextAction || !n.nextAction.trim()) errors.push("下一步是空的");
  return errors;
}

function toBrief(n) {
  return [
    "【今天的事实】" + n.facts.join(" / "),
    "【已定的决定】" + n.decisions.join(" / "),
    "【还不清楚】" + n.unknowns.join(" / "),
    "【下一步】" + n.nextAction,
    "【验证方式】" + n.checks.join(" / "),
  ].join("\n");
}

const errors = validate(note);
if (errors.length > 0) {
  console.error("拆分结果超过了上限：");
  errors.forEach((e) => console.error("  - " + e));
  process.exit(1);
}

console.log(toBrief(note));

加上 validate 是这段脚本的精髓。把事实写成了 4 条却没察觉就递了出去——这种我自己常犯的错，让机器替我挡掉。把输出的 5 行，原样贴进给 Claude Code 的第一条请求。不把所有旧点子都递过去，只递今天判断要用的事实——这套做法就这么被固定下来了。

三个按业务划分的用法

格子的含义不变，但里面装什么，会随工作而变。举三个例子。

1. 文章与内容运营 把热门文章的搜索意图、当前的引导去向、下一个想卖的教材分开。入门文章就先放免费 PDF，只把卡在配置上的读者导向付费的配置指南——把这写进「下一步」。这样每次的提议都不会跑偏。

2. 开发工作的交接 把已经复现的 bug 事实、近期的设计决定、还没查清的原因分开。如果在这里把原因的「假设」塞进事实那一格，AI 会朝错误的方向全力狂奔。原因还没确定，就毫不犹豫地放进「还不清楚的事」。

3. 导入咨询、会前准备 把客户的原话、已经定下的工作范围、下次要问的问题分开。在「下一步」里连咨询要产出的交付物都写上，你这边能拿出的提议就会具体起来。

常见的坑和修法

刚开始那阵子，我踩过的三个坑。连修法一起写下来。

第一个，把一整张长页面整块贴过去。信息量很大，判断却很稀薄。修法很简单：贴之前先削进五个格子。别递仓库，递工作台。

第二个，把决定和未确定的事混在一起。把「免费 PDF 可能不够吸引人」和「确定把免费 PDF 作为主引导」并排贴出去，AI 就会开始怀疑那条既定事项。「可能……」一律挪进「还不清楚的事」那一格。光这一下，翻炒就停了。

第三个，不写验证方式。只说一句「做完了告诉我」，AI 就会按它自己的标准说「做完了」。要像跑测试、看显示效果、检查死链那样，先把机器能判定的条件递给它。把「完成」的定义攥在人手里，这才是诀窍。

常见问题

问：除了 Obsidian，别的笔记软件也能用吗？ 答：能。无论是 Notion 还是苹果自带的备忘录，拆进五个格子的思路都一样。脚本只要能把文本取出来，不管里面装的是什么内容。

问：每次都花十分钟拆分，我没那么多时间。 答：不用对所有笔记都做。只把今天要递给 Claude Code 的那一条笔记拆好就够了。熟练之后三四分钟就能搞定。

问：拆分这件事，全部交给 AI 不行吗？ 答：出初稿这一步交给它没问题。但「这是事实」「这是决定」这种拍板的最终判断，得攥在人手里。这一步一撒手，开头那种翻炒事故就又回来了。

问：写进 CLAUDE.md，和每次都贴一份工作指令，有什么区别？ 答：不变的方针写进 CLAUDE.md，只在今天有效的事实和下一步写进工作指令，这样分。CLAUDE.md 的定位，Anthropic 官方文档里也有系统的说明。写法可以参考 CLAUDE.md 的写法 和 权限配置配方。

问：我想再提升 prompt 的精度。 答：进阶 prompt 组织法 里，整理了让请求文更稳定的具体招数。配合这套拆分法一起用，效果会出来。

我实际试过之后

开头那次翻炒事故之后，我把同一条笔记拆进五个格子，再递给 AI 试了一次。确认了两件事。

一是，怀疑决定的那种回复会不会消失。我只是把「确定把免费 PDF 作为主引导」用一行放进【已定的决定】那一格，AI 就以这条方针为前提开始干活，再没翻炒过。拆分实际花的时间，大概 4 分钟。

二是，validate 是不是真能挡掉错误。我故意写了 4 条事实去跑，结果不出所料，在「事实太多了」那里停住了。有了它，哪怕是刚睡醒迷糊的自己，也破不了上限。与其费心去想多聪明的指令文，不如手里攥着一个「递出去之前先删」的固定动作——结果反而是最快的。现在我是这么体会的。

如果想把这套做法推广到整个团队的工作改进，研修与咨询 能帮你把它落到实际运作里。