如果你工作中也在大量使用飞书群，或者有过在多个群里整理消息的经历，应该很熟悉这种画面：
一天没怎么看群。
晚上再打开，已经是几百条消息。
里面有咨询、有报障、有截图、有回复，也有很多寒暄和无关内容。
真正麻烦的不是“看完”。
而是把真正需要跟进的问题挑出来，再把问题、回复、截图和处理状态整理清楚。
以前这类工作，基本靠人工“爬楼梯”。
从头看到尾。
遇到像问题的内容，就复制出来。
看到截图，要判断它和哪条问题有关。
看到后续回复，还要往前翻，找到它对应的是哪一条问题。
一轮下来，很容易花掉半天，甚至接近一天。
这一次，我换了一个做法。
我让 Codex 通过飞书 CLI 读取群消息，把群里的问题整理进多维表格，再把当天核心内容生成飞书文档。
最后，把这套流程做成自动化任务。
首次跑通时，从读取消息到生成问题表和报告，大约用了 40 多分钟。
后续通过自动化追加每天的群内消息及出报告，10分钟内全部搞定。
一、真正要解决的不是总结，而是漏看问题
群消息汇总看起来像写总结。
但我更关心的是：
不要漏掉真正需要处理的事情。
比如有人发截图说流程没跑起来。
有人问登录系统报错。
有人补充“还没有回写成功”。
也有人几个小时后才给出处理建议。
这些内容分散在群里，人工整理最容易出四类问题：
问题看到了，后续回复没合并进去。 回复看到了，却不知道对应哪条问题。 截图保存了，但没写清楚图里说明了什么。 今天整理过，明天还要重新翻。
所以我给 Codex 的目标很明确：
不是简单总结群聊，而是把“事项类问题”变成可以持续维护的记录。
二、先让 Codex 读取完整群消息
我没有让它靠页面截图识别，也没有手动复制聊天记录。
为了验证可行性，我先让 Codex 调用飞书 CLI，以我的用户身份读取一个测试飞书群的消息。
读取前，它先校验授权。
确认本地 CLI 可以正常访问飞书，再继续拉取消息。
这里有一个关键点：
必须完整分页读取。
群消息不是第一页就结束。
如果只读几十条，后面的内容就会漏掉。
所以我要求 Codex 拉取全部消息，并保留：
话题回复； 图片和文件； 消息 ID； 发送时间； 发送人； 原始消息链接。
这样后面每一条整理结果，都可以追溯回原始消息。
这一步很关键。
因为后面无论是写入多维表格，还是生成群消息报告，都不能只靠一段“看起来差不多”的摘要。
它必须能回到原始消息。
这样结果才可查、可追溯、可复核。
三、把问题写进飞书多维表格
消息拿到以后，Codex 不是把所有内容都塞进表格。
它先筛选。
最近我们公司的系统出现了一些问题，各分子公司的人员在飞书群里集中报障。
这类群消息有一个特点：
真正有价值的信息，经常夹在大量对话中间。
所以我给 Codex 的规则是：
只记录需要跟进的咨询、报障、确认和请求。
闲聊、感谢和无关讨论，不写入问题表。
筛选完成后，再整理成结构化字段：
问题摘要； 当前状态； 提问时间； 提问人； 问题原文和消息链接； 问题截图附件； 回复摘要； 回复时间； 回复人； 回复原文和消息链接； 上下文备注。
这样一来，群消息就不再是一堆散乱聊天记录。
而是一张可以筛选、追踪和复盘的问题记录表。
提示词大意如下：
帮我通过飞书 CLI 读取"XX"飞书群的群消息，完整分页拉取"XX"时间范围内的消息。 不要只做简单总结，而是把群里的“各类咨询和保障的问题”整理成可持续维护的记录：
识别需要跟进的咨询、报障、确认、请求； 过滤闲聊、感谢和无关讨论； 保留消息 ID、发送时间、发送人、原始消息链接； 关联话题回复、图片、文件和截图附件； 把识别出的事项类问题写入飞书多维表格； 再生成一份飞书文档报告，汇总统计、主要问题和处理情况； 完成后回读校验，确认表格记录、附件和文档内容真实存在，并报告处理数量、失败>数量和链接。
为了避免重复写入，我还让 Codex 用“问题消息 ID”作为唯一键。
如果同一个问题之前已经记录过，就不再新建一行。
如果后来出现新回复，就把回复补充到原来的记录里。
这样每天运行，也不会把历史问题重复刷一遍。
这也是我觉得这套流程比普通“AI 总结群聊”更有价值的地方。
今天的问题，明天有了新回复，可以继续补充。
后面要复盘，也可以直接从表格里筛选和追踪。
四、再生成一份能看的群报告
多维表格解决的是“问题记录”。
但每天还需要一份更适合阅读的报告。
所以我又让 Codex 把当天群里的主要内容整理成飞书文档。
报告里包括：
当天沟通数量； 主要问题； 关键回复； 处理状态； 待跟进事项； 原消息链接； 问题记录表链接。
这类报告的价值，是让人不用重新翻群。
打开文档，就能知道今天群里发生了什么。
哪些问题已回复。
哪些问题还需要继续跟进。
哪些内容需要回到原消息查看。
需要追溯时，再点回原消息链接。
对我来说，多维表格像是一张“问题台账”。
飞书文档更像是一份“每日简报”。
一个适合长期维护。
一个适合快速阅读。
这两个结果放在一起，群消息整理才真正变成了一个可用的工作流。
五、最后做自动化任务
手动跑一次，只能解决一次问题。
真正有价值的是让它每天自己跑。
流程跑通后，我把它设置成了自动化任务。
首先是在工作日固定时间更新问题记录表。
它会从上次成功检查点继续读取消息，同时向前重叠一段时间，避免漏掉跨天回复。
写入前，先检查已有问题消息 ID。
只新增，不重复。
然后创建当天群内容的汇总报告给我报告。
提示词如下：
也帮忙做一个自动化任务,每个工作日17:30汇总新增当天群内的消息，并追加到多维表格>记录表:"区部资讯事项沟通群问题记录表-260616",并创建当天的群内容的汇总报告给我，然后通过飞书发送报告链接给我。
到这里，流程就变成了：
群里有人提问，Codex 定时读取消息，把问题和回复写入多维表格，再把当天核心内容写成飞书文档，最后把报告链接发回来。
我只需要看结果，必要时再做人工判断。
这和以前人工翻群相比，最大的变化不是“少看了几百条消息”。
而是流程变清楚了。
什么算问题。
什么算回复。
哪些内容要写进表格。
哪些内容要放进日报。
哪些内容要保留原始链接。
这些规则一旦固定下来，后面就可以不断重复执行。
写在最后
这次实践给我的感受是：
办公中的AI使用，不只是让它帮你写几段总结。
更重要的是，让它进入真实工作流程。
以前我们说“整理群消息”，背后其实有一整套规则：
什么算问题？
什么算回复？
截图要不要保存？
重复问题怎么处理？
跨天回复怎么补充？
报告应该给谁看？
这些规则说清楚以后，Codex 就不只是聊天助手。
它可以调用工具、读取系统、写入表格、生成文档，并定时运行。
我越来越觉得，未来很多办公室里的重复工作，不会一下子被某个大型系统替代。
它们更可能先从一个个具体流程开始改变。
比如每天整理群消息。
比如每周汇总会议纪要。
比如定期检查多维表格数据。
人负责定义目标、规则和验收标准。
Codex 负责执行、检查和持续更新。
如果你也有类似的群消息、会议纪要或文档读取工作，可以先拿其中一个重复性工作最多的场景开始验证。
这就是我这次用 Codex 接管飞书群消息整理的全过程。
