生产数字化与自主应用
把工厂的经验，变成自己的数字化能力
我从饮料生产的工艺和设备进入现场，梳理数字化需求与建设边界，把 PLC、数据交换、共用数据、MES 和 AI 应用放在同一条路径里。设备与专业系统继续保证可靠运行，企业则逐步掌握数据、规则和应用迭代，让现场经验更快进入下一次改进。
古茗 · 2026 至今
我负责生产场景与工艺研究、数字化需求和数据接口梳理、技术协作边界设计，并开发供应商知识产品、规划 AI 应用路径。
一次现场改进，为什么要等一次软件项目？
改一个字段、增加一张报表、把一个经验判断放进系统，原本都可能需要重新沟通需求、等待排期并支付开发成本。现场积累得越深，值得优化的事情越多；如果每一个想法都要经过这条长链路，业务经验就很难及时变成生产力。
我希望改变的是企业与系统的关系：设备和专业系统继续提供可靠的基础，企业自己能够理解数据、定义业务规则，并持续开发适合现场的应用。真实问题由此成为产品的输入，懂工艺、懂生产的人也成为共同设计系统的人。
因此，我把关注点从“买到哪些模块”推进到“怎样形成自己的迭代能力”：哪些数据需要在设备采购时就明确，哪些规则来自现场，哪些能力适合直接采用成熟方案，哪些应用值得由我们持续打磨。
系统要理解的，是一批产品怎样真正做出来
我沿着酿造、过滤、清洗、无菌处理、灌装与包装去理解现场，并在工艺和设备讨论中追问：这一段能提供什么参数？谁用这些信息作判断？这里的波动会怎样影响下一个环节？只有把数据放回生产过程，才能知道采什么、为什么采，以及采到之后能做什么。
上游酿造围绕批次和工艺过程运转，下游包装还要面对产品规格、包装形式与换产。两端需要关联，也需要保留各自的业务节奏。生产管理由此牵涉过程执行、物料、质量、设备和能源；排产只是其中一个入口。
过程数据与检验结果，需要回到同一批产品
设备状态、流量或温度提供过程线索，实验室检验提供另一类质量证据。我在需求梳理中把批次、工序、设备、采集时间与检验结果作为需要关联的对象，让后续应用有条件回答“发生了什么、影响哪一批、还需要谁来判断”。
一台设备的改善，要放回整条产线来看
单机效率提高之后，上下游是否接得住？一次换产或清洗，怎样影响后面的连续生产？我把跨工序的关联纳入研究与讨论，让局部指标能够与产线节奏、质量和交付一起被理解。
底层可靠运行，上层能够持续生长
我将设备、自动化和软件方案放在同一张能力地图上讨论。分层的意义，是明确每一层输入什么、输出什么、谁负责，以及未来增加应用时，需要重新动哪些部分。
在这条路径中，我重点推进业务需求、数据定义与应用之间的连接，同时吸收设备和自动化伙伴在现场接入、稳定运行与集成上的经验。直接采用、共同配置和自主开发可以结合使用；判断依据是业务适配、长期可维护性，以及企业能否掌握下一次变化。
现场设备与控制：可靠地完成生产
设备与 PLC（可编程控制器）承担现场控制。围绕工艺明确仪表、可用参数和接口要求，把未来的数据需求前置到设备选型与技术交流。
数据采集与交换：让数据带着含义上来
明确来源、单位、采集时间、设备状态和传输关系，区分哪些信号已有、哪些需要补充；与专业伙伴共同梳理接入及系统边界。
共用数据与 AI：把信号组织成业务对象
将设备信号与批次、物料、工艺、生产记录及检验结果关联。AI 分析由此能够结合业务背景，沿着具体对象追问原因。
业务应用：把判断变成人们用得起来的产品
围绕 MES（制造执行系统）、质量追溯、设备能源和生产洞察设计应用；与已有经营、仓储等系统衔接，让新需求可以持续进入产品迭代。
AI 的价值，要从现场真正关心的问题长出来
AI 可以提供行业知识，现场人员却知道这条线在哪些条件下会出问题，以及哪些变化值得追。我的切入方式，是先与业务一起选一个有价值的问题，再梳理需要的数据、经验规则和后续动作，把人的判断组织成应用能够使用的上下文。
例如单位产量能耗的变化，看起来是一个指标，背后可能混着运行负荷、启停、清洗、产品切换和统计口径。一个好用的产品应该帮助使用者逐步缩小问题，找到需要核实的现场环节，并把确认后的经验留给下一次判断。
我用这样的场景推演，把现场经验、数据需求与应用交互连起来。
| 业务要弄清什么 | 系统需要关联什么 | 人接下来怎样使用 |
|---|---|---|
| 这次变化是否值得比较 | 产量与能源统计时段、产品、批次和运行状态 | 先确认比较条件，找到真正异常的生产时段 |
| 变化可能发生在哪一段 | 设备状态、启停与清洗记录、前后工序及现场经验 | 沿着线索回到现场，由熟悉工艺的人核实原因 |
| 这次判断怎样帮助下一次 | 确认后的原因、处理动作与适用条件 | 沉淀成可追溯的规则和案例，持续修正分析与提示 |
我想建立的是业务与开发之间的短循环。每解决一个具体问题，数据关联、业务规则和产品交互都能积累下来，继续支持下一次改进。
应用设计场景推演找供应商，也是在建立自己的生产知识
供应商交流是我进入现场业务的重要入口。我把原料、工艺、设备、质量和数字化方案放回生产链路，整理成研究材料、沟通问题和结构化简报。比较一家公司的能力时，先问它解决哪一段问题、需要什么前提，以及如何与整条链路配合。
我开发的供应商协作库，把企业能力、产品领域、资料、交流历史与需求跟进组织起来，支持手机现场查找和记录，也让团队能够接着上一次交流继续工作。它沉淀的是持续协作需要的上下文。
在此基础上，我把知识组织的方向继续推向工艺节点：从一个生产环节找到参数、标准、设备与候选伙伴，再把交流所得带回需求定义。这样，了解现场、组织资源和设计系统能够互相推动。
把一个工厂的问题，变成可以持续复用的能力
这项工作的价值，同时发生在业务和技术两端。业务端把经验、约束与改进机会说清楚；技术端把它们转成数据对象、规则和应用。我的位置就在两者之间：带着开发能力理解生产，再带着生产问题组织数据、产品与外部协作。
我将工艺研究、方案讨论、现场问题与供应商信息组织成相互关联的材料和工具，推动“提出需求—明确数据—设计应用”的讨论能够接续起来。企业对系统的要求，也从一次采购中的功能清单，走向长期掌握数据和迭代能力。
面向伙伴公司与更多工厂，我希望复用的是这套积累方法：共同的数据对象、经过场景打磨的规则、可组合的应用，以及持续吸收现场经验的机制。不同工厂保留自己的工艺与管理特点，已经解决的问题则有机会成为下一家工厂更好的起点。