1. 截图吃灰这件事，到底卡在哪一步
多平台爆款选题采集这件事，我观察下来最大的问题不是「找不到素材」，而是素材进来之后没有出口。你在刷小红书、公众号、X、知乎的时候，看到一句戳中你的话，第一反应是截图。一天下来相册里躺着十几张图，一周下来上百张。然后呢？然后就没有然后了。
这些截图本质上是一堆非结构化信息。它们没有标题、没有标签、没有上下文，检索的时候只能靠翻相册的时间线。你想找「上周看到的那条关于时间管理的观点」，得从几百张图里一张张划过去。这个成本高到大多数人直接放弃，于是截图就变成了心理安慰——「我存过了，等于我学过了」。
真正要解决的是三件事：统一入口、自动结构化、可检索。统一入口解决「散落」的问题，自动结构化解决「手动整理低效」的问题，可检索解决「存了用不上」的问题。这三件事里，最耗人的是第二件。一张截图你要手动提炼观点、归类主题、写成选题，一张图三分钟，一百张图就是五小时。没人能坚持。
所以思路很明确：把「提炼 + 归类 + 生成选题」这段交给多模态模型来做，人只负责最关键的判断——这张图值不值得进库，以及它对你意味着什么。Obsidian 负责当容器和检索层，codex 这类 AI 编程助手负责当加工引擎，中间用统一的 API 通道把模型调用接起来。这样一次配置之后，你丢图进 Inbox，剩下的批量产出。
适合谁？适合已经在做内容、每天要产出选题、又不想被素材整理拖死的人。如果你还没开始做内容，这套流程也能帮你把「输入」变成「可用的输出」，而不是让灵感烂在相册里。
下面我按「库结构 → 前置准备 → 配置片段 → 验证动作 → 排错」的顺序拆开讲，每一步都能直接抄。
2. 前置准备：Obsidian 库结构与 TaoToken 通道配置
先说库结构。这一步决定了后面 AI 往哪儿写文件，结构乱了 AI 也会跟着乱。我的建议是极简四层，不要搞复杂分类，分类越细你越不想维护。
00 Inbox/ # 所有新截图、新灵感的第一站，不做任何分类 01 Notes/ # 提炼后的底层逻辑、个人观点 02 Topics/ # 可产出的选题条目 03 Outputs/ # 已成稿的草稿 assets/ # 图片附件统一放这里核心逻辑是流水线：素材从 Inbox 流向 Notes，再流向 Topics，最后到 Outputs。收集阶段绝对不要纠结分类，先让它进系统。你在 Inbox 里放一张图，图下方手动补两句话：
- Idea：这张图给你的即时启发是什么。比如「长期目标不一定靠更久的耐心，也可以靠压缩时间倒逼行动」。
- Output：它能变成什么。比如「可以写一篇：如何用 6 个月完成你的 10 年计划」。
这两句话是人脑和 AI 协作的桥梁。截图是客观信息，Idea 是你的主观态度，Output 是行动导向。没有这两句，AI 只能无中生有，产出会很空。
接下来是通道。codex 这类 AI 编程助手支持多种接入方式，用 API 方式接入的好处是你可以自由切换模型、统一管理额度。这里我用 TaoToken 作为 OpenAI 兼容的 API 通道来演示，它的 Base URL 是https://taotoken.net/api，兼容 OpenAI 的/v1/chat/completions协议，多模态模型可以直接传图。
你需要准备三样东西：Base URL、API Key、Model ID。这三件套在后面的配置文件里会反复出现，缺一不可。
获取 Key 的路径：进控制台 → API Keys 页面创建令牌。创建时如果对额度不确定，先留空用默认。复制出来的 Key 只显示一次，记得存好。
模型选择上，做 OCR 和多模态理解必须选支持 Vision 的模型。你在模型列表里搜vision或者直接看多模态标记，选一个能读图的。纯文本模型传图进去会直接报错，这是后面排错章节要重点讲的坑。
注意：Base URL 填
https://taotoken.net/api，不要自己加多余的斜杠，也不要填成网页地址。协议路径由客户端自动拼接，填错会 404 或 401。
到这里前置就齐了：库结构建好，Key 拿到，模型选好。下面进配置。
3. 可复制配置：codex 接入与 Obsidian 插件 settings 片段
这一节是全文最需要照抄的部分。我分两块给：一块是 codex 侧的接入配置，一块是 Obsidian 侧调用脚本的 settings。
3.1 codex 侧接入配置
codex 支持通过配置文件指定 API 通道。找到你的 codex 配置目录（通常在用户目录下的.codex/），编辑config.toml。下面这段可以直接抄，把 Key 换成你自己的：
# ~/.codex/config.toml model = "gpt-4o" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"然后在环境变量里放 Key，别把 Key 硬编码进配置文件：
# macOS / Linux，写进 ~/.zshrc 或 ~/.bashrc export TAOTOKEN_API_KEY="sk-你的Key"# Windows PowerShell $env:TAOTOKEN_API_KEY="sk-你的Key"如果你用的是 Codex 的auth.json方式管理凭据，结构是这样的，注意字段名要和客户端版本对齐：
{ "OPENAI_API_KEY": "sk-你的Key", "OPENAI_BASE_URL": "https://taotoken.net/api" }三件套对照一下，别填串：
| 配置项 | 值 | 说明 |
|---|---|---|
| Base URL | https://taotoken.net/api | 统一通道入口，不加 UTM |
| API Key | sk-... | 控制台 API Keys 页创建 |
| Model ID | 如gpt-4o | 必须选支持 Vision 的多模态模型 |
3.2 Obsidian 侧 settings 片段
Obsidian 本身不直接调 API，你需要一个能跑脚本的插件（比如 Templater + Shell commands，或者 QuickAdd 的 macro）。核心是把「读图 → 调模型 → 写文件」串起来。下面是一个 Node 脚本的配置片段，放在库根目录的scripts/下：
// scripts/process-inbox.mjs import fs from "fs"; import path from "path"; const CONFIG = { baseUrl: "https://taotoken.net/api/v1/chat/completions", apiKey: process.env.TAOTOKEN_API_KEY, model: "gpt-4o", // 必须是多模态模型 inboxDir: "00 Inbox", notesDir: "01 Notes", topicsDir: "02 Topics", }; async function imageToBase64(filePath) { const buf = fs.readFileSync(filePath); return buf.toString("base64"); } async function analyzeImage(base64, idea, output) { const res = await fetch(CONFIG.baseUrl, { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${CONFIG.apiKey}`, }, body: JSON.stringify({ model: CONFIG.model, messages: [ { role: "user", content: [ { type: "text", text: `这是我的启发：${idea}\n预期用途：${output}\n请提炼一条笔记和一条选题。` }, { type: "image_url", image_url: { url: `data:image/png;base64,${base64}` }, }, ], }, ], }), }); const data = await res.json(); return data.choices[0].message.content; }这段脚本的关键点：baseUrl指向 TaoToken 的/v1/chat/completions，model必须是多模态，image_url用 base64 内联传图。跑通之后，你只要把图丢进00 Inbox，执行一次脚本，AI 就会读图、结合你写的 Idea 和 Output，往01 Notes和02 Topics写文件。
提示：脚本里读的是环境变量
TAOTOKEN_API_KEY，别把 Key 写死在代码里提交到 Git。Obsidian 库如果同步到云端，配置文件要加进.gitignore。
配置到这一步，通道就通了。下一节验证它真的能跑。
4. 验证请求：从一张截图到一条选题条目
配置完不验证，等于没配。这一节给你一个最小验证动作，跑通了再上批量。
4.1 先用 curl 验证通道
在跑脚本之前，先用一条 curl 确认 Key 和 Base URL 是通的。这一步能排掉 80% 的低级错误：
curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "回复 OK 两个字母"}] }'如果返回里有choices字段和内容，说明通道没问题。如果报 401，是 Key 的问题；报 404，是 Base URL 拼错了；报 model not found，是模型 ID 写错了。这三种错误下一节细讲。
4.2 再跑一次真实截图
准备一张有文字的截图，比如某条讲时间管理的帖子。把它放进00 Inbox，在图片下方用 Obsidian 写两行：
Idea: 长期目标不一定靠更久的耐心，也可以靠压缩时间倒逼行动。 Output: 写一篇「如何用 6 个月完成你的 10 年计划」。然后执行脚本：
node scripts/process-inbox.mjs跑完之后，去01 Notes看，应该多了一篇类似《压缩时间比延长耐心更能推动行动》的笔记；去02 Topics看，应该多了一条《如何用 6 个月完成你的 10 年计划》的选题条目。这就是「一图变两物」的验证动作。
4.3 批量跑
验证通过后，把 Inbox 里积压的截图一次性处理。脚本里加个循环遍历inboxDir下的所有图片即可：
const files = fs.readdirSync(CONFIG.inboxDir) .filter(f => /\.(png|jpg|jpeg)$/i.test(f)); for (const file of files) { const base64 = await imageToBase64(path.join(CONFIG.inboxDir, file)); const result = await analyzeImage(base64, "见图片下方备注", "见图片下方备注"); // 写入 01 Notes 和 02 Topics }实测下来，一百张图批量跑，主要时间花在模型推理上，通道本身很稳。跑完你就有了一整个可检索的选题库，Obsidian 的搜索和标签直接能用。
注意：批量跑之前先拿 3 张图试，确认输出格式符合你的预期，再全量跑。不然一百条格式不对的笔记清理起来更痛苦。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
这一节按真实报错来。你大概率会撞上下面几个，我一个个说清楚原因和解法。
5.1 401 Unauthorized
最常见。原因有三个：Key 没读到、Key 复制不完整、Key 绑定的分组不包含你调用的模型。
先确认环境变量真的生效了：
echo $TAOTOKEN_API_KEY如果输出为空，说明export没生效，重开终端或者source ~/.zshrc。如果输出有值但还是 401，去控制台确认这个 Key 绑定的分组里有没有你填的模型。同一个模型在不同分组下可用状态可能不同，以控制台实时页面为准。
5.2 local proxy failed
这个报错通常出现在客户端配置了本地代理端口，但代理没起来，或者端口被占用。检查你的配置文件里有没有proxy相关字段，把它删掉或注释掉，让请求直连 TaoToken 的 Base URL。codex 的config.toml里如果残留了旧的proxy配置，会优先走代理，导致连接失败。
# 删掉或注释掉这类字段 # proxy = "http://127.0.0.1:7890"5.3 reading choices 报错 / Cannot read properties of undefined (reading 'choices')
这个报错的意思是：代码在取data.choices[0]，但data里根本没有choices字段。说明请求返回的不是正常响应，而是错误对象。打印完整响应就能看到真相：
const data = await res.json(); console.log(JSON.stringify(data, null, 2)); // 先看结构再取字段常见原因是模型 ID 写错，服务端返回{"error": {...}}，你的代码却直接去读choices。把model改成控制台里确认存在的多模态模型 ID 即可。
5.4 OAuth 相关报错
如果你用的是 codex 的 OAuth 登录方式，又同时配了 API Key，两者会打架。OAuth 走的是官方账号体系，API Key 走的是自定义通道，混用会报认证冲突。解决办法是二选一：要么清掉 OAuth 凭据只用 API Key，要么反过来。用 TaoToken 通道就统一走 API Key，把 OAuth 相关的 token 文件清掉。
# 清掉旧的 OAuth 凭据（路径以实际为准） rm ~/.codex/auth.json清掉之后重新用 API Key 方式配置，三件套（Base URL + Key + Model ID）重新填一遍。
5.5 图片识别失败 / OCR 没结果
两个原因：模型不支持 Vision，或者图片分辨率太低。确认你选的模型是多模态的，纯文本模型传图会直接忽略图片内容。如果图太糊，先用系统截图工具提取文字，把文字贴进 Inbox，再让 AI 处理文本。
排错的核心心法就一句：先打印完整响应，再定位是哪一层出的问题。是网络层、认证层、还是模型层，看响应体一目了然。
6. 把通道固定下来，让选题库自己长
这套流程跑顺之后，你会发现真正的变化不是「省了多少时间」，而是「素材终于有了出口」。以前截图是终点，现在截图是起点。一张图进来，经过 Idea 和 Output 两句话的锚定，再经过多模态模型的加工，变成笔记和选题，沉淀在 Obsidian 里随时可搜。
配置层面，最值得固定下来的就是那条统一 API 通道。Base URL 填https://taotoken.net/api，Key 放环境变量，Model ID 选多模态，这三件套一次配好，后面换模型、加批量、接别的工具都不用再动通道本身。想验证模型效果，可以直接在模型对话里试；想长期跑编码和 Agent 类任务，Coding Plan 更划算；Key 的管理和创建在控制台的 API Keys 页面；接入细节和参数说明看接入文档。
我自己的习惯是每周清一次 Inbox，把积压的截图批量跑一遍，跑完在02 Topics里挑三条这周要写的。选题库不是靠一次大整理建起来的，是靠每周这个小动作慢慢长出来的。你下次再看到有启发的截图，别只存相册了，丢进 Inbox，补两句话，剩下的交给通道和模型。
