半年前我做了个决定在公司只有我一个全职开发的情况下把跑了十二年的老 ERP 用 AI 重构一遍。当时很多人觉得这是拿职业生涯开玩笑毕竟 ERP 在企业软件里算是出了名的硬骨头——业务流程复杂、历史数据脏乱、权限模型繁琐任何一个环节出问题都够喝一壶。但半年过去系统非但没被我做死反而顺利替换了旧系统核心业务全部跑在新系统上连财务期初数据都对平了。这篇文章不打算讲太多理论就把这半年我怎么用 AI 拆解需求、写代码、控质量、做数据迁移的过程原原本本记录下来。我适合谁看两类人。第一类是中小公司里被老板点名做数字化的运维或全栈手里资源有限、被业务部门追着跑第二类是想用 AI 提效但又担心 AI 写代码失控的开发者。我会把能直接搬走的工作流、提示词思路、避坑清单全写出来也会告诉你哪些环节 AI 其实帮不上忙别被“AI 一天写完 ERP”这种说法带偏。1. 为什么一个人敢接“重做 ERP”这种硬骨头1.1 冲动的来源现有系统的问题清单先说背景。我所在的公司是一家做建材贸易和轻加工的中小型企业年流水几个亿。老 ERP 是当年外包公司用 .NET WebForms 写的数据库是 SQL Server 2008跑在 Windows Server 2012 上。它最大的问题不是功能少而是改不动报表要导出到 Excel 手工加工库存对不上账每次盘点都得几百条记录逐条核对权限几乎是摆设除了老板和财务其他人都在用一个超管账号。让我下定决心重做的导火索是那年年底的库存盘点。业务员从手机端导了一份当天库存表跟 ERP 里的账面数差了 300 多万的货值财务当场拍桌子。查下去发现原因是老系统里采购入库单和销售出库单居然没有真正关联库存流水有些单据审核和反审核还会把库存字段改乱。这种问题在外包团队手里留了十年没人敢动里面的逻辑于是恶性循环越不敢改越没人改系统越烂。所以“重做 ERP”的动机不是老板拍脑袋而是业务已经被老系统卡住脖子。你想在一个数字都没办法闭环管理的系统上面去做利润分析、做流程优化完全是空中楼阁。1.2 先盘家底这半年要交付出什么决定动手前我用一周时间把旧系统的能力边界摸了一遍。老 ERP 覆盖的模块比想象中多采购管理请购、采购订单、入库、退货、销售管理销售订单、出库、退货、应收、库存管理调拨、盘点、组装拆卸、应付应收管理、总账凭证、BOM 和成本核算还有员工考勤和工资这两个相对独立的小模块。我给自己立的目标是“半年内核心业务闭环一年内彻底割接”。核心业务定义成采购、仓储、销售、财务凭证这四个链条。考勤工资这种边界清晰但与 ERP 核心耦合不深的东西暂时用工具迁移不做重构。这个取舍很重要一个人做项目最忌讳把边界无限扩大你必须在第一天就明确什么事不做。我当时开了一张 Excel把每个模块的现状问题、涉及部门、数据的脏乱程度、业务规则复杂度全部列出来然后按“业务影响大小”和“与核心链路距离”两个维度排优先级。排出来的结论是先把库存和进销存做干净财务只做凭证对接预算、生产、成本这些通通排到二期。1.3 对 AI 的初步判断能做什么不能做什么在立项那几天我正好在重度使用 AI 编程助手。当时我已经用 AI 写了几个内部小工具比如订单明细自动对账脚本、Excel 合并工具效果都不错。但 ERP 的复杂度显然不是一个脚本能比的所以我对 AI 的能力边界做了个预判。我判断 AI 能承担的有三类第一需求分析阶段的“贴身顾问”它读过大量 ERP 实施案例能提醒很多我没想到的业务场景第二写代码阶段的“高级码农”像 CRUD 接口、基础页面、关联查询这类模式化代码AI 生成效率极高第三数据迁移阶段的“翻译官”正则清洗、字段映射、ETL 脚本这类工作AI 能大幅度提速。AI 当时明显做不到的也有三类第一跨模块的一致性设计比如库存模块和财务模块的凭证规则必须在一个大脑里统一建模AI 写单个模块时往往会自洽但两个模块放一起就对不上第二和真实业务的人去沟通你没法让 AI 替你去问财务主管“这个单据的冲销规则到底是什么”第三对历史脏数据的甄别哪些期初数据能信、哪些必须重盘只有懂业务的人才能判断。这个预判后来基本应验了。我的整体策略就是“AI 负责产出我负责判断”。听起来简单但真正执行起来半年的时间里我反复在这条线上找平衡。2. 用 AI 做需求分析和数据建模省下最多的不是写代码时间2.1 把二十年业务规则塞进提示词的尝试正式动手第一件事不是写代码而是做需求清单。过去实施 ERP 项目需求调研通常要顾问驻场几周访谈各个部门把流程画成流程图再开会确认。我一个人当然不可能干这么重的活于是想了个取巧的办法把旧系统的所有表单、菜单、报表、SQL 存储过程全部导成文本塞给 AI 当语料。我把旧系统的数据库里所有的表和字段注释导出来加上程序目录里那些报表文件的标题拼成一份两万多字的文档然后丢给大模型提示词大概是这样的你是一名有二十年经验的 ERP 实施顾问。以下是某贸易企业老 ERP 系统的菜单、报表和数据库字段清单。 请你 1. 梳理出完整的业务功能架构按采购、销售、库存、财务、基础资料分类 2. 指出哪些功能之间可能存在数据关联 3. 列出高频使用且对业务影响大的核心功能清单 4. 猜测该公司业务流程中常见的异常处理场景比如退货、冲销、反审核。这轮对话价值非常大。AI 帮我整理出来的功能架构比我自己对着旧系统点半小时菜单总结得还全。更重要的是它从字段命名上推测出很多隐含规则。比如销售出库单里有“红字”和“蓝字”两种类型AI 立刻判断这是退换货冲销的标记再比如库存表里有一个“锁定数量”字段AI 提示这可能是用于销售预占库存的逻辑建议我在新系统里单独设计预留量模型。这些事情如果靠人工读代码至少得烧掉两周。2.2 用 AI 反向提问补需求盲区需求分析这件事最怕的不是不知道做什么而是不知道自己不知道什么。做 ERP 重构时很多业务规则是藏在老员工脑子里的比如“有运费分摊的采购入库单才能做成本结算”“退货单必须在原订单审核后才能做”这种业务约束你问十个老员工十个人给你十个答案。我的办法是反向利用 AI让它扮演一个刁钻的 ERP 甲方顾问不断提问我逼我把业务规则补全。我给它画了一个框让它按采购、销售、库存、财务四个域分别提问每次问十个问题我只负责回答。比如说销售模块它问了一堆我一开始没想到的问题客户退了一部分货订单金额和已开票金额怎么联动销售出库后如果发现成本算错了还能不能反审核同一个商品有不同的批次和有效期出库时先进先出还是允许手工指定批次这些问题的答案直接决定了数据库怎么设计和代码怎么写。至少有两个问题是上线后差点出事才补上的一个是“采购入库单开票后不能直接改单价”另一个是“库存调拨是否允许调拨负数”都是 AI 在提问清单里提醒我的。所以需求分析阶段我的核心经验是不要只让 AI 给你答案更要让它给你问题。把“AI 提问—我确认—再提问”的循环跑起来需求盲区会以极快速度被填补。2.3 数据模型设计让 AI 先出草稿再手动校验外键关系有了需求清单下一步是数据库建模。我选择 PostgreSQL 作为新系统的数据库理由后面再说。建模方式我很激进直接把数据实体清单和中国式 ERP 常见表结构喂给 AI让它直接产出建表 SQL。AI 出一个数据库设计的速度确实快一分钟就能把二十多张表扔出来字段、类型、注释都齐。但我要说的是这一步恰恰是 AI 最容易“一本正经地胡说八道”的环节绝对不能直接照搬。我遇到过几个典型问题第一它生成的表之间依赖关系经常简化到缺失。比如采购入库单和采购订单本来是父子关系AI 居然把订单号直接存在入库单上作为普通字段没有真正建外键关联也不生成唯一的订单明细行号对应关系。第二很多中国业务特有的字段它不懂。比如单据编号要支持“单据类型年月流水号”这种规则AI 默认生成 GUID 主键完全不符合财务做账习惯。第三金额和数量的精度处理极易出错。ERP 里金额字段必须是 numeric(18,2) 甚至 numeric(18,4)AI 偶尔会给你 integer 或者 float这在财务上是绝对不能忍的。所以我定了一个强制流程AI 生成建表 SQL 后我手动在 ER 图工具里检查一遍所有外键关系然后以真实业务单据为样例手工走一遍从采购订单到入库单到应付账款到凭证的数据流发现断了就补建表脚本。这个流程开始觉得笨后来发现是保命用的。这样建模阶段虽然 AI 参与度极高但真正拍板的人还是我。我不需要从零设计表但我必须理解每一张表的核心字段和关联方式。等后面写代码时我才发现当初花在检查数据模型上的时间换来的是写业务逻辑时极低的返工率。3. 技术栈与 AI 辅助开发工具的选择逻辑3.1 为什么选了前后端分离加最小微服务的落地方案技术选型在一个人做重构时极其重要因为选错了根本没有足够的精力去填坑。我的选择是后端用 Java Spring Boot 3前端用 Vue 3 Element Plus数据库 PostgreSQL部署用一台 8C16G 的服务器加一个对象存储整个系统拆成四个服务gateway 网关、base 基础资料、trade 进销存、finance 财务。你没看错这算是极简微服务但拆服务不是为了分布式的爽而是为了一个人并行推进时模块之间不互相阻塞。选择 Java 而不是 Node、Go 或 Python有三个原因。第一ERP 这个领域 Java 的生态和企业信任度都是最高的将来团队扩编时招人容易第二Spring Boot 的事务管理、权限框架、报表集成都非常成熟尤其分布式事务用 Seata 在单体多模块场景下可以直接简化掉第三也是最现实的——AI 大模型的训练语料里 Java 和 Spring 相关的高质量代码最多AI 写 Java 的准确率明显高于写冷门框架。前端用 Vue 3 没有特别复杂的原因就是它够快、够稳Element Plus 的表格、表单、弹窗组件一堆适合 ERP 这种重交互、轻视觉的管理系统。我在提示词里大量让 AI 直接生成表格页面和弹窗表单这是这套技术栈下效率最高的地方之一。3.2 AI 编码工具的组合用法从 Copilot 到 Agent 模式工具层面我同时用了两类 AI 编码辅助一类是 IDE 内的代码补全工具比如 IntelliJ 的 Copilot 插件另一类是能和整个代码仓库对话的 AI Agent 类工具比如开源的 Continue 加本地模型以及可以直接读取 Git 仓库的大模型工具。这两类工具的用法完全不同。代码补全适合“我知道要写什么但不想敲键盘”的场景比如写 VO、DTO、Mapper、表单元数据字段Tab 键一路补下去效率翻倍。Agent 类工具则适合“我不知道这个 bug 出在哪”或者“这个需求要动哪些地方”的场景它能把整个项目的依赖链条读出来给我一个修改方案。我的日常开发节奏是这样的拿到一个需求比如“采购入库单审核后生成应付暂估凭证”我先用 Agent 工具扫描现有代码里入库单的状态机、凭证生成接口、会计科目配置表让它给我一份修改计划确认后我再让 Agent 直接改代码改完让 Copilot 补全剩余的 import 和 setter最后我自己做一次 CR 审查。这里有个很重要的细节Agent 改代码时我要求它必须遵循我写在项目根目录 CLAUDE.md或 AGENTS.md里的约束文件比如“所有金额操作必须在 Service 层使用 Spring 事务注解禁止在 Controller 直接操作 Entity所有软删除字段必须统一”。这个习惯保证 AI 生成代码的风格和项目一致后续维护才不会痛苦。3.3 一套可复用的“AI 结对编程”工作流半年跑下来我沉淀了一套不管换什么 AI 工具都适用的“AI 结对编程”工作流拆成六个步骤需求拆分把一个大需求拆成半小时到两小时能完成的小任务比如“新增采购退货单页面支持选择原入库单并冲减库存”。约束注入在每个任务开始前把相关的业务字段、状态枚举、权限要求写进提示词避免 AI 自由发挥。AI 生成让 AI 生成详细方案和代码重点要求它说明改动涉及哪些文件、哪些接口会被影响。逻辑走查我对照需求一步步走读代码不看细节格式只看状态流转和临界值有没有问题。自动测试让 AI 生成对应 JUnit 测试覆盖正常路径和异常路径跑通后再提交。复盘归档每天收工前把当天踩到的坑和 AI 犯的典型错误整理成一个 markdown 文件作为后续提示词的反面示例。这套流程一开始很费时间尤其是第五步让 AI 写测试经常要调好几轮。但坚持两周后代码质量肉眼可见地提升。到后期 AI 生成的代码已经能直接过掉一半的单元测试我的 CR 负担大大减轻。4. 实打实的开发节奏三个月写核心两个月补业务一个月搬家4.1 第一阶段用 AI 快速搭起采购、销售、库存闭环我把半年拆成三个大阶段。第一个阶段是前三个月目标是打通采购、销售、库存的基本闭环也就是能录单、能审核、能查库存、能对账。这个阶段是工作量最大的也是 AI 发挥最猛的时候。我给自己定的策略是“垂直切片”不是按照“先把采购模块全部做完再做销售”的水平铺开而是把一条端到端业务链切成一节节做。第一刀切“采购订单到采购入库到库存增加”第二刀切“销售订单到销售出库到库存减少”第三刀才切“库存查询和库存流水”。每个切片都用上一节说的工作流推进。你会发现 AI 在这种垂直切片模式里特别舒服因为任务边界清晰上下文很短生成代码的准确率高。我统计过这个阶段单周最高能完成两个半切片或者说是把三张主表加六张子表加几十个接口加三个页面都写完这个速度放半年前不敢想。库存模块是这个阶段最关键的。我反复让 AI 检查两件事一是库存流水是否是不可变的任何增删改都必须通过流水进行禁止直接 update 库存表字段二是并发扣减是否有行锁保护。下面是 AI 在第三轮提示词下写出来的扣减库存代码核心我认为这种才是能上线的写法Transactional public void deductStock(Long skuId, int qty, String bizType, String bizNo) { Stock stock stockMapper.selectBySkuIdForUpdate(skuId); // select ... for update if (stock.getAvailableQty() qty) { throw new BizException(库存不足可发数量 stock.getAvailableQty()); } stock.setAvailableQty(stock.getAvailableQty() - qty); stockMapper.updateById(stock); stockLogService.recordLog(skuId, -qty, bizType, bizNo, true); }看到forUpdate之后我松了口气。如果 AI 一开始给的版本没有锁上线后碰到两个业务员同时抢最后一件货系统铁定超卖。这种并发问题靠肉眼审查很难发现靠 AI 审查反而更靠谱因为你可以在提示词里明确要求“必须考虑并发安全”。4.2 第二阶段财务和权限的部分AI 的辅助方式完全不同第二阶段是第四、第五个月重心是财务凭证和权限模型。这阶段写着写着你会发现AI 的辅助方式跟前三个月完全不一样因为它不再只是帮你写代码而是要理解一套严谨的账务逻辑。财务模块是 ERP 里最容易让新手翻车的地方。我的做法很土把财务那边的凭证规则整理成一张表每条规则对应一个 AI 提示词。比如“采购入库单审核时借方科目挂原材料/库存商品贷方科目挂应付账款-暂估金额取入库单的不含税金额凭证日期取审核日期”。然后我让 AI 在代码里严格实现这张规则表不允许自由发挥。AI 生成凭证的逻辑成也快、败也快。有一次它把“冲销凭证”的状态字段搞反了导致红字回冲的时候借贷方向颠倒差点把当月财务报表给做错。从那以后我对 AI 生成的财务代码增加了一个硬性要求必须写一个独立的规则说明文件把每个凭证类型对应的借贷方向、科目编码规则、金额来源全部放进去代码里只允许引用这个文件里的规则。这等于给 AI 上了一道紧箍咒。权限模型也是深水区。老系统的权限形同虚设新系统我不想做成每个按钮都配权限的沉重框架但基础的角色和数据范围隔离必须有。我让 AI 生成了基于 RBAC 的权限体系用户归属角色角色配置菜单权限和数据权限数据权限精确到“只能看本部门单据”。为了让 AI 不把权限逻辑写散我要求所有查询接口都走一个自定义的DataScopeInterceptor从当前登录用户的部门隔离数据。这个设计很老套但它稳定。4.3 第三阶段报表和旧数据迁移AI 最能体现价值的环节最后一个月是旧数据迁移和新报表开发。很多人低估迁移的难度其实它比写新系统更耗人。旧系统有大约三十万条历史单据、上百万条库存流水而且还有大量历史垃圾数据。按老规矩我先用 AI 生成了一套数据迁移方案核心思路是“不追求把垃圾数据也搬过去只迁移干净且业务需要的核心数据”。比如客户、供应商、商品资料、期初库存、未结清单据这五类必须迁而历史凭证以总账期初的形式合并成一条初始化记录不进明细。迁移过程 AI 的作用大了去了。旧系统的编码规则、计量单位、客户名称混乱程度堪称灾难莲特么“XXX 公司”和“XXX 有限公司”是两条客户记录。这种脏数据清洗我用 AI 写了大量的 Python 脚本规则也非常直接先用正则做标准化再用相似度匹配做合并最后让业务员抽查人工确认。如果没有 AI光这些清洗规则我就能写一个月。迁移后校验也用了 AI。我让 AI 帮忙生成了一批对账 SQL分别校验“商品SKU数量一致”“期初库存金额等于明细汇总”“未结销售订单都有对应客户”然后让财务拿老系统导出的报表手工核对几个关键科目的期初数。这个过程不可跳过因为数据的一致性直接决定新系统能不能上线。我印象特别深的是两套系统对于“含税单价”和“不含税单价”的存储思路完全不一样迁移时稍不留神金额就差了 13% 的增值税校验脚本救了我一命。5. AI 生成代码的坑看起来对跑起来崩上线前更吓人5.1 幻觉型代码生成的函数与真实业务规则冲突这半年时间里AI 生成代码最大的问题不是语法错误而是“幻觉型对错”。也就是说代码本身能编译、能跑、单测能过但业务逻辑是错的而这种错误往往隐藏得很深。举一个真实案例。我们有一个业务规则销售订单的折扣不能超过商品资料里设置的最高折扣率除非当前登录用户是销售总监。AI 第一次生成校验逻辑时把“销售总监”的角色判断写成了“用户所在部门是销售部”。结果就是销售部的普通员工也能享受总监权限业务员发现后截图发到群里场面一度很尴尬。我复盘了一下这类错误的原因是 AI 对业务规则的理解来自提示词但提示词里我们没有把“角色”和“部门”这个差异讲清楚。所以后来我给 AI 下任务时涉及权限和审批流的逻辑都会把对应的数据模型字段、枚举值原样贴进去比如明确写“用户表中 role_code 字段值为 SALES_DIRECTOR 时才有审批权限部门只用于数据范围过滤”这样才有效减少幻觉。另外一个让我印象深的坑是 AI 生成报表 SQL 时会把指标口径搞错。比如“本月销售额”它写成“本月单据金额合计”完全没过滤已作废单据和未审核单据。这种指标错误最可怕因为数学上完全正确但业务上一看就是错的。解决办法也很土每个报表 SQL 必须附带一句口径描述由我在 CR 时逐一核对。5.2 灾难级的 SQL 与并发更新问题第二类坑集中在数据库层面。AI 生成 SQL 时对老 DBA 才会关注的细节经常忽略。举几个典型第一索引缺失。AI 生成的联表查询经常没有合适的索引数据量一上来就是慢查询。我有一次上线前压测一条销售出库列表接口居然跑了四秒多原因就是查询条件有客户编码和单据日期但表上完全没建联合索引。从那以后我要求 AI 在生成迁移脚本时必须根据 WHERE 和 JOIN 条件补索引。第二更新语句没有锁。前面说的扣库存就是典型。AI 刚开始生成的代码是三步操作先查库存、再判断够不够、再 update中间没有任何锁并发情况下必然出问题。我后来改成先select for update再判断再更新才堵住这个漏洞。第三分页和排序的坑。老系统里有“按审核日期倒序”的习惯AI 生成分页查询时会默认按主键倒序而主键是自增的雪花 ID 时排序结果和审核日期完全不同。这种细节不抓业务员会疯掉。为了防止这些坑反复出现我在项目的.cursorrules文件里写了一堆数据库约束比如“所有 update 必须包含事务”“所有涉及金额字段禁止使用浮点类型”“所有列表查询必须走分页插件且指定排序字段”。AI 每生成一次代码都会读这些约束这种把经验沉淀成规则文件的做法比每次改写提示词强十倍。5.3 对 AI 代码的审查机制我一个人怎么做到一个人做项目最容易被问的问题是“你自己写的代码你自己能审出什么毛病来”尤其是在 AI 辅助下代码量翻了几倍CR 成了纯体力活。我的答案是分层审查第一层让 AI 审 AI第二层让测试来兜底第三层靠真实数据说话。所谓“让 AI 审 AI”就是让 Agent 工具去读另一个模型刚生成的代码专门找业务逻辑错误。我会在提示词里告诉它“只关注状态流转、金额计算、权限校验和并发安全其他格式问题不用管”。这个办法不能指望它抓出所有 bug但至少能过滤掉大概三四成的基础错误。第二层是单元测试和接口测试。说句掏心窝子的话AI 写代码不写单测等于白写。我要求所有 Service 层核心方法必须配套单测尤其是库存扣减、凭证生成、反审核这三大高危区。AI 写单测的痛苦我从第二周就开始承受但后面发现单测写得越细AI 的代码越规矩因为每次改代码跑一遍测试错误当场就暴露了。第三层也是最硬核的——拿真实历史单据做回归。我在测试环境里导入了三个月的历史真实单据然后写了一套自动回归程序把新系统的计算结果和老系统导出的结果做差比对任何差异都会产生一条告警。这个方法帮我在上线前抓到了至少五个“看起来没问题但实际账对不上”的 bug其中最严重的一个是采购退货红字冲销时没有把采购入库单的累计退货数量加回去导致后续采购建议全部算错。6. 半年之后的复盘哪些收益是真的哪些是幻觉6.1 效率提升的真实估算写代码快了三倍但不是十倍如果有人问 AI 让一个人做 ERP 的效率提升了多少我的答案不是网上常说的“十倍”而是——综合算下来大概三倍。写作层面确实有十倍的感觉尤其生成重复性 CRUD 页面和接口时原来一天写五个接口AI 辅助后一天二十个不是梦。但项目整体不只是写代码还有需求分析、方案设计、业务沟通、数据整理、测试验收这些 AI 帮不了太多的事情。而且 AI 造成了一个隐性成本它生成的代码里任何一个小 bug都可能因为量大而被放大。如果你独自完全信任 AI 输出省下的时间很快会在返工里还回去。我的真实体感是AI 把“从零到基本可用”的时间压缩到了原来的三分之一但“从基本可用到稳定上线”的时间几乎没有压缩因为现实世界的业务复杂度不会因为代码生成得快而变简单。这个结论其实挺重要的。我对 AI 的效率判断从“崇拜期”进入“工具期”开始像看待一个熟手外包一样看待它来得快但质量参差必须验收它能承担巨大的编码量但替代不了你对业务的理解和对质量的责任。6.2 ERP 这个领域AI 替代不了什么提到 AI 重做 ERP 的局限性我最有发言权。我踩过最惨的坑是在财务模块有一回 AI 生成了科目辅助核算的代码逻辑自洽我 CR 时也没发现问题直到财务月末结账时发现科目余额表少了一段辅助账那张报告让财务室恨了我整整三天。这背后的本质是 ERP 不只是一个软件系统它是企业管理的制度映射。同一个“供应商”字段在采购模块它只是一个文本在应付模块它就涉及账期、税率、付款条件在成本模块它又会影响存货计价。这种跨模块的语义一致性AI 很难自己意识到。因为它默认只看着当前任务在写代码不具备全局的“企业运营视角”。所以我越来越清楚在 ERP 领域 AI 替代不了三样东西第一对复杂业务规则的全局理解第二和业务部门沟通、确认规则、处理需求冲突的能力第三为上线后的数据质量兜底的判断力。这些能力并没有因为 AI 发达就变得不值钱反而更值钱了。因为有了 AI 之后你不再需要花大量时间暴力写码这些“人的判断”成了唯一的稀缺资源。6.3 后面的路这套半成品应该怎么演进半年到了核心链路已经上线旧系统在上线一周后正式关停。接下来的演进路径我也在琢磨目前有三条明确的主线。第一条是把 AI 的能力从“写代码”延伸到“运维与复盘”。我现在会把每天的慢查询日志、接口报错信息定期丢给 AI 分析让它给出索引调整建议和异常模式归纳。这东西还比较粗糙但至少能让我从看一天的日志堆里解脱出来。第二条是把财务和成本的精细度往上走。现在成本是按移动加权平均算的业务部门将来一定会要求按订单批次来核算那才是真正的硬骨头。我到时会用同样的方法让 AI 先出方案和模拟数据我再人工校验结果。第三条是给公司内部做 AI 赋能。系统里大量积压的文档、客户问询记录、单据备注我们准备用大模型做自动摘要和知识检索。这块虽然不属于 ERP 核心但它是提高整个组织效率的最快路径也是我能从“代码工具人”真正转型成企业数字化顾问的一次机会。我经常跟圈里人开玩笑说半年时间我用 AI 把自己变成了一个带 AI 外包团队的部门。这个团队的成员只有一个我以及随时待命的几个模型我管它叫“一人外包”。但团队里最重要的一条规则从我第一天定下就一直没变过AI 可以写一百行代码但最后签字的那个印章永远只能握在人手里。