传统 ERP 的难点并不在于将采购、销售、库存和财务数据存入系统，而在于业务人员需要在多个模块之间反复录入、查询和核对。表单字段、审批路径与数据报表相互关联，操作入口越多，流程偏差和信息滞后越难控制。将大模型能力接入 ERP，关键也不只是增加一个聊天窗口，而是让自然语言交互、安全的数据访问与既有业务流程形成闭环。
GVV-AI-ERP 将企业资源管理模块与 AI 交互能力放在同一业务平台中。系统覆盖采购、销售、库存、财务和生产等核心环节，同时提供自然语言表单提交、业务数据问答、知识库查询和数据分析能力。对于需要以 Docker 方式快速搭建管理平台，并在后续接入自有模型或行业规则的团队，这种组合减少了从业务系统到 AI 工具之间的割裂。
项目采用 MIT 开源许可证发布，支持商业化使用，并允许在遵守许可证条款的前提下进行修改、分发与二次开发。
从业务模块到 AI 操作入口
GVV-AI-ERP 的业务侧以采购、销售、库存、财务和生产管理为基础。采购流程可关联供应商、订单、到货验收与对账结算；销售流程覆盖客户、报价、订单和发货跟踪；库存侧负责出入库、盘点、安全库存预警与批次管理。生产管理中的 BOM、工单、进度与质量检测，则为生产型企业保留了可继续扩展的业务边界。
AI 能力在这里承担的是操作与查询层，而非替代底层业务规则。例如，用户通过自然语言描述采购需求时，系统可将意图映射为业务表单；当信息不完整时，连续对话可用于补充或修正字段。审批流程可结合金额等条件配置分支，避免所有单据流向同一处理路径。业务人员查询库存、销售额或缺货商品时，交互入口仍然需要受限于其可访问的数据范围。
分层架构中的模型调用边界
前端采用 Vue 3 与 Ant Design Vue 构建业务界面，适合承载表单、仪表盘与管理模块。AI 对话层使用 WebSocket 维持实时通信，并支持 Markdown 渲染，以适配问答、分析结果和较复杂的文本输出。
后端以 Spring Boot 3.x 承担业务服务和接口处理。GVV-AI-ERP 通过 Spring AI 抽象不同模型服务的调用方式，可接入 OpenAI API、Ollama、Qwen 等模型或本地化部署方案。这样的抽象将 ERP 业务接口与具体模型提供方分开：业务层关注采购单、库存和报表等对象，模型接入层负责请求组织、上下文传递与模型切换，降低后续替换模型时对业务模块的影响。
MySQL 8.0 用于持久化业务主数据与流程数据，Redis 7.0 承担缓存和会话管理职责。对于具有连续追问需求的对话场景，会话状态不能与长期业务数据混为一体；对于采购、财务等需要审计追溯的对象，则应由持久化数据和业务权限共同约束。两类数据边界分开处理，才能避免 AI 对话能力绕开 ERP 的业务控制。
自动化流程需要保留可追溯性
在 ERP 场景中，AI 自动化的价值取决于它是否接受既有流程约束。以采购单为例，自然语言可辅助生成表单草稿，但供应商、金额、审批条件和单据状态仍应进入确定的业务流程。金额触发的审批分支、人工修订记录和后续对账关系，共同构成可核对的操作链路。
GVV-AI-ERP 的知识库能力可用于解析 PDF、Word、Excel 等企业文档，并在对话中提供相关信息。实际部署时，应将文档上传权限、知识范围与回答权限绑定到角色体系中。合同、财务或供应商资料的可检索性，不应自动意味着所有用户都可获得完整内容；系统需要在模型回答前保持数据访问边界。
数据分析同样应服务于业务动作。销售趋势、库存周转和需求计划可通过看板呈现，再由管理人员结合采购、生产或补货流程作出决策。模型生成的分析结果适合用作辅助信息，而不应替代审批、核算或生产计划中的确定性规则。
Docker 部署与生产约束
GVV-AI-ERP 提供 Docker Compose 方式，可将 ERP 应用、MySQL 和 Redis 组成完整服务栈，也可在已有数据库与缓存服务的环境中拆分部署。容器化降低了本地验证和环境一致性的成本，但生产环境仍需将默认账号、数据库口令、模型 API 密钥与外部访问策略替换为独立配置。
当系统接入本地模型或外部模型 API 时，建议将模型地址、访问凭据和调用额度从业务配置中分离，并限制其读取的数据范围。对于 Kubernetes 等集群部署环境，还需要结合服务发现、持久化存储、日志与监控机制，保证业务模块扩展后仍可定位接口、缓存或模型调用链路中的异常。
结语
GVV-AI-ERP 的技术取舍在于，以成熟 ERP 模块承载确定性业务规则，再通过模型接入层提供表单辅助、数据问答、知识检索和分析能力。对于希望在企业管理系统中引入 AI、同时保留数据权限、流程控制与二次开发空间的团队，这种分层方式提供了可继续演进的实现基础。
