团队共用一个补全工具，靠共享规则文件把某些补全模式关干净

Q: 问：为什么我在 `.vscode/settings.json` 里写了 `github.copilot.enable: false`，但 VS Code 里还是能看到补全？

github.copilot.enable 的值如果是布尔 false，在新版本 Copilot 插件里可能被忽略。必须写成对象形式，按语言维度显式列出 "*": false。另外检查是否有 .vscode/settings.json 之外的配置源覆盖了它，比如用户级的 ~/.vscode/settings.json 或企业策略。项目级设置理论上优先，但部分 Copilot 版本在启动时会短暂加载用户设置再被项目设置覆盖，如果你刚好在启动瞬间看到一闪而过的补全，这是已知行为。

很多团队用了几年 Copilot 或 Cursor 之后，真正的问题往往不是“要不要开 AI 补全”，而是“某些补全模式关不干净”。个人配置里关了，新成员进来又是默认全开；有人在 IDE 里手动改，有人改 JSON，最后各人环境不一致，代码风格和审查标准全乱。要解决这个，最可靠的办法不是发文档让大家自己关，而是把规则文件放进仓库，让工具在项目根目录自动加载，强制覆盖个人配置。

共享规则文件能覆盖个人配置，但前提是放对位置、写对字段

补全工具读取配置是有优先级的。以 Cursor 为例，它在项目根目录查找 .cursor/rules.json 或 .cursorrules，项目级配置会覆盖用户级 ~/.cursor 下的设置。Copilot 在 VS Code 里则读取 .vscode/settings.json 中的 github.copilot.* 字段，同样优先于用户设置。所以把规则文件提交到 Git 仓库，每个 clone 下来的人都会自动套用同一套补全策略，不需要额外操作。

但这只解决“放哪里”的问题，不解决“关什么怎么关”。补全模式不是单一开关，而是多个正交维度：行内补全、整块生成、多文件编辑、聊天式改代码、自动 import、测试生成等。不同工具对这些模式的命名和配置项完全不一样，需要逐个确认。

Copilot 的补全模式要分三个配置层去关

Copilot 在 VS Code 里最容易漏关的是 Inline Suggest、Next Edit Suggestions 和 Chat Agents。很多人只关了行内补全，结果发现编辑器还在灰字提示下一处编辑位置，或者在 Chat 面板里误触了 /fix 之类的斜杠命令。

在 .vscode/settings.json 里，要把这三类都显式写出来：

{
  "github.copilot.enable": {
    "*": false,
    "plaintext": false,
    "markdown": false,
    "scminput": false
  },
  "github.copilot.nextEditSuggestions.enabled": false,
  "github.copilot.chat.agents.enabled": {
    "workspace": false
  },
  "github.copilot.chat.fix.enabled": false,
  "github.copilot.chat.test.enabled": false,
  "github.copilot.chat.review.enabled": false,
  "github.copilot.chat.explain.enabled": false
}

第一段 github.copilot.enable 是按语言维度关闭行内补全。注意 scminput 这个键，它对应的是 Git 提交信息输入框里的补全，很多人从来没注意到这个场景也在消耗额度、产生奇怪的建议。如果不写，提交信息框里照样会冒出补全。

nextEditSuggestions 是 2024 年推出的 NES 功能，默认开启，会在你改完一处代码后预测下一处需要修改的位置。这个功能在团队协作时要特别小心：它会根据你个人的编辑历史做预测，不同成员看到的是不同的建议，代码审查时很难对齐“这行是谁改的、为什么这么改”。团队如果要求所有 AI 建议必须经过显式确认，NES 就必须关。

Chat Agents 这一层是 2025 年之后 Copilot 更新的重点。workspace agent 可以跨文件读上下文并自动修改多个文件，关闭它意味着团队成员不能用一句自然语言让 AI 改整个模块。如果你的团队只允许“补全”但不允许“自动重写”，这个字段要设为 false。

Cursor 的规则文件是 `.cursor/rules.json`，不是 `.cursorrules`

Cursor 的配置体系在 0.44 版本之后发生了迁移。旧的 .cursorrules 文件仍然向后兼容，但官方推荐的新格式是 .cursor/rules.json，支持更细粒度的匹配规则（按 glob 模式指定哪些文件适用哪些规则）。如果团队还在用旧格式，建议趁这次统一配置的机会迁移到新格式，因为旧格式的“禁用补全”语义在新版本里表现不一致。

Cursor 里要关干净的是三类：Tab 补全、Cmd+K 编辑、Agent 模式。对应的配置项分散在规则文件和 IDE 设置里。rules.json 本身不直接控制“是否启用 Tab 补全”，它控制的是“补全时遵循什么规则”。真正开关补全模式的是 settings.json（Cursor 的 IDE 级配置）和 mcp.json 里的相关字段。

要让规则文件真正“关掉”补全模式，需要在 .cursor/rules.json 里写一条规则，把特定目录或文件类型标记为“不允许 AI 生成代码”。例如：

{
  "version": 1,
  "rules": [
    {
      "id": "no-ai-in-core",
      "name": "Disable AI completion in core modules",
      "description": "Core payment and auth modules must be hand-written only",
      "globs": ["src/core/**", "src/auth/**"],
      "severity": "error",
      "rule": "Do not suggest, complete, or generate any code in these files. Return an empty response for any completion request."
    }
  ]
}

这条规则的作用机制是：当 Tab 补全或 Cmd+K 的上下文命中了 src/core/** 或 src/auth/** 下的文件时，模型会被要求返回空响应。实测效果是补全窗口不弹出，Cmd+K 执行后无改动。但它有一个边界：如果用户手动把文件内容复制到 Chat 面板里让 AI 分析，规则不会触发，因为 Chat 的上下文不经过 glob 匹配。

所以如果团队要彻底禁止某些文件被 AI 接触，单靠规则文件不够，还需要配合 .cursor/settings.json 里的 "cursor.ai.enabled": false 或者干脆用 .gitignore 级别的隔离（比如把核心模块拆成独立仓库）。这一点很多团队踩坑：以为写了规则文件就万事大吉，结果成员在 Chat 里手动粘贴代码照样绕过。

JetBrains 系和 Vim/Neovim 的补全关闭方式完全不同

如果你的团队用的是 JetBrains IDE（IntelliJ、PyCharm、GoLand 等），Copilot 插件和 JetBrains AI Assistant 是两套独立体系。Copilot 插件的配置在 .idea/ 目录下，但这个目录通常不提交到 Git（标准做法是 gitignore 掉大部分 .idea 内容）。所以 JetBrains 用户无法像 VS Code 那样通过仓库里的配置文件强制同步。

实际可行的方案是使用 JetBrains 的 Settings Repository 或者 Shared Project Settings 功能。团队管理员把关闭补全的配置导出成一个项目级配置包，成员导入后生效。但这种方式依赖成员手动执行一次导入，不如 VS Code 的仓库内配置自动加载可靠。

Vim/Neovim 用户如果用 copilot.vim 或 copilot.lua，配置在 ~/.config/nvim/ 下，同样无法通过仓库内文件自动同步。可行做法是在项目根目录放一个 .nvim.lua 或使用 exrc 机制（Neovim 需要 set exrc 开启），然后在项目本地配置里覆盖 vim.g.copilot_enabled = false。但 exrc 有安全警告，团队需要先确认所有成员都接受这个机制。

共享规则文件最大的坑：不同 IDE 的语义不一致

我见过最典型的事故是：团队在 .vscode/settings.json 里写了 github.copilot.enable 的按语言禁用规则，但团队里有人用 Cursor、有人用 VS Code、有人用 Vim。Cursor 会读取 .vscode/settings.json 吗？不会。Cursor 有自己独立的配置体系，虽然它兼容 VS Code 的扩展生态，但 Copilot 相关的设置项在 Cursor 里由 Cursor 自己的 AI 引擎处理，.vscode/settings.json 里的 github.copilot.* 字段对 Cursor 的 Tab 补全和 Cmd+K 完全不生效。

所以“一个规则文件管全团队”的前提是：团队成员使用同一款 IDE 或同一款补全工具。如果 IDE 不统一，就需要为每种工具各写一份配置，并接受“有些工具无法通过仓库内文件强制同步”的现实。

常见问题

问：为什么我在 .vscode/settings.json 里写了 github.copilot.enable: false，但 VS Code 里还是能看到补全？

github.copilot.enable 的值如果是布尔 false，在新版本 Copilot 插件里可能被忽略。必须写成对象形式，按语言维度显式列出 "*": false。另外检查是否有 .vscode/settings.json 之外的配置源覆盖了它，比如用户级的 ~/.vscode/settings.json 或企业策略。项目级设置理论上优先，但部分 Copilot 版本在启动时会短暂加载用户设置再被项目设置覆盖，如果你刚好在启动瞬间看到一闪而过的补全，这是已知行为。

问：Cursor 里写了规则文件禁止补全，为什么 Tab 补全还是弹出来？

规则文件的 glob 匹配只对“文件路径”生效，Tab 补全的上下文有时不包含当前文件路径（比如在未保存的新文件里补全）。另外 .cursor/rules.json 的规则语义是“给模型的指令”，不是硬开关。模型可以遵守也可以不遵守。如果你需要硬关闭，改用 .cursor/settings.json 里的 "cursor.ai.enabled": false，或者按文件类型在 Cursor 的 Settings → AI → Completion 里关闭。

问：共享规则文件之后，成员还能自己改本地设置重新打开补全吗？

能。项目级配置覆盖用户级配置，但用户可以在 IDE 的 Settings UI 里临时改，部分工具会提示“此设置已被项目配置覆盖”。如果团队需要强制禁止，除了配置文件之外还需要在 CI 或 pre-commit hook 里校验代码是否包含 AI 生成的特征（比如 Copilot 专有的注释标记），但这属于另一个层次的问题了。

问：JetBrains 用户怎么统一关闭补全？

JetBrains 不支持通过仓库内文件自动同步。最接近的方案是：在团队的 onboarding 文档里给出一个可执行的脚本，成员 clone 仓库后跑一次脚本，把配置写入 .idea/ 或使用 JetBrains 的 Settings Sync 导入团队配置包。这比 VS Code 的体验差一截，但 JetBrains 的生态决定了没有更好的通用方案。