Obsidian+DeepSeek+Codex：三件套搭建AI Company OS

这套组合我用了差不多四个月，中间换过不少方案，最后还是回到这三个工具来打底。核心原因很简单：我需要的不再是一堆“好用的软件”，而是一套能自己运转的个人工作操作系统，用标题里的话说就是 AI Company OS。Obsidian 负责记忆，DeepSeek 负责思考，Codex 负责执行，三者各管一段，拼成一条完整的数据流水线。这篇文章我会把为什么是三件套、每个环节怎么选型、具体怎么搭、踩过哪些坑，一条条讲清楚。内容比较实操，建议收藏后对着配置。

1. 为什么是三件套，而不是一件套

1.1 我理解里的“AI Company OS”到底指什么

很多朋友一听 Company OS 就以为是上 ERP、搞组织流程管理。我自己的理解更朴素：一个人或一个小团队，每天要处理大量输入——行业信息、会议记录、客户反馈、临时任务、零散想法。如果我们能把这些输入统一捕获到一个地方，用 AI 完成分类、提炼、拆解，再自动生成可执行的任务和内容，最后把结果沉淀成可检索的知识资产，这个闭环就是最简版本的 AI Company OS。

传统的做法是几个工具各干各的：群里看到文章丢进收藏夹，会议纪要用某个在线文档，任务清单又放在另一个软件里，代码脚本散落在本地文件夹。信息根本没有流通，AI 只是被当成一个“对话框”，用完即走。我想要的系统必须满足三个条件：输入统一、处理有逻辑、结果可沉淀。Obsidian 负责统一存储和沉淀，DeepSeek 负责处理和推理，Codex 负责把推理结果变成真实改动。这三个条件刚好一一对应。

1.2 三件套的分工：记忆、推理、执行

如果拿人体来类比，Obsidian 是记忆皮层，所有原始信息、中间产物、最终结论都存在这里，而且是纯文本 Markdown，不依赖任何云服务；DeepSeek 是大脑皮层，负责理解长文本、做摘要、拆解需求、生成模板化内容，它的优势在中文语境和长上下文；Codex 是手和脚，负责真正去读写文件、跑脚本、批量处理数据，把 DeepSeek 输出的“该做什么”变成“已经做了什么”。

这三层不能缺一个。我去掉过 Codex，结果发现 DeepSeek 再聪明，生成的只是文本，没人去把文本变成操作，任务还是卡在那里；我也去掉过 Obsidian，直接全放 API 对话里，结果信息越滚越乱，最后完全没法检索，所有产出变成一次性消耗品；DeepSeek 更不用说了，没有推理层的系统就是一个高级文件夹。三者合在一起，才形成“输入 -> 提炼 -> 执行 -> 沉淀”的循环。

1.3 替换任意一层都不会绑架你

我很看重“可替换性”。这套组合里 Obsidian 存的是 Markdown 文件，哪怕它明天倒闭了，我拿 VS Code 也能接着用；DeepSeek 走的是标准 API，任何兼容接口的模型都能换进来；Codex 本质是脚本执行环境，我换成其他自动化工具也只是改一下配置。

这种模块化设计带来的好处，日常感受不到，真正换工具的时候才体会得到。去年我试过某款“All-in-One”的 AI 工作台，把所有笔记和任务都存进去了，后来免费额度一改，我差点连导出都要费半天劲。从那以后我就坚持：核心数据一定放在本地纯文本里，AI 只是外挂的“服务”，不是数据的唯一容器。

2. 各选型的判断依据：不追新，只追体系

2.1 Obsidian：本地 Markdown 和数据主权

选 Obsidian 而不是在线文档，最大的理由是“数据主权”。所有内容都是本地文件，不锁格式、不锁平台，能用 Git 做版本管理，也能用脚本直接批量处理。对一个要长期滚动的操作系统来说，这个底座价值比任何花哨功能都大。

真正把 Obsidian 和普通笔记软件区分开的，是它的插件生态。Dataview 能把分散的任务按状态汇总成动态看板，Templater 能自动套用模板，QuickAdd 能定义自定义命令来跑脚本。这三件套是我工作流里的地基，后面接入 API 和自动化全部依赖于这套插件体系。

我自己定的目录结构是这样：

00-Inbox/ # 所有输入的暂存区 10-Projects/ # 有明确目标的项目 20-Areas/ # 长期维护的领域 30-Resources/ # 知识库、资料、素材 90-Daily/ # 日记和日志

这个结构其实就是简化版的 PARA 方法。不要一上手就建几百个文件夹，我的建议是只保留这五个根目录，后续发现某类内容频繁出现，再在相应目录下建立细分条目。

2.2 DeepSeek：中文长文本推理的性价比选择

DeepSeek 在这个系统里的角色是“推理层”。我需要它做的不是闲聊，而是给定一篇长文产出结构化纪要、给定一段会议录音转写文本拆出行动项、给定一堆零散笔记整合成知识卡片。这类任务的共同点是：输入长、输出结构明确、对中文细节要求高。

实测下来，DeepSeek 在这三类场景的表现很稳定。它的长上下文处理能力能让我直接丢进去一整篇万字文章，不用提前分段；对中文口语化表达的理解也比多数通用模型更细腻，会议记录里的“咱们尽快看下”能准确拆成“跟进某事项”。关键是成本比商用大模型低一大截，对于一天要调用几十次的工作流，这个差距非常明显。

接入方式我用的是 API。为什么不截图网页版让人工复制粘贴？因为 API 可以被脚本直接调用，能够嵌入 Obsidian 的自动化流程。比如从 QuickAdd 触发一段 Python 脚本，脚本读取当前笔记内容，调用 DeepSeek 生成摘要，再写回文件头部 YAML 里。整个过程不需要打开任何网页。

2.3 Codex：把“对话”变成“完成”

Codex 在这里是“执行层”。DeepSeek 能把一篇会议纪要变成“输出一个 Markdown 文件，列出任务、负责人、截止日期”，但如果没人实际去建文件、更新文档、批量改格式，就只是空谈。Codex 就是负责把这些指令落到文件系统上的角色。

我的用法是把它限定在一个专门的“工作台”目录里，给它明确的规则：只能操作 30-Resources/raw/ 里的文件，生成内容统一输出到 30-Resources/processed/。这样就算执行出错，影响范围也是可控的。

常见的执行任务包括：

• 批量重命名文件，统一命名规范
• 将 Web 页面上下载的 HTML 表格转换成 Markdown
• 把散乱的 CSV 数据自动清洗成 Obsidian 属性格式
• 批量给笔记生成标签和摘要并回填到 front matter

每个任务都遵循“先生成预览 -> 人工确认 -> 再写入”的原则。我强调这个原则，是因为让 AI 直接改文件，一次可能很爽，十次之后总会出现一次小概率事故，比如我踩过的把 status 字段改错，导致整个看板数据错乱。

2.4 为什么不直接用“大模型全家桶”

市面上很多全能型大模型产品似乎什么都能干，既能聊天、又能写作、还能当 Agent 写代码。但真正当我把所有工作都压进一个工具时，问题很快暴露：对话上下文一长，模型开始张冠李戴；代码执行环境隔离开，没法直接操作我的本地文件；内容生成的格式总是跟我的笔记模板对不上。

深层次问题是：All-in-One 工具把“思考”和“执行”耦合在一起，但现实场景里这两个环节需要不同的反馈节奏。思考层我希望是缓慢、可控、可干预的，读完一篇文章生成摘要后我要看一遍再决定采纳；执行层我更希望是快进快出、有明确边界的，批处理脚本跑完就行，不需要过度解读。把两个节奏强制统一，体验必然拧巴。三件套分离设计正好解决了这个问题，每层可以独立调整，互不拖累。

3. 实操搭建：一套可以照搬的工作流

3.1 先定目录和命名，再谈自动化

很多人上来就装插件、配 API，结果目录乱成一锅粥，自动化根本不知道该从哪里找文件。我的建议是先把“人的流程”固定下来，再教 AI 工具跟着走。

命名规范我用了“短名+日期”的方式：

2025-03-21-客户反馈分析.md 2025-03-21-项目A-周报模板.md

每篇笔记开头是标准的 YAML front matter，这样 Dataview 才能做动态聚合：

--- type: project status: active owner: self created: 2025-03-21 tags: [客户, 分析] ---

这套规范看起来死板，但它是整个自动化的真正地基。没有规范，AI 生成的输出就五花八门；有了规范，DeepSeek 只负责生成符合 schema 的 YAML，Codex 只负责把文件放进指定目录，两个工具产出的东西天然就兼容。

3.2 用 Python 把 DeepSeek 接进 Obsidian

接入方式我用了 QuickAdd + Python 脚本。QuickAdd 可以理解成一个“快捷指令入口”，我给它添加了一条命令：对当前笔记运行“AI 摘要生成”。点一下，它调用本地 Python 脚本，脚本读文件、请求 API、写回结果。

下面是简化的 Python 代码，逻辑比较清晰：

import requests import sys from pathlib import Path DEEPSEEK_API_KEY = "你的API密钥" DEEPSEEK_URL = "https://你的接口地址/v1/chat/completions" def generate_summary(content: str) -> str: payload = { "model": "你的模型标识", "messages": [ {"role": "system", "content": "你是知识管理助手。用中文生成200字以内摘要，输出格式为JSON，字段为summary。"}, {"role": "user", "content": content} ], "temperature": 0.3 } headers = {"Authorization": f"Bearer {DEEPSEEK_API_KEY}"} resp = requests.post(DEEPSEEK_URL, json=payload, headers=headers) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": path = Path(sys.argv[1]) content = path.read_text(encoding="utf-8") result = generate_summary(content[:8000]) path.write_text( f"{result}\n\n{content}", encoding="utf-8" )

重点解释两件事。第一，我截取了前 8000 字作为输入，不是为了省 token，而是防止长文件里某个无关段落干扰摘要方向，让模型集中在前面的核心内容上。第二，temperature 设在 0.3，摘要类任务适合低随机性，输出稳定，不会同一篇笔记两次生成完全不同的结论。

3.3 给 Codex 画好“车间范围”

Codex 集成进来不只是让它“写代码”，而是把它变成“车间操作员”。所以最关键的不是模型能力，是给它画清楚能碰什么、不能碰什么。我在配置里加了一条很严格的系统提示：

你只能读取和写入当前工作目录下的 30-Resources 文件夹。 禁止修改 00-Inbox 和 90-Daily 目录下的任何文件。 每次修改前先打印 diff 摘要，等待确认后再应用。

实际跑下来，这条规则的收益非常大。有一次我让它批量整理全部资源文件，它误判了一个文件名格式，差点把近一个月的日记模板全重命名掉。因为限制只允许操作 30-Resources，其他目录直接拒绝访问，最终只毁了一个文件夹里的部分文件名，用 Git 就恢复了。

我建议 Codex 的执行上限以“人工确认”为界。每次执行前输出将要改动的文件列表，我自己扫一眼，看到的都是预期内容就放行。这样做牺牲了一点效率，但换来了整个流程的可控性。AI 自动化最怕的是出错时你不知道它改了什么，人工确认就是最后一道保险。

3.4 一个完整业务场景演示

说一个每天都能遇到的完整场景：下午在微信公众号看到一篇行业分析文章，想把它沉淀成可执行的知识卡片并安排复盘。

第一步，把链接或者全文丢进 00-Inbox/，文件名是“2025-03-21-行业分析原始文章.md”。

第二步，在 Obsidian 里对该文件运行“AI 结构化拆解”命令。这个命令会完成三项工作。

# 伪代码，展示编排逻辑 inbox_file = read_inbox_file() result = deepseek_analyze(inbox_file) project_file = create_markdown_with_template(result) add_task_to_daily_note(result["action_items"]) write_to_projects(result["project_path"])

具体来说：DeepSeek 阅读全文后输出摘要、核心观点、我的业务关联点、后续行动项。脚本再调用 Templater 模板，生成一个带标准 front matter 和双链的知识卡片，存入 10-Projects/2025-03-21-行业分析卡片.md。与此同时，行动项会被追加到今天日记的“待办列表”区块。

第三步，Codex 出场。这里我设计了一个可选项：如果文章里包含表格或数据，我会让 Codex 写一个解析脚本，把表格转换成 Markdown 表格并插入知识卡片，再顺手把所有原文中的特殊字符统一处理，避免 Obsidian 渲染出错。

整套流程下来，从看到一篇文章到形成一条可检索、带任务、有观点的项目卡片，耗时大约三分钟。中间几乎没有手动复制粘贴的环节，所有中间产物都在本地文件系统里有迹可循。

4. 跑到三个月后，我踩过的坑和排障心得

4.1 front matter 被 AI 写坏，整条看板跟着乱

这个坑我印象最深。刚开始我把“生成摘要”的权力完全交给 DeepSeek，让它直接覆写文件头。有一天它输出的 summary 字段里带了换行符和冒号，直接破坏了 YAML 语法。Dataview 读取这条后，整页任务看板都渲染空白，我还以为是插件坏了。

后来加了一道校验步骤：所有写回操作都不直接触原文件，先临时输出到一个 staging 文件，由 Python 脚本用 YAML 解析器验证格式，解析通过才替换原文件。几个关键字段比如 status、tags，校验规则单独写死，类型不对就自动拒绝写入。

这个教训我反复讲：不要信任 AI 每次都会遵守格式规范。大模型生成的内容大概率是对的，但“大概率”远不够用在一个长期运转的系统里。必须在校验层兜底，宁可慢一点，也不要让一条坏数据污染全局。

4.2 上下文太长，推理开始“胡说”

DeepSeek 确实支持很长上下文，但长上下文不等于可以无限塞入重要信息。有一阵我把一整周的工作日记都丢进同一个对话，让它做周总结，结果模型开始编造一些根本没发生的会议，标题日期也出现了错位。原因是长上下文后段的信息权重下降，模型自动“补全”了它觉得应该有的内容。

解决方案是：单次调用只做单一任务，控制好输入范围。一篇文章就只做摘要，一周的所有日记就让脚本逐天处理再合并，而不是一次性全部丢进去。这样会把一次大请求拆成多个小请求，虽然响应次数变多，但每一次的输出质量都很稳定，出错时定位也特别快。

我现在的习惯是：所有进入 API 的内容先截断到 8000 字以内，超过就分段调两次，然后用规则拼接。别迷信“上下文越长越强”，对实际工作流来说，“准确的 8000 字”比“模糊的 50000 字”有用得多。

4.3 Codex 把任务做“过头”了

Codex 的性格是“你让我优化，我就帮你全面优化”。有一回我让它清理某个项目目录里的临时文件，它不光清除了临时文件，还顺手给所有 Markdown 做了格式重排，改动了大量无关文件。变化本身不算错，但严重干扰了文件历史，Git 历史里多了几百条不是我本意产生的改动。

解决方法就是我一直强调的：缩小执行边界 + 强制预览。现在我对 Codex 的全部指令都带明确范围描述，比如“只修改 2025-03-21-客户反馈分析.md 这个文件，其他一律不动”，并且要求它每次执行前先列出将要改动的文件列表，等我确认后再写。这个习惯可能显得繁琐，但真的能救命。在自动化这件事上，边界感比执行力重要得多。

我总结了三个原则放在手边：

• 能只改一个文件，就不要给它两个文件
• 能预览 diff，就不要直接让 AI 写盘
• 能限定只读，就不要开放读写双权限

4.4 API 超时和断点续跑

自动化流程里最烦的是跑了一半请求超时。处理长文摘要时，偶尔会响应很慢，脚本里没写超时重试，整个流程就静默中断了，当时的文件只写了一半，得手工恢复。

我在脚本里加了超时控制和重试逻辑：

import time def call_with_retry(payload, max_retries=3): for i in range(max_retries): try: resp = requests.post(DEEPSEEK_URL, json=payload, headers=headers, timeout=60) resp.raise_for_status() return resp.json() except Exception: time.sleep(2 ** i) # 指数退避 raise RuntimeError("三次重试仍失败")

指数退避的意思很简单：第一次失败等 2 秒，第二次等 4 秒，第三次等 8 秒。给足重试时间，往往第三次就能跑通。同时还给每个任务生成了一个日志文件，记录调用的时间、输入的 token 数、是否成功，方便事后定位是哪一步断的。

4.5 常见问题速查表

把这六个场景跑顺以后，这套组合才真正接近“系统”的样子。它不需要我每天都去观察和维护，日常的输入、消化、输出都在轨道上自动流转，我更像是一个设定规则的人，偶尔处理一些异常而已。

最后再分享一个小经验：这套方案最值钱的部分并不是哪一个大模型，而是你给它设定的“边界”。Obsidian 把数据圈在一个规范目录里，DeepSeek 每一次都只做一件事，Codex 只在一个限定车间里操作。三者的边界各自清晰，拼在一起之后却异常顺滑。如果你想构建自己的 AI 工作系统，建议不是先把工具配齐，而是先花时间想清楚你希望哪些环节自动化、哪些环节一定要人工干预。边界定清楚了，工具只是把它落地的手段。