1. 行业背景：提示词资产化的管理困局
随着 Cursor、Claude Desktop 以及 VSCode Copilot 在开发者群体中的全面渗透，AI 助手的使用已不再局限于简单的对话，而是演变为一种深度定制的“技能资产”。开发者开始编写大量的 SKILL.md、.cursorrules 或特定的 Workflows 来定义 AI 的行为边界。
然而，这种“提示词资产化”的趋势也暴露出明显的管理短板：
- 分发低效：技能包散落在各个项目的隐藏目录中，跨项目复用多依赖手动拷贝。
- 同步滞后：单一项目内对技能的优化难以自动反哺到其他项目，导致版本碎片化。
- 平台隔离：不同 AI 客户端（Cursor, Claude, VSCode）的配置路径与注入逻辑各异，缺乏统一的适配层。
为了解决这些问题，sk-get 尝试定义一套 AI 时代的“技能包管理规范”。
2. 架构演进：从 Git 依赖到轻量化 API
在设计之初，sk-get 的核心逻辑经历了从“重”到“轻”的彻底重构。
2.1 抛弃传统的 Git 操作
最初版本尝试通过 git clone 仓库到本地缓存目录。虽然实现路径直接，但存在两个硬伤：
- 环境强依赖：用户必须预装本地 Git 环境。
- 资源冗余：为了获取几 KB 的文本指令，却下载了整个 Git 仓库的完整历史（.git 目录往往很大），这对于追求极速体验的 CLI 来说并不可接受。
2.2 深度驱动 GitHub API
在 1.1.0 版本中，sk-get 彻底转向了 GitHub API 驱动。
- 按需下载：通过 API 获取目录树，仅针对目标 Skill 文件夹执行下载。
- 递归下载算法：GitHub API 单次请求仅返回单层内容。sk-get 实现了一套深度优先遍历算法，动态识别
dir与file类型，并在本地自动重建对应的目录层级。 - 本地双层缓存：建立本地配置文件与技能列表的双重缓存。即使在网络不稳定或达到 API 速率限制时，依然能保障基础的
ls（列表查看）功能可用。
3. 核心技术细节实现
3.1 跨平台的非破坏性注入
sk-get 的核心挑战之一是处理不同平台间巨大的配置差异：
- 目录级管理 (Cursor/Claude)：这类平台支持模块化的技能存放。工具会精准在
.cursor/skills/下建立隔离的子目录。 - 文件级注入 (VSCode)：VSCode Copilot 主要依赖
.github/copilot-instructions.md单文件。- 注入逻辑：sk-get 并非简单的覆盖，而是内置了一套区块识别机制。它通过
# Skill: <name>这种语义化锚点来定位。如果技能已存在，则精准替换该区块；若不存在，则在文件末尾追加。这种设计确保了用户手动编写的其他指令不会被误删。
- 注入逻辑：sk-get 并非简单的覆盖，而是内置了一套区块识别机制。它通过
3.2 流式交互与参数补全
为了降低学习成本，工具在 CLI 交互上结合了 commander 的指令解析与 enquirer 的动态 UI。 工具实现了一套缺失参数自动触发交互的逻辑：如果用户直接运行 sg add 而不带任何参数，程序会自动拉取远程列表弹出选择菜单，随后再弹出平台选择。这种“流式引导”让初次使用的用户无需查阅文档也能快速上手。
3.3 多源状态机管理
为了支持从任意仓库读取技能，sk-get 在底层实现了一个扁平化的多仓库状态管理模型。通过 sg repo use 切换，可以在不同的技能源之间秒级切换，同时各仓库的技能列表在本地独立缓存，互不干扰。
4. 思考与展望
sk-get 的设计初衷是让 AI 提示词从“临时脚本”向“标准化组件”转变。
在 AI 辅助开发的工具链中，CLI 工具应当保持**“极轻”、“极快”且“零侵入”**。通过 API 驱动和精准的跨平台适配，sk-get 试图为开发者提供一种更具秩序感的管理方式。如果 Prompt Engineering 是 AI 时代的核心竞争力，那么高效管理这些资产将是每位开发者的必修课。
项目开源地址：https://github.com/lyx-jay/sk-get发布版本：sk-get@1.0.3