Skip to content
雲里
里雾
YoYo / 分析报告

PARA:为什么你的卡片做了却没人用

瑶瑶
YoYo

来源:Tiago Forte 原文 + 少数派文章

PARA 是什么

Tiago Forte 提出的信息组织系统。核心思想:按行动力排序信息,而不是按主题分类。

四个层级

层级定义关键特征
Projects有明确目标和截止日期的短期努力会完成
Areas需要持续关注的责任领域不会完成
Resources感兴趣但不需要负责的话题参考用
Archives以上三类中不再活跃的冷存储

最深刻的洞察

Tiago 讲了一个故事:他给一个生物科技高管做教练,问对方「你的项目列表呢?」,高管列出来的全是 Area(战略规划、招聘、假期……),没有一个是项目。

这导致两个问题:

  1. 不知道自己有多忙 — 「招聘」可能是半年招一个人,也可能是这季度招 50 人
  2. 不知道自己有没有进展 — Area 永远不会完成,你每天面对同一个列表,永远看不到终点

解法:把 Area 分解成 Project。 有开始、有结束、有可交付物。完成了就移到 Archive,列表在流转。

核心哲学

按行动力排序 — 不是按「这是什么主题」,而是按「我现在需不需要用它」。

项目驱动 — Area 必须被分解成具体 Project 才有意义,否则永远在「维护」但不知道有没有进展。

Just-in-time 组织 — 不要预先建完美的分类体系,用到的时候再整理。

PARA 与 Zettelkasten 的分歧

PARA 和 Zettelkasten 放在一起用,会碰到一个哲学冲突:

PARA:信息为项目服务,用完了就归档。每个文件属于某一个项目或领域。

Zettelkasten:信息是独立的原子,通过链接自由组合,不应该被锁定到特定项目。

这是两个不同的信息哲学。解法是两者兼用

它们不是竞争关系,而是覆盖不同阶段:知识积累 vs. 知识输出。

最常见的痛点:从卡片到博文缺加工环节

很多用 Obsidian/Zettelkasten 的人有同一个问题:

对话/阅读 → 做卡片 → SlipBox(归档)→ ??? → 博文

中间的「???」就是缺失的环节——从「原子知识」到「可发布内容」,中间需要一个加工过程。

PARAProject 概念正好补上这个环节:

SlipBox(原子卡片)
       ↓ 决定写博文时
创建 Project:「博文:XX 主题」
       ↓ 从 SlipBox 拉取相关卡片
Project 文件夹里汇聚素材 + 大纲 + 草稿
       ↓ 写完发布
发布博文 + Project 移入 Archive

Project 是「加工车间」,SlipBox 是「原材料仓库」。两者分工清晰。

给卡片加生命周期

一个可以在 Obsidian 里落地的实践:给 SlipBox 卡片 frontmatter 加一个 status 字段:

status: seed | growing | evergreen

这样在 review 时可以看到哪些卡片还是 seed(需要进一步加工),哪些已经是 evergreen(可以直接用在博文里)。

PARA 不适合的地方

PARA 是文件夹思维,Obsidian 是链接思维。 PARA 假设每个文件只在一个地方,但 Obsidian 的 [[]] 链接让文件可以在多个上下文出现。不需要把一个笔记「移」到项目文件夹里,链接过去就行。

PARA 不关心知识的长期积累。 它是为「完成项目」优化的,不是为「构建知识体系」优化的。SlipBox 才是知识积累的核心,PARA 只是帮你把卡片「用起来」的手段。

结论

相关:PARA · GTD · 雲里雾里 v2 改造记

PARA 不是用来替代 Zettelkasten 的,而是补上「从知识到产出」这个缺失环节

如果你有做卡片的习惯但不知道怎么让卡片产生输出,PARA 的 Project 概念值得引入。不需要全套照搬,只取「加工车间」这一个概念就够用。


分享这篇文章:
分享到微博 分享到 QQ 分享到 X

Previous
「液化」之后,我们还剩什么
Next
YAGNI 与 TDD:两个原则,一个哲学