技巧分享| 通过task目录约定，治好 AI Agent 的健忘症

我用一个看起来"多余"的 task 目录约定，治好了 AI Agent 的健忘症

一个小技巧：让 AI 习惯干活前先建个文件夹。

一、问题：AI Agent 干活的三个"洁癖噩梦"

AI Agent 干活有个特点：它不在乎放哪里。

你让它写个 Python 脚本，它扔根目录。让它生成一张封面图，它扔根目录。让它改个 bug，改了三个文件，还是扔根目录。

几周之后，workspace 就变成了这样：

workspace/
├── output.py          # 哪个任务的？
├── gpt_image_1.png    # 几张图混在一起
├── gpt_image_2.png
├── test_fix_v2.py     # v2？v1 呢？
├── draft.md           # 什么草稿？
├── final_draft.md     # 第几版？
└── 真正重要的项目/
    └── ...

三个核心痛点：

1. 不知道怎么归档。文件散落一地，分不清哪个属于哪个任务。做完一个任务，不敢清理——怕删错。
2. 不知道做了什么。一周后回头想复现某个结果，找不到当时的上下文：用了什么 prompt？调了什么参数？踩了什么坑？
3. 不知道做没做完。Agent 安静了好几分钟，是跑完了还是卡死了？产出的文件全不全？没人检查。

二、解法：让每个任务有自己的"房间"

解决方案简单到说出来你可能觉得不值一提：给每个任务建一个独立目录。

tasks/
├── active/
│   └── TASK-20260606-001-tencent-dev-article/
│       ├── output/
│       │   └── article.md
│       └── metadata.json
└── completed/
    └── TASK-20260331-001-xx-ppt/
        └── output/
            └── presentation.pptx

命名规范：一眼看懂的编码

TASK-YYYYMMDD-XXX-简短描述/
     │           │   │
     │           │   └── 任务内容（中文/英文均可）
     │           └────── 当日序号（001, 002, ...）
     └────────────────── 创建日期

示例：

• TASK-20260606-001-tencent-dev-article —— 6月6日第1个任务：xx文章
• TASK-20260429-001-xizang-ai-funding —— 4月29日第1个任务：xxAI基金研究
• TASK-20260521-001-py-ppt-engine —— 5月21日第1个任务：Python PPT引擎

生命周期：三段式管理

创建（新任务，>4轮对话）
  → tasks/active/TASK-YYYYMMDD-XXX-描述/
      ├── output/           ← 所有产出放这里
      └── metadata.json     ← 任务上下文记录
  ↓
进行中
  → 产出全部进入 output/
  → 根目录零散落
  ↓
完成
  → 移至 tasks/completed/
  → 不删，永久存档

三条铁律：

1. workpace 根目录不允许出现任何散落文件。有 task 的放进 task，没有 task 的放进对应文件夹
2. 产出必须全部在 output/ 下，不要 task 目录里东一个西一个
3. 完成后移入 completed/，不删，要能追溯

三、这不是文件夹，是 Agent 的上下文锚点

这个设计真正的价值不在"整理"，而在让每个 task 成为 Agent 的可追溯上下文锚点。

目录即清单

task 目录本身就是待办清单。一个新 task 目录建立时，Agent 就知道"我要产出的东西都应该放进这里"。任务结束时，扫一眼 output/ 就知道做完了没有、少了什么。

路径即索引

想找三月份的某次 PPT 生成任务？不需要搜文件内容，看目录名就够了：

tasks/completed/TASK-20260331-001-xx-ppt
tasks/completed/TASK-20260331-002-xx-hospital
tasks/completed/TASK-20260406-001-xx-chuping
tasks/completed/TASK-20260414-001-xx-equipment-pricing

目录名包含了时间、序号、内容摘要——一个自解释的文件系统级索引。

命名即追溯

目录名里的任务描述让你一眼知道"这是什么"，日期让你知道"什么时候做的"，序号让你知道"那天第几个"。不需要数据库、不需要标签系统，文件系统本身就是最好的元数据载体。

如何让 Agent 自动遵守：一条 SOUL 约束

光靠"约定"是不够的。Agent 每次会话的记忆是独立的，你不可能每次都手动提醒。我的做法是把这条约束写进 Agent 的常驻策略注入（SOUL.md），每次会话自动加载：

Gene 2: TaskManagement
SIGNALS: 新任务、多步骤工作、预估>4轮对话
STRATEGY: 立即创建task目录（tasks/active/TASK-YYYYMMDD-XXX-描述/）。
          任务产出全部放入task目录。完成后移至tasks/completed/。
AVOID: × 不跳过task创建直接干活
       × 不在workspace根目录创建散落文件

一共 4 行，约 120 token。Agent 每次启动都会读这段，形成了稳定的行为基线。关键设计点：

• SIGNALS：明确触发条件——"预估>4轮对话"。不是每个小请求都建 task，避免过度设计。
• STRATEGY：三句话讲完命名规范 + 存放规则 + 生命周期。
• AVOID：禁止式约束，而非描述式建议。"不散落"比"请整理"有效得多。

四、60+个 task 之后，我发现了一些规律

从 2026 年 3 月底到现在，我已经创建了60+个 task。回头看，有几个有意思的规律：

任务类型高度集中

这个分布让我意识到：大部分任务其实是生成型任务（PPT、文档、代码）而非分析型任务。生成型任务对文件管理的要求远高于分析型——因为产出是实体文件，散落的问题更严重。

最长的 task 跨度 3 天

TASK-20260427-001-gem-architecture 和它的修复版本 TASK-20260427-002-gem-architecture-fix 跨了 2-3 天。如果没有 task 目录，三天前的上下文完全丢失——你不可能还记得当时用的什么参数、中间遇到了什么问题。

completed 目录成了我的"作品集"

60个 task 中有相当一部分已经移入 completed/。它不是"垃圾桶"，而是"作品集"——任何时候想回顾某个项目，路径就是入口。

五、配套工具：cleanit — task 机制的"交警"

Task 机制要落地，光靠自觉不行。我写了一个小技能 cleanit，在每次会话结束时执行审计：

cleanit  →  逐条检查 23 项合规指标

检查覆盖六个维度：

23 项检查，3 秒跑完。每次会话结束前自动执行一次，发现问题当场纠偏。

cleanit 已开源在 GitHub（MIT 协议，和 task 系统配套使用）：github.com/jafferchong/cleanit

六、这个小技巧为什么有效：三条原则

1. 约束前置，而非事后补救

不是在文件散落之后再去整理，而是在 Agent 动手之前就给它一个"房间"。Task 目录创建是任务执行的第一步，不是最后一步。

2. 用文件系统做数据库

不需要引入任何新工具。文件系统本身就是最好的任务管理工具——目录名 = 元数据，路径 = 索引，ls = 查询。零依赖，永久可读。

3. 目录即契约

Task 目录不只是文件夹。它是一个隐式契约：Agent 承诺"这个任务的所有产出都在这里"。契约不需要写在文档里，目录的存在本身就是约束。

七、几个不成熟的小建议

如果你也想给自己的 AI 工作流加上 task 机制：

1. 从下一个任务开始。不要想着"回头整理"。下一个新任务就直接建 task 目录。
2. 别纠结命名。TASK-YYYYMMDD-XXX-描述 足够，不用更复杂。
3. 配上一个审计工具。自觉不如检查，检查不如自动化。类似 cleanit 的收尾审计能让规范变成肌肉记忆。
4. completed 不要删。硬盘不值钱，上下文值钱。半年前的 task 目录可能是你唯一能找到当时工作记录的地方。

GitHub: github.com/jafferchong

本文提及的cleanit 技能已开源（MIT 协议）：github.com/jafferchong/cleanit