目录即状态
用文件所在的目录位置直接表达它的处理状态，而不是给每条笔记额外发明布尔字段——让流水线式的知识加工用”它走到哪一步了”取代”它该归哪个主题”。
简介
目录即状态（Directory-as-State）是 @Sean 在《3 个脚本、4 个 Skill、3 层防线》中提出的知识库信息架构原则：把知识加工目录按处理状态而非主题内容来划分，让文件所在的目录位置本身就成为它的状态标记。Inbox 里的就是还没碰的，Processed 里的就是处理完等待讨论的，Review 里的就是讨论过的，Archives 里的就是归档的原文。用户不需要想”这篇文章该放哪个主题”，只需要知道”它走到哪一步了”。
这个原则是作者”推倒重来”目录结构后的核心收获。他最初和大多数人一样按主题建目录（产品方法论、行业洞察、AI 学习……），第二周就崩了——因为主题分类”分不准”（一篇讲 Agent 信贷风控的文章到底放”业务领域知识”还是”行业洞察”）且”懒得分”（人性使然，工作间隙不会为每篇文章多花两分钟纠结归类）。按状态分目录彻底绕开了这个问题：状态是客观的、唯一的、随流程自然推进的，不需要主观判断。
关键信息
- 类型：知识库信息架构原则 / 状态管理方法
- 核心主张：目录位置 = 处理状态，不额外发明布尔字段
- 解决的问题：主题分类”分不准 + 懒得分”导致的 Inbox 堆积
- 典型状态流：Inbox → Processed → Review → Archives
- 相关概念：状态文件、脚本与大模型分工、知识库构建工程、闭环沉淀
核心特性
1. 状态流水线：Inbox → Processed → Review → Archives
@Sean 的知识库工厂把加工流程铺成一条流水线，每个状态对应一个目录：
| 目录 | 状态含义 | 谁来推进 |
|---|---|---|
| 01 Inbox | 原始文章，还没碰（主要来自 Web Clipper） | 人（碎片时间收集） |
| 02 Processed | AI 批量提炼后的结构化笔记，等待讨论 | 脚本（batch_ai_process） |
| 03 Review | 人工深度讨论后迁移过来的文章 | 人 + AI（deep-discuss） |
| 04 Archives | 被批量提炼的原始文章归档 | 脚本（migrate） |
最关键的加工工序——深度讨论——需要知识库主人亲自参与，用自己的理解和迁移”点亮”知识。其余的搬运、归档、格式化都由脚本按状态自动推进。
2. 不加多余布尔字段：目录位置就是唯一真相
很多人设计笔记系统喜欢加 processed: true、discussed: true、archived: true 这类布尔字段。@Sean 一开始也想这么干，后来发现根本不需要——文件在 Processed 目录下就说明处理过了，在 Review 下就说明讨论完了，目录位置本身就是状态，再加字段纯属多余。
更麻烦的是字段和目录可能不一致：一篇笔记已经从 Processed 移到 Review，但你忘了把 status 字段从 processed 改成 review，这时候到底信谁？作者的做法是：让 status 字段的值和目录名保持一致（inbox / processed / review / archived），不做额外发明。这样 Dataview 查询时直接按目录筛选，比扫描全库的布尔字段可靠得多。
3. 流动态按状态分，沉淀态按主题分
一个容易被忽视的细节：@Sean 的知识库并非全部按状态分。“个人知识库工厂”（加工区）按状态分，但”Knowledge Cards”（沉淀后的知识层）又是按主题分的。原因是后者不再是流动中的中间态，而是稳定的知识资产。而且主题分类这件事，作者留给了大模型在深度讨论阶段完成——“它比我更擅长判断一张卡片应该归到’知识库工作流’还是’AI PM 转型’”。
这引出一条更普适的分工原则（见 脚本与大模型分工）：让脚本处理不需要人介入的重复劳动，让大模型负责语义理解和知识推理，把人的精力留给关键结果的最终决断。
不同素材中的观点
-
2026-07-11-woshipm-knowledge-base-engineering-practice：@Sean 把”按主题分”推倒重来为”按状态分”作为整套系统能跑下去的起点。核心洞察是”人工分类最大的敌人不是技术，是人性”——按主题分需要每次主观判断，而人性会拒绝这种持续消耗；按状态分则是客观的、随流程自然推进的。文章进一步主张目录位置即状态、不加冗余布尔字段、让 status 字段与目录名保持一致，并把主题分类这件”需要语义判断”的事交给大模型在沉淀阶段完成。
-
2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets：同一作者的姊妹篇从”为什么这么设计”的角度补充了理由。他明确说”我用目录位置而不是布尔字段来表达工作流状态。Inbox 里的就是待处理的，Processed 里的就是待讨论的，Review 里的就是已讨论的。不需要额外加 discussed: true 这种字段——目录本身就是最高效的筛选器，状态语义也更清晰”。这篇还揭示 Processed 中间层的深层价值：它是”讨论输入而非终点”的缓冲层，用目录把”待讨论”和”已讨论”分开，避免单次理解直接污染主知识层。
-
2026-07-14-woshipm-hoarding-to-cultivation-cognitive-assets：同一作者姊妹篇用更精炼的一句复述了这条原则——“我用目录位置而不是布尔字段来表达工作流状态。Inbox 里的就是待处理的，Processed 里的就是待讨论的，Review 里的就是已讨论的。不需要额外加 discussed: true 这种字段——目录本身就是最高效的筛选器，状态语义也更清晰。“这里把三层结构（Inbox→Processed→Review）与”批量处理产物只是中间层、不是终点”绑定，强调 Processed 中间层是为后续讨论提供结构化输入的缓冲区，佐证了”目录即状态”不只是分类偷懒，而是让每一步加工的语义边界清晰。
实用信息
适用场景
任何”素材持续流入、需要分阶段加工”的个人知识管理场景：文章消化、论文精读、灵感沉淀、内容生产流水线。判断信号——如果你的 Inbox 长期堆积、主题目录形同虚设、每次存东西都要纠结归类，就该考虑改成按状态分。
落地步骤
- 建状态目录：最简版四个即可——Inbox、Processed、Review、Archives
- 让状态字段跟随目录：frontmatter 里 status 的取值就用目录名，不发明第二套语汇
- 用查询按目录筛选：Dataview / 脚本直接按目录路径过滤，不扫描布尔字段
- 沉淀层再按主题分：稳定下来的知识卡片单独放一个按主题组织的区域，主题判断交给大模型
- 不为”完整”提前建目录：状态目录够用就好，痛点出现时再加（见 知识库构建工程）
注意事项
- 不要状态字段和目录并存却各说各话——要么只信目录，要么让字段严格镜像目录
- 状态目录是给”流动中的中间态”用的，不要拿它管理已经沉淀的长期知识
- 主题分类不是不做，而是延后到沉淀阶段、并交给更擅长语义判断的大模型