我雇了3个人抄PDF,AI一天就把活干完了

# 我雇了3个人抄PDF，AI一天就把活干完了

19份PDF，24列字段，9个上架渠道。

先说结论：AI帮你省的不是"识别有多准"，而是雇人录入的工资和抄错之后赔的钱。

先看项目

这不是一个“给员工配个AI助手”的项目，而是把一条真实业务链路重做了一遍。

下面这张图来自真实通知。品牌和抬头已经裁掉，只保留产品明细表。

图片型PDF中的产品明细表

这不是OCR问题，是业务口径没固化

一开始很容易把它理解成识别问题。找更强的模型，把图片读出来，不就完了？

真做进去才发现，模型只是其中一段。更难的是，读出来的内容要放在哪一列，哪些字段必须统一，哪些异常必须拦住。

最后定下来的上架主表有24列。

上架渠道固定为9项：门店POS、美团团购、美团外卖、抖音直播、微商城、社群、微信小店、视频号、快团团。

AI到底接在哪一段

AI只接一段的生产链分工

这个项目没有让AI直接“接管运营”，只让它进入一条有边界的生产链。

系统先用PDF渲染把每页变成图片，再让视觉模型只处理“产品明细表”那一页。这样做的代价是多一步人工判断，好处是不会把整份通知里的广告话术、陈列标准和生产BOM一起吞进去。

真正让项目返工的是4个业务坑

这部分比“模型多聪明”重要得多。

第一版最危险的地方，不是少读了字段，而是把“看起来像数据”的内容写进了系统。

比如现烤类PDF里常有产品工艺标准。人一看就知道那是BOM，AI看到“产品名称、规格、用量”，很容易把它当商品明细。

所以后来加了一条硬规则：服务场景、销售话术、陈列标准、入机说明、BOM、工艺标准，全部不进上架主表，只放进“其他表格”备查。

第二个坑更隐蔽

有一份通知写的是“11店分批”。系统第一版把“11店”识别成了通用门店范围，结果展开成数据库里的全部门店。

修复后，系统先看门店范围，再去正文的“上市门店1、上市门店2”章节提取具体名单。最终准确命中11家门店。

第三个坑差点吞掉3个SKU

有一份PDF包含3款麻薯布丁，但原文件没有提供单品SKU，提取结果只好写成短横线占位。

第一版用“文号+SKU+渠道”判重。三行都是短横线占位，系统就认为它们是同一条，最后只保存了1款，另外2款被跳过。

修复方式是把占位SKU归一成空值，改用“文号+产品名称”判断不同商品。

第二次导入时，3款全部进入系统；再次导入同一批数据时，3款又全部被正确拦截。

结果怎么证明

这个项目没有做正式工时测量，所以我不写“节省了多少分钟”或“效率提升百分之多少”。这里只列能核对的交付数字。

系统截图如下。这里展示的是上架填报、门店和渠道标签，以及商品类型化详情。

上架信息填报系统

小团队能抄的4条

• 先定你要什么结果，再选工具。你关心的不是"模型多聪明"，而是"录入能不能不出错"。

• AI帮你省的是重复录入的时间，不是替你做业务判断。该确认的还是要人确认。

• 把渠道拆开。一个渠道出错只改一个渠道，不用整批返工。

• 让系统先拦错误，再让人确认。而不是让人从头抄一遍再检查一遍。

这套东西听着不炫，但它能被验收。

普通AI帮你写了一篇文章。好的AI落地帮你省掉一个人每天重复做的事。

边界也要说清楚

这个项目不是“PDF一上传就全自动”。图片型表格仍然需要视觉读取，门店和渠道仍然需要人工确认，原文件没有的SKU和保质期只能标为缺失。

它没有解决所有业务问题。它解决的是"你的运营每天在做的最耗时间、最容易抄错"的那一小段。

小团队AI落地最现实的样子，不是多一个聊天框，而是把你雇人做的那件重复事，改成机器做、人确认。

你团队里最想先改造的，是找资料、录数据，还是跨系统搬数据？