夜雨聆风手动整理群聊文件，就是一个不该存在的工作量。
一份明明上传过的文件，找不到。
不是真的丢。是淹没在几百条消息里，等于丢。
大多数人的解决方案是：建个文件夹，定期手动整理。听起来合理。但——人做分类，天然不稳定。
机器做这件事的优势不是更快。是每次都一样。
这篇文章是我用 OpenClaw 对接飞书，跑通群聊文件全自动归档的记录。
不需要会写代码，只需要看懂这套流程怎么运作的，可以用在任何 Agent 上。
1、先搞清楚：文件乱，到底乱在哪？
做自动化之前，最容易犯的错是上来就动手。
问题没拆清楚，工具再强也是瞎忙。
群聊文件的混乱，不是一个问题。是四个问题叠在一起：
第一层：散。文件散落在消息流里，和日常对话混在一起。没人会在聊天记录里做归档——但文件就是在那里产生的。
第二层：乱。文件名没有统一规范。同一份东西，有人叫"合同终版"，有人叫"XX项目-合同-0312修改"。靠文件名判断内容？不可能。
第三层：重。同一份文件被反复上传。客户改了一版发一次，你改了又发一次。三天后群里躺着五个"终版"。
第四层：找不到。前三个问题叠加的结果。你知道文件存在，但找到它的成本太高。
所以，单纯"建文件夹"只解决第一层。后面三层需要规则：一套不依赖人的判断力、每次都按同一逻辑执行的规则。
2、我的方案：三个设计决策
决策一："实时响应"还是"定时扫描"？
两条路都能走。
实时响应：群里一有文件上传，AI 立刻处理。快，但配置复杂。某个环节一卡，用户感知到的是："系统出问题了"。
定时扫描：每隔几分钟，AI 自动去群里"巡逻"一轮。有延迟，但简单、稳定，出了问题也不影响群聊本身。
我选了定时扫描。每3分钟一次。
原因很简单：归档不需要实时。没有人上传完文件的下一秒就要去云空间找它。3分钟延迟，换来的是简洁和可靠。
拆开来看，这是一个"够用就好"的判断。很多人做自动化，总想要最快、最全、最实时的方案。但归档这种场景，稳定比速度重要得多。
决策二：文件怎么分类？
分类的本质是映射。把"文件名里的信息"对应到"文件夹结构"，仅此而已。
我的做法：用文件名做关键词匹配。团队先约定命名规范：
[文件类型]-[责任人]-[项目名称]
比如："合同初稿-张三-XX科技项目.pdf"。
然后设定关键词规则，按优先级排序：
优先级很关键——这个我后面会讲，是踩过的坑。
分类规则有了，文件夹结构也要提前想好。我用两层：第一层按项目分，第二层按文件类型分。
云空间/├── XX科技项目/│ ├── 合同文件/│ ├── 调查报告/│ └── 申报材料/├── YY咨询项目/│ ├── ...
为什么不反过来——先按类型、再按项目？
因为你找文件时的第一个念头，通常是"我要找哪个项目的"，而不是"我要找所有合同"。文件夹结构要匹配你找文件时的第一个动作。
决策三：归档后原文件怎么处理？
三个选项：保留、删除、移到"已归档"。
我最终选了删除。理由：群聊文件已经在云空间有了确定位置，保留原件只会让下次扫描时重复处理。这又是一个坑，后面详说。
但这个选择取决于你的场景。团队不放心"文件从群里消失"？可以保留。但一定要做好去重。
3、完整流程：从扫描到归档
三个决策串起来，流程长这样：
定时触发（每3分钟）↓扫描群聊消息，筛选出文件类型的消息↓解析文件名 → 提取文件类型、责任人、项目名↓按关键词规则匹配 → 确定目标文件夹↓下载文件到本地临时目录↓上传到飞书云空间对应文件夹↓删除群聊原文件 + 记录归档日志
一个关键细节：飞书群聊文件和云空间是两套独立的存储系统。不能直接"移动"，必须先下载到本地，再上传。这一点飞书文档里不会直接告诉你。是我试出来的。
用其他协作工具？限制可能不同。但"两个系统之间能不能直接传输"，是动手之前必须验证的第一件事。
4、踩过的坑
方案设计再完美，跑起来一定会出问题。以下是我踩过的4个坑，按"被坑的程度"排序。
坑1：同一份文件被归档了5遍
这是最先暴露的问题，也是最容易被忽略的。
表现：云空间的目标文件夹里出现了"合同(1).pdf"、"合同(2).pdf"……一直到"合同(5).pdf"。
原因很简单。定时任务每3分钟跑一次，但归档完的文件还留在群聊里。下一次扫描，AI 又把它当"新文件"处理了。
解决思路分两层：
第一层是消息级去重——记录已经处理过的消息ID，扫描时跳过。
第二层是文件级去重——计算文件的哈希值（类似文件的"指纹"），上传前先比对，重复就跳过。
两层都做上之后，再加上归档成功后删除原文件，问题彻底消失。
教训：凡是有定时循环的自动化，设计阶段就要问一个问题——"这个东西会不会被重复处理？"
不是"可能会"，是"一定会"。
坑2：关键词匹配的优先级陷阱
这个坑比较隐蔽。
我有一个文件叫"债权确认表-XXX-XX公司.pdf"——对，我的真实场景是法律案件文档——它应该归到"审核材料"文件夹。但系统把它归到了"申报材料"。
为什么？因为"债权确认表"和"债权申报表"都包含"债权"两个字。系统匹配到"债权"就停了，先命中了"申报"的规则。
修复方法：关键词匹配必须按具体程度排优先级。越具体的词，越先匹配。
"债权确认表"比"债权"更具体，优先级应该更高。先匹配最长最具体的关键词，匹配不到再降级。
这不是编程问题。是分类逻辑的问题。即使你用的不是代码，而是飞书自带的自动化规则，优先级逻辑也一样。
坑3：大文件把任务拖超时了
定时任务有默认的执行时间限制。我的环境里是60秒。平时几百KB的文件没问题，但10MB以上的扫描件一来，下载加上传就超时了。任务直接报错。
解决方案很直接：超时限制调到5分钟。
更优的做法：大文件单独排队，后台异步处理，不卡主流程。
这个坑的本质是：默认配置 ≠ 适合你的配置。工具给你一个默认值，你以为够了。大概率只是测试阶段碰巧够了。正式跑之前，拿你业务中最大的那个文件测一遍。
坑4：定时任务的投递地址写错了
这是最低级但花了我最多时间排查的问题。
任务状态显示"执行成功"，但归档就是没发生。我检查了分类规则、文件名格式、权限配置——全没问题。
最后发现：任务配置里的"投递目标"是一个旧群的ID。任务确实执行了。但消息发到了一个没人看的群里。
排查自动化问题的第一步，不是检查逻辑，而是检查"消息到底有没有到达正确的位置"。先确认数据流是通的，再看逻辑对不对。
5、不是工具问题，是"你怎么想"的问题
回头看，真正花时间的不是配置工具。是想清楚三件事：
第一，问题的结构是什么。群聊文件的混乱不是一个问题，是四层问题叠加。不拆清楚，就不知道自动化该覆盖哪些层。
第二，每个环节的决策依据是什么。定时扫描还是实时响应？文件夹按项目分还是按类型分？归档后删不删原件？每个决策背后都是一次取舍。取舍的标准只有一个：你的实际场景需要什么。
第三，失败会发生在哪里。重复归档、优先级错误、超时、地址错误。这些不是"意外"，是你没预设"出错了怎么办"这一层。
跑通的那天晚上，我看着云空间里按项目、按类型码得整整齐齐的文件夹，有一瞬间的恍惚。
群聊文件自动归档。说出来一句话的事。
但如果让人手动做，每天要花多少时间？如果以前想写代码实现，一个不会编程的律师要跨过多高的门槛？
现在，一个Agent，跑通了。
这大概就是工具变革真正的意义。不是让简单的事更快，而是让"以前根本做不到的事"变成"想清楚就能做到"。
工具会迭代。飞书的API会变，AI Agent的能力会进化。但"拆解问题结构 → 设计分类规则 → 预判失败模式"这个思考链路不会过时。
· END ·
看懂规则，拆解复杂
⬇
