在 Cursor 中“安装成功”至少要拆成三件事：文件放到了预期位置，Agent 能发现并调用，实际任务产生了可检查的结果。下载器退出码为零只证明其中一部分。本文按找技能、安装进项目、配置与排错三类场景，完成一次可复查的安装演练。案例是一份虚构博物馆礼品库存演示项目的运行手册，不使用真实库存或客户数据，也不声称已经在读者机器上执行安装。
先纠正路径与概念
Skill、编辑器扩展、规则与 MCP 服务是不同对象。Skill 是包含 SKILL.md 及可能的脚本、资源的目录；扩展改变编辑器能力，规则提供项目约束，MCP 接入工具服务。把它们的安装命令混用，容易得到“文件存在但行为没变化”的结果。 截至本文核对，Cursor 官方技能文档列出项目级 .cursor/skills/ 与 .agents/skills/，以及对应用户级目录。不能把 .cursor/rules/ 当成所有 SKILL.md 包的通用目的地。为本次演练选择项目级 .cursor/skills/writing-guidelines/SKILL.md；这只说明本例目标位置，其他宿主和安装器仍需另查。 Agent Skills 规范说明包的元数据与资源组织；GitHub 上的 agentskills/agentskills 是可检查的规范与参考实现来源，适合核对格式，不代替宿主加载和运行验收。优先复用规范，没必要自己发明一个不兼容的安装目录结构。
场景一：从任务找候选，而不是从热度批量安装
先写一句要完成的事：“审阅礼品库存演示项目的启动手册，找出不清楚的前提、命令解释和故障说明，输出带位置的修改建议，不改源文件。”输入是脱敏 Markdown，输出是问题表。这个任务需要技术写作审阅，不需要浏览器控制、生产数据库或自动发布权限。 先安装或启用 SkillPI Skill Finder，以明确任务搜索候选。检查官方仓库、当前安装说明及你的宿主支持；不要把查找器的搜索结果直接当成执行许可。候选详情需要核对完整源路径、版本、许可证、依赖、写入范围和网络要求。名称相似时记录完整仓库与目录，不按同名包猜来源。 本例目标是可验证的 Writing Guidelines：它审阅技术说明，可能需要读取关联写作指南，因此网络与输入文件都要可用。它不是安装器，也不会证明手册里的命令实际能运行。把这一边界写进候选记录，避免装完后把文案建议误当作功能测试。 如果后续任务是检查本地库存演示网页，可另选 Webapp Testing，它用于 Python Playwright 浏览器验证，需要可运行站点、浏览器依赖和启动信息。不要为了本轮只读手册审阅提前装整套测试依赖。
场景二：把完整包放进确定的作用域
先备份同名包并记下已有项目改动。确定是仅本项目使用，还是个人多个项目都要使用；首次试验采用项目范围容易观察影响。安装记录写清目标 Agent、范围、绝对目的地、来源提交和时间，不只留一行“已安装”。 从已核对的源版本取得完整目标技能目录，保留它引用的脚本、references、assets 与其他文件。只复制 SKILL.md 可能导致相对引用失效；复制整个多技能仓库又可能引入不需要的包。检查解压后的实际结构，确保 SKILL.md 位于目标技能目录，避免无意多套一层仓库名或覆盖已有资源。 若使用安装器，先读它当前帮助，显式选择目标宿主和作用域，执行后核对实际文件清单。npx 命令可能下载并执行包，不应被当成单纯复制文件；不要从不明镜像复制一行命令就运行。本文不提供未经核验的统一安装命令，也不假设每个安装器都具有同一个 list 或 verify 子命令。 在例子中，检查 writing-guidelines 的名称与描述，确认引用资源存在，并保存源提交。已有同名技能时先比较来源和内容，决定替换、保留或停止；不要静默覆盖。相对路径从技能根目录解释，Windows 与其他系统的路径写法分别确认，不把波浪号是否展开当成理所当然。
安装验收：发现、调用、产物三步各有证据
第一步看 Cursor 的技能列表是否出现目标名称及合理描述。没有出现先停在发现问题，不继续宣称安装成功。第二步在当前支持的调用入口明确选择目标技能，让它处理那份虚构运行手册；要求只读并输出文件位置、问题、原因、建议。能在列表中看到与真正被调用是两回事。 第三步检查产物是否对应输入。假设手册写“启动后访问页面”，却缺端口和必要环境变量，合格建议应指向该段落并说明缺少哪些信息。写作技能不能擅自编造端口、凭证或服务地址；未知内容交给项目负责人补充。另用无关任务检查它是否不恰当地接管流程，避免描述过宽造成误触发。 输出验收记录：来源版本、目的地、发现结果、调用方式、输入样本、建议示例和未验证事项。没有网络读到关联指南时，应说明审阅依据不足；不要假装按指南完成。若再装 Webapp Testing，另开本地网页任务并记录浏览器证据，不把手册检查结果沿用为网页测试通过。
场景三：按故障层级排查配置
文件没找到时，核对项目根、宿主范围、安装器输出与实际目录。Agent 找不到时，检查 SKILL.md 名称、元数据、当前工作项目及宿主的加载说明。不要随意把文件搬进 rules 目录碰运气；规则迁移与技能安装是不同变更，应分别备份和验证。 找得到但不自动触发时，检查任务是否匹配描述以及是否配置为手动调用。先手动验证一次，区分触发问题与执行问题。能调用但失败时，检查脚本、资源、运行时、工作目录和网络前提。错误在这里就修这里，不要用重装编辑器掩盖缺依赖。 多份同名技能同时存在时，记录项目与用户范围中的来源，按宿主支持方式确认实际加载版本。一次只禁用或移走一个候选副本并保留备份，复测后再清理。旧规则和新技能若给出矛盾指令，先找出冲突条文与用途，不应直接删除整套团队规则。 网络超时时，保存脱敏错误和时间，核对官方源是否可达、组织是否允许该访问。可以在许可范围内使用可信分发方式，但必须核对内容和版本；换镜像不意味着可信度不变。不要绕过速率限制、关闭证书验证或更改正在工作的系统代理来“解决”安装问题。
跨项目同步与更新怎么做
中央库可以降低重复维护，但前提是明确哪些是源、哪些是副本，以及目标宿主是否支持。做同步前列出现有版本和本地修改，先在测试项目验证；不要默认一次安装自动覆盖所有 Agent、远程工作区与云环境。项目技能进入版本库前检查是否夹带私有路径、令牌或业务资料。 更新按来源提交做差异审阅，检查新增脚本、权限、依赖和行为，再重复发现、调用、产物验收。保留上一个可用版本及自己的配置，回滚时也核对资源是否匹配。所谓“卸载”通常只移除包或登记，不会撤回它此前生成或修改的文件。
FAQ 与完整交付清单
安装 Skill 和安装扩展一样吗？不一样，先确认对象类型，再用对应流程。安装器说成功但没反应？按目的地、发现、调用、运行前提逐层排查，别只重启。必须重启吗？遵守当前版本的加载说明，不把重启当成唯一验收证据。 多个 Agent 是否装三遍？可复用同一来源，但目录、权限与工具兼容性需要分别确认；同步不是自动兼容承诺。技能都免费吗？许可证、托管工具收费、模型用量和外部服务成本分别核对。下载量大能保证安全吗？不能，检查实际源代码与权限比数字更有意义。 最后交付一份包清单、安装记录和验收记录，注明哪些已核验、哪些仍待确认。一个范围明确、可以复现并能回退的安装，比同时装入几十个用途不清的包更容易维护。