关联主题:: Claude Skills说明(2026.02.03), Skill-creator
同级:: CFlow-Brain——用Codex开发cflow智能助手Skill
下一级::


项目管理 Skill:用 Notion 承载活项目

为什么需要这个 Skill?

很多项目并不是一次性写完的文档,而是不断推进、不断补充、不断调整的问题集合。

典型场景是:

  • 手机端随手记录想法、进展、问题和资源;
  • 项目执行过程中经常出现碎片信息;
  • 任务、文档、沟通记录、外部链接散落在不同工具里;
  • AI 每次介入时,如果只看当前页面,很难知道之前改过什么、为什么这么改。

如果把所有内容都强行同步到一个 Markdown 笔记里,移动端体验可能不够顺手;如果只放在 Notion,又容易缺少版本感和长期记忆。

所以这个 Skill 的核心思路是:

Notion 负责活项目执行,本地账本负责 AI 修改历史。

Notion 是项目主阵地,适合移动端记录、项目状态管理和任务视图;本地记录则保存 AI 每次处理 Notion 项目的快照和操作日志,方便之后回看差异。


设计原则

这个 Skill 有几个明确边界。

1. Notion 是活项目主库

执行中的项目优先放在 Notion:

  • 项目目标
  • 当前进度
  • 问题与思路
  • 资源表
  • 项目记录
  • 任务入口

其他工具可以作为来源,但不和 Notion 做自动双向同步。

2. 默认新增,不默认修改和删除

项目管理里最危险的不是信息多,而是历史被无意覆盖。

所以规则是:

  • 默认追加新记录;
  • 默认不删除旧内容;
  • 默认不覆盖已有段落;
  • 需要修改、替换、删除时,AI 必须先说明旧内容和拟修改内容,并等待确认。

这套规则特别适合长期项目、争议项目、证据项目、复杂协作项目。

3. 碎片入口可以很多,项目沉淀只有一个

任务工具、碎片笔记工具、聊天记录、文档链接都可以作为来源。

但最终进入项目页时,需要被整理成几类内容:

  • 新事实 → 项目记录
  • 新问题 → 问题与思路
  • 新文件/链接 → 资源表
  • 明确行动 → 任务或下一步动作

这样可以允许记录入口分散,但项目状态不分裂。


项目模板

Skill 使用固定项目模板,重点是帮助 AI 区分「目标」和「进度」。

## 项目进度
---
**【目标】** [明确项目最终要达成的状态]
**【进度】** [当前已经走到哪一步、已有材料、卡点和下一步]
 
> 目标 = 最后希望事情被推进到什么状态;进度 = 现在已经走到哪一步。
 
## 问题与思路
---
**【问题】**
- **问题 1:**[描述问题]。方法:[应对策略或思路]
- **问题 2:**[描述问题]。方法:[应对策略或思路]
 
## 资源表:项目文档、表格、排期、备忘、SOP 等
---
**【资源】**
- **文档 / SOP:**[链接或说明]
- **表格 / 排期:**[链接或说明]
- **备忘录:**[链接或说明]
- **关键线索:**[链接或说明]
 
## 项目记录
---
**【记录】**
- **[[YYYY-MM-DD]]**:[当天项目进展、延误、决策、下一步]

这不是为了把所有项目都写成一样,而是为了让 AI 每次接手项目时都有稳定抓手。


工作流

创建项目

创建项目时,AI 会先把用户给出的信息整理成草稿。

流程大致是:

  1. 提炼项目名称、目标、进度、问题、资源和记录;
  2. 按模板生成项目页草稿;
  3. 用户确认后,在 Notion 项目数据库中新建页面;
  4. 写入模板内容;
  5. 把新项目登记到本地项目注册表;
  6. 保存第一次 Notion 页面快照。

更新项目

更新项目时,AI 不会直接改页面。

更安全的流程是:

  1. 先读取本地项目注册表,确认项目页面;
  2. 读取 Notion 当前页面;
  3. 保存一份修改前快照;
  4. 将新信息转换成追加内容;
  5. 写入 Notion;
  6. 保存一份修改后快照;
  7. 如有需要,生成前后差异。

本地记忆系统

这个 Skill 不把动态数据写进 Skill 本体。

Skill 本体只保存规则和脚本;项目数据、Skill 维护清单、历史版本保存在一个本地记忆目录中。

结构类似:

.project-management/
├── project-registry.json
├── skill-registry.json
└── notion-history/
    ├── ledger.jsonl
    └── snapshots/
        └── <notion-page-id>/
            ├── 20260607T210000_before.md
            ├── 20260607T210030_after.md
            └── ...

project-registry.json

记录正在维护的 Notion 项目。

通常包含:

  • 项目名称
  • Notion 页面 ID
  • Notion 页面 URL
  • 项目状态
  • 简短摘要
  • 历史快照目录

这样 AI 不需要每次重新猜“哪个项目对应哪个页面”。

skill-registry.json

记录当前真正维护中的 Skills。

这和系统里“安装过的所有 Skills”不是一回事。安装过的 Skill 可能很多,但真正持续维护、需要项目化记录的 Skill 只有一部分。

注册表可以记录:

  • Skill 名称
  • 本地路径
  • 状态
  • 用途
  • 关联项目

ledger.jsonl

这是追加式操作日志。

每次 AI 处理 Notion 项目,都会写入一条 JSON 记录,包含:

  • 时间
  • 页面 ID
  • 操作类型
  • 操作阶段
  • 摘要
  • 快照路径
  • 内容哈希

使用 JSONL 而不是单个大 JSON,是因为它更适合追加历史,也不容易因为一次写入失败损坏整个文件。

snapshots

快照保存的是 Notion 页面导出的 Markdown。

它不是复制 Notion 里的图片、PDF 或附件本体,只保存文本、结构和链接,因此通常占用很小。

普通项目就算保存很多次版本,一般也只是几 MB 级别。真正占空间的是附件,而不是 Markdown 快照。


为什么不直接做双向同步?

因为 Notion 和 Markdown 的结构并不一致。

Notion 是块结构,Markdown 是纯文本结构。如果两边同时编辑,容易出现:

  • 旧内容被当成删除同步掉;
  • Notion block 顺序和 Markdown 段落对不上;
  • 附件、数据库、任务视图无法完整映射;
  • 双链、嵌入、属性格式丢失;
  • AI 很难判断哪个版本才是权威版本。

所以这个 Skill 采用更稳的策略:

执行期 Notion 为主,归档期再整理到其他知识库。

如果需要引用外部笔记,就在 Notion 里放链接或摘要,不做自动覆盖同步。


版本记录如何帮助 AI?

Notion 自己有页面历史,但 AI 不一定容易直接读取和比较。

本地快照的价值是:

  • AI 可以快速看到最近一次处理前后的差异;
  • 可以知道某次写入是新增、创建、登记还是更新;
  • 可以根据历史摘要理解项目为什么变成现在这样;
  • 出现误写时,可以用 Markdown 快照辅助恢复。

它不是完整 Git 仓库,但保留了最关键的能力:

当前页面是什么?
上次处理前是什么?
上次处理后变了什么?
这次写入的理由是什么?

安全边界

为了适合公开项目、敏感项目和长期项目,这个 Skill 默认遵守几条规则:

  • 不把真实数据库链接、页面 ID、私人路径写进公开文档;
  • 不自动删除 Notion 内容;
  • 不把缺失内容理解为“应该删除”;
  • 不用本地旧快照覆盖 Notion 当前页面;
  • 不把碎片工具里的内容自动全量搬运到项目页;
  • 需要改旧内容时,先给出修改方案,再等待确认。

这让它更像一个谨慎的项目秘书,而不是一个激进的同步工具。


适合什么场景?

这个 Skill 适合:

  • 长期推进的个人项目;
  • 移动端频繁记录的项目;
  • 有很多碎片想法和资源链接的项目;
  • 需要 AI 定期整理进度的项目;
  • 需要保留 AI 写入痕迹的项目;
  • 不适合完全自动同步但需要轻量版本记录的项目。

不太适合:

  • 一次性小任务;
  • 完全依赖本地 Markdown 双链的知识卡片;
  • 需要多人严格协作审批的企业级项目系统;
  • 需要数据库级强一致性的复杂同步系统。

小结

这个 Skill 的关键不是“把 Notion 自动化”,而是给 AI 一个稳定的项目操作协议:

  • 用 Notion 承载活项目;
  • 用模板稳定项目结构;
  • 用注册表记录项目和 Skill;
  • 用快照保留 AI 写入历史;
  • 用新增优先避免误删;
  • 用确认机制保护旧内容。

它解决的是一个很常见的问题:

项目不是缺工具,而是缺一个能长期记得上下文、谨慎追加、保留历史的 AI 工作流。