夜雨聆风想象一个场景。
你是企业的 ERP 顾问。客户甩过来一份需求："工单上要加 5 个栏位，还要改批次选料的逻辑，替代料那块也要动。"
你打开源码目录，两个文件映入眼帘：asfi301.4gl，10,091 行；asfi301_sub.4gl，4,363 行。合计 14,454 行 Genero 4GL 代码。
你打算花多久？
传统流程下，答案是两到四周。读操作手册、读数据字典、逐行读源码、人工比对差异、定位客制点、写需求确认书——每个环节都是体力活。
而这次，借助 AI，我们把这个数字压缩到了两个小时。
这不是概念验证，不是 PPT 故事。这是我们真实做过的项目记录，以下是完整复盘。
一、困局：顾问的两周
先说清楚传统流程到底慢在哪里。
一份 ERP 客制需求，从拿到客户需求到产出可签字的需求确认书，传统路径长这样：
📊 差异分析耗时对比
瓶颈在三个地方：
第一，代码量大。一个工单维护程序就 14,000 行，而一个中型 ERP 项目可能有 500 个这样的程序。顾问不可能逐行读完。
第二，语言断层。客户需求用的是业务语言（"我要按批次选料"），操作手册用的是功能语言（"工单单身维护作业"），源码用的是技术语言（i301_s()、sfa26）。三层语言之间需要人工翻译，而翻译错了，后面全错。
第三，定位精度差。传统方式能告诉你"这个功能在 asfi301 里面"，但无法精确到"改哪个函数的哪一段"。到了开发阶段，程序员还得再翻一遍源码。
"顾问最贵的不是时间，是注意力。把注意力花在翻代码上，是对资源的浪费。" —— 某资深 ERP 项目经理 |
二、破局：AI 读 Genero 4GL
第一步，让 AI 读源码。
Genero 4GL 不是主流语言，ChatGPT 之类通用工具对它的支持有限。但有一个被忽视的优势：Genero 4GL 的结构化程度极高。SCREEN 段、FUNCTION 段、REPORT 段分块清晰，函数命名遵循严格的前缀规范（i301_ 开头表示工单维护相关函数），注释中大量保留鼎新标准的异动编号（MOD-XXXX、FUN-XXXX）。
这意味着 AI 不需要"理解"4GL 的语法细节，只需要做结构提取——找出所有 FUNCTION 定义，按命名前缀分类，建立"函数→职责"的映射表。
实际操作中，我们用 AI 做了以下几件事：
# Step 1: 提取所有函数定义 FUNCTION i301() # 总入口，建立窗口 FUNCTION i301_menu() # 主菜单循环 FUNCTION i301_a() # 新增 FUNCTION i301_u() # 修改 FUNCTION i301_b() # 单身维护 ★核心 FUNCTION i301_s() # 替代料处理 ★客制高发区 FUNCTION i301_q() # 查询 FUNCTION i301_aps() # APS排程 FUNCTION i301_ef() # EasyFlow签核 FUNCTION i301_mes() # MES整合 ... # 共提取出 64 个主程序函数 + 36 个子程序函数 |
AI 自动完成了函数分类，并绘制出了完整的程序架构图：
📐 asfi301 源码架构全景
| |||||||||||||
|
图 2：asfi301 源码架构全景 —— 64+36 个函数，自动分类
🔍 关键发现 AI 在扫描源码时发现了一个被忽视的细节： |
这一步的产出是一张完整的"函数→职责"映射表。顾问拿到的不是 14,000 行代码，而是一张100 行的结构索引，每个函数名后面跟着它做什么、涉及哪些表、是否是客制高发区。
三、实战：从源码到需求确认书
源码结构清楚了，下一步是映射客户需求。
客户提了 5 个栏位需求。传统做法是顾问凭经验猜"大概改哪个表"，然后用 aooi999（栏位设置作业）逐个确认。AI 的做法不同——直接去源码里找答案。
具体来说，AI 检索了 asfi301.4gl 中所有 sfbud（单头自定义栏位）和 sfaud（单身自定义栏位）的使用情况，发现：
sfbud01 | ||
sfbud02 | ||
sfbud03~04 | ||
sfbud05 | ||
sfbud06 | ||
sfaud01 | ||
sfaud02 |
这张表的价值在于：它不是"建议"，而是基于源码事实的结论。每个栏位的"已使用/未使用"状态，都是从代码中实际检索出来的，不是顾问猜的。
映射关系一目了然：
图 3：需求栏位到源码字段的映射关系
💡 为什么这是"低风险客制"？ 全部使用 |
最终，AI 基于以上分析，自动生成了一份完整的《工单栏位客制需求确认书》，包含栏位分配方案、涉及源文件清单、修改要点和注意事项。顾问只需要审核确认，不需要从零撰写。
四、深水区：批次与替代料的四重耦合
如果故事到这里就结束，那只是一次"AI 帮忙填表格"的经历。真正的考验在后面。
客户追加了四条需求，每一条都不简单：
⚠️ 客户的四条追加需求 1. 单身【批次】栏位可以调整，用批次选择材料，替换默认带出的 BOM 料件。 2. 批次选择时，按属性过滤——相同属性、类似属性的料件才能被选到。 3. 选择后，自动更新取替代逻辑，单身取替代的栏位要联动调整。 4. 取替代后，【去替代】按钮的子程序也要同步处理批次数据。 |
这四条需求不是独立的，而是一条因果链：需求 1 改了输入方式 → 需求 2 给输入加了过滤 → 需求 3 要求输入结果联动替代逻辑 → 需求 4 要求反向操作也要同步。
AI 的工作方式是：先从源码中定位到替代料处理的核心函数 i301_s()（约行 6996-7700），然后逐行分析其逻辑流程：
# i301_s() 替代料处理核心流程（简化版） FUNCTION i301_s() # 1. 开窗选择被替代料 CALL q_img('old_part') # 2. 从 bmd_file（替代档）读取可替代料件 SELECT bmd04, bmd07 FROM bmd_file WHERE bmd01 = g_sfa[l_ac].sfa27 AND bmdacti = 'Y' # 3. 计算库存、在途量、需求 # 4. 输入替代数量 # 5. INSERT 替代料记录 (sfa26='S') # 6. UPDATE 主料记录 (sfa26='3', sfa05 减少数量) # 7. 更新转换率 sfa28 END FUNCTION |
分析完成后，AI 给出了每个需求的修改方案，精确到函数和代码段：
i301_b() | |||
i301_b()i301_s() | |||
i301sub_r1() |
⚡ 最大不确定因素 需求 2 中的"属性"到底存在哪个表？是 AI 能定位到代码的每个角落，但无法替客户回答"你的业务属性存在哪里"。这正是人机协作的边界。 |
五、反思：AI 能做什么，不能做什么
做完整个项目复盘，我们得出了一个清晰的结论：
📊 AI 与顾问的能力分工
|
| |||||
图 4：AI 与顾问的能力分工边界
有一个被反复验证的教训：AI 最大的盲区不是技术能力，而是"参数 vs 代码"的判断。
TOPGP 这类 ERP 系统，大量功能不是代码实现的，而是参数表控制的。一个"完工方式不同"的需求差异，可能根本不需要改代码——只需要在 sma_file（系统参数表）里改一个配置项。但 AI 只看代码，看不到参数表里的值，于是会误判"标准功能不满足，需要客制开发"。
这就是为什么我们坚持：AI 输出的客制清单，必须经过顾问审核才能签字。AI 的角色是"结构化挖掘 + 快速检索 + 自动出报告"，判定权永远在顾问手里。
🔄 三层语言对齐问题 整个过程中最容易出错的是"语言翻译"——客户需求用的是业务语言（"按批次选料"），操作手册用的是功能语言（"单身维护-批次栏位"），源码用的是技术语言（ 这不是风险，而是长期存在的天花板。AI 可以逼近它，但无法突破它——因为业务语言的模糊性是本质属性，不是技术可以消除的。 |
六、写在最后
这次实战最大的收获，不是"省了多少时间"，而是发现了一个新的工作模式。
传统模式下，顾问的时间分配是这样的：
AI 把顾问从"翻代码"和"写文档"中解放出来，让他们把注意力集中在真正有价值的地方——理解客户业务、设计方案、控制风险。
这不是替代，是赋能。
"14,000 行代码，AI 用 2 小时读完了。但它读不懂客户说'类似属性'时脑子里在想什么。所以，我们还需要顾问。" —— 实战复盘 |
下一步行动建议：如果你也是 ERP 从业者，不妨拿一个自己熟悉的模块试试——让 AI 读一遍源码，看看它能不能比你更快地画出函数地图。如果能，说明这条路值得走下去。
毕竟，代码不会说话，但 AI 可以替它翻译。
