SeqTK

为长期复杂任务而做的 Obsidian 项目管理插件。

用一句话概况理念：切分长线任务的设计与执行，设计阶段不承诺时间，执行阶段不重复设计。

形式上：把「一件事」写成独立节点文档，通过类似 MOC 的方式以从属、状态和依据组织与串联不同节点，形成组合项目

内容上：设计鼓励通过先设计、再分发的形式，将复杂任务进行拆解后再进行分发安排

自动化：（尚未完成由旧版的迁移工作，因为换了数据层的实现方式）让流程与脚本按你定下的规则，不需要即时决策的向你推送下一件要做的事。

---

针对「长期、多并行项目」需求：论文、长线开发、活动筹备、研究跟踪、需要留痕的决策过程。

如果你对我的想法感兴趣，欢迎来找我聊聊：

• QQ 1569830316
• WX Taffy-331

需要 Obsidian 1.13.0 或更高 · 桌面与移动端均可用

• 这个插件的开发首先是为了满足我个人需求，因此，我会对其进行长期的更新与维护
• 这个插件正处于重构过程中，目前仅有 事务设计 、模板模式 、线路模式 被确认为完全可用
  • 流程 相关功能正处于测试中
  • 其余可用视图会进行继续迁移与继续开发
• 等待所有主要视图完善后，会重写 README 与增加教程 WIKI ，目前这里的信息可能是过时的。

---

它解决什么问题

其他个人任务管理工具，长线任务通常会难以维护：

1. 结构散乱 —— 没有确切项目层次、生命周期，均以任务、清单为层级管理
2. 组织困难 —— 难以使用文本进行批量编辑或写入，必须依靠其提供的不便利的可视化工具
3. 信息分离 —— 信息和任务项分散在不同软件中，或分散在不同任务项的描述，对长描述、复杂带有结构的描述难以审阅和组织
4. 缺乏设计 —— 无法嵌入和任务同级的信息，这意味着无法针对设计过程留下思考痕迹
5. 规则推送 —— 没有一套根据规则将任务进行推荐的系统，清单上始终会显示完整的待完成项，你始终要对下一件使其想做什么做即时决策，这在任务体量大时很消耗心力

这里要做的，就是在确保可视化的基础上，提高个人长线任务管理的自由度

SeqTK 的做法是把这三件事各归其位，彻底以节点文件形式进行信息管理：

• 结构交给框架与事务的层级，
• 状态交给可传播的节点属性，
• 依据交给挂在节点上的节点。

三者都在同一套节点体系里，可以互相引用、整体重排、批量改写。

---

设计取向

• 节点即文档。 每个节点就是库里的一篇 Markdown 文档。你随时可以离开插件，用 Obsidian 原生方式阅读、搜索、同步、做版本控制——插件不是数据的看门人。
• 关系写进文档，不另立私库。 从属、顺序、状态、证据都记录在节点文档自身，插件另外维护的只是一份可随时重建的查询缓存。
• 设计先于执行。 先用「事务设计」把结构和依据想清楚，再用「流程草稿 → 流程设计 → 流程推送」把它交给时间和脚本。设计阶段不承诺时间，执行阶段不重复设计。
• 只碰它管的目录。 插件只在自己的数据根目录内读写节点；你其它笔记不受影响。卸载插件不会丢失任何节点。
• 不替你做决定。 不强制工作流、你需要自己指定任务投注到时间轴的顺序和位置；破坏性操作（归档、删除）按你配置的确认级别执行。

---

核心概念

节点与分类

节点按用途分五类，每一类下面再分具体类型（新建时给你的就是这些具体类型）：

分类	具体类型	用途
框架	事务框架、信息框架、模板框架	装东西的骨架：一整个项目、一块资料区、一套可复用结构
事务	构想、方向、目标、工序、清单、行动、事件	你要推进的事本身，从想法一路拆到可执行动作
证据	对象、条件、信息、状态	支持某个事务判断的依据：涉及对象、前置条件、资料线索、快照状态
运行	编辑日志、行为日志、流程状态	自动留痕：什么时候发生了什么改动、流程跑到哪一步
脚本	流程脚本、执行脚本、查询脚本	把规则写成可执行的东西，让流程按时间或事件自动推进

层级与从属

节点之间有明确的从属与顺序，所以「一件事属于哪个阶段、排在第几位」是结构本身，不需要靠标签或命名约定去暗示：

• 框架可以套框架，形成「大项目 → 子项目 → 具体方向」这样的层级；
• 事务沿链条层层拆解（构想 → 方向 → 目标 → 工序；清单 → 事项），每一层只容纳它该容纳的类型，落错位置会被拦住；
• 同级之间有先后顺序，直接拖动即可重排；拖动会自动维护顺序与从属两边的记录，不会出现「看着移了、实际没变」的错位。

状态

事务类节点带状态：规划 / 进行 / 完成 / 放弃。另有正常 / 搁置 / 阻塞这组附加状态，用来表达「在做、但暂时推不动」。

状态可以按你配置的规则在父子之间传播：父节点进入某状态时把子节点一起改写，或子节点全部达标时向上聚合结果。规则在设置里配置，也可以完全不配。这就是「状态不可见」那一侧的解法——进度从结构里自动长出来，不用手工维护一份进度表。

证据

证据是挂在事务节点上的独立节点（对象、条件、信息、状态），不是正文里的一段文字。好处是它可以被单独检索、可以被多个事务复用、可以跨事务连接，也可以在「证据总览」里作为一张关系网整体浏览。外部材料（网页链接、库内文件、时间戳文档）作为「外部信息源」单独挂在节点上，与内部关系互不干扰。

模板、归档与回收

• 模板：任何一棵子树都可以「存为模板」，之后套用到别的框架上；模板库在「模板模式」里统一管理。
• 归档：不再活跃但还想留着的东西归档掉，默认视图里不再打扰你；归档时后代的处理方式可以配置。
• 回收：归档节点集中在「回收模式」里，可以还原，也可以彻底删除（删除的确认级别可配置）。

典型用法

从一段草稿开始。 把脑子里的想法按缩进写成列表，选中它，用命令或右键菜单提取成节点组，然后在事务设计里继续调整结构：该拆的拆、该挂证据的挂证据、该定状态的定状态。

边用边定型。 层级不对就拖，名字不对就用行菜单的「重命名」原地改，一次要改很多就用「以文本批量编辑」把整棵子树导出来改完再回写。整个过程不离开这张双栏界面。

把成熟结构变成模板。 某套框架拆法好用，就存成模板；下个项目直接套用，只需要改占位内容。

让时间接手。 结构定下来之后，用流程草稿排出并行事件轴、敲定起止时间；再用流程设计写成推送规则；日常工作时侧栏的流程推送会告诉你此刻该做什么。

收拾现场。 做完的事归档，需要时在回收模式里还原；过时的彻底删除。