做一套自己的ERP，是我多年的念想。不会写代码，模型再清楚也只是模型。AI来了，这个念想成了真。如今系统已跑进内测，采购、生产、销售单据能自动生成凭证。本文分享开发中踩过的四个大坑，希望后来者少走弯路。

做一套自己的ERP，是我很多年的念想。

我是计算机专业出身，操作系统、数据库、软件工程都学过，但毕业之后基本没正经写过代码。

早年不是没动过做ERP的念头，是压根动不了手。脑子里有蓝图，键盘前一个字敲不出，念头就只能停在念头。

工作后倒是跟ERP越缠越深，先参与过多家大型企业的数字化项目，后来进了一家国产ERP公司，再后来去了四大会计师事务所。

一圈走下来，项目里见过的业务流程、财务勾稽、上线前的那些乱仗，慢慢在我脑子里长成了一套ERP系统模型。

业务怎么流，凭证怎么生，我心里是有图的。报表最后怎么平，反而不是最难想的事。可图归图，落不了地。不会写代码，模型再清楚也只是模型。

AI来了，这个念想成了真。

如今这套东西已经跑进内测，采购、生产、销售的单据能自动生成记账凭证，凭证滚成科目余额，余额再吐出资产负债表和利润表。

更妙的是，我把几个核心模块抽象成了MCP，每个MCP里几十个工具，背后就是ERP的功能接口，往WorkBuddy里一配，对话就能查库存、开采购单、拉利润表。

我不想把它写成那种一路开挂的故事，聊点每一步都踩过坑，有些坑踩得我想把代码全删了重来。过程摊开，能帮后来者少绕两步就值了。

最早动手那阵，我把最多的精力花在界面和流程上。按钮怎么摆，字段怎么联动，折腾半天觉得这才是真功夫。真写下去才发现，那些都是次要。

真正的枢纽是业务单据怎么变成会计语言，采购入库得记存货和应付，生产领料是把材料转去在产，销售一确认收入和应收就跟着来。三种业务动作，背后是三套借贷逻辑。我第一版让各模块自己出凭证，谁的业务谁算，各算各的。

很快就崩了，科目余额对不上，采购说应付是这个数，财务说余额是那个数，谁都觉得自己对。后面想了想，我把架构换了，所有模块不再自己出凭证，只产生业务事件，一套集中的凭证引擎来翻译。

每种单据类型配一套科目映射规则，采购入库单进来，引擎按规则借存货、贷应付，库存一动凭证自动带出。销售一确认，引擎带出收入和应收。所有凭证写进同一张科目余额表，资产负债表和利润表只是这张表的投影，只读不写。

业财一体化的本质，不是把财务模块和业务模块拼在一起，而是一条从业务动作到会计语言的翻译管道。翻译规则要集中、要可配置，别散落在各模块自说自话。

后面无论加什么模块，只要往引擎里挂一套映射，凭证自己就出来了，不用再求财务帮你对账。

框架这关过了，下一坑则在模型上。

代码是AI写的，但模型这块我犯过一个错，前期图新鲜，这个模块让A模型出，那个模块让B模型写，心里盘算着各取所长，强的干强的活。结果惨，A写的接口风格和B差很远，命名、结构、错误处理全是两个脾气。改A的时候牵动B，B改完A又报错，代码改过去改过来，bug比功能多。

更隐蔽的是让不同模型接力改同一段逻辑，前一个写的上下文，后一个接不上，按自己理解重写一遍，逻辑直接混乱。你看着每段都像那么回事，拼起来跑不通，定位问题时特别折磨，因为每段单独看都没错。

试了一圈模型，最后定在GLM5.2上。整个项目从头到尾一个模型出代码，风格统一了，改起来心里有底，哪里接哪里断脑子里有数，遇到混乱的地方也是同一个模型的思路，续得上。

我现在回看，个人拿AI做东西，最忌贪心，一个模型顺手，比三个模型加起来聪明管用。这条早懂半年，能少删好几万行代码。

版本管理是另一坑。

开头那些天，我没正经用Git，或者用了也不规范，文件靠日期命名堆在文件夹里，什么最终版、最终版2、真最终版、真最终版不改了。一次大的重构把凭证引擎核心逻辑改崩了，想回退，发现没有干净版本，只能重写。

这种事不止一次，每次重写都是两三天积累打水漂，更伤的是心气，重写到第二遍你已经开始怀疑这东西到底做不做得出来，关键还要消耗Token。

后来老实上了Git，每个阶段开一个分支，主分支只进验证过的代码，feature分支上随便造，改崩了切回去十分钟的事。还养成个习惯，每天收工前把当天稳的推进主分支，不稳定的留在分支里过夜。

没有版本纪律的个人项目，等于在悬崖边写代码，你以为省事，实则随时可能把积累清零。一个人开发更要守，因为没人帮你兜底，崩了就是真的崩了。

等系统真能跑起来，我又栽在MCP化上。

传统ERP靠菜单和表单，点来点去，我嫌笨也嫌慢，把采购、生产、销售、财务几个核心模块各包成一个MCP，每个MCP里几十个工具，背后是一个功能接口。从查库存、建采购单到出利润表，每个动作都拆成了一个独立工具。配进WorkBuddy，对话里说一句查下某物料还有多少，工具就调了，不用开界面。

工具粒度也是磨出来的，太粗，一个工具干十件事，对话分不清意图。太细，几十个工具长得像，调用方也懵。最后按业务动作切，一个动作一个工具，命名直白，对话才好懂你要什么。

但MCP化埋的坑最隐蔽。

最初我把一些计算逻辑放在接口外层，想着前端顺手就算了。金额小计、税额、单据汇总放前端算，系统自己跑没事，因为前端那层会执行。可对话式调用不一样，对话层只传参数、拿结果，不跑前端那层计算。于是数据算错，凭证金额对不上，报表里的数跟业务对不上。

这个坑最难查。界面里一切正常，点开单据数字是对的，只有对话调出来是错的。我对着同一笔业务，界面看一遍，对话拉一遍，两个数不一样，愣了半天。

做了一次接口升级。所有业务计算无论多小一律收进后端接口，前端和对话层只负责传参和展示，不碰任何算账的事。又加了一道后端双重校验：同一笔数两套路径各算一遍，不一致就拦下，不让它进凭证，等于给数据上了双保险。

这之后数据才真正稳了，对话里查出来的数，和界面里看到的，和报表里汇的，终于是一回事。

MCP接口必须是全后端的，前端算过的账，对话一调就蒸发。接口的每一处计算都要经得起被对话直接调用，因为对话不会替你补任何前端逻辑。某种程度上，对话式操作倒逼我把接口想得更干净，这倒是意外的收获。

做了这趟，我有个判断，AI松开的是写代码的缰绳，没松开想清楚业务的缰绳。好多人以为AI能替他把系统想明白，其实AI只替他把系统写出来，想明白那部分还是他自己的事。这中间的空当，就是坑。

这四个坑没一个一次过，每一次重来都带代价，时间、心气、还有对着屏幕怀疑自己的那些时刻。

说到底，AI给的是体力，判断还是得自己来，它没让开发变轻松，只是让一个人也撑得起企业级软件的体量。代价是每一步都得自己拿主意，没人帮你踩刹车。

那个做了多年的念想，现在在内测里跑着，它不完美，模块还要磨，报表还要调，对话偶尔还听错我的意思。但它真的会，自己出资产负债表了。