Skill + Config Compiler
Markdown → JSON
读取本地 config.md,由 LLM 编译成规范机器配置并通过 Schema 校验;Markdown 未变化时直接复用上一有效结果。
MyWorkflow · File Organization
智能文件整理工作流
LetsDrop 把本地文件整理变成由人、LLM / Agent、Skill 与确定性工具共同完成的工作流。用户只维护自然语言友好的 Markdown 配置;Skill 先将其编译为经过 Schema 校验的规范 JSON,再由 AI 判断文件最可能的归宿,人确认真正要执行的操作,Executor 安全地改变文件系统。
它不是一条预先写死的流水线。语义分类由 LLM / Agent 判断;实际文件状态会在运行时产生分支;移动和删除之前,人始终保留决定权。
WORKFLOW
Markdown 是人工维护的 Source of Truth。Skill 内置 Config Compiler,把它转换成规范化 JSON;Scanner 观察 Inbox,LLM / Agent 使用编译后的机器配置生成 Plan。Web Review 是第一次人工确认;之后 Executor 才真正执行文件移动。
Markdown → JSON
读取本地 config.md,由 LLM 编译成规范机器配置并通过 Schema 校验;Markdown 未变化时直接复用上一有效结果。
扫描 · 语义分类 · Plan
Scanner 获取候选文件;LLM / Agent 结合编译后的目录语义判断主归档位置、其他相关位置与置信度。
Human-in-the-loop
用户快速审查 AI 的建议,取消不希望自动处理的项目;未确认文件继续留在 Inbox。
确定性文件操作
只执行确认后的 Plan,并在运行时处理同名冲突、引用创建与操作日志。
RESPONSIBILITY BOUNDARIES
理解意图并组织流程,内置 Config Compiler 与机器配置校验规则;本身不保存用户的个人目录配置。
用户唯一需要人工维护的配置源。可用自然语言详细描述 Inbox、候选归档位置及自己的文件管理经验。
只观察文件系统,不负责语义分类;默认忽略 重复已验证_ 文件。
只负责判断并生成 Plan,不执行 move、rename、delete 或底层 hash 操作。
把 AI 建议交还给用户,形成文件系统发生改变之前的明确审批点。
重新检查真实文件状态,只执行已经确认的确定性操作,并记录结果。
RUNTIME CONFLICTS
Plan 只表达“建议移动到哪里”。目标目录的实际状态以 Executor 执行时为准;只有发生同名冲突时才需要进一步用内容 hash 作确定性判断。
两者都是不同实体。双方都改为 原文件名_hash.ext,避免让先进入目录的文件天然获得无后缀名称。
Executor 不移动,也不删除 Inbox 源文件,而是改名为 重复已验证_原文件名.ext,交给 Duplicate Review。
重复已验证_ 前缀 → 已验证重复文件不再进入 AI 分类 → 用户在 Duplicate Review 中可全选并显式执行清理。DESIGN PRINCIPLES
LetsDrop 使用 Canonical Location + References:真实文件移动到最合适的主位置;其他同样合理的位置建立快捷方式或引用,而不是复制多个独立实体。
用户只维护 Markdown;Skill 将其编译、校验为 JSON 中间表示,后续确定性环节只消费规范结构。
信息不足或置信度过低时,文件继续留在 Inbox,等待以后或人工处理。
移动前有 Web Review;重复文件删除前还有 Duplicate Review。
同名冲突必须通过明确规则处理,不允许 Executor 直接覆盖已有实体。
实际文件操作记录日志,为后续 Undo、异常恢复和审计留下基础。
语义不确定性交给模型;文件 hash、移动、重命名和引用创建交给可验证的工具。