Claude Code Obsidian to Issue Prompt：把笔记变成一个可交付任务

好的 Obsidian 笔记不等于好的 Claude Code 请求。如果直接贴全文，session 很容易变成总结工作，而不是实现工作。

这篇文章把一条笔记转换成一个 issue prompt。先抽取用户结果、限制、保护区域、证明和 CTA 路径，再让 Claude Code 编辑。

相关阅读: claude-code-obsidian-integration, claude-code-obsidian-claude-md-bridge, claude-code-claude-md-templates. 官方文档基线: Anthropic Claude Code docs.

为什么要在第一条命令前决定

把大量上下文压缩成一个有证据的可实现任务

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

笔记很有用，但每次都要向 Claude Code 重讲背景的人

实际工作流程

1. 只选择一条相关笔记
2. 用一句话写出用户结果
3. 列出保护区域和失败条件
4. 选择 build、截图、公开URL 或数据证明
5. 把 issue prompt 保存给下次使用

场景	交给 Claude Code 的工作	人工确认的证据
CTA 笔记	只改一个免费PDF区块	build, diff, URL
Bug 笔记	先传复现步骤和日志	build, diff, URL
文章想法	固定 Gumroad 路径需要的内部链接	build, diff, URL

有了这些证据，Claude Code 的结果就能用可观察的工作来判断，而不是只看一段自信的总结。

可复制的提示词和代码

请把这条 Obsidian 笔记转换成一个可实现的 Claude Code issue prompt。分为 Goal、Do not touch、First edit、Proof required、CTA path、Rollback note。暂时不要实现。

const note = {
  title: "Signup CTA feedback",
  userOutcome: "More visitors start the free PDF",
  constraints: ["Do not touch payments", "Keep mobile layout stable"],
  proof: ["npm.cmd run build", "public URL screenshot"]
};

function toIssuePrompt(n) {
  return [
    `Goal: ${n.userOutcome}`,
    `Do not touch: ${n.constraints.join(", ")}`,
    `Proof required: ${n.proof.join(" + ")}`,
    "Return one small implementation plan before editing."
  ].join("\n");
}

console.log(toIssuePrompt(note));

真实例子和失败模式

场景	交给 Claude Code 的工作	人工确认的证据
CTA 笔记	只改一个免费PDF区块	build, diff, URL
Bug 笔记	先传复现步骤和日志	build, diff, URL
文章想法	固定 Gumroad 路径需要的内部链接	build, diff, URL

• 贴完整笔记会让 Claude Code 变成总结器，延迟真正修改。
• 没有限制时，支付、认证或部署文件可能被误触。
• 没有证据时，只能相信完成说明。

关键是不要把第一条请求写得太大。先写清阅读范围、禁止触碰的区域、第一步动作和验证命令，Claude Code 就不容易把任务扩展到无关修改。

把证据包留下来

把大量上下文压缩成一个有证据的可实现任务 如果只停留在一次聊天里，价值会很快消失。更好的做法是保存成证据包：原始请求、Claude Code 阅读的文件、没有触碰的区域、执行的命令、公开URL或截图，以及仍然不确定的判断。下一次 session 就能复用同一套判断，而不是重新解释背景。

对笔记很有用，但每次都要向 Claude Code 重讲背景的人来说，第一天不需要完整的团队制度。先在一个 PR、一条笔记或一次部署上使用这个流程。失败时，把失败原因写回 checklist，再用更小的版本重试。只有在 build、diff、URL、CTA、rollback 证据都可见之后，才扩大 Claude Code 的访问范围。证据不足时扩大权限，看似更快，实际会把验证成本留给后面的人工 review。

收入路径也遵循同样原则。读者还卡在基础命令时，免费PDF是下一步。读者每周重复同类 prompt 时，Gumroad 教材更合适。读者要做团队或生产判断时，咨询更合适。文章不是把所有人都推去购买，而是只把需要 把 Obsidian 笔记变成可交付 issue prompt 的读者送到付费教材，其余读者回到免费PDF和相关文章。

还要留下一个判断分支。Claude Code 的建议是直接采用、缩小范围，还是先补一个验证步骤，都用一句话写下来。PR 评审可以写「没有 P0，P1 是移动端破版，P2 是测试缺口」。Obsidian 到 issue 可以写「没有使用整篇笔记，只采用 CTA 改善」。deploy dry run 可以写「preview URL 正确，但 rollback owner 未设置，所以暂不生产部署」。

有了这句话，下一次选择 CTA 也更清楚。基础命令不熟的人去免费PDF，反复做同类工作的人去 Gumroad，卡在责任边界或生产权限的人去咨询。把 Obsidian 笔记变成可交付 issue prompt 对应的是已经可以自学、但需要带走一个稳定模板的读者。

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

如果基本命令还不稳定，先用 免费速查表 固定日常习惯。想深入 把 Obsidian 笔记变成可交付 issue prompt，请看 Gumroad 教材。如果需要团队导入、评审规则或收入路径设计，请进入 咨询；产品比较从 products 开始。

CTA 不应该只放在文章底部。开头适合免费PDF，实作例子之后适合 Gumroad 教材，涉及团队导入或生产风险时，咨询就是自然的下一步。

发布后要看的数字

发布后观察 Obsidian 文章到 Prompt Templates、Setup Guide 和咨询页的流动。

不要只看 PV。要分开看正文开头阅读、内部链接、免费PDF注册、Gumroad 点击和咨询页访问。HTTP 200、h1、canonical、heroImage、CTA 和本地化正文都必须指向同一个 slug。