插件、skills、MCP 和 hooks 能统一分发后，不要先问装什么，先问来源、用途、权限、触发、审计和退出规则。

AI 插件的问题，很快会从“怎么装”变成“谁批准它装”。

GitHub 在 2026-06-05 公告 enterprise-managed plugins for VS Code public preview。简单说，企业可以把 Copilot CLI 和 VS Code 的插件、custom agents、skills、hooks、MCP 配置和 baseline settings 通过配置统一下发。

这对团队很有用：新人不用一个个装，团队标准能保持一致。但它也让一个问题更明显：插件一旦能统一下发，错误基线也会被统一放大。

所以先别急着列插件清单，先写 6 条团队基线。

一、插件不是装饰，是权限入口

很多人把 AI 插件当成快捷方式：装了就多一个能力。

但对 Agent 来说，插件可能意味着三件事：读更多资料、触发更多工具、写入更多系统。

一个插件如果能接 MCP server、hook、CLI、浏览器或内部知识库，它就不只是“扩展功能”，而是新的权限入口。

二、6 条团队基线

可以直接复制这 6 个字段：

| 字段 | 要写清什么 | | --- | --- | | 来源 | 插件来自官方、内部、开源，还是第三方市场 | | 用途 | 它解决哪个具体任务，不接受“提高效率”这种空话 | | 权限 | 它能读什么、写什么、触发什么外部工具 | | 触发 | 自动触发、命令触发，还是必须人工确认 | | 审计 | 它的动作、日志、输出、失败在哪里能查 | | 退出 | 不用了怎么禁用、回滚、替换、通知使用者 |

这张表不是为了让团队慢下来，而是为了让插件变成可管理资产。

三、个人也要写简化版

即使你不是企业管理员，也可以用简化版。

你在 VS Code、Cursor、Codex、Claude、ChatGPT 里装一个插件、skill、MCP server 或浏览器扩展前，至少问三句：

•        
• 它会读我的哪些本地文件或在线资料？
•        
• 它会不会自动写入、发送、发布、删除？
•        
• 不想用了，我在哪里关掉它？
•      

这三句能挡掉大部分“装完忘记”的风险。

四、hooks 和 MCP 要单独标红

普通插件可能只是多一个命令。

但 hooks 和 MCP 往往更接近“流程入口”。它们可能在某些事件发生时自动运行，也可能把 Agent 接到内部系统、数据库、浏览器或命令行。

所以团队基线里要把这两类单独标红：

•        
• hook 的触发条件是什么？
•        
• MCP server 能访问哪些系统？
•        
• 是否需要人工确认？
•        
• 失败日志在哪里？
•        
• 谁负责维护？
•      

不要靠“应该不会出事”来管理自动触发能力。

五、先试点，再统一下发

统一下发之前，先做一个小试点。

试点不是看大家喜不喜欢，而是看四个指标：是否真的减少设置时间，是否有日志，是否出现误触发，是否能顺利禁用。

如果一个插件不能解释用途、权限、审计和退出，就不要进入团队基线。

工具和资源建议

•        
• GitHub enterprise-managed plugins：关注 VS Code、Copilot CLI、.github-private/.github/copilot/settings.json、MCP 和 hooks 的边界。
•        
• 团队文档：保存“来源、用途、权限、触发、审计、退出”表。
•        
• 个人工作台：把已安装 AI 插件列成清单，每月清一次不用的。
•        
• 小团队：先给 1-2 个高频任务试点，不要全员一次性铺满。
•      

今天就做这一步

列出你现在装过的 5 个 AI 插件、MCP、skill 或浏览器扩展。给每个填“用途、权限、退出方式”。如果某个填不出来，先停用或降权。