我是如何管理自己的数字资产的
本页目录
这篇文章跟大家分享一下我是如何管理我的数字资产的，方法可能未必通用，也未必先进，希望大家能有所得。
我的数字资产管理方案是这么推导的，“我是谁？”->“我会产生哪些资产？”->“这些资产需要怎样的创作与管理能力？”->“我手里有哪些设备和存储服务？”->“资产存放与管理方案”。
数字资产管理的一些细节，跟你有什么设备、购买了什么软件、有什么云服务很相关，有时候会互相交织没有因果关系。
让我们接下来一步一步推导：
我是谁，会产生哪些资产？
按照数字资产的产生量和管理复杂度来看，我首先是一名软件工程师、开源爱好者，其次是家庭成员，同时周末的时候也会和家里人一起看看电影电视剧。
- 软件工程师、开源爱好者：大量与代码、文档、笔记、会议分享、论文、项目资料相关的资产。
- 家庭成员：家庭生活中的各种证件、体检、车辆等日常资料。
- 观影者：一些电影、电视剧、动漫等等。
这些资产需要怎样的创作与管理能力？
不同资产需要不同能力：
- 普通文件需要跨设备访问、目录组织、文件名搜索和全文检索。
- 代码需要版本控制、分支、提交历史和协作流程。
- 照片和个人视频需要时间线、人物、地点、相册和移动端浏览体验。
- 论文和书籍批注需要 iPad 阅读、手写、高亮和页面级上下文。
- 影视和大型媒体需要大容量存储和播放环境。
我手里有哪些设备和存储服务？
当前我有如下几个主要使用设备：MacBook Pro M1 Max、iPhone 15 Pro Max、iPad Pro M5，之前还有一个Windows台式机，主要是平时打打魔兽争霸、枪火重生，后面因为太占地方已经二手出掉了。这意味我几乎所有的工作都在Apple生态内完成。
除了这些设备外，我还有以下几个存储订阅/设备：
- Microsoft 365 订阅：自带 1TB OneDrive 空间，适合多平台访问，多平台支持良好。
- iCloud（家庭共享）：每月 21 元，提供 200GB 空间，与 Apple 系生态深度融合。
- 家用 NAS：群晖四盘 NAS，目前插入了一个 16TB 的硬盘。
资产存放与管理方案
如果你看重你的资产，照片、PPT，或者是代码，一定要做好容灾。比如放在家中 NAS 里，不管多少个盘都有同一个故障因子，这时候可以叠加一个远程备份，比如到 OneDrive、百度网盘之类。
一个常见的备份原则 3-2-1 原则：
- 3：存储 3 份完整文件，一份原件加上两份拷贝。
- 2：将文件起码保持在两种不同的介质上。
- 1：将一份拷贝保存在异地。
我自己也没按 3-2-1 原则搞得那么复杂，觉得丢失也无所谓的东西就放在 NAS 或者某个设备的硬盘上，有所谓的东西就放在 OneDrive、iCloud 或者 GitHub 上。
我的资产存放原则是：优先使用云盘和开放格式管理文件型资产；对于照片、批注、手写、影音等专业场景，则交给更合适的 App 或设备。低心智快速存放，灵活搜索即可，不追求一次性精确归类。
更适合交给专业系统管理的资产如下：
- 代码资产使用 GitHub 进行管理。
- 论文、书籍的阅读批注版放在 Goodnotes。
- 当前正在手写的草稿放到 Notability。
- 个人照片、短视频使用 iCloud 照片管理。
- 影音（并非个人特殊），不属于个人独占的数据（如电影、公共资料等）使用 NAS 进行管理。
我尝试过多次，要不要在 Notability、Goodnotes 两个软件之间归一，最终都以失败告终。
Goodnotes 没办法快速进入手写，Notability 进入空白笔记只需要一次操作，Goodnotes 要两三个操作，功能、概念太多导致的复杂性，有利也有弊。
Notability 之前不支持多级文件夹，现在好像是支持，但是仍不支持不同文件夹下笔记重名，两者的数据存储模式，似乎一个是文件夹方案，另一个是平铺再加标签方案。这导致一些很结构组织化的管理用起来不舒服。
排除掉这些更适合交给专业系统的资产后，剩下大量 PPT、Word、PDF、Markdown、图片素材、参考资料和博客内容，我都把它们放在 OneDrive 中，OneDrive 是我个人文件型数字资产的核心仓库。
为什么是 OneDrive
我个人同时订阅了 iCloud 和 OneDrive，选择 OneDrive 的核心原因主要是：iCloud 云盘与 macOS 的文件删除行为联系紧密，清空 Mac 回收站同时彻底删除 iCloud 中的文件。相比之下，OneDrive 上存在一个网页回收站，我曾经失误将 OneDrive 挂到 Linux 目录上 rm -rf 过，最终还能找回。
OneDrive：文件型数字资产的核心仓库
OneDrive目录说明
家庭：家庭长期档案库，保存体检报告、工作合同、医疗记录、考试成绩单等资料，不使用 PARA 拆分。游戏：游戏相关文件。Archive：存档目录，保存已经完成、放弃或停止维护，退出当前活跃工作但仍值得保留的项目和材料。Areas：领域目录，保存需要长期维护的责任领域、主题积累和个人成果。内容通常会被持续补充、更新和复用。Attachments：附件目录，由应用统一管理，不承担个人文件的主要分类职责。Documents：独立文稿目录，目前主要保存博客草稿，直接平铺在这一层。明确属于项目或领域的内容，放到对应目录中。Public：公开内容目录，保存已发布、已定稿准备对外使用的内容，以及持续维护的个人公开资料。其中Public/Blog保存博客文章及其配套图片。Projects：项目目录，保存正在推进、有明确目标或结束条件的事项。Resources：资源目录，保存可查阅、可复用、可调用的资源资产。Resources中的内容可以编辑，但主要用于查阅、调用、复制、复用或支持其他工作。通常以别人或组织产出的资料为主；自己产出的内容如果已经从“一次表达”变成“通用素材、模板、案例、培训材料或可复用组件”，也可以放入Resources。
OneDrive文件组织原则
1. 以 OneDrive 为中心，App 只读
以 OneDrive 为中心，App 只作为阅读器/浏览器，随时访问文件、打开、批注，可以像 PowerPoint 一样缓存 OneDrive 里的文件，但不要把文件导入到自己的沙盒里（比如 Readdle 那种要复制一份进 App 内部的），不产生多份拷贝。
2. 跨平台访问，开放格式
跨设备/平台可访问，使用开放的文件格式：
- 拒绝非标准封装或 App 独占格式（如 Evernote ENEX、Notion 数据库导出）。
- 文件就是资产本体，不依赖数据库或工具才能访问。
3. 低心智快速存放，灵活搜索
现如今的搜索功能都非常强大，我们并不是在维护一个图书馆。如何让一个文件/资料更低心智地存放、更低成本地找到，往往比如何把它分类得绝对正确更重要。
很多人在整理文件时容易陷入一个误区：希望设计一套完美的目录结构，让任何文件都能找到唯一且正确的位置。但现实情况是，一个文件往往同时属于多个维度。
比如一篇关于 AI Agent 的 PPT：
- 它可能属于某个项目；
- 也可能属于个人技术研究；
- 还可能是一次会议分享材料；
- 未来甚至会成为参考资料。
如果为了追求分类准确而不断调整目录，最终维护成本会远远超过收益。
4. 整体参考 PARA，但不原教旨使用
Projects 用于阶段性推进，Areas 用于长期领域积累，Resources 用于参考和复用，Archive 用于保存已经结束的内容。
我没有在 OneDrive 下面再创建一个“个人资料库”之类的目录，而是直接使用根路径。这样做主要是为了降低访问成本：在 Finder、手机 App 上，这些核心目录都能少一跳访问。
同时，我将对外的内容和家庭档案保留了独立的目录（小规模，高度内聚按 Topic 聚合）。对外内容放在 Public 中，下面分为 Blog、Presentations 和 Profile。
在微软生态下，OneDrive 的根路径很容易就会有文件夹 Documents（还有 Attachments，只要你用了 OneNote、Outlook 这样的软件），我把自己的独立文稿放在 Documents 中，目前主要是博客草稿，直接平铺在这一层，Obsidian 新建笔记也默认放到这里。
在 PARA 方法论中，还推荐使用 Inbox 路径，用于接收和暂存尚未完成分类或后续仍需处理的信息与文件。Inbox 作为整个系统的缓冲区，帮助用户快速捕获外部输入，避免在信息进入系统时频繁进行分类决策。对于归属明确的内容，也可以直接存放到对应的 Projects、Areas、Resources 或 Archive 中，而无需经过 Inbox。
我这里稍微有点特殊，个人场景里的外部文件流没有公司里那么密集，反而是零散想法更多一些，就直接放到 Documents目录里，再搭配上操作系统自带的下载路径（这类文件应该被快速迁移，同步到云盘价值也不大），临时手写草稿则先放在 Notability 里。这样一来，我就没有创建 Inbox 路径，也可以说是把 Inbox 路径给分解了。
如果换一个场景，比如公司内，经常有各种材料从 IM、邮件等涌来，我想我一定会创建一个 Inbox 文件夹。
5. 如无必要，不新增文件夹
目录不是越细越好。目录越细，判断成本越高（有些文件就没有合适的单一维度可用于 MECE 分类）。这就像代码要不要分目录、分包一样，有点多了的时候再分包即可。
6. Resources 按资源类型组织，避免变成“垃圾桶”
有明确用途的内容跟随用途，独立内容才进入通用分类。
Resources 如果文件夹建得不好，最容易变成“资料”垃圾桶，所以我给它加了一个限制：
一级目录原则上按资源类型组织，而不是按临时主题、来源或场景来建。如 Media（图片、音频、视频和成套媒体资料）、Slides、Docs、Sheets、Books、Papers、Standards（标准）、Templates、Prompts、Skills 等这些资源类型。
如果一级目录下，该类型的文件非常多，可以继续创建下一层目录，但二级目录也应该尽量使用稳定、客观的分类维度。比如 Templates/PPT、Tools/Macos、Standards/RFC、Pcap/MySQL 这类目录就比较稳定，尽量避免用“学习”、“AI”、“重要”这类名词，它们刚开始看起来很顺手，但时间一长，边界会越来越模糊，最后又变成一个新的“垃圾桶”。
少量天然跨格式、经常按资料包整体检索的集合可以作为一级特例。目前只有 Conferences，一个会议资料包里可能同时有 PPT、PDF、图片、视频、讲者指南和模板，如果强行拆散，反而不利于查找。会议资料如果已经拆散并按类型使用，也可以放入 Resources/Slides、Resources/Media/Images。
Templates 虽然也可能包含 PPT、Word、Excel 等多种格式，但它的共同使用方式非常明确：作为模板被复制和复用。因此我把它作为 Resources 下的稳定资源类型，而不是特例。
文件放置判断链
对于已经退出活跃工作的项目或领域材料，值得保留的放入 Archive。其余文件按如下链条判断位置：
- 是否属于家庭成员、共同资产、家庭财务或生活档案？→
家庭 - 是否已经发布、已定稿准备对外使用，或属于持续维护的个人公开资料？→
Public - 是否明确服务当前项目交付，并且项目有目标或结束条件？→
Projects - 是否属于长期责任、长期能力沉淀，或自己的研究过程？→
Areas - 是否是自己正在写、整理、发展，但尚未归属具体项目或领域的独立文稿？→
Documents - 是否主要用于查阅、调用、复制、复用，或者来自会议、外部资料包？→
Resources
专业 App：只承担特定场景
Notability 我只写一些临时草稿，写好了就会整理到 OneDrive 去，基本没什么管理，常年不会超过 10 个笔记。 Goodnotes 我只管理批注版书籍和论文，因此目录很简单。
Books：存放批注的书籍。Papers：存放批注的论文。
让数字资产成为AI 的工作上下文
随着我越来越多地使用Agent，我深刻地感受到你应该给Agent一个充分的上下文环境。目前，我把我的所有工作都放在home目录，代码放在code，其他资产放在网盘上。
即使是Windows电脑也一样，我在D盘只保留了极少的东西，下一台Windows电脑，我应该会考虑不用D盘。在多个目录维护了AGENTS.md、README.md来支撑工作。
home/
├── AGENTS.md 个人背景、资料位置和通用操作约定
├── code/ 本地代码仓库
│ └── 某个代码项目/
│ ├── AGENTS.md 项目开发约定
│ ├── README.md 项目介绍与使用说明
│ └── ...
└── OneDrive/ 指向 OneDrive 同步目录
├── AGENTS.md Agent 在资料库中工作的约定
├── README.md 目录含义与文件组织原则
├── Archive/ 已退出活跃工作的材料
├── Areas/ 长期责任与积累
├── Documents/ 独立文稿
├── Projects/ 当前正在推进的事项
├── Public/ 对外内容
└── Resources/ 可查阅、可复用的资源结尾
这套方案并不是一次性设计出来的，而是在我的工作内容、家庭资料、设备条件、软件订阅和历史使用习惯之间慢慢折中出来的。数字资产管理不应该追求一种抽象上的完美分类，而应该降低日常使用时的判断成本。在搜索能力愈发强大的当下，快速整理存放，把时间放在产出而非整理上更重要。
修订记录
2026.10.28 从OneDrive转向iCloud
由于不再存在Windows上工作的需求，出于节约订阅费用，迁移到iCloud。
2026.10.17 不再沿用卡片盒笔记法（Zettelkasten）的分类
ReadingNotes里面存放的内容并不是读书笔记，更多的是按书名、章节保存的原文摘录集。因此，我把ReadingNotes跟原先的LiteratureNotes合并成Clippings，放在Resources/Clippings。
原来的 FleetingNotes 实际上主要承接博客草稿，很少承担所谓“闪念笔记”的独立用途。我去掉了这层目录，直接平铺在 Documents 中，Obsidian 新建笔记也默认放到这里。