从通用 ERP SaaS 到垂直行业系统：一次工程复用实践总结
见字如面，与大家分享实践中的经验与思考。
上一篇文章里，我主要分享了自己如何使用 AI 从 0 到 1 做一款 ERP SaaS 产品，包括产品商业化、多端建设、权限体系、业务流程、数据能力以及 AI 工作流等内容。
做完第一个项目之后，我并没有马上重新从空白目录开始第二个项目，而是基于第一个 ERP 项目沉淀下来的工程结构、通用能力和文档规范，继续推进了一个垂直定制项目。
这个项目不是简单做一套新的进销存系统，而是在原有 ERP 的基础上，面向总部和合作商的经营模式，把商品供应链、会员 CRM、课程消课、财务对账等业务放到一套系统里。
接下来，我会复盘一下整个过程：一个已经跑起来的企业级项目，到底有哪些东西可以复用？哪些东西不能简单照搬？AI 在这个过程中适合做什么？又有哪些地方仍然需要人工判断？
背景
个人开发的 ERP SaaS 做到后期，已经进入稳定迭代阶段，也逐渐沉淀出了一套企业级系统的基础能力。
比如后端服务、PC 管理端、小程序端、企业权限、菜单配置、数据字典、商品管理、采购销售、库存流转、导入导出、经营报表、订阅体系，以及围绕这些能力形成的一整套开发规范和 AI 协作流程。
这些东西第一次做的时候很慢，因为很多问题都需要边做边想：目录结构怎么定，权限颗粒度怎么拆，接口规范怎么统一，前后端怎么协作，AI 生成的代码怎么 Review，复杂业务怎么拆成可以交付的任务。
在和一位客户老板沟通后，我决定基于现有 ERP SaaS 项目做一次垂直化改造。于是我先回头梳理第一个项目里已经沉淀下来的东西，再判断哪些可以继续使用，哪些需要裁剪，哪些需要重新设计。这一步不是马上写代码，而是先把已有项目里可以复用的部分梳理出来。
如果想要看项目运行的演示，可以查看视频版本：
<插入视频号地址>
01 为什么不从零开始
企业级系统有一个很明显的特点：不同业务看起来差异很大，但底层有很多基础能力是重复的。
比如账号、组织、角色、权限、菜单、日志、数据字典、基础资料、导入导出、报表、审批、配置等能力，几乎每个企业系统都会遇到。只要项目进入真实业务场景，这些基础设施迟早都要补齐。
第二个项目虽然是垂直定制，但它同样需要登录、权限、菜单、商品、客户、订单、库存、报表和操作留痕。这些能力在第一个 ERP 项目里已经经过了一轮真实业务验证，所以第二个项目没有必要完全重写，而是可以优先复用已有工程底座。
当然，不从零开始并不等于直接复制。企业系统最麻烦的地方就在于：基础设施可以复用，但业务结论不能照搬。
有些代码看起来能搬过去，但背后的业务假设可能已经不成立。如果没有重新判断边界，很容易把第一个项目里的复杂度带到第二个项目里，最后反而增加维护成本。
所以我在第二个项目里做的第一件事，不是让 AI 写代码，而是先梳理已有资产，再判断它们在新项目里是否仍然适用。
02 第一个项目留下了什么
第一个 ERP 项目留下来的，不只是某几个页面或者某几段代码，而是一套相对完整的工程组织方式。
首先是工程结构。 后端按 DDD 思路做了分层，同理前端也尽量按照类似的分层思想组织代码。这样做的好处是，功能越来越多之后，代码不会完全散掉，AI 生成代码时也有比较明确的落点。
其次是通用能力。 比如用户、角色、权限、菜单、数据字典、系统配置、基础资料、导入导出、报表等模块。这些能力在不同项目里会有差异，但基础模型和实现方式有很高的参考价值。
第三是业务经验。 ERP 项目里涉及商品、采购、销售、库存、单据流转、应收应付等业务。它们不一定能直接搬到第二个项目里，但在做领域建模、状态流转、数据一致性和业务边界拆分时，之前的经验是有帮助的。
第四是文档规范。 包括 PRD、DDD、ADR、specs、接口规范、编码规范、AI Rules 等。这些文档不是为了好看，而是为了让自己和 AI 都能更快理解项目上下文。
最后是 AI 协作流程。 从需求澄清，到领域建模，再到任务拆解、代码生成、Code Review 和人工验证，第一个项目里慢慢形成了一套相对稳定的节奏。第二个项目启动时，这套流程比单纯复制代码更重要。
03 复用不是复制
我发现最重要的事情不是“哪些代码能搬过去”，而是“哪些能力在新项目里仍然成立”。
有些能力可以保留，比如登录、权限、菜单、基础资料、导入导出和报表。有些能力需要裁剪，比如订阅、支付、自助开通、套餐限制等 SaaS 商业化能力。第二个项目更偏定制交付，并不需要一开始就保留完整的 SaaS 商业化链路。
还有一些能力需要重新建模。
这个项目里最典型的变化，就是从单纯的进销存，扩展到了总部-合作商模式，以及进销存和 CRM 消课的一体化。
这也是它和通用 ERP 最大的区别：通用 ERP 主要围绕企业内部经营流转，而这个项目要同时处理总部、合作商、会员和课程权益之间的关系。
原来的 ERP 里，商品、采购、销售、库存是核心业务。但在新的项目里，还要考虑合作商向总部订货、总部出库发货、商品资料同步到分店、本地差异化定价等流程。
这些能力可以借鉴原来的采购销售模型，但不能直接把原来的流程复制过去。因为这里多了总部和合作商之间的协同关系，也多了数据隔离和权限边界。
另一个变化是 CRM 消课。
会员、课程、权益卡、消课流水、退款对冲，这些都不是传统进销存里的概念。它们可以和 ERP 里的客户、销售、财务发生关系，但不能简单塞进原来的商品和库存模型里。
比如会员购买课程后，需要授予课程权益；后续每次消课，都要扣减权益次数或者有效期；如果发生退款，还要追溯原来的权益卡和消课记录。它们看起来也有“订单”和“流水”，但背后的业务含义和进销存不一样。
所以这次复用过程中，我更关注的是边界判断：哪些属于通用工程能力，哪些属于原项目业务逻辑，哪些只是阶段性实现。
AI 可以辅助整理和迁移，但边界判断仍然需要人先完成，这也是前期最花时间的部分。
下面是新项目的一小部分业务模型示意图：
04 AI 在这次迁移里做了什么
在第二个项目里，AI 的作用和第一个项目有些不同。
第一个项目更多是从 0 到 1，很多时候要让 AI 帮忙生成初稿、探索方案、补齐页面和接口。
第二个项目里，AI 更多承担的是工程复用过程中的辅助工作。
第一步，我会先让 AI 读取旧项目结构，整理已有模块和边界。
比如哪些模块属于通用支撑能力，哪些模块和进销存业务绑定比较深，哪些地方只是历史阶段的实现。这个过程不一定一次就能整理准确，但可以节省不少人工梳理时间。
第二步，是让 AI 基于旧项目文档生成新项目的 PRD、领域模型、ADR 和 specs 初稿。
这些内容不能直接使用，但很适合作为讨论基础。复杂业务先有一版可修改的文档，比直接面对空白文档要轻松很多。
第三步，是处理重复迁移工作。
比如调整包名、目录结构、接口命名、DTO、页面骨架、基础 CRUD、列表页、表单页、详情页等。这类工作边界比较清楚，只要规范给得足够明确，AI 的效率很高。
第四步，是辅助 Review。
比如检查代码是否符合既有分层，接口命名是否统一，文档和实现是否一致，有没有明显遗漏。中间也可以让不同 AI 工具互相 Review，再由我做最后判断。
但我不会把核心判断完全交给 AI。
比如总部和合作商的数据边界、会员权益的扣减规则、退款对冲的业务链路、核心领域模型设计，这些仍然需要人工参与。页面和接口生成得快，不代表系统设计就是对的。更容易出问题的，往往是业务状态、数据一致性、权限边界和异常流程。
所以我现在使用 AI 的方式会更克制一些：先把问题定义清楚，再让它执行；先让它生成可 Review 的结果，再决定是否进入下一步。
05 我的几点体会
这次实践之后，我对工程资产复用有几个比较直接的感受。
第一，复用前要先划边界。
哪些是通用能力，哪些是原业务逻辑，哪些是当前项目暂时不需要的能力，要先分清楚。
第二，文档是 AI 理解项目的重要上下文。
AI 能不能准确理解项目，不只取决于代码，还取决于有没有清晰的 PRD、领域模型、接口规范和任务说明。
第三，复杂业务不能只靠页面生成。
列表页、表单页、详情页可以交给 AI 快速生成，但业务状态、数据一致性、权限边界、异常流程还是要先设计清楚。
第四，可复用的不只是代码。
目录结构、命名规则、接口风格、异常处理、权限模型、Review 流程、任务拆解方式，其实都属于工程资产。
第五，垂直定制和标准 SaaS 的重点不一样。
标准 SaaS 更关注自助开通、套餐、支付、配置化和规模化复制；垂直定制更关注具体场景、交付效率和完整流程。
这些经验都不算复杂，但只有做过第二个项目之后，感受才会更明显。
最后
对开发者来说，AI 确实可以显著提高开发效率。但如果每个项目都从零开始，很多经验很难沉淀下来。
从更长期的角度看，每个项目结束后留下什么，可能比某一次生成了多少代码更重要。
如果一个项目能沉淀出清晰的工程结构、通用能力、文档规范和协作流程，那么下一个项目就不必重新从空白开始。
这也是我做第二个项目时最大的体会：AI 不只是帮我更快完成当前项目，也让我开始重新思考，如何把一个项目变成下一个项目的基础。
附录
新项目的一些截图，做了脱敏处理。
欢迎关注公众号"Eric技术圈"，原创技术文章第一时间推送。