Microsoft 的 VS Code 仓库在 2026 年 4 月 16 日合并了 PR #310226，将内置 Git 扩展的 git.addAICoAuthor 默认值从 off 改为 all。按 PR 中 Copilot review 的概述，这意味着在检测到 AI 生成代码贡献时，AI co-author trailer 将默认启用，用于在提交信息中加入类似 Co-authored-by 的署名尾注。
这不是 GitHub 全平台政策变化，也不能简单理解为所有提交都会无条件加上 Copilot 署名。材料显示的范围只在 microsoft/vscode 仓库内 Git 扩展配置，具体触发条件仍取决于 VS Code Git 扩展运行逻辑。但它触到了一个更棘手的问题：AI 参与痕迹该默认公开，还是应由开发者主动选择。
默认值改了两处代码，却改到了提交习惯
这次 PR 本身很小，页面显示 2 个文件变更、2 行增加、2 行删除。核心变化出现在 extensions/git/package.json，配置 schema 中 git.addAICoAuthor 的默认值由 off 改为 all。
| 项目 | 变化 | 影响 | 判断 |
|---|---|---|---|
| 配置项 | git.addAICoAuthor | 控制 AI co-author trailer | 不是新功能，是默认策略改变 |
| 旧默认值 | off | 默认不加 AI 协作署名 | 更强调用户选择 |
| 新默认值 | all | 默认开启 AI 协作署名 | 更强调可追溯性 |
| 已知问题 | repository.ts fallback 仍可能是 off | schema 与运行时默认值或不一致 | 需要看后续修正 |
Copilot review 还指出一个工程层面的细节：schema 默认值改成了 all，但 extensions/git/src/repository.ts 中运行时 fallback 仍调用 config.get('addAICoAuthor', 'off')。这意味着，至少在代码审查阶段，配置展示与实际运行兜底值可能存在不一致。对普通用户来说，这种差异很难察觉；对扩展维护者和企业团队来说，它会影响预期管理。
评论区的情绪也很直接。该 PR 初始说明为空，只写了“Enabling ai co author by default”，下方反应中 thumbs down 达到 87 个，confused 为 12 个，thumbs up 只有 1 个。这个比例不能代表所有 VS Code 用户，但足以说明默认开启不是一个无感改动。
透明度是好理由，默认替用户决定是坏手感
从合规角度看，AI co-author trailer 有现实价值。许多团队已经要求开发者标记 AI 辅助代码，方便审计、许可证检查、事故追溯和责任划分。Git 的 trailer 机制本来就常用于 Signed-off-by、Co-authored-by 等信息，放在提交信息末尾，比散落在聊天记录或 IDE 状态里更容易被 CI、审计脚本和代码平台读取。
问题在默认值。开源社区长期接受“可追溯”，但更警惕“替我署名”。DCO 的 Signed-off-by 通常是开发者主动确认；GitHub 网页端的 co-author 也需要作者在提交信息中写入对应 trailer。相比之下，把 AI co-author 从关闭改成默认开启，会让一部分开发者感觉自己的提交元数据被工具预设了立场。
误标风险也不能忽略。AI 参与程度不是二元变量：有时只是补全一行，有时生成一个函数，有时只是解释错误。如果触发条件不够透明，团队会遇到两类麻烦：该标的没标，不该标的标了。前者影响合规，后者影响作者归属和代码评审判断。
受影响最大的是使用 VS Code 提交代码的团队
这次变化最该被 VS Code 用户、扩展开发者和工程管理者检查，而不是被解读成 GitHub 或 Copilot 的全局强制政策。它发生在 VS Code 的 Git 提交流程里，影响的是使用内置 Git 扩展提交代码时的默认行为。
对个人开发者，最现实的动作是查看 git.addAICoAuthor 设置，确认是否符合自己的署名偏好。对企业团队，动作更具体：把该配置写进工作区设置或开发环境基线，明确哪些仓库要求 AI trailer，哪些仓库不允许自动添加。
接下来最该观察的不是反应数会不会继续上涨，而是两个变量：一是 repository.ts fallback 与 schema 默认值是否被修正到一致；二是 VS Code 是否会在用户界面中给出足够清楚的提示，让“默认透明”不变成“默认代签”。