Cursor Customize 页面：规则怎么分三级管
Customize 页统一管 plugins、skills、MCP 与规则，说清 user/team/workspace 三级的生效顺序、团队分发与装插件前的检查。
同一条规则，有人放项目里，有人放 user 级，团队 marketplace 里还装了一份。Cursor Customize 页面怎么管理规则，得先弄清这三层谁压得过谁。
Customize 页面收进来的七类东西
侧边栏点开 Customize，顶部横排是七个标签：Plugins、MCPs、Skills、Subagents、Rules、Commands、Hooks。这是 3.9 版本（2026 年 6 月 22 日）的改动，官方 changelog 的说法是把 plugins、skills、MCP 这些扩展收进一处，支持 user、team、workspace 三个层级，也允许接自己的 MCP。
七类里有一类是打包形态。文档把 plugin 定义成可分发的 bundle，一个插件可以同时带 rules、skills、agents、commands、MCP servers 和 hooks，装一次就散落到各自的标签页。其余六类各管一件事：rules 是常驻指令，skills 是按需加载的 SKILL.md 包，subagent 跑在自己独立的上下文窗口里，hooks 是挂在 agent 循环特定生命周期上的脚本，commands 是用 / 触发的 markdown 提示词，MCP 负责连外部工具和数据源。
页面本身另外挂了三件事：按 scope 过滤查看装了什么、看团队和社区的热门榜、打开插件自带的 canvas，官方举的例子是做数据可视化的 Hex Canvas 和看 Jira/Confluence 的 Atlassian Canvas。
三级作用域：装在哪一层决定谁看得见
配置文件的位置本身就是作用域，同一类组件在用户级和项目级各有落点。
| 组件 | 用户级位置 | 项目级位置 |
|---|---|---|
| Rules | Customize → Rules 里的 User Rules | .cursor/rules/ 下的 .mdc |
| Skills | ~/.cursor/skills/、~/.agents/skills/ |
.cursor/skills/、.agents/skills/ |
| Hooks | ~/.cursor/hooks.json |
.cursor/hooks.json |
项目级的东西跟着仓库走，进了 git，队友克隆下来就有。用户级只在你这台机器上生效。团队级不在文件系统里：Team Rules 在 dashboard 上写，团队 hooks 由 dashboard 分发（企业版），团队插件走 team marketplace。
有一条容易踩空：云端 agent 不读 ~/.cursor/hooks.json。文档写得很直白，云端虚拟机拿不到你本地 home 目录的配置，它只加载仓库里的 .cursor/hooks.json，企业版另外加上团队 hooks 和企业托管 hooks。本地跑得好好的格式化 hook，到云端 agent 那边可能压根没执行。
冲突了听谁的：规则和 hooks 不是同一张表
两套优先级顺序不一样，记混了判断就会偏。
规则的合并顺序是 Team Rules → Project Rules → User Rules，所有适用的规则都会合并进上下文，指导冲突时靠前的来源优先。团队管理员在 dashboard 上勾了 Enforce this rule，成员就没法在 Customize 里关掉它；没勾的那些，成员可以自己在 Team Rules 那一栏关掉。
hooks 的顺序是 Enterprise → Team → Project → User。四个来源里所有匹配的 hook 都会执行，只有响应互相打架时才按这个顺序取高优先级那一个。工作目录也不同：项目 hook 从仓库根启动，路径得写成 .cursor/hooks/script.sh；用户 hook 从 ~/.cursor/ 启动，写 ./hooks/script.sh。这一条写错，表现出来就是 hook 一声不吭地不生效。
规则还有第二层筛选，alwaysApply、globs、description 三个字段共同决定它什么时候进上下文。规则明明在列表里却不起作用，多数时候卡在这里，分层定位的办法见 Cursor 规则不生效怎么排查。
团队统一分发：三种安装模式决定强制力
Team marketplace 的关键开关在 Dashboard → Plugins。每个插件对目标人群可以设成三档：Default Off 让开发者自己决定装不装，Default On 默认装上但允许退出，Required 强制安装且卸不掉。
配额上，Teams 套餐只有一个 team marketplace，Enterprise 不限个数，并且企业版只有管理员能添加。可见范围默认覆盖全团队，管理员可以在 Marketplace Settings → Marketplace Access 里收窄到指定的 Organization Group，成员关系能通过 SCIM 从身份提供方同步过来。
那个叫 Default 的内置 marketplace 专门放团队共享的 MCP server。这里有个常见误会：把 Team MCP server 加进 Default marketplace，不等于替每个人装好了，开发者仍然要自己安装配置，而且可能还得各自到 MCP 提供方那边完成认证。团队侧 MCP 怎么铺，Cursor 团队 MCP 与 marketplace 配置 里有更细的拆解。
自建 GitLab 的团队怎么把插件仓库导进来
3.9 起 team marketplace 支持从 GitLab、BitBucket、Azure DevOps 导入插件仓库，不再只有 GitHub 一条路。
仓库那边要准备的结构很轻：插件根目录放 .cursor-plugin/plugin.json，manifest 只有 name 一个必填字段，rules、skills、commands 这些组件从默认目录自动发现；一个仓库塞多个插件的话，在仓库根加一份 .cursor-plugin/marketplace.json。
导入路径是 Dashboard → Plugins → Team Marketplaces → Add Marketplace，然后走 Import from Repo。两个地方国内团队得自己确认。一是 Auto Refresh，文档明确写它要求仓库上装了 Cursor GitHub App，开启后最快每 10 分钟重新索引一次、把密集推送合并到最新 commit；从 GitLab、Bitbucket、Azure DevOps 导入有没有等价的自动刷新，文档没有写，按手动点 Refresh 来规划更稳妥。二是自建实例的网络可达性，Cursor 侧能否访问你内网的 GitLab，需要自行验证。
还有一条跟刷新方式无关的坑：Auto Refresh 只更新已经在 marketplace 里的插件，仓库里新增的插件不会自动冒出来，得重新导入一次仓库 URL。
个人临时覆盖：不动团队配置也能改今天的行为
单次任务想收窄工具面，不必去动 dashboard。Customize 里每个 MCP server 都带开关，关掉之后它不加载也不出现在聊天里；每条 rule 可以在 Always、Agent Decides、Manual 三档之间切换；skills 落在 Agent Decides 区，也能用 /skill-name 手动叫起来。
想让某个 skill 彻底不自动进来，在 SKILL.md 的 frontmatter 写 disable-model-invocation: true，它就退化成显式调用才生效的斜杠命令；只希望它在特定文件上露面，用 paths 字段写 glob。
插件侧能覆盖多少取决于管理员那一档：Default On 装上的可以退出，Required 的动不了。自己写的插件在提交审核之前，放进 ~/.cursor/plugins/local/my-plugin，或者从仓库 symlink 过去，再跑一次 Developer: Reload Window 就能试。如果不同工作区需要加载不同插件，可以用 workspaceOpen hook 返回插件路径。
一键添加之前的四个检查动作
官方对 marketplace 的口径是：插件必须开源，上架前人工审核，每次更新也要复审，发现风险立刻下架。同一页还写了另一半，插件属于第三方软件，安装风险由安装者承担，建议装之前读一遍源码。cursor.directory 上的社区插件不在这套人工审核范围内。
落到动作上有四步：
- 打开插件仓库，看
.cursor-plugin/plugin.json里有没有hooks和mcpServers字段。带hooks就意味着它会在 agent 循环里执行脚本。 - 翻
hooks/和skills/*/scripts/目录，读一遍脚本干了什么，重点看有没有往外发请求的地方。 - 看 MCP 配置指向哪里：本地 stdio 进程，还是某个远程 URL。远程的要弄清数据发给谁。
- 团队侧提前配好 MCP allowlist 和 blocklist。文档写明插件遵守这套名单，被 block 的 server 即使随插件装进来也发不出调用。
判断一个 MCP 到手能拿到多大的工具面，可以对照 Cursor 与 Claude Code 的 MCP 能力差异。准备设成 Required 的插件，值得先在个人机器上用本地目录跑一两周再推给全员。