一个人用AI重做ERP的这半年听起来像是朋友圈里又一个噱头标题。但我是真的干完了——从去年秋天到今年春天差不多六个月一个人一台电脑把一套原本要五个人干一年的ERP系统重做了一遍。这里说的“重做”不是把旧代码翻新而是面对一套老掉牙的系统理清业务逻辑用AI把前端后端全部重建最后让新系统真正跑在公司日常订单、采购、库存和应收应付上。这篇东西不是炫技也不是卖课就是一个极简团队其实就我一人用AI做企业软件的完整复盘。整个过程我用了一堆AI工具大模型对话、代码生成、Agent自动编排、AI辅助测试不同的阶段用不同的手段踩了不少坑也总结了一些很实在的方法。如果你也正在考虑用AI独立做一个复杂的系统或者被传统ERP的开发和维护折磨过这篇文章应该能让你少走很多弯路。我先把结论放在前面一个人用AI做ERP这件事技术上已经完全没有壁垒真正的难点在于业务理解、边界控制和上线后的不确定性。AI解决了“写代码”的效率问题但你需要一个更清醒的脑子去决定“写什么”和“怎么写”。1. 为什么一个人敢碰ERP这块硬骨头1.1 传统ERP到底难在哪ERP是企业资源计划系统的缩写听起来很学术说人话就是把销售、采购、库存、财务、生产这些公司运营环节放进一套系统里统一管理。市面上的商业ERP动辄几十万几百万实施周期按年算实施团队里有实施顾问、项目经理、开发人员、测试一堆人围着客户转。传统ERP难不是因为技术含量多高而是因为业务太乱。每个公司的流程都是“历史上自然长出来的”没有标准答案。你说库存要先进先出但实际仓管老人习惯后进先出你说订单审核要三级审批但老板不在的时候销售直接改价也要能过。一个字段要不要显示、一张报表要不要按部门过滤这些需求看起来小累积起来就是几百上千条能把人磨到崩溃。而且原来的老系统往往是“补丁摞补丁”的状态。我在接手前大概翻了翻旧代码发现一个订单状态字段居然有八种取值其中三种在界面上根本找不到入口属于历史版本遗留。这种系统你越改越深越深越乱最后就是没人敢动那几行关键SQL。这个场景做软件开发的人都不会陌生。所以当我说要“一个人重做ERP”的时候周围人第一反应都是你认真的吗1.2 AI把我焦虑的打字瓶颈直接抹平了传统开发里最耗时的是什么我自己的体感排序是写页面、调接口、造数据、改样式、写测试。这些工作技术难度不高但量非常大而且没有捷径。一个普通的库存盘点页面从表格、筛选、分页到导出Excel手动写少说也要两三天。AI介入以后这个瓶颈被直接击穿了。我让大模型生成带增删改查的页面复制进来改改字段名一个页面几十分钟就能跑起来。原来需要两天的工作量压缩到了半天以内。这不是“锦上添花”这是“质变”。当代码生成效率翻了四到五倍你就有精力去啃那些AI帮不了的东西——业务规则、数据一致性、角色权限边界。所以严格来说我不是“用AI写完了ERP”而是“AI把我从无休止的CRUD里解放了出来让我有时间把系统做成一个正常人能用的东西”。这句话才是这半年真正的心得。1.3 我的边界判断做什么不做什么一个人做ERP最忌讳的就是一上来就想覆盖所有模块。我给自己定了三条边界第一不做生产和MRP只做贸易型企业最常见的进销存加财务第二不做复杂的多组织架构只做单公司多部门第三不做移动端先把Web端做扎实。这个选择是关键的。ERP是个大概念但你要交付的其实是一套能解决具体问题的工具。我服务的这家公司业务很典型销售开单、采购入库、库房发货、财务对账。核心链路就是客户订单→库存锁定→出库单→应收款。把这条链路做顺了系统就成功了八成。剩下的考勤、工资、审批流都不要碰碰了就会陷入泥潭。这个阶段我的做法很简单拿出一张纸画出五张核心表商品、客户、供应商、订单、出入库单然后让AI帮我列出它们之间的关联关系和外键关系。AI在这个阶段的角色是“快速梳理员”它输出的字段清单很可能不完整但比我从零到第一版快太多了。2. AI在半年里实际干掉的四类脏活2.1 批量生成CRUD代码这是AI最成熟的应用也是我最初入坑的原因。一类典型的任务根据商品表结构生成完整的后端接口和前端管理页面。大模型对这个场景的完成度非常高尤其是使用主流技术栈时它几乎能把规范化的代码写得像模像样。我的工作方式是这样的先在数据库设计文档里定义好字段这个过程我会人工做AI不给主键和唯一约束拍板然后把表结构贴给AI要求它输出一套基于FastAPI的接口代码包含分页、排序、条件筛选和简单的权限校验。生成之后我做一个非常快速的人工审查然后直接丢进项目里跑。半年下来我大概统计过一个粗数整个系统四百多个接口有将近三百个是AI先写出来、我修改后上线的。剩下的接口涉及复杂的库存扣减、应收应付核销这些我不敢让AI直接写最多让它写个草稿核心逻辑我亲自来。这个比例是平衡出来的不是越激进越好。2.2 Agent把任务当成项目来编排有一段时间我不满足于“一问一答式”的代码生成开始尝试Agent工作流。所谓Agent就是给AI布置一个更完整的任务目标让它自己拆解步骤自己调用工具自己检查结果。听起来很科幻实际使用下来它的强项和弱项都很明显。我搭过一个自动生成“菜单权限—角色关联—用户分配”整套模块的Agent流程。我给出数据库表结构和角色规则让Agent先梳理需求再写数据库脚本再生成接口最后生成前端页面并且每一步都要输出检查点。结果是接口和页面生成得很顺利但在“角色继承”这个业务规则上它连续给出了三个不同方案每个方案我都得仔细判断最后我不得不终止Agent流程手工把规则写死。我的结论是Agent适合处理步骤清晰、劳动密集型的模块化任务不适合处理业务语义模糊、规则价值重的部分。你在设计AI工作流的时候一定要把“人做决策”的节点保留下来不要让AI在业务规则上自我发挥。2.3 AI当测试员和甲方这个用法大多数教程里没人细讲但我觉得特别实用。具体做法是新模块写完以后我先把接口文档丢给AI让它扮演测试工程师生成几十条测试用例包括正常流程、边界条件和异常输入。AI生成测试用例的水平已经相当不错尤其对输入校验、权限拦截这些场景它能给出很多我平时想不到的角度品。更狠的用法是让它扮演“苛刻的甲方”。我会说现在你是一个懂ERP但不讲理的业务经理请对这个订单变更流程提出十个刁钻问题。然后它就会问如果客户已经部分付款再修改金额怎么处理如果货已出库再退单怎么算库存这些问题每一次都能帮我发现流程漏洞。这套“AI对抗式需求澄清”的方法我在第三个月才算玩明白。它本质上是用AI的低成本来做以前团队里产品经理和业务方之间的需求交锋把隐性规则提前逼出来。我强烈建议每一个独立开发者都试试这个用法比让AI写一百行代码价值大得多。2.4 AI写文档和迁移脚本程序员的通病是不爱写文档但ERP系统没有文档绝对会出事故。我用AI把这块补上了每个模块开发完以后把关键代码片段和数据表结构发给AI让它生成模块说明文档和接口调用手册。AI生成的文档虽然偶尔会过度修饰但整体结构是完整的我只需要改掉细节错误。还有一个用得非常多的地方历史数据迁移脚本。旧系统里有几万条商品、客户、订单记录字段命名混乱有的是空值有的是脏数据。我让AI写一个Python脚本负责从旧库读取、清洗、转换、写入新库。这种一次性任务AI的完成率意外地高因为规则明确、目标单一。它会主动处理日期格式、状态枚举映射、外键重排这些细节我在旁边微调几次上万条历史数据一周内就迁移干净了。3. 技术选型一个人也要把地基打稳3.1 我的技术栈清单与选择理由整个系统的技术栈非常主流前端用Vue 3加Element Plus后端用Python的FastAPI数据库用PostgreSQL部署直接上Docker Compose。这个组合在2024年底到2025年初的AI大模型知识库中语料量极大意味着AI生成代码的准确率是最高的。为什么刻意选这种“无聊”的技术栈因为对一个人团队来说AI对框架的熟悉程度就是生产力。我见过有人为了炫技选了比较小众的前端框架或者自定义的ORM库然后AI生成代码的质量急剧下降每次都在各种奇怪的API上翻车。技术选型不需要“最先进”需要“大模型最擅长”。这个逻辑可能和很多追求新技术的人相反但它才是AI工程实践里真正的第一原则。如果规模再大一点我可能会后端换NestJS或者Java Spring Boot。但对于我一个人维护的系统FastAPI的自动API文档功能简直是礼物模型定义完字段Swagger文档自动生成AI可以根据接口文档继续生成前端代码这个联动效率非常高。3.2 数据设计上AI帮我省了多少事数据库设计是重做ERP最重要的一环也是最容易出问题的一环。传统做法是找一张白纸人和业务方聊需求画ER图再设计表结构。我是用对话的方式把业务规则一条一条喂给AI让它输出建表语句和关系说明。比如我描述“一张订单可以有多个明细每个明细对应一个商品要记录下单时的价格快照因为商品价格以后会变。库存扣减要在确认订单时锁定而不是下单时锁定。”AI会把这些规则拆解成字段、外键和事务边界建议。说什么“订单表存客户ID、订单状态、应付总额、已收金额”然后明细表存商品ID、数量、成交单价、快照商品名。这些设计建议大部分是合格的但“价格快照”这种字段它偶尔会漏我会人工补充。表结构定型以后我让AI统一生成SQL迁移脚本和Mock数据。它会按字段类型生成一批合理的假数据——商品名、规格、SKU、价格比如SKU编码带规则。这个环节节省了我大量手工造数的时间。整个系统的数据库从零到近百张表大约只用了一个月其中AI帮忙生成和修正的占比很高但我保留了所有主键、唯一约束和关键索引的人工审核权。3.3 部署与迭代节奏部署方案我刻意做得很简单一台云服务器Docker Compose起三个容器——前端Nginx、后端接口、PostgreSQL数据库。没有搞K8s也没有搞CI/CD流水线最多加了一个Webhook自动拉代码重启服务。原因很简单一个人维护的系统部署越复杂出问题的时候越痛苦。曾有朋友建议我上K8s说以后扩展方便。我的回答是等系统真需要扩展的时候我一个人也维护不过来K8s不如保持单体简单架构。迭代节奏方面我坚持“每两周一个可演示版本”的节奏。每个双周五下午我会把当前版本部署到测试环境截图发给业务方看收集反馈再进入下一轮。这个节奏对个人来说压力不小但好处是很少出现方向性错误。有一轮我把库存报表做得过于复杂业务方看了一眼说“我要的就是一张简单的表格”及时止损避免了白忙两周。4. 半年实操流水账4.1 第1-2个月领域建模是最重要的一个月这个阶段没有急着写代码我花了整整三周梳理业务。做的事情包括翻旧系统的操作手册、导出旧数据库的字段字典、和业务方进行三轮访谈、把核心流程用表格列出来。我一开始就意识到AI可以写代码但AI不会替我去搞清楚“这家公司到底怎么运转”。业务访谈的结果是几张流程图和几百条字段说明我把这些整理成文档逐条喂给AI让它帮我检查逻辑漏洞。比如我描述“采购入库后供应商应付款增加”AI会追问“如果入库后发现质量问题需要退货应付款怎么处理”这些问题逼着我回去问业务方提前把退换货流程敲定。到第二个月月底数据库设计文档已经基本完整我让AI生成了第一批建表脚本和项目骨架代码。这时候的代码量虽然不大但地基已经稳了。4.2 第3-4个月核心交易链路这是整个项目最累也最出活的阶段核心目标是打通“销售订单→扣库存→生成出库单→生成应收款→收款核销”这条完整的资金与货物链路。我把这条路拆成五个服务模块商品中心、客户中心、订单中心、库存中心、资金中心。每个中心独立开发AI生成CRUD代码我处理跨中心的事务与状态机。这里面最大的技术难点是库存扣减。下单和出库之间有时间差同一商品可能被多个订单同时锁定必须用数据库行锁控制并发。这个我一开始就有意识地不让AI写而自己用事务和悲观锁实现。AI参与的部分是生成库存流水表的设计、出库单和库存的联动逻辑草稿。实现完这条链路系统就已经能跑通一家公司最核心的日常运转了。我在这里尝到甜头也第一次深刻体会到链路型业务逻辑必须人来兜底AI可以给你草稿、给你测试用例但最终的“库存永远不能为负”这条铁律其业务理解才能写清楚。4.3 第5个月报表、权限与并发系统功能跑通以后接踵而至的是“报表”和“权限”这两个磨人的模块。老板要看得见数据部门经理要只看本部门的单子财务要看全部金额但有修改权限仓库只能操作出入库。这些需求在代码上不复杂关键在于“规则矩阵”要明确。我让AI生成了一张“角色×权限×菜单”的配置表然后基于这张表自动生成前后端的权限控制代码。AI做的部分是把规则转成枚举和路由守卫人工做的是定义规则本身。报表方面我选了个取巧的方案把常用报表都做成固定接口而不做拖拽式自定义报表——后者对一个人来说简直是时间黑洞。四个核心报表销售日报、库存余量、应收账龄、采购对账列出来让AI实现并用真实数据验证陈旧的“报表是ERP的灵魂”在这算是落地了。这个月还顺带做了批量导入导出。客户的Excel格式千奇百怪AI生成的解析逻辑能覆盖八成情况剩下两成我建了一个“导入错误日志”把问题行标红反馈给用户。这正是AI辅助的很好样本——它处理模式化的解析和校验我处理未知情况的兜底。4.4 第6个月真实数据迁移与试运行最后一个月基本不在写新功能而是做三件事历史数据迁移、真实业务平行运行、BUG修复。历史数据前面说了用AI写的Python脚本清洗进了新库。平行运行更费精力——新老系统同时用每天比对订单、库存和应收数字发现差异就排查逻辑。最痛苦的是“差异排查”。有一天对账差了一万块钱最后追溯到一笔三个月前的手工折扣订单在旧系统里扣了库存但没生成应收款。这种脏数据问题靠AI查不出来只能靠人对业务规则的敏感度。我翻了旧系统的日志又跟财务确认才算把这笔历史的账平掉。这一个月给我的教训是系统上线最大的风险不在代码在数据。AI能把代码写得很好但它对你公司的历史烂账一无所知。试运行期满我把老系统彻底停掉。从那一刻起这套全新的ERP就是这家公司日常运营唯一依赖的系统了。5. 踩坑实录AI生成代码时我必须盯死的事5.1 AI代码的三个通病第一是接口参数校验太弱。AI生成的代码能跑通正常流程但很少主动写严格的入参校验。客户名字传空字符串、数量传负数、日期格式不对这些情况它不会处理。我后期不得不在找AI生成代码的提示词里固定追加一句每个接口必须包含参数类型校验和业务规则校验。即使这样还是要人工抽查。第二是异常处理逻辑过于敷衍。AI在遇到错误分支时回复的思考奇偶处理。代码看起来很工整但一旦数据库超时或者库存不足它很可能只在日志里打一行字而不是抛出业务异常。公司里用户不是程序员看不到日志界面必须给出“库存不足当前可用数为10”这样可读的提示。这一条我在后期用AI当测试员揪出了二十多处。第三是事务边界经常缺失。多表写入操作如果不包事务中间步骤失败会导致脏数据。AI生成代码时对事务的使用很“看心情”有时候有有时候没有。我要求它在所有写操作里统一使用装饰器声明事务并补了一段代码规范文档喂给AI这个问题才慢慢好转。5.2 提示词驯化和代码审查这半年里我建立了一套自己的提示词模板不追求花哨但非常固定。模板长这样背景说明表结构或接口定义必须遵守的规则列表事务、校验、日志错误提示输出格式完整代码数据库迁移说明自测用例。这个模板的效果比随手提问要稳定得多。AI生成代码的行为会随着对话状态有很明显的漂移——前十分钟生成的代码质量很高聊了一个小时后可能开始偷懒省掉校验和注释。短会话、模板化提问是保持AI输出质量最实在的方法。每天下班前我会留半小时做一个“AI代码抽查”随机打开两个接口重点看异常分支和数据边界。这个习惯坚持了五个月虽然没有完全拦住所有问题但至少在两三次可能造成线上事故的边缘把问题拽了回来。5.3 常见问题速查表现象排查思路解决手段AI生成的接口调用报错但返回信息检查打印日志和异常捕获分支提示词强制补充业务错误码库存数据偶尔出现负数扣减库存无事务或没加锁手动实现悲观锁禁止AI独自写扣减逻辑报表数字和Excel对不上统计口径不一致同名字段含义不同把口径文档喂给AI让生成代码前先确认口径导入Excel偶尔闪退空行或非法字符导致解析失败AI生成行级错误收集不中断整体导入前后台字段大小写不一致前端传参命名和Python字段驼峰/蛇形不一致增加统一序列化配置AI按示例生成权限设置不生效路由守卫漏配或菜单权限未关联用AI生成权限矩阵测试用例逐个角色验证6. 半年复盘哪些事做得值哪些事没必要6.1 工作量估算与AI贡献度半年下来整个系统大概有前后端代码四五万行数据库表九十张左右接口四百多个。如果按传统方式这个量级一个三人小组至少要做一年。我单人半年完成AI的贡献率我估算在77%左右——注意这里不是“AI写的代码占77%”而是“AI帮我节省的工作量占77%”。剩下的23%是我认为AI无力承担的需求澄清、数据清洗策略、关键事务逻辑、上线后的运维判断。很多人问用AI生成代码会不会导致代码质量很烂我的实际体感是AI生成代码的平均质量比我见过的不少外包代码要高因为它很“规整”命名一致、格式化良好。但问题是AI不懂你的业务上下文它能写出一段“看起来对”的代码但真正的业务正确性必须靠人来把关。AI生成的系统测出来的BUG不会比别人手写的少但修复BUG的效率会高很多因为定位往往更准。6.2 AI帮不了的那部分代码之外这半年最花费精力的其实是“人”的问题。业务方对旧系统有一百个不满意但对新系统也有两百个担心。你得解释为什么库存报表的格式变了为什么那个用了十年的按钮被挪了位置。这些工作AI完全帮不上忙只能靠你作为一个产品的负责人去沟通。还有一件事AI帮不了就是“取舍”。需求永远是多到做不完的一个人能做的只有排序和拒绝。这半年我至少说了一百次“这个功能下个版本再做”。这种判断力不是模型能力是经验。每一次说“不”的时候你需要想清楚不做这个东西业务流程能不能照常跑。能跑就往后放不能跑就从当前优先级里挤掉别的。6.3 给想尝试的人的三条建议第一选一个足够小、足够真实的切口不要一上来就啃“ERP”三个字。你可以先做一个小模块比如进销存里的“库存盘点”把它做到能解决实际问题再考虑扩展。一个人做大型系统的核心竞争力不是“写得多”而是“想得清”。第二把AI当同事不当工具。同事要交代背景、检查产出、提出反馈。如果你只是把问题丢给AI拿答案90%的情况下你不会比AI更聪明。但如果你像带新人一样和AI协作一边验收、一边纠错、一边更新你的文档它的产出质量和稳定性会指数级上升。第三固定你的“交付物标准”。我会在项目里放一个文档写清楚代码规范、事务规定、异常处理办法、命名规则。每次AI生成代码之前先把这份文档发给它。实测下来一遍过的比例提高了不少。没有标准的团队会乱没有标准的AI协作更乱。这半年里我最深的一个体会是ERP真正难的不是那些表单和按钮而是把不确定的业务变成确定的流程。AI能帮你把一个确定的流程以极快的速度造出来但把不确定变成确定还是得靠人。如果你也想一个人挑战这种项目别把它想成“用AI开发软件”你把它想成“你带着一个无限耐心、永远不打瞌睡的实习生把一家公司的运营逻辑从头梳理了一遍”。这个实习生替你敲了键盘但方向盘始终在你手上。最后分享一个我这半年坚持下来的小习惯每周给自己留半天“不写代码”的时间专门做决策和复盘。AI负责把代码量堆起来但哪些功能重要、哪些设计要推翻、下一周做什么这些问题要靠一个清醒的大脑。把AI用好的秘诀从来不是更强的提示词而是更好的判断力。