核心判断

Obsidian Bases 值得拆的地方，不是它终于补上了“数据库视图”，而是它把数据库能力压回了正确位置：文件是事实，视图只是临时组织方式。

对 personal software 和 Agent 产品来说，这个判断很关键。用户真正需要的不是又一个更强的表格，而是一个不会篡夺材料主权、可以随时重建、可以被人和机器共同理解的工作界面。

背景与产品现象

Obsidian 的 Bases 是一个核心插件，官方描述是可以为笔记创建类似数据库的视图，用表格或卡片查看、编辑、排序、过滤文件及其 Properties。它可以用来组织项目、旅行计划、阅读列表等。更关键的一句是：Bases 的所有数据仍然存储在本地 Markdown 文件和 Properties 里，视图本身由 .base 文件或嵌入在 Markdown 里的代码块描述。

这和 Notion 的数据库逻辑形成了一个很好的对照。Notion 官方说，数据库是 pages 的集合，每个条目本身就是一个 Notion page，可以有属性，也可以用列表、日历、图表等视图呈现。Notion 的强处是把“页面”和“数据库条目”统一成一个可协作的云端对象；Obsidian Bases 的强处则是反过来：它不要求用户先承认一个应用内对象模型，仍然让 Markdown 文件站在最前面。

所以这不是一个“谁的数据库功能更强”的问题。更值得看的产品矛盾是：当个人知识、任务、阅读、项目都开始被结构化时，产品应该让结构成为主系统，还是让结构只成为可替换的视图？

真正值得看的不是数据库，而是主权边界

大众很容易把 Bases 看成 Obsidian 终于追 Notion，或者把它理解成“本地 Notion 数据库”。这个看法太浅。

真正值得看的，是 Obsidian 在补结构化能力时没有改变用户的心理契约：你的材料仍然是文件，你可以在 Finder、VS Code、Git、其他 Markdown 工具里打开它们；表格、卡片、过滤、公式是叠加出来的看法，不是材料本身。

这是一种很强的产品克制。因为数据库视图一旦做得好，产品团队很容易顺手把用户推向“以后都在我的表格里工作”。短期看，这会提高留存和功能深度；长期看，它会削弱用户对个人软件的信任。尤其在 AI 时代，如果一个 Agent 既替你整理材料，又把整理结果锁在自己的对象系统里，用户会越来越难判断：到底哪些是我的原始材料，哪些是 AI 生成的索引、解释和投影？

拆解

1. 这个产品相信什么用户行为

Obsidian Bases 相信的不是“用户想建数据库”，而是“用户已经有一堆文件，但需要在不同场景下临时换一种看法”。

同一批笔记，今天可以按 status 看成项目面板，明天可以按 source 看成阅读列表，后天可以按 date 和 tag 看成复盘素材。用户并不是为了维护数据库而来；用户是为了让已有材料在当前任务里变得可用。

这个信念和很多效率产品不同。很多产品默认用户愿意先建一个完整系统：字段、关系、模板、视图、权限、自动化。真实个人工作往往不是这样。个人材料是混乱进入的：一句想法、一篇文章、一个任务、一个会议摘录、一个截图、一段临时判断。产品如果一开始就要求用户把这些东西塞进严格表格，反而会降低捕获频率。

好的个人软件应该允许输入自由，但在需要行动时提供结构。Bases 的方向正是把结构放在“查看和处理”的阶段，而不是放在“记录和拥有”的阶段。

2. 它牺牲了什么

这个选择一定有代价。

如果文件是源头，视图是派生，就很难像纯数据库产品那样拥有完整的一致性控制。字段命名可能混乱，Properties 可能不齐，用户手写 Markdown 可能破坏某些假设，跨设备同步也可能出现短暂不一致。它也不会天然拥有 Notion 或 Airtable 那种端到端的协作、权限、自动化和后台数据模型。

换句话说，Obsidian 牺牲的是平台型数据库产品的确定性，换来的是个人文件系统的可解释性和可退出性。

这对团队协作产品未必划算，但对个人知识工作很划算。个人软件最怕的不是少一个字段类型，而是几年后用户发现自己的思考、任务、阅读、草稿都变成了某个应用才能解释的残骸。Bases 的克制在于，它让高级视图存在，但不让高级视图成为用户的牢笼。

3. 这个判断如何体现在具体体验里

最关键的体验不是“可以表格显示”，而是“每一行仍然对应一个文件，每一列来自文件属性”。这让用户在视图中编辑结构化信息，同时仍然知道这些信息落回了哪里。

.base 文件或 Markdown 代码块也很有意思。它意味着视图定义本身可以成为 vault 的一部分，而不是只存在于应用数据库里。用户保存的不只是内容，还有自己如何看内容的方式。更重要的是，这种“看法”仍然是文本化、可迁移、可版本管理的。

这给 AI 产品一个很直接的提示：Agent 不应该只生成一个漂亮 dashboard，而应该把 dashboard 背后的规则也写成用户能看见、能改、能带走的东西。比如“最近需要推进的项目”“所有读完但未产出的文章”“所有包含待办的草稿”，这些都不应该只是黑盒推荐流，而应该是可解释的视图规则。

当用户不同意 Agent 的整理方式时，他不应该只能点“不喜欢”。他应该能看到规则、改掉规则、删除规则，必要时从原始文件重建一遍。

4. 对个人产品 / Agent 产品的启发

第一，早期 personal software 不要急着做一个总数据库。更好的顺序是：先保护原始材料，再做可重建索引，最后提供高质量视图。

如果 Dewey 要做本地优先的个人上下文产品，Markdown 和附件应该是 source of truth；SQLite、embedding、任务列表、关系图都应该是 derived layer。用户可以享受搜索、RAG、任务聚合和项目视图，但这些能力坏掉时，不能带走他的材料。

第二，Agent 的产品价值不只是“帮我归类”，而是“帮我生成可检查的组织方式”。一个 Agent 可以建议 Properties、抽取任务、建立阅读列表、生成项目面板，但它必须把变更和规则显性化。否则，所谓记忆和上下文会很快变成用户不敢依赖的暗箱。

第三，视图应该服务当前动作，而不是炫耀数据完整性。对个人用户来说，一个能立刻回答“我今天该推进什么”“这些材料能写成哪篇文章”“哪些任务藏在文档里”的视图，比一个字段完美但需要长期维护的数据库更有价值。

5. 哪些不能照抄

不能照抄 Obsidian 的地方，是把“文件优先”误解成“什么都让用户自己配置”。Obsidian 的用户愿意为可控性付出学习成本，但一个新的个人产品不能默认用户也愿意。

如果照抄 Bases，只给用户过滤器、字段、公式和视图编辑器，很容易变成另一个配置型工具。对 indie product 来说，更好的做法是提供少数默认视图：Inbox、Today、Active Projects、Reading to Write、Tasks in Docs。先让用户感到“我的材料被拿来做事了”，再逐步开放自定义。

也不能把本地文件当成逃避产品设计的借口。Local-first 不是“我们把文件给你，你自己管理”。Local-first 的产品责任反而更重：要处理命名、冲突、恢复、索引重建、AI 修改前后对比、跨设备延迟等细节。只有这些默认路径做稳，文件主权才会变成信任，而不是负担。

结论

1. 结构化不是问题，结构反客为主才是问题。 好的个人软件可以有数据库视图，但不能让视图替代用户真正拥有的材料。

2. AI 时代的个人软件要区分三层：原始文件、派生索引、临时视图。 原始文件属于用户；索引可以重建；视图可以变化。这个边界比多一个 AI 功能更重要。

3. Agent 产品不要只给结果，要给可修改的组织规则。 用户信任的不是“它好像懂我”，而是“我知道它依据什么整理，我也能把它改回来”。

4. 早期产品应该少做通用数据库，多做默认视图。 先证明某几个视图能让用户反复回来，再开放复杂配置。否则产品会很强，但不会真正进入个人工作流。