选型工具：从 Codex 到 Qoder，兜兜转转
最开始的想法很简单：搭一个本地笔记库。
要实现 Markdown 写作，图片用自己的图床嵌入，Agent 能像人一样检索和编辑笔记，而不是把所有东西向量化丢进黑盒。
为了这件事，我试了一圈工具，最后发现 Qoder 好像是个不错的选项。
试过的那些
Claude Code、Codex、Opencode 我都用过，它们都是纯工作台模式——没有编辑器，所有交互走聊天框。
一度我用 Codex 比较多，但两个问题慢慢浮现：
一是用 GPT 5.5 做笔记确实大材小用（贵且慢……）。其次，文本处理上我更习惯 DeepSeek 的风格（便宜还好用）。
这两件事单独看不算致命，但每天用的时候就会不舒服。
笔记工具这一路
Codex：聊天式笔记让我觉得自己在退化
纯工作台 Agent 让我和笔记的交互变成了聊天。偶尔我也会厌恶这种模式，一度觉得是在被 LLM 接管——古法编程这门手艺还是需要保留的……
Cherry Studio：笔记做得真好，但 Agent 太冗余
Cherry Studio 是我用过对 Markdown 支持最好的工具。代码块、图片、预览、排版，远超很多专业笔记软件。
但它的 AI 对话和笔记在两个不同的框里，算上 Agent 还有第三个……这就让强迫症的我很难受了。
而且它的 Agent 做得确实不太行。
Notion：Markdown 图片嵌入的硬伤
Notion 和类似的笔记工具，都不支持图片嵌入的 Markdown 写法（）。这意味着我没法用自己的图床。
最关键的是，它居然不报错，不报错，只是拒绝……一度我粘贴的时候怀疑是自己操作有问题。
不然 Notion CLI + 工作台的模式我还是比较能接受的。
遗憾放弃。
Qoderwork：太臃肿，模型也不透明
公司给了付费的 Qoder 和 Qoderwork 资源。一度我很喜欢 Qoderwork，但慢慢发现它太臃肿了，各种花里胡哨的东西。
更关键的是，即便是付费版本，模型也不支持自定义，只能选标准、高级、旗舰。不够透明，也不适合非工作场景使用。
最后落在 Qoder
好像没太久，Qoder Quest 模式变成了 Qoder Desktop。意外的是，它基本满足了我所有需求。
界面简约，但 Skills、MCP、Memory、Repo Wiki 都在，Agent 和编辑器集成又独立，一键就能切过去改，自定义模型按厂家开放、最高 1M 上下文，虽然没给标准 OpenAI 端点，但对我来说确实没啥影响。
Repo Wiki 的索引很好用，虽然免费版不支持，但可以自己写 skills 实现（参见 notes skills），所以问题不大。
最让我舒服的一点：它和编辑器是集成又独立的。可以完全当工作台用，也可以一键进入编辑器去改。有种回到用 VSCode 写博客的年代的感觉……我已经把默认编辑器从 VSCode 换成 Qoder 了。
最后分享下我的 Notes Skill
我放弃了 RAG 路线，改用人的 SOP 方式：建索引、查索引、读文件、改文件、更新索引。每步都可见，每步都可控。
目录结构
Skill 放在 .qoder/skills/notes/，两个文件：
.qoder/skills/notes/
├── SKILL.md
└── scripts/
└── rebuild_index.py
笔记根目录通过相对路径推导，不写死绝对路径：
SKILL_DIR = .qoder/skills/notes
NOTES = SKILL_DIR/../../..
笔记库的布局：
<NOTES>/
├── .qoder/skills/notes/
├── 技术笔记/
├── 项目文档/
├── 读书笔记/
└── INDEX.json
所有业务笔记都是 Markdown 文件，分类用子目录管理。
索引：INDEX.json
INDEX.json 是机器可读索引，记录每篇笔记的路径、分类、标题、摘要和更新时间。格式大概是：
{
"schema_version": 1,
"generated_at": "2026-06-28T20:00:00+08:00",
"root": ".",
"count": 42,
"notes": [
{
"path": "技术笔记/某篇笔记.md",
"category": "技术笔记",
"title": "某篇笔记的标题",
"summary": "正文第一段的前120个字符作为摘要",
"updated_at": "2026-06-28T19:00:00+08:00"
}
]
}
维护规则就一条：笔记增删改移之后，跑一次 rebuild_index.py 重建索引。脚本扫全库 Markdown 文件，自动跳过 .qoder 内部目录，提取每个文件的一级标题和首段摘要，写入 INDEX.json。
不再维护人工可读的 Markdown 索引。检索时先看 INDEX.json，定位到具体文件后再用 rg 搜正文细节。
重建索引脚本
rebuild_index.py 的核心逻辑大概 70 行，做了几件事：
- 从脚本自身路径向上查找笔记根目录（通过
.qoder/skills/notes/SKILL.md定位） - 递归扫描所有
.md文件，跳过.qoder内部文件和旧INDEX.md - 对每个文件提取一级标题作为标题、正文第一段前 120 字符作为摘要
- 取文件修改时间作为
updated_at - 按路径排序后写入
INDEX.json
def find_notes_root() -> Path:
here = Path(__file__).resolve()
for parent in here.parents:
if (parent / ".qoder" / "skills" / "notes" / "SKILL.md").exists():
return parent
raise RuntimeError("Cannot locate notes root")
def first_heading_and_summary(path: Path) -> tuple[str, str]:
title = path.stem
summary = ""
lines = path.read_text(encoding="utf-8").splitlines()
for line in lines:
text = line.strip()
if not text:
continue
if text.startswith("# "):
title = text[2:].strip() or title
continue
if text.startswith("#"):
continue
summary = text[:120]
break
return title, summary
搜索流程
Agent 搜索笔记时按这个顺序：
- 先重建索引确保最新
- 打印
INDEX.json看标题和摘要 - 用
rg在笔记正文中搜索关键词 - 汇报命中文件和简短片段
# 搜索正文
rg -n "<关键词>" "$NOTES" -g "*.md" -g "!.qoder/**"
# 按文件名搜索
find "$NOTES" -path "$NOTES/.qoder" -prune -o -iname "*<关键词>*" -print
创建和编辑笔记
创建笔记时，Skill 会：
- 优先归入已有分类子目录，没有合适分类时先确认再新建
- 文件顶部加一级标题
# <标题> - 创建后自动重建索引
追加内容时，按时间倒序插入，默认加日期戳如 ## 2026-06-28，保持标题层级一致。追加后重建索引。
修改笔记时，小改动做精确替换，大改动保留已有内容。涉及目录结构或正文摘要变化时重建索引。
为什么不用 RAG
RAG 的问题在于，它把检索变成一个黑盒。向量化之后，你不太清楚 Agent 到底看到了什么、没看到什么。
SOP 方式的好处是每一步都可见：
- 索引告诉你有哪些笔记、各自的标题和摘要
rg精确匹配关键词，告诉你命中了哪几行- 读文件时你看到完整上下文
- 编辑后重建索引，状态一致
每个环节都可以确认、纠正、回退。对于个人笔记库这种规模不大但需要精确操作的场景，可控性比召回率更重要。
