pg-migration 技能评估报告¶
评估日期：2026-04-18 | 评估方法：A/B 实测对比 | 断言总数：23 | 场景数：3
汇总指标¶
| 指标 | 有 Skill | 无 Skill | Delta |
|---|---|---|---|
| 断言通过率（严格 PASS） | 23/23 (100%) | 20/23 (87.0%) | +13 pp |
| 断言通过率（含 PARTIAL） | 23/23 (100%) | 22/23 (95.7%) | +4.3 pp |
| Critical 断言通过率 | 9/9 (100%) | 7/9 (77.8%) | +22.2 pp |
| 平均 Token 消耗 | 18,900 | 35,054 | −46.1% |
| 额外 Tool Calls（Web搜索等） | 0 次/场景 | 2.3 次/场景 | −100% |
| Scorecard 输出包含 "Data basis" | 3/3 场景 | 0/3 场景 | +100% |
关键发现：pg-migration 技能的基线质量高于同类迁移技能（mysql-migration 基线 52%，pg 基线 87%），反映出 PostgreSQL 迁移安全规范已被广泛训练入基础模型。技能的核心价值在于三点：结构强制性（全部 §9 节强制输出）、Token 效率（节省 46%）、评估框架一致性（Gate 分析、Data basis 标注、原始 SQL 独立评分）。
评估方法¶
框架：A/B 双盲测试。每个场景并行运行两个子代理： - 无 Skill 组：仅接收场景描述 + SQL，无任何 SKILL.md 内容 - 有 Skill 组：接收场景描述 + SQL + 完整 SKILL.md + 按深度加载的参考文件
评分标准： - PASS：输出明确包含该要素（精确语言或等价表述） - PARTIAL：部分提及但不完整或方法有误 - FAIL：输出中完全缺失该要素
场景设计：3 个场景覆盖技能的三个核心工作模式——标准审查（Standard depth）、大表高危迁移（Deep depth）、降级模式（Minimal context）。
场景 0：标准 DDL 审查¶
输入：PostgreSQL 14.5，users 表，2M 行，1,500 QPS，streaming replication，golang-migrate，无维护窗口。
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMPTZ NOT NULL DEFAULT now();
CREATE UNIQUE INDEX ON users(email);
ALTER TABLE sessions ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id);
断言评分（8 条）：
| # | 断言 | 有 Skill | 无 Skill | 说明 |
|---|---|---|---|---|
| A0-1 | 识别 CREATE UNIQUE INDEX 缺失 CONCURRENTLY（ShareLock 阻塞写入） | PASS | PASS | 两者均明确指出 |
| A0-2 | 建议 FK 使用 NOT VALID + VALIDATE 两步模式 | PASS | PASS | 两者均提供修正 SQL |
| A0-3 | 将"缺少 lock_timeout"列为关键风险项（Critical 层） | PASS | PASS | 两者均在摘要中明确 |
| A0-4 | 分析 DEFAULT now() 为 volatile 函数，可能触发表重写（非元数据操作） | PASS | PASS | 无 Skill 组同样做出精确分析 |
| A0-5 | 每条 DDL 提供锁级别分类表（AccessExclusiveLock / ShareLock） | PASS | PASS | 两者格式基本一致 |
| A0-6 | 输出 X/12 格式 Scorecard（Critical Y/3, Standard Z/5, Hygiene W/4） | PASS | PASS | 无 Skill 组自发产生，与 Skill 格式相同 |
| A0-7 | §9.9 / Uncovered Risks 包含 ≥3 条假设或未确认项 | PASS | PASS | 无 Skill 组列出 7 条，有 Skill 组结构化呈现 |
| A0-8 | 输出包含 "Data basis: full/degraded/minimal" 评估依据标注 | PASS | FAIL | 无 Skill 组从不包含此标注 |
场景 0 小结： - 有 Skill：8/8 (100%) - 无 Skill：7/8 (87.5%)，差距在于 Data basis 标注缺失
关键差异分析：无 Skill 组（33,097 tokens）对核心 DDL 安全问题（CONCURRENTLY、NOT VALID、lock_timeout）的识别准确率与有 Skill 组（19,042 tokens）相当。主要差距体现在： 1. Token 消耗高出 74%，且使用 2 次额外工具调用（推测为 Web 搜索） 2. 缺少强制性的评估依据标注，无法追溯评估的信息完整度
场景 1：大表高危迁移¶
输入：PostgreSQL 13.8，events 表，60M 行，~85 GB，24/7 服务，无维护窗口，streaming（2 replicas）+ logical replication（analytics）。
ALTER TABLE events ALTER COLUMN payload TYPE jsonb USING payload::jsonb;
CREATE INDEX ON events(user_id, created_at);
ALTER TABLE events DROP COLUMN deprecated_field;
断言评分（9 条）：
| # | 断言 | 有 Skill | 无 Skill | 说明 |
|---|---|---|---|---|
| A1-1 | 识别 ALTER COLUMN TYPE 为全表重写（AccessExclusiveLock 持续 15-90+ 分钟） | PASS | PASS | 两者均量化 85 GB 风险 |
| A1-2 | 推荐 pg_repack 或 create-swap-rename 替代直接 ALTER | PASS | PASS | 两者均提出影子表方案 |
| A1-3 | 建议 CREATE INDEX 使用 CONCURRENTLY | PASS | PASS | 明确指出 ShareLock 阻塞写入 |
| A1-4 | 所有 DDL 执行前强制设置 lock_timeout | PASS | PASS | 均包含在修正 SQL 中 |
| A1-5 | 识别 DROP COLUMN 在 COMMIT 后不可逆（数据无法恢复） | PASS | PASS | 均标注 irreversible |
| A1-6 | 量化磁盘空间需求（需 ~90 GB 额外空间）及 WAL 放大影响 | PASS | PASS | 两者给出具体估算 |
| A1-7 | 提供零停机分阶段执行计划（影子表→回填→原子交换→清理） | PASS | PASS | 5 阶段方案完整 |
| A1-8 | 识别逻辑复制 DDL Gap（analytics replica 需独立 DDL 同步） | PASS | PASS | 均标注为高风险项 |
| A1-9 | 原始 SQL 独立评分：Critical 全部 FAIL（lock_timeout/CONCURRENTLY/Rollback 均缺失） | PASS | PARTIAL | 无 Skill 将"§9.7 回滚"计入原始评分得 Critical 1/3，混淆了原始提交与审查输出 |
场景 1 小结： - 有 Skill：9/9 (100%) - 无 Skill：8.5/9 (94.4%)，差距在于原始 SQL 评分方法有误
关键差异分析：无 Skill 组（38,406 tokens，3 次工具调用）在技术内容上与有 Skill 组（19,069 tokens，0 次工具调用）高度一致，但存在评分方法缺陷：无 Skill 在对提交 SQL 评分时，将 §9.7 中自行补充的回滚方案计为原始 SQL 的通过项（Critical 1/3 而非 0/3），导致对原始迁移风险的评判偏宽。
有 Skill 组正确执行了"原始 SQL 独立评分"规则：
"The original submitted SQL would score 0/3 Critical: no lock_timeout, no CONCURRENTLY, no rollback plan — overall FAIL."
场景 2：降级模式边界¶
输入：PostgreSQL 版本未知（可能 11–15），products 表，行数未知，大小未知，QPS 未知，复制类型未知。
ALTER TABLE products ADD COLUMN price_usd NUMERIC(10,2) NOT NULL;
ALTER TABLE products ALTER COLUMN description TYPE TEXT;
断言评分（6 条）：
| # | 断言 | 有 Skill | 无 Skill | 说明 |
|---|---|---|---|---|
| A2-1 | 明确进入 Minimal/Degraded Mode（不凭空推断缺失信息） | PASS | PASS | 两者均声明 Minimal mode 并列出保守假设 |
| A2-2 | 遵守 "Hard rule: Never claim SAFE without evidence" | PASS | PARTIAL | 无 Skill 组做到了保守评估，但未显式声明此规则；在缺少该规则的情况下，行为仍可靠 |
| A2-3 | 列出所有保守假设（PG 版本、行数、QPS、复制类型） | PASS | PASS | 无 Skill 列出 8 条假设，有 Skill 列出 18 条 |
| A2-4 | 识别 ALTER COLUMN TYPE TEXT 的版本相关重写风险（VARCHAR→TEXT 在 PG 12+ 为元数据操作，其他情况需重写） | PASS | PASS | 均正确说明版本差异 |
| A2-5 | §9.9 / Uncovered Risks 以完整的表格格式呈现所有已知未知量（≥8 条） | PASS | PASS | 两者均超出 8 条要求 |
| A2-6 | 识别 ADD COLUMN NOT NULL 无 DEFAULT 在非空表上的硬错误（非性能问题，是执行时立即报错） | PASS | PASS | 两者均精确识别此硬错误 |
场景 2 小结： - 有 Skill：6/6 (100%) - 无 Skill：5.5/6 (91.7%)，差距在于 "Never claim SAFE" 规则的显式执行
关键差异分析：降级模式下两组输出最接近，差异最小。无 Skill 组（33,658 tokens）同样进入了正确的保守模式，但这依赖于 LLM 内部推理而非显式规则约束。在极端信息缺失场景下（如运维新人或弱提示），有 Skill 组的 Hard Rule 显式约束提供了更强的防护。
汇总指标¶
| 断言 ID | 类别 | 有 Skill | 无 Skill |
|---|---|---|---|
| A0-1 | Critical (S0) | PASS | PASS |
| A0-2 | Critical (S0) | PASS | PASS |
| A0-3 | Critical (S0) | PASS | PASS |
| A0-4 | Standard (S0) | PASS | PASS |
| A0-5 | Standard (S0) | PASS | PASS |
| A0-6 | Standard (S0) | PASS | PASS |
| A0-7 | Hygiene (S0) | PASS | PASS |
| A0-8 | Hygiene (S0) | PASS | FAIL |
| A1-1 | Critical (S1) | PASS | PASS |
| A1-2 | Critical (S1) | PASS | PASS |
| A1-3 | Critical (S1) | PASS | PASS |
| A1-4 | Critical (S1) | PASS | PASS |
| A1-5 | Standard (S1) | PASS | PASS |
| A1-6 | Hygiene (S1) | PASS | PASS |
| A1-7 | Standard (S1) | PASS | PASS |
| A1-8 | Hygiene (S1) | PASS | PASS |
| A1-9 | Standard (S1) | PASS | PARTIAL |
| A2-1 | Standard (S2) | PASS | PASS |
| A2-2 | Critical (S2) | PASS | PARTIAL |
| A2-3 | Standard (S2) | PASS | PASS |
| A2-4 | Standard (S2) | PASS | PASS |
| A2-5 | Hygiene (S2) | PASS | PASS |
| A2-6 | Critical (S2) | PASS | PASS |
| 合计 | — | 23/23 (100%) | 20/23 + 2 PARTIAL = 87.0% |
Token 效费比分析¶
| 指标 | S0（Standard） | S1（Deep） | S2（Minimal） | 平均 |
|---|---|---|---|---|
| 无 Skill 总 Token | 33,097 | 38,406 | 33,658 | 35,054 |
| 有 Skill 总 Token | 19,042 | 19,069 | 18,589 | 18,900 |
| Token 节省 | 14,055 (42%) | 19,337 (50%) | 15,069 (45%) | 46.1% |
| 无 Skill Tool Calls | 2 次 | 3 次 | 2 次 | 2.3 次 |
| 有 Skill Tool Calls | 0 次 | 0 次 | 0 次 | 0 次 |
效率悖论：有 Skill 组虽然接收了更长的输入（SKILL.md ~4,500 tokens + 参考文件 ~1,800–5,600 tokens），但总 Token 消耗反而低 46%。原因如下：
- 输出聚焦：结构化框架使模型直接按 §9 节填充，而非先进行探索性推理再组织输出
- 消除工具调用：无 Skill 组需要 2–3 次 Web 搜索获取 PostgreSQL 最新文档；有 Skill 组将知识内嵌，0 次额外调用
- 避免重复推导：无 Skill 组每次都重新"发现"最佳实践（CREATE INDEX CONCURRENTLY、NOT VALID 模式等），有 Skill 组从框架直接取用
ROI 估算（基于 Claude API 定价，仅供参考）：
| 场景 | 无 Skill 成本估算 | 有 Skill 成本估算 | 单次节省 |
|---|---|---|---|
| Standard DDL 审查 | ~$0.052 | ~$0.030 | ~$0.022 |
| 大表高危迁移 | ~$0.061 | ~$0.030 | ~$0.031 |
| 月度 100 次审查 | ~$5.60 | ~$3.00 | ~$2.60/月 |
注：以上基于 Sonnet 4 API 输入价格估算，仅反映 Token 成本差异，不含工程师时间价值。
核心发现¶
发现 1：pg-migration 基线强于同类迁移技能¶
| 技能 | 基线（无 Skill）通过率 | 有 Skill 通过率 | Delta |
|---|---|---|---|
| mysql-migration | 52% | 100% | +48 pp |
| pg-migration | 87% | 100% | +13 pp |
| oracle-migration | （未评估） | — | — |
PostgreSQL 迁移规范（CONCURRENTLY、NOT VALID、lock_timeout）已深度训练进入基础模型，甚至能自发产生与技能格式相同的 X/12 Scorecard 和 §9.9 Uncovered Risks。这源于 PostgreSQL 迁移最佳实践的广泛文档化。
发现 2：技能价值集中在框架强制性，而非知识传递¶
无 Skill 组的三处核心失分均属于"框架合规性"问题，而非技术知识缺失： - A0-8：不包含 "Data basis" 标注 → 审查质量可追溯性为零 - A1-9：将自行添加的 §9.7 回滚计入原始 SQL 评分 → 风险判断偏宽 - A2-2：未显式声明 "Never claim SAFE without evidence" 规则 → 在弱提示下行为不稳定
发现 3：工具调用依赖是隐性成本¶
无 Skill 组每场景平均使用 2.3 次工具调用（推测为 Web 搜索 PostgreSQL 文档），带来三重问题： 1. Token 成本：工具调用结果累积到上下文，放大总消耗 2. 延迟风险：网络依赖增加不确定性 3. 一致性风险：搜索结果随时间变化，技能知识库固定且经过审核
发现 4：Token 效率是 pg-migration 技能的第一差异化优势¶
与 mysql-migration（+51% Token 开销）相反，pg-migration 节省 46% Token。原因：PostgreSQL 迁移 DDL 本身更复杂（锁矩阵、CONCURRENTLY 限制、pg_repack 方案），无 Skill 组需更多探索推理，而有 Skill 组通过结构化框架直接命中要点。
与同类技能对比¶
| 维度 | pg-migration | mysql-migration | 说明 |
|---|---|---|---|
| 技能深度（SKILL.md 行数） | 353 行 | ~300 行 | pg 因锁矩阵、CONCURRENTLY 特殊规则更复杂 |
| 参考文件数量 | 3 个（lock-matrix, large-table, anti-examples） | 类似 3 个 | 结构对称 |
| 基线通过率 | 87% | 52% | pg 基线显著更强 |
| Token 节省 | −46% | +51%（技能增加消耗） | pg 通过聚焦输出抵消了更长输入 |
| 最大价值场景 | 一致性和效率 | 知识传递和错误防止 | 角色定位不同 |
| 独特技术覆盖 | CONCURRENTLY 限制、NOT VALID、transactional DDL rollback | gh-ost/pt-osc、INSTANT algorithm、utf8mb4 边界 | 各有专属领域 |
结论¶
pg-migration 技能评定：生产就绪，推荐用于所有 PostgreSQL DDL 审查工作流。
技能在知识内容上与基线 Claude 高度重叠（基线已达 87%），但提供了基线无法保证的三个关键能力：
- 结构强制性：§9.1–§9.9 全部 9 节必须输出，Data basis 必须标注，消除"漏审"风险
- Token 效率：46% Token 节省使其成为 29 个技能中 ROI 最高的迁移类技能之一
- 评估框架一致性：Gate 分析、原始 SQL 独立评分、Scorecard 格式强制执行，使审查结果可重复、可比较、可审计
推荐使用场景： - 所有涉及 ALTER TABLE、CREATE INDEX、CONSTRAINT 的 PostgreSQL 生产变更 - 大表迁移（>10M 行）规划阶段，作为 pg_repack vs. shadow table 决策的判断框架 - CI/CD 流水线中的迁移文件审查（利用 Token 效率优势，低成本高频运行）
不推荐场景： - 纯查询优化、连接池调优 → postgresql-best-practise - 应用代码安全审查 → security-review