TaoToken 是把 Codex 接到统一 API 的一个入口打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 YOUR_API_KEY再把 ~/.codex/config.toml 里的 base_url 指向 https://taotoken.net/api然后让它去核对 EBS Form 里 import_list 那一大段 PL/SQL。这两件事看着八竿子打不着——一头是 Oracle EBS 的 Form 开发一头是 AI 编程助手的通道配置——但实际做起来就是一件事你手上那段挂在 WHEN-NEW-FORM-INSTANCE 上的 List 初始化脚本细节密集、肉眼容易看漏交给一个每次都能完整读完上下文的模型逐行对比自己在 Forms Builder 里反复编译、反复点开 List 数选项快得多。EBS 的 Form 里List 型 ITEM 原则上不该把值写死在属性面板上。写死的后果很直接业务加一个状态值你得改 Form、编译、打补丁、走发版流程更麻烦的是测试环境改了、生产忘了改两个环境的下拉选项对不上业务人员提工单你能查半天。所以常规做法是先在 Lookups 里定义一套快速编码再让 import_list 这类过程在 Form 启动时从 fnd_lookup_values_vl 里把数据捞出来用 clear_list 清空、用 add_list_element 逐项塞进去。真正卡人的地方就集中在这几个过程的调用顺序和过滤条件上——顺序差一点点界面就是一片空白条件写宽一点点列表里就混进别的 lookup_type 的值。1. import_list 这段脚本卡人的地方到底在哪1.1 从 WHEN-NEW-FORM-INSTANCE 到 add_list_element 的调用链先把整条链路摊开。用户打开 FormForms Runtime 触发 WHEN-NEW-FORM-INSTANCE这个触发器里调用 import_listimport_list 内部打开游标 csr_status游标从 fnd_lookup_values_vl 里按 lookup_type 取数接着 clear_list 把目标 List 的全部旧选项清掉最后 FOR 循环逐行调用 add_list_element用一个自增的 l_index 当列表下标。原始的写法大致是这样PROCEDURE import_list IS CURSOR csr_status IS SELECT flv.lookup_code, flv.meaning FROM fnd_lookup_values_vl flv WHERE flv.lookup_type CUX_CM_XXXXXXX ORDER BY flv.lookup_code DESC; l_index NUMBER : 1; BEGIN clear_list(BLOCK.ITEM); FOR l_rec IN csr_status LOOP BEGIN add_list_element(BLOCK.ITEM, l_index, l_rec.meaning, l_rec.lookup_code); l_index : l_index 1; EXCEPTION WHEN OTHERS THEN NULL; END; END LOOP; END import_list;add_list_element 的四个参数位置感和直觉不太一样第一个是要操作的 List 全名形如BLOCK.ITEM必须大写、必须和 Form 里的块名项名对得上第二个是列表下标从 1 开始且必须连续第三个才是用户在界面上看到的标签通常取 meaning第四个是选中后真正传到:BLOCK.ITEM里的取值通常取 lookup_code。第三和第四个参数一旦颠倒界面上显示的就会是一串编码取值反而成了中文名称后面程序判断状态时全部落空。1.2 clear_list 和 add_list_element 谁先谁后这一段是审查时最值得盯的地方。clear_list 必须在任何 add_list_element 之前执行而且要放在游标循环外面。原因不复杂clear_list 是整体清空它不认下标只认 List 名。如果顺序反了先 add 再 clear前面加进去的选项会被一次性抹掉用户看到的还是空列表如果 clear_list 被写进循环体里那么每加一项之前先把前面所有项清掉最终 List 里只剩最后一条。还有一种更隐蔽的情况import_list 被调用两次。比如开发时图省事既在 WHEN-NEW-FORM-INSTANCE 里调了一次又在某个 Block 级的 WHEN-NEW-BLOCK-INSTANCE 里调了一次。第一次执行完List 有 N 项第二次如果没有先 clear就会在 N 项之后继续从 1 开始加Forms 对重复下标的处理结果各版本略有差异表现上可能是选项翻倍也可能是下标覆盖两种都很难从界面上一眼看出来。让 Codex 读脚本时把这个过程可能被调用几次一起告诉它它才会顺着这个角度去查。1.3 fnd_lookup_values_vl 的过滤条件容易写偏不少脚本的问题不在 PL/SQL 语法而在那个 WHERE 条件。fnd_lookup_values_vl 是个视图它在基表 fnd_lookup_values 之上已经加了一层约束当前会话语言对应的那几行、以及 enabled_flag 为 Y 的行。也就是说你写WHERE lookup_type XXX拿到的是已经过滤过一次的结果。坑点有三个。第一lookup_type 的大小写和拼写必须和 Lookups 定义里完全一致自定义的编码一般带CUX_前缀写成CUX_CM_XXXX少一个字符结果就是零行而且不报错。第二如果这个 lookup_type 被多个应用视图共用那么同一份数据会在不同应用下被解析出不同的含义这时候应该补上view_application_id条件把它限定到当前 Form 所属的应用而不是让所有应用共用一份结果。第三ORDER BY lookup_code DESC是按编码倒序看起来最新定义的在最前面但业务上想要的顺序往往和编码顺序没关系这一条要拿实际数据核对不能想当然。提示vl 视图只保证语言和启用状态这两层过滤像生效日期区间这类业务约束视图本身不一定替你处理需要结合你的 lookup 定义方式判断。这一条正好可以交给 Codex 帮你把业务语义一起过一遍。2. 用 Codex 审脚本之前先把 Base URL 换到 TaoToken2.1 打开统一入口拿 Key顺手把模型 ID 记下来先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 YOUR_API_KEY。同一个后台里有个模型广场你要跑的那次审查用哪个模型就在那里选把模型 ID 原样抄下来。不要自己拼模型名也不要凭印象加日期后缀——模型广场上当时列表里没有的 ID写进配置就是白跑一趟。这一步顺手把两件事记清楚Key 只显示一次复制完就存到密码管理器里模型 ID 抄完整包含前缀和后缀。后面配置文件里出现的YOUR_MODEL_ID就是替换成你抄下来的那串。2.2 ~/.codex/config.toml 里写死 model_provider 和 base_urlCodex 的配置走 TOML不认环境变量那一套 ANTHROPIC_* 的写法别把 Claude Code 的模板搬过来。在用户目录下找到或新建~/.codex/config.toml写成这样model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat几个要点。model_provider的值要和下面方括号里定义的那个 provider 名一致写错就等于没配。base_url是填进工具里的接口地址末尾不带 /v1也不要写成带 UTM 的官网首页地址那两个是不同用途——落地页给人点接口地址给工具填。env_key是告诉 Codex 去哪个环境变量里读密钥变量名自己定但必须和下面 export 的完全一致。wire_api这一项按你所用 Codex 版本支持的取值填常见是chat如果版本不支持这个键删掉这一行也不会影响 base_url 生效。密钥不落在配置文件里放到 shell 环境export TAOTOKEN_API_KEYYOUR_API_KEY想让它长期生效就写进~/.bashrc或~/.zshrc然后重新打开一个终端或者 source 一下。Key 永远从 TaoToken 的控制台创建别从别的地方抄一份来用。2.3 起 Codex确认它真的走了兼容通道配置改完在任意目录下敲codex先问一句和 EBS 无关的问题探路比如让它解释fnd_lookup_values_vl和fnd_lookup_values的关系。能正常回话说明 base_url 和 Key 这一层已经通了如果直接报 401八成是env_key的值和你 export 的变量名对不上或者你在新开的终端里忘了 export。这时候不用急着去查脚本先把通道这一层确认干净再进正题。3. 让 Codex 逐条核对 import_list 的三处细节3.1 第一轮只放 clear_list 与 add_list_element 的顺序问题审查最忌讳一次问太多模型容易给你一份什么都对又什么都没用的总结。第一轮只做一件事——把脚本贴进去明确限定输出范围下面是 EBS Form 里由 WHEN-NEW-FORM-INSTANCE 调用的 import_list 过程 目标 List 是 BLOCK.ITEM。请只回答三个问题不要重写整个过程 1) clear_list 的位置是否必须位于 FOR 循环之前写出理由 2) add_list_element 的四个参数依次是什么第三和第四个参数如果写反 界面上看到什么、程序取值拿到什么 3) 如果 import_list 在一次 Form 会话中被调用两次会发生什么。这样问的好处是答案可以直接对照。如果它说 clear_list 可以放循环里那这份回答本身就有问题可以追问放循环里第二项开始会发生什么如果它准确指出参数顺序和重复调用的后果这一轮的结论就可以直接拿去比对你的脚本。3.2 第二轮把 lookup_type 和视图条件单独拎出来问第二轮换一个角度只谈数据源。把 Lookups 里那段定义的截图或描述一起给它重点问三件事当前这个 lookup_type 命名是否和 Lookups 定义严格一致是否需要补view_application_id来区分共用同一个 lookup_type 的不同应用视图ORDER BY lookup_code DESC是否真的符合界面上的呈现顺序。这一轮可以要求它给出一份改写后的 WHERE 子句但不要让它替你连库执行。它给的是文本落库的动作由你在 SQL*Plus 里做见下一节。顺带可以让它列一个自查清单比如零行返回时依次排查哪几项方便你固化下来当团队规范。3.3 第三轮WHEN OTHERS THEN NULL 到底吞掉了什么那段内层异常处理是整个脚本里最容易被忽略的一行。WHEN OTHERS THEN NULL的意思是add_list_element 如果抛异常静默跳过继续下一轮。它保护了 Form 不被中断代价是把问题藏了起来——某一项没加进去List 就少一项而 l_index 已经自增过了下标序列出现断点更麻烦的是业务上表现为某个状态选不到而你从界面上完全看不出是加项失败还是数据本身缺失。让 Codex 评估这段异常处理的取舍并给出替代写法。合理的改法通常有两种一是异常里写入日志表或者调用消息机制把出错的 list_index 和 lookup_code 记下来方便事后查二是干脆不在这一层兜把异常抛到上层统一处理让问题在测试阶段就暴露出来。选哪种取决于你们团队的运维习惯但静默 NULL基本可以判定为不可取。4. 拿 Codex 的结论回本地验证4.1 在 SQL*Plus 里单独跑一遍游标模型给的 WHERE 子句是不是对的用数据说话。打开 SQL*Plus连上你的 EBS 数据库把游标里的 SELECT 单独跑一遍SELECT flv.lookup_code, flv.meaning, flv.enabled_flag, flv.language FROM fnd_lookup_values_vl flv WHERE flv.lookup_type CUX_CM_XXXXXXX ORDER BY flv.lookup_code DESC;如果返回零行换个角度查基表去掉语言过滤看看数据到底存不存在SELECT lookup_code, meaning, enabled_flag, language, view_application_id FROM fnd_lookup_values WHERE lookup_type CUX_CM_XXXXXXX ORDER BY language, lookup_code;把两次结果贴回对话里给 Codex让它对比着看比只贴一个查不到要有效得多。注意这条查询由你在本地 SQL*Plus 里执行工具只负责生成和解释 SQL不替你连生产库。生产环境上跑之前先用测试库确认。4.2 在 Forms Builder 里确认 List 的取值是 meaning 还是 codeSQL 能查出行不代表 List 里就是对的。编译并运行 Form让 WHEN-NEW-FORM-INSTANCE 走一遍然后打开那个 List 往下拉看显示的是中文名称还是一串编码。选中其中一项在对象导航器或者调试窗口里看:BLOCK.ITEM的实际值——如果显示是中文、取值却是中文那第三第四参数就是反的如果显示是编码、取值也是编码说明 meaning 那一列本身取的就是 code要回头查 lookup 定义里这两列是怎么填的。这一步一定要在测试库里点一遍。List 型 ITEM 的行为和它的属性设置强相关光看代码推断容易漏掉读一致性列表项映射这类属性带来的差异。4.3 几类别扭的现象对照着查现象优先怀疑的对象先看哪里List 打开全空lookup_type 拼写或语言过滤4.1 的 SQL 是否返回行显示编码、取值是名称add_list_element 参数顺序反了第 3、4 个参数选项重复或翻倍没先 clear_list或过程被调用两次clear_list 是否在循环外、调用点有几个少了几项但界面无提示WHEN OTHERS THEN NULL 吞了异常临时改成抛异常复现换了环境选项变少两个库的 Lookups 数据没同步对同一 lookup_type 做行数比对对照表用起来比逐行读代码快尤其是接手别人写的 Form 时先按现象缩小范围再用 Codex 去解释具体那一小段。4.4 Codex 这一侧的配置类报错只查这几项通道层的报错就那么几个。401 基本都是环境变量没生效echo $TAOTOKEN_API_KEY先确认变量有值再确认env_key写的名字和它一致。模型不存在的报错一般是model那一行抄错了回模型广场核对当时的列表。如果请求发出去了但返回的内容很怪检查base_url是不是被多加了个/v1——接口地址就是 https://taotoken.net/api末尾不带版本号。5. 审查做完回控制台把这次调用对上账5.1 用同一把 Key 发一条消息确认链路没串在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错、额度还在。然后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 看这次的调用记录有没有记上——如果你刚跑的是比较长的脚本审查这里的用量会比随手问一句高出不少顺手对一下心里对成本有个数。5.2 接着往下走的两件事短期只是偶尔查脚本模型对话页够用如果打算天天把 Form、PL/SQL、报表逻辑往 Codex 里丢Coding Plan 里挑一档更划算不用每次担心额度。Key 相关的事都集中在 控制台 API Keys需要新开一把给同事用、或者轮换旧 Key都在这里操作。最后留一个习惯每次让 Codex 读完 EBS 脚本把它给的结论落到你本地能执行的 SQL 或者 Form 运行验证上能跑通再写回代码。模型说得再顺最终还是要 Forms Runtime 那一遍编译和 SQL*Plus 那一次查询来签字。
EBS Form List 初始化脚本，把 Codex 的 Base URL 改到 TaoToken 后查 clear_list
TaoToken 是把 Codex 接到统一 API 的一个入口打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 YOUR_API_KEY再把 ~/.codex/config.toml 里的 base_url 指向 https://taotoken.net/api然后让它去核对 EBS Form 里 import_list 那一大段 PL/SQL。这两件事看着八竿子打不着——一头是 Oracle EBS 的 Form 开发一头是 AI 编程助手的通道配置——但实际做起来就是一件事你手上那段挂在 WHEN-NEW-FORM-INSTANCE 上的 List 初始化脚本细节密集、肉眼容易看漏交给一个每次都能完整读完上下文的模型逐行对比自己在 Forms Builder 里反复编译、反复点开 List 数选项快得多。EBS 的 Form 里List 型 ITEM 原则上不该把值写死在属性面板上。写死的后果很直接业务加一个状态值你得改 Form、编译、打补丁、走发版流程更麻烦的是测试环境改了、生产忘了改两个环境的下拉选项对不上业务人员提工单你能查半天。所以常规做法是先在 Lookups 里定义一套快速编码再让 import_list 这类过程在 Form 启动时从 fnd_lookup_values_vl 里把数据捞出来用 clear_list 清空、用 add_list_element 逐项塞进去。真正卡人的地方就集中在这几个过程的调用顺序和过滤条件上——顺序差一点点界面就是一片空白条件写宽一点点列表里就混进别的 lookup_type 的值。1. import_list 这段脚本卡人的地方到底在哪1.1 从 WHEN-NEW-FORM-INSTANCE 到 add_list_element 的调用链先把整条链路摊开。用户打开 FormForms Runtime 触发 WHEN-NEW-FORM-INSTANCE这个触发器里调用 import_listimport_list 内部打开游标 csr_status游标从 fnd_lookup_values_vl 里按 lookup_type 取数接着 clear_list 把目标 List 的全部旧选项清掉最后 FOR 循环逐行调用 add_list_element用一个自增的 l_index 当列表下标。原始的写法大致是这样PROCEDURE import_list IS CURSOR csr_status IS SELECT flv.lookup_code, flv.meaning FROM fnd_lookup_values_vl flv WHERE flv.lookup_type CUX_CM_XXXXXXX ORDER BY flv.lookup_code DESC; l_index NUMBER : 1; BEGIN clear_list(BLOCK.ITEM); FOR l_rec IN csr_status LOOP BEGIN add_list_element(BLOCK.ITEM, l_index, l_rec.meaning, l_rec.lookup_code); l_index : l_index 1; EXCEPTION WHEN OTHERS THEN NULL; END; END LOOP; END import_list;add_list_element 的四个参数位置感和直觉不太一样第一个是要操作的 List 全名形如BLOCK.ITEM必须大写、必须和 Form 里的块名项名对得上第二个是列表下标从 1 开始且必须连续第三个才是用户在界面上看到的标签通常取 meaning第四个是选中后真正传到:BLOCK.ITEM里的取值通常取 lookup_code。第三和第四个参数一旦颠倒界面上显示的就会是一串编码取值反而成了中文名称后面程序判断状态时全部落空。1.2 clear_list 和 add_list_element 谁先谁后这一段是审查时最值得盯的地方。clear_list 必须在任何 add_list_element 之前执行而且要放在游标循环外面。原因不复杂clear_list 是整体清空它不认下标只认 List 名。如果顺序反了先 add 再 clear前面加进去的选项会被一次性抹掉用户看到的还是空列表如果 clear_list 被写进循环体里那么每加一项之前先把前面所有项清掉最终 List 里只剩最后一条。还有一种更隐蔽的情况import_list 被调用两次。比如开发时图省事既在 WHEN-NEW-FORM-INSTANCE 里调了一次又在某个 Block 级的 WHEN-NEW-BLOCK-INSTANCE 里调了一次。第一次执行完List 有 N 项第二次如果没有先 clear就会在 N 项之后继续从 1 开始加Forms 对重复下标的处理结果各版本略有差异表现上可能是选项翻倍也可能是下标覆盖两种都很难从界面上一眼看出来。让 Codex 读脚本时把这个过程可能被调用几次一起告诉它它才会顺着这个角度去查。1.3 fnd_lookup_values_vl 的过滤条件容易写偏不少脚本的问题不在 PL/SQL 语法而在那个 WHERE 条件。fnd_lookup_values_vl 是个视图它在基表 fnd_lookup_values 之上已经加了一层约束当前会话语言对应的那几行、以及 enabled_flag 为 Y 的行。也就是说你写WHERE lookup_type XXX拿到的是已经过滤过一次的结果。坑点有三个。第一lookup_type 的大小写和拼写必须和 Lookups 定义里完全一致自定义的编码一般带CUX_前缀写成CUX_CM_XXXX少一个字符结果就是零行而且不报错。第二如果这个 lookup_type 被多个应用视图共用那么同一份数据会在不同应用下被解析出不同的含义这时候应该补上view_application_id条件把它限定到当前 Form 所属的应用而不是让所有应用共用一份结果。第三ORDER BY lookup_code DESC是按编码倒序看起来最新定义的在最前面但业务上想要的顺序往往和编码顺序没关系这一条要拿实际数据核对不能想当然。提示vl 视图只保证语言和启用状态这两层过滤像生效日期区间这类业务约束视图本身不一定替你处理需要结合你的 lookup 定义方式判断。这一条正好可以交给 Codex 帮你把业务语义一起过一遍。2. 用 Codex 审脚本之前先把 Base URL 换到 TaoToken2.1 打开统一入口拿 Key顺手把模型 ID 记下来先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 YOUR_API_KEY。同一个后台里有个模型广场你要跑的那次审查用哪个模型就在那里选把模型 ID 原样抄下来。不要自己拼模型名也不要凭印象加日期后缀——模型广场上当时列表里没有的 ID写进配置就是白跑一趟。这一步顺手把两件事记清楚Key 只显示一次复制完就存到密码管理器里模型 ID 抄完整包含前缀和后缀。后面配置文件里出现的YOUR_MODEL_ID就是替换成你抄下来的那串。2.2 ~/.codex/config.toml 里写死 model_provider 和 base_urlCodex 的配置走 TOML不认环境变量那一套 ANTHROPIC_* 的写法别把 Claude Code 的模板搬过来。在用户目录下找到或新建~/.codex/config.toml写成这样model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat几个要点。model_provider的值要和下面方括号里定义的那个 provider 名一致写错就等于没配。base_url是填进工具里的接口地址末尾不带 /v1也不要写成带 UTM 的官网首页地址那两个是不同用途——落地页给人点接口地址给工具填。env_key是告诉 Codex 去哪个环境变量里读密钥变量名自己定但必须和下面 export 的完全一致。wire_api这一项按你所用 Codex 版本支持的取值填常见是chat如果版本不支持这个键删掉这一行也不会影响 base_url 生效。密钥不落在配置文件里放到 shell 环境export TAOTOKEN_API_KEYYOUR_API_KEY想让它长期生效就写进~/.bashrc或~/.zshrc然后重新打开一个终端或者 source 一下。Key 永远从 TaoToken 的控制台创建别从别的地方抄一份来用。2.3 起 Codex确认它真的走了兼容通道配置改完在任意目录下敲codex先问一句和 EBS 无关的问题探路比如让它解释fnd_lookup_values_vl和fnd_lookup_values的关系。能正常回话说明 base_url 和 Key 这一层已经通了如果直接报 401八成是env_key的值和你 export 的变量名对不上或者你在新开的终端里忘了 export。这时候不用急着去查脚本先把通道这一层确认干净再进正题。3. 让 Codex 逐条核对 import_list 的三处细节3.1 第一轮只放 clear_list 与 add_list_element 的顺序问题审查最忌讳一次问太多模型容易给你一份什么都对又什么都没用的总结。第一轮只做一件事——把脚本贴进去明确限定输出范围下面是 EBS Form 里由 WHEN-NEW-FORM-INSTANCE 调用的 import_list 过程 目标 List 是 BLOCK.ITEM。请只回答三个问题不要重写整个过程 1) clear_list 的位置是否必须位于 FOR 循环之前写出理由 2) add_list_element 的四个参数依次是什么第三和第四个参数如果写反 界面上看到什么、程序取值拿到什么 3) 如果 import_list 在一次 Form 会话中被调用两次会发生什么。这样问的好处是答案可以直接对照。如果它说 clear_list 可以放循环里那这份回答本身就有问题可以追问放循环里第二项开始会发生什么如果它准确指出参数顺序和重复调用的后果这一轮的结论就可以直接拿去比对你的脚本。3.2 第二轮把 lookup_type 和视图条件单独拎出来问第二轮换一个角度只谈数据源。把 Lookups 里那段定义的截图或描述一起给它重点问三件事当前这个 lookup_type 命名是否和 Lookups 定义严格一致是否需要补view_application_id来区分共用同一个 lookup_type 的不同应用视图ORDER BY lookup_code DESC是否真的符合界面上的呈现顺序。这一轮可以要求它给出一份改写后的 WHERE 子句但不要让它替你连库执行。它给的是文本落库的动作由你在 SQL*Plus 里做见下一节。顺带可以让它列一个自查清单比如零行返回时依次排查哪几项方便你固化下来当团队规范。3.3 第三轮WHEN OTHERS THEN NULL 到底吞掉了什么那段内层异常处理是整个脚本里最容易被忽略的一行。WHEN OTHERS THEN NULL的意思是add_list_element 如果抛异常静默跳过继续下一轮。它保护了 Form 不被中断代价是把问题藏了起来——某一项没加进去List 就少一项而 l_index 已经自增过了下标序列出现断点更麻烦的是业务上表现为某个状态选不到而你从界面上完全看不出是加项失败还是数据本身缺失。让 Codex 评估这段异常处理的取舍并给出替代写法。合理的改法通常有两种一是异常里写入日志表或者调用消息机制把出错的 list_index 和 lookup_code 记下来方便事后查二是干脆不在这一层兜把异常抛到上层统一处理让问题在测试阶段就暴露出来。选哪种取决于你们团队的运维习惯但静默 NULL基本可以判定为不可取。4. 拿 Codex 的结论回本地验证4.1 在 SQL*Plus 里单独跑一遍游标模型给的 WHERE 子句是不是对的用数据说话。打开 SQL*Plus连上你的 EBS 数据库把游标里的 SELECT 单独跑一遍SELECT flv.lookup_code, flv.meaning, flv.enabled_flag, flv.language FROM fnd_lookup_values_vl flv WHERE flv.lookup_type CUX_CM_XXXXXXX ORDER BY flv.lookup_code DESC;如果返回零行换个角度查基表去掉语言过滤看看数据到底存不存在SELECT lookup_code, meaning, enabled_flag, language, view_application_id FROM fnd_lookup_values WHERE lookup_type CUX_CM_XXXXXXX ORDER BY language, lookup_code;把两次结果贴回对话里给 Codex让它对比着看比只贴一个查不到要有效得多。注意这条查询由你在本地 SQL*Plus 里执行工具只负责生成和解释 SQL不替你连生产库。生产环境上跑之前先用测试库确认。4.2 在 Forms Builder 里确认 List 的取值是 meaning 还是 codeSQL 能查出行不代表 List 里就是对的。编译并运行 Form让 WHEN-NEW-FORM-INSTANCE 走一遍然后打开那个 List 往下拉看显示的是中文名称还是一串编码。选中其中一项在对象导航器或者调试窗口里看:BLOCK.ITEM的实际值——如果显示是中文、取值却是中文那第三第四参数就是反的如果显示是编码、取值也是编码说明 meaning 那一列本身取的就是 code要回头查 lookup 定义里这两列是怎么填的。这一步一定要在测试库里点一遍。List 型 ITEM 的行为和它的属性设置强相关光看代码推断容易漏掉读一致性列表项映射这类属性带来的差异。4.3 几类别扭的现象对照着查现象优先怀疑的对象先看哪里List 打开全空lookup_type 拼写或语言过滤4.1 的 SQL 是否返回行显示编码、取值是名称add_list_element 参数顺序反了第 3、4 个参数选项重复或翻倍没先 clear_list或过程被调用两次clear_list 是否在循环外、调用点有几个少了几项但界面无提示WHEN OTHERS THEN NULL 吞了异常临时改成抛异常复现换了环境选项变少两个库的 Lookups 数据没同步对同一 lookup_type 做行数比对对照表用起来比逐行读代码快尤其是接手别人写的 Form 时先按现象缩小范围再用 Codex 去解释具体那一小段。4.4 Codex 这一侧的配置类报错只查这几项通道层的报错就那么几个。401 基本都是环境变量没生效echo $TAOTOKEN_API_KEY先确认变量有值再确认env_key写的名字和它一致。模型不存在的报错一般是model那一行抄错了回模型广场核对当时的列表。如果请求发出去了但返回的内容很怪检查base_url是不是被多加了个/v1——接口地址就是 https://taotoken.net/api末尾不带版本号。5. 审查做完回控制台把这次调用对上账5.1 用同一把 Key 发一条消息确认链路没串在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错、额度还在。然后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 看这次的调用记录有没有记上——如果你刚跑的是比较长的脚本审查这里的用量会比随手问一句高出不少顺手对一下心里对成本有个数。5.2 接着往下走的两件事短期只是偶尔查脚本模型对话页够用如果打算天天把 Form、PL/SQL、报表逻辑往 Codex 里丢Coding Plan 里挑一档更划算不用每次担心额度。Key 相关的事都集中在 控制台 API Keys需要新开一把给同事用、或者轮换旧 Key都在这里操作。最后留一个习惯每次让 Codex 读完 EBS 脚本把它给的结论落到你本地能执行的 SQL 或者 Form 运行验证上能跑通再写回代码。模型说得再顺最终还是要 Forms Runtime 那一遍编译和 SQL*Plus 那一次查询来签字。
