核心用法
该技能构建了一套以文件夹为核心的本地项目管理系统，工作流围绕「定义→执行→回顾→归档」展开。用户提及项目时，助手协助界定范围、创建 ~/projects/ 文件夹结构；添加任务时自动捕获到对应项目上下文；并通过定期回顾提示暴露停滞项目。
启动流程遵循 GTD 风格的三问：用一句话描述项目、设定截止日期（或明确无截止）、确定「下一步具体行动」。系统强制创建 README.md 记录这些信息，从起点建立清晰边界。
任务管理强调「具体行动优先」——「研究选项」是有效任务，「搞定装修」则过于模糊。支持按小/中/大或小时数估算任务规模。当任务超过 15 项时，建议按阶段（phase）分组；出现依赖关系时标注阻塞任务；涉及协作者时明确责任人。
项目生命周期管理是该技能的显著特点：建议同时进行的活跃项目不超过 3-5 个，多余项目移入 _someday/ 文件夹季度回顾；检测 2 周无进展的停滞项目，提供「推进/暂停/终止」三选一决策；完成后必须回顾得失并归档至 _archive/year/，强制庆祝环节防止无缝衔接到下一项目。
类型识别覆盖一次性目标（搬家、旅行）、持续领域（健康、职业）、客户工作（外部截止、可计费）、学习项目（技能获取）和创意项目（过程与产出并重）。针对客户项目额外支持时间追踪、交付物状态管理和沟通日志。
优点
- 去工具依赖：纯 Markdown + 文件夹结构，无需订阅 SaaS，数据完全本地可控
- 防范围蔓延机制：「What does done look like?」作为强制首问，从心理学上降低项目烂尾率
- 健康的工作流设计：并行项目上限、僵尸项目清理、完成庆祝等环节体现对认知负荷的理解
- 渐进复杂度：从单文件任务清单自然扩展到分阶段结构，不强迫用户过早使用复杂功能
- 客户场景适配：内置计费追踪、沟通日志等企业级需求，但保持最小实现
局限性与风险
- 无原生同步：跨设备依赖第三方云盘（Dropbox/iCloud），冲突解决需手动处理
- 协作能力薄弱：「note who owns what」仅为文本标注，无权限控制或实时协作
- 无自动化触发：停滞项目检测依赖用户主动执行「每周回顾」，无系统级提醒
- 搜索与索引：纯文件结构在大规模历史项目检索时效率低于数据库方案
- 移动端体验：手机端 Markdown 编辑和文件夹操作体验通常劣于原生 App
适合人群
- 对 Notion/Trello 等工具产生疲劳、希望回归简单文件系统的用户
- 自由职业者/小型工作室（客户项目管理场景）
- 隐私敏感型用户（拒绝云端项目管理 SaaS）
- 命令行/开发者友好人群（可与 git、脚本工作流结合）
- GTD 或 PARA 方法论实践者（系统设计理念兼容）
常规风险
数据丢失：纯本地文件缺乏自动备份机制，用户需自行配置云同步或版本控制。
结构熵增：缺乏强制约束，长期运行后可能出现个人定制的「方言」结构，降低模板可迁移性。
回顾执行衰减：「每周回顾」和「季度审视」是系统有效运行的关键，但依赖用户自律，易随时间推移被跳过。
协作摩擦：涉及多人项目时，文件共享与版本协调成本显著高于专为协作设计的工具。