Copilot内容排除＋MCP白名单＋Sandbox三层防线

摘要： 企业部署 GitHub Copilot Agent 时，真正有效的安全方案不是只开启一个开关，而是建立“Content Exclusions 内容排除 + MCP 工具白名单 + Sandbox 运行隔离”三层防线：第一层限制哪些仓库内容能够进入 Copilot 上下文；第二层限制 Agent 可以调用哪些外部工具、数据源和业务动作；第三层限制这些工具在文件系统、进程、网络和凭据层面实际能做什么。GitHub 官方同时列出了重要边界：编辑器中的 Edit/Agent 模式当前不支持 content exclusion；MCP 策略并不治理 Cursor、Claude 等第三方宿主中的 GitHub MCP Server；Copilot cloud agent 的集成防火墙不覆盖 MCP Server 和 setup steps 启动的进程。本文面向 Copilot Business/Enterprise 管理员、研发负责人和安全团队，提供配置步骤、策略样例、验证矩阵、攻击路径和上线检查表。

核心结论

**Copilot 的企业安全必须同时控制“看什么、能调用什么、最终能做什么”。**Content Exclusions、MCP 白名单和 Sandbox 分别对应上下文、工具与执行环境；少任何一层，都可能留下可被 prompt injection、错误推理或过度权限利用的通道。

• **Content Exclusions 管可见内容：**减少密钥文件、合同、客户数据和核心算法进入受支持 Copilot 建议、Chat 与 code review 的机会，但不是文件 ACL。
• **MCP 白名单管工具入口：**只允许经过审核的 MCP Server、工具和 OAuth scope；“出现在 Registry”不等于适合企业直接授权。
• **Sandbox 管真实影响：**限制 Agent 能读取和写入的目录、可启动进程、可访问网络和可获得凭据，阻止错误工具调用扩大影响。
• **三层仍有交叉盲区：**GitHub 官方说明，Agent firewall 不覆盖 MCP Server 和 setup steps；MCP 与 Sandbox 必须分别设置出口和身份边界。
• **推荐立即实施：**高敏仓库先采用默认拒绝、临时单次运行环境、最小仓库权限和人工批准，再逐步开放工具与网络。

为什么单一控制必然不够

结论是：Agent 安全不是“模型会不会听话”的问题，而是一次任务从输入到执行跨越了多个控制面。

一个典型任务可能经历以下过程：Copilot 读取 issue 与代码，模型决定调用 MCP 工具，MCP Server 使用 OAuth token 查询数据库，Agent 再通过 Shell 写文件和访问网络，最后创建 PR。内容排除只影响第一段；MCP 策略主要影响第二段；Sandbox 和网络策略则约束第三、第四段。

风险问题	Content Exclusions	MCP 白名单	Sandbox/运行时
敏感文件是否进入模型上下文	主要控制	不控制	可通过挂载进一步阻断
Agent 能否调用数据库、浏览器、Slack	不控制	主要控制	限制网络与进程
MCP 工具拥有哪些业务权限	不控制	需审核 scope	用短期身份和网关约束
Agent 能否读取磁盘其他目录	不是 ACL	本地 MCP 可能扩大访问	主要控制
Agent 能否向任意域名外传数据	不控制	远程 MCP 可能形成通道	防火墙/代理控制
高风险动作是否需人工审批	不控制	工具层可设计审批	平台和工作流最终把关

如果只做 Content Exclusions，Agent 仍可能通过 Bash、搜索或文件系统 MCP 打开文件；如果只做 MCP 白名单，Agent 自带 Shell 仍可能访问网络；如果只做 Sandbox，模型仍可能接收本不该进入上下文的合同或核心算法。三层的价值正在于互相补位。

第一层：Content Exclusions限制Copilot上下文

Content Exclusions 的正确定位是“上下文最小化”。根据 GitHub Content exclusion 官方文档，被排除文件不会获得行内建议，不用于其他文件的建议或普通 Chat 回答，也不会被 Copilot code review 审查。

推荐排除对象

• .env、私钥、证书导出文件和本地凭据。
• /contracts/**、/legal/**、客户资料导出目录。
• 风控规则、定价算法、许可证校验和专有模型特征。
• 生产基础设施配置、应急响应手册与安全检测规则。
• 含真实个人信息的测试数据和数据库快照。

组织级样例：

"*":
  - "**/.env"
  - "**/.env.*"
  - "**/*.pem"
  - "**/*.p12"
  - "**/credentials.json"

YOUR_ORG/payment-platform:
  - "/contracts/**"
  - "/customer-data/**"
  - "/src/risk-engine/**"
  - "/security/detection-rules/**"

真实密钥不应入库。上述规则只是减少 Copilot 上下文暴露，不能撤销 Git 历史中的密钥，也不能阻止拥有文件权限的进程读取它。发现真实密钥后，应立即轮换并调查使用日志。

官方明确的限制

截至 2026 年 9 月 10 日，GitHub 官方明确说明：Copilot Chat 的 Edit 和 Agent 模式当前不支持内容排除；symlink 与远程文件系统也不在当前支持范围内；IDE 还可能间接提供类型信息、悬停定义和构建配置等语义信息。因此不能向企业承诺“配置排除后 Agent 绝对看不到”。

另一个业务影响是，被排除文件不会进入 Copilot code review。核心算法排除后必须由 CODEOWNERS、人工安全审查、SAST 和测试补位，不能把“没有 Copilot 评论”解释成“没有风险”。

第二层：MCP白名单限制工具与数据通道

MCP 白名单的目标不是列出“团队喜欢的插件”，而是形成一份经过供应链、权限和数据流审查的允许清单。MCP Server 可以提供 tools、resources 和 prompts，也可能连接数据库、工单、浏览器、云平台甚至生产系统；它的权限往往比普通代码补全高得多。

GitHub 官方说明，企业和组织可通过 MCP servers in Copilot 策略启用或禁用 Copilot 中的 MCP 支持，该策略默认关闭。只有由相关组织或企业分配 Copilot Business/Enterprise seat 的用户受这项策略治理；Copilot Free、Pro、Pro+ 或 Max 用户不会因该组织策略自动受到同样的 MCP 访问管控。

Registry不是安全认证

GitHub MCP Registry 提供可发现的 MCP Server 列表，当前官方标注为 public preview。Registry 能降低安装和发现成本，但不能替代企业自己的准入审查。官方文档还指出，其他 Server 仍可通过配置文件手动添加。因此，“只从 Registry 安装”和“技术上只能运行白名单 Server”并不天然等价。

企业应为每个 MCP Server 记录：

审查项	必须回答的问题	拒绝条件示例
来源与版本	谁发布、是否固定镜像摘要或版本	使用 latest、来源不明
传输方式	本地 stdio 还是远程 HTTPS/OAuth	明文传输、证书不可验证
工具清单	只读查询还是写入、删除、发布	工具能力描述模糊
数据流向	请求和结果会发送到哪里	无法说明日志与第三方处理
身份权限	token scope、仓库与租户范围	使用全局管理员 PAT
审批机制	哪些动作必须人工确认	删除、付款、发布可自动执行
审计能力	能否记录主体、参数、结果和时间	无稳定审计日志
供应链	镜像签名、依赖、更新机制	自动拉取未经审核版本

仓库级MCP配置的风险

VS Code 可在仓库根目录使用 .vscode/mcp.json 分享配置。便利之处是团队成员打开项目即可看到 Server 配置；风险则是恶意 PR 可能修改启动命令、镜像、远程 URL 或参数。

一个较安全的示意配置应只引用固定、受控入口，不把秘密明文写进仓库：

{
  "servers": {
    "github-readonly": {
      "url": "https://mcp-gateway.YOUR_DOMAIN/github-readonly"
    },
    "internal-docs": {
      "url": "https://mcp-gateway.YOUR_DOMAIN/docs"
    }
  }
}

应通过 CODEOWNERS 保护 .vscode/mcp.json、.github/** 和 Agent 配置目录，并要求安全团队批准。若本地 stdio Server 使用 npx -y、uvx 或容器镜像动态下载代码，生产基线应固定版本和摘要，避免每次启动执行不同供应链内容。

白名单要下沉到工具级

只批准 Server 不够。例如 GitHub MCP Server 可能同时具备读取仓库、创建 issue、修改 PR 等多个工具。推荐通过 MCP Gateway 暴露经过裁剪的工具集：普通 Coding Agent 只获得 read_repository、search_code 和 create_draft_pr；合并、修改规则、读取组织 secrets 等能力不开放。

第三层：Sandbox约束真实执行能力

Sandbox 的职责是把“模型决定调用工具”与“工具对真实世界产生影响”隔开。有效的 Sandbox 至少控制文件系统、进程、网络、身份、资源与生命周期。

GitHub Copilot cloud agent 在由 GitHub Actions 支持的临时开发环境中工作，可以探索代码、修改文件、运行测试与 lint。临时环境能降低持久驻留风险，但“ephemeral”不等于“没有敏感访问”：挂载进环境的仓库、Agents secrets、网络可达系统和 MCP 工具仍可能被使用。

文件系统隔离

• 只检出任务需要的仓库，不把合同库或核心算法库挂载进同一环境。
• 工作目录默认可写，系统和共享目录只读。
• 禁止挂载宿主 Docker socket、SSH agent 和开发者主目录。
• 对 /tmp、缓存和构建产物设置容量与生命周期。
• 不用 symlink 把受保护路径带入工作区。

进程与系统调用

• 以非 root 用户运行 Agent 和 MCP Server。
• 移除不必要 Linux capabilities，启用 seccomp/AppArmor/SELinux 等运行限制。
• 禁止特权容器、host network 与宿主 PID namespace。
• 对命令执行设置 timeout、CPU、内存、进程数和磁盘限额。

网络隔离

GitHub 官方说明，Copilot cloud agent 默认通过防火墙限制互联网访问；推荐 allowlist 会允许常见操作系统包仓库、容器 Registry、语言包仓库、证书机构，以及 Playwright MCP 所需的部分下载主机。组织可关闭推荐列表，并配置精确的域名或 URL 路径规则。

高敏仓库应采用“默认拒绝 + 精确 URL”的策略，只允许 GitHub 必要服务、内部制品库和任务所需 API。不要为了安装一个依赖而永久开放整个互联网。

防火墙的关键盲区

GitHub 官方列出三个限制：集成防火墙只适用于 Agent 通过 Bash tool 启动的进程；不适用于 MCP Server，也不适用于 configured setup steps 启动的进程；只在 GitHub Actions appliance 内运行；复杂攻击仍可能绕过。因此防火墙不是完整 Sandbox。

这意味着远程 MCP Server 必须在 MCP Gateway、企业代理或网络层另设出口规则，本地 MCP 进程也要在容器/命名空间中运行。setup steps 不应下载并启动长期后台代理，更不能把高权 token 交给常驻进程。

横切控制：身份、密钥、审批与审计

三层防线之外，还需要贯穿所有层的身份治理。否则一个被批准的 MCP Server 持有全局管理员 PAT，就可能让白名单变成高权限直通车。

GitHub 为 cloud agent 提供独立的 Agents secrets 与 variables。官方说明，只有 Agents 类型的 secrets/variables 会传给 Agent，而 Actions、Codespaces 和 Dependabot 的秘密不会自动传入。以 COPILOT_MCP_ 开头的 Agents secrets/variables 只提供给 MCP Server。

推荐原则：

1. 优先 OAuth/OIDC 和任务级短期 token，不使用长期 PAT。
2. 组织 secret 只授权 selected repositories，不选 all repositories。
3. MCP 使用的秘密统一 COPILOT_MCP_ 前缀，减少普通脚本可见范围。
4. 日志脱敏不代表秘密绝不会被工具外传，仍需最小 scope 和出口限制。
5. 删除数据、发布内容、合并 PR、修改权限、调用生产系统必须人工批准。

三层防线的推荐架构

一套可落地的企业架构可以分成控制平面和执行平面。

控制平面由 Enterprise/Organization AI policies、Content Exclusions、企业 MCP Registry/Gateway、身份提供商、审批系统和审计平台组成。执行平面则是每次任务创建的临时 Agent Runner、最小代码工作区、本地受限工具和网络代理。

关键原则是：

• Content Exclusions 的维护者不能是日常 Coding Agent。
• MCP 准入、工具 scope 与 Secret 发放由不同角色审核。
• Sandbox 模板从受保护默认分支加载，PR 不能在当前任务中即时降低隔离。
• Agent 只创建分支和 Draft PR，不直接合并主分支。
• CI、secret scanning 和人工 code owner 独立验收输出。

这与 AI Stack Nav 的 Coding Agent 独立验收教程 可以形成一套完整治理方案；需要进一步建设统一工具入口时，可参考 企业 MCP Gateway 相关教程。

从零部署三层防线

以下步骤适合先在一个非生产仓库试点，再推广到组织或企业。

1. 资产分级。 标记公开、内部、敏感、机密四级数据，列出密钥、合同、客户数据、核心算法和生产配置所在位置。
2. 移出不该入库的数据。 密钥进入 Secret Manager，合同进入受控文档系统，核心算法尽量拆到独立仓库。
3. 配置 Content Exclusions。 企业放通用基线，组织放业务规则，仓库放特殊路径；保存后刷新 IDE 并用 canary 文件验证。
4. 默认关闭 MCP。 只对试点组织和指定用户启用 MCP servers in Copilot，禁止未经评审的 Server。
5. 建立 MCP 准入表。 固定来源、版本、工具列表、OAuth scope、数据流向、网络域名、审批和日志要求。
6. 部署 MCP Gateway。 将远程 Server 收敛到企业入口，进行身份交换、工具裁剪、参数校验、速率限制和审计。
7. 建立临时 Sandbox。 每项任务使用一次性 Runner，只挂载所需仓库，以非 root 身份运行并设置资源限制。
8. 配置出站规则。 保持防火墙开启，高敏仓库关闭宽泛推荐 allowlist，只添加必要域名或 URL 路径；为 MCP 单独控制出口。
9. 发放最小 Agents secrets。 选定仓库、短有效期、最小 scope；MCP 专用秘密使用 COPILOT_MCP_ 前缀。
10. 保护控制文件。 对 Content Exclusions、.vscode/mcp.json、.github/workflows/**、Sandbox 模板和 CODEOWNERS 要求人类安全审批。
11. 只允许 Draft PR。 Agent 不获得直接 push 主分支、审批自己 PR 或绕过 branch protection 的权限。
12. 红队验证。 使用无害 canary 测试读取排除文件、调用未批准工具、访问未授权域名、泄露环境变量和修改安全配置。

可复用配置样例

最小权限setup steps

name: Copilot Setup Steps

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
  pull_request:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: "20"
          cache: npm
      - run: npm ci --ignore-scripts

--ignore-scripts 是否可用取决于项目，不应盲目复制。如果依赖确实需要安装脚本，应审查脚本并锁定依赖版本。GitHub 官方还提醒，setup step 失败后 Agent 会跳过剩余步骤，并在当前环境状态下继续工作；因此验证步骤失败时应通过外部规则阻止任务继续，而不是只依赖 workflow 中的失败退出。

受保护路径CODEOWNERS

/.github/                       @YOUR_ORG/platform-security
/.vscode/mcp.json               @YOUR_ORG/platform-security
/security/                      @YOUR_ORG/security-team
/src/proprietary/               @YOUR_ORG/core-team

CODEOWNERS 需要配合受保护分支或 ruleset 才能形成强制审批。仅存在文件而没有 required review，不能阻止拥有写权限的人直接合并。

MCP准入策略示意

policy_version: 1
default: deny
servers:
  internal-docs:
    source: "https://mcp-gateway.YOUR_DOMAIN/docs"
    transport: https
    tools:
      allow:
        - search_documents
        - read_document
    write_actions: deny
    outbound_hosts:
      - docs-api.YOUR_DOMAIN
    secret_prefixes:
      - COPILOT_MCP_DOCS_
    human_approval: false
  github-pr:
    source: "https://mcp-gateway.YOUR_DOMAIN/github"
    tools:
      allow:
        - read_repository
        - create_draft_pr
    tools_requiring_approval:
      - update_pull_request
    tools_denied:
      - merge_pull_request
      - modify_repository_settings

这是企业实施建议，不是 GitHub 原生配置格式。其价值是把 Server 级许可下沉到 tool、scope、host 和审批级别，并由 Gateway 执行。

攻击场景与三层如何协同

场景一：恶意README诱导上传源码

第三方依赖仓库中的 README 包含提示注入，要求 Agent 把诊断信息上传到外部站点。Content Exclusions 减少机密路径进入上下文；MCP 白名单阻止调用未知上传工具；Sandbox 出站防火墙拦截未授权域名。PR 中还应显示被阻止地址和命令，供审查者判断。

场景二：被批准的MCP工具权限过大

一个“GitHub 工具”既能读取 issue，也能修改组织设置。Server 在白名单中并不代表所有工具都安全。Gateway 应只暴露读取与 Draft PR 工具，token 只授权指定仓库，修改设置类动作拒绝。Sandbox 的普通 Agent token不具备组织管理权限。

场景三：Agent从远程文件系统读取合同

Content Exclusions 对远程文件系统存在官方限制，不能作为唯一防线。正确做法是不把合同目录挂载到 Agent 环境，远程文件服务按身份拒绝访问，并在 MCP Gateway 禁止读取合同资源。

场景四：MCP绕过Agent防火墙

GitHub 官方说明集成 firewall 不覆盖 MCP Server。企业需要让本地 MCP 在独立容器和网络 namespace 中运行，远程 MCP 只能经企业代理/Gateway 访问，出口域名与请求大小受控，并检测敏感数据。

上线验收矩阵

测试	操作	预期结果	责任层
C01	普通 Chat 请求解释被排除文件	不引用该文件	Content Exclusions
C02	Agent 模式搜索同一文件	不把内容排除视为保障，验证挂载/ACL阻断	Sandbox
M01	添加未批准 MCP Server	策略或企业基线拒绝	MCP 白名单
M02	调用批准 Server 的高风险工具	工具不可见或触发审批	Gateway/审批
M03	MCP 请求未授权域名	独立 MCP 出口控制拒绝	Sandbox/Gateway
S01	Bash 请求未批准域名	Agent firewall 拦截并留痕	Sandbox
S02	读取宿主目录或 Docker socket	路径不存在或权限拒绝	Sandbox
I01	普通脚本读取 MCP 专用 secret	不可获得	身份/Secrets
P01	Agent 尝试合并自己的 PR	分支保护拒绝	GitHub Ruleset

所有测试使用 canary 字符串和测试账户，禁止用真实密钥验证。报告需记录客户端版本、策略来源、用户 seat 来源、Runner 类型、MCP Server 版本、网络规则版本和审计事件。

监控、审计与持续治理

上线不是终点。Copilot 表面、MCP Registry、Agent 功能和策略覆盖范围仍会更新，public preview 功能尤其可能变化。

建议统一收集：

• Content exclusion 规则变更与 copilot.content_exclusion_changed 事件。
• MCP Server 安装、启动、工具发现、调用参数摘要与结果状态。
• OAuth 授权、token scope、身份交换和 Secret 使用。
• Sandbox 命令、文件写入、进程树、网络请求与 firewall block。
• Agent 创建的 commit、PR、CI 结果、人工审批与最终合并身份。

告警重点包括：排除路径骤减、MCP 配置指向新域名、Server 镜像摘要变化、Agent 请求未知域名、读取大量文件、Secret 使用量异常、setup steps 启动后台服务，以及 Agent 修改自身安全配置。

成本与实施优先级

三层防线的成本主要来自治理和基础设施，而不是 token。Content Exclusions 配置成本低，但需要资产盘点和回归测试；MCP 白名单需要持续供应链评审；Sandbox 和 Gateway 的建设成本最高，却是阻断真实影响的关键。

小团队可从一个仓库开始：移出密钥、配置精确排除、关闭不需要的 MCP、保持 cloud agent firewall、只创建 Draft PR。中大型企业应建设集中 MCP Gateway、一次性 Runner、短期身份、SIEM 审计和策略即代码。

推荐顺序：

1. P0：真实密钥不入库，轮换历史泄露，启用 secret scanning。
2. P0：Agent 不直连生产系统，不获得合并和组织管理权限。
3. P1：部署 Content Exclusions 和 MCP 默认拒绝。
4. P1：建立临时 Sandbox、网络白名单和 MCP 独立出口控制。
5. P2：策略即代码、自动验证、集中审计与红队演练。

事实依据与来源

本文关于 Content Exclusions 的效果、适用套餐、Edit/Agent 模式限制、symlink/远程文件系统限制，来自 GitHub 官方概念与配置文档。关于 MCP 支持默认关闭、策略对 Business/Enterprise seat 的适用边界、Registry public preview 和手动配置能力，来自 GitHub 官方 MCP 教程与企业策略文档。

关于 Copilot cloud agent 使用 GitHub Actions 临时环境、setup steps、Agents secrets、COPILOT_MCP_ 前缀及 self-hosted runner 建议，来自 GitHub 官方 Agent 环境和 secrets 文档。关于默认防火墙、推荐 allowlist、组织/仓库 URL 规则，以及防火墙不覆盖 MCP Server 和 setup steps 等限制，来自 GitHub 官方 firewall 文档。

本文没有使用第三方 Benchmark。“三层防线”“MCP Gateway 工具级裁剪”“canary 验证”“临时 Sandbox 基线”等属于编辑整理和企业实施建议，不代表 GitHub 提供了同名的一键产品。具体控制效果必须按 Copilot 客户端、seat、Runner、MCP 宿主和企业网络实际测试。

内容核验日期：2026 年 09 月 10 日。

FAQ

三层防线中哪一层最重要？

三层缺一不可，但高风险场景应优先保证 Sandbox 与身份权限，因为它们决定 Agent 最终能造成多大影响。Content Exclusions 减少上下文暴露，MCP 白名单缩小工具面，Sandbox 则在前两层失误时提供最后一道执行边界。

Content Exclusions能保护Agent模式吗？

不能单独依赖。GitHub 当前明确说明，编辑器中的 Copilot Chat Edit 和 Agent 模式不支持 content exclusion。Agent 模式必须通过最小工作区、文件权限、工具白名单和 Sandbox 控制敏感内容。

GitHub MCP Registry里的Server都可以直接批准吗？

不建议。Registry 是发现与安装入口，当前还处于 public preview，不是企业安全认证。企业仍需审查 Server 来源、版本、工具、OAuth scope、数据流向、日志、更新机制和供应链。

开启MCP servers in Copilot策略就等于建立白名单吗？

不等于。该策略主要控制是否允许使用 MCP；不同界面仍可能支持手动配置 Server。企业白名单需要额外限定批准的 Server、版本、工具、身份和网络，并验证用户是否受相应 Business/Enterprise seat 政策治理。

GitHub的Agent firewall会限制MCP Server吗？

官方明确说明不会。集成 firewall 只覆盖 Agent 通过 Bash tool 启动的进程，不覆盖 MCP Server，也不覆盖 setup steps 启动的进程。MCP 必须使用独立容器、Gateway、代理和出口规则。

自托管Runner是否更安全？

不一定。自托管 Runner 可以接入内网，但也可能扩大横向移动范围。GitHub 推荐用于 cloud agent 的自托管 Runner 应为临时、单次使用，并配置网络安全控制。不要把可重复使用且能访问广泛内网的 Runner 直接交给 Agent。

Agents secrets与Actions secrets有什么区别？

Copilot cloud agent只会自动获得专门配置的 Agents secrets/variables，不会自动获得 Actions、Codespaces 或 Dependabot secrets。以 COPILOT_MCP_ 开头的 Agents secret/variable 只提供给 MCP Server，但仍需最小 scope、选定仓库和网络限制。

Sandbox是否可以阻止所有数据外传？

不能做绝对保证。GitHub 官方也指出复杂攻击可能绕过集成 firewall。企业应叠加默认拒绝网络、代理、MCP Gateway、DLP、短期凭据、请求限制、输出扫描和审计，提高攻击难度与可发现性。

Agent生成的PR可以自动合并吗？

低风险仓库可在严格测试与规则下评估自动化，但生产代码、权限、安全配置、依赖、数据库迁移和发布流程应保留独立审批。Agent 不应批准或合并自己的变更。

参考来源

• GitHub Docs：Content exclusion for GitHub Copilot
• GitHub Docs：Excluding content from GitHub Copilot
• GitHub Docs：Extending Copilot Chat with MCP servers
• GitHub Docs：Managing Copilot policies for an enterprise
• GitHub Docs：Configure the development environment
• GitHub Docs：Configure secrets and variables for Copilot cloud agent
• GitHub Docs：Customizing or disabling the firewall for GitHub Copilot

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包