go-ci-workflow Skill 评估报告¶

评估日期: 2026-03-12 评估对象: go-ci-workflow 评估方法: skill-creator 框架 (3 场景 × 2 配置 = 6 次运行)

参考基准: issue2md 项目(https://github.com/johnqtcg/issue2md) 真实 CI 工作流 (.github/workflows/ci.yml)

go-ci-workflow 是一个面向 Go 仓库的 GitHub Actions CI 设计与重构 skill，用于根据仓库结构、Makefile 入口和测试类型生成诚实、可维护、与本地执行方式一致的 CI 工作流。它最突出的三个亮点是：先做 repository shape 检测，再决定 workflow 架构，避免把不适合的 CI 模板硬套到仓库上；强强调 Make-driven delegation，并在缺少稳定入口时提供显式 fallback，保证“本地怎么跑，CI 就尽量怎么跑”；同时对工具版本锁定、输出合约和本地等价标记有统一规范，便于长期维护和排障。

一、评估概览¶

本次评估从实际任务表现和 Token 效费比两个维度对 go-ci-workflow skill 进行全面评审。利用 issue2md 项目的真实 Makefile 和 CI 工作流作为参考基准，设计 3 个递进场景，共 35 条 assertion 进行评分。

二、测试方法¶

2.1 场景设计¶

2.2 参考基准¶

issue2md 项目真实 CI 工作流特征： - 6 个独立 Job: ci, docker-build, api-integration, e2e-web, govulncheck, fieldalignment - 核心 Gate 通过 make ci COVER_MIN=80 委托 - E2E 仅在 push/schedule 触发 - 工具版本与 Makefile 精确对齐 - 无 concurrency（可改进点）

三、Assertion 通过率¶

3.1 场景 1：从零创建 CI (15 项)¶

3.2 场景 2：重构劣质 CI (12 项)¶

3.3 场景 3：无 Makefile Go 库 (8 项)¶

3.4 总览¶

3.5 趋势分析：Skill 优势随提示信息量反向变化¶

结论: 当提示本身包含足够多的结构信息时，Baseline 能达到接近 Skill 的水平。但当提示信息量低（如场景 3），Baseline 完全缺乏 Skill 提供的降级处理、等价标记等概念。Skill 的核心价值在于结构化的知识补全，尤其是提示中未提及的最佳实践。

四、与真实 CI 的对比分析¶

issue2md 项目有一个人工编写的高质量 CI 工作流。将 With-Skill 输出与真实 CI 对比：

关键发现: - With-Skill 输出在 Job 架构和 Make 委托上与真实 CI 高度一致 - With-Skill 甚至改进了真实 CI（添加了 concurrency 和 permissions，真实 CI 缺少这两项） - Without-Skill 的 Docker 构建使用 inline 命令而非 make docker-build，违反本地等价原则 - Without-Skill 的 E2E Job 添加了不必要的 server startup 逻辑（curl 轮询等），增加了复杂性

五、逐维度对比分析¶

5.1 Make-driven 委托（核心差异）¶

Skill 的 "Execution Priority" 规则确保了一致的 Make 委托。Baseline 在场景 2（有明确提示）中做到了一致委托，但在场景 1（无提示）中 Docker 构建回退为 inline。

5.2 Output Contract（Skill 独有）¶

With-Skill 在每个场景均产出结构化报告：

Without-Skill 均无此类结构化输出。

5.3 降级处理（场景 3 关键差异）¶

场景 3 暴露了 Baseline 在 无结构化指导 下的最大弱点： - 使用 @latest（非确定性构建） - 硬编码 Go 版本 - 无 concurrency - 无降级意识（不知道自己缺少 Makefile 应该标注）

5.4 安全与权限¶

两者都设置了 permissions，但 With-Skill 在场景 1 使用了更严格的 deny-all default (permissions: {}) + job-level escalation 模式，并在 Output Contract 中显式分析了 Fork PR 安全性。

六、Token 效费比分析¶

6.1 Skill 体积¶

6.2 典型加载场景¶

6.3 效费比计算¶

6.4 与其他 Skill 效费比对比¶

go-ci-workflow 的 SKILL.md 效费比最优（~45 tok/1%），但参考资料体量大（~10,100 tokens），导致典型加载的效费比较差（~136 tok/1%）。这与 go-makefile-writer 的模式类似。

6.5 Token 分段效费比¶

高杠杆指令（~610 tokens SKILL.md → 11.5 条 assertion 差值）占 SKILL.md 的 ~41%，贡献了全部直接差异。

七、综合评分¶

7.1 分维度评分¶

7.2 加权总分¶

7.3 与其他 Skill 综合评分对比¶

go-ci-workflow 综合评分略低于前两个 skill，主要受限于 Token 效费比维度（5.5/10）。参考资料总量 ~10,100 tokens 是所有已评估 skill 中最大的，而典型加载 ~4,500 tokens 的效费比（~136 tok/1%）也偏高。

失分分析: - Token 效费比 (5.5/10): 参考资料过于庞大。workflow-quality-guide.md（445 行）和 golden-examples.md（385 行）合计占 ~5,600 tokens，但在评估中只提供间接贡献 - Assertion delta (9.0/10): 场景 2 的 delta 仅 +8pp（baseline 已达 92%），拉低了整体 delta

亮点: - 降级处理 (10.0/10): 场景 3 的 +94pp delta 是所有已评估 skill 中单场景最大差异，证明了 Degraded Output Gate 的独特价值 - SKILL.md 效费比: ~45 tok/1% 是所有 skill 中最优的，说明核心规则本身非常紧凑高效

八、结论¶

go-ci-workflow skill 在三个核心领域提供了显著价值：

1. 降级处理（+94pp 单场景 delta）: 这是所有已评估 skill 中单场景最大差异，证明了 Degraded Output Gate 和 Local Parity 标记的独特价值。Baseline 模型在无 Makefile 环境下完全缺乏降级意识。

2. Make-driven 委托一致性: 确保所有 Job 通过 Makefile targets 执行，与本地开发行为一致。Baseline 在无明确提示时会退化为 inline 命令（如场景 1 的 Docker 构建）。

3. Output Contract: 结构化报告使 CI 工作流变更可审计、可追溯，包括仓库形状、执行路径分类、缺失 targets 等关键信息。

主要风险: 参考资料总量 ~10,100 tokens 是所有已评估 skill 中最大的，典型加载 ~4,500 tokens。通过精简 workflow-quality-guide.md 和 golden-examples.md，可减少 ~24% 的 token 开销，将 tokens/1% 从 ~136 降至 ~103。

与真实 CI 的对比验证了 skill 的实用性: With-Skill 输出不仅匹配了 issue2md 项目手工编写的 CI 质量，还在 concurrency 和 permissions 两个维度上改进了真实 CI。