干了这么多年库存管理最让人头疼的还真不是搬货而是月底那几天对着几十张乱糟糟的盘点记录发呆一条一条手工录入电子表格。明明都是中文字写什么的都有——“螺丝100个”、“螺丝 一包”、“螺丝1盒”能出现在同一页上规格型号还时不时缺胳膊少腿。这个月我终于把这事儿彻底解决了用运行在本地电脑上的AI模型直接把乱七八糟的盘点原始记录自动变成规范的Excel表格全程数据不离开本机平均处理300条数据只用十几分钟。这篇就把完整的实操思路、环境搭建、核心代码和踩过的坑都写出来给还在靠人工对表的同行一个参考。这内容适合所有被库存表格折磨过的人仓库管理员、门店运营、小企业主甚至学校里做实验耗材管理的老师。你不需要懂什么高深的算法会装软件、会复制粘贴代码就行。整个过程分三步走先把本地AI模型跑起来再写一套指令模板把非结构化文本转成结构化数据最后用Python自动生成Excel。下面从为什么选本地化方案开始讲每一步我都会说清楚“为什么这么做”而不是光给结论。1. 为什么是“本地化”方案而不是直接在线问答1.1 盘点数据的隐私属性决定了不能上网处理库存数据这东西看起来就是一堆物品名称、数量、位置但实际上它能反推出很多东西进出货频率能看出销售淡旺季库存深度能倒推资金压力甚至某类物料的囤积量能推测出公司正在进行的生产计划。把这类数据贴到公共网络平台上去做AI转换等于把家底露给别人看。我之前试过一次在线工具把脱敏后的数据传上去确实方便但心里始终不踏实而且遇到网络波动整个流程就卡住了大半天白等。本地化方案的处理逻辑完全不同模型文件下载到自己的电脑上所有数据的读取、识别、转换都在内存和本地磁盘里完成没有一次网络请求。你关掉路由器也不影响处理速度。对于仓库这种每天都有敏感数据变动的场景这个特点本身就是最大的优势。当然本地模型对硬件有一定要求但8GB显存的显卡就能跑得动7B参数级别的量化模型实在没有独显纯CPU运行小尺寸模型也能接受只是速度慢一些。1.2 本地AI和在线AI的取舍以及为什么“够用就好”可能有人会问本地模型的能力会不会比在线大模型差很远确实纯粹的会话和逻辑能力肯定有差距但我们要做的任务非常聚焦把一行盘点文本拆出“名称、规格、单位、期初数量、盘盈盘亏”这几个字段。这个任务不需要多强的创造力只要模型具备基本的文本理解和格式化输出能力就够了。从实际测试来看主流的7B开源模型在这个场景上完全够用准确率能到95%以上剩余的少量错漏靠规则脚本就能兜底。如果选在线AI大模型单次调用还有限流和延迟问题数据量一大就要花钱买配额。本地模型跑起来之后调用次数完全没有限制哪怕一天处理一万条记录也只是多花一点电费。从成本和可控性角度考虑这不是一道选“更强”还是“更弱”的选择题而是在合适的场景里选最匹配的工具。2. 盘点数据乱在哪里AI到底在做什么2.1 盘点单上的“非结构化文本”到底是什么样拿实体仓库存盘单举例现场通常是纸笔记录或者微信语音转文字到了汇总阶段就变成各种画风清奇的文本。我整理了几条真实的现场记录做示例A区货架第三层 螺丝M6*30 大概2公斤吧 蓝色箱子里的 单价不知道 盘盈8包 找了一下 不锈钢板 1.5mm 有40片 卧槽怎么多了5片 铝合金窗把手 型号小号 黑色 库存对不上 差20个这种文本的特点是字的顺序是乱的、数量单位混用、位置信息和物品名称混在一起、盘盈盘亏直接用口语表达。如果靠人去一条条看再录表一百条记录至少要花三四个小时而且很容易看错行、录错数。AI模型解决这个问题的思路和人是一样的先读一整句理解哪些词在说物品、哪些词在说数量、哪些话是盘点人的随口评价然后按照预设的字段定义把信息提取出来填入“格子”。模型之所以能做到是因为它在训练阶段看过大量类似文本知道“盘盈8包”这种说法意味着实盘数比账面数多8包。2.2 结构化输出的目标格式提前想清楚才不至于返工在教AI做事情之前先得定义清楚最终表格长什么样。我设计的输出表包含这么几列字段名示例说明盘点区域A区货架第三层盘点单上标记的物理位置物品名称螺丝M6*30标准化后的名称规格尽量拆开规格型号M6*30单独成列便于后续筛选汇总单位包标准化单位把“袋““袋子”都统一成“包”账面数量20库存系统里的原数量实盘数量28现场清点的实际数量盈亏数量8实盘减账面正数盘盈、负数盘亏备注蓝色箱子里保留现场补充说明这样分列之后后续不管是用透视表汇总还是按规格查明细都会非常顺手。如果是手工录入光把“螺丝”、“M6*30”、“蓝色箱子里”拆成三列就会消耗大量力气而这恰恰是AI最擅长的事——它天然知道怎么把一段话里的信息点拆开并归位。2.3 AI生成表格和“一键模板工具”的本质区别有的小伙伴可能用过那种连Excel都不用装的在线表单工具上传文本选几个模板就能出结果。但固定模板只能处理长得差不多的输入一旦出现“卧槽怎么多了5片”这种情绪化表达模板就抓瞎了而且模板通常不具备语义理解能力它理解不了“多了5片”和“盘盈5”是一个意思。AI方案的弹性就在这里只要你在指令里说清楚“口语化表达要转成标准术语”模型自己就会做同义替换和逻辑换算。这也是我认为这个方向值得写一篇实操文章的原因——大家缺的并不是一个查字典式的工具而是一套能理解上下文的数据清洗流程。3. 环境准备三步搭好本地模型推理环境3.1 硬件配置建议与模型选型思路说说我这台机器的配置CPU是6核12线程的中端处理器内存32GB显卡是8GB显存平时主要用来写代码和跑一些轻量级渲染。这个配置跑一个7B参数的模型用INT8量化大概占6GB左右显存速度能到每秒生成二十来个字符处理一条盘点记录基本在几秒以内体感是可以接受的。如果你的机器没有独立显卡也不要马上放弃。纯CPU跑一个3B或4B的量化模型内存占用控制在8GB以内速度虽然慢一些但一次处理两三百条数据也能在半小时内跑完比手工录表还是快很多。个人建议是参数不超过7B优先选中文能力较强的开源模型量化版本优先选INT8而不是INT4因为量化的损失在抽取数字和单位时可能会放大误差。3.2 模型运行时框架的安装与基础配置现在跑本地模型最省事的方式是借助现成的推理框架不用自己去配CUDA和模型加载代码。我目前使用的是开源社区的本地推理工具安装命令很简单装完后拉取模型一条命令就能完成。# 安装推理框架以常见方式为例 curl -fsSL https://ollama.com/install.sh | sh # 拉取中文能力较好的模型7B参数INT8版本 ollama pull qwen2.5:7b-instruct-q8_0 # 启动服务并验证 ollama serve curl http://localhost:11434/api/generate -d {model:qwen2.5:7b-instruct-q8_0,prompt:你好}框架装好之后本地会启动一个API服务默认端口是11434。后续Python脚本只需要用HTTP请求把它当成一个后端服务来调就行。如果你平时也用Python做数据处理这一步做完就已经具备了把AI能力接进自动化脚本的基础。注意如果你是在公司内网环境可能需要自己下载模型文件后离线导入这一步要提前确认好网络策略避免装到一半被卡住。我当时就是因为公司网络限制只能在自己电脑上先跑通再拷贝模型文件到工作机。3.3 不写代码的配置方式用图形界面工具也很香如果你对命令行和环境变量比较陌生还有一条完全避开代码的路安装带图形界面的本地模型管理软件直接把模型文件下载到本地再通过桌面应用进行问答。这类工具能做到“选模型、下载、开聊”三步走底层同样是本地推理API接口也兼容后续写Python脚本不受影响。我在项目早期就是用这种图形工具先验证了模型效果确认它能准确理解“盘盈”“盘亏”“差20个”这些术语之后才动手写自动化脚本。建议你也按这个路径来先拿几十条真实数据人工测试模型输出质量再决定要不要跳到下一步编程避免一上来就陷入代码调试的泥潭。4. 核心实现让AI从原始记录到Excel表格的全流程4.1 设计“说人话”的提示词模板AI才听得懂本地模型不像在线大模型那么“聪明”它对指令的措辞更敏感所以提示词写得越具体、例子越充分输出就越稳定。我最终使用的提示词模板经过了四轮迭代核心结构是“角色定位 任务描述 字段定义 输出格式 示例”。下面是一段脱敏后的模板你现在是一个库存盘点数据整理助手。我需要你把一段口语化的盘点记录转换成结构化的JSON数据。 输出字段如下 - location盘点区域 - name物品名称去掉规格 - spec规格型号 - unit单位标准单位例如个、包、箱、件、片 - book_qty账面数量数字 - actual_qty实盘数量数字 - diff_qty盈亏数量整数正数为盘盈负数为盘亏 - remark备注信息例如存放位置、外观描述等 输入文本“A区货架第三层 螺丝M6*30 大概2公斤吧 蓝色箱子里的 单价不知道 盘盈8包” 输出JSON {location:A区货架第三层,name:螺丝,spec:M6*30,unit:包,book_qty:20,actual_qty:28,diff_qty:8,remark:蓝色箱子里约2公斤} 注意 1. 如果文本没有明确的账面数量可以依据上下文合理推算并在remark中注明“估算”。 2. 口语词汇“多了”“少了”“差”要换算成具体的盈亏数量。 3. 只输出JSON不要输出任何解释性文字。这段模板里最重要的其实是“示例”和“注意”。示例让模型明白了“大概2公斤吧”这种模糊描述要转写到备注里而不是当作规格注意里的“只输出JSON”能避免模型在输出里夹杂一堆解释方便脚本直接解析。我在第一批测试时发现如果不给示例模型经常把“M6*30”当作物品名的一部分而不是拆到spec字段加了示例之后错误率直线下降。一句话总结本地模型的提示词里示例比说教管用。4.2 Python脚本实现批量调用与数据落地模型服务跑起来之后剩下的就是用Python写一个批处理脚本。整个脚本分成三个模块读取原始记录、调用模型接口、解析结果并写入Excel。为了不重复造轮子我采用了requests发请求、pandas处理数据、openpyxl写入Excel的组合。import json import requests import pandas as pd from openpyxl import Workbook MODEL_NAME qwen2.5:7b-instruct-q8_0 API_URL http://localhost:11434/api/generate system_prompt 上面的完整提示词粘贴到这里 def parse_text_to_json(text): payload { model: MODEL_NAME, prompt: system_prompt \n输入文本 text, stream: False, temperature: 0, max_tokens: 200 } resp requests.post(API_URL, jsonpayload, timeout30) resp_data resp.json() output resp_data.get(response, ) # 清理模型可能输出的多余字符 if json in output: output output.split(json)[1].split()[0] output output.strip() try: return json.loads(output) except json.JSONDecodeError: return {error: output} records [] with open(raw_records.txt, r, encodingutf-8) as f: for line in f: line line.strip() if line: records.append(line) results [] for i, rec in enumerate(records): item parse_text_to_json(rec) if error in item: item {name: , spec: , unit: , book_qty: , actual_qty: , diff_qty: , remark: f解析失败: {item[error]}} item[原始记录] rec results.append(item) if (i 1) % 20 0: print(f已处理 {i 1}/{len(records)} 条) df pd.DataFrame(results) df.to_excel(盘点结果表.xlsx, indexFalse, engineopenpyxl) print(完成共处理, len(results), 条记录)这个脚本最需要注意的地方是temperature参数必须设为0。如果不设或者设置太高模型输出的数字会每次跑都不一样比如“实盘数量28”偶尔会蹦出来一个“30”这对于库存数据是不可接受的。设置成0之后模型在相同输入下的输出基本稳定虽然偶尔还有细微波动但在可接受范围内。另外如果某条记录真的解析失败脚本会把失败原文单独存下来并继续跑不会中断整个流程。处理完之后你只需要用Excel打开结果表人工复核一下少量标红或者失败的记录就行。4.3 数据校验与Excel格式化让表格直接能交差AI跑完之后直接交表还是不行的至少要做两道校验。第一道是数量校验算一下每条记录的diff_qty是否等于actual_qty - book_qty不一致的地方打上标记。第二道是单位校验把“包”、“袋”、“袋子”等等统一映射成标准单位这一步如果全靠AI偶尔会漏所以我用简单的规则表在脚本里做了一次兜底替换。为了让表格能直接发给领导看我还在脚本里做了一些格式化处理表头加粗、列宽自适应、盈亏数量用红绿颜色标注正数为绿、负数为红。这样一张表格落地之后既省了整理数据的时间也省了做格式的时间整体效率比之前手工操作提高了很多。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定JSON解析老是报错这应该是上手时最容易遇到的问题。现象是脚本跑着跑着突然挂掉或者生成的Excel里某一行的字段全是空值。排查思路分三步第一次出现时先单独打印出原始返回内容看看模型是输出了多余文字还是少了一个字段第二步检查提示词里的示例尽量让示例覆盖到文本中的表达模式第三步在脚本里加一个容错分支解析失败就跳过并记录不要中断整个批次。我还遇到过一个很奇怪的现象模型偶尔会在JSON前后加一段“好的我来帮你转换”这种话。后来我把解析逻辑改成先提取字符串中第一个{到最后一个}之间的内容再转JSON问题才彻底解决。5.2 本地模型第一次跑特别慢之后又变快了有些型号的显卡第一次加载模型时要做缓存预热速度会慢几十秒甚至几分钟这是正常现象。如果第二次跑还是慢重点查看是否CPU和GPU同时都在工作、后台是不是开了很多程序在抢资源。我在实际使用中的经验是用批处理方式一次性处理所有记录而不是一条一条调用脚本这样可以重复利用已加载的模型内存把平均每条耗时从十几秒降到两三秒。如果你是在没有独显的办公电脑上跑建议把一次处理的文本条数控制在100条以内分几次处理处理完一批保存一次结果避免长时间运行导致内存溢出或者系统卡死。5.3 名称识别不准同一物品出现多个名字“螺丝M630”、“不锈钢螺钉630”、“M6螺丝30mm”这三种写法在系统里其实是同一个东西。但AI在逐条转换的时候并不知道上下文可能会把它们输出成三条不同的记录。我的解决办法是在脚本后面加了一道归一化处理先按规格型号分组再对同规格下的名称做模糊匹配手动维护一张同义词映射表把“螺钉”“螺丝”“螺栓”等词统一成同一个标准词。这道工序之前靠人做现在则是AI做完了粗加工规则脚本做细加工配合起来既保留了AI的语义理解能力又保证了最终数据的唯一性。6. 最终效果与实际体验这套方案到底省了多少事6.1 数据对比AI处理 vs 手工录入我拿一个月度盘点的真实数据做了个对比测试总共326条原始记录。手工录入加核对我大概需要三个半小时而且中间还发现了两处由于疲劳导致的录入错误。用本地AI方案跑完从启动脚本到Excel生成耗时不到二十分钟之后我只需要花大概二十分钟人工复核异常的记录总体时间压缩到了之前的三分之一左右。准确率方面AI一次处理下来的可识别率在96%左右其中4%的失败主要来自特别混乱的手写体转文字记录例如“这个框里好像是那批急单的五金件”这种完全无法唯一对应到库存项的信息。这类记录我选择保留下文由人工补充。6.2 从短期“省事”到长期“数据资产化”这套方案更大的价值其实不在于一次节省多少时间而在于把原来分散在纸张和大脑里的信息变成了结构化、可分析的数据资产。以前月底盘完点仓库组长只能告诉你“大概齐”现在每个月都能拿出实实在在的盈亏趋势表哪些物料经常盘亏、哪些区域频繁出错一目了然。有一次我们通过分析连续三个月的盘亏数据发现某种规格的垫片总是在同一个货位少货最后查明是货架标签贴错了这个问题靠手工对表几乎不可能发现。6.3 后续可以扩展的方向如果你已经跑通了这个流程可以继续往几个方向加料。一是定期自动盘点提醒连接库存系统的导出功能每个月自动拉取账面数配合AI生成实盘检查单二是多仓库数据汇总分析和可视化看板三是把输出的JSON数据接入企业内部报表系统让盘点结果实时反映在管理看板上。我个人在实际操作中的体会是这套方案最核心的门槛不在技术而在“敢不敢把自己从繁琐重复劳动里解放出来”。刚开始我也担心AI处理数据会不会不靠谱后来跑了两个月数据、订正了若干次提示词之后现在每次盘点都变成了一件轻松活。最后再分享一个小技巧所有的历史数据不要覆盖保存按月归档好后面如果有新的模型版本或者更好的处理思路随时可以回放数据重新跑一遍效果会越来越好。 
长河君 · 2026/10/16 5:01:54 · 阅读 1.2k 本地AI自动整理库存盘点记录，一键生成规范Excel表格
干了这么多年库存管理最让人头疼的还真不是搬货而是月底那几天对着几十张乱糟糟的盘点记录发呆一条一条手工录入电子表格。明明都是中文字写什么的都有——“螺丝100个”、“螺丝 一包”、“螺丝1盒”能出现在同一页上规格型号还时不时缺胳膊少腿。这个月我终于把这事儿彻底解决了用运行在本地电脑上的AI模型直接把乱七八糟的盘点原始记录自动变成规范的Excel表格全程数据不离开本机平均处理300条数据只用十几分钟。这篇就把完整的实操思路、环境搭建、核心代码和踩过的坑都写出来给还在靠人工对表的同行一个参考。这内容适合所有被库存表格折磨过的人仓库管理员、门店运营、小企业主甚至学校里做实验耗材管理的老师。你不需要懂什么高深的算法会装软件、会复制粘贴代码就行。整个过程分三步走先把本地AI模型跑起来再写一套指令模板把非结构化文本转成结构化数据最后用Python自动生成Excel。下面从为什么选本地化方案开始讲每一步我都会说清楚“为什么这么做”而不是光给结论。1. 为什么是“本地化”方案而不是直接在线问答1.1 盘点数据的隐私属性决定了不能上网处理库存数据这东西看起来就是一堆物品名称、数量、位置但实际上它能反推出很多东西进出货频率能看出销售淡旺季库存深度能倒推资金压力甚至某类物料的囤积量能推测出公司正在进行的生产计划。把这类数据贴到公共网络平台上去做AI转换等于把家底露给别人看。我之前试过一次在线工具把脱敏后的数据传上去确实方便但心里始终不踏实而且遇到网络波动整个流程就卡住了大半天白等。本地化方案的处理逻辑完全不同模型文件下载到自己的电脑上所有数据的读取、识别、转换都在内存和本地磁盘里完成没有一次网络请求。你关掉路由器也不影响处理速度。对于仓库这种每天都有敏感数据变动的场景这个特点本身就是最大的优势。当然本地模型对硬件有一定要求但8GB显存的显卡就能跑得动7B参数级别的量化模型实在没有独显纯CPU运行小尺寸模型也能接受只是速度慢一些。1.2 本地AI和在线AI的取舍以及为什么“够用就好”可能有人会问本地模型的能力会不会比在线大模型差很远确实纯粹的会话和逻辑能力肯定有差距但我们要做的任务非常聚焦把一行盘点文本拆出“名称、规格、单位、期初数量、盘盈盘亏”这几个字段。这个任务不需要多强的创造力只要模型具备基本的文本理解和格式化输出能力就够了。从实际测试来看主流的7B开源模型在这个场景上完全够用准确率能到95%以上剩余的少量错漏靠规则脚本就能兜底。如果选在线AI大模型单次调用还有限流和延迟问题数据量一大就要花钱买配额。本地模型跑起来之后调用次数完全没有限制哪怕一天处理一万条记录也只是多花一点电费。从成本和可控性角度考虑这不是一道选“更强”还是“更弱”的选择题而是在合适的场景里选最匹配的工具。2. 盘点数据乱在哪里AI到底在做什么2.1 盘点单上的“非结构化文本”到底是什么样拿实体仓库存盘单举例现场通常是纸笔记录或者微信语音转文字到了汇总阶段就变成各种画风清奇的文本。我整理了几条真实的现场记录做示例A区货架第三层 螺丝M6*30 大概2公斤吧 蓝色箱子里的 单价不知道 盘盈8包 找了一下 不锈钢板 1.5mm 有40片 卧槽怎么多了5片 铝合金窗把手 型号小号 黑色 库存对不上 差20个这种文本的特点是字的顺序是乱的、数量单位混用、位置信息和物品名称混在一起、盘盈盘亏直接用口语表达。如果靠人去一条条看再录表一百条记录至少要花三四个小时而且很容易看错行、录错数。AI模型解决这个问题的思路和人是一样的先读一整句理解哪些词在说物品、哪些词在说数量、哪些话是盘点人的随口评价然后按照预设的字段定义把信息提取出来填入“格子”。模型之所以能做到是因为它在训练阶段看过大量类似文本知道“盘盈8包”这种说法意味着实盘数比账面数多8包。2.2 结构化输出的目标格式提前想清楚才不至于返工在教AI做事情之前先得定义清楚最终表格长什么样。我设计的输出表包含这么几列字段名示例说明盘点区域A区货架第三层盘点单上标记的物理位置物品名称螺丝M6*30标准化后的名称规格尽量拆开规格型号M6*30单独成列便于后续筛选汇总单位包标准化单位把“袋““袋子”都统一成“包”账面数量20库存系统里的原数量实盘数量28现场清点的实际数量盈亏数量8实盘减账面正数盘盈、负数盘亏备注蓝色箱子里保留现场补充说明这样分列之后后续不管是用透视表汇总还是按规格查明细都会非常顺手。如果是手工录入光把“螺丝”、“M6*30”、“蓝色箱子里”拆成三列就会消耗大量力气而这恰恰是AI最擅长的事——它天然知道怎么把一段话里的信息点拆开并归位。2.3 AI生成表格和“一键模板工具”的本质区别有的小伙伴可能用过那种连Excel都不用装的在线表单工具上传文本选几个模板就能出结果。但固定模板只能处理长得差不多的输入一旦出现“卧槽怎么多了5片”这种情绪化表达模板就抓瞎了而且模板通常不具备语义理解能力它理解不了“多了5片”和“盘盈5”是一个意思。AI方案的弹性就在这里只要你在指令里说清楚“口语化表达要转成标准术语”模型自己就会做同义替换和逻辑换算。这也是我认为这个方向值得写一篇实操文章的原因——大家缺的并不是一个查字典式的工具而是一套能理解上下文的数据清洗流程。3. 环境准备三步搭好本地模型推理环境3.1 硬件配置建议与模型选型思路说说我这台机器的配置CPU是6核12线程的中端处理器内存32GB显卡是8GB显存平时主要用来写代码和跑一些轻量级渲染。这个配置跑一个7B参数的模型用INT8量化大概占6GB左右显存速度能到每秒生成二十来个字符处理一条盘点记录基本在几秒以内体感是可以接受的。如果你的机器没有独立显卡也不要马上放弃。纯CPU跑一个3B或4B的量化模型内存占用控制在8GB以内速度虽然慢一些但一次处理两三百条数据也能在半小时内跑完比手工录表还是快很多。个人建议是参数不超过7B优先选中文能力较强的开源模型量化版本优先选INT8而不是INT4因为量化的损失在抽取数字和单位时可能会放大误差。3.2 模型运行时框架的安装与基础配置现在跑本地模型最省事的方式是借助现成的推理框架不用自己去配CUDA和模型加载代码。我目前使用的是开源社区的本地推理工具安装命令很简单装完后拉取模型一条命令就能完成。# 安装推理框架以常见方式为例 curl -fsSL https://ollama.com/install.sh | sh # 拉取中文能力较好的模型7B参数INT8版本 ollama pull qwen2.5:7b-instruct-q8_0 # 启动服务并验证 ollama serve curl http://localhost:11434/api/generate -d {model:qwen2.5:7b-instruct-q8_0,prompt:你好}框架装好之后本地会启动一个API服务默认端口是11434。后续Python脚本只需要用HTTP请求把它当成一个后端服务来调就行。如果你平时也用Python做数据处理这一步做完就已经具备了把AI能力接进自动化脚本的基础。注意如果你是在公司内网环境可能需要自己下载模型文件后离线导入这一步要提前确认好网络策略避免装到一半被卡住。我当时就是因为公司网络限制只能在自己电脑上先跑通再拷贝模型文件到工作机。3.3 不写代码的配置方式用图形界面工具也很香如果你对命令行和环境变量比较陌生还有一条完全避开代码的路安装带图形界面的本地模型管理软件直接把模型文件下载到本地再通过桌面应用进行问答。这类工具能做到“选模型、下载、开聊”三步走底层同样是本地推理API接口也兼容后续写Python脚本不受影响。我在项目早期就是用这种图形工具先验证了模型效果确认它能准确理解“盘盈”“盘亏”“差20个”这些术语之后才动手写自动化脚本。建议你也按这个路径来先拿几十条真实数据人工测试模型输出质量再决定要不要跳到下一步编程避免一上来就陷入代码调试的泥潭。4. 核心实现让AI从原始记录到Excel表格的全流程4.1 设计“说人话”的提示词模板AI才听得懂本地模型不像在线大模型那么“聪明”它对指令的措辞更敏感所以提示词写得越具体、例子越充分输出就越稳定。我最终使用的提示词模板经过了四轮迭代核心结构是“角色定位 任务描述 字段定义 输出格式 示例”。下面是一段脱敏后的模板你现在是一个库存盘点数据整理助手。我需要你把一段口语化的盘点记录转换成结构化的JSON数据。 输出字段如下 - location盘点区域 - name物品名称去掉规格 - spec规格型号 - unit单位标准单位例如个、包、箱、件、片 - book_qty账面数量数字 - actual_qty实盘数量数字 - diff_qty盈亏数量整数正数为盘盈负数为盘亏 - remark备注信息例如存放位置、外观描述等 输入文本“A区货架第三层 螺丝M6*30 大概2公斤吧 蓝色箱子里的 单价不知道 盘盈8包” 输出JSON {location:A区货架第三层,name:螺丝,spec:M6*30,unit:包,book_qty:20,actual_qty:28,diff_qty:8,remark:蓝色箱子里约2公斤} 注意 1. 如果文本没有明确的账面数量可以依据上下文合理推算并在remark中注明“估算”。 2. 口语词汇“多了”“少了”“差”要换算成具体的盈亏数量。 3. 只输出JSON不要输出任何解释性文字。这段模板里最重要的其实是“示例”和“注意”。示例让模型明白了“大概2公斤吧”这种模糊描述要转写到备注里而不是当作规格注意里的“只输出JSON”能避免模型在输出里夹杂一堆解释方便脚本直接解析。我在第一批测试时发现如果不给示例模型经常把“M6*30”当作物品名的一部分而不是拆到spec字段加了示例之后错误率直线下降。一句话总结本地模型的提示词里示例比说教管用。4.2 Python脚本实现批量调用与数据落地模型服务跑起来之后剩下的就是用Python写一个批处理脚本。整个脚本分成三个模块读取原始记录、调用模型接口、解析结果并写入Excel。为了不重复造轮子我采用了requests发请求、pandas处理数据、openpyxl写入Excel的组合。import json import requests import pandas as pd from openpyxl import Workbook MODEL_NAME qwen2.5:7b-instruct-q8_0 API_URL http://localhost:11434/api/generate system_prompt 上面的完整提示词粘贴到这里 def parse_text_to_json(text): payload { model: MODEL_NAME, prompt: system_prompt \n输入文本 text, stream: False, temperature: 0, max_tokens: 200 } resp requests.post(API_URL, jsonpayload, timeout30) resp_data resp.json() output resp_data.get(response, ) # 清理模型可能输出的多余字符 if json in output: output output.split(json)[1].split()[0] output output.strip() try: return json.loads(output) except json.JSONDecodeError: return {error: output} records [] with open(raw_records.txt, r, encodingutf-8) as f: for line in f: line line.strip() if line: records.append(line) results [] for i, rec in enumerate(records): item parse_text_to_json(rec) if error in item: item {name: , spec: , unit: , book_qty: , actual_qty: , diff_qty: , remark: f解析失败: {item[error]}} item[原始记录] rec results.append(item) if (i 1) % 20 0: print(f已处理 {i 1}/{len(records)} 条) df pd.DataFrame(results) df.to_excel(盘点结果表.xlsx, indexFalse, engineopenpyxl) print(完成共处理, len(results), 条记录)这个脚本最需要注意的地方是temperature参数必须设为0。如果不设或者设置太高模型输出的数字会每次跑都不一样比如“实盘数量28”偶尔会蹦出来一个“30”这对于库存数据是不可接受的。设置成0之后模型在相同输入下的输出基本稳定虽然偶尔还有细微波动但在可接受范围内。另外如果某条记录真的解析失败脚本会把失败原文单独存下来并继续跑不会中断整个流程。处理完之后你只需要用Excel打开结果表人工复核一下少量标红或者失败的记录就行。4.3 数据校验与Excel格式化让表格直接能交差AI跑完之后直接交表还是不行的至少要做两道校验。第一道是数量校验算一下每条记录的diff_qty是否等于actual_qty - book_qty不一致的地方打上标记。第二道是单位校验把“包”、“袋”、“袋子”等等统一映射成标准单位这一步如果全靠AI偶尔会漏所以我用简单的规则表在脚本里做了一次兜底替换。为了让表格能直接发给领导看我还在脚本里做了一些格式化处理表头加粗、列宽自适应、盈亏数量用红绿颜色标注正数为绿、负数为红。这样一张表格落地之后既省了整理数据的时间也省了做格式的时间整体效率比之前手工操作提高了很多。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定JSON解析老是报错这应该是上手时最容易遇到的问题。现象是脚本跑着跑着突然挂掉或者生成的Excel里某一行的字段全是空值。排查思路分三步第一次出现时先单独打印出原始返回内容看看模型是输出了多余文字还是少了一个字段第二步检查提示词里的示例尽量让示例覆盖到文本中的表达模式第三步在脚本里加一个容错分支解析失败就跳过并记录不要中断整个批次。我还遇到过一个很奇怪的现象模型偶尔会在JSON前后加一段“好的我来帮你转换”这种话。后来我把解析逻辑改成先提取字符串中第一个{到最后一个}之间的内容再转JSON问题才彻底解决。5.2 本地模型第一次跑特别慢之后又变快了有些型号的显卡第一次加载模型时要做缓存预热速度会慢几十秒甚至几分钟这是正常现象。如果第二次跑还是慢重点查看是否CPU和GPU同时都在工作、后台是不是开了很多程序在抢资源。我在实际使用中的经验是用批处理方式一次性处理所有记录而不是一条一条调用脚本这样可以重复利用已加载的模型内存把平均每条耗时从十几秒降到两三秒。如果你是在没有独显的办公电脑上跑建议把一次处理的文本条数控制在100条以内分几次处理处理完一批保存一次结果避免长时间运行导致内存溢出或者系统卡死。5.3 名称识别不准同一物品出现多个名字“螺丝M630”、“不锈钢螺钉630”、“M6螺丝30mm”这三种写法在系统里其实是同一个东西。但AI在逐条转换的时候并不知道上下文可能会把它们输出成三条不同的记录。我的解决办法是在脚本后面加了一道归一化处理先按规格型号分组再对同规格下的名称做模糊匹配手动维护一张同义词映射表把“螺钉”“螺丝”“螺栓”等词统一成同一个标准词。这道工序之前靠人做现在则是AI做完了粗加工规则脚本做细加工配合起来既保留了AI的语义理解能力又保证了最终数据的唯一性。6. 最终效果与实际体验这套方案到底省了多少事6.1 数据对比AI处理 vs 手工录入我拿一个月度盘点的真实数据做了个对比测试总共326条原始记录。手工录入加核对我大概需要三个半小时而且中间还发现了两处由于疲劳导致的录入错误。用本地AI方案跑完从启动脚本到Excel生成耗时不到二十分钟之后我只需要花大概二十分钟人工复核异常的记录总体时间压缩到了之前的三分之一左右。准确率方面AI一次处理下来的可识别率在96%左右其中4%的失败主要来自特别混乱的手写体转文字记录例如“这个框里好像是那批急单的五金件”这种完全无法唯一对应到库存项的信息。这类记录我选择保留下文由人工补充。6.2 从短期“省事”到长期“数据资产化”这套方案更大的价值其实不在于一次节省多少时间而在于把原来分散在纸张和大脑里的信息变成了结构化、可分析的数据资产。以前月底盘完点仓库组长只能告诉你“大概齐”现在每个月都能拿出实实在在的盈亏趋势表哪些物料经常盘亏、哪些区域频繁出错一目了然。有一次我们通过分析连续三个月的盘亏数据发现某种规格的垫片总是在同一个货位少货最后查明是货架标签贴错了这个问题靠手工对表几乎不可能发现。6.3 后续可以扩展的方向如果你已经跑通了这个流程可以继续往几个方向加料。一是定期自动盘点提醒连接库存系统的导出功能每个月自动拉取账面数配合AI生成实盘检查单二是多仓库数据汇总分析和可视化看板三是把输出的JSON数据接入企业内部报表系统让盘点结果实时反映在管理看板上。我个人在实际操作中的体会是这套方案最核心的门槛不在技术而在“敢不敢把自己从繁琐重复劳动里解放出来”。刚开始我也担心AI处理数据会不会不靠谱后来跑了两个月数据、订正了若干次提示词之后现在每次盘点都变成了一件轻松活。最后再分享一个小技巧所有的历史数据不要覆盖保存按月归档好后面如果有新的模型版本或者更好的处理思路随时可以回放数据重新跑一遍效果会越来越好。