GitHub 近期为 Copilot 代码审查增加了 REST 与 GraphQL API 支持。对工程团队而言，真正的问题不是“有没有 API”，而是变更日志究竟证明了什么、接入前还缺什么，以及哪些内容只能留在本地证据清单里。本文把这三类信息分开，避免把一页产品公告误当成完整接口文档。

变更日志能提供什么边界信息

先按以下三项核对：

1. 记录官方声明的 REST 与 GraphQL 可用性。
2. 区分“每次请求可选设置努力级别”与仍需接口参考确认的具体字段。
3. 记录默认级别变化，并把接入所需的后续证据列入清单。

据 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"}

def audit_integration_record(record: dict) -> dict:
    errors = []

    plan = record.get("plan_type")
    if plan not in ALLOWED_PLANS:
        errors.append("plan_type 未落在公告列出的适用计划中")

    evidence_urls = record.get("evidence_urls", [])
    if not isinstance(evidence_urls, list) or len(evidence_urls) < 2:
        errors.append("至少保存两条冻结的官方来源链接")

    if record.get("api_reference_checked") is not True:
        errors.append("尚未回读接口参考，不能进入调用实现")

    explicit_effort = record.get("explicit_effort_requested")
    if explicit_effort is not None and not isinstance(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 接入从一开始就具备可追溯的事实边界：已知内容有来源，未知内容有停止条件，示例代码不会冒充官方契约。