行记录转列记录、set relation 失配，用 TaoToken：https://taotoken.net/?utm_source=taotoken_aicg_blog_end 先把 Key 建出来，再让 Codex 对着 create cursor t2、create cursor t4、index on 学号+姓名 tag xhxm、set relation to 学号+姓名 into "t4"、scan 里 found("t4") 判断 replace 还是 insert 这一段逐句核对。VFP 的代码、DBF 和游标都在本机，模型只负责读代码、解释语句、指出两边表达式哪里对不上，命令窗口还是你自己敲。
成绩表转报表是最典型的场景：一个学生五六行科目成绩，导出时要变成一行一个学生、科目当列头。原文走的就是双游标加关系查找的路子，t2 装源数据，t4 装目标结构，靠 xhxm 这个索引把两边接上，循环里 found 为真就 replace、为假就 insert。逻辑不复杂，真跑起来却总在这三处翻车：关系建不上、found 一路 .F.、&km 换出来的列名不认。这三件事看起来是三件事，其实是同一层的问题——键、状态、名字。下面按这个顺序拆开。
1. set relation to 学号+姓名 into "t4" 建不上，先查这三件事
关系建不上时，很多人第一反应是去改表达式。但多数情况下表达式没错，错的是执行那一刻的工作区状态。SET RELATION 是在当前工作区上挂关系，它认的是"我现在站在哪张表上、子表叫什么别名、子表的控制索引是哪个 tag"，这三样里有一样不对，命令就 silently 失败或者直接报别名找不到。
1.1 两条 create cursor 有没有挤在同一个工作区
先别急着看表达式。在命令窗口敲这三行，把结果抄下来：
? SELECT("t2") && 返回 0 表示这张游标压根没开 ? SELECT("t4") ? ALIAS() && 当前工作区别名 ? ORDER() && 当前工作区的控制索引 tagSELECT("t4")返回 0 的话，后面SET RELATION ... INTO "t4"一定报Alias 't4' not found，跟学号+姓名怎么写一点关系都没有。游标别名重复、被 CLOSE 掉、或者在子过程里用同名游标覆盖过，都会造成这个结果。
还有一个方向性的坑：SET RELATION一定是在父表上执行。如果你的当前工作区是 t4，这条命令的意思就变成了"在 t4 上挂一个指向 t2 的关系，键是 t4 的 学号+姓名"，方向整个反过来。t2 上如果没有 xhxm 这个 tag，VFP 会告诉你索引不存在；如果恰好有，那就更麻烦——不报错，但匹配结果全错，你会在 found 分支上排查半天，其实问题在最开始那一行。
养成习惯：建完两个游标之后，明确SELECT t2回到父表，再往下写。
1.2 index on 学号+姓名 tag xhxm 到底建在了哪张表上
INDEX ON同样作用于当前工作区。原文的顺序是先 create cursor t2、再 create cursor t4，然后接index on 学号+姓名 tag xhxm。如果这中间当前工作区不在 t4 上，这个 tag 就建到别的表上去了，t4 手里空空，关系自然挂不上。
稳妥的写法是把"选表"和"建索引"贴在一起，中间不夹任何别的命令：
SELECT t4 INDEX ON 学号+姓名 TAG xhxm SET ORDER TO TAG xhxm ? ORDER() && 应该回 XHXM ? KEY() && 把索引表达式打出来，跟父表那侧对比tag 建好不等于在用。一张子表可以有十几个 tag，真正参与关系查找的是当前控制索引，也就是 ORDER。中途一句SET ORDER TO、一句SET ORDER TO 0，关系查找立刻失效，而且不会报错。维护别人代码的时候，这类"某处顺手改了个 ORDER"造成的故障特别常见。建议在SET RELATION之前再补一句SET ORDER TO TAG xhxm，把状态钉死。
1.3 父子两边的表达式必须逐字一致
关系的匹配过程说穿了很简单：把父表当前记录的表达式求值成一个字符串，拿这个字符串去子表的控制索引里找。所以两侧表达式必须产出同一个键，差一个字符都不行。
| 父表表达式 | 子表 tag 表达式 | 结果 |
|---|---|---|
| 学号+姓名 | 学号+姓名 | 匹配 |
| 学号+姓名 | ALLTRIM(学号)+ALLTRIM(姓名) | 定长拼接对变长拼接，基本匹配不上 |
| ALLTRIM(学号)+ALLTRIM(姓名) | ALLTRIM(学号)+ALLTRIM(姓名) | 匹配，但注意 SET EXACT 的影响 |
| 学号+姓名（学号为 N 型） | 学号+姓名 | 加号被当算术运算，报类型错或产出怪键 |
最后一行是最隐蔽的。学号如果被建成 N(8)，学号+姓名在 VFP 里是数值加字符，要么直接报数据类型不匹配，要么被隐式转换成一个你根本不认识的键值。索引表达式和 relation 表达式两边都得写成STR(学号,8)+姓名，或者干脆把学号建成 C 型，少一半麻烦。
另外提醒一句：SET EXACT ON时字符比较要求等长。索引键一旦用了 ALLTRIM，父表那侧也必须 ALLTRIM，否则前缀匹配直接失效。做定长拼接的场景，建议两边都别用 ALLTRIM，键是什么就是什么。
2. scan 里 found("t4") 一直为 .F.：FOUND() 读的是哪一次查找
关系建上了，found 还是 .F.，这时候要换一个思路：FOUND()从来不是"关系有没有命中"的查询函数，它是"某个工作区最近一次查找成不成功"的查询函数。你把它当状态检查用，它就把你带沟里。
2.1 FOUND() 反映的是最近一次查找，不是"关系是否有效"
FOUND([别名])返回的是指定工作区里最近一次查找的结果。父表记录指针一移动，子表会被关系带着重新定位，这次定位的结果就是 found 该读的东西——前提是它紧接着被读。
一旦中间插进了别的动作，值就被改写了。在循环体里为了别的事SELECT t4然后LOCATE FOR ...一下、SEEK一下、SKIP一下，FOUND("t4")立刻变成那一次操作的结果。后面那句IF FOUND("t4")判断的已经不是关系了，它判断的是你刚才那次 LOCATE。
还要说清楚的是：关系定位算不算一次"查找"，不同版本的处理并不完全一致。靠 FOUND() 撑起整个 replace/insert 分支逻辑，本身就是把业务正确性压在了一个隐式状态上，短期能跑，换个环境就翻车。
2.2 循环体里三件容易把状态冲掉的事
第一件，判断之前做了别的查找。关系已经把 t4 指到正确位置了，代码里又来一次LOCATE，found 变成 LOCATE 的结果，分支自然走错。
第二件，SET RELATION OFF之后忘记重建，或者每次循环都重建一次。关系重建期间父表指针会被重新触发定位，子表指针乱跳，found 的值也跟着乱。
第三件，循环里重开游标或者USE ... AGAIN。游标一重开，tag 的 ORDER 状态、关系本身全断，而且很多时候不报错。
这三件事有个共同点：都不是语法错误，都不会中断程序，只会让你看到一片 .F.。所以排查的时候，与其在循环里加一堆? FOUND("t4")，不如直接把这段逻辑换掉。
2.3 干脆用 SEEK() 的返回值替掉 SET RELATION 和 FOUND()
推荐的改法是把"关系 + 隐式状态 + found 分支"整段拆掉，换成显式的 SEEK，一次调用直接拿到布尔值：
SELECT t4 SET ORDER TO TAG xhxm && 控制索引明确钉死 SELECT t2 SCAN lcKey = 学号 + 姓名 lcKm = ALLTRIM(科目) IF SEEK(lcKey, "t4") SELECT t4 REPLACE &lcKm WITH t2.成绩 ELSE SELECT t4 APPEND BLANK REPLACE 学号 WITH t2.学号, 姓名 WITH t2.姓名 REPLACE &lcKm WITH t2.成绩 ENDIF SELECT t2 ENDSCANSEEK()是函数形式，直接返回 .T./.F.，三个参数分别是键值、目标别名、目标 tag。它不依赖任何隐藏状态，也不需要先建关系——第 1 节里那些"关系建不上"的问题，到这里一次性消失。
两个使用细节：一是SEEK()只移动指定工作区的记录指针，不会切换当前工作区，所以 REPLACE 之前还是要SELECT t4；二是SEEK()会把 t4 的记录指针定位到命中记录上，紧接着 REPLACE 就是改在正确的那一行。代价是每行源记录都重新 seek 一次，但行转列这种一次性批处理，这点开销完全可以接受。
3. &km 宏替换列名不生效：动态列名该拼在哪一层
行转列真正难的地方不在关系，在列头。列名是跑起来才知道的，宏替换是绕不开的工具，但它对字符串内容极其挑剔——多一个空格、多一对引号、多一个别名前缀，展开出来的就是另一条命令。
3.1 宏替换替换的是"名字"，别把别名、引号、空格塞进去
&km的执行逻辑是：把 km 变量的字符串内容原封不动塞进命令里，VFP 再整体解析一遍。所以 km 里装什么，直接决定命令长什么样。
| km 的值 | REPLACE &km WITH 成绩展开成 | 结果 |
|---|---|---|
| 语文 | REPLACE 语文 WITH 成绩 | 正常 |
| "语文" | REPLACE "语文" WITH 成绩 | 语法错 |
| t4.语文 | REPLACE t4.语文 WITH 成绩 | 目标字段带别名限定，别赌，容易报错 |
| 语文（C 型字段取出来带尾空格） | 名字尾部带空格 | 引用不上，或拼进建表语句后列名带空格 |
最常见的来源是第三种和第四种组合：km 的值直接从 t2 的科目字段里取，而科目字段是 C(10)，取出来是"语文 "。这个值用&km去 REPLACE 可能还能蒙对，但一旦拼进CREATE CURSOR的列名里，建出来的列就叫语文——屏幕上看像"语文"，用AFIELDS()一比就露馅，别的工具读结构更对不上。
所以取值的时候一律ALLTRIM()清干净，再用一个独立变量接住，别在循环里反复从字段取。
还有一种情况是变量作用域：km 在子过程里定义成 PRIVATE，或者循环外定义、循环内被别处覆盖，宏替换展开的就是旧值。这种问题盯着代码看不出，直接在 REPLACE 前加一句? "[" + km + "]"，中括号一包，尾空格和旧值全都现形。
3.2 列要多少、叫什么都是跑起来才知道：把整条 CREATE CURSOR 拼出来
t4 的列头来自 t2 里出现过的科目，事先写不死，可以分两步：先收科目，再拼建表语句。
* 先把要变成列头的科目收干净 SELECT DISTINCT ALLTRIM(科目) AS 科目名 ; FROM t2 ; WHERE NOT EMPTY(科目) ; ORDER BY 科目名 ; INTO CURSOR tkm * 逐个拼列定义 lcCols = "" SELECT tkm SCAN lcCols = lcCols + IIF(EMPTY(lcCols), "", ", ") + 科目名 + " N(6,1) NULL" ENDSCAN * 拼整条命令，然后整体执行 lcCmd = "CREATE CURSOR t4 (学号 C(10), 姓名 C(10)" + ; IIF(EMPTY(lcCols), "", ", " + lcCols) + ")" ? lcCmd && 执行前先看一眼 &lcCmd这里的&lcCmd是宏替换的另一种用法：替换的不是一个名字，而是整条命令。VFP 会把字符串当命令解析再执行。所以括号、逗号、类型串都得自己拼对，少一个逗号、括号没闭合，报的就是Unrecognized command verb或者语法错。养成拼完先? lcCmd看一眼的习惯，比事后猜快得多。
列定义里的NULL值得单独说一下：不带 NULL 的数值列，没赋值时默认是 0，你分不清"这门课没考"和"考了 0 分"。加上 NULL 之后，用IS NULL就能把两种情况分开，报表口径才干净。
还有个坑要提前知道：别想着先建个只有学号姓名的 t4，再循环ALTER TABLE t4 ADD COLUMN 语文 N(6,1)动态加列。ALTER TABLE 对数据库容器里的表、自由表和游标的支持程度不一样，CREATE CURSOR 出来的临时游标上这么加列，经常直接报错或者行为不一致。一次拼全再建，最省事。
列名长度也得留意。自由表的字段名长度限制偏紧，中文长科目名容易被截断，计算机应用基础这种建议先映射成短列名或科目代码，或者干脆用数据库容器里的表。DISTINCT 收出来的科目名如果有前后空格或大小写差异，也要在这一步统一掉，否则会生成两个看起来一样的列。
3.3 三条路线的取舍：关系游标、动态 SQL、名字表达式
如果科目就那么几门、短期内不会变，其实根本用不上双游标加关系。VFP 的 SQL 直接把行压成列：
SELECT 学号, 姓名, ; SUM(IIF(ALLTRIM(科目) = "语文", 成绩, 0)) AS 语文, ; SUM(IIF(ALLTRIM(科目) = "数学", 成绩, 0)) AS 数学, ; SUM(IIF(ALLTRIM(科目) = "英语", 成绩, 0)) AS 英语 ; FROM t2 ; GROUP BY 学号, 姓名 ; INTO CURSOR t4这条语句不需要 index、不需要 relation、不需要 found、不需要宏替换，四类坑一次全绕开。缺点是列头写死在 SQL 文本里，科目一变就得改语句。
科目会变的时候，可以把上面这段 SELECT 也当字符串拼出来，列名从 tkm 游标里生成，最后&lcCmd一次执行。既然都是拼字符串，就把列名拼接和 SQL 生成合成一层，省掉维护 t4 结构那一摊事。这条路线的可控性最好：拼出来的语句能打印、能存日志、能直接贴给 Codex 看。
至于名字表达式，像REPLACE (lcKm) WITH t2.成绩这种把变量名括起来当字段名用的写法，部分版本、部分命令支持，但它只能替代"名字"这一个位置，替代不了整条命令——要动态建表还是得回到&。两者别混着写，也别写成&(lcKm)这种既不是宏替换也不是名字表达式的形式。不确定版本行为的地方，统一用&宏替换，通用性最好。
4. 用 Codex 复查 set relation 与 found 分支：config.toml 里换掉 model_provider
代码改到这一步，剩下的往往是"我看了三遍还是没看出哪不对"。这种时候把表达式、索引状态、循环体分块喂给模型，让它按可能性排序列原因，比自己在命令窗口瞎试快。前提是通道先配通。
4.1 ~/.codex/config.toml 里加一个供应商指向兼容通道
先去 TaoToken 注册并创建 API Key，Key 只在创建时显示一次，复制下来。然后打开 Codex 的配置文件：macOS/Linux 在~/.codex/config.toml，Windows 在%USERPROFILE%\.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"几个必须注意的点。base_url写https://taotoken.net/api，末尾不要加 /v1，也不要在这一行挂任何查询参数。model填具体模型 ID，以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 上的模型广场当时列表为准，YOUR_MODEL_ID只是占位符，别照抄。env_key填的是环境变量名，不是 Key 本身。
Key 通过环境变量给：
export TAOTOKEN_API_KEY=YOUR_API_KEYWindows PowerShell 用：
$env:TAOTOKEN_API_KEY = "YOUR_API_KEY"这么配的好处很直接：一把 Key 对着多个模型，换模型只改model那一行，不用来回切换账号和 provider。Codex 这边只认 base_url 和 Key，你本机的 VFP 环境、DBF 文件、游标全都不受影响。
4.2 起会话，把结构、索引、关系、循环分四段贴进去
在放 VFP 代码的目录里起会话：
cd /path/to/your/vfp/code codex贴代码的顺序比分块本身更重要。一次糊一大坨进去，模型只能给你泛泛的建议；按下面四段拆开贴，它能直接指出是哪一层对不上：
- 第一段：两条
CREATE CURSOR语句，加上? SELECT("t2")、? SELECT("t4")、? ORDER()的实际输出 - 第二段：
INDEX ON 学号+姓名 TAG xhxm那一行，以及执行它时当前工作区是谁 - 第三段：
SET RELATION TO 学号+姓名 INTO "t4"那一行，父表那侧表达式怎么写 - 第四段：SCAN 循环全文，重点是 found 判断和 REPLACE
提问也要具体，别问"帮我改一下"：
这段 VFP 代码里，SET RELATION 的父表表达式是 学号+姓名， 子表 t4 的 tag xhxm 建在 学号+姓名 上，但 found("t4") 一直是 .F.。 请按可能性排序列出所有原因，每条给出对应的验证命令。 不要直接改代码，先给排查顺序。有个边界必须说清楚：Codex 只读你本机的文件、解释和生成代码，它不会替你连数据库、不会替你执行 SQL、不会改你的数据。要验证什么，得你自己在 VFP 命令窗口敲，把返回结果贴回对话让它接着分析。想让它顺带解释&lcKm那段，就直接把拼好的lcCmd字符串贴过去，问"这条命令展开后哪里语法不对"。
4.3 先问一个无关问题，确认通道通了再贴代码
正式开工之前花十几秒验一次：随便问一个跟 VFP 无关的问题，比如"用一句话解释索引表达式是怎么参与匹配的"。能正常回答，说明 base_url 和 Key 都对。
回 401，是 Key 的问题——检查环境变量有没有导进去、有没有多复制了空格。回 404 或者提示模型不存在，多半是model写错，或者 base_url 又被加回了/v1。这两类错误跟你的 VFP 代码毫无关系，但表现都是"模型不回答"，很容易被误判成"代码贴得太乱它看不懂"，然后白白浪费半小时在整理代码上。
5. 改完这一版，怎么确认行转列真的对了
代码能跑不等于结果对。行转列最容易出的不是报错，是"跑完了，数字不对"——少了几行、某几列全是 0、某门课的分数串到别的列里。
5.1 三条对照检查
第一条查行数。t4 的记录数应该等于源数据里去重后的学生数。基准值在源数据侧算：
SELECT 学号, 姓名 FROM t2 GROUP BY 学号, 姓名 INTO CURSOR tk ? RECCOUNT("tk") SELECT t4 ? RECCOUNT("t4")两个数不一样，说明 SEEK 分支里有记录漏了，或者 APPEND BLANK 走了两次。
第二条查总分。把所有科目列加起来，应该等于 t2 里成绩列的总和。列多的时候可以循环拼一条求和语句，也可以先在源数据侧SUM(成绩)，再在 t4 侧逐列累加，两边对不上就去查那门课的列。
第三条查空值语义。建表时如果列声明了 NULL，用SELECT * FROM t4 WHERE 语文 IS NULL就能筛出"这门课没考"的学生；如果没声明 NULL，数值列默认是 0，WHERE 语文 = 0会把没考和考了 0 分混在一起。这一步在教务口径上很关键，值得单独核一遍。
5.2 报错对照表
| 报错或现象 | 最可能的原因 | 先去查什么 |
|---|---|---|
| Alias 't4' not found | t4 没有开在工作区，或别名被覆盖 | ? SELECT("t4") |
| Variable 'LCKM' is not found | 宏替换变量名拼错，或作用域不对 | ? TYPE("lcKm") |
| Field '语文' is not found | 列名带尾空格，或列根本没建成 | ? AFIELDS()打印列名 |
| Data type mismatch | 学号是 N 型却参与字符串拼接 | 改用STR()或把学号建成 C 型 |
| Unrecognized command verb | &lcCmd拼出来的整条命令语法错 | ? lcCmd执行前先看一眼 |
| 结果某几列全是 0 | SEEK 没命中，全走 APPEND BLANK，且列名没写对 | 在 REPLACE 前? lcKey |
这张表里的六行覆盖了绝大多数情况。真遇到表里没有的，把报错原文和? lcCmd的输出一起贴给 Codex，让它对着具体字符串找语法问题，比描述现象有效得多。
5.3 跑完一批回控制台对一下账
数据出来后，回 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 看一下这次的调用记录和用量。排查阶段来回贴代码和报错，次数往往比正常写代码多好几倍，尤其是把整段循环反复贴进去的时候，心里有个数比较好。模型 ID 换过的话，也在模型广场确认一下当前用的是哪个，别拿 A 模型的价格预期去看 B 模型的账单。
下次再碰到这类 VFP 老代码，记住三件事就够了：父表的表达式和子表的 tag 表达式摆在一起逐字比；found 分支别压在隐式状态上，能换成SEEK()就换；列名拼接的地方，执行前先?出来。这三条摆平，行转列就没什么玄学了。
通道配好之后，可以先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息，确认 Base URL 和模型 ID 都没填错；如果打算长期用 Codex 跑这类代码复查，打开 Coding Plan 看看额度够不够；Key 需要重建的时候在 控制台 API Keys 里随时处理。
