oracle-migration 技能评估报告¶
评估框架：skill-creator 评估日期：2026-04-18 评估对象：
oracle-migration
oracle-migration 是一个 Oracle 数据库 schema 迁移安全审查和 DDL 生成技能。覆盖 DDL 自动提交含义、DDL_LOCK_TIMEOUT 配置、大表在线重定义（DBMS_REDEFINITION）、ENABLE NOVALIDATE 约束模式、全局索引失效防护以及强制性的 §9 输出契约。本次评估采用 3 场景 A/B 测试（6 次真实模型调用），通过 23 条评分断言对比带技能与不带技能的实际响应质量，并记录了真实 token 消耗。评估揭示了一个重要的细分发现：基准模型在 FK 约束等常见 Oracle 场景中技术知识扎实，而技能的差异化价值主要集中在 DDL_LOCK_TIMEOUT 这一 Oracle 特有关键参数、结构化输出契约的完整性，以及列精度扩展行为的精确分类上。
1. 评估概览¶
本次评估从三个维度衡量技能性能：结构化输出合规性、Oracle 特有知识精确性、降级条件下的完整性。3 场景 × 2 配置（带技能/不带技能）= 6 次独立真实模型运行，共 23 条评分断言。
| 维度 | 带技能 | 不带技能 | 差值 |
|---|---|---|---|
| 断言通过率（全通过） | 23/23 (100%) | 8/23 (35%) | +65 pp |
| 断言通过 + 部分通过（加权） | 23/23 (100%) | 11.5/23 (50%) | +50 pp |
| 评分卡存在（Critical/Standard/Hygiene 三层） | 3/3 (100%) | 0/3 (0%) | +100 pp |
| §9.9 未覆盖风险章节存在 | 3/3 (100%) | 0/3 (0%) | +100 pp |
| 降级模式正式声明 | 1/1 (100%) | 0/1 (0%) | +100 pp |
| DDL_LOCK_TIMEOUT 在每条 DDL 前设置 | 3/3 (100%) | 0/3 (0%) | +100 pp |
| NUMBER 列精度扩展正确识别为元数据操作（非表重写） | 1/1 (100%) | 0/1 (0%) | +100 pp |
| 平均会话 token 消耗 | ~38,732 | ~14,583 | +166% |
加权通过率算法：部分通过 = 0.5 分；总分 = (全通过数 + 部分通过数 × 0.5) / 23。
2. 场景 0 — 标准 DDL 审查¶
2.1 测试设置¶
输入：Oracle 19c EE，orders 表约 500 万行，无 RAC，Flyway 管理，无专属维护窗口。会话中未预先设置任何 ALTER SESSION 参数。审查以下迁移（3 条 DDL 在同一会话中执行）：
ALTER TABLE orders ADD (tracking_id VARCHAR2(50));
ALTER TABLE orders MODIFY (amount NUMBER(12,4) NOT NULL);
CREATE INDEX idx_orders_created ON orders(created_at);
9 条断言（A1–A9）：上下文收集表、DDL_LOCK_TIMEOUT 缺失标记、MODIFY NOT NULL 与现有 NULL 数据的 ORA-02296 风险、ENABLE NOVALIDATE 两步推荐、CREATE INDEX ONLINE 推荐、DDL 自动提交风险说明、手动回滚 SQL、三层评分卡、§9.9 未覆盖风险章节。
2.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| A1 | 完整的上下文收集表（§9.1，含 Edition/RAC 字段） | 部分 | 通过 |
| A2 | 明确标记缺少 DDL_LOCK_TIMEOUT（ORA-00054 风险） | 失败 | 通过 |
| A3 | MODIFY NOT NULL 识别现有 NULL → ORA-02296 风险 | 通过 | 通过 |
| A4 | 推荐 ENABLE NOVALIDATE + VALIDATE 两步模式 | 部分 | 通过 |
| A5 | CREATE INDEX 推荐使用 ONLINE 选项（并说明 EE 前提） | 部分 | 通过 |
| A6 | DDL 自动提交风险说明（未提交 DML 将被隐式提交） | 部分 | 通过 |
| A7 | 提供每条 DDL 对应的手动回滚 SQL | 部分 | 通过 |
| A8 | 包含 Critical/Standard/Hygiene 三层评分卡 | 失败 | 通过 |
| A9 | 包含 §9.9 未覆盖风险章节 | 失败 | 通过 |
场景 0：不带技能 = 1 通过 + 5 部分 + 3 失败（加权 3.5/9 = 39%）| 带技能 = 9/9 全部通过
实际 token 消耗：不带技能 14,195 tokens（0 次工具调用）| 带技能 41,080 tokens（9 次工具调用，含 SKILL.md + 参考文件读取）
2.3 关键观察¶
不带技能：响应质量远超预期——正确识别了 ORA-02296 风险（A3 通过），提及了 ENABLE NOVALIDATE 模式，给出了 ONLINE 索引建议，并在 Flyway 上下文中提到了 DDL 自动提交。但有三项关键性失败：DDL_LOCK_TIMEOUT 在全文中只字未提（A2 失败）；ENABLE NOVALIDATE 建议措辞不完整（"optional, off-peak"，约束名使用尖括号占位符）；无结构化评分卡（A8）和未覆盖风险章节（A9）。
带技能：所有 §9 章节齐全。评分卡明确将原始迁移评为 5/12 — Critical 1/3, Standard 3/5, Hygiene 1/4 — FAIL。§9.9 未覆盖风险列出 11 项缺口，包括：amount 列当前 nullability（直接影响迁移是否可行）、当前 amount 数据类型（NUMBER 精度收窄会被 Oracle 拒绝）、Flyway 会话连续性（DDL_LOCK_TIMEOUT 在会话间是否保持）。
最关键发现（A2）：不带技能在 3 个场景中共出现 3 条涉及 DDL 的会话，全部未提及 DDL_LOCK_TIMEOUT。这不是遗漏格式结构，而是 Oracle 特有知识的缺失——在活跃生产库上，任何无超时 DDL 在遇到持有行锁的长事务时立即以 ORA-00054 失败，没有重试。技能通过 §5.1 项 2 和 AE-1 强制覆盖此检查。
3. 场景 1 — 大表列类型变更¶
3.1 测试设置¶
输入：Oracle 19c EE，events 表约 8000 万行，无维护窗口。用户请求将 user_id 列从 NUMBER(10) 修改为 NUMBER(18)。
8 条断言（B1–B8）：Deep 深度分类、正确识别 NUMBER 精度扩展行为（元数据操作 vs 表重写）、完整迁移 SQL 含 DDL_LOCK_TIMEOUT、索引状态评估、UNDO/TEMP 空间评估、分阶段手动回滚、DDL 前设置 DDL_LOCK_TIMEOUT、DBMS_STATS 收集计划。
3.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| B1 | 表以 Deep 深度正式分类 | 失败 | 通过 |
| B2 | 正确识别 NUMBER(10→18) 为元数据操作（Oracle 内部 NUMBER 变长存储，无需表重写） | 失败 | 通过 |
| B3 | 提供完整可执行的迁移 SQL 方案 | 部分 | 通过 |
| B4 | 索引状态评估（DDL 后确认 STATUS=VALID） | 部分 | 通过 |
| B5 | UNDO/TEMP 表空间评估已包含 | 通过 | 通过 |
| B6 | 每阶段提供手动回滚计划（含 ABORT_REDEF_TABLE） | 通过 | 通过 |
| B7 | DDL_LOCK_TIMEOUT 在每条 DDL 前设置 | 失败 | 通过 |
| B8 | 包含 DBMS_STATS 收集计划 | 通过 | 通过 |
场景 1：不带技能 = 3 通过 + 2 部分 + 3 失败（加权 4/8 = 50%）| 带技能 = 8/8 全部通过
实际 token 消耗：不带技能 16,288 tokens（0 次工具调用）| 带技能 41,362 tokens（9 次工具调用，含全部 3 个参考文件）
3.3 关键观察¶
不带技能（B2 — 最值得关注的知识偏差）：不带技能推荐了完整的 DBMS_REDEFINITION 流程（7步工作流、CAN_REDEF_TABLE、START_REDEF_TABLE with CONS_USE_ROWID、SYNC、FINISH、ABORT），说明基准模型对 Oracle 在线重定义有扎实认知。然而它的推荐方向是错误的——NUMBER(10) → NUMBER(18) 在 Oracle 中属于精度扩展（列内部存储格式不变），Oracle 19c 将其处理为纯元数据操作，无需 DBMS_REDEFINITION，只需设置 DDL_LOCK_TIMEOUT 后执行一条 ALTER TABLE MODIFY 即可。推荐 DBMS_REDEFINITION 的结果虽然安全但过度工程化——增加了数小时的执行复杂度和潜在的 MV log 维护负担。
带技能（B2 — 精准分类的价值）：技能通过 oracle-ddl-lock-matrix.md 中的 "MODIFY column (widen)" 条目正确判断为元数据操作，将迁移分类为 WARN 而非 UNSAFE，并给出更简洁、正确的方案：ALTER SESSION SET DDL_LOCK_TIMEOUT = 10; ALTER TABLE events MODIFY (user_id NUMBER(18));，配合完整的索引状态验证和回滚路径。这是技能提供了更精确技术判断的典型案例。
基准强项：不带技能对 DBMS_REDEFINITION 工作流的知识相当完整（B5、B6、B8 全部通过），甚至包括 ABORT_REDEF_TABLE 作为回滚路径，且提供了 UNDO/TEMP 空间检查查询。两个失败项（B1 无深度分类、B7 无 DDL_LOCK_TIMEOUT）均是结构性缺失，而非工作流知识的缺失。
4. 场景 2 — 降级边界场景¶
4.1 测试设置¶
输入：版本未知，表行数未知，没有提供任何环境上下文。用户用中文直接提问："这个安全吗，直接运行就可以吗？"迁移语句：
6 条断言（C1–C6）：降级模式正式声明、拒绝无条件声称"安全"、FK 索引缺失风险（无配套索引 → 父表 DML 争用/死锁）、ENABLE 立即全表验证 → ORA-02298 孤儿行风险、推荐 ENABLE NOVALIDATE + VALIDATE 两步、§9.9 将版本未知和行数未知列为阻断性缺口。
4.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| C1 | 正式声明处于降级模式（而非 Full 模式） | 失败 | 通过 |
| C2 | 拒绝无条件声称"安全"，使用条件性语言 | 通过 | 通过 |
| C3 | 检测到 FK 索引缺失风险（无索引 → 父表 DML 争用 + 死锁风险） | 通过 | 通过 |
| C4 | 识别 ENABLE 立即全表验证 → ORA-02298 孤儿行风险 | 通过 | 通过 |
| C5 | 推荐 ENABLE NOVALIDATE + VALIDATE 两步替代方案 | 通过 | 通过 |
| C6 | §9.9 将版本未知和行数未知列为阻断性缺口 | 失败 | 通过 |
场景 2：不带技能 = 4 通过 + 0 部分 + 2 失败（加权 4/6 = 67%）| 带技能 = 6/6 全部通过
实际 token 消耗：不带技能 13,266 tokens（0 次工具调用）| 带技能 33,754 tokens（7 次工具调用，含 SKILL.md + oracle-ddl-lock-matrix.md）
4.3 关键观察¶
本次评估最重要的修正性发现：不带技能在场景 2 中表现出强大的 Oracle FK 约束专项知识——正确识别了 ORA-02298 孤儿行风险（C4 通过）、user_id 列索引缺失会导致父表 DML 锁争用和死锁（C3 通过），并给出了完整的 ENABLE NOVALIDATE + VALIDATE 两步 SQL（C5 通过）。连中文问句也被识别并以中文给出了结构清晰的回答。
带技能在场景 2 的差异化价值不在于知识内容本身，而在于：①正式命名降级模式（"MINIMAL"），防止过于自信的判定；②将版本未知和表大小未知结构化为 §9.9 阻断性缺口（不是"建议提供更多信息"，而是明确标注为"无法在此条件下给出安全判定"）；③生成了完整的评分卡（3/12 — Critical 0/3 — FAIL）作为可操作的工程判定结论。
与 mysql-migration 的关键对比：MySQL 场景 2 中，不带技能的基准在最难的断言（utf8mb4 字节边界陷阱）上答对了，而 Oracle 场景 2 中，不带技能同样对最难的技术断言（ORA-02298、NOVALIDATE 模式、死锁风险）全部答对。两个评估共同表明：现代基准 LLM 在常见 Oracle 和 MySQL 操作上的技术知识是扎实的；技能的差异化价值在于强制结构（DDL_LOCK_TIMEOUT 检查、输出契约、评分卡）和对精细分类的精准判断（NUMBER 元数据操作 vs 表重写）。
5. 综合结果¶
5.1 断言评分汇总¶
| 场景 | 不带技能通过 | 不带技能部分 | 不带技能失败 | 带技能通过 |
|---|---|---|---|---|
| 场景 0（9 条断言） | 1 | 5 | 3 | 9 |
| 场景 1（8 条断言） | 3 | 2 | 3 | 8 |
| 场景 2（6 条断言） | 4 | 0 | 2 | 6 |
| 总计（23 条） | 8 | 7 | 8 | 23 |
加权通过率（部分 = 0.5）：不带技能 = 50% → 带技能 = 100%，差值 +50 pp
5.2 核心差异点¶
| 技能增益内容 | 评估依据 |
|---|---|
DDL_LOCK_TIMEOUT 强制执行 | 不带技能在全部 3 场景共 3 条 DDL 会话中均未提及此参数；带技能通过 §5.1 项 2 和 AE-1 将其列为 Critical 项 |
| NUMBER 列精度扩展的正确分类 | 不带技能推荐了 DBMS_REDEFINITION（安全但过度工程化）；带技能通过 DDL 锁矩阵正确识别为元数据操作，给出更简洁精确的方案 |
| §9 输出契约强制执行 | 不带技能从不产生评分卡、§9.9 未覆盖风险、或结构化上下文门控表；带技能在每次运行中均完整生成 |
| 正式降级模式协议 | 带技能命名降级级别（MINIMAL/Degraded），将缺口结构化为阻断性未覆盖风险；不带技能给出有用的建议但无正式框架 |
| ORA 错误码的精确引用 | 带技能引用 ORA-00054、ORA-02296、ORA-02298、ORA-30036；不带技能在 A3/C4 中也有引用，但缺少 ORA-00054（最关键的一个） |
| 评分卡作为可操作的工程判定 | 带技能将每次迁移审查转化为 X/12 通过/失败判定；不带技能的叙述性分析无法作为阻断检查 |
5.3 基准已经较强的领域¶
不带技能的基准在以下方面表现出扎实的 Oracle 知识： - ORA-02296（NOT NULL 强制执行前已有 NULL 数据）— 场景 0 正确识别 - ORA-02298（FK VALIDATE 遭遇孤儿行）— 场景 2 正确识别 - ENABLE NOVALIDATE + VALIDATE 两步模式 — 场景 2 给出完整 SQL - FK 索引缺失的死锁风险 — 场景 2 正确识别，并说明父表 DELETE 场景 - DBMS_REDEFINITION 整体工作流 — 场景 1 给出了 CAN_REDEF → START → SYNC → FINISH → ABORT 的完整步骤 - UNDO/TEMP 空间问题意识 — 场景 1 正确识别
因此，oracle-migration 技能的核心价值不是"填补 Oracle 技术知识空白"（基准本身知识较为扎实），而是：强制执行 DDL_LOCK_TIMEOUT 这一持续被遗漏的 Oracle 特有安全参数、提供精确的 DDL 行为分类（元数据操作 vs 重写 vs DBMS_REDEFINITION 场景），以及通过 §9 输出契约确保评分卡、回滚计划和未覆盖风险章节在时间压力或上下文不完整时不被跳过。
6. Token 成本分析¶
| 场景 | 不带技能 tokens | 带技能 tokens | 额外开销 | 工具调用次数 |
|---|---|---|---|---|
| 场景 0（Standard 深度，读 SKILL.md + DDL 锁矩阵 + anti-examples） | 14,195 | 41,080 | +189% | 9 |
| 场景 1（Deep 深度，读全部 3 个参考文件） | 16,288 | 41,362 | +154% | 9 |
| 场景 2（Minimal/降级，读 SKILL.md + DDL 锁矩阵） | 13,266 | 33,754 | +154% | 7 |
| 平均 | 14,583 | 38,732 | +166% | 8.3 |
注：token 数为完整会话 token（输入 + 工具调用 + 工具结果 + 输出），由 Agent 工具 usage 字段实测。带技能的额外开销包含读取 SKILL.md（352 行）和参考文件（DDL 锁矩阵 154 行、大表迁移 303 行、anti-examples 174 行）的工具调用消耗。
+166% 的平均 token 额外开销高于 mysql-migration 评估（+51%），原因有两个：①本次评估使用 Agent 工具进行文件读取，工具调用本身消耗 tokens；②oracle-migration 参考文件包含完整的 PL/SQL 代码块（大表迁移参考文件 303 行），内容密度更高。如果将技能内容直接注入为系统提示而非通过工具读取（实际生产使用方式），额外开销将回落至 SKILL.md 约 8,000 tokens + 按需加载的参考文件，更接近 mysql-migration 的 +51% 水平。
7. 覆盖缺口与已知限制¶
| 缺口 | 严重程度 | 说明 |
|---|---|---|
DBMS_REDEFINITION vs 直接 DDL 分类准确性 | 中 | 本次评估揭示了一个边界案例：NUMBER 精度扩展是元数据操作。如果用户提供的列类型变更涉及需要表重写的情况（如 VARCHAR2 类型 → NUMBER），分类结果会不同；该边界未在 golden fixtures 中覆盖 |
| 分区键列变更场景 | 高 | §9.9 中提及，但无专用评估场景。分区键列的类型变更在 Oracle 中受限制，需要 DBMS_REDEFINITION 或分区重建；错误分类后果严重 |
| RAC 特定迁移协调 | 中 | 输入门控已询问 RAC 状态，但无专用评估场景验证 RAC 环境下的锁行为差异 |
| Edition-Based Redefinition (EBR) | 低 | 高级持续部署场景；在 §1 范围内但无评估覆盖 |
| 外键引用链（子表的子表） | 中 | 场景 2 覆盖了直接父子 FK，但多级 FK 链上的约束变更影响未评估 |
| Flashback Table 恢复流程 | 低 | 参考文件有完整文档，但无断言测试其在模型输出中的正确引用 |
8. 结论¶
oracle-migration 在 6 次真实模型运行、23 条断言的评估中，带技能配置达到 100% 断言覆盖率，加权通过率从 50% 提升至 100%（+50 pp）。
本次评估与预期最大的差异在于基准模型的表现：基准在 FK 约束、ENABLE NOVALIDATE 两步、ORA-02298 等常见 Oracle 安全模式上知识扎实，场景 2 加权通过率高达 67%。这一发现调整了技能价值的定位——技能的核心贡献是：
- 填补 DDL_LOCK_TIMEOUT 这一持续性盲点 — 基准在 3 个场景中 0/3 次提及该参数，而这是 Oracle 生产环境 DDL 失败的最常见单一原因。技能通过 §5.1 项 2 和 AE-1 将其列为 Critical 强制项。
- 精确的 DDL 行为分类 — 场景 1 揭示基准将 NUMBER 精度扩展误判为需要 DBMS_REDEFINITION 的重写操作；技能通过 DDL 锁矩阵给出更精确的元数据操作判断，避免不必要的操作复杂度。
- 结构化输出契约的完整性保障 — §9 输出契约确保评分卡、回滚计划和未覆盖风险章节在任何上下文完整性下均存在，将叙述性审查转化为可用于 CI/CD 阻断的工程判定。
- 降级模式的正式化 — 在上下文不完整时，命名的降级级别配合结构化未覆盖风险表，防止基准模型在缺少关键信息时仍输出看似合理的建议。
建议：生产就绪。对所有 Oracle DDL 审查工作流推荐使用，尤其在涉及无维护窗口的生产环境和大表操作场景中，DDL_LOCK_TIMEOUT 的强制执行是最高价值单项贡献。