1. 写在前面：我为什么折腾一套OpenResearch体系
大概在两年多以前，我被一件事折磨得够呛——手头同时推进着三四个研究主题，浏览器标签页开了一百多个，微信收藏夹里躺着各种截图，桌面文件夹里堆着一堆"最终版_v7.docx"。等到真要用某个资料的时候，要么花上半天时间翻找，要么干脆忘了自己看过什么。更让我崩溃的是，有些东西我明明读过、摘录过，到了写作要引用的时候，却找不到原出处到底在哪里。
后来我下定决心，用"开放研究"的思路重建自己的工作流。OpenResearch在我这里并不是某一个现成软件，而是一套组合方案：用开源工具把"收集—整理—输出—复盘"这一整条研究链路彻底打通，让每一条资料都进入一个可检索、可追溯、可复用的知识网络。这套体系解决的核心问题有三个：信息过载带来的"失忆感"、动笔时"没有米下锅"的困窘感、以及研究过程不可回溯造成的重复劳动。
这个体系适合谁？我的判断是：长期追踪某一个领域的技术研究者、产品经理、咨询顾问、创业者，以及所有需要"持续吸收信息并产出判断"的知识工作者。如果你每天都要读大量文章、做大量笔记，却总觉得"看了就忘、存了不用"，那这套思路大概率能帮上忙。我不会只讲空洞的理念，而是会把我实际用到的工具链、目录结构、命名规范、脚本和踩坑记录全盘托出，你可以直接拿去参考，再根据自己的习惯调整。
2. OpenResearch的核心思路：四个关键设计
动工之前，我先想明白了一个问题：一个知识工作者的研究过程，最缺的到底是什么？答案不是资料，而是秩序。资料永远搜不完，真正稀缺的是把资料沉淀成自己判断力的能力。围绕这个结论，我做几个关键设计。
2.1 为什么强调"开放"
"开放"这个词，很多人第一反应是"公开""免费"。但在我的体系里，它更接近于"不锁死"——资料格式不锁死、工具不被单一厂商锁死、研究过程不锁死在自己的脑子里。
市面上很多笔记软件，进去容易出来难。数据封闭在一个私有格式里，一旦厂商调整策略或者停止维护，你想换工具就跟搬家一样痛苦。我见过太多人用了五六年某个云笔记，突然某天被限制设备数，几千条笔记导出格式七零八落。所以我选择了全链路使用开放、基于纯文本的格式。Markdown作为笔记的主体格式，PDF和文献元数据交给Zotero，版本管理交给Git。这四者没有一个由商业公司垄断，都是开放标准或者开源软件。数据始终在我自己手里，哪天想换工具，复制粘贴就能走。
2.2 输入、处理、输出的闭环
研究本质上是一个循环：疑问→假设→收集证据→形成判断→输出→产生新疑问。但我观察到的普遍现象是，大部分人做研究是"输入型"的——只收集，不输出。这就导致知识是死的：存在那里，永远只是别人的观点。
我把"输出"作为整个闭环里最关键的一环。这里的输出不是指某种宏大的成果，而是最朴素的一句话：每读一篇文章，都要用自己的话写几句札记。这个动作在认知科学里叫"精加工"，本质是强制大脑对新信息做编码。没有这个过程，读过的东西就是过眼云烟。所以我在整理任何资料时，都会逼自己补一段"我的判断"，哪怕只有一百字。
2.3 单一事实来源
研究过程中，同一份信息往往存在多个副本：PDF、网页截图、微信收藏、某个笔记软件里的摘录……副本一多，麻烦就来了。引用的时候不知道该信哪一份，更新的时候不知道要在几个地方同步，时间一长，"哪份是准的"完全要靠记忆。
我给自己定的铁律是：所有核心资料只存一份，位置唯一，其他地方只允许出现链接或者索引。具体来说，原始PDF和文献条目放Zotero，由Zotero统一管理文件存储；我在Obsidian里写的所有摘录和思考，通过插件指向Zotero里的条目，而不是把PDF塞进Obsidian库。这样一来，每个信息只有一个"家"，找起来零混乱。
2.4 可追溯、可复现
这是整个体系里我最看重，也最容易被忽略的一点。写文章的时候，凡是引用的数据、结论、观点，我必须能一键追溯到原始出处。这个能力听起来简单，但绝大多数人做不到——因为平时根本没有记录"这条信息是从哪来的"这个习惯。
我的方案是双管齐下。第一，每一条笔记都必须有"来源"字段，写明URL、书名、DOI，不写来源就不许入库。第二，凡是转载、翻译外部文章的笔记，必须在开头标注原始作者和发布日期。这两条规矩看起来繁琐，一旦养成习惯，写作和查证都会变得非常轻松。
3. 研究流程的五个关键环节：从问题到输出
理论上讲得再好，落地还是得靠流程。我把自己过去一年多的实操路径拆成五个环节，每个环节环环相扣。
3.1 选题：把模糊兴趣变成可研究的问题
研究的起点几乎都是某种模糊的好奇："最近Agent好像很火""这个系统的性能为什么上不去"。这种模糊的兴趣如果不加约束，很快就会被信息洪流冲散。我的做法是，在启动任何研究之前，先用一段话写清楚三件事：我想解决什么问题、目前我知道什么、我还缺哪类信息。
这个动作花不了十分钟，但效果极其明显。它相当于给后续的收集活动画了一个靶子，看到文章的时候，能快速判断"这跟我当前研究有没有关系"。没有靶子，阅读就是被动的，效率极低。我自己最开始跳过这一步，结果收集了十几篇文章后发现方向完全跑偏，只好全部作废重来。
3.2 收集：建立统一的待处理入口
很多人收集资料时有一个致命习惯：看到一篇好文章，立刻停下来细读，然后花二十分钟把它整理得漂漂亮亮。这种即时整理的认知负担太高了，坚持不了几天就会放弃。
我的方案是：统一入口，进箱再说。所有渠道的信息——浏览器里的网页、微信公众号里的推送、邮箱里的PDF报告、读书时的划线——先丢进一个"收集箱"（Inbox），不做分类、不做整理。任何一条信息的入箱操作都不超过十秒：浏览器一键剪藏，公众号链接转发到文件传输助手，PDF直接拖进Zotero的待读文件夹。
这个设计的核心逻辑是"降低收集阻力"。如果入箱的成本太高，人就会倾向于"先放着吧，等会儿弄"，然后就没有然后了。反而是这种无脑往里扔的方式，能让收集习惯长期坚持下来。
3.3 整理：定期批量处理，而不是实时零散整理
收集箱里的内容不能永远堆着。我给自己安排了固定的整理时间，每周至少一次，通常放在周五下午。整理不是重新阅读，而是做四件事：快速扫一遍内容、划出关键信息、用三句话写摘要、决定是否入库以及入库后归属哪个主题。重要的标准只有一个：我将来会不会再次引用它。不会的东西，果断删掉或者留在原处，不占知识库的空间。
整理的时候我遵循"两分钟法则"：能在两分钟内处理的条目，当场处理完；需要深度读的，打上"待精读"标签留在箱里；已经过时的，直接归档。这样每周的整理时间能控制在四十五分钟以内，不会变成负担。
3.4 输出：写笔记就是写作的草稿
我所有的文章，最终都不是坐在电脑前从零开始写的，而是从知识库里的卡片笔记"拼"出来的。我在整理环节做完摘要之后，会额外写一个"我的观点"字段，强制输出一段独立的判断。这个动作本质上就是在做写作训练：每篇笔记都像一个乐高积木块，单独看不大，但积少成多之后，可以拼出各种形状的文章。
为了让这个"拼接"过程更顺畅，我在建笔记时尽量做到原子化：一张笔记只讲一个主题，只回答一个问题。过深的内容单独拆成多张笔记，然后用双链连接。这样做的好处是，到写季度总结或者研究报告时，用Dataview一查，所有散落在各处的素材会自动汇集到列表里，我只需要调整顺序、补充过渡，一篇文章的初稿就出来了。
3.5 复盘：让知识库长出新的研究问题
研究不会因为一篇文章写完了就结束，它更像是从一棵树上长出新枝。我每个月会做一次"知识库体检"：看看这一个月新增了哪些笔记、哪些主题下的笔记密度最高、哪条笔记的引用链最深。这些东西就是我的"研究雷达"——它告诉我真正的兴趣焦点在哪里。
实际操作中，我在Obsidian里建了一个"月度回顾"笔记，用Dataview自动统计当月新增笔记数量和信息来源分布。统计本身很简单，真正值钱的是统计后的那个问题：为什么这个主题积累了这么多素材？这个主题接下来还能怎么深入？顺着这个问题，下一轮研究会自然冒出来，整个过程不需要意志力硬撑。
4. 实操：用开源工具搭建一套可落地的OpenResearch工作台
理念讲完了，接下来是真正可以抄作业的部分。我的工作台由四样东西组成：Markdown做统一格式，Git做版本管理，Zotero做文献管理，Obsidian做知识网络编辑。下面逐个说明选型和配置要点。
4.1 工具选型：为什么偏偏是它们
先回答一个很自然的问题：市面上笔记软件那么多，为什么要用这么一套组合？我的答案很简单：这套组合的每一个部件都不可取代，但组合起来又不绑定。
Markdown是我所有笔记的唯一格式。它本质上就是带排版的纯文本，没有厂商锁死问题，任何一个文本编辑器都能打开，十年后绝不会因为某个软件停止服务而无法阅读。很多云笔记软件导出格式混乱，说白了就是想把用户留在生态里，我可不想被这种机制绑住。
Git是版本控制工具，很多人写代码才用Git，我用来管知识库。好处是每一次修改都有记录，哪天手滑删了几百字，一条revert命令全部找回。更关键的是它天然支持多机同步和多人协作，配合Gitea的私有仓库，我的知识库在任何设备上都保持同一个状态。
Zotero在我这里负责所有文献类资料：论文、报告、专业书籍。它是开源软件，文献元数据管理能力非常强，还支持插件扩展。我用一个Better BibTeX插件把文献导出为引用键，这样在笔记里写[@doe2024]就能直接生成规范引用，比手动打书名号和作者名高效太多。
Obsidian是笔记的编辑界面和知识网络层。它读取本地文件夹里的Markdown文件，不把数据锁进自己的数据库，所以它倒了文件还在。双向链接、标签、Dataview插件让知识库具备"网络效应"——笔记之间可以互相引用，还能用类SQL语法做动态查询。这一层所有工具里，Obsidian是我最不担心被绑架的一个，因为它本质上是"没有数据库的笔记软件"。
4.2 目录结构与命名规范
搭这套体系的第一件事就是定目录结构。我参考了PARA方法论，并针对研究场景做了调整：
Research/ # 知识库根目录 ├── 00-Inbox/ # 收集箱，所有新资料先进这里 ├── 01-Projects/ # 进行中的研究项目，每个项目一个子目录 ├── 02-Areas/ # 长期负责的领域，例如"AI Infra" ├── 03-Resources/ # 按主题沉淀的资源库 ├── 04-Archive/ # 已完结项目的归档区 ├── 90-Meta/ # 笔记模板、流程文档、月报总结 └── 95-Scripts/ # 自动化脚本，比如快速剪藏脚本这套结构的原则是"流程分家"：进行中的活在01、02里，沉淀的知识在03里，做完的在04里，支撑体系本身的东西在90、95里。好处是分区清晰，不互相污染，备份和清理都有明确的对象。
命名规范同样重要，我统一采用"日期-关键词"的格式，比如20250112-AI-Agent-综述.md。日期前置最大的好处是文件夹里自动按时间排序，一眼就能看出哪条笔记更新；关键词负责语义，让人不看内容也能猜到七八分。另外我规定文件名里绝对不能出现空格和特殊符号，因为Git和命令行工具对此非常敏感。
4.3 Zotero文献管理配置要点
Zotero的安装没什么好说的，关键是这三个配置点：存储路径、引用插件、同步方案。
第一个是存储路径。Zotero默认会往C盘塞PDF附件，我第一时间把它改到知识库外的独立数据盘，并开启"附件自动重命名"功能。否则时间一长，PDF文件名要么是乱码要么是重复，找起来心累。
第二个是插件。我装了三个必装插件：Better BibTeX、Zotfile、Zotero Integration。Better BibTeX负责生成稳定的引用键，格式我设置成"作者-年份-标题首词"，例如doe2024agent；Zotfile负责把PDF里的批注自动提取成独立的Markdown笔记，这功能极大减轻了手动摘录的负担；Zotero Integration负责让Obsidian和Zotero互通，在笔记里输入@关键字就会弹出匹配的文献条目。
第三个是同步。我的做法是Zotero的WebDAV免费空间用于元数据同步，附件储存在本地并纳入定期备份。重要文献绝不只存在于云端，万一云端账号出问题，本地文件还在。这是我踩过坑之后的血泪教训，之前论文PDF只放在了Zotero云同步里，某次同步冲突把一批文件搞坏了，重新找原文件花了整整两天。
4.4 Obsidian笔记流转与双链设计
Obsidian的安装是零成本的；难的是怎么用它来承载研究流。我的建议是分三步走。
第一步，只启用核心功能：文件夹、标签、双链。不要装一堆花哨插件，先用起来。第二步，逐步引入Templater模板组件，把每一类笔记的固定结构（来源、日期、状态、我的观点）沉淀为模板，新建笔记时一键套用。第三步，上Dataview，把"手动维护清单"变成"自动生成动态视图"。
双链的使用有个容易忽略的细节：不要为了链接而链接。双链的语义应该是"这两张笔记之间存在逻辑关系"，比如一张是另一张的上位概念、一张是另一张的例证。我在每张笔记底部固定有一个"相关笔记"区域，手动维护有真正引用价值的链接。这样三个月后回头查，整棵知识树是清楚的长出来的，不是乱编的网络。
下面是我在Inbox笔记里用的一个Dataview片段，用于自动列出所有还没处理完的收集条目：
TABLE 来源, 收集时间 FROM "00-Inbox" WHERE 状态 != "已完成" SORT 收集时间 DESC LIMIT 20这个查询放在一个固定的"收件箱总览.md"里，每次打开库第一眼就知道还有几条没消化。不用记任何命令，筛选逻辑全部交给查询语句，压力瞬间少很多。
4.5 用脚本打通收集与整理
工具链最大的痛点是"割裂"：浏览器里看到一篇好文章，得手动复制、改格式、存文件。我写了一个小脚本，把那套重复劳动压缩到一条命令。
#!/bin/bash # quick-save.sh — 快速将网页剪藏转成 Markdown 并放入收集箱 # 用法: ./quick-save.sh "标题" "文章URL" "/path/to/content.markdown" TITLE="$1" URL="$2" CONTENT_FILE="$3" DATE=$(date +%Y%m%d) FILENAME="$DATE-$TITLE.md" # 拼装 frontmatter 与正文 cat > "$FILENAME" <<EOF --- 标题: $TITLE 来源: $URL 收集时间: $(date +%Y-%m-%d) 状态: 待整理 --- $(cat "$CONTENT_FILE") EOF # 移入收集箱 mv "$FILENAME" "$HOME/Research/00-Inbox/" echo "已存入 Inbox: $FILENAME"使用的时候，我用浏览器插件把网页完整转成Markdown存到本地临时目录，然后执行一行命令，五分钟前还在网页上的内容现在已经在自己的知识库收集箱里了。脚本本身不复杂，但它把"收集动作"从五步压缩到一步，这就是坚持下来的关键。
4.6 一篇调研笔记的完整生命周期演示
理论多抽象，不如走一遍完整案例。假设我想调研"2025年开源AI Agent框架的现状"，整个过程是这样的。
第一天，我把选题拆成三个子问题：主流框架有哪些、它们的核心架构区别是什么、社区活跃度如何。然后我把这三个子问题写进01-Projects/AI-Agent-调研/调研计划.md，给每个子问题标注了预期的信息来源类型。
接下来的两周，我所有看到的相关文章都进了00-Inbox。有些是公众号推文，我转发到文件传输助手后定期统一拖到电脑上处理；有些是arXiv论文，直接进Zotero；有些是技术博客页面，用上面那个脚本一键剪藏。
周末整理时，我先处理Inbox里的10篇网页剪藏：扫一遍，留下6篇有独特视角或关键数据的，其余归档。6篇各写一张卡片笔记，每张都包含核心观点、方法、来源及我的判断。论文部分，我用Zotero Integration插件把三篇关键论文的关键段落摘录进Obsidian，每段摘录后附上我的引申思考。
一个月后写调研报告时，我在Obsidian里用Dataview查"来源路径含AI-Agent"的笔记，十几条笔记自动列出来。我按子问题把它们重新排列，补充开头和过渡段，两天后报告初稿完成。整个过程我没有刻意去找"素材"，它们早就躺在知识库里等着被调用。
5. 常见问题与排查技巧实录
这套体系我用了两年多，踩过的坑不比任何人少。我挑四个最典型的写在这里，给你当备查手册。
5.1 收集速度快，整理速度却跟不上，Inbox爆了怎么办
Inbox堆积是几乎每个使用者都会经历的崩溃时刻。我的解决方案是"设定清箱阈值"：Inbox里的待处理条目超过30条，就强制停止收集，只做整理。另外我给每一类来源设置不同的处理优先级：论文和报告优先处理，深度文章次之，新闻资讯类果断丢弃。
最反直觉的经验是：不要追求每条都读完。整理不是阅读理解，是筛选判断。扫一眼标题和摘要，能判断"这跟我研究方向无关"，这条就可以归档了。很多人Inbox爆掉是因为读得太认真，把整理环节做成了精读环节。
5.2 笔记越积越多，检索效率反而下降
从第500张笔记开始，很多人会明显觉得以前搜索一下就能找到的东西，现在搜不到了。原因不外乎两个：命名不规范，关键词覆盖不到；标签体系膨胀，每个标签下都有几百条笔记。
我的对策是双管齐下。第一，把命名规则坚持到底，文件名即检索入口，宁可多写几个关键词也不要偷懒。第二，标签体系采用"领域+主题+类型"三层结构，比如"AI/Agent/综述""项目管理/方法论/流程"，每层数量控制在20个以内。超过20个就要合并，否则标签就失去筛选意义。定期用Dataview统计标签使用频次，会发现哪些标签是僵尸标签，该合并的合并，该删的删。
5.3 工具链总在某个环节"断掉"
最常见的情况是：PDF批注提取到一半乱码；网页剪藏后格式烂得没法看；Git同步冲突导致文件损坏。这些问题不是偶发，而是必然。我的经验是"降低环节耦合度"。
PDF乱码主要是因为扫描版PDF没有文字层，解法是识别后用OCR工具处理，或者干脆放弃依赖自动提取，手动做摘录。网页剪藏格式乱，解法是设置剪藏工具的CSS选择器，只保留正文区域，去掉导航、评论、广告等干扰模块。Git同步冲突，解法是"一台设备在本地改完再推到远端，另一台设备先拉取再改"，不需要学什么高深技巧，把这个操作顺序养成习惯，冲突就能减少九成。
5.4 多人协作或公开分享时，如何保护敏感信息
OpenResearch未必一定是私人的，有时需要和团队成员共享知识库，或者把部分内容公开发布。这时候最需要注意的不是功能配置，而是"敏感信息边界"。
我的铁律是：个人敏感信息（身份证号、银行账号、密码、家庭住址）绝对不进入知识库，即使Gitea仓库是私有的也不行，因为一旦同步出错或者账号被盗，后果相当严重。团队共享时，需要写清楚哪些目录可以公开，哪些是私密项目。我在Zotero里同样的原则适用：涉密或未公开的文献，不要和公开论文混在同一个账户里，单独建一个本地专属文献库。
6. 写在最后：这套体系真正改变我的地方
两年用下来，我最直观的感受不是"效率变高了"，而是"焦虑变少了"。以前信息过载会让我有种深深的无力感——觉得世界那么大、内容那么多，自己永远追不上。现在这种焦虑消失了，因为我知道每一条读过的内容都安放在该在的位置，需要用的时候，它们会排着队等我取用。
最后分享一个不常被提到的小技巧：定期给知识库做"体检"不是看笔记数量，而是找"断链"——那些建了笔记但始终没有跟任何其他笔记产生关联的孤独节点。它们往往是最该去深入挖掘的研究线索，也可能是你已经放弃的伪需求。我每次月检都会从断链里挑一个主题深耕一周，效果远超漫无目的地刷文章。
OpenResearch这套体系不是终点，它更像一个活的工程：今天读书的方式变了、工具体验变了、研究的方向变了，体系就得跟着调整。但那个内核——让信息流通、让判断生长、让知识可复现——是永远不会过时的。希望这篇分享能让你少走几步弯路，早点把"读过的内容"变成"自己的判断"。
