《管理软件AI化落地实录》, 它是一部关于传统管理软件AI重造的全程实录。这个实录包含9个模块, 还有200张表, 是从零开始搭建的, 而且人没有写一行代码。我身为甲方, 记录下我亲手所做之事。
有一家从事跨境物流的公司, 它的业务范围涵盖了物流, 仓储, 报关, 换单。这家公司自主打造了在供应链管理方面的软件, 还实现了AI自动化办公的落地, 且是从无开始做的。
身为数字化负责人的我, 记录下从项目选型开始, 历经项目开发阶段, 直至最终交付运营的那般完整落地流程。今天要讲的头一件事是, 项目技术架构选型。
先来交代一下基本面, 有9个模块, 其包含订单管理、仓储管理、物流管理、商务管理、BI中心、系统管理、基础管理、档案管理以及企微消息交互这9个方面, 还有200张表。再说有规模100来人的用户, 但其业务可不简单, 其中物流管理涉及三种业态, 仓储管理要管批次效期, 商务管理需管计费、对账以及合同, BI要从200张表里提取数据。
这些，是选型的约束条件。
二、AI 应用在 2B 管理软件上走到哪了
选技术栈之前，得先想清楚 AI 能干什么、不能干什么。
审视这过去的一年半时间, AI于2B办公范畴呈现出历经三个迅速迭代的时期, , 起初是2025年初兴起的那次统计分析风潮（具备查看、审视数据的能力、然而却不拥有操作数据的功能）, 继续发展到下半年的Dify/N8N的可实施配置智能架构平台（具有构造流程的能力、只是场景存在割裂状况、数据缺乏治理措施），进而发展到今年的这类具备工程化特性的通用智能架构, 其模式从"你搭建流程由AI执行"转变成为"你凭借描述意图AI就能自主予以完成"。
可是在进行了几个月测定之后, 却发觉了这样一个实际情况: /coze等等之类的，个人场景已然十分强大, 然而公司级团队协作场景却仍不太行。它并非协作工具, 而是个人生产力工具。
这就引出了这套方案的核心定位------
通用智能体即 Coze 担任 AI 能力层的职务, 业务管理系统负责业务的流转, 还负责数据治理。这两者借助 API 实现了打通, 其目的并非是要让 AI 去替代业务系统。
回顾这一年半的时间, 为何在2B管理软件范畴内, 几乎不存在形成规模的AI应用呢? 存在四条核心缘由:
第一, 2B场景的关键在于"操作"而非"分析"。企业落地应用中最大的场景是办公自动化, 对于2B系统而言, 其核心是生成订单、进行出入库操作以及结算发票等, 在满足公司管理规范（业务管理单据加上流程）的基础上, 进一步提升员工自动化办公水平。最先打造的是操作过程当中的数据, 随后才是智能"分析"。
其次, 传统管理软件繁杂至极, 大量代码是针对"人机交互便利性"编写的。录入一张入库单, 能自动带出默认仓库, 填充批次, 推荐库位, 校验上限, 这些占据了一个模块30%至70%的代码量。复杂逻辑致使AI无法洞悉全貌, 从而没能力施展作用。我的方案是, 要通过整理以及收集数据, 借助API写入业务数据, 人在这套系统里时进行简要复核, 如此一来, 原来传统项目中"便利性复杂逻辑"的代码就全然无需了。
那么第三点, 数据治理这一环节是无法避开的, 客户名称存在三种不同的撰写方式, 费用项所对应的业务意义, 当AI遭遇缺乏业务语义的数据时, 其输出产生的幻觉难以避免不谈, 怎样去规避这种幻觉乃是此项目的关键要点所在, 后续将会予以记录。
第四, Vibe的那种能力遭到了极为严重的低估, AI编码于公众号、小程序当中能够施展得很顺利, 然而在有着200张表、存在多表关联以及状态机流转的2B场景里, 几乎没有什么人敢去触碰, 还要注明一下, 这是挺让人难过的事实, 编码在全行业使效率提升的幅度还没有达到10%, 而这里恰恰正是AI编码能力最应当发挥其价值的所在之处。
由于这样, 所以我才撰写这个系列了。对于2B管理软件而言, 其AI实现落地, 并非是关于能不能做到的问题, 而是涉及到究竟该如何去做的问题了。
三、选型决策
鉴于上述所提及的定位, 即开展AI层相关工作, 同时管理软件进行业务流转以及实施数据治理, 如此一来, 选型便具备了锚点。
决策一：单体还是微服务？
有着二百张表, 以及一百人的规模, 处于传统架构经理的情况下, 大概率会选择Java微服务, 然而我却没有选择, 我选择的是单体服务。
简单来说, 有如下几个理由。其一, 不存在高并发情况, 仓库录单人数不足十人, 物流调度也就七八人, 微服务所解决的高并发问题在此处并不存在。其二, 微服务的部署实在太过复杂, 涉及K8s、注册中心、配置中心以及链路追踪等, 十来人的IT团队养不起专职的部署工程师。其三, 考虑服务器成本, 微服务需要5至7台机器起步, 而单体只需2至3台就足够了, 如此一来硬件成本能省下一半还多。
决策二：Java、 还是 Node.js？
对于这个项目, 我给自己定下这样一条规矩, 即这个项目的全都由AI生成, 里头任何一行代码, 其中的任意一份内容, 我都不去触碰。
根据这条既定的规则, 挑选的准则发生了改变，不再考量生态环境, 也不再关注社群情况, 而是聚焦于------究竟哪一种语言在借助人工智能生成代码时, 出现错误的概率是最低的?
答案是, 代码量要是越少, 那么出错率就会越低。本来一个文件就能搞定的事情, 可是 Boot 却要拆分成 5 个类。拆分得越零散, AI 在多个文件之间的一致性就越难以保证。
并且, 这一组管理软件已不再涵盖较多交互便利性逻辑, 传统软件撰写出"默认值填充", "下拉联动", "关联数据带出", 皆是出于使界面操作得以顺畅的目的。然而在我们所采用的模式当中, 依据业务实体依照动态方式生成数据, 借助 API 将数据推送至系统, 人员仅在进行数据确认时才会瞧上一眼界面。增删改查虽然仍然存在, 可是那些具备"便捷性"的交互逻辑已不再需要编写代码了。
决策三：MySQL 还是 ？
以往传统 2B 场景会选择 MySQL, 而我进行的选择并非如此, 这不是由于"更先进"这个缘由, 而是因为需求已然发生了变化。
知识库进行交互, 要跟系统开展知识库积累, 其中涵盖大量非结构化数据, 诸如合同扫描件、操作手册, 而且知识库的 JSONB加上全文检索天然支持"结构化加上非结构化混合查询"。
针对档案管理所提出的半结构化需求, 合同之中的核心信息, 也就是金额、日期以及费用条目, 这些属于半结构化数据, 將它们存入 JSONB 字段里, 不但能够保持灵活性, 而且还可以参与 SQL 聚合, 只是 MySQL 无法做到这种级别的 GIN 索引支持。
硬件成本反倒下降, JSONB与全文检索是内置的, 不需要额外添加用于做搜索的, 也不需要添加用于做文档存储的, 如此便省掉了两套中间件, 硬件成本降低了大约50%。
决策四：前端用什么？
后端定了 ，前端呢？
答案很直接：Vue 3 + Plus。
怎么就不是 React , 怎么就该全砍了界面采用纯 API 模式, 回到这方案核心的所具情形, 去生成数据, 并经 API 推送, 促使业务系统入库, 然而每个业务环节最终得有人去确认那最后的一步, 入库单 AI 已帮你填好了, 可你得瞧一瞧数量是否正确后再去点"确认", 合同匹配 AI 也已为你算好了, 但是你得核查一下匹配结果后再去点"过", 这些"最后一环"的确认行为, 必定得有界面。
因此, 前端并不可以省去。然而, 它实则也没必要做得过于繁重------传统管理软件前端之中, 像某些逻辑, 诸如"默认值联动""下拉级联""自动计算带出", 于我们当下的模式里是不需要的了。因为AI在推送数据之前就已经做出了决策。前端能够提供清晰的列表、表单以及按钮, 从而使人能够进行查看、修改以及确认。
Vue 3与Plus的搭配, 于这件事情上恰好足够使用。由AI生成的Plus组件代码质量相当高, 其中包括表格、表单、对话框、按钮, 这些高频使用的组件生成得既快速又精准。并且Vue的SFC（单文件组件）结构天生契合AI生成, 一个.vue文件涵盖模板、逻辑、样式, AI一次生成便能够运行。
前端与后端交互通过走 API 来实现, 前端仅仅负责进行展示以及确认, 而不承担业务判断逻辑。
四、总结
决策
选项
结论
核心理由
架构
微服务 vs 单体
单体
无高并发，微服务运维不经济
语言
Java vs vs Node
代码越少，AI 出错率越低
数据库
MySQL vs
非结构化+全文检索内置，匹配 AI 环境
前端
Vue 3 + Plus
AI 生成质量高，满足确认环节的 CRUD 需求
下图是这一架构的总览。
但说真的，选型只是第一步。更复杂的是整个项目的建设规划------
在每一个迭代进程当中, 于从需求设计开始, 历经开发、测试直至实施的各个环节里, 规范均务必维持一致。需求文档该如何撰写, 接口定义要怎样确定, 测试用例要如何进行覆盖, 每一次步骤都得拥有统一的AI编码规范。怎样促使AI依照统一风格去生成200张表的代码? 如何确保12个标准字段在每个模块都保持一致?
前端跟后端的逻辑分工得清楚明晰, 前端仅仅负责展示以及确认, 不进行业务判断, 然而"不编写业务逻辑"这一界限划在哪里, 是需要有明确的约定的, 此情形下。
需要去考量那些处于AI模式之下所特有的风险, 像是怎样去防止AI将数据进行批量误删除情况出现, 对数据权限怎样于API层面以及前端层面进行双重严格审查, 对于工作流引擎------即订单审批跟入库复核这两方面------怎么在下具备"AI生成 + 人确认"的这种闭环当中去实现运转呢?