介绍
公司举办了一项运动打卡活动，报名成员每天完成运动后，会把运动 App 截图和相关说明发到运动聊天群。工作人员需要定期整理群里的打卡记录，统计每位成员的运动时间和运动时长。
随着群聊资料不断增加，人工逐张查看截图、判断有效记录和抄录数据会花费不少时间。如何减少这些重复工作，快速得到可以统计的运动打卡数据，就是这次要解决的问题。
为此，我做了一套运动打卡数据处理流程。它会下载群聊归档，识别截图和上下文，整理成结构化数据，再把异常记录交给人工核查。最近我又用 TRAE Work 在 sportcheckin 工程中完整跑了一遍这套流程，确认 Agent 可以完成资料下载、内容识别和数据输出。
主要痛点
原来的做法是人工逐张看图。管理员需要一张张图片，再判断图片是不是运动记录，抄下运动时间和时长，最后汇总统计。难点不在单张截图，而在这些细节会叠在一起。
- 不同运动 App 的版式不同，人眼识别有概率出错
- 运动时间和发送到群里的提交时间可能不同需要人工甄别
- 群里有补交、重复图、排行榜和普通聊天内容需要人工甄别
- 如果还想统计运动类型、卡路里，人工录入的工作量会继续上涨
要解决的问题
我需要做的事情是把每天群里哪些繁杂的聊天记录整理为一个结构化、可追溯的数据表，我的同事已经开发了工具，可以每天定时把聊天内容图文上传内部云盘，我只要通过API下载文件，并输出分析后的干净数据即可。
我要拿到的不只是一张总表。每条记录要保留各种运动信息、原图地址、人工核查状态。最后输出 CSV格式的文件、识别报告和待人工复核清单。一开始我以为只要做个工具获取聊天记录docx 丢给 AI，让它直接输出表格就行。结果跑起来才发现，图片多时速度慢，中间哪里错了也不好找，后面人工复核更没法追溯。
所以调整了工作流程，给 TRAE Work 下发任务前，没有写成一句"帮我整理运动记录"，而是先把我具体的需求，输入、输出和异常规则说清楚。
markdown
请处理指定日期范围内的运动群归档文件。
任务要求
1. 通过API下载并整理 docx 中的文字、图片、发送人和发送时间
2. 识别有效运动打卡，忽略闲聊、排行榜和无关图片
3. 输出运动时间、提交时间、人员、运动类型、运动时长、卡路里、原图路径和核查状态
4. 对重复记录、时间不完整、字段冲突和低置信内容标记为待核查
5. 输出 records.csv 与 evidence.md
处理原则
- 不确定时不要猜测，不要写入正式数据
- 每条记录必须保留可回看的原图或来源位置
- 运动时间和提交时间分开保存核心思路
这个流程最核心的工作，就是识别出聊天内容中的运动记录。
我之前用同一份含 13 张图片的 docx 做过测试。全量视觉识别加大模型理解，识别效果很好，但耗时约 30 分钟，测试成本约 1.63 美元。改成 OCR 先读取文字，再交给大模型整理，同一份资料约 2 分钟，成本约 0.42 美元，不过出现了两处数据错误 。
对比之下，全部使用AI大模型视觉识别通过率高（但不代表正确率100%），但费用高不可持续；使用OCR识别成本低，但通过率没那么高。事实上做数据的整理如果单纯只做图片识别还是非常容易把数据搞错，因为活动成员做打卡时有可能发送重复app截图，或者直发现场照片加文字描述，并不会有app截图。
后来我把处理流程再收紧了一步。OCR 负责识别文字、数字。AI 负责理解字段含义和聊天上下文。OCR 缺字、错位、冲突或置信不足时，Agent 先写入待复核清单。人工确认需要补看原图后，才启用大模型视觉识别做二次修订。
这套分工解决了两个问题。大部分规则化截图不必都走昂贵的视觉理解，复杂图片也不会因为 OCR 读错一个数字就直接写进结果。
比如一张截图里 OCR 已经读出"跑步 46 分钟、326 千卡"，AI 可以结合图片版式和同一条消息的上下文，判断哪一个是运动时间，哪一个只是提交时间。若 OCR 把 8:36 读成了不完整的时间，或卡路里字段没有读出，Agent 会把这一行标成待核查。人工确认需要处理后，才让视觉识别回看原图补齐字段。
具体操作步骤
第一步 让 TRAE Work 下载资料、识别数据并生成 CSV
我先在 TRAE Work 中打开 sportcheckin 工程，用自然语言告诉 Agent 要处理的日期范围。Agent 会按指令下载对应的群聊记录，读取聊天文本和运动截图，再结合提交人的上下文整理运动数据。
处理完成后，Agent 会生成 records.csv，同时输出识别摘要、来源信息和过滤诊断。CSV 是后续入库和统计的统一输入，每一行仍然能够追溯到原始聊天记录与截图。
第二步 导入数据库并完成人工核查
生成 CSV 后，我把数据导入 sportcheckin 的数据管理系统，这个小小的系统也是vibe coding生成的。系统支持把已核查记录和待核查记录分开，管理员只需要集中处理缺失、冲突和低置信度的数据，不必重新翻完整的群聊记录。
核查页面会把原图、识别字段和异常原因放在一起。管理员可以对照截图修改运动时间、时长、人员等字段，再确认核查结果，如果有问题可以马上修改。当然如果下载数据和核查数据是同个人，我会建议优先在上一步，下载数据阶段就直接核查了。
第三步 展示统计结果
完成核查后，系统基于数据库中的有效记录生成报表。页面可以查看总体打卡情况，也可以按人员筛选，并通过排行榜快速了解参与情况。后续新增的数据只要经过同一套入库和核查流程，报表就能继续更新。
第四步 通过智能问数继续分析
拿到治理并经过人工确认的数据后，就可以继续做智能问数。问数的入口并不固定。可以把数据库的只读 API、调用方式和字段说明提供给 TREA WORK等agent，让agent按问题获取数据，直接在 对话中完成查询和汇总、提供运动建议。也可以把相同的能力接入钉钉机器人，再把机器人放进运动群。群成员直接提问，就能查看个人运动信息、运动趋势分析。
TREA Work上问数
钉钉群里问数
成效如何
目前为止已经创建了1210 条运动记录，累计运动 65588 分钟，约 1093.1 小时。使用这套流程以前，负责这项工作同事需要逐张查看运动截图，再手工填写和汇总表格，每周统计一次大约需要 60 分钟。
现在由 Agent 先下载资料、识别截图并整理 CSV，人工只处理异常记录和最终核查，每周大约需要 10 到 20 分钟，耗时下降比例|约 67% 到 83%。说实话这个流程也不是一蹴而就的，开发初期也是遇到各种规则意外的问题，导致识别异常，感谢我的同事陪我跑了好几轮的迭代才发识别通过率慢慢提升到了接近100%。
如何复用
运动打卡只是一个输入比较杂的例子，关键方法可以迁移到其他"图片多、规则明确、又需要留痕"的工作。
- 财务整理发票图片，读取号码、日期、金额和税额，再交给财务确认
- 行政整理巡检照片，提取地点、时间和异常描述
- 项目组处理物流回单或合同扫描件，先形成结构化台账
- 运营团队归档报名表和聊天记录，先把重复、缺失和冲突标出来
这些场景都不适合把 AI 当成自动盖章工具。更稳的做法，是让它先做文件整理、文字读取、字段抽取和异常标记，人把精力放在少量需要判断的地方。
总结
这次实践让我更清楚地看到，AI 能不能进入真实工作，首先取决于人是否理解业务。哪些记录可以采用，哪些数据必须核查，出现缺失和冲突时怎样处理，这些规则需要人来确定。规则说清楚以后，AI 才能稳定地接手下载、识别、整理和统计这些重复工作。
TRAE Work 给我留下较深印象的地方，是它没有把工作停在一段建议或一份示例代码上。它可以进入已有工程，读取项目约定，调用现成工具，再把处理结果写回文件。整个过程中它确实是个实干助手，我负责说明业务目标、检查结果和修正规则，它负责把中间那些具体而繁琐的步骤跑完。
运动打卡只是一个很小的场景，却包含了许多真实业务都会遇到的问题。原始资料分散，图片版式不一，识别结果可能出错，最终数据还要能够追溯。把这些问题处理好以后，统计报表和智能问数才能建立在可信的数据上。