起因AI 以人类账号提交开源贡献现在很多开发者让对话式 AI 代跑开源贡献流程建分支、写 commit、开 PR、回 issue。这本身没问题但有一个容易踩的坑——以谁的名义、标注谁做了这件事。AI 用人类的 GitHub 账号提交提交记录里作者是人类账号但实际动手的是 AI。如果只字不提等于默认这是人类写的如果过度包装又会变成人类批准了 AI 根本没问过的事。我们维护玄铁语言一门开源中文编程语言的过程中专门定了一套标注规范核心就一条诚实不误导人。核心问题诚实标注人类参与程度要区分两件事提交行为创建 issue、开 PR、提交 commit——这类动作需要人类授权账号是人家的责任也是人家的内容生成正文、代码、验证结论——这类内容主要是 AI 产出人类未必逐字看过所以规范的第一个原则是声明只描述批准不冒充审阅。人类逐字看过才算审阅人类只是点头授权就写批准。禁止把批准包装成审阅/查看。声明格式批准与提交分开写固定在 issue / PR 正文结尾附一段声明--- 人类已在Agent对话中批准提交人未逐字审阅内容仅瞄了一眼确认授权 提交方式Personal access tokens (classic)提交者豆包 Mac版工作模式模型Auto推理强度高字段拆开看第一行如实标注人类参与程度人没逐字看就写批准提交人未逐字审阅内容第二行写清楚认证方式和提交环境用什么 token、什么工具、什么模型——让读者能判断这条提交的可信度Git commit 里用 Git 标准 trailer 格式Co-Authored-By: 豆包 Mac版 (模型: Auto, 推理强度: 高) noreplydoubao.com适用范围边界提交 vs 追评这是后来踩坑才补的规则。声明只用于提交行为创建 issue、开 PR、提交 commit。评论/留言comment不适用。AI 为 issue 追加验证信息、补测试结果属于自作主张的追评——它没有经过人类逐字批准就不许贴人类已批准提交这种句式要如实写--- 本评论由 AI 代理豆包 Mac版工作模式模型Auto推理强度高在对话中自行追加未经人类逐字审阅内容仅供参考。一句话红线任何人类已批准表述必须以人类真实批准为前提未打招呼、未获批准的追加内容一律不得写人类已批准。玄铁语言案例跨平台自举的维护实践玄铁XuanTie是一门开源中文编程语言作者用 Go 写了种子编译器目标是让语言自举种子编译器Go→ 转译器 → 编译器 → 自举编译器。Windows 上自举链是通的但 macOS 一直没人验证——作者手头没有 Mac。我们接手了 macOS/arm64 的自举维护用这套标注规范跑了一串真实的开源贡献PR #16macOS/arm64 自举——种子编译器与运行时平台化链接参数按平台分支、运行时 C 文件 POSIX 适配、编译脚本 darwin/linux 分支合并后作者在无 Mac 的情况下拿到了完整改动issue #18 → PR #19Linux 链接缺 -lm 等库补 POSIX 链接分支PR #20渲染桥的 Win32 专有代码平台隔离_WIN32 守卫 raylib 原生 API 回退实测渲染库用例在 macOS arm64 编译通过issue #21CI 门禁必失败根因——GitHub en-US runner 下中文输出文件名经 Go→gcc 变成 ??.exe 导致链接失败且链接失败只 return 不报错误导排查方向遗留 issue 验证追评#12/#7/#6/#5 四个挂了几周的 macOS 相关 issue逐一在本机验证后追评补上实测证据grep 定位修复位置、编译链接实证、-jc 检查模式回归这些动作里PR 和 issue 创建都走人类批准声明验证追评则按新规则标注AI 代理自行追加。作者无 Mac 也能从留言里拿到可复现的验证步骤。一次教训追评上的错误声明规范落地过程中我们自己犯过一次错给两个 closed issue 追评验证结论时尾巴直接套用了人类已在Agent对话中批准提交——但那条评论人类并没有批准。被指出后才明确了两件事追评本身可以自主追加提供信息是好事但措辞必须诚实人类已批准这种话只能出现在人类真的批准过的提交上于是规范补上了适用范围边界一节从此追评一律用AI 代理自行追加、未经人类逐字审阅。落地与验证这套规范已经写进本地提交约定文件跨会话持续生效。实践下来有三条可复用的经验声明与事实严格对应批准就是批准审阅就是审阅不混用提交动作与评论动作分两套标注提交贴人类批准追评贴AI 自行追加任何人类已批准的表述都以人类真实批准为前提——这是底线AI 参与开源贡献会越来越常见标注规范解决的不是谁写了代码commit 历史自然记录而是这个提交经过什么程度的把关——让维护者一眼能判断信息可信度也让 AI 的参与透明、可追溯。