企业官网建设流程全解析

说真的，两年前我还是个典型的知识囤积症患者。网盘里堆着几十个PDF，微信收藏躺着上百篇文章，本地文档散落在桌面和下载目录，真到写方案或者做复盘的时候，满世界翻不出一句能用的东西。后来我把整套个人知识管理方案重构为 Obsidian + WorkBuddy + Gitee 的三联组合，前后花了一周把链路全部跑通，坚持用了半年多，笔记从几百条积累到几千条，检索和复用效率反而越来越高。这篇就把完整搭建思路、关键配置和踩过的坑一次性写清楚，适合那些笔记常年吃灰、想把 AI 真正用进知识管理流程的朋友直接照做。

1. 这套组合到底解决了什么问题

1.1 个人知识库的三大痛点

先别急着装工具，想清楚痛点比选工具更重要。我自己把知识管理的麻烦总结成三条，基本覆盖了大多数人的情况。

第一条是“散”。笔记分布在各个平台：临时想法记在手机备忘录，工作资料放在公司电脑，深度阅读的摘抄在另一款笔记软件里，微信收藏里还躺着几十篇链接。真要用的时候，得同时开五六个应用去翻，查找成本极高。这条不解决，后面任何优化都是白搭。

第二条是“死”。很多笔记只是把别人的内容复制粘贴过来，记完就再也不看，也没有和已有的笔记产生任何关联。知识之间是割裂的，没法形成自己的观点和体系。这种笔记堆积得越多，反而越让人焦虑，因为它没有复利效应。

第三条是“险”。本地文件可能因为硬盘损坏、电脑丢失而彻底消失；在线笔记平台可能调整收费策略、停止服务，甚至导出格式受限。换句话说，数据不掌握在自己手里的知识库，本质上是在替别人打工。

这条三联组合给出的解法很直接：Obsidian 负责“管”，WorkBuddy 负责“想”，Gitee 负责“保”。三者各司其职，把散、死、险三个问题分别按死。

1.2 三个工具的分工逻辑

Obsidian 是知识库的主载体。它基于本地 Markdown 文件，所有笔记都以.md文本文件的形式存你硬盘上，意味着不开软件也能读，换个工具也能迁移，数据完全自主。它的双链和知识图谱能力，能把零散笔记编织成一张真正的关系网络，这是它和传统文件夹式笔记最本质的区别。

WorkBuddy 是给知识库外挂的“AI 副脑”。它的角色不是替代 Obsidian，而是和 Obsidian 打配合。我在 WorkBuddy 里同时配置了多家大模型服务的接口，用来做摘要提炼、资料翻译、润色改写、生成标签、提问追问这些脑力活，再把成果回填到 Obsidian 里。简单说，Obsidian 是沉淀知识的仓库，WorkBuddy 是帮你加工知识的工厂。

Gitee 则是知识库的保险箱加传输带。它提供 Git 版本管理，每次提交都会留下历史快照，误删了旧版本也可以随时找回；远程仓库又把本地知识库同步到了云端，换电脑、换手机都能无缝衔接；还能借助 Gitee Pages 做对外内容发布。我选 Gitee 选了很久，核心原因是国内访问稳定，私有仓库免费，和 Git 生态完全打通，对个人用户非常友好。

打个不严谨的比方，Obsidian 是书架，WorkBuddy 是图书管理员，Gitee 是防火保险柜。书架负责摆得整齐，管理员负责帮你查资料、做摘要，保险柜负责防丢防意外。

1.3 为什么不是 Notion、GitHub 或其他方案

用过这套组合的朋友基本都绕不开一个疑问：Notion 不也能写笔记、接 AI、多端同步吗，为什么要折腾这三个工具？

我用 Notion 也有过比较长的时间，它的问题是数据绑定在云端，导出虽然能做但格式和链接结构会丢，而且离线基本没法用。更关键的是，Notion 的 AI 能力和本地文件的深度结合比较有限，很难做到“读取本地全量笔记来做上下文理解”。Obsidian 就不存在这个问题，所有文件就在本地，任意 AI 工具都能直接读取处理，和 WorkBuddy 的配合几乎没有摩擦。

也有朋友推荐直接用 GitHub 私有仓库来同步 Obsidian，这个思路是通的，GitHub 本身很好，但国内网络访问时快时慢，个人私有仓库每天读写几十次，体验不够稳定。Gitee 在国内的访问速度更稳，而且不需要额外折腾网络配置。如果你人在海外，那用 GitHub 也没问题；人在国内长期用，Gitee 会更省心。

把对比列成一张表可能更直观：

综合下来，这套组合最适合看重数据自由、喜欢折腾工具链、且希望 AI 深度参与知识加工流程的人。如果你只想开箱即用地记点东西，Notion 类工具其实更省事；但如果你想打造一个能真正复利、能长期积累的第二大脑，这套组合的潜力要大得多。

2. 环境准备与基础搭建

2.1 Obsidian 安装与知识库初始化

Obsidian 的安装本身不复杂，从官网下载安装包，一路下一步即可。有一点要特别注意：尽量从官网下载，别用搜索引擎里转存的旧版本，旧版本可能缺少最新的安全更新，还会影响插件兼容性。

安装完成后，第一次启动会要求选择“创建新库”还是“打开已有文件夹”。库就是一个普通文件夹，里面装你的 Markdown 文件和.obsidian配置目录。我把库建在了D:\KnowledgeBase，没有放在 C 盘系统盘，原因很简单——系统盘空间金贵，而且重装系统时容易误删。

新建库之后，我建议不要急着写笔记，先把顶层目录规划好。我的目录结构是参考 PARA 方法调整过的：

• 00-Inbox：临时想法、待整理素材
• 10-Sources：读书笔记、文章摘抄、课程记录
• 20-Projects：按项目维度归档，一个项目一个文件夹
• 30-Areas：长期关注的领域，比如 AI、写作、产品
• 90-Archive：已归档的旧笔记

这套结构的好处是检索路径很清晰，配合 Obsidian 的标签和双链，新笔记进来基本不会迷路。目录规划好了，再到“设置→核心插件”里把需要的功能打开。我个人必开的是“文件列表”“标签”“图谱”“模板”“出链”。官方核心插件稳定可靠，尽量优先用原生的，社区插件一台一台加。

写第一篇笔记的时候，顺手试试两个 Obsidian 的标志性操作：用[[双链]]把新笔记和已有笔记关联起来；用#标签给笔记打上主题标记。这两个操作看起来简单，却是知识库从“文件夹堆文件”走向“知识网络”的关键。

2.2 WorkBuddy 安装、语言切换与缓存目录调整

WorkBuddy 是一款桌面 AI 工作台软件，核心是把多个大模型服务统一放到一个界面里管理，避免在多个网页之间来回切换。安装同样走官网下载，支持 Windows 和 macOS，装完首次启动会进入设置向导。

下载安装后如果发现界面是英文版，别慌。在软件主界面的设置菜单里找到 “Settings” 或者 “Preferences”，语言选项一般在 “General” 或 “Appearance” 分类下，把语言切换为“简体中文”，然后重启软件。部分版本切换后需要完全退出进程再重开，否则语言包没有完全生效。如果设置里找不到语言选项，检查一下安装目录里有没有language或locale相关的配置文件，手动改配置也能实现。

还有一个很容易被忽视但很重要的设置项：缓存目录。WorkBuddy 在运行过程中会产生大量缓存文件，包括 AI 对话记录、临时生成的图片、模型加载数据等等。默认情况下缓存目录放在系统盘的用户目录下，用久了 C 盘空间会肉眼可见地减少。

我的处理方式是在设置里找到“存储”或“缓存”相关选项，把缓存路径改到D:\WorkBuddyCache。需要注意两点：一是修改后必须重启软件才生效；二是新路径不要放在有权限限制的系统目录下，否则软件写不进去会报错。如果某个版本的 WorkBuddy 没有提供界面修改入口，那就打开安装目录下的配置文件（一般是config.json或db.config），查找包含cache或path的字段，手动改成目标路径后保存重启。改完缓存目录后，C 盘的压力明显小了很多，这是长期使用非常加分的一个细节。

2.3 Gitee 仓库创建、开源许可证与 SSH 密钥配置

Gitee 的注册登录就不多说了，登录后进入“新建仓库”页面。仓库名建议和你的知识库一致，比如KnowledgeBase，方便对应。可见级别根据自己的需求选择私有或公开。私有仓库只有自己能看到，公开仓库任何人都能访问，如果你的知识库里有个人心得、职场记录，强烈建议选私有。

关于开源许可证，只针对公开仓库有实际意义。私有仓库不需要也不应该选择许可证，因为许可证本质是声明他人可以使用你的代码/内容的条款。如果知识库未来想公开分享，三个常见选项可以这样选：

创建完仓库之后，最重要的一步是配置 SSH 密钥。 SSH 密钥相当于你电脑和 Gitee 之间的身份凭证，配置好之后推送代码就不用反复输入账号密码了。

打开终端（Windows 上用 Git Bash 或 PowerShell），执行：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车即可，默认会在用户目录下生成.ssh文件夹。密钥生成后，把公钥内容复制下来：

cat ~/.ssh/id_ed25519.pub

复制完整输出，然后到 Gitee 的“设置→安全设置→SSH 公钥”页面，粘贴并保存。最后测试是否配置成功：

ssh -T git@gitee.com

如果看到类似 “Hi 用户名” 的欢迎语，说明 SSH 配置完成。第一次连接时终端会询问是否确认主机指纹，输入yes回车即可。

3. 三联组合的核心链路打通

3.1 用 Git 把本地知识库托管到 Gitee

工具都装好、仓库也建好了，接下来就是把 Obsidian 知识库和 Gitee 仓库接上线。整个过程就是标准的 Git 操作。

假设 Obsidian 知识库路径是D:\KnowledgeBase，先进入这个目录：

cd D:/KnowledgeBase git init git add . git commit -m "init knowledge base" git remote add origin git@gitee.com:你的用户名/KnowledgeBase.git git push -u origin master

如果 Gitee 仓库的默认分支是main，就把最后一句的master换成main。推送成功后，知识库的基础版本就备份到了 Gitee。

这里有一个特别关键的细节：.gitignore文件。Obsidian 的配置目录里有一个workspace.json文件，记录的是你最近打开过的面板和窗口布局，这属于纯本地的使用状态，不应该同步到远程库。如果不排除它，每次切换设备后布局都要重新适应，而且很容易产生冲突。我在知识库根目录创建了.gitignore文件，内容如下：

.obsidian/workspace.json .obsidian/workspace-mobile.json .trash/

注意保留.obsidian/plugins和.obsidian/themes这两个目录的同步，否则换一台电脑后插件、主题全部丢失，又得重新配一遍。

之后每次更新知识库，只需要执行三条命令：

git add . git commit -m "update" git push

刚开始会嫌麻烦，多推几次形成肌肉记忆之后就顺手了。为了降低提交压力，我后来还写了个简单的脚本，一键完成 add、commit、push 三步操作，效率高很多。如果不想用脚本，也可以直接在 Obsidian 里安装第三方的 Git 插件，界面化操作，对新手更友好。

3.2 WorkBuddy 多 AI 协作与 Obsidian 的搭配用法

WorkBuddy 最核心的玩法是“多 AI 协作”。很多人觉得 AI 对话工具不就是打几个字的事，但真正用起来才会发现，把多个模型统一到工作台里，效率提升是几何级的。

配置方式很简单，在 WorkBuddy 的模型管理页添加你已申请的服务商 API Key 即可。各家大模型服务都有对应的接口地址和模型名称，照着填就好。WorkBuddy 的一大好处是支持 OpenAI 兼容接口格式，所以几乎任何一家主流服务都能接进来。

配置好之后，我用的最多的场景有三个。

第一个是外文资料翻译和提炼。做技术调研时经常要啃英文文档，整篇丢给 AI 翻译，输出太长且容易超上下文窗口。我的做法是把文档关键段落粘贴到 WorkBuddy，用一条固定的提示词：“你是一个资深译者，请将以下内容翻译成中文，保留专业术语，并附一个三句话的内容摘要。” 翻译结果直接回填到 Obsidian 的对应笔记里，关键词和链接一并保留。

第二个是写文章前的思路整理。我在 Obsidian 里建好选题笔记，把零散想法写进去，然后把这些内容交给 WorkBuddy 里的一个模型，让它生成文章大纲；让另一个模型站在读者的角度提出质疑和补充问题；最后由第三个模型把前两步结果合并成结构化草稿。不同模型风格侧重点不同，这种“分工式”用法比单模型反复对话要聪明得多，也更接近 Agent 的运作思路——规划、执行、校对分别由不同角色承担。

第三个是自动生成标签和双链建议。笔记写完后，把正文放到 WorkBuddy，用提示词：“请分析这篇笔记的主题，推荐 3-5 个标签，并给出 2-3 个可以关联的笔记主题方向。” 生成的标签我从来不会照单全收，只挑真正贴合内容的加入 Obsidian。标签宁少勿滥，否则知识库会被噪音淹没。

这里顺便聊一下上下文窗口。大模型的上下文窗口是有限的，意思是一次对话能“记住”的字符量有限，超出部分会被截断。所以别把一篇上万字的文档一次性丢进去，而是选关键段落或者让 AI 分段处理，这样输出质量会稳定很多。

3.3 Gitee Pages 与知识库的对外发布

知识库搭好之后，很多人会想把部分内容发布到网上，作为个人博客或者作品展示。Gitee 自带一个静态站点服务叫 Gitee Pages，原理是把仓库里的静态文件部署到它提供的域名上。开通方式是在仓库页面找到“服务”菜单里的“Gitee Pages”，按照提示选择分支和目录，提交后等待部署即可。

不过我自己的经验是：Gitee Pages 可以作为临时演示用，但不太适合做长期的主站。主要原因是需要按平台要求完成身份认证，而且审核流程和响应速度有时候不太理想，部署机制也比较脆弱。如果你要把知识库内容当成正式博客运营，更稳妥的方案是自己租一台轻量云服务器，或者使用对象存储服务托管静态页面。

实操上，我把 Obsidian 知识库里适合公开的部分导成 Markdown 和 HTML 文件，然后配置了一个简单的静态站点发布脚本，每次把指定目录推送到云存储上，几分钟内就能完成更新。这套方案自主性更强，还不用担心平台政策的波动。Gitee 在这个体系里的角色依然是“私人备份库”，最核心、最私密的知识资产都待在私有仓库里，公开的只是你愿意分享的子集。

3.4 双链、标签与 AI 内容的归档规范

很多人的知识库用了一段时间就乱成一锅粥，根源在于缺少归档规范。趁早期把规则定好，后面维护成本极低。

我建议每篇笔记的开头加上 YAML front matter，也就是用---包裹的元数据区域，Obsidian 原生支持，方便后续用 Dataview 或搜索做聚合。我常用的格式如下：

--- title: Obsidian 与 Gitee 同步实战 type: note tags: [AI/Obsidian, 工具链] date: 2025-01-15 source: 个人实践 ai_status: 已人工核对 ---

标签体系我推荐“主题/类型”两级结构。比如AI/Obsidian表示主题是 AI 且具体领域是 Obsidian，Article/翻译表示来源是文章、类型是翻译。主题词控制在 20 个以内，全部用英文命名避免中英文混用带来的检索问题。

还有一个很重要的规范是 AI 内容标注。我在前面提到 WorkBuddy 参与摘要、翻译、大纲，但这些输出不能直接混进知识库而不加说明。我的习惯是在每段 AI 生成内容的末尾加一行“AI 生成，已人工核对”，并保留原始出处链接。这么做的意义在于，AI 偶尔会一本正经地给出错误信息，人工核对自己是否真的理解了这段内容，其实是把别人的知识变成自己知识的过程。这个强制标注的步骤虽然麻烦，但能让知识库可信度大大提高，长期积累下来价值巨大。

4. 日常使用中的高频问题与排查实录

4.1 Obsidian 插件与主题安装失败的解法

用了 Obsidian 的朋友应该都遇到过这一幕：设置里想装一个社区插件，结果列表加载半天出不来或者干脆报错，尤其是想装 AnuPpuccin 这类热门主题时提示“无法安装”。这基本是网络连接第三方插件市场不稳定导致的。

我实测下来最稳妥的解法是手动安装。具体步骤：

1. 在 Gitee 或 GitHub 上搜索插件的官方仓库，进入 Releases 页面，下载最新版的 zip 压缩包。
2. 解压后，确认文件夹内有main.js和manifest.json这两个文件，这是插件的核心组成部分，缺少任何一个都无法加载。
3. 将该文件夹完整放入 Obsidian 知识库的.obsidian/plugins/目录下。如果发现.obsidian文件夹不可见，记得在系统文件管理器里开启“显示隐藏项目”。
4. 重启 Obsidian，到“设置→第三方插件→已安装插件”里启用它。

主题的安装方式类似，把主题文件夹放入.obsidian/themes/目录，然后在“外观”设置里启用即可。手动安装熟练之后，比在线安装还要快，而且完全不依赖插件市场的网络状况。值得提醒的是，安装插件和主题时注意版本兼容性，某些老插件不支持最新版 Obsidian，装完不生效也不要着急删，去 release 页面找一个与当前 Obsidian 版本同期发布的版本即可。

4.2 Gitee 上传与密钥配置的常见坑

Gitee 上传代码的报错，我把常见的几条列成速查表，直接对着排查：

我早期遇到最多的问题是failed to push some refs，原因是手机端或者另一台电脑提交过内容，本地没有拉取合并就直接推送。后来我养成了一个习惯：每次开工前先git pull，完工后立刻git push，把集中式的“攒一堆再推”改成分散式的“随时推”，冲突概率大幅下降。

另外还有一个小坑是公司网络干扰 SSH 的 22 端口，导致ssh -T git@gitee.com不通。这种情况可以改用 HTTPS 方式远程连接，或者尝试使用测试命令ssh -T -p 443 git@gitee.com验证 443 端口是否可用。Gitee 官方文档有详细的端口和地址说明，照着配一次就行。

4.3 WorkBuddy 使用中的疑难杂症

WorkBuddy 下载安装后是英文版的问题前面已经说过，直接进设置切语言。还有几个高频问题也一并记下来。

第一个是缓存目录修改后不生效。很多新手改了路径但发现 C 盘空间还在减少。检查三处：设置是否保存、是否重启软件、新目录是否有写入权限。有时候修改的是“临时目录”，但“模型缓存”是另一个开关，需要同时改。Waste时间最少的做法是改完后重启，然后观察目标目录下是否真的有文件生成，没有就继续翻设置。

第二个是多个 AI 模型配置好之后，部分模型调用报错。这个问题九成是 API Key 失效、额度耗尽或模型名称填错。某个服务商的模型命名规则比较特殊，名称前缀带版本号，填错一个字符就会报“Model Not Found”。解决办法就是回到服务商后台核对模型 ID，复制粘贴过来，不要手敲。

第三个是请求超时。同一个提示词，某些模型反应快，某些模型反应慢，这和模型本身的推理负载有关。我一般先切换成轻量模型跑第一轮，再用重量级模型做精调，在 WorkBuddy 里把不同模型分到不同会话，检索起来也方便。

第四个是提示词效果不稳定。同样的提示词，今天有效明天无效，多半是模型后台版本更新导致的。应对办法是不要迷信“万能提示词”，把常用提示词保存成模板，微调关键词即可。

4.4 多设备同步冲突的应对策略

多设备同步是这套方案最容易翻车的环节。我手机和电脑都装了 Obsidian，两个设备同时编辑同一篇笔记的情况时有发生。常规解决思路有三条。

第一，养成“先拉后推”的习惯。到第二台设备上打开工作台上，先执行一次git pull再开始写，写完马上git push。这个习惯能把冲突窗口压缩到最小。

第二，控制同时编辑的范围。同一时间只在一个设备上修改某个文件夹里的内容。比如白天在电脑上写项目文档，晚上用手机补充阅读摘抄，把写作和摘录拆到不同目录，冲突概率就会大大降低。这也是前面规划目录结构的原因之一。

第三，如果真的冲突了，Git 会在文件里插入冲突标记：

<<<<<<< HEAD 本地修改的内容 ======= 远程拉取的内容 >>>>>>> 分支名

这种时候不要慌，打开文件，手动保留正确的部分，删除冲突标记，再提交一次即可。Obsidian 里这类纯文本冲突处理起来很直观，比在线文档舒服多了。

还有一个额外建议：别把 Obsidian 的数据库目录本身当成一个整体到处拷贝。我的做法是始终以 Gitee 远程仓库为基准，本地目录只是它的一个工作副本。这样即使某台电脑彻底报废，重新拉取仓库就能满血复活。

5. 沉淀半年的实操心得与进阶建议

5.1 三套可以直接套用的工作流模板

这套组合最值钱的地方是可以固化成模板，每次直接往里面填内容就行。下面是我自己沉淀的三套工作流，覆盖了阅读、写作和复盘三个高频场景。

第一套，读书笔记流。每次读完一本书，先在 Obsidian 的10-Sources下新建一条笔记，把书的基本信息填进 YAML front matter，包括书名、作者、主题标签。摘抄原文时，每段摘抄都标注页码和出处。读完后，把摘抄丢给 WorkBuddy，让 AI 整理出全书论证主线，并生成三到五个问题留给读者思考。我会把 AI 整理出来的结构和自己的观点做一遍交叉验证，然后更新同一篇笔记，加上双链指向相关的旧笔记。

第二套，项目周报流。每周五下午，我把这一周在 Obsidian 里记录的工作日志、会议要点、问题清单汇总，交给 WorkBuddy 生成周报草稿。提示词大致是：“提炼过去一周的关键进展、阻碍和下一步计划，用条目式输出，不要寒暄。” 生成后人工检查一遍，补充细节，最后同步到项目文件夹。这套流程省掉了大量重复劳动，而且周报素材完全来自知识库，不会出现“这周干了啥想不起来”的窘况。

第三套，技术调研流。接到一个新技术调研任务时，先建一个20-Projects下的调研笔记，让 AI 先在 WorkBuddy 里生成一个大纲和关键词清单。拿着关键词去搜索、采集资料，把收集到的内容分段落粘贴回笔记，再用 AI 逐段翻译、总结、对比。最后把结论写成一篇结构化笔记，并加好相关标签和双链。整个过程所有原始资料和中间产出都在 Obsidian 里留痕，下次回头查时能完整复原研究路径。

5.2 值得长期坚持的几个使用习惯

工具链顺手之后，习惯就成了决定知识库上限的因素。我踩了半年坑之后总结出四条：

第一条，每日记录必须有出口。不需要写长篇日记，每天花十分钟，把当天学到的知识点、发生的关键事件、产生的想法记到00-Inbox里。关键是不要直接删除或忽略，每周末把这些碎片归入正式目录。这个“流动→沉淀”的过程是知识库持续生长的动力。

第二条，标签一定不要贪多。我见过有人打了几百个标签，结果搜的时候比不搜还乱。标签的本质是检索入口，不是分类系统。每篇笔记三到五个标签足够，并且严格遵循主题/类型两段式结构。宁可少打标签，也不要滥打标签。

第三条，定期回溯旧笔记。我的节奏是每两周挑一批旧笔记，快速浏览一遍，更新已经过时的信息，剔除已经没有价值的内容。Obsidian 的图谱视图在这里特别好用，能直观看到哪些笔记被冷落了，哪些笔记是知识网络中的枢纽节点。

第四条，敏感信息不建议入库。虽然 Gitee 私有仓库相对安全，但只要是上云的内容，就有泄露的可能。个人日记、账号密码、重要证件信息等，最好留在本地不推送，或者单独用一个本地加密库来放。知识库追求的是“可复用的智慧”，不是隐私保险柜。

5.3 后续可以扩展的方向

这套组合的扩展空间很大，提几个我尝试过且效果不错的方向，给大家做个参考。

Obsidian 生态里最值得折腾的插件是 Dataview。利用 YAML front matter 里设置的元数据，Dataview 可以自动生成列表和表格。比如把全部笔记按标签汇总，自动统计每个主题的笔记数量，甚至生成一个“最近 30 天新增笔记”的自动列表。配上 Templater 插件，还能实现新建笔记时自动套用模板、自动填充日期和标签，把重复性操作降到最低。

WorkBuddy 层面可以进一步探索 AI 自动化流程。比如把 Obsidian 的导出文件丢给 WorkBuddy 做定时分析，每周自动生成知识库质量报告；或者把每日记录自动分类归档，减少手动整理的工作量。多 AI 协作的思路一旦建立起来，能做的自动化场景会越来越多。

还有一个已经被不少人玩起来的方向是打通 Obsidian 和日常沟通工具。网上有飞书连接 Obsidian 的方案，也有人做微信到 Obsidian 的桥接工具，核心思路都是把聊天中的零散灵感自动导入到 Inbox。我自己目前用的是一个简单的 API 方案，把重要消息转发到 Obsidian 的临时收件箱，效果不错。Typora 我也还在用，但场景完全不同——Typora 更适合沉浸式纯写作，Obsidian 才是知识管理的核心场所。两种工具各有定位，配合着用体验反而更好。

最后说一个我自己的小习惯：每次用 AI 处理完内容，我都会在笔记末尾加一行“AI 生成，已人工核对”。这不是仪式感，而是因为 AI 出错的时候太自然了，你不主动验证就会被带偏。这套三联组合最大的价值，不一定是让你记更多，而是让你记下来的东西在真正需要的那一刻，能稳定地被找到、被调用、被重新组合成新的产出。工具只是起点，知识库是靠每一天的记录和每一次的思考慢慢用出来的。