科研工作流的个人理解、实践与反思——从 Karpathy 的 LLM Wiki 到 Obsidian/Zotero 生态：知识工具如何为非线性思考建模本文以一个 AI 知识工具开发者的视角，梳理科研工作流的本质，评述 2026 年最具代表性的几个知识管理范式（Karpathy 的 LLM Wiki、research-hub、Heptabase、NotebookLM、Elicit 与 Obsidian–Zotero 插件生态），并分享我在产品「知芽（Notebook Skill）」中的设计取舍、工程落地、不足反思与生态规划。文中所有评述仅代表个人观点。核心速览科研工作流建模的单位应该是"人的思考与实践过程"，而不是调研、综述、挖掘问题、实验、写作这类线性环节。后者是流水线，可以（也应该）被云端全托管式科研产品自动化；前者必须容纳非线性、用户习惯与个性化。Karpathy 于 2026 年 4 月提出的 LLM Wiki，是知识管理领域近年最有启发性的思想实验。它用"编译器 vs 解释器"的比喻批评 RAG 的"无积累"缺陷，把知识维护的"记账"负担外包给 LLM，但存在错误结构化传播、schema 天花板与规模上限等局限。research-hub 揭示了科研工具生态的核心痛点不在单点能力，而在"交接"（handoff）。它以"真实性门禁"拒绝虚构引用、以低 token 成本设计服务 AI 代理，方向正确；但它仍是在流水线思维内部的优秀实现，尚未触及思考本身。Heptabase、NotebookLM、Elicit 分别代表了"空间化思考"“来源绑定问答”"结构化提取"三条路线，各有极致之处，却都没有认真建模"知识回到人的头脑"的回环。过度结构化的知识架构会抑制创新涌现。知识工具应当允许并支持思考链路的动态重构，至少要能描述这种过程。知芽（Notebook Skill）的工程实践围绕上述判断展开：低结构化入口、渐进式结构化、随时可重构的知识组织、引用硬校验、可观察可纠正的记忆画像；同时我坦承在思考可视化、主动智能、结构化负担等方面的不足，并规划与 Zotero、Obsidian 生态的融合。一、我们谈论科研工作流时，究竟在谈论什么1.1 工作流不是流水线开始做知芽（Notebook Skill）时，我要回答的第一个问题不是"做什么功能"，而是"科研工作流到底是什么"。这个问题听起来抽象，但答案决定了整个产品的架构走向。市面上绝大多数科研工具对工作流的理解是高度一致的：调研、综述、挖掘问题、做实验、写作。五个环节排成一条线，工具在每个环节上提供对应能力——检索工具管调研，综述工具管文献，问题管理工具管问题，实验平台管实验，写作工具管成稿。把这条线整体自动化，就得到了"全托管式科研"：用户输入一个主题，云端代理自动完成从检索到成稿的全程。ClawsGO Science 这类云端全托管式科研产品，正是这条流水线的工程化实现——对"按流程生产知识"的任务，它确实高效且可预期。但这是工作流吗？我自己的科研经历给出的答案是否定的。真实的研究过程是：读文献时冒出一个与手头任务无关的念头；写综述时发现概念框架不成立，回头重读原始论文；实验失败后反推，发现是问题定义错了；写作过程中产生的新问题，反而成了下一轮研究的起点。调研、综述、挖掘问题、实验、写作并不是先后发生的，而是互相嵌套、彼此倒灌的。问题在研究中途漂移，方法在写作中被重新审视，结论在综述时被推翻重来。这不是执行不力的表现，而是创造性认知的常态。研究的绝大多数关键时刻发生在"环节之外"——发生在材料与想法的碰撞处，发生在两篇论文的缝隙里，发生在半夜突然意识到"这两个概念其实是一回事"的瞬间。这些时刻无法被安排进任何流水线，但它们是科研工作流真正的主干。所以我的判断是：以环节为单位建模得到的不是工作流，是流水线。流水线适合被自动化，但它没有描述人的思考。工作流的建模，应该基于人的思考与实践过程各个环节的统筹与模型化——是"认知活动的组织方式"的模型，而不是任务清单的机械排列。前者是活的、长的、随人而异的；后者是死的、短的、一次性的。1.2 非线性意味着什么：对工具的三条硬约束承认科研工作流是非线性的，对工具设计意味着几条硬约束。第一，灵活性优先于流程完整度。工具可以建议路径，但不能把路径锁死。用户今天从问题出发、明天从材料出发、后天从一句灵感出发，都应当被同等支持。一个只接受"先建项目、再收素材、再生成"的工具，本质上是在用软件工程的思维管理认知活动——它能保证产出整齐，但会牺牲掉最不整齐、也最有价值的那部分思考。第二，容忍甚至支持"链路重构"。一个知识库如果强约束"问题必须挂材料、材料必须挂来源、笔记必须有分类、结构必须稳定"，那么用户重建思考链条的成本就会高到放弃。工具至少要能描述重构过程：记录一个想法如何从摘录变成转述、从转述变成笔记、从笔记变成问题、从问题变成结论——这条链路本身，就是科研过程最有价值的记录。第三，个性化不是附加功能，而是核心机制。思考节奏、组织习惯、输出风格因人而异：有人从摘要读起，有人从结论读起；有人靠写出来思考，有人靠画出来思考；有人每周回顾，有人三个月集中爆发。工具如果只提供一套"最佳实践"，就在把一半用户挡在门外的同时，也把他们的创新方式挡在了门外。1.3 知识库管理面临同样的问题同样的张力出现在知识库管理上。传统知识管理工具的隐含假设是：知识是分层的、有边界的、可归档的——文件夹、目录树、严格分类。这个假设在"存储与检索"的语境下成立，但在"思考与创新"的语境下是危险的。过度结构化的知识架构会限制创新想法的涌现，原因是：创新在认知层面本质上是对既有知识结构的"非法重组"——把一个概念从它原本的领域强行嫁接到另一个领域，是许多重大发现的共同结构。而一个把每个概念都钉死在唯一分类里的知识库，会在用户试图"乱连"时处处掣肘：要么找不到那个想被重新组合的元素，要么系统根本没有表达"跨领域连接"的语法。所以知识管理工具应该允许甚至支撑思考过程中的链路重构，至少要能描述这种过程。这件事说起来简单，做起来反直觉——因为所有知识管理工具的商业叙事都是"帮你整理得更有序"，而这里的主张是：整理得有序是手段，允许无序地重组才是目的。知芽的"孵化区—问题看板—笔记—内容源"之所以是现在的形态，很大程度上就是这句话的工程化结果，这一点我在第五节展开。1.4 知识库的下一个读者，是机器还有一个这个时代特有的维度：个人知识库的读者正在从"只有自己"变成"自己和 AI"。2026 年 AI 搜索已成为中国超过 2 亿月活用户的信息入口，调研显示超过四成的用户已几乎完全转向 AI 搜索。当知识被 AI 引擎检索、综合、转述时，内容的组织方式直接影响它是否被理解、被引用——结构清晰且语义明确的段落，被 AI 召回的概率显著高于叙事松散的长文。这个变化对知识管理提出了一个新的要求：知识架构既要松弛到允许人类非线性思考，又要清晰到能被机器理解。过度结构化伤害人类，毫无结构伤害机器。这两条约束看似矛盾，其实指向同一个解法——结构应该生长在内容之后，而不是强加在内容之前：先有自然的笔记，再有机器的索引；先有人的重组，再有系统的归档。这也是后文所有产品评述的一条暗线。二、Karpathy 的 LLM Wiki：一场"知识编译"的思想实验2.1 基本主张2026 年 4 月，Andrej Karpathy 以公开文档的形式系统阐述了他关于个人知识库的构想，社区称之为"LLM Wiki"。其核心主张可以概括为一句话：不要让大模型在每次提问时从原始资料里"重新发现"知识，而要让它在资料摄入时就完成"