⭐️
模型基准测试
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 倍——证明修复循环下一步最有杠杆的改进是结构化错误解析，而不是更聪明的模型。
自己运行基准测试
基准测试工程随主仓库发布，位于
seatunnel-cli/benchmark/——
包含 100 个声明式任务、分层判定门、Docker 数据环境和报告生成器。
cd seatunnel-cli
# 凭证走各提供商的标准环境变量
export OPENAI_API_KEY=sk-... # 或 ANTHROPIC_API_KEY / AWS 凭证
# 一条命令：装依赖、预检环境、运行、出报告
./benchmark/run_benchmark.sh --provider openai --model gpt-4o
# 多模型对比
./benchmark/run_benchmark.sh --models benchmark/models.json
# 可选的更深判定门：
# L2（引擎 dry-run） — 设置 SEATUNNEL_HOME 指向 dev 分支构建
# L3（真实执行） — docker compose -f benchmark/docker/docker-compose.yml up -d --wait
环境缺失时自动降级：没有引擎或 Docker 时输出静态门（L1）报告；请求了但 无法执行的判定门对应的测试轮次会被排除在所有通过率指标之外并在摘要中 标注，不同配置的机器之间不会被静默比较。
每份报告都标记被测 CLI 的版本与 git commit——在新的 CLI 构建上重跑同一
模型，即可在相同任务集上量化任何 prompt、元数据或修复逻辑改动的效果。
完整方法论、任务集结构与指标定义见
benchmark/README.md。