⭐️
模型基准测试
AI CLI 的准确率靠实测而非假设：专门的基准测试包含 100 个任务、三档复杂度，判定门层层递进直至真实作业执行（连接 Docker 化的真实数据源），覆盖 7 个主流大模型。本页汇总方法论、测试结果与选型建议。
以下数据于 2026 年 7 月实测，被测对象为 seatunnel-cli v0.1.0（commit
59ada4ec0），模型由 AWS Bedrock 提供。模型与 CLI 都在演进，数字是时间快照——需要最新数据请重新运行基准测试。
方法论
任务集：100 个任务 —— 20 个简单（单源单宿）、45 个中等（类型映射、CDC、transform 链、多表）、35 个复杂（多源 DAG、扇出、条件路由），覆盖 12 个 ETL 场景类别，含 10 个中文任务和 18 个针对已知 LLM 错误模式的规则探针（条件选项误用、BATCH/STREAMING 推断、路由标签接线）。
判定门，与 CLI 自身的 check → dry-run → run 管道一一对应：
| 判定门 | 判定方式 | 能抓住什么 |
|---|---|---|
| L1 静态 | HOCON 解析 + 连接器元数据 + 断言 | 语法错误、连接器用错、缺选项 |
| L3 真实执行 | 在官方 apache/seatunnel 镜像里对真实 MySQL/PostgreSQL/Kafka/ClickHouse/Elasticsearch 运行作业；批任务看退出码，流任务看 60 秒健康存活 | 一切"看着对但跑不通"的问题 |
修复循环：判定失败后，把失败层的真实报错喂给 CLI 自带的修复 Agent，最多 3 轮。所有判定均为确定性——没有"LLM 当裁判"。
核心发现：静态排名在真实执行下反转
| 模型 | 静态门（L1） | 真实执行（L1+L3） |
|---|---|---|
| Claude Opus 4.8 | 89%（第 3） | 85%（第 1） |
| GPT-5.6 Sol | 90%（第 2） | 81%（第 2） |
| GPT-5.6 Terra | 93%（第 1） | 74%（第 3） |
静态冠军写出的配置"看着对"但运行时失败最多（静态→真实衰减 -20 个百分点）；静态第三的模型写出的配置真的能跑（仅 -6pp）。"看着对"和"能跑"是两种不同的模型能力——这正是基准必须真实执行配置的原因，也是对"只做静态检查就宣称准确率"应保持警惕的原因。
静态门完整排名（7 模型）
| 模型 | 通过率（≤5 轮修复） | 首次通过 | 修复救回 |
|---|---|---|---|
| GPT-5.6 Terra | 93% | 79% | +14 |
| GPT-5.6 Sol | 90% | 80% | +10 |
| Claude Opus 4.8 | 89% | 87% | +2 |
| Claude Sonnet 5 | 82% | 78% | +4 |
| Claude Fable 5 | 80% | 73% | +7 |
| Qwen3-Coder-Next | 67% | 53% | +14 |
| DeepSeek V3.2 | 58% | 58% | +0 |
模型行为画像
生成能力与修复能力是两个独立维度，且家族特征高度一致：
- 一次写对型（Anthropic 系）：Opus 4.8 首次通过率全场最高（静态 87% / 真实 77%），静态→真实衰减最小——它写出来的基本就能跑。但修复贡献极低（+2）：自己的失败很少能修回来。
- 迭代修复型（GPT-5.6 Terra）：首过平平，但修复能力全场最强——真实运行时失败修回 48%，总分从 55% 爬到 74%。它的初稿"看着对但跑不通"的风险最大。
- 修复失能型（DeepSeek V3.2）：100 个任务中修复成功次数为零——修复输出要么与原配置相同要么直接放弃。对内建自动修复循环的产品，等于砍掉了一半机制。
- 两个值得注意的现象：深推理旗舰（Fable 5）只排第 5——在该用合理默认值干活的场景里过度追问澄清；10 个中文任务上，国产模型得分反而更低（Qwen 5/10、DeepSeek 4/10），GPT-5.6 Sol 拿了 10/10。
模型选型指南
| 场景 | 推荐 | 理由 |
|---|---|---|
| 交互式使用（用户在等） | GPT-5.6 Sol / Terra | 快（25–58 秒/任务），综合准确率高 |
| 无人值守 / 批量生成 | Claude Opus 4.8 | 首次通过率最高，产出最可能免修改直接运行 |
| 预算敏感的回归测试 | Qwen3-Coder-Next | 成本最低档；适合冒烟，不适合生产生成 |
| 自动修复流程中避免使用 | DeepSeek V3.2 | 实测修复成功率为零 |
已知弱场景（所有模型）
13 个任务在前三名模型上全部失败。如果你的管道属于以下形态，生产使用前请人工复核生成的配置：
| 场景 | 失败根因 |
|---|---|
| Doris / StarRocks 目标端 | 连接器选项知识缺失（fenodes、load 端口、save mode） |
| PostgreSQL-CDC | 前置条件（复制槽、publication）未在配置中体现 |
| 条件路由（一个源按谓词拆分到多个目标） | 并行 SQL transform 下的 plugin_output/plugin_input 接线 |
| 宽 DAG（5+ 块、混合 transform） | 标签配对与块组织错误 |
这些聚类是工程改进目标，不是永久限制：正在通过连接器元数据注入和黄金样例覆盖逐项解决，改进效果用同一基准验证。
修复循环的实测效果
把真实引擎报错喂回修复 Agent，可挽回 47% 的运行时失败（前三名模型合计）。同一个模型修复结构化校验错误的成功率约为修复原始 Java 堆栈的 2 倍——证明修复循环下一步最有杠杆的改进是结构化错误解析，而不是更聪明的模型。