企业官网建设流程全解析

半年前我做了个决定：在公司只有我一个全职开发的情况下，把跑了十二年的老 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 结对编程”工作流，拆成六个步骤：

1. 需求拆分：把一个大需求拆成半小时到两小时能完成的小任务，比如“新增采购退货单页面，支持选择原入库单并冲减库存”。
2. 约束注入：在每个任务开始前，把相关的业务字段、状态枚举、权限要求写进提示词，避免 AI 自由发挥。
3. AI 生成：让 AI 生成详细方案和代码，重点要求它说明改动涉及哪些文件、哪些接口会被影响。
4. 逻辑走查：我对照需求一步步走读代码，不看细节格式，只看状态流转和临界值有没有问题。
5. 自动测试：让 AI 生成对应 JUnit 测试，覆盖正常路径和异常路径，跑通后再提交。
6. 复盘归档：每天收工前，把当天踩到的坑和 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 可以写一百行代码，但最后签字的那个印章，永远只能握在人手里。