把 AI 工具权限写进仓库，只解决了“有人声明过策略”，没有证明策略能被解析、映射到正确团队并到达客户端。9 月 25 日 GitHub 新增的产品内校验器提醒了一个常被忽略的事实：AI 治理也需要像代码一样编译、审查、发布和验收。
发生了什么
GitHub Copilot 企业托管设置现在会在 AI controls 页面检查copilot/managed-settings.json、copilot/team-mappings.json以及映射引用的团队设置文件。官方称它可以发现畸形 JSON、不支持的配置、无效团队映射等问题，并把错误定位到文件和 JSON path。管理员修复后提交到.github-private仓库默认分支，再刷新页面确认结果。
官方文档给出的范围也很重要：支持 Copilot CLI、VS Code、Copilot app、云端 Agent 与 JetBrains IDE，但不是每个客户端都支持每个属性。服务器托管策略通常在约一小时内到达用户端，重启客户端或重新登录可触发立即刷新；若验证服务暂时不可用，现有设置继续生效。换句话说，校验器检查配置，不是终端行为的实时证明。
从“合法JSON”到“有效策略”有四层
第一层是语法：文件能否解析。第二层是结构：键和值是否被平台支持。第三层是引用：团队 slug、文件名和覆盖关系能否解析到真实对象。第四层才是效果：指定用户在指定客户端上是否真的得到预期限制。只做第一层，很容易出现“提交成功、护栏失效”的绿色假象。
具体场景是安全团队要求研发 Agent 必须运行在沙箱内，并只安装批准插件。若team-mappings.json把payments-core拼成已不存在的 slug，基础 JSON 仍完全合法，但高风险团队可能继承默认策略。配置校验应在合并前尽量发现引用错误，平台校验和客户端抽样再确认真实传播链。
最小实践：本地检查映射引用
下面用内存样本检查三件事：映射值必须是团队数组、目标设置文件必须存在、团队 slug 必须来自允许清单。真实 CI 中应读取仓库文件，并通过受控来源同步企业团队清单。
importjson files={"copilot/managed-settings.json":'{"model":"auto"}',"copilot/team-mappings.json":'{"restricted.json":["payments-core","ghost-team"]}',"copilot/teams/restricted.json":'{"model":"unmanaged"}',}known_teams={"payments-core","platform"}defvalidate(repo_files,teams):errors=[]parsed={}forpath,rawinrepo_files.items():try:parsed[path]=json.loads(raw)exceptjson.JSONDecodeErrorasexc:errors.append(f"{path}: invalid JSON at{exc.pos}")mappings=parsed.get("copilot/team-mappings.json",{})forfilename,slugsinmappings.items():target=f"copilot/teams/{filename}"iftargetnotinparsed:errors.append(f"{filename}: referenced file missing")ifnotisinstance(slugs,list):errors.append(f"{filename}: team mapping must be a list")continueforsluginslugs:ifslugnotinteams:errors.append(f"{filename}: unknown team{slug}")returnerrors problems=validate(files,known_teams)print("\n".join(problems))assertproblems==["restricted.json: unknown team ghost-team"]依赖只有 Python 标准库。保存为policy_check.py后运行python policy_check.py。本次在 Python 3.9 实际运行，准确报告未知团队ghost-team，断言通过。这个脚本没有覆盖 GitHub 支持键全集，也不能代替平台校验；它的价值是把最便宜的错误提前到拉取请求阶段。
开发者和管理者该怎样落地
先为.github-private设置 CODEOWNERS 和分支保护，限制管理员与 AI 管理者修改；每次变更附上影响团队、预期客户端行为和回滚提交。再把本地 JSON/Schema 检查放进 CI，避免语法与引用问题进入默认分支。平台显示无错误后，至少用一个默认用户和一个覆盖团队用户抽查模型选择、沙箱与插件权限，并记录时间和客户端版本。
还要区分“可覆盖”和“未管理”。官方示例中的{ "overridable": "auto" }允许团队文件改变默认值，而团队设置"unmanaged"表示移除该项控制。它不等于安全默认值。高风险属性应明确谁能覆盖、覆盖到什么范围，以及验证不可用时采用继续运行还是暂停变更。
边界与风险
这套方法适合多团队、多客户端和 Agent 权限复杂的企业。小团队也可用简化版清单，但没必要复制全部治理层。产品内校验器无法证明插件本身安全、沙箱没有逃逸，也无法发现用户从其他计费主体获得的不同策略；这些仍需身份、终端和运行时审计。
策略测试最好同时包含正例和反例。正例证明普通研发仍能完成日常任务，反例则验证受限团队无法关闭沙箱、安装未批准插件或使用被禁模型。只测“应该允许”的路径，会让治理看起来稳定，却漏掉最重要的拒绝语义。抽查证据还应包含用户所属团队、客户端版本、策略刷新时间和观察到的行为，便于复盘传播延迟。
回滚也不能等事故发生才设计。保存上一版已验收配置和对应提交，在新策略出现大面积阻断时恢复旧版，再重新走平台校验与客户端抽样。不要通过临时开放全部设置来救火，因为这种改动最容易在事后遗忘。治理仓库的变更日志应回答谁改了什么、影响谁、何时生效、如何撤销。
我的判断是，AI 治理最容易失败的地方不是没有规则，而是规则从仓库到用户端的传播不可见。新增校验器补上了中间一段，但完整闭环还需要本地预检、审批、平台验证与终端验收。今天最值得做的动作，是给每条高风险策略写一个可观察的验收步骤。
你的 AI 策略变更目前验证的是文件正确，还是用户端最终行为正确？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。
