Zotero+Obsidian+Codex：打造自动化论文整理工作流

最近两年搞科研的人都有一个共同的感受论文下载越来越方便但论文的整理和阅读却越来越痛苦。文件夹里躺着几十篇 PDF要么是paper_final_v3.pdf要么是下载后根本没打开过。好不容易读完一篇想把核心观点记下来又要在 Zotero、Word、笔记软件之间来回切换复制粘贴摘要、补全作者信息、标注期刊年份一晚上整理三篇论文就过去了。这篇文章想聊一个可行的工作流改造方案把 Zotero、Obsidian、Codex 三个工具串联起来让“文献收集 → 笔记生成 → 知识沉淀”这条链路尽量自动化。核心判断是论文阅读的效率瓶颈不在“读”而在“读完之后手动搬运信息”的过程。Zotero 负责收集和管理文献元数据Obsidian 负责承接笔记和知识链接Codex 负责写脚本把前两者之间的重复劳动自动化。读完这篇文章你能得到一个可以直接复制的自动化思路包括完整的脚本示例、Obsidian 笔记模板、常见问题排查方法以及哪些环节不建议自动化的边界判断。全文内容基于个人实践经验总结不涉及任何虚构测试数据你会看到每一步的实际产出物长什么样。1. 为什么需要一套自动化论文整理流程先算一笔时间账。假设你每周精读三篇论文每篇论文手动整理笔记需要 20 分钟其中真正“思考”的时间可能只有 8 分钟剩下 12 分钟花在复制标题、粘贴作者、补全期刊信息、调整引用格式、新建笔记文件、写标签、归类文件夹这些机械操作上。一周就是 36 分钟一个月接近两个半小时一年下来超过 30 个小时。这些时间并不产生任何知识增量只是信息在工具之间搬家的成本。更麻烦的是这个过程一旦中断笔记往往就永远补不上了——周一读完的论文拖到周五已经不想整理了。自动化要解决的就是这 12 分钟“搬运成本”。目标不是替你做学术思考而是让你读完论文后只保留“记录观点”这一个动作其余全部交给脚本和模板。还有一个容易被忽视的问题手动整理时笔记格式往往不一致。今天记的笔记有摘要明天记的只有标题后天又在 Word 里单独写了一篇心得。半年后想用关键词搜索发现格式混乱、字段缺失知识库价值大打折扣。自动化的另一个价值是强制统一格式——每篇论文的笔记都包含固定字段后续检索、统计、回溯都会省力很多。把这套流程拆解开来本质上是三个能力的组合文献数据库的规范化管理能力Zotero、本地 Markdown 知识库的链接能力Obsidian、以及通过自然语言驱动脚本生成的能力Codex。三者单独使用都很常见但串起来之后会产生一个明显的乘数效应Zotero 让文献元数据变得结构清晰Obsidian 让笔记之间能够互相引用和聚合Codex 则把 Zotero 的数据转成 Obsidian 笔记的重复编码工作自动化。2. 三个工具的分工与集成逻辑很多人第一次接触这套组合时会误以为 Zotero、Obsidian、Codex 是三个功能重叠的笔记软件。实际上它们的定位完全不同放在一起正好覆盖了论文阅读的完整链路。Zotero 是文献管理的“数据源”。它负责抓取论文元数据、管理 PDF 附件、维护标签和条目关系。你在浏览器里看到一篇论文点一下插件按钮标题、作者、期刊、年份、DOI 就自动进入 Zotero 数据库。这一层的核心产出是结构化数据而不是最终笔记。Obsidian 是知识沉淀的“展示层”。它基于本地 Markdown 文件把论文笔记变成可链接的文本卡片。Obsidian 最大的优势不是编辑体验而是双链和 Dataview 这类插件带来的知识组织方式——你可以把 Zotero 导出的文献数据转换成带有 YAML Front Matter 的 Markdown 笔记然后在 Obsidian 里用查询语句按标签、年份、阅读状态筛选论文。Codex 是连接两者的“自动化引擎”。它本身是一个能够在命令行环境里执行的 AI 编码工具。你给它一个自然语言任务描述它会生成并运行脚本。在这个工作流里Codex 负责把 Zotero 导出的 JSON 文献数据批量转换成 Obsidian 笔记文件。三个工具的分工关系可以用下面这张表来概括工具职责产出物关键能力Zotero文献收集与元数据管理Better BibTeX 导出的 JSON/CSV浏览器插件抓取、条目去重、附件管理Obsidian笔记组织与知识链接Markdown 笔记 YAML Front Matter双链、Dataview 查询、模板系统Codex自动化脚本生成与执行Python/Shell 脚本、批量生成的笔记自然语言生成代码、命令行执行、迭代调试整体流程是Zotero 抓取论文 → 导出结构化数据 → Codex 根据数据批量生成 Obsidian 笔记 → Obsidian 中通过模板和 Dataview 完成知识管理。换成更直观的描述就是Zotero 是书架Obsidian 是笔记本Codex 是那个替你抄书的助手。3. 环境准备与前置条件这套工作流依赖的操作系统主要是 Windows 和 macOSLinux 也可以但 Obsidian 的插件生态在桌面端表现更好。本文的脚本示例是跨平台的但部分命令在 Windows PowerShell 和 macOS Terminal 中会有细微差别代码中会标注。开始之前先确认基础环境。Zotero 部分需要 Zotero 7 及以上版本因为新版对插件兼容性和数据导出稳定性都有明显改进。浏览器插件建议在 Chrome 或 Edge 中安装 Zotero Connector如果你希望导出更规范的 BibTeX 数据再安装 Better BibTeX 插件这是 Zotero 生态里最常用的增强插件。Obsidian 部分建议安装 1.5 以上版本主要原因是新版内置了更好的模板支持。笔记库建议使用英文或拼音路径避免在脚本处理时因为中文路径编码问题报错。需要安装的两个核心插件是 Templater 和 Dataview前者用于生成模板笔记后者用于在笔记列表中按字段聚合查询。Codex 部分推荐使用 OpenAI Codex CLI 工具官方提供npm安装方式。安装前提是电脑里有 Node.js 环境推荐 18 以上的 LTS 版本同时需要配置好 OpenAI API 密钥。如果你所在网络环境需要代理才能访问 API 服务需要正确设置环境变量HTTP_PROXY和HTTPS_PROXY否则很可能出现网络连接失败。Python 环境用于运行 Codex 生成的转换脚本。建议使用 Python 3.10 以上版本不一定需要虚拟环境但建议在项目目录下单独建一个scripts文件夹来管理脚本。后面代码示例会涉及json、os、re、pathlib等标准库不需要额外安装第三方包。这里单独说明 Codex 的安装方式方便第一次使用的人快速上手。在终端里执行npm install -g openai/codex安装完成后执行codex --version能看到版本号就说明安装成功。第一次运行时Codex 会引导你配置 API Key。如果你用的是第三方兼容接口也可以通过环境变量设置接口地址和密钥例如在 Linux/macOS 中export OPENAI_API_KEY你的_API_Key export OPENAI_BASE_URL你的_Base_URL需要提醒的是Codex 是一个能直接修改你电脑文件的自动化工具新增文件、批量重命名这类操作一定要在测试目录里先跑通再应用到正式笔记库。4. 第一步搭建 Zotero 文献收集与导出链路Zotero 在这套流程里的角色是“干净的数据源”。如果 Zotero 里的文献条目混乱、字段缺失后面生成的所有 Obsidian 笔记都会有同样问题。所以第一步不是自动化而是先把 Zotero 的导出规范搞定。4.1 安装浏览器插件并抓取文献在 Zotero 桌面端打开后保持后台运行。然后在 Chrome 或 Edge 中安装 Zotero Connector 插件。安装完成后访问论文页面例如 arXiv、Google Scholar 或期刊官网点击浏览器右上角的 Zotero 图标插件会自动识别页面中的文献信息并把标题、作者、摘要、年份、DOI 等字段保存到 Zotero 对应分类中。常见问题有两个一是点击插件后没有反应或者提示“保存此条目时发生错误”。这个问题通常与翻译器translators失效有关。解决办法是在 Zotero 中更新翻译器打开“编辑 → 首选项 → 高级 → 文件和文件夹”点击“重置翻译器”按钮即可等待网络请求完成后重新抓取。二是国内网络环境下访问部分学术数据库比较慢抓取超时。更稳妥的方式是先把论文 PDF 下载到本地然后拖入 Zotero再右键点击条目选择“查找可用的 PDF 元数据”Zotero 会尝试自动补全元数据。4.2 安装 Better BibTeX 插件Better BibTeX 是 Zotero 生态中非常重要的增强插件。它的主要作用是生成稳定的引用键同时提供更符合 BibTeX 规范的导出格式。对于我们的自动化流程来说Better BibTeX 最重要的能力是导出带完整扩展字段的 Better CSL JSON。安装方式是在 Zotero 的“工具 → 插件”页面中选择“从文件安装插件”然后在 Better BibTeX 的 GitHub Releases 页面下载最新的.xpi文件版本以实际项目为准安装后重启 Zotero。4.3 导出文献数据在 Zotero 中选中你要导出的论文条目可以多选点击右键 → “导出所选条目”格式选择“Better CSL JSON”取消勾选“导出注释”或“导出笔记”等附加项保留下干净的核心数据。导出后会得到一个 JSON 文件大致结构如下[ { id: 1, DOI: 10.1000/xyz123, title: A Survey of Large Language Model Agents, author: [ { family: Wang, given: Lei }, { family: Zhang, given: Yiming } ], issued: { date-parts: [[2024, 3, 15]] }, container-title: Computing Surveys, abstract: Large language models have shown remarkable abilities..., URL: https://example.com/paper1 } ]这一步的核心目的是把 Zotero 中结构化的论文元数据变成一个可以被脚本读取的中间文件。后面的自动化生成流程都以这个 JSON 文件为输入。实际导出的文件名可能是My Library.json或自定义名称记住路径即可。5. 第二步在 Obsidian 中搭建笔记模板与查询视图Obsidian 端主要解决两个问题笔记长什么样、笔记怎么被检索。前者靠模板后者靠 Dataview。5.1 创建笔记库目录结构建议在 Obsidian 库中建立如下目录My Knowledge Base/ ├── 01_Inbox/ # 临时笔记 ├── 02_Papers/ # 论文笔记 ├── 03_Templates/ # 模板文件 └── 04_MOCs/ # 知识地图在03_Templates中创建论文笔记模板文件例如paper_template.md。模板内容如下--- title: {{title}} authors: {{author}} year: {{year}} journal: {{journal}} doi: {{doi}} url: {{url}} tags: [paper, unread] status: unread created: {{date}} --- ## Summary - **一句话总结** - **核心贡献** - **关键结论** ## Notes - ## Quotes - ## Related -这个模板的价值在于不管来自脚本还是手动创建每篇论文笔记的字段结构都是一致的。后续用 Dataview 聚合、用 Templater 插入、用搜索过滤都会非常方便。5.2 配置 Dataview 查询在04_MOCs中创建一个论文总览笔记写入 Dataview 代码块用于列出所有论文笔记并按阅读状态分组TABLE authors AS 作者, year AS 年份, journal AS 期刊, status AS 状态 FROM 02_Papers WHERE contains(file.name, paper) SORT year DESC再创建一个“待读清单”查询LIST FROM 02_Papers WHERE status unread SORT year ASCDataview 查询语法并不复杂核心就是FROM指定路径WHERE指定过滤条件SORT指定排序。字段名必须和笔记 YAML Front Matter 中的字段保持一致否则查询结果会为空。Obsidian 端的准备工作到这里就足够了。真正的关键自动化——批量生成带上述模板结构的笔记文件——交给 Codex 来完成。6. 第三步让 Codex 生成批量笔记转换脚本Codex 的核心交互模式是你用自然语言描述任务它会生成对应代码然后你在终端里运行并验证结果。下面以“把 Zotero 导出的 JSON 文件转换为 Obsidian Markdown 笔记”为例演示完整的操作路径。6.1 创建测试环境在 Obsidian 笔记库同级目录下创建一个用于测试的工作目录mkdir paper-automation cd paper-automation mkdir output把第 4 节导出的 JSON 文件复制到paper-automation目录下例如命名为zotero_papers.json。6.2 向 Codex 描述自动化需求在终端中启动 Codexcodex然后输入类似这样的任务描述请帮我写一个 Python 脚本 1. 读取当前目录下的 zotero_papers.json 文件这是一个 Zotero 导出的论文列表。 2. 对每一篇论文生成一个 Markdown 笔记文件。 3. 文件名格式为年份_第一作者姓_论文短标题.md 4. 笔记内容需要包含 YAML Front Matter字段包括 title、authors、year、journal、doi、url、tags、status。 5. 文件输出到 output 目录。 6. 生成时自动跳过没有 title 字段的条目。 7. 请生成完整脚本并在生成后立即测试运行。Codex 会生成一个类似下面的 Python 脚本实际生成的代码可能略有不同以你获得的集成为准# 文件路径paper-automation/generate_notes.py import json import os import re from pathlib import Path INPUT_FILE zotero_papers.json OUTPUT_DIR Path(output) def sanitize_filename(name: str) - str: 清理文件名中的非法字符 name re.sub(r[\\/:*?|], _, name) return name.strip() def get_first_author_lastname(authors) - str: 从作者列表中提取第一作者的姓氏 if not authors: return unknown first authors[0] return first.get(family, unknown) def build_front_matter(paper: dict, year: str, first_author: str) - str: 生成 YAML Front Matter authors [] for author in paper.get(author, []): family author.get(family, ) given author.get(given, ) authors.append(f{given} {family}.strip()) author_str , .join(authors) journal paper.get(container-title, ) doi paper.get(DOI, ) url paper.get(URL, ) return f--- title: {paper[title]} authors: {author_str} year: {year} journal: {journal} doi: {doi} url: {url} tags: [paper, unread] status: unread created: {year} --- ## Summary - **一句话总结** - **核心贡献** - **关键结论** ## Notes - ## Quotes - ## Related - def main(): if not INPUT_FILE: print(未找到输入文件请先导出 Zotero JSON ) return with open(INPUT_FILE, r, encodingutf-8) as f: papers json.load(f) OUTPUT_DIR.mkdir(exist_okTrue) generated 0 skipped 0 for paper in papers: title paper.get(title) if not title: skipped 1 continue year unknown issued paper.get(issued) if issued and issued.get(date-parts): year issued[date-parts][0][0] first_author get_first_author_lastname(paper.get(author)) filename f{year}_{first_author}_{sanitize_filename(title[:50])}.md filepath OUTPUT_DIR / filename front_matter build_front_matter(paper, year, first_author) filepath.write_text(front_matter, encodingutf-8) generated 1 print(f生成完成共处理 {len(papers)} 条生成 {generated} 个笔记跳过 {skipped} 条无效条目。) if __name__ __main__: main()脚本的逻辑并不复杂但几个关键点值得展开说明。issued[date-parts][0][0]是从 Zotero 导出的 CSL JSON 中提取年份的标准方式直接读取issued字段下的日期数组。如果你的 Zotero 导出的字段名不同Codex 生成的代码可能需要微调。我建议在运行脚本前先用python -c import json; print(json.load(open(zotero_papers.json))[0])看一眼实际数据结构。sanitize_filename函数用于过滤文件名中的非法字符。Windows 和 macOS 对文件名字符限制不同路径分隔符\ /、冒号:、星号*等都要替换成下划线。如果不做这一步脚本可能在生成几十个文件后突然中断。作者字段的处理同样重要。CSL JSON 里的作者是一个列表每个元素包含family和given字段但有的条目没有given有的连family都没有。脚本必须做空值兜底否则会抛 KeyError。6.3 生成并运行验证Codex 生成脚本后会在对话中给出运行命令。你可以在 Codex 对话中直接确认运行也可以回到终端手动执行python generate_notes.py如果一切正常输出目录中会出现类似这样的文件output/ ├── 2024_Wang_A_Survey_of_Large_Language_Model_Agents.md ├── 2023_Chen_Reinforcement_Learning_from_Human_Feedback.md └── 2022_Liu_Efficient_Transformers_A_Survey.md打开其中一个文件内容应该包含完整的 YAML Front Matter 和空的笔记模板。到这里最小的自动化闭环就已经跑通了。7. 第四步把生成的笔记接入 Obsidian脚本生成的 Markdown 文件默认输出在paper-automation/output目录但 Obsidian 只能识别笔记库内的文件。这一步要完成的是把生成文件移动到 Obsidian 库的02_Papers目录并验证模板和 Dataview 是否正常工作。如果不想每次手动移动文件可以让 Codex 在脚本里直接指定输出目录为 Obsidian 库的实际路径。例如把代码中的OUTPUT_DIR改成你的本地笔记库路径OUTPUT_DIR Path(/Users/yourname/My Knowledge Base/02_Papers)Windows 系统对应路径类似OUTPUT_DIR Path(rD:\My Knowledge Base\02_Papers)这里需要提醒一个 Windows 反斜杠的问题。Python 字符串中的反斜杠是转义符直接写D:\My Knowledge Base\02_Papers会报错或路径错误。最稳妥的方式是使用原始字符串rD:\...或把反斜杠都改成/。移动文件后打开 Obsidian在04_MOCs中的论文总览页面按刷新按钮或等几秒Dataview 查询应该能自动识别新增笔记。如果查询为空优先检查两件事笔记文件是否确实在02_Papers目录下YAML Front Matter 中的字段名是否与 Dataview 表格中的列名一致特别是authors和journal这类包含特殊字符的字段此时整个自动化的第一次闭环完成了。你以后在 Zotero 里添加一批论文导出 JSON运行脚本Obsidian 中就会自动出现一批格式统一、可查询、可链接的论文笔记。真正需要你动手的只有两步在 Zotero 里抓取论文以及在 Obsidian 里填写笔记内容。8. 进一步增强用标签和状态管理文献阅读进度基础流程跑通后可以把自动化做得更精细一些。论文阅读不是一次性动作一篇论文从“已收集”到“已精读”再到“已被引用”是一个动态过程。这个状态转换如果放在笔记里手动维护很容易遗漏。你可以利用 Obsidian 的 Dataview 和 Templater 插件建立一套轻量级的阅读状态管理机制。具体的做法是在笔记模板中保留一个固定的status字段初始值由脚本写为unread。当某篇论文读完后手动把状态改为read或在笔记正文中添加日期标签。然后在论文总览页面建立“正在读”的查询例如LIST FROM 02_Papers WHERE status reading SORT year DESC如果你希望更自动化一点可以继续请 Codex 生成一个小脚本读取 Obsidian 目录下所有笔记的 YAML Front Matter统计不同状态的数量# 文件路径paper-automation/check_status.py import yaml from pathlib import Path NOTES_DIR Path(/Users/yourname/My Knowledge Base/02_Papers) counter {} for md_file in NOTES_DIR.glob(*.md): with open(md_file, r, encodingutf-8) as f: lines f.read().split(---) if len(lines) 3: meta yaml.safe_load(lines[1]) status meta.get(status, unknown) counter[status] counter.get(status, 0) 1 print(counter)这个脚本依赖pyyaml库需要先安装pip install pyyaml运行后能看到一份简单的阅读进度统计。这种方式没有引入复杂的项目管理工具也不需要在线服务所有数据都保存在本地 Markdown 文件中稳定性很高。9. 常见问题与排查思路工具串联之后一旦出问题很多人第一反应是“某一个工具坏了”实际上问题往往发生在数据流转的中间环节。下面是这套工作流里最常见的几个问题及排查顺序。问题现象可能原因排查方式解决方案Zotero 浏览器插件无法抓取文献提示“保存此条目时发生错误”翻译器过期或网络请求失败打开 Zotero 首选项 → 高级 → 重置翻译器重置翻译器后重新抓取或先下载 PDF 拖入 Zotero 再查找元数据导出 JSON 后脚本报错 KeyError: issuedZotero 条目不完整缺少年份字段用 Python 打开 JSON检查第一条数据的字段在脚本中用.get()做空值兜底跳过缺字段条目Codex CLI 启动失败或无法访问 API网络代理配置错误或 API Key 未设置执行echo $HTTPS_PROXY查看代理环境变量执行codex --version确认安装设置HTTPS_PROXY环境变量或重新配置 API Key生成的 Markdown 文件中文乱码脚本写入时未指定 UTF-8 编码用文本编辑器打开文件查看编码在 Python 的open()中指定encodingutf-8Obsidian 中 Dataview 查询列表无结果YAML 字段名与查询字段不一致打开笔记源码对比 YAML 字段名与查询中的字段名统一字段命名注意大小写和引号Obsidian 同步到手机后笔记路径失效Obsidian 库在手机上同步不完全检查同步服务是否完整确认02_Papers目录存在在手机端重新等待同步完成或重新创建空目录脚本生成速度过慢几百篇论文要跑很久脚本中使用低效字符串拼接或重复文件读写检查是否在循环中频繁打开文件一次性构建全部内容再批量写文件这里特别提一下 Codex 网络代理问题。很多开发者配置了本地代理但 Codex 终端环境下未必继承了系统代理会出现类似“cc switch local proxy failed while handling codex endpoint /responses”的报错。排查顺序是先确认HTTPS_PROXY环境变量是否生效再检查代理地址是否能访问目标 API 端点。如果你使用的是公司网络或学校网络还需要检查防火墙是否放行相关域名。10. 这套自动化方案的边界与最佳实践自动化不是万能的。这套 Zotero Obsidian Codex 工作流最大的价值在于降低论文笔记的启动成本但它并不适合所有场景。先说适合的场景你的研究方向需要长期跟踪大量文献并且希望建立一个可以回溯的知识库你愿意花少量时间维护笔记模板和脚本你对论文笔记的格式统一性有要求。对于这些场景自动化带来的收益非常明显——每周节省半小时手动整理时间同时笔记质量更稳定。不适合的场景也要说清楚如果你只是偶尔读几篇论文或者你的研究领域论文结构非常复杂例如需要手工绘制大量图表和公式那么前期搭模板、配脚本的成本可能高于收益。自动化不能替你思考如果你的核心需求不是整理文献而是深读某一篇论文那直接在 PDF 上做标注可能更快。从工程最佳实践角度有几点建议值得长期坚持。第一脚本的操作范围必须严格限制。Codex 能执行系统命令误操作的风险是真实存在的。我建议在脚本开头打印将要操作的目录路径并在生成文件前做一个 dry-run 检查。也就是说先跑一次“只生成到临时目录、不覆盖正式库”的验证确认输出结果符合预期后再切换到正式目录运行。第二Zotero 和 Obsidian 的数据都建议纳入定期备份。Zotero 的数据库文件可以导出为压缩包Obsidian 的 Markdown 文件可以直接备份到本地磁盘或网盘。脚本本身也应该保存在笔记库之外的地方避免误删。第三不要过度自动化。有位研究者说过一句很实在的话笔记软件最怕的不是不记录而是记录了一堆从未回顾的内容。自动化生成的模板笔记只有“骨架”真正的价值来自于你在“Notes”和“Quotes”区块里填写的思考。如果只收集不消化这套流程反而会制造一种“我读了很多论文”的错觉。第四善用 Obsidian 的双链。脚本生成的模板中有Related区块你可以手动填写与其他笔记的关联。这一步虽然无法自动化但它是知识库从“文件堆”变成“知识网络”的关键。建议每篇精读论文至少关联 1 到 2 篇已读论文长期积累后Obsidian 的图谱视图会变成一个非常有价值的研究地图。11. 总结与下一步建议现在回看整条链路实际上只做了三件事Zotero 导出结构化论文数据Codex 按照规则把数据转换成 Obsidian 笔记模板Obsidian 通过 Dataview 让这些笔记可以被检索和聚合。三个环节相互独立又通过 JSON 文件这个中间格式平滑衔接替换任意一个环节都不会影响其他环节。如果你第一次接触这套工作流我建议不要一开始就追求全自动。可以先用最笨的办法手动创建三个笔记感受一下 Obsidian 的模板和 Dataview 语法然后在 Zotero 中导出一次 JSON找一个已有的简单脚本来处理最后才引入 Codex 来加速脚本生成和迭代。先把链路跑通再逐步增加自动化程度这个顺序比一口气配置全部工具要稳得多。如果论文量很大或者你有固定的研究方向还可以尝试把维度继续扩展。例如在 Zotero 中给论文打上主题标签脚本读取标签后自动写入笔记的 YAML或者在 Obsidian 中为不同期刊创建 MOC 笔记通过 Dataview 自动汇总当前期刊下所有论文又或者接入翻译插件让 Abstract 区块直接显示中文摘要。工具组合不是重点重点是它们帮你释放了精力。最好的状态是读完一篇论文你只需要在 Zotero 里点一下收集在 Obsidian 里写几句真正属于自己的思考剩下的格式整理、字段补全、分类归档全部交给脚本去完成。这样省下来的时间本该属于真正的研究本身。建议把这篇文章收藏备用周末抽半小时在本地跑通最小示例后面读论文时会轻松不少。model_used: gpt-5.6-sol