其实我始终认为自研的系统很难称得上是“ERP系统”，无论是功能的完善程度还是使用的便捷性、通用性，大部分公司自研的系统都应该称之为“定制业务系统”。这种系统在立项、设计、实施前后都充满了不确定性和个性化，不确定的原因是见过太多的需求变化，这种变化你就是当场让需求方立字据确认后面不修改也没用！

自研“采购系统模块”之前已经做过2个都正式上线用了几年，算上最新的这个采购需求是第3次要自研了，有同学可能要问为什么同样的系统要做多个？因为运营老总的需求不一样，大老板涉足的行业不一样，对供应链采购系统的需求自然不一样，更何况要配合已经自研的C端、B端产品进行业务、数据打通……

前面说太多，今天只想聊下采购下单计划与最终成单如何对比这个事情， 就一个自研采购订单现在已经发展到有如下几个概念：采购需求单（门店给大概需求计划）、采购计划单（总部根据供应链情况及采购经验对门店采购需求单进行调整形成采购计划单）、采购配货单（总部分批次让供应商发货配货形成的子订单）、采购成单（最终所有采购配货单组成的大单）。这次运营想要知道这些单子之间的关系及变动情况，之前我们图省事都是直接记录流水的，运营估计也很少自己导出吧，这次就想着把这个功能尽量做“好”一点吧！

最终的方案其实也很简单，就是参考git给这些个单子之间做diff 对比，目前产品原型还没开始设计，只是让AI 预先生成了几个版本预览，后面打磨下使用者想对比哪些单子/自动对比哪些单子都行。

1、扣子（C端效果）

订单维度对比：

变更流水日志：

总览+明细：

下图的“流向对比图 – SKU流向总览”，这个不知道是它瞎画的还是我没看懂（只能当个可视化图表demo来看）。

2、千问（B端极简）

很标准的element 风格，数据简单但信息足够。

这个是看板维度，样子货信息不全，但也有借鉴价值。

流水明细，很中规中矩的设计方案，变更案例也不全。

3、CodeBuddy（Vue 组件开发）

因为我电脑装的开发环境比较多，这里就直接在CodeBuddy 中让它使用vue 开发的，开发完毕它自己npm run serve 就打开了！

顶部是导入对比数据区域，这个vue方案更注重落地执行，让它封装了组件，最终其实就是2个json对比，实际开发中只要后端有返回2个单子的json数据，前端直接就能对比了（当然也可以后端处理好格式前端直接渲染）。

对比结果

总结下吧：

1、对千问的结果不是很满意，太精简保守了以完成指令为目标，方案对用户交互考虑不够（比如订单对比不能直接切换 新增、删除、变动 来查看同类型变动）

2、扣子表现让人意外，给的方案比较详细会“考虑”的比较多，字节的大模型虽然没啥存在感，但是智能体 （所谓 Harness） 这块做的还是不错的，有时候能一定程度弥补大模型的不足。

3、CodeBuddy 是因我还有5000多积分没用，就让它也参与了下，效果还行反正也是够我这项目使用了。最近这几个月感觉CodeBuddy 进步比较大，不知道是舍得用大模型了还是智能体改进了（大部分任务我模型选择都是开Auto）。

4、在这个AI 时代真的是人人都要把AI 工具当成普通软件来用，它学习的接触的知识很广泛，平常产品需求、设计问问它们也会有不少收获。或许再过2年，不会用AI 就跟20年前不会用电脑的人一样。