问题
用 Obsidian/Logseq 做项目跟踪、CRM、问题跟踪的用户，习惯在笔记里用重复的 inline 字段追加记录状态变化（append-only 历史），但查询工具读不到“最新值”。Obsidian 论坛用户表示希望 Bases 公式能做 status_history.last() 这类操作，把历史动态转为当前状态；Logseq 用户则因为完成 TODO 时不记录时间戳，无法查询最近完成的任务。目前的临时做法是只在 YAML 里存当前值（丢失历史），或用脚本把最新值同步进 YAML，存在同步出错风险。
目标用户
在 Obsidian 或 Logseq 中用笔记做轻量项目跟踪、CRM、问题/风险/支持工单管理的知识型个人用户和小团队。两个信号分别来自 Obsidian 论坛和 Logseq GitHub Issues，说明这类需求跨工具存在，但单个信号互动量低（1 评论 / 2 评论），属于小众但真实的长尾需求。
解决方案
做一个本地优先的 Obsidian 插件：
- 历史字段提取：自动扫描笔记中重复的 inline 字段，识别每个字段的“最后一个值”；
- 可查询化：把最新值写入虚拟属性/缓存，让 Bases 公式与 Dataview 查询可以直接 filter/sort/group，等价于 status_history.last()；
- TODO 完成时间戳：勾选任务时自动在块级记录 CLOSED 时间戳，取消时移除，支持“最近完成的任务”查询；
- 保留完整历史：原文的追加式记录不改动，避免用户现有数据迁移。
AI 的角色：用 LLM 辅助解析非结构化的历史记录（如自然语言写的状态变化），并在用户配置时把口语化需求转成查询表达式；核心功能不依赖 AI，纯规则解析即可完成。
为什么是现在
Obsidian 新推出的 Bases 功能正在扩展查询能力，用户开始把笔记当轻量数据库用（信号 1 即是对 Bases 公式的功能请求），正是插件生态填补查询空白的窗口期；同时该信号较新（2026-09），说明需求随 Bases 推广而活跃。
MVP 范围
第一版（Obsidian 插件）做到：
- 解析笔记中重复出现的同名 inline 字段，识别其追加顺序，提取最后一个值；
- 将最新值以缓存属性形式暴露给 Bases/Dataview 查询，支持 filter/sort/group；
- 用户勾选/取消勾选 TODO 时，在块上自动写入/移除完成时间戳，可被查询；
- 纯本地运行，不改动用户原始笔记内容（缓存与正文分离，避免 sync 冲突）。
明确不做：
- 不做完整 LOGBOOK/org-mode 兼容；
- 不做云同步、多人协作；
- 不做 Logseq 版本（先验证 Obsidian 侧需求）。
风险
平台依赖（最大风险）：官方可能在 Bases 或 Logseq 核心中直接实现同类功能（信号本身就是官方功能请求），插件价值一夜归零。 生态分散：Obsidian 与 Logseq 数据格式不同，跨平台适配成本高。 付费能力弱：信号显示用户无付费意愿，生态以免费开源插件为主，商业化路径不明。 技术边缘情况：嵌套字段、日期格式、块引用等解析 corner case 多，需持续维护。
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Obsidian 论坛 · 功能请求9月29日功能请求▲ 01 条评论
“It would be extremely useful if a Base formula could do something conceptually similar to:”
Obsidian 用户希望在 Bases 公式中访问重复 inline 字段的最后一个值,以便把 append-only 历史记录动态转换为可查询的当前状态。原文
GitHub Issues · logseq/logseq6月24日功能请求▲ 122 条评论
“Currently, querying on `LOGBOOK` entries is not possible with logseq. However, a basic use-case of querying for recently closed todo items seems to need much less effort than adding the full LOGBOOK support.”
Logseq users cannot query for recently completed TODO items because closed timestamps are not recorded at the block level like org-mode does.原文