先交代一下我们公司的SAP组织架构在原有架构中公司代码CM05是一个财务核算主体它下面设置了工厂C050。这里的“公司代码”可以简单理解为财务核算主体“工厂”则是具体开展生产、收发货业务的组织。今年2月为了实现不同工厂之间的独立核算我们又新增了公司代码CM15并在CM15下面设置了C051、C052、C053三个工厂同时启用了SAP多级评估功能。简单理解就是同一笔业务可以在不同核算层级下分别记录和分析成本让工厂之间的经营结果划分得更清楚。这项调整不只是增加几个组织编码。原来服务于“公司代码CM05—工厂C050”这套组织关系的公司间采购订单接口也需要识别新增的“公司代码CM15—工厂C051/C052/C053”并根据实际发货工厂从正确的核算主体读取成本、发票或条件价格。CM15上线时我们因此在原接口上增加了相关取价分支。运行一段时间后财务同事在核对一张涉及CM15的公司间采购订单时发现其中一个行项目的价格和预期不一致。这里的公司间采购订单可以简单理解为集团内部不同公司之间调拨或采购货物时生成的订单。我们公司的这类订单不是由用户在 SAP 里手工逐行录入而是由接口自动创建。接口拿到供应商、收货工厂和物料后还要根据发货工厂、物料类型和价格来源自动带出价格。所以财务说“这张订单的价格不太对”时我真正需要确认的并不是某个公式有没有算错而是接口创建订单时到底把哪个工厂当成了价格来源又走进了哪一条历史分支。从这条业务反馈开始我没有把Codex只当成一个“帮我写ABAP”的工具而是让它参与从系统分析、业务确认到开发验证的整个过程。这次最大的变化不是 Codex 帮我写了几段代码而是它先通过 ADT 读取系统、梳理现有逻辑再把复杂分支整理成飞书确认文档。我拿着文档和业务确认确认清楚后再进入开发最后仍由我负责更新代码、测试和上线。下面这张图先把整篇文章的处理过程放在一起问题从哪里产生Codex参与了哪些环节以及哪些决定仍由人来完成。一、先看懂组织架构CM05、CM15和四个工厂分别是什么这套接口原本服务于公司代码CM05下的C050工厂并已经形成一套相对成熟的取价逻辑。不同物料、不同买卖方向会分别使用标准成本、库存成本、外部采购发票或者特殊价格条件。新增公司代码CM15以及其下的C051、C052、C053三个工厂后我们本来的设计方向就是参考“CM05—C050”这套稳定运行的框架再根据CM15下属工厂和新增交易方向做适配。真正的难点不是“多加一个公司代码”而是要把成熟逻辑准确映射到新的组织结构每一种交易方向都要先识别实际发货工厂再决定价格应该从哪个核算主体读取。下面这张图是我后来重新整理的历史逻辑。它不仅是追溯旧代码的依据也是这次完善CM15逻辑时的重要参考框架。由于当时上线节奏比较快中间版本先用标准成本和采购发票等相对简化的规则覆盖了主要场景没有把不同交易方向、物料类型和实际发货工厂的组合完全细分。程序能够支持新业务运行但在部分场景下价格来源还不够精确最终被财务在订单核对中发现。中间版本的详细流程图我没有放进本文。它对开发留档有意义但对普通读者来说需要先理解大量已经被替换的过渡规则反而会把“为什么出错、后来怎么完善”这条主线冲淡。这里记住一句话就够了参考成熟逻辑的方向没有问题只是第一次落地还没有把CM15的场景拆得足够细。二、以前我会先翻代码这次我先让 Codex 把问题说清楚以前碰到这类问题我一般会先翻代码、调试、查表再把自己理解到的逻辑整理出来找业务确认。问题也能解决但代码分支一多我很容易在历史逻辑、新增逻辑和业务反馈之间反复切换。沟通时如果缺少一份大家都看得懂的材料很多问题还要来回解释。这次我没有一上来就让 Codex 改代码而是先告诉它先不要修改。通过 ADT 读取测试系统里的当前接口再对比历史版本和现有说明。先把价格相关的分支、数据来源和仍需确认的地方梳理清楚。Codex 随后做了几件事通过 ADT 读取测试系统中的当前接口和相关对象而不是只看本地旧源码对比当前版本、历史版本和已有说明确认哪些属于原逻辑、哪些属于新增场景把一句“价格不对”拆成实际发货工厂、物料类型、价格来源和异常处理四类问题再回到测试和生产系统做只读核对验证主数据映射、成本层级和现有代码是否一致。这一步给我的帮助不是“马上得到答案”而是先把事实、推断和待确认事项分开。比如系统里同一份成本数据可能存在不同货币或评估层级如果只是看到一条记录就拿来用代码表面上能跑结果却可能并不是业务要的那一层。三、Codex 把技术分支整理成飞书文档我再拿去找业务确认代码看明白以后我没有直接开始开发。Codex 通过飞书 CLI把四个业务方向、不同物料对应的价格来源、缺失数据时的处理以及本次明确不修改的历史范围整理成了一份飞书开发说明书。这一环对我很重要。代码里的IF、ELSEIF和表字段业务用户通常不关心他们真正需要确认的是谁卖给谁实际发货工厂是哪一个成品、半成品和原材料分别取什么价格价格取不到时是回退到成本还是必须报错停止这次调整会不会影响原有工厂已经稳定运行的逻辑。Codex 把这些内容从代码语言转换成流程图、表格和确认问题我再拿着这份文档跟用户逐项确认。用户补充口径后Codex继续更新同一份文档直到里面不再保留“待确认”“可能”“建议”等过渡内容最终变成可以直接用于开发和留档的说明书。这比我直接拿代码找用户沟通有效得多。业务确认的是业务结果开发看到的是可以落地的判断条件后面即使再回头看也能知道当时为什么这样改。四、确认完成后再开发代码仍然由我来更新和把关等业务口径确认完成后我才让Codex进入开发阶段。现在的Codex在具备相应权限时已经可以通过ADT直接连接SAP并修改源码。但这次涉及公司间订单取价和采购主数据更新接口影响范围比较大如果让AI直接写入或激活一旦修改边界判断不准确风险会被立即带进系统。因此我没有开放写入模式而是选择了一种更稳妥的人机协作方式。Codex根据最终说明书把修改范围拆成几个明确的代码区段告诉我每一步应该定位哪里、删除哪一段、插入什么逻辑以及修改后应该和哪一段原代码衔接。我先检查它给出的修改方案再由我手动更新到SAP。我按照这个顺序逐段更新接口代码每完成一部分再让 Codex 继续检查下一部分。这样做有两个好处一是不会为了修改新增场景把原来已经稳定运行的逻辑一起重写二是每一步都有清晰的起止位置出现问题时更容易回看。整套分工可以概括成Codex负责读取、拆解、生成修改方案和检查我负责业务判断、用户确认、代码复核以及实际更新。它帮我减少了重复翻资料和漏看分支的时间也保留了核心接口修改前必要的人工安全闸门。五、回 SAP 验证时顺着错误分支又发现一个隐藏风险代码更新后我没有只测试“订单能不能成功创建”。我按正常场景、价格数据缺失、多行项目和异常分支分别准备了测试组合并逐项核对实际发货工厂、价格来源、采购信息记录和最终订单结果。顺着错误分支继续检查时还发现了一个容易被忽略的问题如果一张多行订单的后续项目取价失败整张订单最终没有创建成功前面已经准备好的采购信息记录也不应该继续更新。否则就会出现订单没有建成相关主数据却先被改变的情况。正常流程跑通时看不出来只有沿着错误路径完整走一遍才会暴露。最后确认的处理方式是任意一行取价报错就返回错误不维护采购信息记录也不创建采购订单。这个结论同样被补进了开发说明书和最终流程图中。六、最终留下的不只是一段代码下面这张图是完成业务确认、代码调整和测试复盘后整理出的最终版本。它和前面的历史图放在一起正好能看出这次工作的起点和终点历史逻辑告诉我原程序为什么会形成现在的结构最终逻辑明确了新增场景应该按实际发货工厂和物料类型怎样取价原有工厂及其他稳定逻辑保持不变入口控制、异常返回和主数据更新边界也被一起补齐。对我来说这次 AI 真正帮我完成了四类工作环节Codex 的作用我负责的事情现状分析通过 ADT 读取代码、对比版本、梳理分支判断分析方向确认读取范围业务确认生成飞书说明书、流程图和确认清单带着材料找用户确认最终口径开发修改按确认结果生成分段修改方案并检查衔接复核并更新 SAP 接口代码测试复盘整理测试组合追踪正常和错误路径执行测试判断是否满足上线条件以前这些事情我需要自己在代码、表数据、聊天记录和业务说明之间来回整理。现在 Codex 可以先把材料变成结构化成果我再基于这些成果做判断和沟通。这也是我现在理解的“AI SAP ADT”更实际的用法不是让 AI 替我做最终决定而是让它参与从问题梳理、文档确认到开发验证的完整闭环。人的责任没有减少但很多重复、容易遗漏的工作确实可以交给它先完成。下一篇我还会继续记录真实 SAP 工作中Codex 和 ADT 能帮我解决哪些问题以及哪些环节仍然必须由人来把关。