智慧工厂 AI 数据问答工具

封闭的系统，是智慧工厂最大的敌人

在工业4.0的浪潮下，无数企业砸钱买最先进的MES系统、SCADA平台、数据中台。但讽刺的是，设备数据越多，运维人员反而越难用到这些数据。

原因很简单：数据在数据库里，但数据库不是谁都能读的。

一个真实的场景：凌晨两点，生产线突然停机。运维工程师老张想起昨天有台设备报过F001故障，想查查这是什么问题、谁负责维修。结果他需要——找到IT部门、说明查询需求、等待排期、拿到SQL结果、再翻译成自己能看懂的话。

这不是技术问题，这是认知税。每一个"专业系统"都在提高使用数据的门槛，而不是降低它。

三个问题，一种思路

在做智慧工厂相关项目时，我一直在思考：能否让一线人员直接用自然语言提问，系统自动理解意图、生成查询、返回答案？

这听起来像是一个"AI聊天机器人"的想法。但本质上，它要解决的是三个问题：

1.理解用户想问什么

2.把问题转成可执行的查询语句

3.把查询结果转成人能看懂的话

围绕这三个问题，传统方案往往选择"更贵的专业软件 + 更长的培训周期"。而我的思路截然不同：不是让人去适应系统，而是让系统适应人的语言习惯。

这就引出了我今天想分享的核心观点——开放架构，是解决这类问题的唯一正确路径。

先看最终效果演示：

系统全景：四层分离，职责清晰

四层分离的好处是什么？每一层只做一件事，改一件事不影响另一件事。

模块详解：每个设计背后都有一个"为什么"

1. API 接入层：协议的事，交给专业的人

传统工业软件的问题是什么？接口私有、数据封闭、集成靠厂商。

我的选择：用标准的 RESTful API 对外提供服务。

@router.post("/query", response_model=QueryResponse)async def query(request: QueryRequest):    sql = llm_service.generate_sql(request.question)    result = database_service.execute_query(request.db_type, sql)    answer = llm_service.generate_natural_language(request.question, result)    return QueryResponse(question=request.question, sql=sql, result=result, answer=answer)

当你的系统用标准协议对外接口时，它就变成了一个可以被任何前端调用的"能力"，而不是一个封闭的"产品"。今天可以用网页调用，明天可以用小程序调用，未来可以用工厂大屏调用。

2. LLM 服务层：不被任何一个模型绑架

这是整个系统最"开放"的设计点。

传统方案的做法是什么？选定一个模型商，写死代码，深度绑定。

我的做法： 配置与代码分离，模型只是一个可替换的组件。

def generate_sql(self, question):    prompt_template = self.load_prompt_template()    table_schema = get_table_schema_summary()    prompt = prompt_template.format(table_schema=table_schema, question=question)    # 调用大语言模型 API    response = requests.post(f"{self.base_url}/chat/completions",                             headers=headers, json=data)    sql = result["choices"][0]["message"]["content"]    if "```sql" in sql:        sql = sql.split("```sql")[1].split("```")[0].strip()    return sql

API URL、模型名称都从配置文件读取。如果明天出现更好的模型，只需要改配置，不需要改代码。

3. 数据库抽象层：一个接口，多种数据库

传统方案的问题：一个数据库写一套代码，MySQL的运维工程师动不了SQL Server的表。

这背后是什么思维？是"隔离"——每个数据库都是一个孤岛。

我的选择： 适配器模式，统一封装。

def get_connection(self, db_type):    if db_type == "mysql":        conn = pymysql.connect(host=..., port=..., ...)    elif db_type == "sqlserver":        conn = pyodbc.connect(conn_str, ...)    elif db_type == "postgresql":        conn = psycopg2.connect(host=..., port=..., ...)    return conn

上层调用方不需要知道底层是MySQL还是PostgreSQL，接口完全一致。

这意味着你的数据可以自由流动，今天在MySQL，明天想迁到PostgreSQL，成本极低。

4.提示词工程：让业务语言回归业务人员

这是最容易踩坑的地方，也是最有洞察的地方。

传统方案的问题： 提示词硬编码在代码里，改一个字需要发版，需要工程师介入。

开放的做法： 提示词模板独立文件管理。

你是一个专业的SQL查询生成器。请根据用户的自然语言问题，结合提供的表结构信息，生成准确、高效的SQL查询语句。## 表结构信息{table_schema}## 用户问题{question}

表结构信息动态注入后，LLM能理解"查故障"需要关联哪几个表，而不是凭感觉乱写。

更重要的是： 业务人员可以自己调整提示词的语言风格、业务规则，而不需要动代码。

这才是真正的"赋能"。

开放架构的工程价值

回顾整个设计，每一项技术选择都服务于同一个理念： 开放。

• API层 → 协议开放，任何前端都能调用

• LLM层 → 模型开放，不被单一供应商绑定

• 数据库层 → 数据源开放，支持多种数据库

• 提示词层 → 业务规则开放，业务人员能参与优化

因为在智慧工厂的语境下， 变化才是唯一确定的事 ——设备在换、系统在换、需求在变。封闭的系统会积重难返，开放的系统才能持续演进。

架构即思维

回到开头那个场景。

凌晨两点，运维工程师老张不再需要找IT、不需要等排期、不需要翻译SQL。他只需要说一句："帮我查查F001故障最近有没有维修记录，是谁负责的。"

系统很快返回答案。

这才是智慧工厂该有的样子——不是更贵的软件，是更低的认知税    

而实现这个愿景的第一步，是从架构设计开始，选择开放，而不是选择封闭。

我是Tick，一个一心打造智慧工厂的实践者！