从一个进销存，到一个轻量 ERP：我用 AI 做了一套业务系统
2026-05-07 08:42:21 24 0
很多人做进销存，最后都会陷入一个问题：
要么太简单，只能记账
要么太复杂，像一套“迷你 SAP”，没人愿意用
我最近做的这个系统，一开始也只是想解决一个很现实的问题：
👉 以销定采 + 库存可控 + 资金可追踪
但做着做着，它慢慢“长大”了。
一、系统整体结构
目前系统已经覆盖了四个核心角色：
1️⃣ 销售侧
-
销售单：创建 / 修改 / 审核 / 售后
-
自动生成出库单
-
发起应收
-
发票录入、合同管理
-
售后支持：退货入库 / 补发出库
👉 核心目标：订单驱动一切
2️⃣ 采购侧
-
基于“待采购”生成采购单
-
采购单审核、售后
-
自动生成入库单
-
发起应付
-
发票录入、合同管理
👉 核心目标：以销定采，减少库存积压
3️⃣ 仓库侧
-
出入库管理
-
库存盘点
-
外借管理
👉 核心目标：库存准确 + 流转清晰
4️⃣ 财务侧
-
应收 / 预收 / 抵扣
-
应付 / 预付 / 抵扣
👉 核心目标：业务与资金闭环
二、系统的“核心中枢”：待采购
这个系统最关键的一点，不在功能，而在“数据流设计”。
👉 所有采购行为，都来源于销售单推导出的“待采购”数据。
逻辑如下：
-
销售单 → 占用库存
-
库存不足 → 生成待采购
-
待采购 → 转采购单
-
售后发生 → 自动回补/冲减待采购
这解决了一个很真实的问题：
❗ 避免“多采”与“盲采”
同时也带来了一个挑战：
❗ 售后、在途库存、已采购未入库，都会影响待采购
目前系统已经支持：
-
售后自动回滚采购需求
-
在途库存参与计算（规划中/可扩展）
三、为什么说“有点用力过猛”
因为你会发现，这套系统已经具备：
-
订单流（销售 → 出库）
-
供应链（采购 → 入库）
-
资金流（应收 / 应付）
-
库存流（实时变化）
-
售后逆向流程
👉 这其实已经是一个完整业务闭环系统
换句话说：
这不是“进销存”，而是一个轻量 ERP 内核
四、最大的不同：我是用 AI 来开发它的
这部分，才是这个项目真正有意思的地方。
整个开发过程，我没有走传统路径，而是：
1️⃣ 先让 AI 写单元测试
不是先写功能，而是：
👉 先定义“系统应该如何正确运行”
包括：
-
销售 → 库存占用
-
库存不足 → 触发待采购
-
售后 → 回滚数据
2️⃣ 再补充“真实业务场景”的集成测试
我会给 AI 一些典型场景，例如：
-
销售10个，库存2个 → 采购8个
-
采购后，发生退货 → 是否出现“多采”？
-
发货一半时发生售后 → 数据如何一致？
👉 这些是传统 CRUD 系统最容易出问题的地方
3️⃣ 最后才是 UI 与压力测试
-
UI：保证业务可操作
-
压测：验证并发下库存与资金是否正确
五、这种方式带来的变化
和传统开发相比，有几个明显不同：
✅ 1. 系统更“抗业务复杂度”
因为测试先行，很多边界情况一开始就被覆盖。
✅ 2. AI 更像“协作开发者”
不是写代码工具，而是：
-
写测试的人
-
推演业务的人
-
帮你找漏洞的人
✅ 3. 开发节奏更快，但更依赖设计能力
AI 可以写代码，但：
❗ 系统对不对，取决于你怎么定义规则
六、接下来会做什么
后续计划：
-
完善“在途库存”对待采购的影响
-
优化库存占用模型（锁定 / 释放机制）
-
增加更多自动化测试场景
-
打磨 UI，让系统更轻量可用
最后
一开始我只是想做一个简单的进销存。
但现在，它更像是：
👉 一个“由 AI 驱动开发的业务系统实验”
如果你也在做类似系统，可以交流。
因为真正难的，从来不是“写代码”，而是：
把业务讲清楚。