企业官网建设流程全解析

1. 为什么我会把个人知识库、AI编程助手和推理模型绑在一起

先说清楚这个组合到底是什么。Obsidian 是本地优先的 Markdown 笔记工具，Codex 是 OpenAI 推出的代码生成与执行智能体，DeepSeek 是国产开源推理模型。这三样东西看起来风马牛不相及——一个管笔记、一个管代码、一个管推理——但我把它们组合起来，做成了自己的“AI Company OS”。这个名字听着唬人，其实落地之后就是一套能承载公司日常运营、产品迭代、知识沉淀和决策分析的工作流操作系统。

先讲我为什么需要这东西。做独立开发和小团队管理的人应该都有体会：公司规模小，但事情一点不少。产品需求要拆、客户反馈要归集、技术方案要写、营销内容要排期、财务数据要盯、知识库要沉淀。以前我靠一堆工具来回切换——飞书文档、Notion、GitHub、各种AI聊天窗口，结果信息散落得到处都是，每次开会前光找资料就要花半小时。后来我意识到，问题的本质不是“工具不够多”，而是“没有一套统一的运行环境来承载公司的数字大脑”。所以我开始搭这套 OS，核心就是三件事：用 Obsidian 收纳所有信息，用 Codex 自动化处理可编程的重复工作，用 DeepSeek 做深度推理和决策辅助。

这个组合最打动我的地方在于“本地可控 + 云上智能”的平衡。Obsidian 的笔记全部存本地，数据隐私有保障；Codex 负责执行那些可以被代码化的任务，比如批处理文档、自动生成报表、写脚本整理数据；DeepSeek 则承担需要逻辑推演的部分，比如方案对比、风险预测、文本重构。三者通过文件接口和 API 串联，形成了一个有输入、有处理、有输出的闭环。

如果你也是独立开发者、小团队负责人，或者想给自己的工作效率做一次系统升级的人，这篇文章值得看完。我会把整套架构、踩过的坑、具体的配置步骤全部拆开讲。看完你不需要照搬我的方案，但至少能明白为什么“笔记工具 + 代码智能体 + 推理模型”这个组合拥有很强的发展空间。

2. 整体设计与思路拆解：为什么偏偏是这三个组件

2.1 Obsidian 当作 OS 的“文件系统”

一个操作系统最底层的是什么？是文件系统。所有程序、数据、配置最终都要落地成文件。

Obsidian 在我的整套体系里就扮演这个角色。它用纯文本 Markdown 存储所有笔记，支持双链、标签、属性、模板，还有一个杀手级特性——所有数据都在本地文件夹里。这就意味着我可以直接用代码读取、修改、批量操作这些文件。Codex 写的 Python 脚本可以在 Obsidian 的 vault 文件夹里创建新笔记、更新任务状态、生成周报，整个过程完全透明。

对比一下其他笔记方案。Notion 虽然漂亮且功能强大，但它的数据不开放，API 权限有限，本地离线能力也很弱。飞书文档适合团队协作，但要把里的内容拉出来做自动化，需要走审批、配权限，麻烦得要死。而 Obsidian 让我能“万物皆文件”，文件即是数据，数据即是笔记。这个设计哲学和我后面要接 Codex、接 DeepSeek 是完全吻合的——它们都需要一个可编程的、可访问的存储层。

当然 Obsidian 也不是没有缺点。它的协同能力弱，实时多人编辑基本要靠 Git 或者第三方同步。但我是个人 + 小团队场景，更看重数据的可迁移性和可编程性，这些短板可以接受。

2.2 Codex 作为“执行引擎”

Codex 是模型的代码能力与沙箱执行环境的结合，你可以直接下达任务，它会在云端或本地环境里执行代码，返回结果。对我这种“不想写重复脚本但偏偏有大量重复任务”的人来说，它的价值是质变级的。

在 Company OS 里，Codex 主要干三类活：

• 文件处理：批量重命名、格式转换、清洗 CSV、合并 Markdown 文件
• 数据管道：从 Obsidian 里提取表格数据，生成统计图表，写入每日复盘
• 代码维护：写小工具脚本、修 bug、做自动化测试

因为 Codex 具备代码执行能力，所以它可以完成复杂操作：比如让它在 Obsidian vault 下建一个新的子文件夹、按照模板生成10篇产品文档，然后逐条读取笔记里的标签统计出现次数。这些任务过去我要手动一个个做，现在一句话就能搞定。

用 Codex 做执行引擎最大的好处是“确定性”。笔记写了什么、脚本怎么跑的、结果放到哪，每一步都可以通过代码日志重现，而不是像用 AI 聊天那样每次答案都不一样。这在一个公司的运行系统里非常重要——你可以追溯一周前的数据是怎么算出来的。

2.3 DeepSeek 充当“推理中枢”

Codex 擅长“做”，但“想”这件事还是得靠推理模型。DeepSeek 是我选择的推理模型，原因有三：中文语义理解扎实、API 便宜、开源可控适合私有化部署。

在 Company OS 里，DeepSeek 负责副驾驶角色。比如我输入一堆客户反馈笔记，它负责归纳出三类主要问题；我要做产品路线图，它对比三种方案的风险和成本；我写了一堆季度复盘材料，它提炼出关键结论。这些都是需要理解上下文、做权衡和输出结构化内容的工作，DeepSeek 做得不错。

有人会问为什么不用 GPT-4 或者 Claude。说句实话，我在多轮测试中发现 DeepSeek 和它们差距不大，尤其在中文领域甚至更细腻。更重要的是它可以本地部署，敏感的公司数据不出门，心里踏实。所以推理层我坚持用 DeepSeek。

2.4 三者的连接逻辑

整个 OS 的工作流简单来说是这样：Obsidian 里的笔记是原始输入；我通过 Codex 执行脚本来抽取、转换和加载数据；处理完的数据喂给 DeepSeek 做分析推理，推理结果以 Markdown 形式写回 Obsidian。

举个例子：每周五我会让 Codex 跑一个脚本，把本周所有“客户访谈”标签的笔记抽取出来，合并成一个临时文件。然后 DeepSeek 读取这个文件，生成三条关键洞察和下周建议。最后 Codex 把结果写入 Obsidian 的“周复盘”笔记中。整个流程文件流转清晰，每一步都能复现。

这套设计的核心原则就是：可编程、可追踪、可替换。即使哪天我不想用 Codex 了，接口不变，直接换其他工具；DeepSeek 效果不满意了，也可以换成其他模型。Obsidian 只是文件容器，完全没有锁定风险。这个架构的价值远大于任何一个单一工具的选型。

3. 核心细节解析与实操要点

3.1 Obsidian 侧的配置细节

要让 Obsidian 成为 OS，不只是建几个文件夹那么简单。我在实践了几个版本后，最终优化出一套配置方案：

• 文件夹结构：使用01 收件箱、02 项目、03 客户、04 运营、05 知识库、06 复盘六个一级目录。收件箱用于快速捕获想法，后续经过处理再归档到对应目录。
• 属性系统：每篇笔记的 YAML frontmatter 中必须包含type（类型）、status（状态：idea/doing/done）、date（日期）、tags（标签）。这套结构化字段是 Codex 能批量操作的关键。
• 模板插件：用 Obsidian 自带的模板插件统一新建笔记格式。比如客户访谈模板包含公司、联系人、需求、痛点和下一步行动。
• Dataview 插件：用于在笔记中动态展示数据。比如某客户的所有交互记录可以在笔记首页自动列出来。不过注意，Dataview 查询复杂了会拖慢 Obsidian 性能，笔记超过几千篇时要小心。

这些配置看起来基础，但很关键。因为 Codex 脚本是通过解析 frontmatter 和 tag 来管理任务的。如果笔记结构不统一，后面所有自动化的精确度都会大打折扣。所以我从一开始就坚持每个笔记都必须有完整的属性。

3.2 Codex 侧的任务设计

Codex 用起来容易，但用得好需要一点设计。核心经验是：每次给它一个明确的任务描述 + 输入路径 + 输出路径 + 约束条件。

比如我会这样说：“读取02 项目/某项目/文件夹下所有 status 为 doing 的笔记，按优先级从高到低排序，把结果输出为一个 Markdown 表格，保存到06 复盘/项目优先级.md。”这个任务不涉及任何模糊判断，Codex 完美执行。

但如果你只是说“帮我整理一下项目进度”，它就会自由发挥，做出的格式可能不符合运维要求。所以给 Codex 下任务要像写函数参数一样精确。习惯了这种协作方式后，效率反而比自然对话更高，因为你知道它看到什么、输出什么。

另外一个关键点：Codex 的文件操作会影响真实数据，所以必须在任务里明确是否允许覆盖文件，是否需要在执行前备份。我吃过一次亏——它把一个写满记录的笔记覆盖了，导致数据丢失，后来就养成了在涉及写操作时，先让 Codex 自动复制一份带时间戳的备份的习惯。

3.3 DeepSeek 侧的工程设计

DeepSeek 的 API 调用比较简单，但真正实用需要包装一层。我写了一个 Python 工具函数，专门处理“读取本地文件 → 发送给 DeepSeek → 返回结构化结果”。

在调用 DeepSeek 时，我最看重的是温度参数和提示词结构。做数据分析时温度设为0.2左右，保证输出稳定；做头脑风暴时温度调到0.7，让发散性好一些。提示词部分，我会在 system prompt 里明确规定输出格式，比如“只输出 Markdown 列表，不要多余解释”，这样结果直接回流到 Obsidian，省去人工清洗。

另外，DeepSeek 上下文长度有限制，所以长文档要先做摘要分段再喂进去。我通常用 Codex 预先做一遍文本压缩，把核心段落保留，再交给 DeepSeek 做归纳。这个“先裁减、后推理”的策略已经稳定运行很久。

3.4 连接器与自动化的实现思路

连接器是整个 OS 的粘合剂。我用 Python 脚本把 Obsidian 和模型 API 串起来。最简单的流程只需要一个脚本、几个函数。

第一步是读文件。使用 Python 标准库os和glob遍历 vault 下所有.md文件，读取 frontmatter 和正文。也可以用yaml库解析属性。

第二步是处理文本。这一步可能调用 Codex API 或者本地写好的文本处理函数。如果任务是“找出所有提到退货政策的客户反馈”，完全可以用关键词匹配解决，不一定要调用大模型，节约成本。

第三步是生成内容。把处理后的数据通过 requests 调用 DeepSeek API，传入模型名称、上下文、温度参数，收到响应后保存到指定路径。

第四步是写回笔记。用pathlib模块新建或覆盖文件，写入 Markdown 内容。如果要保证可追溯，就在笔记末尾添加“生成时间”和“调用模型信息”的属性。

这个思路不复杂，门槛在于你愿不愿意花时间把几个模块拼起来，并且处理好异常情况，比如 API 超时、文件编码问题、模型返回 JSON 解析失败等。

4. 实操过程与核心环节实现

4.1 第一步：搭建 Obsidian 基础结构并制定规范

我当时花了两个小时手动把文件夹和笔记模板都建好。这步不建议跳过，因为后边所有自动化都依赖它。

在终端里进入 vault 目录，执行：

mkdir -p "01 收件箱" "02 项目" "03 客户" "04 运营" "05 知识库" "06 复盘"

然后在 Obsidian 设置里打开模板插件，指定模板文件夹，创建客户访谈模板.md：

--- type: customer-meeting status: doing date: {{date}} tags: - 客户 - 访谈 company: "" contact: "" --- # 访谈记录 ## 背景 ## 需求 ## 痛点 ## 结论 ## 下一步行动

这样的规范能让后续所有文档结构如出一辙，Codex 脚本统计起来非常方便。如果没有这套规范，AI 很难从一大堆自由笔记里提取出精确信息。

4.2 第二步：配置 Codex 并验证文件操作能力

Codex 的接入方式随着工具变化会有些差异，但思路一致：让 Codex 能够读取和操作当前文件系统。

我的做法是在项目目录下初始化一个工作区，给 Codex 赋予该目录的读写权限，并配置好 .gitignore 忽略临时文件。然后测试一句话任务：“列出当前目录下所有文件夹和 Markdown 文件，统计每个文件夹的文件数量，输出为表格。”如果它能正确输出，说明环境通了。

接着测试更复杂一些的真实任务：“在01 收件箱中创建一个新笔记，名为未命名-今天日期，内容包含当天新闻摘要。”这个测试验证了 Codex 的日期能力和文件创建能力。我强烈建议第一次使用的人花半小时把这些基础操作验证清楚，后面就会非常顺畅。

4.3 第三步：部署 DeepSeek API 并设计调用函数

去官网注册后获取 API key，然后把 key 写入环境变量，不要写死在代码里。我用的是：

export DEEPSEEK_API_KEY="sk-xxxxxxx"

Python 调用代码示例：

import requests import os def deepseek_chat(prompt: str, temperature: float = 0.3) -> str: api_key = os.environ["DEEPSEEK_API_KEY"] url = "https://api.deepseek.com/chat/completions" headers = {"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"} payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个严谨的分析助手。只输出 Markdown，不要额外解释。"}, {"role": "user", "content": prompt} ], "temperature": temperature } resp = requests.post(url, json=payload, headers=headers, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这个函数我封装在最基础的工具层。后面所有调用 DeepSeek 的脚本都复用这个函数，不用到处复制 API 代码。有一点值得注意：deepseek-chat是最常使用的对话模型，也可以选择推理能力更强的版本，根据自己的场景来。

4.4 第四步：实现“客户反馈自动周报”全流程

这个功能是我最先跑通的，很有代表性。需求是：每天把与客户相关的访谈、会议、聊天记录写在 Obsidian 笔记里，周五自动生成一份客户反馈周报。

整个任务拆成三步脚本：

第一步，用 Codex 写一个提取脚本，找出本周所有type: customer-meeting的笔记，抽取company、demand、painpoint字段，合并成一个文本文件temp/weekly_customers.md。这个脚本用 Python 遍历目录，读取 frontmatter，用yaml解析，再筛选日期。稍微懂点 Python 的人都可以写。

第二步，调用 DeepSeek 对合并文本进行归纳。系统 prompt 设为“你是客户洞察分析师，请从以下访谈记录中提炼出三个主要问题、三个潜在机会和行动建议”。返回结果写入06 复盘/客户周报-本周日期.md。

第三步，用 Codex 做后处理。检查生成的文件中是否包含团队成员名字、是否缺失日期，如果缺失自动补充。同时把状态从 doing 改成 done。

这套流程跑通后，原本每周五一个小时的整理时间缩短到十分钟，而且结果更加规范统一。后续我增加了更多类似任务：销售周报、项目风险追踪、知识库索引生成。

4.5 第五步：用工作流编排让自动化自己跑起来

单个功能跑通后，下一步就是编排。我尝试过几种方案：系统自带的任务计划程序、开源的流程编排工具、甚至直接让 Codex 写一个调度器。

最简单稳定的是直接写一个 shell 脚本，按顺序调用三个 Python 脚本：

python scripts/extract_customers.py python scripts/analyze_with_deepseek.py python scripts/generate_report.py

然后在任务计划程序里设置每周五 17:00 执行。这样整个 Company OS 就像一个定时任务系统，Obsidian 负责输入，Codex 负责中间处理，DeepSeek 负责决策输出，最后又归档到 Obsidian。

更进阶的做法是给每个脚本加日志和错误通知。比如用logging模块记录执行时间、输入文件、API 调用状态，如果运行失败就发一封邮件提醒。我在实际运行中遇到过 API 偶尔超时的场景，如果没有日志几乎找不到原因。加了这个机制后，排障效率大幅提升。

5. 常见问题与排查技巧实录

5.1 Obsidian 笔记编码导致乱码

实际问题表现：Codex 脚本读取某些笔记时出现中文乱码。原因是 Obsidian 默认保存的文件编码是 UTF-8，这本身没问题，但有些通过第三方同步或者 Windows 记事本编辑过的文件，可能被保存为 GBK 编码。

解决办法：在读取文件时统一指定编码。Python 里使用：

with open(path, "r", encoding="utf-8") as f: content = f.read()

如果仍然报错，可以在读取时加容错逻辑，尝试 utf-8 失败后用 gb18030 解码。这个问题看起来小，但一旦触发就会让模型分析的结果全是乱码，特别坑。

5.2 Codex 修改文件导致数据丢失

有一次我想让 Codex 批量把某个文件夹里的笔记都加上一个标签，它直接覆盖了原始文件，但标签插入位置不对，把部分正文内容给删掉了。从那以后，我所有涉及写操作的脚本都会先复制一份原文件到_backup目录，并给文件名加时间戳。

现在我的通用做法是在每个写脚本开头加一行指令：备份指定目录。虽然占用一点额外存储空间，但安全感提升了很多，尤其是公司运营数据这种东西，丢一次可能就再也没法补救。

5.3 DeepSeek 输出格式不稳定

虽然设置了 system prompt 输出 Markdown，但有时候模型还是会输出额外的解释，或者把表格格式写错。遇到这种问题，我一般会：

• 在 user prompt 里再强调一遍输出要求，比如“严禁输出任何表格之外的内容”
• 让 Codex 在后处理里面做格式校验，不符合要求就重跑一次
• 尽量把请求拆小，一个请求只做一类任务，输出格式可控性更高

经过一段时间调教后，我现在 90% 的请求都能一次得到可用的格式。剩下 10% 的靠后处理脚本兜底。

5.4 API 费用不可控

DeepSeek 虽然便宜，但无限调用也会产生费用。如果不对调用做预算控制，月底账单会很意外。

我的做法是：在脚本里记录每次调用的 token 数和费用，定期汇总到 Obsidian 的一张表格中。这样每次跑完自动化我都能看到当天花了多少钱。另外对不需要推理能力的任务，尽量用基于规则的脚本替代模型调用，降低整体成本。比如关键词归类和标签匹配完全不需要大模型，用代码就能实现。

5.5 知识库膨胀导致 Obsidian 卡顿

当笔记数量超过几千篇后，Obsidian 的搜索、Dataview 查询会变慢。我的解决办法是清理行动：

• 定期将超过半年的“已完成”项目笔记归档到一个单独的“Archive”文件夹，不参与日常索引
• 禁止 Dataview 在大量笔记中做全局查询，改成在具体项目笔记里用局部查询
• 把附件图片统一放到 vault 外的 assets 文件夹，用软链接引入，减少索引负担

这套机制跑下来，Obsidian 的性能基本保持在新建初期那样流畅。如果不做这些清理，后期打开一个项目笔记要卡好几秒，非常影响体验。

5.6 自动化任务互相冲突

同时跑两个脚本时，如果它们都去修改同一篇笔记，就会出现覆盖冲突。最典型的是周报脚本和知识库整理脚本同时跑，都把结果写到同一个复盘文件里。

解决方案：给任务设计时增加互斥机制，或者错开运行时间。比如周报安排 17:00 跑，知识库整理安排 18:30 跑。如果必须同一时间，我会在脚本里加文件锁（例如检查.lock文件是否存在），防止两个进程同时写。在实际生产环境中，我用错峰运行更简单，完全不用写锁。

6. 实操心得与扩展建议

6.1 这套组合最核心的价值是“思维文件化”

用 Obsidian 做 Company OS 这么长时间，我最深的一个体会是：它的价值不在于记录本身，而在于把每一条思考、决策、复盘都变成可程序化处理的数据。

以前我依赖脑子和聊天记录，信息一多就混乱。现在，任何时候冒出一个想法，我会建一条笔记；谈完一个客户，我会按模板记录；做完一个决策，我把推理过程和依据都写下来。这样一来，所有零散的东西都有了结构化出口，后续不管是 Codex 自动处理，还是 DeepSeek 做分析，输入质量都有保障。

有人觉得记录很麻烦，但当你建立起自动归档和自动整理的能力后，记录的成本其实很低，而收益是长期复利式的。不只是记录客户反馈，连公司内每个人的工作习惯、每周进展都能用同一套机制管理。

6.2 想快速上手可以怎么做

如果你不想一上来就搭全链路，给你一个低门槛的路径：

第一步，先在 Obsidian 里建好两个目录：01 收件箱和06 复盘。其他目录等用到了再建。

第二步，把日常记录全部写进 Obsidian，坚持一周，先培养笔记习惯。

第三步，写一个最简单的脚本，让 Codex 每周帮你统计收件箱中有多少没归档的笔记，生成提醒清单。

第四步，接入 DeepSeek，对一周的笔记做一次自动摘要。

等这四步都能跑顺了，你再逐步加入项目管理和客户管理，慢慢扩展成完整的 Company OS。不要追求一步到位，先让最小的闭环运转起来，然后再迭代。

6.3 后续还可以扩展的方向

这套架构的扩展空间很大，我目前在研究的方向包括：

• 语音输入：用手机上的语音转文字工具快速创建笔记，再批量清洗归档
• 自动化会议纪要：参会录音转文字后，由 Codex 抽取动议，DeepSeek 生成执行清单
• 财务周报：把记账软件的导出数据放到 Obsidian，让模型分析现金流并进行预测
• 团队知识库共享：用 Git 同步 vault 到团队成员，每个人都能在本地使用自己的 Obsidian 编辑，再通过 Codex 合并冲突

这些方向本质都不复杂，核心仍然是“文件 + 执行 + 推理”的铁三角。你已经搭好了底座，后续只需要往里面添加模块而已。

最后分享一个小技巧：不要让你的 Company OS 一开始就大而全，否则很容易因为配置复杂而放弃。先从一件你最重复、最痛苦的事情开始自动化，等它真正生效，让你尝到甜头，你自然会有动力继续扩展。我在实际搭建这套系统的过程中，也经历过三天打鱼两天晒网，但坚持到第一个自动周报跑通后，剩下的路就顺了。