把 Obsidian 笔记改写成 Claude Code 今天就能实现的任务请求

周五晚上，我在 Obsidian 里只留了一句：「注册引导好像太弱了，很多人得往下滚才会注意到免费 PDF 的链接。」周一早上，我把这整条笔记原样贴给 Claude Code，说「帮我改一下」，结果它回了我整整两屏的「现状梳理」。代码一行都没写。

笔记本身没问题，问题是我把笔记原封不动地丢了过去。那天我光是听它复述背景，就烧掉了 30 分钟。

Obsidian 里明明攒了一堆想法，可每次我都在给 Claude Code 重写同样的开场白。如果你也有同感，那你缺的不是更聪明的 AI，而是一个把笔记削成「任务请求」的固定套路。

本文要点

• 把 Obsidian 笔记原样贴过去，Claude Code 就会变成做总结的，实现进度被拖慢。要交给它的不是全文，而是今天能做完的那一个任务。
• 从笔记里只抽 6 样东西：目的、禁改区域、第一步、验收方式、引导去向、回滚方式。
• 先写好「要读的范围」和「不许碰的范围」，那种顺手改到支付或登录的事故就消失了。
• 把任务请求做成模板存回 Obsidian，下次就不用再从头写一遍开场白。
• 别只信它的完成报告，要用截图、构建结果这类可以亲眼看的材料来判断。

为什么不能把笔记整条丢过去

Obsidian 里的笔记是写给未来自己的信，背景和犹豫全都写在里面。正因如此，丢给 AI 时它会努力「把全部读完、彻底理解」。

换成人类同事，他读完一长段会自己删减：「说白了就是引导链接的位置问题嘛。」Claude Code 没那么会察言观色，你给的字数越多，它就回越细致的总结。它很贴心，可我要的不是总结。

所以在交出去之前，先由人来削。把 1000 字的笔记，只留下实现真正需要的那 30 字。这个「删」的动作，恰恰是省掉每次开场白的捷径。

想把笔记整理本身也交给 Claude Code 的人，建议先读一遍与 Obsidian 联动的基础，这篇的步骤会更容易接得上。

从笔记里抽出的 6 个字段

我每次从笔记里取出来的，就下面 6 样。笔记里这 6 样没凑齐也没关系，缺的那栏在削的时候自己定。

字段	内容	例子
目的	用户能得到的结果，一句话	访客在往下滚之前就注意到免费 PDF 的链接
禁改区域	不想弄坏的地方	支付处理、登录、手机端排版
第一步	从哪儿下手	在首页第一屏加一个版块
验收方式	判断「做完了」的材料	构建通过、改动的 diff、线上 URL 的样子
引导去向	把读者接着送到哪	免费 PDF 的注册页
回滚方式	失败时的退路	把这一个提交撤掉就行

重点在「禁改区域」。这栏要是空着，它很可能在修引导链接时顺手「帮你把支付那块也整理了一下」。先把禁区划出来，是最管用的一招。

交给 AI 的范围，和人来定的范围

这俩混在一起就要出事，得把界线划清楚。

• 人来定：目的、禁改区域、回滚方式。这些是业务判断，不能甩给 AI。
• 交给 AI：把第一步具体化、写实现代码、跑验收命令。
• 人最后过目：线上 URL 的样子，以及 diff 是不是和预想一致。就这一步必须亲眼看。

能交给它的是「怎么做」，而不是「要守住什么」。决定守住什么的，永远是人这一边。

把笔记变成任务请求的提示词模板

把抽出来的 6 个字段，整理成能直接交给 Claude Code 的形式。复制下面的模板，最后把笔记贴进去就行。

请把下面这条 Obsidian 笔记，转换成你今天就能实现的一条任务请求。
输出请分成以下 6 个小标题。现在先不要写代码。

- 目的（用户能得到的结果，一句话）
- 禁改区域（不许改动的地方）
- 第一步（最小的一处改动）
- 验收方式（构建、diff、线上 URL 等）
- 引导去向（把读者接着送到哪）
- 回滚方式（失败时恢复原状的步骤）

【笔记】
（把 Obsidian 的笔记贴在这里）

最关键的是最后一句：「现在先不要写代码」。没有这句，Claude Code 会一口气把转换和实现都做了，把禁改区域的确认整个跳过去。先让它出一版任务请求，由人确认过禁区，再回一句「那就按这个请求来实现」。这个两段式能少出很多事故。

想把模板打磨得更精准的人，我在Claude Code 提示词设计进阶里整理了更细的措辞技巧。

可复制运行的转换脚本

如果嫌每次手搓提示词太麻烦，那就把笔记写成一个对象，让脚本自动生成任务请求。有 Node.js 就能直接跑。

// 把笔记转成「今天就能实现的任务请求」的最小脚本
// 用法: node note-to-issue.mjs

const note = {
  目的: "访客在往下滚之前就注意到免费 PDF 的链接",
  禁改区域: ["支付处理", "登录", "手机端排版"],
  第一步: "在首页第一屏加一个公告版块",
  验收方式: ["构建通过", "改动的 diff", "线上 URL 的样子"],
  引导去向: "免费 PDF 的注册页",
  回滚方式: "把这一个提交撤掉就能恢复原状",
};

function toIssuePrompt(n) {
  // 必填字段缺了，要在生成任务请求之前就发现
  const required = ["目的", "禁改区域", "第一步", "验收方式"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`任务请求缺少必填字段: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("目的", n.目的),
    line("禁改区域", n.禁改区域),
    line("第一步", n.第一步),
    line("验收方式", n.验收方式),
    line("引导去向", n.引导去向),
    line("回滚方式", n.回滚方式),
    "现在先不要写代码，只在这个范围内返回最小的实现计划。",
  ].join("\n");
}

console.log(toIssuePrompt(note));

跑起来会输出 6 行加最后一句的任务请求。把 禁改区域 改成空数组再跑一遍，它会在生成请求之前就报「缺少字段」并停下。这是用代码这一侧，提前拦住「空着栏位就丢出去」那类事故的机制。

三个真正用得上的场景

1. 引导链接的改进笔记 「免费 PDF 的链接太弱」这条笔记原样贴过去，回来的是没完没了的改进方案说明。削成任务请求后，第一步 就被收窄成「在第一屏加一个版块」这一点，支付那块根本不让它碰。改之前和之后的样子在线上 URL 上对照着看，效果就能用眼睛判断，而不是凭感觉。

2. Bug 排查的笔记 「登录后偶尔会白屏」这条笔记信息太多。任务请求里把 第一步 收窄成「先只共享复现条件和错误日志」。别让它一口气把查因和修复都做了，先逼它专注于复现，就能避开那种南辕北辙的乱改。

3. 文章选题的笔记 「下一篇文章，内部链接要好好埋」这种含糊的笔记，只要把 目的 削成「固定埋两条指向相关文章的内部链接」，就变成可实现的了。验收方式设成「构建通过」，发布前就能拦住链接失效。把文章相关的活儿交出去之前，先在写给非工程师的 Claude Code 入门里练一遍手会更稳。

把任务请求当模板留下来

做过一次的任务请求别用完就扔，存回 Obsidian。下次再来类似的笔记，这 6 个小标题能整套复用。

我专门建了一条叫 templates/issue-prompt.md 的笔记，里面放着 6 个小标题的空模板。新笔记一来，复制这个模板填进去就行，每次写开场白的时间就这么没了。

更进一步，把 Claude Code 该读的规则本身固定在项目里，任务请求还能更短。项目里大家共用的约定，统一收进CLAUDE.md 的写法，任务请求那侧就不用每次重复了。

容易踩的坑和修法

把我最初那阵子搞砸的几次，连修法一起列出来。

• 整条贴全文：Claude Code 变成做总结的。修法是贴之前先削成 6 个字段。削不动的笔记，说明它还没固定成一个任务，先自己写一句结论。
• 不写禁改区域：被顺手扩散到支付或认证。修法是不许空着，也别写「无」。养成至少列出一个禁区的习惯。
• 验收方式写成「能跑就行」：只能去信它的完成报告。修法是构建结果、diff、线上 URL 里至少指定一个。
• 让它一口气全做完：转换和实现混在一起，禁区确认被跳过。修法是务必加上「现在先不要写代码」，确认过任务请求再让它实现。

这些坑全都是「事先定下一行就能防住」的那种。

常见问题

Q. 笔记很零碎，6 个字段填不满怎么办？ 不用全填满。最起码把「目的」和「禁改区域」定下来，就能成一条任务请求。剩下的等请求出来之后，看着 Claude Code 的建议再补也来得及。

Q. 一定要做让 Claude Code 直接读 Obsidian 笔记的联动吗？ 一开始不需要。手动复制笔记贴进模板就足够顶用了。等到同样的活儿反复做很多遍之后，再考虑自动联动也不晚。

Q. 写了「现在先不要写代码」，它还是开始实现了。 在项目的 CLAUDE.md 里写明「转换任务请求时不写代码」会稳很多。比起单次提示词里的一句指示，项目里共用的规则更容易被遵守。

Q. 任务请求多长比较合适？ 我以 6 个小标题合计 10 行上下为准。超过这个长度，就是一个任务里混进了好几个目的的信号，把任务拆开。

Q. 验收方式里该放什么我拿不准。 拿不准就先用「构建通过」和「线上 URL 的样子」这两个起步。光这两个，就能让你从「把完成报告照单全收」的状态里脱身。

我自己实测的结果

开头那条引导链接的笔记，我用这套 6 字段模板削过之后又交给了 Claude Code 一次。这回它没回总结，最先给出的是「在第一屏加一个公告版块」这样的实现计划。我列进禁改区域的支付处理，它一点都没碰。

校验脚本那边，我故意把 禁改区域 留空跑了一遍，它在生成任务请求之前就以「缺少字段」停住了。我确认了：那个最常见的「空着就丢出去」的事故，能在运行前被拦下来。

比起每次绞尽脑汁想出聪明的指令，手里有一个削笔记的固定套路要快得多——这是我现在的真实感受。想把同一套做法推广到团队的文章生产和咨询应对上的人，可以在面向业务的研修与咨询里，按你实际的运作把套路搭出来。官方的判断基准可以在 Anthropic 官方文档里查到。