企业很多数据和操作已经存在于不同业务系统，增加 AI 能力不一定要求重新开发整套系统。更稳妥的路线往往是复用现有 API，在受控工具层之上提供自然语言交互和流程编排。
从 Swagger/OpenAPI、系统文档或浏览器开发者工具中识别必要的业务查询接口。明确接口的请求参数、权限、数据口径和返回含义，并通过服务端代理封装为稳定的领域工具。不要直接让模型自行访问生产数据库或拼接任意 SQL。
例如“查看某客户尚未发货的合同”，需要解析客户实体、合同状态、时间范围等字段。由应用层进行权限与参数校验，再查询合同、出库或交货信息，最终统一返回结果及来源。
查询类工具应执行最小权限和结果脱敏。修改订单、锁库、发货等涉及真实业务状态的操作，应增加规则校验、二次确认、幂等键和审计日志。AI 模型提出操作意图，不直接替代企业的业务约束。
WMS 关注“货”：货物收发、库位、批次、盘点和追溯；YMS 关注“车与园区资源”：预约排队、门岗、过磅、月台及离场；TMS 关注“运输”：运输委托、承运商、在途节点、签收与回单。
例如销售订单生成后，WMS 负责拣配和实物出库，YMS 负责车辆进场与磅单记录，TMS 负责运单及签收。三者通过统一业务单号、单据状态和幂等接口交换事件，减少同一业务在不同系统中重复操作。
物理库存通常应由仓储执行系统负责核对，订单预留、货权和可售库存可以由统一库存中心或上层业务系统承担，具体根据企业组织、SAP 等既有能力选择架构。
企业系统上线不应只关注服务器是否能访问。域名与 HTTPS、应用性能、数据库备份、安全规则、版本回滚和日常监控，同样会决定后续维护成本。
根据访问量、业务高峰、系统重要性和数据保留要求选择服务器、数据库及备份策略，不必一开始就采用过于复杂的架构。将配置文件、证书与密码分离管理，记录部署流程。
定期备份数据库和文件，测试备份恢复流程，为应用设置健康检查和基础日志告警。系统升级时先验证兼容性，保留回滚方案。只有“可维护、可恢复”，才是真正意义上的可上线。
从现状分析到系统上线，用可执行的技术方案解决真实问题。