GitHub 近期为 Copilot 代码审查增加了 REST 与 GraphQL API 支持。对工程团队而言真正的问题不是“有没有 API”而是变更日志究竟证明了什么、接入前还缺什么以及哪些内容只能留在本地证据清单里。本文把这三类信息分开避免把一页产品公告误当成完整接口文档。变更日志能提供什么边界信息先按以下三项核对记录官方声明的 REST 与 GraphQL 可用性。区分“每次请求可选设置努力级别”与仍需接口参考确认的具体字段。记录默认级别变化并把接入所需的后续证据列入清单。据 GitHub 官方变更日志Copilot 代码审查现在可以通过 REST 与 GraphQL API 发起请求时可以选择设置该次审查的努力级别。该变化一般适用于 Copilot Pro、Pro、Max、Business 和 Enterprise 计划。官方文章同时说明默认审查努力级别改为 Balanced并明确这一变化自 2026 年 9 月 28 日生效。这些信息足以确认能力、适用计划、可选设置和默认级别变化却不足以直接写出请求。变更日志没有在同一页给出端点路径、请求字段、返回结构和失败响应因此接入人员仍需找到相应接口参考并把实际文档回读结果留档。另一篇 GitHub 官方更新汇总列出了 VS Code Agent 会话中的合并、创建拉取请求和 Dev Container 会话等能力。它适合作为边界对照产品同时存在 API 能力和会话内能力但不能因为两者出现在相近时间的公告里就把会话功能推断为同一个 API 的组成部分。左侧为可选开关右侧为默认配置变更为什么公告不能替代接口参考工程接入至少需要三层证据。第一层是产品事实例如 API 是否存在、哪些计划可用、某项设置是否可选这一层可由变更日志支持。第二层是接口契约例如精确端点、认证要求、请求字段和响应结构这一层必须来自对应接口参考。第三层是本地运行证据包括团队实际采用的配置、测试输入、回读结果和异常记录这一层只能由自己的受控测试产生。把三层混在一起会产生两类错误。一类是把公告里的自然语言名称直接当成字段名另一类是把默认值变化误写成请求必须显式携带某个字段。正确做法是公告负责建立“需要核对”的事项接口参考负责确认“怎样调用”本地记录负责回答“当前系统按什么证据作出决定”。本地审计如何拦截无效配置下面的 Python 代码不调用 GitHub也不假设真实端点或字段名。它只检查一份本地接入记录是否包含计划类型、两条官方证据链接以及接口参考是否已经人工回读。是否显式指定努力级别是一个可选的本地决策项不会被当成必填 API 参数。ALLOWED_PLANS{Pro,Pro,Max,Business,Enterprise}defaudit_integration_record(record:dict)-dict:errors[]planrecord.get(plan_type)ifplannotinALLOWED_PLANS:errors.append(plan_type 未落在公告列出的适用计划中)evidence_urlsrecord.get(evidence_urls,[])ifnotisinstance(evidence_urls,list)orlen(evidence_urls)2:errors.append(至少保存两条冻结的官方来源链接)ifrecord.get(api_reference_checked)isnotTrue:errors.append(尚未回读接口参考不能进入调用实现)explicit_effortrecord.get(explicit_effort_requested)ifexplicit_effortisnotNoneandnotisinstance(explicit_effort,bool):errors.append(explicit_effort_requested 只能是布尔值或省略)return{ready_for_implementation:len(errors)0,errors:errors,}这段检查器刻意不验证真实请求参数。explicit_effort_requested只是团队是否准备显式配置努力级别的本地布尔记录省略它不会报错。只有接口参考回读完成后接入人员才应把真实端点、字段和响应校验加入另一份实现测试。这样可以避免在证据不足时把示例键名传播成生产契约。一份最小记录可以包含以下内容适用计划、两条来源 URL、是否已回读接口参考、是否计划显式设置努力级别以及回读人和证据文件位置。默认级别变化可以写入变更台账但不能靠本地脚本证明平台内部行为脚本只能证明团队是否保存了作出接入决定所需的材料。本地检查逻辑与外部停止条件的隔离三步接入边界核对表第一步冻结产品事实。保存两篇官方文章的 URL、标题、发布日期和与当前决策直接相关的原句。对于本次变化应分别记录 API 可用性、适用计划、可选努力级别和默认级别生效日。来源外的信息不要补写成事实。第二步回读接口参考。给每个待确认项设置明确状态未找到、已找到待复核、已由第二人回读。端点、认证、字段、响应与限制只有在接口参考中逐项出现后才允许进入实现清单。若关键项仍为空就停在准备阶段不生成看似可运行的请求样例。第三步建立本地观察记录。测试时记录输入摘要、采用的文档版本、是否显式设置努力级别、实际回读结果和异常原文。这里的目标不是证明 GitHub 内部如何实现而是让团队能够回答这次决定依据哪一版文档哪些项已经验证哪些项仍然未知。这三步对应一个简单决策产品事实齐全但接口参考未回读只能进入文档核验接口参考齐全但本地测试未完成只能进入受控测试三层证据都存在才进入实现评审。任一层缺失时停止条件都应写入审查记录而不是用模型猜测补齐。失败边界与后续维护本文的本地检查器不验证 GitHub API 本身也不判断默认级别是否在远端真实生效。变更日志不能替代接口参考本地布尔项也不能替代平台返回。若官方接口参考与变更日志表述不一致应暂停实现保留两份页面快照和差异说明再由人工决定采用哪一份当前证据。后续维护时把“产品公告更新”“接口参考更新”“本地实现更新”拆成三个独立事件。每次只改动有新证据支持的那一层并重新回读依赖它的决策记录。这样做的价值不是增加流程而是让 API 接入从一开始就具备可追溯的事实边界已知内容有来源未知内容有停止条件示例代码不会冒充官方契约。