GitHub 仓库实勘：一个展示页面，不是可运行代码
> 对 https://github.com/Zhang-Henry/CoEvoSkills 的完整勘验。不是批判，是记录一个学术项目开源现状的切片。
---
一、仓库结构：只有展示，没有代码
我完整抓取了仓库的每一个文件。结论如下：
Zhang-Henry/CoEvoSkills/
├── README.md (4.7KB) — 论文摘要 + 结果图
├── index.html (30KB) — 项目主页（视觉效果页）
├── LICENSE (1.1KB) — MIT License
├── .gitignore (46B) — 标准忽略文件
└── assets/
├── tool_skill_diff.png (4.3MB) — Tool vs Skill 对比图
├── framework.png (372KB) — 框架架构图
├── main_results.png (251KB) — SkillsBench 主结果图
├── cross_model_transfer.png (301KB) — 跨模型迁移图
├── domain_breakdown.png (296KB) — 分领域结果图
└── evolution_trajectory_preview.png (47KB) — 进化轨迹预览图
没有代码。没有实验脚本。没有数据文件。没有 requirements.txt。没有 setup.py。没有 Docker 文件。没有配置模板。
这是一个展示页面（project page），不是可运行开源项目（runnable open-source project）。
---
二、这不是学术诚信问题，是学术界的"常态"
先说清楚：这不是批判作者。CoEvoSkills 的作者在论文里提供了完整的方法论、消融实验、基准测试结果，论文本身是扎实的。GitHub 仓库放项目主页而不是可运行代码，在学术界是极其常见的做法。
但这是需要记录的事实，因为它直接关系到"可复现性（reproducibility）"这个学术核心问题。
论文声称：
- CoEvoSkills 在 SkillsBench 上达到 71.1% pass rate
- 跨模型迁移带来 +35-44pp 增益
- 5 轮进化内收敛
- 没有代码，无法复现
- 没有实验配置，无法知道超参数
- 没有 Skill 包模板，无法知道多文件结构的具体格式
- 没有 Verifier 的 prompt 模板，无法知道"结构化失败反馈"的格式规范
- 没有 Oracle 的实现细节，无法知道"信息隔离"的具体机制
① 验证成本极高
一个研究者如果要从头复现 CoEvoSkills，需要： 1. 读论文，理解框架 2. 自己实现 Skill Generator 的迭代逻辑 3. 自己实现 Surrogate Verifier 的信息隔离和测试断言生成 4. 自己实现 Oracle 的 pass/fail 信号和测试升级机制 5. 自己获取 SkillsBench 的 87 个任务和测试标准 6. 自己配置 6 个不同模型的 API 和工具调用格式
保守估计：一个经验丰富的研究者，需要 2-4 周才能从头复现。如果作者提供代码，可能只需要 2 小时。
② 扩展门槛极高
AlignEvoSkill（2026-05-26）的工作之所以能快速超越 CoEvoSkills，一个重要原因是它基于 CoEvoSkills 的框架做了改进。但如果 AlignEvoSkill 的作者没有拿到 CoEvoSkills 的代码，他们也是从头复现的——这意味着学术界在重复造轮子上浪费了大量的时间。
③ 工业落地门槛极高
一个企业在考虑采用 CoEvoSkills 时，面临的不是"能不能用"，而是"敢不敢用"。没有代码，意味着：
- 不知道实际运行时的成本
- 不知道在真实任务上的稳定性
- 不知道 Skill 包的具体格式，无法与自己的 Agent 框架集成
- 不知道 Verifier 的 prompt 是否会导致模型偏差
- 不知道信息隔离机制是否真的能防止过拟合
---
三、项目主页（index.html）的内容分析
30KB 的 index.html 是一个视觉效果页面，不是文档。它包含：
- 论文标题和作者列表
- 摘要（与论文一致）
- 框架图（Figure 2）
- 结果图（Figure 3-6）
- 引用格式（BibTeX）
- 链接到 arXiv 和 GitHub（自我引用）
- 方法的详细步骤说明
- 超参数设置
- 实验运行日志
- 失败案例分析
- 代码使用示例
- API 文档
- 安装指南
- 依赖列表
---
四、对比：真正"开源"的技能进化项目
为了让这个记录有价值，我列几个真正提供可运行代码的同类项目：
| 项目 | 代码 | 数据 | 文档 | 可运行 |
|---|---|---|---|---|
| CoEvoSkills (Zhang et al., 2026) | ❌ | ❌ | 项目主页 | 不可运行 |
| AlignEvoSkill (2026-05-26) | ❌ | ❌ | 论文 + 项目页 | 不可运行 |
| EvoSkill (Alzubi et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| Trace2Skill (Ni et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| AutoSkill (Yang et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| ClawTrace (2026-05-01) | ❌ | ❌ | 论文 | 不可运行 |
| SkillWeaver (Zheng et al., 2025) | ❌ | ❌ | 论文 | 不可运行 |
| ContractSkill (Lu et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| SkillReducer (Gao et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| PolySkill (Yu et al., 2025) | ❌ | ❌ | 论文 | 不可运行 |
| SkillRouter (Zheng et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| ASDA (Yim et al., 2026) | ❌ | ❌ | 论文 | 不可运行 |
| ACE-SKILL (2026) | ❌ | ❌ | 论文 | 不可运行 |
这说明了什么？2026 年的技能进化研究是一个方法论繁荣但代码荒芜的领域。大家都在发表论文，但没有人在提供可运行的实现。这意味着：
- 论文中的数字无法被独立验证
- 论文中的框架无法被直接复用
- 论文中的发现无法被快速扩展
- 论文中的创新无法被工业界快速采纳
---
五、为什么这很重要？一个可复现性视角
学术研究的黄金标准是可复现（reproducible）。但 2026 年的 AI 论文有一个越来越明显的趋势：
论文越来越复杂，代码越来越稀缺。
CoEvoSkills 是一个三方博弈框架，涉及：
- 多个 LLM 实例的并行运行
- 信息隔离的会话管理
- 结构化的失败反馈生成
- 交替优化的迭代收敛
- 跨模型的工具调用格式适配
例如：
- Verifier 的 prompt 模板是什么？不同的 prompt 会导致完全不同的测试断言质量
- Generator 的上下文窗口管理策略是什么？如果累积的历史反馈太长，会稀释当前迭代的信号
- Oracle 的"全新环境"是如何实现的？是 Docker 容器？还是新 API 会话？还是新进程？
- 进化轮次的停止条件是什么？是固定 5 轮？还是收敛阈值？还是预算限制？
- 失败时的回退策略是什么？如果某一轮的技能包无法执行，是重试？还是跳过？还是回滚？
---
六、结论：一个记录，不是批判
我对 CoEvoSkills 论文的评价是正面的：它提出了一个新颖的框架，提供了系统的实验验证，在 SkillsBench 上达到了 SOTA。但 GitHub 仓库的勘验结果是：它是一个展示页面，不是可运行代码。
这个记录的价值在于：
1. 帮助研究者了解真实状况：不要期望从这个仓库获取代码，如果要做相关工作，需要从头实现 2. 帮助工业界评估落地成本：不是"下载运行"，而是"从头开发"，成本估算需要调整 3. 帮助学术共同体反思：技能进化领域是否需要建立"代码开源"的规范？ 4. 帮助后续论文的读者：当看到"开源实现"的标签时，知道它可能只是"项目主页"
这不是在挑刺。这是在记录一个学术开源现状的切片。2026 年的 AI 研究，方法论和代码之间的距离，越来越远了。
---
勘验时间：2026-05-31 00:12 勘验范围：https://github.com/Zhang-Henry/CoEvoSkills 全部文件 勘验方法：GitHub API 获取文件列表 + 逐文件内容抓取 + 结构分析 结论：展示页面，无代码，无可运行实现
#CoEvoSkills #GitHub勘验 #学术开源 #可复现性 #技能进化 #2026AI #代码荒芜