BossAgents从桌面到手掌：BossAgents微信小程序如何让PLM管理“随时在线”
想象一下这个场景：你正在去机场的路上，手机突然震动——一条紧急的工程变更请求(ECR)等待审批。按照以往，你得赶紧找台电脑，登录系统，在一堆复杂的菜单里找到审批入口。但今天不一样，你只需在微信里点开一个小程序，扫一眼变更摘要，手指轻点“通过”，整个过程不到30秒。
这不是未来，这是BossAgents微信小程序正在实现的事情。
对于很多制造企业来说，PLM系统就像企业的“产品大脑”——管理着从设计图纸到BOM结构、从供应商信息到变更流程的一切。但问题是，这颗“大脑”通常被锁在办公室的电脑里。工程师出差了、管理者在车间、运维人员巡检时，想要快速查一条数据或批一个流程，往往需要“找电脑”这个前提条件。
移动化，成了PLM系统最大的痛点之一。
今天，我们就来聊聊BossAgents团队是如何用一套统一架构，让原本“沉重”的PLM系统，轻巧地跑进微信小程序的。
---
设计哲学：不做“缩水版”，只做“刚刚好”
很多企业在做移动端时容易陷入两个极端：要么试图把PC端的所有功能都搬过去，结果交互复杂到在小屏幕上根本没法用；要么只做个“查询工具”，核心操作还得回电脑。
BossAgents选择了第三条路——“渐进增强，移动优先”。
我们定下了五个核心原则：
- 后端统一
- 渐进增强
- 移动优先
- 离线友好
- 微信生态
基于这些原则，我们明确了MVP阶段要聚焦的五大场景：
| 场景 | 用户角色 | 核心需求 | |------|----------|----------| | 移动审批 | 管理者 | 随时随地审批ECR/ECO变更请求 | | 快速查询 | 工程师 | 秒查BOM结构、零件信息、供应商 | | AI助手 | 所有人 | 用自然语言查数据、建对象 | | 状态监控 | 运维 | 查看数字员工运行状态 | | 通知接收 | 所有人 | 变更通知、审批提醒、异常告警 |
至于那些交互太重、屏幕太小、使用频率低的功能——比如复杂的BOM树形编辑、文件上传、系统配置——我们果断把它们留在了“不做清单”里。
少即是多，有时候“不做什么”比“做什么”更重要。
---
架构解密：一条API，服务两端
很多团队在做小程序时，会习惯性地建一套独立后端。但BossAgents的做法不同——我们选择复用现有的Node.js后端，只做“增量适配”。
整个架构看起来是这样的：
客户端层：Web前端（Vue 3）和微信小程序（uni-app）并行存在，各自调用同一套后端API
代理层：Nginx做反向代理，统一路由
后端层：现有的Node.js后端（80+ RESTful端点）保持不变，新增一个/api/miniapp/路由组，专门处理小程序特有的需求
数据层：SQLite本地缓存 + SCSAI agent（SOAP/AML）+ 外部服务（LLM、飞书等）
这个设计最巧妙的地方在于：Web端和小程序看到的，是同一个后端世界。 只不过小程序多了一层“翻译官”——/api/miniapp/路由。
为什么需要这个“翻译官”？
因为微信小程序有两个“先天限制”：一是无法直接调用SOAP/XML接口（而SCSAI的系统正是基于SOAP/AML协议）；二是小程序有严格的域名白名单和安全限制。所以，我们让后端充当“透明代理”——小程序发一个JSON请求，后端把它转成SOAP/AML发给SCSAI，再把结果转成JSON返回。
用户感知不到这层转换，只会觉得“哎，这小程序查数据真快”。
---
后端适配：三块拼图，补齐移动能力
要支撑小程序的运行，我们在后端新增了三块核心能力：
第一块：微信登录与账号绑定
小程序通过wx.login()获得临时code，后端调用微信的code2session接口换取openid，再生成JWT令牌。如果用户是第一次使用，可以通过/api/miniapp/bind-user接口将微信openid与现有的PLM账号绑定。一次绑定，永久免密登录。
第二块：SCSAI透明代理
这是最核心的技术点。小程序发起的每一次SCSAI查询，都走/api/miniapp/proxy/SCSAI这个统一入口。后端接收到JSON参数后，动态组装成SOAP/AML请求，发给SCSAI，再把结果解析成JSON返回。
这样做的好处是：小程序前端完全不需要知道SCSAI的存在，它只需要跟RESTful JSON API打交道。 而且，后端可以在代理层做缓存、限流、错误处理，提升稳定性和响应速度。
第三块：消息订阅与推送
微信小程序支持模板消息推送。用户在小程序里授权订阅后，当有新的审批任务、变更通知或异常告警时，后端就会通过/api/miniapp/send-template-msg接口，给用户发送一条微信服务通知。
这意味着：管理者不用再频繁打开APP或登录系统，微信消息就能把关键信息推送到眼前。
---
前端选型：为什么是uni-app，而不是原生？
在技术选型上，我们面临一个选择：是用微信原生开发，还是用跨端框架？
最终敲定了uni-app（基于Vue 3）。理由有三：
- 1. 团队熟悉度
- 2. 代码复用
- 3. 未来扩展
当然，跨端框架也有性能损耗。但我们权衡后认为，对于PLM这种企业级应用，功能完整性和开发效率比极致的性能更重要。
UI组件方面，我们选择了uni-ui + 自定义组件。uni-ui提供微信原生的视觉风格，自定义组件则用来处理PLM特有的数据展示，比如变更状态标签、BOM树形结构、审批流程图等。
---
页面结构：四个Tab，覆盖80%高频场景
小程序采用经典的底部Tab导航，一共四个页面：
- 1. 首页
- 2. 查询
- 3. AI助手
- 4. 我的
每个页面都遵循“移动优先”的设计原则——信息层级清晰，操作路径短，关键按钮放在拇指易触达的区域。
比如审批页面，我们设计了“三秒决策”模式：变更摘要一目了然，附件支持预览，审批按钮（通过/驳回/转办）固定在底部，用户无需滑动页面就能完成操作。
---
开发路线图：小步快跑，持续迭代
整个开发分为三个阶段：
Phase 1（MVP）：实现四个核心Tab + 微信登录 + 账号绑定 + 审批流程 + BOM查询。目标：让用户“能用起来”
Phase 2（增强）：AI助手集成 + 消息订阅推送 + 离线缓存 + 性能优化。目标：让用户“用得顺手”
Phase 3（扩展）：更多业务场景覆盖 + 数据统计 + 多端适配。目标：让用户“离不开”
每个阶段周期2-3周，快速上线验证，根据用户反馈调整方向。
---
风险与应对：提前想好“如果”
做任何项目，风险预判都是必修课。我们识别了几个关键风险点：
- SCSAI代理性能
- 小程序包体积
- 弱网体验
- 微信审核
---
写在最后：移动PLM，不只是“换个屏幕”
从Web端到微信小程序，表面上只是“换了个屏幕尺寸”，但背后是产品思维的转变——从“功能完整”到“场景精准”，从“全键盘操作”到“拇指交互”，从“必须在线”到“离线可用”。
BossAgents团队一直相信：好的企业软件，应该像水一样，流到用户所在的每一个场景里。 办公室的电脑前、工厂的车间里、出差的路上——无论你在哪，PLM系统都应该触手可及。
而这，正是BossAgents（左帮右臂）智能体公司的使命——用智能体技术，让企业核心系统变得轻盈、敏捷、无处不在。
如果你也在为PLM系统的移动化发愁，不妨想想：你的用户，真的需要一台电脑才能完成工作吗？
也许，答案就在他们的手掌心里。
