Build a Project Management System in Obsidian That Claude Understands and Updates Constantly

大多数项目管理工具都有同样的隐藏成本：维护这套系统本身，就在和实际工作竞争。

你的 Notion 看板每周一更新要花 15 分钟，产出的文档没有人读。Jira 的 ticket 状态每个月都落后于实际情况。苹果的提醒事项列表每次打开都让你重新确认优先级——因为你上次更新它已经是三天前了。

问题的根源不是工具本身，而是：维护一个项目状态的成本，在持续累积；而这个成本消耗的精力，本可以直接用在项目本身上。

这篇文章介绍了一套系统，用 Obsidian 存储所有信息，用 Claude Code 直接读写这些文件，不需要 API 对接，不需要付费插件，不需要任何额外配置。

核心问题：维护系统 vs 做工作

当你同时背负十个项目时，每一个项目都需要你更新状态。每一个状态更新都要花时间，而时间有限。结果必然是：你停止更新系统，或者系统变得不准确，或者两者同时发生。

最后，你的项目管理工具变成了一份"事情如何开始的记录"，而不是"事情现在进展到哪里的实况"。

传统解法是更复杂的工具：更好的看板、更自动化的状态更新、更频繁的提醒。但这些解法同时也在增加维护成本——你学新工具要时间，配置新工具要时间，保持工具和实际工作同步也要时间。

这套系统的关键设计选择是：用 Obsidian 存储，用 Claude Code 读写，整个系统不需要任何 API 集成。

Obsidian 的本质是一个文件夹里的 Markdown 文件。任何可以读取文本文件的工具，都可以读取你的项目信息。

Claude Code 的本质是一个可以直接读取和写入文件的大模型 Agent。它可以理解你的项目结构，可以分析上下文，可以更新文件内容。

把这两者接起来，你得到的就是：一个 AI Agent 能随时读取你的项目状态、分析需要更新的内容、写回更新后的状态——全流程不需要你手动操作。

整个系统的架构由四个 Skill 文件定义，告诉 Claude 在什么时候做什么事情：

这四个 Skill 文件的总工作量是两个小时。两个小时写好配置文件，之后整个系统就跑起来了。

文章里描述的效果很具体：

Day 30 的时候，你的仪表盘是准确的，不需要你主动去更新。它是系统运行的副产品——Claude 每处理一个任务，就顺手更新了状态文件。你只需要去看，不需要去写。

每周回顾变成了一份你实际会去读的报告，而不是一份你花时间写完就再也不看的文档。因为报告的内容是 Claude 写的，你的角色是审阅者而不是撰写者。

这听起来像个小变化，但它是系统设计里最关键的一个转移：系统不再向你收税，它变成了一项为你工作的资产。

两个小时的工作主要花在这几件事上：

1. 设计状态文件的格式 你需要先想清楚"项目状态"由哪些字段构成。比如：当前阶段、负责人、关键里程碑、风险等级、下一步行动。每个字段需要有明确的格式约定，让 Claude 能够可靠地解析和更新。

2. 写四个 Skill 文件 Skill 文件本质上是给 Claude 的指令，告诉它如何理解你的项目结构、如何在特定时机执行特定操作。这些文件不需要写得很复杂——只需要覆盖最核心的场景。

3. 测试正常路径和异常路径 正常路径是：项目推进，Claude 识别变化，更新状态文件。异常路径是：状态文件格式有误、Claude 的判断和实际情况不符、项目突然新增或取消。测试几个真实场景，确保系统在这些情况下不会崩溃。

Notion 的问题是它是结构化数据库——你需要通过 Notion 的 API 或者官方集成才能让外部工具读写数据。而 Obsidian 的本质是文件夹里的 Markdown 文件——任何工具都可以直接读写。

Claude Code 能够读写本地文件，所以它可以直接读取你的 Obsidian vault，不需要任何中间层。这就是为什么文章说"不需要 API 集成，不需要付费连接器，不需要插件"——因为根本不需要。

对于已经用 Obsidian 管理知识的人来说，这个系统几乎是零成本接入：你只需要把项目状态文件放在你的 vault 里，配置好 Skill，系统就跑起来了。

如果你符合以下任意一条，这套系统值得考虑：