判定
每一项都会针对每个可能执行的操作得到一个判定，判定附带理由。颜色从来不是唯一的标识：每种判定都有自己的图案、自己的标记和自己的规则。
已锁定和不确定的项目永远无法选中。需查看的项目只有在选择“仍然加入”后才会清理。
四种判定
| 判定 | 含义 | 清理时 |
|---|---|---|
| READY可清理 | 此操作的所有检查均已通过。 | 一开始就已选中。 |
| REVIEW需查看 | 已知的风险，或只有你才能做的决定。 | 通过“仍然加入”。 |
| BLOCKED已锁定 | 正在使用、受保护，或含有 git 会拒绝丢弃的工作。 | 无法选中。 |
| UNKNOWN不确定 | 证据不足。 | 无法选中，永远不会算作可清理。 |
命令行以大写形式打印同样的判定。
理由
判定的理由会写明关于这一项的已知信息。例如：
- 属于哪个智能体：“属于一个运行中的 Claude Code 会话”，或者是哪个工具创建的。
- **是否正在使用：**其中或其上级文件夹中有智能体会话在运行、有进程从这里运行、有文件被打开占用。
- **未保存的工作：**已修改、未跟踪或已暂存的文件；未推送的提交；git 锁。
- **证据：**在光凭名称不够的地方，它要寻找的标记，例如
node_modules旁边的package.json。
可清理
所有检查均已通过。按下“清理”时，这一项还会再检查一次；如果期间有任何变化，就不会动它。
需查看
删除它很可能没问题，但有些事情 Devbroom 无法知道。例如：
- worktree 中有一个被忽略的
.env文件：git worktree remove会不加询问地删除它。git status干净，并不能证明里面没有有价值的东西。 - 名称看起来像构建文件夹，但旁边没有能证明这一点的项目文件。
dist、build和vendor这类含义模糊的名称，除非有构建脚本生成它们。- 重新下载代价很高的缓存：pnpm store、Playwright 浏览器、Hugging Face 模型。
- 由智能体自己管理的文件夹。
已锁定
现在动它可能会破坏某人的工作：
- 其中或其上级文件夹中有智能体会话在运行、有进程从这里运行，或其中有文件被打开占用。
- 含有未提交更改、未跟踪文件或已暂存更改的 worktree。没有
--force，git 不会删除它；Devbroom 从不使用--force。 - 主工作副本、含有子模块的 worktree，或被 git 锁定的 worktree。
- 受保护的文件，例如智能体的数据库和凭据。
- 只应使用智能体自己的命令来清理的东西。
不确定
无法判断它属于哪个智能体，或者其中一部分无法读取。Devbroom 从不把它不了解的东西算作可清理。
你自己的规则
项目根目录下的 .devbroom.toml 可以说明该项目中哪些算作构建输出。由于这个文件也可能是智能体写的，命令行不会不经询问就信任它：devbroom clean --yes 会排除仅因该文件而被判为可清理的项目。
最后更新： 2026年10月7日