给 Cursor 加能力之前，先判断任务为什么没有做好。需求缺少前提、项目没有启动、差异无法审查与编辑器卡顿，需要不同处理，不能都归结为“没装五个外挂”。本文以虚构手工工作坊的材料说明站为例，覆盖效率方法、开发与 Git 增强、性能调优三类场景。目标是修正单位说明和本地预览路径，留下可复查产物，不执行真实发布，也不把示例当成产品测试成绩。
先分清扩展、插件包与 Skill
社区口中的外挂不是精确技术类型。编辑器扩展、单个 Skill、规则、工具连接和插件包可能一起出现，但不能使用相同安装方法。Cursor 官方插件文档说明插件可以组合多类组件；一个技能包不因此自动包含 Git 集成或系统性能工具。安装前先看清清单与请求访问范围。 对材料说明站列出五个检查点：任务范围、项目上下文、适用方法、验证证据与恢复方式。这是本教程的检查顺序，不是五个必装产品。若工作只有审阅一页说明，就不需要浏览器服务、生产凭证或全部仓库写权限。工具数量不能替代清楚的输入输出。 准备虚构材料记录和测试目录，保留既有改动。当前问题是说明把毫米与厘米混写，预览链接又指向旧页面。验收要求是单位含义明确、示例计算一致、导航能到正确预览；材料安全、生产尺寸和商业承诺不由 Agent 推测，所有事实需由负责人确认。
场景一：效率方法要减少明确的返工
把“让说明更专业”改成可执行任务：“只审阅材料尺寸段落，标记单位、对象和换算含糊处，返回文件位置、原因和建议，不改技术事实。”先通过 SkillPI Skill Finder 搜索适合的方法，再检查目标包来源、版本、许可证和前提，不凭下载量决定。 可核验的 Writing Guidelines 适合这一步的技术表达审阅，需要目标文档与关联写作指南。GitHub 的 Vercel agent-skills 仓库 有明确的写作技能说明、文档和 MIT 许可，可参考现有方法而非再造泛化“效率插件”。技能不负责认证材料数据，也不自动替读者选择产品规格。 审阅结果分成两类：能直接改清楚的句子，以及必须由负责人确认的事实。比如“留 2 的边”缺单位，应提出问题，不能自作主张补成厘米。负责人确认后再让 Agent 改指定段落，并比较前后差异。这样减少的是围绕歧义的来回修改，不是凭空宣称省掉百分之多少时间。 阶段产物包含问题表、事实确认记录和小范围文案差异。若技能无法读取关联指南，就说明依据不足，不冒充已按指南审阅；网络失败也不意味着应改用未知来源安装另一个包。
场景二：开发增强与 Git 交付围绕同一行为
预览链接指错时，先定位链接来源、目标页面与路由规则，再决定修改位置。要求 Agent 给出最小计划，不同时换目录结构、组件库和构建工具。修改后检查每处链接，确认旧路径的处理是否在本轮范围；需要保留外部旧链接时另定兼容方案。 Webapp Testing 用在本地运行的说明站：观察页面后测试目录到材料页、材料页到预览以及返回路径。它需要 Python、浏览器依赖、启动命令、地址和虚构输入。它不是 Git 管理器，不保证线上部署或真实用户访问；未运行的检查不能写成通过。 Git 部分先查看工作区，分清原有改动与本轮文件，再看完整差异和待提交差异。提交描述应是“修正材料说明单位并恢复预览入口”，而不是“优化全部”。若项目规范要求分开文案与路由两次提交，就按规范组织；不能为了好看随手重写共享历史。 冲突时读两边意图。一个分支可能更新材料名称，另一个修链接，整份选择一边会丢失另一项行为。合并后复核单位说明、目标路径和相关检查。让 Agent 解释取舍与剩余问题，无法理解的冲突先列出待确认点。提交、推送和生产发布按授权分别处理，不藏在“增强 Git”里面。 如果考虑另一编码工具，拿同一小任务、同一快照与同一验收比较，记录总完成时间、人工纠正、无关改动和实际成本。没有当前证据不写“某工具必然更快”。本页没有关联未经核验的横评或 Git 专项 Skill，必要人工步骤明确保留。
场景三：性能调优从症状与基线开始
先分辨是编辑器界面冻结、索引耗时、模型回复慢，还是本地预览站本身慢。记录软件版本、项目规模、操作步骤与时间。能否在只包含说明页的小项目复现，是缩小范围的线索，不是根因证明。 如果只有大型工作区慢，检查是否包含构建输出、重复依赖、归档或与任务无关的目录。按当前官方支持方式调整范围，保存原设置，一次只改一项。若是预览页慢，观察资源加载与页面行为，不把网站性能问题归给编辑器索引。若是网络错误，保留脱敏诊断与时间，遵守组织网络策略，不关闭证书验证或更改已正常工作的系统代理。 性能修改也需要结果对照：同一项目、同一操作、相近环境，分别记录改前与改后时间、资源与功能是否保持。更快但跳过必要文件或检查，不算改进。技能本身可能带脚本、外部调用或额外上下文，因此不能保证“安装更多技能几乎不占资源”。 若目前没有可核验且用途匹配的性能包，就先做这套人工诊断；不要把写作或网页测试技能改名成性能优化专家。仍未解决时交付症状、已排除因素和下一步负责人，而不是继续批量安装碰碰运气。
实操：一份完整交付怎样验收
用虚构记录 M31 的尺寸段落和一条旧预览路径做固定样本。先保存原文、原路径和负责人确认的单位；完成技术文案审阅后只改已批准内容。再修链接，在测试环境检查点击到达的标题与正文确实属于 M31，不能仅以地址变化判断正确。 保存相关差异、浏览器操作与结果、未运行项目检查的原因，再让维护者照运行手册重现。这里没有运行该演示，读者需生成自己的证据。对外发布前还需实际环境验收；本地能访问不是生产发布完成。 维护表记录每个包的来源、版本、用途、前提、测试样本与回退方式。用完这一轮再决定是否保留，去掉没有当前任务的候选。更新前检查新增组件、依赖和权限，再跑同一样本；安装同名包不能默认替换来源相同。
FAQ：选装、成本和兼容
插件与 Skill 是一回事吗？不是精确等同，检查包内实际组件与宿主格式。要装五个才能提效吗？不需要，按缺口选方法，先 Finder 后核验目标。安装量大是否代表适合当前项目？不能，任务契合与验收证据更关键。 技能都不消耗额度吗？包许可与宿主、模型和外部服务成本分别看；不保证固定节省。换 Agent 能直接用吗？核对标准支持、路径、工具与权限，不承诺所有配置相同。卸载能恢复全部修改吗？不能，包与生成文件是不同对象，备份和差异记录要保留。 一个有效的增强方案应说明少了哪类返工、修好了哪条路径、测到了什么瓶颈及哪些仍未知。它是围绕项目行为建立的小闭环，而不是把工具回答不佳全归咎于用户没有装够外挂。