企业官网建设流程全解析

1. 项目概述：当“研究”这件事本身也需要被设计

如果你近半年一直在关注AI圈或者效率工具圈，大概率见过“OpenResearch”这个名字——有人把它当成一个开放科学运动的口号，有人把它当作一套开源的科研工具链，还有一些人，干脆用它来命名自己手头那个整理文献、跑实验、写笔记的本地项目文件夹。

我属于第三种。今天想聊的，不是某一个具体产品，而是一套可以落到实处的“开放研究”工作流：即怎样把文献管理、实验记录、写作输出和版本管理这四件事，用一套开源、本地优先、可持续维护的体系串起来。换句话说，你不需要花一分钱，不需要把数据交给任何一家云厂商，就能搭出一套属于自己的研究基础设施。

这套东西适合谁？如果你在做毕业论文、在写技术调研报告、在搞独立开发前的竞品分析，或者只是想把平时零散的阅读变成能复用的知识资产，这篇文章都能给你一套可抄作业的方案。我自己踩了快两年的坑，换过三套工具组合，最后沉淀下来的这套流程，至少在目前看来，是稳定性、迁移成本和维护心智最低的方案。

提示：下文所有内容基于我个人的实际使用经验。工具选型不一定适合所有人，但思路和流程设计是通用的。

2. 整体设计思路：为什么“开放”比“免费”更重要

先说一个容易混淆的概念。OpenResearch里那个“Open”，重点从来不是“不要钱”，而是“不锁死”。一套研究系统最怕的不是功能少，而是你用了三年，积攒了500篇文献笔记之后，那个笔记软件突然宣布停止维护，或者把免费额度砍掉一半。真到那时候，迁移成本高到你可能想放弃整个知识库。

所以我在设计整套流程时，只坚持三个原则：

第一，数据格式要开放。所有笔记用Markdown纯文本存储，文献元数据用BibTeX，图片和附件用普通文件夹管理。这些格式随便用什么文本编辑器都能打开，哪怕十年后现在所有工具都消失了，你的数据依然可读。

第二，数据位置要本地。全部数据放在本地磁盘的同一个根目录下，云同步只是备份的手段，不是数据存在的前提。我会用Syncthing做局域网设备间的同步，用Git做历史版本管理，但这些都是“附加保险”，不是“唯一副本”。

第三，工作流要声明式。意思是，你的研究进度、待办事项、阅读笔记都应该是某种文本文件里的一段结构化内容，而不是某个软件界面里的一颗按钮。这样你随时可以切换工具，只要新的工具能读文本文件。

这套思路本质上是在做“反脆弱”设计。学术研究或者深度调研通常是一个以月甚至年为单位的长期工程，你投入时间越长，数据就越值钱。值钱的东西，不应该放在一个随时可能消失的平台上。

另外，为什么我没有选择Notion、飞书这类一体化工具？不是它们不好，而是它们的“一体化”恰恰是问题所在——它们把数据托管在别人服务器上，把格式锁在自家数据库里。对快速协作来说很方便，但作为长期研究仓库，风险敞口太大了。

2.1 核心需求拆解：研究这件事到底需要什么工具

在设计具体方案之前，我先把自己做研究时会遇到的真实任务列了一个清单：

• 读论文时想划重点、写批注，之后能快速找回来
• 读过的文献之间要能互相跳转，形成“引用网络”
• 做实验时要记录参数、结果和当时的想法，且不能事后篡改
• 一个项目结束后能生成整洁的阅读列表或参考文献
• 换电脑时，能在半小时内恢复整个工作环境

把需求拆解为“输入—存储—处理—输出”四层之后，工具选型就清晰了：

• 输入层：Zotero负责抓取和整理文献元数据，配合浏览器插件一键保存网页
• 存储层：一个名为OpenResearch的本地文件夹，所有数据以标准格式存放
• 处理层：Obsidian负责笔记的阅读、链接和知识提取
• 输出层：Pandoc负责把Markdown笔记转换成Word、PDF或HTML

这个分工很明确：每个工具只干一件自己最擅长的事，彼此之间通过标准格式衔接，互不绑架。就算某一个工具挂了，替换成本可能只有半天。

3. 核心工具链解析与选型考量

我用了两三个月反复试错才确定这组工具组合。下面把每个环节的选型理由和容易踩的坑展开说说。

3.1 文献管理：Zotero为什么是长期主义者的首选

市面上文献管理工具不少，EndNote、Mendeley、Zotero是三巨头。EndNote收费且格式封闭，Mendeley被Elsevier收购之后云同步的免费额度越来越小，Zotero是唯一一个开源、免费、数据全在本地、且有活跃插件生态的选项。

我用Zotero最顺手的是三点：

一是浏览器插件抓取能力极强。在arXiv、Nature、Google Scholar、知网等绝大多数平台上，点一下插件按钮，论文的标题、作者、期刊、DOI、摘要就自动抓好了，连PDF附件都会一并保存。

二是文件夹和标签系统灵活。我习惯按“项目—子主题”建目录，同时用彩色标签标注阅读状态：红色是“待精读”，黄色是“在读”，绿色是“读完且有笔记”，紫色是“要在最终稿里引用”。

三是插件生态能补齐几乎所有短板。比如Better BibTeX插件可以自动生成稳定的引用键，每次导出BibTeX时格式都可预测；ZotFile插件能把PDF附件自动重命名并按规则分类存放；配合一个开源插件还能在PDF阅读界面直接做高亮批注，批注会自动同步回笔记库。

也要说一下我不太满意的点：Zotero自带的PDF阅读器目前只支持做高亮和注释，还做不了真正意义上的“双链标注”。我的做法是——Zotero负责“管”，Obsidian负责“记”，中间用一条路径打通。

注意：Zotero 6 之后的版本已经内置了PDF阅读功能，但如果你需要把阅读批注自动导出到Obsidian，必须使用带“Zotero Integration”插件的配置。安装插件时建议去Zotero官网的插件商店，不要从第三方网站下载，避免恶意脚本。

3.2 笔记与知识管理：Obsidian的本地Markdown哲学

Obsidian的核心卖点是一句话：你的笔记就是一堆本地Markdown文件，软件本身只是一个读取这些文件的“外壳”。这意味着，哪怕有一天Obsidian不更新了，你的笔记依然躺在本地的文件夹里，用vscode、Typora、甚至Windows自带的记事本都能打开阅读。

我在Obsidian里的实践主要围绕三个功能展开：

第一是Wiki链接。在笔记里输入两个方括号就能创建指向另一篇笔记的链接，[[]]这个语法帮我把分散的阅读笔记连成了一张知识网。读A论文时发现它引用了B论文，我就直接在A的笔记里写上“与B论文的方法形成对照”，顺便给B建立一条链接。等半年后回头搜索某个主题时，所有相关的笔记都能顺着链接摸出来。

第二是标签系统。我给每篇笔记打的标签通常是主题和状态的组合，比如#arXiv/2025、#status/done。这样通过Obsidian自带的标签面板，我可以一键筛出所有还没整理完的笔记。

第三是Dataview插件。这个插件能把笔记当成数据库来查询，比如我可以写一行代码，把所有标签为#status/reading且创建时间在一个月内的笔记，自动列成一个带链接和摘要的清单。这个功能我每天都在用，它让零散的笔记拥有了“自动汇总”的能力。

对Obsidian的争议点在于，它不开源。虽然数据格式是开放的，但软件本体是闭源的。我的态度是：这正好验证了“开放格式+任何外壳”这个思路的合理性——只要数据是Markdown，外壳是什么其实无所谓。

3.3 文档转换：Pandoc是格式自由最坚实的后盾

最后来说Pandoc，这玩意被称作“文档转换界的瑞士军刀”。Markdown转PDF、转Word、转HTML，各种格式之间的互转，基本一条命令就能搞定。

在研究场景里，我主要用它做两件事：

一是把多篇笔记合并成一个带章节结构的PDF。写综述论文时，我常把每篇文献的阅读笔记用#标题组织好放在同一个目录下，然后运行一条Pandoc命令，就能把它们按标题顺序拼成一个带层级目录的完整文档。

二是自定义参考文献格式。用Pandoc配合CSL样式文件和Zotero导出的BibTeX，可以把引用格式在两分钟内从APA切换成GB/T 7714或者IEEE，投不同期刊时需要调参考文献格式，再也不用手动改来改去。

安装Pandoc时有个小坑：如果只是装了主程序，依赖的LaTeX引擎缺失，转PDF时会报错。你在Windows上建议直接安装完整版的MiKTeX，在macOS上安装BasicTeX就可以，否则输出中文字体时会有各种诡异问题。

3.4 版本管理与备份：用Git给研究仓库上保险

你可能觉得Git是程序员才用的东西，但研究笔记同样需要版本管理。我遇到过最惨烈的一次事故，是在某次文献整理中误删了一个写了三个月的综述笔记文件夹，等我发现时，自动同步服务已经把“删除”这个行为同步到了所有云端备份。

从那以后，我给自己立了几条规矩：

• 每天结束工作时运行一次git add . && git commit -m "daily update"，保留当日全部变更
• 每个阶段性节点（比如完成一篇笔记、定稿一个章节）手动打一个git tag
• 用Git的Web界面查看每次提交的具体改动，继续确认没有误删

刚开始你可能觉得每次提交是多余的动作，但当你真正需要回退到“昨天”或者“上个月”的状态时，会发现这是全世界最划算的一笔时间投资。

4. 实操过程：一步步搭建属于你的OpenResearch工作台

下面是我的完整搭建流程。从头到尾大约需要半天时间，之后每天维护只需要几分钟。

4.1 目录结构设计与分区逻辑

在动手前，我先在本地建立了一个根目录，把上面说的所有工具都挂在这棵树下面：

OpenResearch/ ├── 00-Inbox/ ├── 01-Literature/ ├── 02-Projects/ ├── 03-Attachments/ ├── 04-Archive/ ├── 99-Resources/ ├── library.bib └── config/

每个文件夹的定位和命名逻辑说一下：

• 00-Inbox：临时存放快速捕获的想法、链接、PDF下载，相当于“未分类的入口”。每天结束前我会清空它，把里面的内容分流到其他文件夹
• 01-Literature：所有文献阅读笔记，按主题建二级目录
• 02-Projects：每个进行中的研究课题一个子目录，包含实验记录、草稿、数据分析脚本
• 03-Attachments：Zotero自动存放PDF附件的目标文件夹，按“作者+年份+标题”自动重命名
• 04-Archive：已完成的旧项目、不会再主动引用的笔记，从活跃区移到这里，保持主库的整洁
• 99-Resources：通用模板、写作素材、报告样式文件

这套目录设计借鉴了GTD的“收集—处理—归档”循环。把数据按“位置状态”不按逻辑分类，这比按学科分类更符合实际操作频率——因为当你在收集阶段时，你根本还没想清楚这篇文献属于哪门学科。

4.2 Zotero + Obsidian + Pandoc 联合工作流

接下来是核心工作流。我按每天做研究的实际顺序来写。

第一步：收集文献。当我看到一篇论文，用浏览器插件一键存入Zotero，同时用Better BibTeX插件自动生成引用键。然后把PDF附件交给ZotFile，统一转移到03-Attachments目录下，重命名成“作者_年_标题首词.pdf”。

第二步：记录阅读笔记。在Obsidian里新建一篇笔记，我采用了一个基本固定的模板：

--- title: author: year: tags: [status/reading, topic/xxx] citekey: related: --- ## 核心问题 （作者想解决什么问题？） ## 方法与数据 （用了什么方法？数据从哪来？） ## 主要结论 （作者得到了什么结论？） ## 局限与争议 （哪些环节让你怀疑？） ## 与我工作的关系 （这篇文献对我当前研究有什么启发？）

模板不是限制，而是降低每次做笔记的决策成本。填写时不需要写完整句子，短条目、关键词、甚至箭头都行，重点是逼自己把“被动阅读”变成“主动提取”的过程。

第三步：关联笔记。每做完一篇文献笔记，我都会在文末的related字段里手动加上与它相关的已读文献链接，形成双向关联。这样做的好处是，当未来某一天我通过一篇旧文献回溯时，可以顺着关联链条发现一个完全没想到的知识分支。

第四步：汇总输出。写综述或最终报告时，我先用Obsidian的Dataview查询出项目目录下所有“已读且有笔记”的文献，然后在终端中运行Pandoc，把笔记合并成一份带目录的文稿。

4.3 一键生成报告：Pandoc命令实战

举个例子。我的某篇文献综述放在OpenResearch/02-Projects/survey-llm-agents/里，笔记按顺序排好，执行下面这行命令就能生成Word版本：

pandoc OpenResearch/02-Projects/survey-llm-agents/*.md \ --citeproc \ --bibliography=OpenResearch/library.bib \ --csl=ieee.csl \ -o survey-llm-agents.docx

各参数说明：

• --citeproc：启动引用解析，让Pandoc自动根据BibTeX文件生成引文和参考文献列表
• --bibliography：指定BibTeX文件位置，里面存着所有Zotero同步过来的文献元数据
• --csl：指定参考文献样式，我提供了IEEE的CSL文件。换成APA、GB/T 7714也行，只需替换成你的CSL文件路径

如果你需要的是PDF，再把命令改为-o survey-llm-agents.pdf，Pandoc会调用LaTeX引擎完成排版。中文用户记得把--pdf-engine=xelatex也加上，否则默认的pdflatex处理不了中文字符。

实际跑过一轮之后你会发现，配置好了这个流程，从“一堆零散笔记”到“一份带规范引用的正式报告”，只需要不超过30秒的命令时间。第一次搭好时我被这种效率优势惊到了。

4.4 Git仓库初始化与自动化提交

为了让整套系统有版本保障，我在OpenResearch根目录执行了初始化：

cd OpenResearch git init git add . git commit -m "init OpenResearch workspace"

然后用Cron（Linux/macOS）或任务计划程序（Windows）配置了每日自动提交。比如在macOS的crontab里加一行：

30 23 * * * cd /Users/name/OpenResearch && git add . && git commit -m "daily sync" --quiet || true

注意末尾的|| true，意思是“即使没有文件变更导致git报错也没有关系”，避免每天收到无意义报错通知。Git提交不依赖任何云服务，这也是“本地优先”的一部分——即使天下大乱，你的历史版本依然完好地躺在本地。

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

这块内容是实战经验的浓缩。我踩过不少坑，下面按问题类型整理成速查表，再挑几个典型的展开说。

5.1 文献元数据错乱与PDF重命名的坑

Zotero从网页抓取元数据时，偶尔会把部分字段抓错，比如作者列表里多出“et al.”，或者把期刊名抓成会议论文标题。解决方法是下载到本地后，在Zotero的编辑器里花30秒检查并补全字段。优先级顺序：作者、年份、期刊/会议名、DOI号。DOI是后续做引用关联的锚点，丢了想找回来要花好几倍的工夫。

ZotFile自动重命名PDF时，如果文献标题里有冒号（西文标题很常见），在Windows系统上会导致目标文件名非法。我的处理方式是在ZotFile规则中把冒号替换为“-”，同时把中文标题的顿号保留，避免过度清洗导致文件名失去可读性。

5.2 Obsidian插件失效与笔记链表断裂

Obsidian的插件生态更新很快，时不时会出现某个插件因为API变动而失效。我遇到最多的是Dataview在新版本中不支持某些旧语法。这时候去插件仓库的GitHub页面看Issues，一般能快速定位是兼容性问题还是插件本身已经停止维护。

另一种常见情况是移动了某个笔记文件之后，其他笔记里的[[]]链接断了。Obsidian自身有“检测失效链接”的面板，但更高效的办法是在笔记模板中规范地使用related字段——断链后我用Dataview列出所有带旧文件名的条目，统一替换一次性修复。

5.3 Git冲突与同步灾难的补救

最严重的场景是，同时在两台设备上编辑同一篇笔记，同步完之后发现两边改动了不同内容，产生了冲突文件。我的处理流程是这样的：

1. 如果冲突只涉及一篇笔记，保留内容更完整的一方，把另一方的内容手工合并进对应小节
2. 如果冲突波及多个文件，优先用git log --oneline查看最近的几次提交，定位是哪次提交引入了冲突
3. 用git checkout -- <file>回退到事故前的版本，再重新手动合并一次

重要：不要依赖云同步软件当做唯一备份。我用Syncthing做局域网排除，用Git做版本快照，用移动硬盘做月度冷备份。三重机制互相冗余，才敢说数据是安全的。

5.4 Pandoc输出格式错乱与中文字体问题

Pandoc转换PDF时遇到中文乱码或无法显示，基本是LaTeX引擎和字体配置的问题。完整解法如下：

1. 安装XeLaTeX引擎，比如MiKTeX完整版或TeXLive
2. 在Pandoc命令中追加--pdf-engine=xelatex参数
3. 用-V mainfont="Noto Sans CJK SC"指定中文字体，Windows用户可以换成Microsoft YaHei

如果转出的Word文档里标题层级不对，是因为Markdown的标题层级和Word样式映射不一致。解决办法是在参考模板文件（reference.docx）里统一设置，Pandoc命令加上--reference-doc=reference.docx。这个参考模板文件可以先用Pandoc命令生成一份默认的，再用Word编辑好你的样式，之后每次转档都以它为准。

6. 进阶扩展：让OpenResearch更进一步

整套系统跑顺之后，就可以考虑加一些自动化能力了，我最近使用的两个方向，靠一个开源工具就实现了。

方向一：网页剪藏自动化。用开源浏览器插件配合Zotero的收藏接口，一键保存网页内容，同时生成Markdown摘要。这样在浏览行业研究报告、技术博客时，那些不适合归入学术文献的内容也能进入研究库，作为辅助素材。

方向二：从笔记到博客发布。我把这套工作流直接扩展成了个人博客发布管线：Obsidian里的笔记经过Pandoc转换成Hugo或Astro需要的Markdown文件，再通过Git自动部署到静态托管平台。说白了，你正在看的这篇文章，最初也是从这套工作流里的某条碎片笔记起步的。

这两个方向让我从“为研究服务”，逐渐过渡到“研究的结果随手就能变成输出物”。研究闭环打通之后，知识管理的复利效应才开始真正出现。

提示：如果你动手能力强，还可以用GitHub Actions配置一个CI工作流，在Obsidian仓库每次同步时自动运行Pandoc脚本，这样连“手动执行命令行”这最后一步也可以省去。

7. 一点个人心得

从去年初开始使用这套OpenResearch工作流，最大的感受不是“效率变高了”，而是“焦虑变少了”。以前最怕的是读到一篇好文献但没保存好，下次需要时找不回来；或者是写到关键部分时发现某篇重要文章的笔记写得特别潦草，没法引用。现在这些都变成不太可能发生的事情，因为系统本身就替你兜底了。

最后再分享一个小技巧：不要一上来追求完美的目录结构和复杂的自动任务。先以最简单的方式跑起来——一个文件夹里放几篇笔记，跑一个礼拜，等习惯了再逐步添加Zotero、Git、Pandoc这些环节。工具链的复杂度应该是慢慢长出来的，而不是一步到位设计出来之后再用它来捆住自己。研究这件事，最终靠的还是持续积累和判断力，工具只是保证你的积累不会白费。