把 Obsidian 笔记变成 Claude Code 实现 brief

如果 Obsidian vault 里明明有答案，但每次打开 Claude Code 还要重复解释，问题通常不在笔记，而在交接格式。

这篇文章建立一个 Claude Code issue brief 模板。不要贴整篇长笔记，只传事实、决定、未知点、下一步和验证要求。

相关阅读: claude-code-obsidian-integration, claude-code-claude-md-templates, claude-code-session-handoff-template. 官方安装基线见 Anthropic Claude Code getting started.

为什么要放在第一条命令之前

这个主题的核心是 把 Obsidian 知识转成实现 brief。Claude Code 可以很快行动，但如果第一份输入太宽，低价值 diff、过期假设、和收入无关的格式整理，都会和真正重要的工作混在一起。

对笔记很多但 Claude Code 交接很重的人来说，重点不是把任务说得很大，而是先写清读什么、不碰什么、先试什么、失败后回到哪里。内容运营和产品开发都需要这层边界。

实际工作流程

1. 把笔记拆成事实、决定、未知点和下一步
2. 旧假设不要放进实现 brief
3. 内容修改时写清 CTA 和商品路由决定
4. 最后要求 build 和移动端截图作为证据

按这个顺序，给 Claude Code 的请求会从“自由发挥”变成“在这个边界内工作，并留下证据”。它仍然可以推理，但危险区域会在第一次编辑前先关上。

场景	安全做法	需要留下的证据
文章改善	只传搜索意图和 CTA 方针，避免全文重写	build, diff, URL
修 bug	把已复现事实和未确认原因分开	build, diff, URL
咨询准备	把客户笔记转成范围、禁止区域和下次问题	build, diff, URL

有了这些证据，就不是听 Claude Code 说完成，而是看工作结果是否成立。

可复制的提示词和代码

把这份 Obsidian 笔记转换成 Claude Code 实现 brief。分为事实、决定、未知点、下一步、禁止区域和证据。过期假设单独列出，不要混进实现指令。

const note = {
  title: "Checkout CTA wraps on mobile",
  facts: ["375px screenshot shows two-line button", "Gumroad URL is correct"],
  decision: "keep free PDF before paid guide",
  unknowns: ["which component owns the button spacing"],
  nextAction: "find component, make smallest CSS change, verify mobile",
};

function toClaudeBrief(item) {
  return [
    `Goal: ${item.nextAction}`,
    `Facts: ${item.facts.join("; ")}`,
    `Decision: ${item.decision}`,
    `Do not assume: ${item.unknowns.join("; ")}`,
    "Proof: build plus mobile screenshot",
  ].join("\n");
}

console.log(toClaudeBrief(note));

这段代码只是小型检查。真实项目里，可以把输出贴进 CLAUDE.md、issue 或 handoff note，让下一次会话复用同一份判断。

真实例子和失败场景

场景	安全做法	需要留下的证据
文章改善	只传搜索意图和 CTA 方针，避免全文重写	build, diff, URL
修 bug	把已复现事实和未确认原因分开	build, diff, URL
咨询准备	把客户笔记转成范围、禁止区域和下次问题	build, diff, URL

• 贴整个 vault 会混合旧决定和当前限制。
• 只贴决定会让 Claude Code 不懂背后的理由。
• 不写 CTA 方针，文案可能变好但收入路径变弱。

这些失败的共同点，不是 Claude Code 能力不够，而是输入边界太薄。边界薄时，AI 会出于好心把任务扩大。对有收入导线的文章来说，免费 PDF、Gumroad、咨询之间的选择也是边界的一部分。

实际使用时，还要写清“最后由谁确认”。把 Obsidian 知识转成实现 brief 不只是给 Claude Code 的备注，也是给明天的自己、审查同事、或咨询对象看的记录。尤其修改文章和商品导线时，不只判断文字是否自然，还要写清读者处在哪个阶段：命令还不熟就推免费 PDF，已经反复做同类工作就推 Gumroad，需要团队或生产环境判断时再推咨询。这样 CTA 不会因为当天感觉不同而漂移。

另一个技巧是把第一次完成条件压小。一次要求大改进时，Claude Code 会为了帮忙而扩展范围。先限制到一个 slug、一个 component、一个 command，等 build 和截图都通过后再进入下一步。这样速度不会明显变慢，但事故后的回滚成本会低很多。

把读者引向免费 PDF、Gumroad 和咨询

如果读者还不熟悉基本命令，先用 免费速查表 固定日常习惯。卡在安装、权限、CLAUDE.md、MCP 或 CI 时，下一步适合购买 Setup Guide。如果反复重写 review、debug、refactor 提示词，推荐 50 Prompt Templates。如果涉及团队导入或收入路径设计，就进入 咨询。教材比较可以从 products 开始。

CTA 不必只放在文末。开头附近适合免费 PDF，实作例子之后适合 Gumroad 教材，谈到团队或生产风险时，咨询才是自然的下一步。

发布后要看的数字

接下来观察 Obsidian 相关文章到 Prompt Templates 和 Setup Guide 的点击。

发布后不要只看 PV，还要分开看正文开头阅读、内部链接点击、免费 PDF 注册、Gumroad 点击和咨询页访问。HTTP 200 本身不是成功。h1、canonical、heroImage、CTA 和本地化正文都要指向同一个下一步。