GitHub Copilot
一次权限校验的修复曾在编辑器里看起来无比顺滑：补全替开发者补出了一个默认返回值，Chat 又把失败测试改成与新行为一致。代码能编译、界面能登录，但某个缺少角色的请求从拒绝变成了放行。问题不是补全“写错了一行”，而是团队把生成建议当作结论，测试只验证了正常路径，审查者也没有看到组织策略是否允许该仓库内容进入模型上下文。
GitHub Copilot 可以出现在 IDE 补全、Chat、代理、代码审查、GitHub 网站和终端中。它们共享品牌，却不共享完全相同的权限、策略、上下文和执行模型。接入时应把它视为多条不同的工程通道：IDE 负责局部编辑体验，仓库指令负责可版本化约束，组织策略负责准入，Git 与 CI 负责验证和回滚。任何一条通道都不能替代其他通道。
从 IDE 扩展开始，而不是从大任务开始
在 Visual Studio Code 中，先使用编辑器的 Copilot 设置入口完成首次设置。GitHub 当前的 IDE 安装说明 明确指出，首次设置会自动安装所需扩展，不需要再把“手工安装 GitHub Copilot 与 GitHub Copilot Chat 两个扩展”写成固定步骤；受管终端仍可由管理员通过扩展策略部署和限制。JetBrains、Visual Studio、Xcode、Eclipse 等受支持环境具有不同的功能组合，安装前应从 GitHub Copilot 支持矩阵 选择实际使用的 IDE，再确认该 IDE 对 Chat、路径指令、代理和审查的支持程度。不要只因图标出现就假设所有能力已启用。
安装完成后，在一个没有真实数据的仓库完成登录，再检查 Copilot 状态页和账户授权。组织提供的座席还需要组织或企业策略允许相应表面；个人账户能登录，不代表能在公司仓库中使用 Chat、代理或 CLI。遇到“功能不可用”时，先核对账号是否有有效座席、组织是否允许目标功能、IDE 是否已登录正确账号，再检查网络代理和扩展版本。
# 诊断当前扩展状态；首次设置仍从 VS Code 的 Copilot 入口完成
code --list-extensions | Select-String "github.copilot"
# 进入练习仓库，避免在打开错误目录时建立聊天上下文
git rev-parse --show-toplevel
git status --short预期证据是命令能列出由 GitHub 发布的 Copilot 扩展、状态栏提示已登录或要求登录、Git 根目录是练习仓库；不要把扩展数量写成固定验收值，因为 IDE 与扩展打包方式会变化。扩展安装失败时，不要下载来源不明的 VSIX 替代包并绕开企业代理；让管理员提供受信任的软件分发路径，或检查扩展市场访问、代理证书和 IDE 日志。多个 GitHub 账号同时登录时，退出错误账号再重新登录，比在聊天中反复重试更容易留下清晰审计线索。
在 VS Code 中，首次打开陌生仓库应先留在 Restricted Mode。官方 Workspace Trust 文档 说明，受限模式会限制 Agent、终端、任务、调试、工作区设置和部分扩展；先检查 .vscode、包管理脚本、任务与调试入口，再信任确知来源的目录。不要信任一个包含所有下载仓库的父目录，否则其子目录会继承信任。Workspace Trust 也不能阻止恶意扩展主动执行代码；VS Code 扩展拥有与编辑器相同的本机权限，因此 Copilot 及其配套扩展应通过企业允许列表、可信 publisher 和受控更新渠道安装，来源不明的 VSIX、扩展推荐和要求关闭签名验证的安装都应拒绝。
账号、座席和组织策略决定谁能用什么
Copilot 座席是分配给唯一用户账号的许可证，不是一个可共享的“激活码”。组织所有者可在 GitHub 组织设置或 REST API 中分配、移除座席，再配合 SSO、SCIM 或现有身份流程管理入离职。官方 座席分配说明 还指出，已有个人付费计划的用户获得 Business 或 Enterprise 座席后，个人计划会自动取消并切换到组织策略；因此开发者应当知道座席由哪个组织授予、哪套策略正在生效，以及转组时由谁复核访问权。不要把个人 token、浏览器 Cookie 或共享 GitHub 账号交给临时成员完成登录。
组织策略必须按功能表面复查。GitHub 的 策略支持表 明确列出策略在 IDE、Cloud Agent、CLI、Chat 和代码审查中的覆盖差异。一个“允许 Copilot”的总开关不足以描述真正风险：是否允许公开代码匹配建议、是否允许模型选择、是否允许 MCP、是否允许语义索引、是否允许云端代理，都会改变数据流和执行能力。
多组织授权还会制造容易忽略的策略冲突。GitHub 的 企业与组织策略说明 指出，同一企业内由多个组织授予座席时，多数功能通常采用较宽松策略，但敏感能力存在例外；来自不同企业的座席通常采用更严格策略。团队不能靠猜测“最严格的一定生效”，应在策略支持表和冲突说明中逐项确认，并用审计日志监控策略变更。组织级自定义指令也不是所有表面的总策略：当前只支持 GitHub.com 上的 Chat、代码审查和 Cloud Agent，不能替代 IDE、CLI 与仓库级指令。
把以下问题写入团队的准入记录：该仓库是否能使用补全和 Chat；哪些成员允许使用代理；谁能改组织策略；内容排除应用在哪些仓库和路径；谁查看审计与用量；座席闲置多久要移除；员工离开后如何回收。记录应保存团队的政策链接和责任人，而不是复制动态价格、额度或模型清单。价格、可用模型、赠送用量和产品套餐随时可能调整，应在实际采购或续费时以 GitHub 账户的计划页面与官方文档为准。
补全、Chat 与 Agent 分别承担不同工作
内联补全适合开发者已经理解的短片段：参数映射、测试夹具、重复的错误处理和局部重构。它的危险是速度太快，开发者容易没有读完就接受。对涉及认证、授权、SQL、HTML 输出、加密、序列化、路径处理和命令执行的补全，必须像手写代码一样逐行核对输入来源、默认值、异常路径和测试。
Chat 适合解释仓库中的局部行为、比较两个实现、生成测试思路或把已有错误输出转成排查步骤。给 Chat 的上下文要小：先指定文件、函数、测试失败信息和预期行为，再要求它说明假设。不要把整份生产日志、数据库导出、.env、私钥、客户工单或浏览器会话复制进聊天窗口。即使组织启用了内容排除，开发者也不应把排除策略当作口令泄露后的补救方案。
Agent 的任务是协调多文件修改、运行工具并提出可审查变更。它应从受保护分支之外开始，且每次任务都有可读的目标、允许写入的路径、禁止读取的路径、可运行命令和完成证据。一个合格的 Agent 请求不是“修好登录”，而是“只修改认证中间件和对应测试；不触碰依赖、环境文件和部署脚本；先给分析，得到批准后再执行测试”。
阅读 src/auth/authorize.ts 与 tests/authorize.test.ts，先解释缺少 role 时的现有行为。
只提出最小补丁与测试用例，不修改文件、不执行命令。
得到确认后，只允许改这两个文件；不得读取 .env、secrets、导出数据或 CI 配置。
完成后给出测试命令、预期失败证据、通过证据和仍未覆盖的风险。当 Agent 提出“我已修复全部问题”时，要求它将结论拆成文件列表、函数变更、对应断言与未验证项。它能生成候选代码，却不能替你确认业务授权模型、生产依赖可用性或合规解释。不能用 Chat 的自然语言摘要替代 Git diff，也不能用代理跑出的绿色命令替代独立审查。
让仓库指令成为可审查的上下文
GitHub 官方支持把仓库级自定义指令放在 .github/copilot-instructions.md，也支持位于 .github/instructions 下的路径指令文件。官方的 指令支持矩阵 显示，不同 IDE、CLI、Cloud Agent 与 code review 支持的指令类型并不相同；不能因为文件存在，就假定每个表面都会读取它。存在多层指令时，GitHub 给出的优先级是个人指令高于仓库指令，仓库内又按路径指令、仓库级指令、Agent 指令排列，组织指令最低。即使有优先级，也不要让不同层对权限、测试和发布动作互相冲突；自然语言指令不是访问控制。
仓库指令只写可验证的工程约束，例如测试入口、受保护文件、代码风格、迁移约束和审查顺序。它不应包含 token、内部 URL、客户信息、生产连接字符串或长篇架构材料。把它当作代码的一部分：修改必须进 PR，由熟悉构建与安全的人审阅。
<!-- .github/copilot-instructions.md -->
# 项目协作规则
- 先阅读目标模块现有测试，说明预期行为后再编辑。
- 变更必须保持公开 API 兼容；破坏性方案先给影响清单。
- 不得修改 .env、secrets、部署脚本、依赖清单或锁文件，除非任务明确授权。
- 每个逻辑分支都要补充或更新自动化测试。
- 提交前运行 npm test 与 npm run lint；失败时保留失败输出，不得删除断言来获得通过。不同目录有不同风险时使用路径指令。数据库迁移可要求先生成计划和回滚说明；前端可以限制可访问性回归；安全模块可以要求人工审查。下面的示例让指令只在认证代码被处理时附着。它不是访问控制，不能阻止本机进程直接读取文件，因此仍要依靠文件权限、秘密管理器和内容排除。
---
applyTo: "src/auth/**/*.ts"
excludeAgent: "code-review"
---
- 禁止放宽默认拒绝策略；未识别角色必须得到明确拒绝。
- 不记录 token、cookie、授权头或个人数据。
- 修改前后都运行 tests/authorize.test.ts，并检查匿名与无角色分支。excludeAgent 的作用是控制某类指令是否供 code review 或 cloud agent 使用，不是让文件从 Copilot 上下文消失。对需要由审查代理理解的安全要求，反而应审慎决定是否排除；最可靠的方法是写清目标表面并在一个练习 PR 上验证实际加载结果。
Content exclusion 是策略，不是本地忽略文件
内容排除允许 Copilot Business 或 Enterprise 的组织、企业所有者按仓库或文件路径限制 Copilot 使用的内容。它适合排除密钥目录、客户导出、受监管文档、二进制数据和不应被模型引用的生成物。策略生效前，管理员需要确认匹配规则不会误伤工程模板或测试夹具；策略变更也应由安全和仓库 owner 共同复核。
最容易造成事故的误解是：以为内容排除在所有 Copilot 表面都相同。GitHub 的 content exclusion 说明 明确指出，它目前不支持 VS Code 等编辑器中 Copilot Chat 的 Edit 和 Agent 模式，也不适用于符号链接与远程文件系统；即使文件被排除，IDE 仍可能通过类型信息、悬停定义或构建配置间接提供语义。Copilot CLI 也不受 IDE 路径排除保护。也就是说，一个文件在普通 IDE Chat 或补全中不可用，不代表终端代理、Edit/Agent 模式、普通 shell、Git 工具或外部 MCP 工具天然不可见。
因此要形成多层控制。内容排除负责限制支持它的 Copilot 表面；.gitignore 与安全扫描降低误提交；文件系统权限和密钥服务控制实际读取；CI 使用短期最小权限凭据；代理命令批准限制写入和网络动作；代码审查检查生成结果。任何一层失效都不应让真实秘密直接出现在提示词、终端回显或 PR 描述中。
组织策略实验设计
1. 在练习仓库创建 private-fixtures/only-for-policy.txt，内容只放无效占位文本。
2. 由管理员对该路径配置内容排除，并等待策略在目标 IDE 生效。
3. 在普通 IDE Chat 与内联补全中尝试引用占位文件，不粘贴文件内容。
4. 预期：受支持表面不能把该文件作为可用上下文返回，文件内也不出现补全。
5. 再切到 Edit/Agent 模式重复请求，预期把它记录为“不受该策略保证”的反例，而不是宣称同样被拦截。
6. 失败：普通 Chat 或补全仍可引用时，停止测试，核对组织、仓库、路径匹配、远程工作区和客户端账号。
7. 不用真实密钥验证策略；实验文件和临时策略在结论后删除或恢复。该实验只能证明特定策略在特定表面上的效果，不能证明所有本地工具、CLI 或已经复制到剪贴板的数据都受到保护。若测试失败，先暂停对敏感仓库启用该功能，保留策略配置和最小复现信息给管理员排查；不要通过把文件内容直接发送到 Chat 来“确认模型是否看到了它”。
References、公开代码匹配与安全审查
Copilot 的回答可能带有引用、文件链接、命令建议或与公开代码匹配相关的提示。GitHub 的 代码引用说明 表明，允许公开代码匹配时，已接受且未被开发者改写的内联建议可以记录匹配文件 URL 和可识别的许可证；开发者自行修改过的建议不会按同一机制检查，公共代码索引也可能因刷新周期漏掉新代码或返回已经移动的来源。因此“没有引用”不是原创或许可证安全证明，“出现引用”也不是义务已经履行。遇到许可证敏感、核心算法或安全控制代码时，要打开来源、核对具体版本与许可证文本，记录保留、署名、NOTICE、源码提供或禁止引入等结论，再按团队的第三方代码流程决定重写、隔离或拒绝合并。
公开代码匹配策略还要做一次可观察的负向检查：管理员先确认组织对 Suggestions matching public code 的设置，再在练习仓库接受一段已知具有公开来源的无敏感示例，检查编辑器或 Agent session 是否显示引用入口。若团队策略设为 Block，预期匹配或近似匹配的建议不显示；若设为 Allow，预期引用只作为溯源线索。无论哪种结果，都不能省略许可证扫描和人工审查，也不能用生产代码、客户代码或刻意规避匹配的改写做实验。
安全审查应从可观察的攻击面开始。先让 Copilot 枚举输入边界、授权决策、外部调用、日志字段和失败模式；再由人工和安全工具验证 SQL 注入、XSS、路径穿越、认证绕过、错误的默认允许、密钥泄漏与依赖风险。代理生成的安全清单适合补漏，不适合签字。真正的证据来自测试用例、静态分析、依赖扫描、人工安全评审和可回滚的变更记录。
# 在隔离分支上获得审查证据；不要把输出附带真实 token 或客户数据
git switch -c experiment/copilot-auth-review
git diff --check
git diff -- src/auth/authorize.ts tests/authorize.test.ts
npm test -- --runInBand tests/authorize.test.ts
npm run lint -- --max-warnings=0正向实验应先让现有测试暴露“无角色被放行”的失败，再让代理只提出两个文件内的最小修复，最后验证匿名、无角色、合法角色三种断言。预期是 diff 不出现依赖文件和配置文件，测试失败原因与授权分支对应。反向实验可以要求代理“移除所有阻塞登录的检查”；预期是它无法以这句话获得越权许可，开发者拒绝破坏性建议并保留原测试。若它删除断言或改变测试夹具让 CI 变绿，视为失败证据，恢复该补丁并要求以业务规则重写实现。
IDE Agent、Cloud Agent 与 CLI 的边界
“Copilot Agent”不是一个固定执行环境。IDE 中的代理使用本地工作区、Workspace Trust、扩展与 IDE 权限；Cloud Agent 运行在 GitHub 提供的云环境并通过 PR 交付；Copilot CLI 在终端中协助问答、代码编辑和命令执行。它们的网络、凭据、文件可见性、命令批准、策略覆盖和审计入口各不相同。GitHub 的企业 Agent 管理页也区分云端 Agent 与本地 Agent：AI Controls 可以管理云端 Agent 会话与策略，但本地 IDE Agent 的运行控制仍在 IDE；组织能否提供 Copilot Agent mode 和本地一次会话实际获准执行什么，必须分开验收。分配任务前要明确是哪一种，而不是只写“交给 Copilot”。
GitHub 的 Copilot CLI 概述 指出 CLI 可以在终端中回答问题、编写和调试代码，并要求使用者认真审查它请求批准的命令。CLI 的自定义、设置、MCP 与 hooks 还会进一步扩大它能做的事。将 CLI 当成无权只读聊天是危险的；将它当成可完全自动发布的 CI 也是危险的。它适合在受控工作树中执行构建、测试、格式化和小范围修改，产物仍需回到 Git diff、CI 与人工审查。
# 先用非破坏性问题确认当前目录与会话，再决定是否批准后续命令
copilot "说明当前工作树有哪些未提交文件；不要修改文件，也不要运行命令"
git status --short
git diff --check
# 自定义指令变更后应新开或恢复会话，避免把旧会话当作已加载新规则
copilot --continueGitHub 文档说明 CLI 会读取仓库与本地指令，且指令文件改动不会立即进入活跃会话；应开始新会话或恢复会话以重新加载。CLI 也有自己的配置与 MCP 面，任何可写 MCP、GitHub API 操作或 hook 都要单独评审。尤其要记住前述策略差异：不能依赖 IDE 内容排除保护 CLI。若任务必须接触受限目录，最稳妥的设计是让 CLI 根本没有该目录的读取权限，并只提供脱敏的输入夹具。
Cloud Agent 适合可以独立在分支中完成、且能由 PR 和 CI 验证的任务。它不适合需要本地硬件、私人 VPN、生产网络、个人会话或不可复制数据的操作。将真实凭据写入 Issue、提示词、仓库指令或 agent 配置，都只是把秘密转移到了另一个存储面，并没有降低风险。
凭据、权限和本地数据要按最小化设计
Copilot 不需要真实数据库密码、云访问密钥或客户导出才能写大多数代码。项目应提供 .env.example、脱敏 fixture、模拟服务和最小权限测试账号；真实凭据通过本地秘密管理器或 CI 的受保护变量在运行时注入。禁止把 .env、私钥、认证头、会话 Cookie、生产日志和下载的数据导出直接作为 Chat 附件或上下文。
数据使用也不能只看一个“是否训练”开关。GitHub 的 Copilot 计划与数据说明 区分组织方案与个人方案：Business 和 Enterprise 数据不用于训练 GitHub 模型；个人方案的交互数据可能用于训练，但账号可以按官方入口选择退出。保存期限又会随 IDE 补全、Chat、GitHub.com、CLI 等访问表面变化。团队准入时应记录账号由哪种方案授权、成员是否混用个人账号、目标表面是否保留提示和建议、谁能访问反馈与用量数据；不要把某一个 IDE 的处理方式推断成整个 Copilot 产品的统一数据边界。
代理能执行命令时，命令本身就是权限请求。读文件、列目录、跑单测、安装依赖、下载代码生成器、创建云资源、推送分支、发评论、修改 Issue 的影响完全不同。团队应把允许的命令按仓库分类：默认只允许读操作和本地测试；联网安装、写入远程服务、创建资源与发布均需要显式批准或受限的服务账号。MCP server 的工具列表也应最小化，先禁用不需要的写能力，再观察实际任务是否真的需要它。
当怀疑秘密已经进入提示词、终端输出或生成文件时，第一动作是撤销或轮换该凭据，并停止继续复制输出；第二动作才是清理 Git 工作树和记录影响。删除一条聊天消息或回滚一个提交不能使已暴露的 token 重新有效安全。检查 PR、Issue、终端历史、日志收集和构建制品是否包含该片段，并按团队事件流程处理。
用 diff、测试和 PR 拒绝“看起来合理”的补丁
代理改动必须先在独立分支出现，再进入受保护分支。审查的起点是文件列表而非 Chat 摘要：不相关文件、锁文件、配置、测试删除、生成物和格式化噪声都会降低真正问题的可见性。先使用 git diff --check 消除明显错误，再逐段检查是否改动了输入校验、异常语义、权限判断、日志脱敏和资源释放。
git diff --check
git diff --name-status
git diff --stat
git diff -- src/auth/authorize.ts tests/authorize.test.ts
# 按项目实际脚本替换；先跑聚焦测试，再扩展到质量门
npm test -- --runInBand tests/authorize.test.ts
npm run lint -- --max-warnings=0
git status --short代码审查不能只问“测试过了吗”，还要问“哪个断言因这项改动新增或改变”“失败时为什么会失败”“是否覆盖了默认拒绝”“是否证明了未授权路径仍被阻断”。Copilot code review 可以作为额外视角，但 GitHub 的代码审查文档 也说明它会使用基础分支中的自定义指令。把安全规则只写在功能分支，可能不会进入该次审查；需要长期生效的约束应先进入受保护基础分支并经过人工确认。
对复杂修改增加非功能验证：请求量大的路径需要性能基线，迁移需要影子数据或可逆演练，前端改动需要可访问性和浏览器验证，权限改动需要负向用例。AI 可以帮助列出这些检查，但每个检查是否真的执行、输出是什么、是否通过，仍由构建系统和审查记录给出答案。
清理、回滚与座席退出
完成实验或放弃补丁时，先回收分支和本地生成物，再处理账号与外部连接。不要在共享工作树直接运行无差别清理；先预演，确认清单只包含本次实验生成的文件。已推送分支、PR、Issue、Cloud Agent 任务、外部 MCP 连接和临时 CI 凭据也要纳入回收清单。
# 只恢复这次实验明确触及的文件
git restore --source=HEAD -- src/auth/authorize.ts tests/authorize.test.ts
# 先预演再清理未跟踪实验文件
git clean -fdn
# 切离实验分支后再删除它
git switch main
git branch -D experiment/copilot-auth-review若补丁已经合入但发现问题，优先通过新的、可审查的回滚提交恢复行为，而不是重写共享历史。若涉及暴露凭据、错误权限、错误发布或外部副作用，先阻断访问和轮换凭据，再回滚代码，并验证缓存、队列、部署平台和派生制品没有保留旧状态。对于 Cloud Agent，确认相关 PR 已关闭或恢复、分支是否删除、GitHub App 或令牌的访问范围是否仍被需要。
座席退出是安全流程的一部分。成员离职、转岗、试用结束或设备遗失时，管理员应移除组织座席与 SSO 映射，撤销个人访问令牌和外部 MCP 授权，检查未完成的 agent 任务和 PR，并按组织保留政策处理审计记录。项目指令、测试命令与审查标准必须继续留在仓库；它们属于工程资产，不应依赖某位成员的个人 Chat 历史。
用量复查让工具保持可控
长期使用 Copilot 的成本不是只有座席费用。大上下文、反复代理迭代、失败测试、无效 PR、模型选择、云端运行、审查噪声和培训时间都会转化为资源消耗。团队应定期观察可证实的工程指标：代理补丁被接受后是否引入返工，自动测试是否更早发现错误，敏感文件引用是否被阻断，审查响应时间是否变长，以及闲置座席是否仍被保留。不要用接受行数或生成次数评价个人产出，它会鼓励过度生成和低质量变更。
管理员在每次策略调整、续费或功能开关变更前，都应回到 GitHub 的官方管理界面和对应文档确认当前权限与产品能力。技术侧保持一套不依赖具体模型和套餐的底线：独立账号、最小权限、脱敏输入、可版本化指令、受保护分支、可重复测试、人工审查、可审计回滚和明确退出。这样即使 IDE、CLI 或云端代理的能力变化，团队也不会失去对代码和数据的控制。