让传统 ERP 走进移动端

一套已经运行五年的 ERP，业务仍在正常运转，却没有移动端。员工只能回到电脑前处理采购，手机上直接打开 PC 页面，导航、表格和操作按钮挤在狭窄的视口里，几乎无法使用。

真正棘手的并不是“把页面缩小”。这类遗留系统往往缺少完整文档，而熟悉它的人也可能已经离职，这就像是一个黑盒，难以修改。一个看似简单的移动端需求，背后连接着采购订单、审核、采购入库、库存查询，以及一整套不能被破坏的状态和数据关系。

我们让 Seed-2.1-pro-0915 接手这项改造：从旧系统源码、PC 端操作录屏和三张手绘草图出发，理解真实业务，再为它增加一条可用的移动端路径。

最终，模型在不改动原 PC 页面和登录流程的前提下，完成 1 个移动端入口和 3 个业务页面，新增 9 个产品代码文件，并产出业务流程、开发规格和任务清单 3 份过程文档，走通“移动端下单—PC 审核—采购入库—库存查询”的完整链路。

【待插入视频】

不是重做一套 ERP

案例基于开源项目 jshERP 2.1。项目包含约 28 万行代码，使用 Spring Boot、MyBatis、jQuery、EasyUI 等技术，采购相关操作长期依赖 PC 端完成。

不需要提供完整的产品需求文档，也不用给出已经整理好的接口清单，只需要旧系统源码、PC 端采购业务的操作录屏，以及采购订单、采购入库、库存状况三张移动端草图。

草图只呈现目标界面，录屏只记录操作过程，源码则保存着真正的业务规则。模型需要把三者拼在一起，回答一组在遗留系统改造中最关键的问题：订单如何保存、由谁审核、状态如何变化、入库怎样关联原订单、库存又从哪些接口汇总出来。

在 TRAE 中完成开发，基础环境如下：

开始前需要准备：

• ERP 仓库源码及项目规则文件；
• 采购订单、采购入库、库存状况三张移动端草图；
• 覆盖新建订单、PC 审核、采购入库和库存查询的操作录屏；
• 可登录的测试环境，以及供应商、商品、仓库和结算账户等基础数据。

先使用 docs/erp.sql 初始化测试数据库，再运行 mvn spring-boot:run。确认测试账号能够登录，并且采购订单、采购入库和库存状况三个 PC 页面都能正常打开。

随后用 TRAE 打开项目根目录，上传 PC 端操作录屏和三张移动端草图，再粘贴下面的提示词：

请综合已上传的 ERP PC 端操作录屏、三张移动端草图、当前仓库源码和可运行的测试环境，完成“采购订单 → PC 审核 → 采购入库 → 库存状况”的移动端 Web 闭环。

1. 先读取 AGENTS.md 及项目规则，保留已有修改。完整查看录屏和草图，并在浏览器中复现旧流程。沿“操作与页面 → Network 请求 → 前后端源码 → 数据与后续查询”建立证据链，不得猜测接口、字段、状态或业务规则。草图决定目标体验，旧系统行为和源码决定业务事实。

2. 明确订单初始状态、PC 审核后的状态变化、采购入库与源订单的关联方式，以及库存查询条件和结果。

3. 编码前生成 business-flow.md、spec.md 和 issues.md 三份中文文档，分别记录业务流程、开发规格和可独立验证的任务；自行检查一致性后继续开发。

4. 采用增量改造：复用 ERP 现有 Session、接口、字段、状态、技术栈和构建方式；移动端页面、样式和脚本放在独立目录中。不修改原 PC 页面、菜单和登录流程，不引入新框架，也不新增未经证据确认的接口、状态或计算规则。

5. 按草图实现移动端入口、采购订单、采购入库和库存状况页面，覆盖编辑、只读、加载、错误和保存结果等实际状态。使用浏览器结合 Network、Console、DOM 和服务端源码持续调试；以 390 × 844 为主视口，并在 360–430px 宽度范围内检查横向滚动、遮挡和不可触达操作。

6. 使用测试账号和可恢复的测试数据完成闭环验收：移动端创建订单，PC 审核后移动端同步状态并进入采购入库，入库正确带入源订单数据并保存，库存结果可与 PC 端按相同条件核对。

先理解业务，再开始写代码

Seed-2.1-pro-0915 没有一上来就生成页面。面对约 28 万行源码和录屏，它先制定执行计划，再让多个子 Agent 分别检查相关代码、录屏和运行中的页面；随后通过浏览器、源码交叉验证，逐步还原完整业务链，生成业务文档。

在这条链路中，移动端新建采购订单后，单据进入未审核状态；PC 端完成审核后，状态变为已审核；采购入库通过 LinkNumber 关联源订单，保存后再推进源订单状态；库存状况则需要沿月份、仓库、商品和合计接口继续查询。

这些字段和状态不能凭经验猜测。模型把核对后的结果整理为业务流程、开发规格和任务清单三份过程文档，让后续实现建立在可复查的业务事实之上。

这一步把一次模糊的“做个手机页面”，转换成了可以执行和验收的工程任务：哪些能力复用旧接口，哪些状态必须保持一致，哪些页面只读，哪些操作需要回到 PC 端完成，都有了明确边界。

理解业务后，Seed-2.1-pro-0915 选择了增量改造。新的移动端入口、样式和脚本集中放在独立目录中，复用原 ERP 的登录 Session、接口、字段和状态，不直接改写原有 PC 页面。

在具体功能上，采购订单页负责新建和保存；采购入库页承接已审核订单，并带入供应商、关联单号和商品明细；库存状况页则按仓库与月份展示库存和合计。

真正接入旧接口后，第一版页面很快暴露出遗留系统中常见的问题：请求方法与预期不一致、字段大小写不同、响应层级变化、查询参数隐含依赖，部分接口直接返回 500。根据源码逐项修正假设，而不是在前端伪造一套绕开旧系统的数据。

从能打开，到走通采购闭环

页面完成后，模型按照真实业务顺序完成了四步验收：

1. 1. 在移动端新建并保存采购订单，确认单据进入未审核状态；
2. 2. 在 PC 端完成审核，再回到移动端确认订单状态已经同步；
3. 3. 从已审核订单进入采购入库，核对供应商和商品明细等源订单数据后保存；
4. 4. 选择相同的仓库和月份查询库存，并与 PC 端结果进行核对。

验收不仅看页面是否“像草图”，还检查真实数据能否保存、订单状态能否同步、关联单号能否正确传递。模型同时在移动端显示方式下检查横向滚动和布局，并对原有 PC 页面进行验证。

在复测中，“移动端下单、PC 审核、采购入库、库存查询”能够按顺序完成；新增页面接入了旧 ERP 的业务数据和状态流转，原有 PC 审核节点也得到保留。

从手绘草图到真实页面，改变的不只是界面尺寸。新的移动端页面已经接入旧 ERP 的业务数据和状态流转，原有 PC 审核节点也被完整保留下来。

不只是生成三个页面

在这次任务中，从制定计划、理解业务到实现和验证，Seed-2.1-pro-0915 不单单是交付了结果，更重要的是，它展示了一条更适合遗留系统的改造路径：先从操作、页面和源码中恢复业务知识，再把业务逻辑沉淀为规格和任务，最后进行增量实现，并用真实运行结果反复修正。

对于大量仍在运行、却缺少文档和维护人员的旧系统，这种能力的价值不只是“更快写代码”，而是把散落在代码和操作中的知识重新组织起来，让系统具备继续演进的可能。

真正让旧系统重获新生的，不是重新画一套界面，而是先把它重新理解一遍。