用 Git 历史追踪每一行由人还是 Agent 写成：AI 代码归属能否事后还原
作者：林岚｜OC 开发者生态编辑
林岚
开源项目 us-vs-them 尝试从 Git 版本历史推算一份文本中哪些区段主要由人编写、哪些由 Agent 生成。它不要求在源文件里插入标记，而是把每次提交的作者身份分为“ours”和“theirs”，再根据后续修改计算每段文本的人类贡献比例。
一句话结论：Git 历史可以帮助团队恢复“谁最后改过这一段”，却无法凭空证明“谁真正想出或写出这一行”；它适合作为 Agent 编辑策略和审查线索，不适合作为版权、原创性或责任归属的最终证据。
工具的出发点很实际：在一个大部分由 Agent 生成的项目里，开发者可能亲自重写了核心算法或 README 开头，希望后续 Agent 不要轻易覆盖。us-vs-them 把这些区域视为人类“岛屿”，机器内容视为周围“海面”，并尝试在拆分、合并和部分改写后保留连续区段，而不是只做逐行二元标签。
命令可以指定人类邮箱，例如 us-vs-them --ours dan@example.com README.md。输出以行号范围给出 0 到 1 的分数：1 表示完全由指定人类提交，0 表示由另一侧提交，中间值表示一段人类内容后来被 Agent 修改。团队可以据此提醒 Agent 对高分区域提高修改门槛。
限制也从输入开始。Git 作者字段只是提交者声明，不是创作过程记录。人可以把模型输出粘进自己的提交，Agent 可以使用人的邮箱，结对编程的代码可能只显示一个名字。Squash merge、rebase、格式化、文件移动和从外部仓库复制，都会让逐行历史丢失或被重新归属。
因此，这种分数更像“版本链置信度”。它能告诉审查者某段内容经过哪些身份标记的提交，却不能判断模型是否受许可证代码影响，也不能证明一个人独立创作。若要满足合规要求，还需要保存 Agent 会话、提示、模型版本、工具调用、代码评审和依赖扫描记录。
不过，轻量方法仍有价值。许多团队不会接受把每一行都包在机器可读标签里，Git 却已经存在。先用历史为 Agent 提供编辑谨慎度，再在合并请求中要求人类确认高风险区域，是比“所有 AI 代码一视同仁”更可执行的工作流。
关键事实
- us-vs-them 从 Git 版本历史推算文本区段的人类与 Agent 贡献比例
- 工具通过
--ours或--theirs指定身份集合，不修改源文件 - 输出为行号范围和 0 至 1 分数，支持部分改写后的混合归属
- 当前方法基于提交身份与差异算法，不能直接识别真实创作来源
OC 判断
项目解决的是“Agent 下一次该对哪里谨慎”，不是“法庭上谁拥有这行代码”。先把用途限定清楚，它会是一个有趣的编辑控制信号；把分数包装成绝对来源证明，则会制造新的合规幻觉。
为什么重要
- 对开发者：可用现有 Git 历史给 Agent 设置不同区域的修改谨慎度。
- 对团队：Squash、共享账号和复制粘贴会显著降低溯源可信度。
- 对合规人员：行级分数必须与会话记录、评审和许可证扫描结合。
评论
围绕这篇文章补充信息、提出问题或分享观察。