现场原来怎么做
一两百名工人每天在微信群里报工，公司安排两名文员逐条统计、核对和汇总。报工本身已经发生了，问题在于后续整理每天都要重新做一遍。
公司没有先给我一个系统需求。是我在现场看到这个流程后，判断生产数据没有真正进入管理闭环，才提出把后面的拆分、清洗、复核和统计交给流程处理。
我没有先换掉微信
如果一开始就要求所有工人换入口、学新系统，推进成本会很高。我的取舍是保留微信报工，让一线继续按熟悉的方式操作。当前版本由操作人员在 Codex 中手动触发，后续拆分、清洗、复核和汇总再自动完成。
后台需要处理几件事：
- 识别并拆分群里的报工信息；
- 按产品、人员和日期整理；
- 把不确定或异常的内容留给人工确认；
- 按生产和财务需要的口径汇总。
这样做的重点不是“用了什么技术”，而是把改变尽量放在对一线干扰最小的位置。
真正难的是规则和配合
生产、财务和开发关注的东西不一样。生产要确认报工和异常规则，财务要确认统计口径，开发要知道输入长什么样、什么情况不能自动判断。
我分别和相关人员把规则问清，再把每一方要确认、要配合的事项说清楚。很多项目卡住，不是因为代码写不出来，而是问题没有被讲明白，或者没人持续追那些待确认项。
最后接到了哪里
系统先把日报打通，随后同一批数据继续用于：
- 机台产能；
- 每日异常；
- 财务所需统计。
这让生产、管理和财务能逐步按同一套口径看数据，而不是各自再做一遍。
这个案例没有写什么
我没有把它包装成“节省了多少人力”或“效率提升百分之多少”，因为没有一套足够完整、可公开核验的前后测量。两名文员原来承担统计工作，不等于系统上线后就替代了两个人。
这个案例能确认的价值，是发现了一条长期重复的流程，保留了工人熟悉的入口，协调生产、财务与开发把规则接起来，并让同一套数据口径继续延伸到日报、产能、异常和财务所需统计。
延伸阅读：没人提需求，不等于没有需求；如果你也有类似流程，可以先看合作方式。