VibeSkills 4.0发布，本地skills调度大管家

背景

随着 AI 编程和工作流工具的普及，用户往往会下载和安装大量来自社区或自行编写的 Skills（技能包），用于辅助特定任务。然而，Skills 的数量增长之后，一个普遍痛点随之出现：用户容易忘记自己已经安装了哪些 Skills，在遇到复杂任务时不知道应该调用哪些 Skills。进一步，当任务涉及多个不同领域的 Skills 复合组织调用时，人类规划起来非常复杂，需要详细向 AI 阐明每个模块要使用什么 Skills，而 AI 在执行过程中可能遗忘这些设计。现有的 Harness 框架（如 Superpower、GSD 等）大多不会主动规划利用本地的 Skills 资源，甚至有时陷入 Harness 框架与领域 Skills 资源非此即彼的调度矛盾。为了解决这些问题，项目作者在毕业一个月后推出了 VibeSkills V4.0.0 版本，彻底削去内置的 300 多个 Skills，改为在 Harness 框架下完全依赖本地用户已有的 Skills 目录进行调度，返璞归真，着力于成为用户身边顺手的 Skills 资源调度大管家。

核心内容

VibeSkills V4.0.0 是一个开源项目，核心是一个基于 Harness 框架的 Skills 调度系统。它不再内置任何 Skills，而是完全依赖用户本地 Skills 目录中已经安装的 Skills 来进行任务规划和执行。项目的工作流程分为五个阶段：

1. 确认限制需求：开始工作前，项目先确认任务目标、条件、现有材料和最终要交付的内容。需求没有确认时，流程会停在这里，确保后续计划和检查有明确依据。这一步有状态机进行最后记录。

2. 推荐规模：VibeSkills 根据任务范围、步骤、依赖关系和可装的工作推荐 L（Large）或 XL（Extra Large）规模，由用户确认。规模可控的任务按顺序推进，更大的任务拆除得更细。这一步也有状态机记录。

3. 组织技能：VibeSkills 查看本地 Skills 目录，为任务各部分选择合适的方法，并写清每个 Skills 负责什么、需要交付什么、如何确认完成。

4. 执行并记录：计划确认后，当前代理按计划完成工作。任务可以在适当时使用代码测试驱动开发（TDD）——先用失败测试确认问题，再修改并重新测试。完成、失败和阻塞都会记录，中断后也可以从先前进度继续。这一步对每一个模块工作的完成有状态机记录，保证按流程全面完成。

5. 检查结果：工作结束后，VibeSkills 把实际结果和计划逐项对照。必做内容没有完成、执行失败或仍然被卡住时，任务不会通过最终检查。

实战效果：以一个公开数据分类实验任务为例，要求使用公开数据完成可复现的分类实验，并交付数据审计、统计复核、4 张结果图、科学报告和 7 页组幻灯片。VibeSkills 与用户交流确认需求，然后拆分为 5 个工作组和 10 个工作单元，并为每个工作单元设置好对应要选择的 Skills。在用户本机 100 多个 Skills 中，它选出了 7 个适合的 Skills，分别安排负责以下工作：

• exploratory-data-analysis：整理公开数据并检查结构、质量、类别分配、重复和泄漏风险
• scikit-learn：建立与逻辑回归线路固定的对照模型，并检查能否精确复跑
• statistical-analysis：计算变量性和不确定性，并编写清晰的假设方法
• scientific-critical-thinking：复核偏倚、疏漏、泛化范围和不能下的结论
• scientific-visualization：生成 4 张可追溯数据源的 PNG 图和对应的 SVG
• sciwrite：分 5 轮检查科学报告，只确认科学内容
• presentations：制作 7 页幻灯片，逐页渲染并检查版面和数据

所有工作完成后，VibeSkills 对数据、实验结果、图表、报告和幻灯片做了 17 项检查，包括文件内容一致性、数据是否存在泄露、是否可溯源、是否有缺失等。

调用范围与使用方式：项目只路由和调度安装目录下的周围 Skills。例如，如果安装到 Codex 的 Skills 目录下，它只会调度和管理 Codex 目录下的 Skills；如果安装到 Claude 中，也只会调度 Claude 目录下的 Skills，不会串库。使用方式直接按 Skills 的调用方式，如 $vibe、/vibe。

Token 消耗：VibeSkills 会检查配置的 Skill 目录，但不会将所有的 Skills.md 全部阅读一遍。它先提取 Skill 的名称、说明、适用场景等信息，用这些信息为任务的不同部分筛选候选。只有保留下来的候选才会由 Agent 继续阅读完整的 SKILL.md。执行时也只使用已经写进计划的 Skills。因此，Token 开销主要取决于本次任务保留了多少候选、这些文档有多长，以及任务本身的复杂度，不会等同于把整个 Skill 库全文读一遍。但作者也承认，当候选较多、Skill 文档较长或任务拆分较细时，会使用更多上下文，这是调度本地优秀资源不可避免的弊端。

项目理念：作者从 V3 版本开始思考项目最终价值。一开始想把太多东西塞进去——好的 Skills、自动化调度架构、自动化组织本地 Skills 功能、自动化 Harness 框架和记忆管理。但后来发现维护一个 Skills 仓库非常困难，因为大家需求各异，且存在安全风险担忧。之前的调度框架又比较依赖内置好的 Skills 模块，因为预置了描述才能自动化路由。最终作者决定大改项目，让项目回归初心：纯粹、通用，成为用户身边顺手的 Skills 资源调度大管家，帮助用户遇到复杂任务时慢慢捋清楚有哪些模块、有哪些好的经验可以复用，然后交付