research-note

研究笔记工作流

当用户提供一个需要整理成研究笔记的粗略问题时，请严格按照以下步骤操作。

步骤 0：检查烹饪指南例外情况

关于烹饪或烘焙的指南笔记不是研究笔记。

改用 [[recipe-cleanup]] 格式：YAML frontmatter 中包含 tags: recipe，食材使用带有 wikilink 的已勾选复选框，包含 Prep 部分，说明则写成普通段落，每段以小写字母开头、不带句末句号，并且每个句子单独成段。

如果没有外部来源，则省略 creator、pic 和 source 字段。

这种情况下，不适用其余步骤。

步骤 1：整理问题

重写问题，使其清晰、准确且足够完整，可以复制粘贴到任何大模型中。

规则：

• 删除对先前对话或其他模型无法获知的上下文的引用——将必要的背景直接补充到问题中
• 消除歧义——选择最可能的理解方式，或调整问题结构
• 修正语法、拼写和标点
• 使用直白、简洁的语言——删去填充词
• 问题中的每个句子单独成段，段落之间空一行
• 明确范围——将过于宽泛、无法有效回答的问题缩小，将过于狭窄、无法独立成立的问题拓宽
• 问题包含多个部分时，清楚地区分各部分
• 此步骤中不要回答问题

保留促成这个问题的背景，而不要将问题简化为抽象问题。

保留具名示例、具体工具、拟定的工作流和已说明的限制条件。

目标是清晰且易于迁移，而不是以牺牲具体细节为代价追求简短，因为这些细节能让笔记在数月后仍然有用。

这些重写规则也复制在问题整理命令 /Users/mtm/.claude/commands/question-cleanup.md 中，该文件由 chezmoi 模板命令 question-cleanup 生成。此技能保留自己的副本，因为它会安装到没有该命令目录副本的机器上。请同步修改这两处。

步骤 2：统计不同的问题

如果输入包含多个可以独立回答的问题，请将其拆分——每个问题一个文件。

如果两个问题涉及主题的不同方面，且无需参考对方也能回答，则它们属于不同的问题。

步骤 3：通过重命名源文件来命名文件

请将源文件重命名为描述性目标名称，而不是创建新文件并删除旧文件。

重命名可将源文件视为正在完善的同一份内容，并保留已纳入 git 跟踪的文件的历史记录。

对于已纳入 git 跟踪的文件，使用 git mv "Untitled NNNN.md" "descriptive name.md"；对于未跟踪的文件，使用 mv，然后直接在重命名后的文件中写入笔记内容。

文件名规则：

• 全部使用小写字母
• 单词之间用空格分隔，不用连字符或下划线
• 具体描述问题
• 扩展名为 .md

示例：lamination fold what builds strength.md

如果步骤 2 生成了多篇笔记，只能将其中一篇作为重命名后的源文件；其余笔记需创建为新文件，并参见步骤 9。

步骤 4：编写文件

结构：

1. YAML frontmatter，包含 tags: [voice-memo-research]
2. 上下文块（如果源文件包含 Obsidian wikilink）——在问题文本前原样保留所有 [[wikilinks]]
3. 整理后的问题——不加标签、不加标题，只写问题文本
4. 如果提供了 URL，则添加 ## Source 部分
5. 如果笔记最终包含多个主题部分，则添加 ## Short answer 部分
6. 每个主题各设一个 ## 部分，每个部分都包含对应的答案和搜索链接
7. ## Original request 部分

格式规则：

• 每个句子单独成段，段落之间空一行
• 文件中不使用斜体、粗体或任何强调格式
• 所有列表都使用项目符号
• 文件末尾保留一个换行符

Frontmatter 格式：

---
tags:
  - voice-memo-research
---

步骤 5：编写来源部分

记录用户遇到该主题时所在页面的网址——也就是他们当时正在阅读的文章、新闻简报或页面，而不是项目自己的主页或源代码仓库。

这样做是为了能返回原始上下文并重新阅读。

只有在请求中没有提供网址时，才跳过此部分。

步骤 6：每个主题各写一个部分

为每个不同的角度或子主题单独设立一个 ## 部分，并以该角度命名。

部分名称示例：## 利益冲突、## 成本比较、## 替代方案、## 在线舆论。

在相应部分中撰写该角度的答案，每句话单独成段。

答案基于你所能做出的最佳理解——搜索链接供用户核实并进一步探究。

将该角度的搜索链接放在其所在部分的底部。

切勿把所有链接集中到笔记末尾的单个 ## 搜索链接 部分中。

按部分提供链接，便于日后扩展任何一个部分，而无需新建一份链接回此笔记的文档。

如果笔记确实只涉及一个角度，那么只设一个部分即可。

该部分本身就是答案，因此采用这种结构的笔记无需在其上方添加其他内容。

步骤 6a：多部分笔记以简短答案开篇

写完各主题部分后，统计其数量。

如果多于一个，就在问题下方、各部分上方添加一个 ## 简短答案 部分。

否则，读者必须读完六个部分才能知道答案，这与笔记的用途背道而驰。

以一句话概述结论开篇；如果结论与问题本身的假设相矛盾，也要包含这一点。

然后，每个主题部分各用一个项目符号概述其结论，并注明结论来自哪个部分，让该项目符号同时指向论据所在的位置。

最后说明实际影响，以及任何会影响读者对其余内容信任程度的注意事项。

篇幅应控制在读者无需滚动就能看完的程度。

简短答案部分不应包含自己的搜索链接，因为其中的每项主张都属于下方已有搜索链接的某个部分。

其中不得引入下方各部分未证实的事实，因为简短答案是笔记的入口，而不是放置调查结果的地方。

步骤 7：设置搜索链接格式

每个部分添加 4–6 个 Google 搜索链接，并以项目符号列表呈现。

每个链接都应从不同角度切入该部分的主题。

每个条目都必须是可点击的 Markdown 链接，不能是裸网址。

每个项目符号的格式为 - [描述性链接文本](https://www.google.com/search?q=search+terms+separated+by+plus+signs)。

链接文本应描述预期会看到哪类结果，不能直接写网址。

网址中的搜索词以加号分隔。

这是对通用知识库规范的刻意例外；该规范要求将网址单独裸写一行，以便 Obsidian 自动识别链接。

示例：

## Swallowing and coughing

- [clinical term for coughing triggered by swallowing](https://www.google.com/search?q=coughing+while+eating+medical+term+oropharyngeal+dysphagia)
- [how penetration and aspiration differ](https://www.google.com/search?q=laryngeal+penetration+vs+aspiration+difference)

完成文件前，重新检查每个部分中的链接，并确认每个项目符号都采用方括号和圆括号的形式。

步骤 8：撰写「原始请求」部分

在笔记末尾追加一个 ## Original request 部分，其中包含源文件的原始内容，不作任何改动。

不要丢弃源文件中的任何文本，即使它看起来像多余的维基链接、复制的内容或应用自动生成的消息。

用户可能有意收集这些内容，作为上下文或原始材料，即使它看起来不像一个完整的问题。

逐字保留的是文字，而不是换行，因此请按照用户每句话单独成段的风格排版：

• 每个词都要原样保留，不要修改语法、改写或删减
• 每句话结束后另起一段，并以空行分隔
• 维基链接、URL 和粘贴的文本块等非正文行保持原样

保留此部分是为了让用户能够将整理后的问题与他们实际提出的问题进行比较；只有文字未经改动，这种比较才有意义。

口述的源内容通常是一大段文字，照搬其中的换行也会造成一堵文字墙。

之前：

One question I have is: why would I need RAG if I have Claude Code? When I ask it questions it seems to do the same thing. Let's make a new document for this.

之后：

One question I have is: why would I need RAG if I have Claude Code?

When I ask it questions it seems to do the same thing.

Let's make a new document for this.

步骤 9：仅在拆分时删除源文件

单篇研究笔记无需删除源文件，因为步骤 3 已将源文件重命名为笔记。

步骤 2 将输入拆分到多篇笔记时，源文件无法重命名为所有笔记，因此请在提交所有输出文件后将其删除。

删除前不要询问用户。

删除后立即提交，再继续操作。

步骤 10：提交

创建或更新每个文件后，立即将其提交到 git。

每次单独提交一个文件，以便可以逐个还原更改。

提交信息应简短，并使用祈使句。

提交前不要询问用户。

步骤 11：处理后续问题

在研究对话中，只要用户提出问题，就在当前笔记中新增一个以该问题为标题的 ## 标题，并在下方正文中写入答案。

立即执行，不要询问是否要更新笔记。

使用标题而不是单独的段落，可以为问题留出空间，以便稍后补充更多上下文。

每次添加后都按照步骤 10 提交。

用户指出遗漏了问题或子问题时，也同样应将其添加到适当的文件并提交，不要询问。

新增内容可能会使笔记从一个主题部分变为两个，因此新增后请重新检查数量，并应用步骤 6a。

如果笔记已有 ## Short answer，请为新增部分添加一个项目符号，而不要让该部分继续描述已经扩展的笔记。