夜雨聆风声明
本系列文章只是一组阶段性的思考与实践记录，主要用于抛砖引玉，并不构成对所有学科、所有工具或所有研究场景都适用的标准答案。由于 AI 工具迭代很快，本文中的部分判断、界面描述与工作流经验都具有较强时效性，随着模型、插件和平台的发展，后续很可能需要重新修订，因此也请读者结合自己的实际情况自行甄别。另需特别说明：本文讨论的是 AI 对研究工作区、材料组织与日常流程的辅助作用，而不是鼓励任何形式的学术不端。无论工具如何发展，文献理解、研究判断、结果核查与学术责任都不能外包给 AI。
此文章中的示意图与分析图由Gemini Nano Banana Pro生成，特此声明。
写到这里，有必要先停一下，把几个反复出现的名字说清楚。因为如果不先把 Codex、VSCode、Obsidian 这三个词放回各自的位置，后面很多讨论都容易变成“名词看起来都懂，实际还是混在一起”。这并不是读者的问题，而是现在工具生态本身变化太快，很多产品既有旧身份，又在长出新能力。结果就是，大家一边在用，一边又很难用一句话把它们真正说清楚。
先说最容易被误解的一个：Codex。按照 OpenAI 现在的官方定位，Codex 已经不只是传统意义上的代码补全工具，也不只是一个网页里回答编程问题的模型。官方更愿意把它描述成一种能够在编辑器、终端和云端协同工作的 coding agent，既可以回答问题，也可以围绕一个真实工作环境去执行任务、编辑文件、运行检查、推进流程。这个变化很关键，因为它意味着 Codex 的价值不再只在“写几行代码”，而在于它开始接近一种能够进入工作区、理解上下文并持续行动的工具形态。对研究者来说，这一点的重要性甚至可能超过它本身到底会不会写代码，因为研究现场本来就包含大量需要整理、说明、连接和维护的材料。
如果把视野再放宽一点，Codex 并不是唯一一条路线。Anthropic 的 Claude Code，同样强调 agentic coding system，会读代码库、改文件、跑测试，并把“描述目标、由系统继续往下做”作为核心能力；Google 的 Gemini CLI 则代表了另一种更偏命令行与终端协作的路径，强调通过 CLI 把模型能力直接带进本地工具链。把这些名字放在一起看，比较合适的理解并不是“哪一个工具彻底替代另一个”，而是它们共同指向了一类新工具：不再只是聊天，不再只是补全，而是开始进入工作区、接触文件、执行步骤、处理上下文。这里之所以重点谈 Codex，只是因为这组文章目前主要围绕它展开，而不是说只有它值得讨论——当然从成本角度来考虑，也许Codex是较为平衡的选择。
再说 VSCode。很多人一听到这个名字，第一反应还是“程序员用的代码编辑器”。这当然没错，Visual Studio Code 本来就是微软推出的编辑器，而且今天它仍然是一个很强的开发环境。但如果只把它理解成“写代码的地方”，也会把它用窄。对我们这一组文章来说，VSCode 更重要的地方在于，它是一个非常适合打开整个目录、查看文件树、维护说明文件、运行脚本、调用终端、查看版本变化并接入 Agent 的工作台。官方文档里本来就强调它的集成终端、资源管理器和 source control 视图，这些能力放在研究场景里会特别顺手，因为你真正需要处理的，往往不是一篇孤立文档，而是一整个项目现场。
这里还需要顺手说清一个选择问题。对于很多程序员来说，纯命令行工具当然经常是更高效的解决方案，像 Codex CLI 这样的形态在某些任务里也会更直接。但这组文章之所以更偏向 VSCode，并不是因为命令行不好，而是因为 VSCode 在“可见性”和“可维护性”上更友好（难道你想对着一个黑黢黢的命令行操作界面写论文？不会吧！）。目录树、文件内容、终端输出、版本变化和 Agent 协作入口可以同时摆在一个界面里，这对研究工作尤其重要。研究现场里往往不只是代码，还有文档、笔记、图表、说明文件和中间结果。把这些东西放在一个更直观的工作台里，很多人会更容易理解，也更容易长期维护。
当然，这并不意味着只有 VSCode 才能承担这个角色。像 PyCharm 这样的 IDE，本来就强调面向 Python 开发的完整集成环境；Cursor 则把自己明确定位成 AI code editor，也在尝试把代码编辑和 AI 协作更紧地绑在一起。它们在很多场景下都可以完成类似工作。这里之所以选择 VSCode，说到底还是一个很朴素的理由：我自己以前就在用它，已经习惯了，也更清楚它在工作区层面好用在哪里。工具选择并没有唯一正确答案，顺手、稳定、能长期维护，往往比“理论上最先进”更重要。
最后说 Obsidian。这个名字在中文互联网里经常和“第二大脑”“双链笔记”“知识管理”绑在一起，所以很多人一听到它，就会自动把它理解成一种很重的知识管理方法，甚至觉得不用它就不配谈研究工作流。我的看法没有那么夸张。Obsidian 的官方帮助文档其实很朴素：它本质上是一个围绕本地 Markdown 文件工作的笔记环境，提供文件浏览、链接、搜索、图谱、模板、同步、发布等能力。它真正适合的，不是取代所有工具，而是承担研究过程中的“阅读、回看、关联与沉淀”这一层工作，同时Codex之类的工具，markdown格式与其天然产生了较好的兼容性。说得更直白一点，Codex 更像一个能在工作区里协助你做事的助手，VSCode 更像一个处理项目现场的工作台，而 Obsidian 更像一个适合承接思考痕迹与笔记网络的阅读界面。只要把这个分工看明白，Obsidian 就不会显得神秘，也不会显得非用不可。
把这三个工具放在一起时，最容易犯的错误就是把它们看成同一层面的东西。其实并不是。Codex 更偏“智能执行与协作层”，VSCode 更偏“工作台与项目现场层”，Obsidian 更偏“笔记与知识沉淀层”。这也是为什么我一直不太喜欢那种简单粗暴的说法，比如“用某某工具替代某某工具”。在一个成熟一点的研究工作流里，它们往往不是替代关系，而是分工关系。只有把分工说清楚，后面讨论工作区时才不会变成工具堆砌。
这一点背后，其实还牵涉一个更大的问题：今天很多工具之所以让人困惑，不只是因为名字多，而是因为工具边界本身正在移动。代码编辑器开始接入 AI，AI 开始进入目录，笔记工具开始兼具数据库和发布能力，聊天工具开始长出执行环境。于是我们很容易在语言上继续沿用旧理解，在实际使用中却已经站到了新的场景里。结果就是，明明已经进入了一个新的工作方式，却还在用旧词解释新问题。第二点五期存在的意义，某种程度上就是先把这些词捋顺。不是为了做名词解释题，而是为了让后面的讨论有一个更稳的起点。
如果要用一句最短的话来概括，我会这样说：Codex、VSCode 和 Obsidian 不是三个堆在一起的热门名词，而是三种不同层次的工具。前者更像进入工作区的智能助手，中间那个更像处理项目现场的工作台，后者则更像承接阅读和思考痕迹的界面。只要这层关系理顺了，后面关于工作区、日志、索引、模板和协作的讨论，才不会一开始就跑偏。
