1. 这半年我到底干了件什么事先说结论我一个人从零开始用六个月的时间把公司跑了好几年的 ERP 系统从技术栈到业务模型全部重写了一遍。不是换皮不是局部优化而是把原来的单体架构、手工报表、人工对账逻辑全部打散用 AI 辅助生成了核心代码、重新设计了数据模型、还顺手把进销存和财务对账的流程都给捋顺了。这个事情的起因其实很朴素——原来的 ERP 是十年前买的商业套件每年的维护费够养两个应届生每次业务部门提一个“加个字段”的需求实施顾问排期都要到三个月后。更致命的是底层数据库结构早就被各种定制化改得面目全非别说数据分析连正常的库存导出都要半小时才能跑完。公司领导层的想法很简单能不能用现在流行的 AI 技术把这个系统的复杂度降下来别年年往里填钱。我接这个活的时候心里也清楚这不仅仅是一个“用 AI 写点代码”的项目而是要把一个贯穿公司所有流程的“大泥潭”重新梳理一次。半年下来我的体会是一个人做这件事完全可行但成功的关键不在于 AI 多强而在于你把系统拆得多细、流程想得多透、以及对旧系统里那些历史包袱态度有多么果断。这篇文章我不打算写成那种“AI 神兵天降、一键重写系统”的爽文而是想老老实实记录一下这半年的路程——技术选型、架构设计、踩坑实录、还有那些 AI 干不了非得人来扛的时刻。如果你也在考虑用 AI 重写公司的老系统或者你正在做 ERP 相关的数字化转型这里面的很多经验应该能帮你少走不少弯路。2. 动手之前为什么传统 ERP 会让人如此痛苦2.1 老 ERP 真正的痛点不是代码老很多人的直觉是ERP 难用是因为技术落后换个技术栈就好。但接触这行越深你就越会发现ERP 的复杂度从来不是技术问题而是流程和数据的复杂度。我接手的时候先做了两周的调研发现业务部门嘴里说的“需求”往往是表象真正的问题集中在三点。一是数据标准混乱同一个客户名称销售系统里叫“华信科技”财务系统里叫“华信科技有限公司”仓库系统里干脆叫“HXKJ”三套数据导出来做对账的时候全部要靠人工去模糊匹配。二是流程断点太多订单从销售录入到仓库发货中间要经过四个人手工确认任何一个环节的人休假订单就卡住。三是报表严重滞后管理层要看的毛利分析、库存周转率现行的系统做不了实时计算每个月都要财务手工导数据再加工三天。这三类问题本质上和编程语言没关系是系统在十年间被各种妥协性定制浸染之后自然形成的状态。用 AI 重做的第一步不是先写代码而是先重新定义数据字典和流程边界。我把公司所有业务模块翻了个底朝天——销售订单、采购入库、库存调拨、生产领料、财务应收应付、成本核算整理出了大概六十多个核心业务对象然后把它们之间的关系重新画了一遍。说实话这个过程比后面写代码辛苦得多也重要得多。因为只有在这里想清楚了后面用 AI 生成的模块才不会出现“各说各话”的数据孤岛。2.2 为什么现在这件事可以一个人做放在五年前一个人要重写一套 ERP几乎是不可能完成的任务。因为一个像样的 ERP 至少要覆盖进销存、生产、财务、报表、权限、审批流等模块每个模块按传统的开发方式两个人配合也得写大半年。但现在情况不一样了。我个人的体会是AI 编程工具把个人能力的下限和上限同时拉大了。说下限是指像我这样不是每个技术栈都精通的开发者也可以用自然语言描述我要的业务逻辑让 AI 生成基础代码我再修改核心部分说上限是指 AI 可以瞬间完成以前需要大量重复劳动的模板代码、CRUD 接口、数据库迁移脚本让我的精力能集中在架构和业务建模上。后端的整体框架我用的是 Python FastAPI 加 PostgreSQL这套组合的优点是单机部署简单、生态成熟、用 AI 补全代码的效率特别高。前端我原本想用 React但后来考虑到公司内网客户端机器老旧最后改成了 Vue 3 加 Element Plus然后在 AI 的辅助下几乎是一周一个页面的速度在推进。当然速度上的翻倍也不全是好事。用 AI 写东西快了代码量就大得快随之而来的问题就是“看起来都对、跑起来就炸”的情况比手写时代多得多。这逼着我养成了比以往任何时候都严格的代码审查习惯——AI 写的每一段核心逻辑我都要一行一行地确认边界条件。3. 半年重做路径的实操拆解3.1 先定技术主线别让 AI 替你选型如果你问我在整个项目里学到的最大教训是什么我会说是AI 可以帮你写一万行代码但没法替你决定架构走向。我见过太多人上来就扔给 AI 一句“帮我重构 ERP”结果 AI 给出一个包含十几个微服务的花哨方案最后一个人根本维护不住。我在动手前就先圈定了几条不可动摇的主线。第一必须保留单体架构但做好模块化拆分。很多人一听到“重做”就觉得要拆微服务其实对于一家百人规模的公司单体应用加 PostgreSQL性能绰绰有余。我按业务域拆成了销售域、库存域、财务域、基础数据域每个域独立成模块内部高内聚、外部通过明确的 API 通信以后真有必要拆服务可以按域边界直接切。第二前端采用低代码辅助方案。前端是我最担心拖进度的部分因为表单、列表、审批流这些东西数量巨大。我对比了一下如果用纯手写 Vue预计至少三个月如果用低代码平台的付费版又要额外花钱且绑定平台。最后我的选择是自建一套极其轻量的配置化脚手架——把列表页、详情页、表单页做成通用组件每个页面仅需要交付一个 JSON 配置对象和一个自定义逻辑入口。这样AI 生成每个具体功能时我只需要让它输出符合这套脚手架规则的配置而不是从零写页面。这样前后端联调的时间被大幅压缩。第三数据库设计仍然要人来把关。AI 生成建表语句非常快但数据库设计决定了下半年乃至几年的系统健康度。我在建表时坚持了几个原则所有金额字段用 numeric(12,2)所有单据必须有独立的单号字段并创建唯一索引所有核心表必须包含 created_at、updated_at、created_by、updated_by凡是状态字段一律设计成 varchar把具体枚举值写入代码常量表以免后期需求变更时改表。这些规则不复杂但一旦 AI 生成的表结构里漏掉了后面排查数据问题会非常痛苦。3.2 用 AI 重建进销存从数据模型到逻辑闭环进销存是整个 ERP 的骨架也是业务部门每天都离不开的部分。我大概花了两个月时间从数据模型开始一步步重建。采购域方面我把原来的采购申请、询价、采购订单、收货单、入库单几个环节合并成一个“采购全流程”模块在一个界面上可以看到某笔采购的完整生命周期。核心表包含采购订单主表、采购订单明细表、收货记录表。AI 在一个下午就帮我生成了主表的标准 CRUD 和状态流转接口但真正有难度的在于库存的扣减与回补逻辑。采购收货确认后要写库存流水、要更新商品表的实时库存、要触发应付账款的生成这个三连操作必须放在同一个数据库事务里。这里 AI 最初生成的代码是没有事务控制的我在 code review 时发现后补上了async with db.transaction()的包裹并且加入了库存流水表与单据明细表的对账校验。销售域的逻辑更复杂一点因为涉及价格策略和客户信用额度。我让 AI 根据我描述的需求生成了订单锁定库存的接口然后调整了锁库失败时的应对策略——不是直接报错而是把不足部分转入“缺货登记表”再生成一条待确认消息推送给销售员。这一步 AI 给出了一个不错的建议它通过分析我的上下文提出可以用 Redis 做锁库存的临时状态但实际上我们内网环境根本没必要引入 Redis我就把临时锁库存直接用一张order_stock_lock表实现逻辑更直观排查问题更容易。整个进销存跑通之后我明显感觉业务部门的抵触情绪下来了。以前他们最烦的就是仓库数据不实时现在所有操作在一个闭环里走库存账和实物账的差距降到了一个极低的水平。3.3 财务对账模块AI 最大的用武之地与最大的坑财务模块是 ERP 里最容易让人崩溃的部分但这个模块恰恰是 AI 发挥效率最明显的部分。因为财务规则相对固定什么单据走什么科目、税率怎么算、凭证怎么生成这些逻辑清晰且重复非常适合让 AI 批量生成。我设计了一个“财务自动凭证引擎”当采购入库确认时自动生成借“库存商品”贷“应付账款——暂估”的凭证当销售出库确认时自动生成借“应收账款”贷“主营业务收入”和“应交税费——销项税”的凭证。这些凭证规则全部维护在配置表里AI 根据我给的模板一口气生成了十几个场景的凭证生成器准确率出奇地高。但这里也踩了最大的坑。AI 生成的代码里对大数字的精度处理并不稳定。有一次测试发现一笔含税金额为 1,234,567.89 元的销售单生成的税额居然是 123,456.789 这种带三位小数的结果。查了半天发现问题出在 AI 生成的计算逻辑里用了 Python 的浮点数乘法然后在 Decimal 转换时没有指定精度位数。这种问题在最开始的单测里还测不出来因为测试数据都是 100 上下的小数精度误差不容易暴露。后来我在所有金额计算代码里统一强制用 Decimal并且所有除法都显式保持quantize(Decimal(0.01))才算彻底堵住。这件事给我的教训是用 AI 写财务相关代码一定要自己补齐精度测试和大金额的边界测试AI 对“看起来对”的代码有很强的自信但金钱往来不能有丝毫马虎。3.4 报表与数据分析让 AI 从“写报表”变成“搭模型”老系统里每个月财务都要手工导数据做 Excel 报表这也是业务部门抱怨最集中的地方。我重做的思路不是用 AI 写更多报表页面而是搭建一个“报表自定义中枢”。我先把公司所有核心数据统一抽到了一套规范的“事实表”和“维度表”结构里比如fact_sales_order就包含所有销售订单的金额、成本、部门、客户、商品、日期等维度。然后我做了一个拖拽式报表设计器——用户选好维度、选好指标、定义好筛选条件系统自动生成 SQL 查询并输出图表。这个设计器本身是用 AI 生成的。我给它描述清需求左侧是维度和指标列表中间是画布右侧是筛选条件区点击预览后执行数据查询。AI 在几次迭代后给出了一个非常有模有样的实现但我后来发现它在生成 SQL 时对权限的控制不够。不同部门的业务员应该只能看自己部门的业绩数据但 AI 最初生成的 SQL 里完全没有部门权限过滤。我在公共查询入口加了当前用户部门 ID 的强制注入保证任何查询都默认带上这个过滤条件这样报表上线的数据安全性才有保障。报表模块上线后财务部门的反馈是“终于不用每个月加班导数据了”这也是整个半年里我最有成就感的时刻。4. AI 与人分工的实战边界4.1 什么内容可以大胆让 AI 写根据我半年的实际体感我给自己总结了一个“AI 分工清单”现在已经成了我做类似项目的默认准则。适合让 AI 写的内容第一类是标准 CRUD 接口。实体的增删改查、列表的分页查询、简单的状态流转这些代码模式高度雷同AI 几乎不会出大错最多是在字段映射上漏掉一两个认真 review 就能发现。第二类是表单页面和列表页面基于我自建的配置化脚手架AI 生成配置的速度远比手写快而且格式统一。第三类是数据迁移脚本和数据修复脚本。存量数据从旧系统迁到新系统时会有大量字段映射、清洗、去重的活儿这类一次性脚本用 AI 编写效率极高反正用完就丢写得糙一点也没关系。第四类是文档和测试数据。AI 生成测试用例的能力远超过我的预期。我把核心交易流程的业务规则描述给它它能生成覆盖正常、边界、异常等各种场景的测试数据虽然不能完全替代真实的业务验收但作为第一道防线已经足够。4.2 什么内容必须自己一行行写不可碰的领域有几个。一个是核心事务逻辑和财务计算。库存扣减、成本核算、凭证生成这些必须自己手动写AI 的代码只能作为草稿参考。因为一旦出错最容易暴露的问题不是接口报错而是“数据悄悄错了”。浮点数精度问题就是最典型的例子。二是权限模型设计。ERP 里最复杂的就是“谁可以看什么、谁可以批什么”公司的组织架构有部门、岗位、角色、数据范围四层关系AI 可以生成角色表的增删改查但数据权限的查询过滤策略必须人肉设计而且要非常仔细地测试每种组合场景宁可少一点灵活也不能出现越权。三是业务流程编排。采购、销售、财务之间的上下游关系是与公司实际管理模式绑定的。AI 不理解公司里谁和谁有信任关系、哪个环节可以省、哪个环节必须留痕这些必须由人来定义流程节点AI 只负责实现你已定义的节点逻辑。4.3 关键技巧如何“喂”好 AI 让他少写错代码很多人用 AI 写代码觉得不靠谱其实八成问题是出在提问方式上。我半年来最大的一个习惯改变是把需求从“名词描述”改成“场景描述约束条件验收标准”。举个例子如果你对 AI 说“帮我写一个采购入库的接口”它只能给你一个普通的 insert。但如果你说“请实现采购入库接口入参包含采购单号、收货明细、收货人需要校验采购单状态为待收货校验每个明细的到货数量不超剩余数量更新库存流水并生成应付暂估凭证所有操作需在一个事务中完成返回入库单号”它生成逻辑的准确率就会明显上升。还有一个技巧是善用“否定约束”。AI 生成代码时默认会做一些它觉得合理的发挥但这些发挥经常不符合你的实际需求。我在每个模块开始前会明确告诉它“不要引入额外依赖不要使用 AI 自动生成的枚举值数据库操作统一走现有 session所有接口必须返回统一结构”这些约束越早给越省事。另外代码审查必须建立“单项验证”习惯。AI 生成一个接口后我不会直接把整个模块端到端测试而是会用一段最小例子单独验证最核心的业务逻辑。比如先单独测税额计算函数入参 100 和 10000 两种金额看返回的精度是否符合预期。通过的逻辑再放进接口里联调这样问题定位就非常快。5. 踩坑实录这半年我踩过最大的几个坑5.1 旧系统数据迁移纸质时代的账本比代码难搞一百倍重做 ERP 的过程中最让我没想到的是最花时间的事情不是写代码而是把旧系统里的历史数据整理出来。旧系统是一个已经有十年历史的商业套件数据库里的表结构虽然清晰但里面的数据质量惨不忍睹。最典型的是“商品档案”表里面有将近两万条记录但有大约 20% 的商品是重复的只是因为录入时规格写法不同比如“A4 复印纸 70g”和“复印纸 A4 70克”被当成两个商品。至于往来单位更是重灾区同一家客户在不同时期被录成了三四个不同的编号。我用了一周多时间写了一套数据清洗脚本先把商品表、往来单位表、仓库表的重复数据用相似度算法跑出来然后交给业务部门一条一条确认合并。这个环节非常考验耐心因为一旦合并错了后面所有单据的关联全部会乱。整个过程耗时约三周每天的节奏都是白天让业务部门确认合并映射晚上我跑批量更新。这个过程没法用 AI 代劳但 AI 帮我写了不少相似度匹配的脚本用 Jaccard 相似系数和编辑距离做两轮过滤把人工确认的范围缩小了 70%。5.2 流程断点AI 不会替你发现业务逻辑的矛盾重写系统的过程中我发现旧系统里有很多“看似合理但有矛盾”的流程设计。举个例子旧系统里销售订单在“已审核”状态时不允许修改金额。可是销售的实际场景是客户验收后可能因为部分退货导致实收金额和订单金额不一致原来的处理方式是财务直接在应收账款里改金额结果订单、出库单、应收账款的金额就对不上月底对账就成了财务最头疼的一件事。我重做的时候把这种场景重新设计了一遍销售订单保留原金额允许创建一个“销售退补单”来调整应收金额保证订单和应收账款之间永远有据可查。这种逻辑上的修补AI 是发现不了的因为它不知道你的业务里有什么猫腻。所以我一直强调AI 写的是代码流程思考还得靠人。5.3 测试的心智成本AI 生成的代码反而需要更多测试有一种错觉是 AI 写的代码不需要测试因为 AI 自己觉得没问题。但我的经验恰恰相反AI 生成的代码比人写的代码更需要体系化的测试覆盖。原因不难理解一个资深程序员写代码时会下意识考虑边界情况但 AI 是根据概率生成代码的它更擅长把“常见的写法”拼在一起具体到你的业务数据边界它默认会用最典型的情况来覆盖。所以在核心交易路径上我给自己定了一个死规矩凡是涉及金额、库存、状态流转的接口必须写单元测试和集成测试而且测试数据不能只用“正常值”必须包含零值、负值、极大极小值、浮点数边界、空字符串、null 等。这个过程会花不少时间但实际上是在给后面省时间。有一次我以为库存扣减逻辑已经测得很好了结果一个单测里漏了“商品 ID 不存在”的用例后来在联调时才发现当传一个不存在的商品 ID 时AI 生成的代码居然默认创建了一条新的商品记录入库原因是它调用了get_or_create。这种狡猾的 bug如果没有完整的测试覆盖上线后一定会以更难受的方式出现。6. 重做之后的变化与后续思考6.1 上线前后系统的真实指标对比现在系统已经上线稳定运行了两个多月我可以给一些真实的数据对比。原来导出全量库存报表要半小时现在同样是全量数据从点击到输出 Excel 不超过 8 秒。原来月末财务对账需要两个人加班三天现在财务报表自动生成对账只需要财务复核异常项整体人力消耗减少 90%。原来新增一个业务字段从提需求到上线要两个多月现在基于配置化脚手架我平均一到两天就能完成一个字段的新增和页面上线。业务部门的使用反馈也比较正向最典型的评价是“页面变快了操作流程能顺下来”。这里说的“顺下来”就是指订单从录入到发货的所有状态变更都在一个页面上可追踪不用像以前那样来回切换三四个窗口。当然系统刚上线那几周也有阵痛。比如有几天销售部门反馈打印发货单的速度变慢我排查下来是公共查询接口没有加数据库索引导致列表页关联查询走了全表扫。这个问题的修复倒是很快加索引就完了但也提醒了我AI 生成的查询代码里特别容易漏掉联合索引设计需要人工在压测后补上。6.2 这套方式还能怎么扩展半年做完了进销存、财务、报表、权限这几个核心模块但系统的扩展空间还有很大。我已经在着手布局下一步的几个方向这里也一并分享出来。第一是生产工单管理。公司属于轻加工行业生产环节的领料、退料、完工入库目前还是脱离系统在用 Excel 管理。我计划下一步把生产工单纳入进来与现有的库存和成本核算模块打通这样成本就能自动归集到产品上而不是靠财务月末手动分摊。第二是移动端审批。现在公司管理者出差时审批还得打开电脑这在移动互联网时代已经显得很不合时宜了。我准备用企微的 H5 应用接入现有的审批流引擎让订单审核、采购审核、报销审批都能在手机端完成。第三是 AI 数据分析助手。现在报表模块已经能自动出报表但管理层经常还会追问“为什么这个月华东区毛利率下降了”这种诊断型问题需要一个语义层解析器把所有表结构、指标口径和维度关联关系都配置好然后让大模型生成对应的查询逻辑并解释原因。这个方向我觉得比写一堆固定报表更有价值它真正让数据变得会说话。7. 几点体会收尾半年下来回头看我最大的感受是用 AI 重做 ERP 这件事真正的难度从不在“写代码”而在“想清楚业务”。AI 是一个超级高效的执行者但它不是一个懂业务的顾问。一个恰当的比喻是AI 像一台动力极强的挖掘机。如果你没有图纸就让它挖它能在半天之内给你挖出一个巨大的坑但那个坑是不是你要的完全取决于你的思考和决策。所以如果你想做类似的项目我的建议是花 30% 的时间设计数据模型和业务流程花 40% 的时间做数据迁移和测试剩下 30% 再交给 AI 去生成和迭代代码这样效率最高风险也最低。还有一个小建议如果你也打算一个人干这件事最好在项目开始前就把范围界定清楚宁可只做进销存和财务两个模块也不要贪多。一个人做系统最怕的是铺开面太大最后每个模块都半生不熟。先把核心业务跑顺让业务部门看到实实在在的收益再往周边模块扩张这个节奏会更稳。最后分享一个我后来一直在用的方法每完成一个模块我都会把项目中踩到的坑和 AI 交互的提示词模板整理成文档。这套文档现在已经成了我自己的“AI 辅助开发手册”做下一个项目的时候很多问题都不用重新试错。这种积累才是半年项目真正留下来的资产。