AI代码开始逐行追责

AI 写了多少代码，现在可以按行看了

AI 编码协作正在补上一块长期缺失的基础设施：逐行溯源。近日进入开发者视野的开源项目 us-vs-them，尝试在 Agent 持续编辑文本和代码的过程中，通过差异比较记录每一行究竟来自人类还是 AI Agent。

**逐行溯源是指系统在行级粒度记录内容由哪个执行主体创建或修改，并保留这一归属随编辑过程变化的轨迹。**它回答的不是“这段代码看起来像不像 AI 写的”，而是“在这次可观测的编辑过程中，这一行最后由谁动过”。

这个区别很重要。市面上所谓的 AI 内容检测器，大多根据词频、困惑度、句式或模型分类结果做概率判断；us-vs-them 走的是另一条路线：不猜作者，而是观察修改。只要 Agent 和人类的写入动作都经过可记录的编辑流程，系统就能根据前后版本的 diff，把新增、删除和替换映射到对应执行者。

它更像“面向 Agent 的 blame”，而不是 AI 检测器

**Diff-based provenance 是一种基于版本差异重建内容来源的溯源方法。**它以修改前后的文本快照为输入，对新增行、删除行和替换行进行匹配，再把本轮变化归属到发起操作的人类或 Agent。

传统 git blame 已经能够显示每一行最后由哪个提交者修改，但它的身份模型仍然是“提交者”。当开发者使用 Claude Code、Codex、Cursor Agent 或其他编码 Agent 时，最终提交往往仍由开发者账号完成，因此 Git 看到的是一个人类提交了 5000 行代码，却看不到其中哪些行由 Agent 生成、哪些行经过人工重写。

us-vs-them 要补的是提交之前的那段历史。它关心编辑会话内部发生了什么：Agent 一次写入几十行，人类随后修改其中三行，Agent 又根据测试结果重构一个函数。到了提交时，这些操作已经被压缩成一个普通 diff，而逐行溯源希望保留被压缩掉的执行者信息。

这种设计可以简单理解为三步：

1. **记录基线。**系统保存 Agent 或人类开始编辑前的文本状态。
2. **计算差异。**每轮编辑结束后，对新旧文本执行行级 diff，识别新增、删除和替换区域。
3. **绑定执行者。**系统把本轮差异标记为人类修改或 Agent 修改，并把归属写入独立的溯源数据。

这套机制的关键不是模型能力，而是事件边界。系统必须知道“谁在什么时候完成了一轮写入”，否则只能看见文件变化，无法可靠地区分变化来自键盘输入、自动格式化器、代码生成器，还是后台运行的 Agent。

Git、AI 检测器和逐行溯源解决的不是同一个问题

**代码来源管理需要区分提交身份、生成来源和内容相似性三个概念。**Git 擅长管理版本，AI 检测器试图推测生成来源，而行级 provenance 记录的是可观察的修改过程。

| 方案 | 核心问题 | 粒度 | 判断方式 | 主要优势 | 主要局限 | |---|---|---:|---|---|---| | Git commit | 谁提交了这次变更 | 提交级 | 提交元数据 | 成熟、通用、可签名 | 看不到提交前的人机分工 | | git blame | 每一行最后属于哪个提交 | 行级 | 提交历史 | 能定位最后一次修改 | Agent 通常被归入人类提交者 | | AI 内容检测器 | 内容是否像 AI 生成 | 文本块或文件级 | 概率模型 | 不要求接入编辑流程 | 误报和漏报不可避免，难作为审计证据 | | Diff-based provenance | 本轮可观测编辑由谁完成 | 行级 | 编辑事件与 diff | 结果可解释，适合接入审查流程 | 无法识别流程之外的复制、粘贴和伪造 | | 提交签名 | 提交是否由指定身份签署 | 提交级 | 密码学签名 | 可验证提交身份与完整性 | 不证明每行代码由谁编写 |

逐行溯源因此不是 Git 的替代品，而是 Git 上游的一层事件记录。更合理的组合方式，是在编辑阶段记录人类与 Agent 的行级归属，在提交阶段由 Git 保存版本，在合并阶段由 CI 和代码审查系统读取溯源数据，并按风险决定检查强度。

这也解释了为什么单纯在提交信息里加一句“由 AI 协助生成”远远不够。一个 PR 可能包含 2000 行变更，其中 1800 行是 Agent 批量迁移，150 行是格式化工具产生，最后 50 行由工程师处理边界条件；笼统标成“AI 生成”会抹掉人工判断，笼统标成“人类提交”又会掩盖自动生成比例。

真正有价值的地方，是改变代码审查的资源分配

**风险导向审查是根据代码来源、模块敏感度和验证结果动态分配人工审查强度的机制。**逐行溯源一旦进入 PR 页面，团队不必再对所有变更采用相同的审查策略。

例如，Agent 修改测试夹具、重复性数据映射和类型声明时，团队可以主要依赖编译、静态检查与自动化测试；Agent 修改鉴权、支付、密钥处理、数据库迁移和并发控制时，系统则可以强制要求指定人员审批。人工重写过的关键行，也可以被单独标出，而不是淹没在几千行生成代码里。

一个可执行的审查策略可以按以下方式分层：

• **低风险变更：**文档、测试数据、机械式重命名，允许 Agent 生成后由自动检查放行。
• **中风险变更：**普通业务逻辑、接口适配和前端交互，要求测试通过并进行抽样人工审查。
• **高风险变更：**权限、资金、隐私、生产配置和基础设施代码，要求逐行展示 Agent 来源并由责任人审批。
• **不可自动放行变更：**安全策略、审计逻辑和灾难恢复配置，不因模型评分较高而取消人工确认。

这种机制比“所有 AI 代码都逐行人工看一遍”更现实。随着云端 Agent 并行工作，一名开发者可能同时派出多个任务执行器，单个 Agent 又可能在数小时内反复修改、运行测试和重构；如果团队仍按传统方式从第一行读到最后一行，Agent 增加的产能最终会堵在审查环节。

逐行来源也能帮助团队评估 Agent 的真实贡献。代码行数本身不是质量指标，但如果溯源数据能与缺陷、回滚、测试覆盖率和审查意见关联，团队就可以回答更实际的问题：哪个 Agent 在数据库迁移任务中返工最多，哪些类型的生成代码最常被人类重写，以及哪些模块适合提高自治程度。

这套方法可靠，但可靠性有明确边界

**基于 diff 的溯源记录的是系统观察到的编辑事实，而不是不可伪造的作者身份证明。**这是理解 us-vs-them 时最需要避免的误区。

如果人类从聊天窗口复制一段 AI 生成代码，再通过普通粘贴写入编辑器，系统可能把它记录成人类修改；如果 Agent 调用格式化器重排整个文件，大量没有语义变化的行也可能被标记为 Agent 变更；如果某个工具绕过受监控的编辑通道直接覆盖文件，来源链条就会出现缺口。

行级 diff 本身也无法完整表达语义归属。人类只改了 Agent 生成条件表达式中的一个运算符，这一行应该算人类、Agent，还是人机共同完成？Agent 把一个函数移动到另一个文件，传统行级算法可能把它视为原位置删除、新位置新增；代码格式化导致换行变化时，视觉上的多行变更可能实际上没有行为变化。

这些问题意味着成熟的 provenance 系统不能只提供二元标签。更实用的数据模型至少应考虑以下状态：

• 当前行最初由谁创建；
• 当前行最后由谁修改；
• 该行是否经历过人机共同编辑；
• 修改来自直接输入、Agent 工具调用还是自动格式化；
• 对应的任务、会话、模型和审查记录是什么；
• 溯源链条是否完整，是否存在未观测写入。

“最后修改者”也不应被直接等同于责任人。Agent 生成的代码由工程师批准合并后，工程责任通常仍属于批准者和团队；反过来，人类改动过一行，也不代表这一行已经经过充分验证。来源标签是风险信号，不是免责标签。

从原型走向团队使用，还缺少四层工程能力

**组织级溯源是一套覆盖编辑器、Agent 运行时、版本控制和审查平台的完整证据链。**一个行级 diff 原型证明了技术路径可行，但企业真正部署时，至少还要补齐四层能力。

第一层是身份。每个 Agent 实例需要稳定身份，后台任务、子 Agent 和工具进程也要有明确归属；否则多个执行器同时写文件时，记录只能笼统标成“AI”。

第二层是完整性。溯源记录需要与文件哈希、提交哈希和时间戳绑定，重要记录还应具备签名或防篡改能力；否则开发者可以在提交前删除不利的来源信息，审计价值会明显下降。

第三层是传播。行被复制、移动、重构或合并冲突后，来源信息需要尽可能跟随内容传播，而不能每次重排文件就全部重置。这里通常要结合行级 diff、语法树匹配和符号级追踪，单靠文本位置并不够。

第四层是消费。GitHub 或内部代码平台需要在 PR 中展示来源覆盖率、未观测变更、高风险 Agent 修改和人工重写区域；CI 也要能据此执行策略，而不是只生成一份没人阅读的日志。

| 工程层 | 最低能力 | 更成熟的能力 | |---|---|---| | 编辑采集 | 记录人类与 Agent 两类写入 | 区分主 Agent、子 Agent、工具和格式化器 | | 来源映射 | 行级新增、删除、替换 | 跨文件移动、语法树和符号级传播 | | 证据完整性 | 保存会话与差异 | 哈希绑定、签名、防篡改日志 | | 审查集成 | 展示不同来源的代码行 | 按目录、风险和来源执行合并策略 | | 效果评估 | 统计 Agent 修改比例 | 关联缺陷率、返工率、回滚率和审查成本 |

截至 2026 年 8 月 9 日，us-vs-them 更适合被视为一个方向明确的开源实验，而不是已经完善的企业审计产品。项目公开信息没有给出可用于横向比较的性能跑分、误归属率或大规模仓库开销数据，因此现阶段不宜把它包装成“已经解决 AI 代码合规”的完整方案。

Agent 越自治，来源信息越不能只停留在聊天记录里

**Agentic editing 是由 AI Agent 通过工具自主读取、修改和验证文件的编辑模式。**它与早期代码补全最大的区别，是模型不再只建议下一行，而是能够跨文件执行任务、运行测试、根据失败结果继续迭代，甚至自行创建 PR。

Cursor 近期披露，其内部合并的 PR 中已有 35% 由运行在云端虚拟机中的 Agent 创建，过去一年 Agent 使用量增长超过 15 倍。无论这些数字能否代表整个行业，它至少说明一个趋势：当 Agent 从补全工具变成独立执行者，团队需要管理的已经不是一段建议代码，而是一条自动化生产链。

自动化生产链最怕“结果存在、过程消失”。聊天记录能够解释用户最初下了什么指令，却不能精确说明最终文件里的某一行经历过哪些重写；提交记录能够保存最终差异，却通常看不到差异由哪个 Agent、哪轮工具调用产生。逐行 provenance 正是在两者之间补一层可查询的事实记录。

这也会改变团队对 AI 编码指标的理解。“AI 写了多少代码”不应只是一个营销百分比，因为生成 1000 行随后删除 900 行，与生成 100 行全部进入生产环境不是一回事。更值得关注的是 Agent 代码保留率、人工重写率、高风险模块占比、缺陷密度和回滚率，而这些指标都需要更细粒度的来源数据作为基础。

判断：这是小工具，但踩中了 AI 编码的下一处瓶颈

**us-vs-them 的价值不在于把代码涂成两种颜色，而在于把人机协作从口头声明变成可计算数据。**它选择 diff 而不是 AI 检测，技术上更朴素，却更符合工程审计的逻辑：对已观察到的操作做确定性记录，而不是对最终文本进行概率猜测。

这个项目目前的局限同样明显。行级粒度对代码语义仍然粗糙，流程外复制无法可靠识别，二元的人类/AI 标签不足以覆盖子 Agent、工具链和共同编辑，缺少签名的数据也不能承担强合规证明。它更像一块应该嵌入 IDE、Agent Harness 和代码托管平台的能力，而不是一个单独存在就能解决问题的产品。

但方向基本没有悬念。AI 编码的第一阶段解决“能不能补全”，第二阶段解决“能不能完成任务”，第三阶段要解决的是“系统能否证明任务如何完成”。当一个 PR 的主要生产者从人变成 Agent，团队迟早会要求知道：谁改了什么、依据是什么、经过哪些验证，以及最后由谁承担责任。

逐行溯源不会让 Agent 自动写出更好的代码，却可能决定企业是否敢让 Agent 获得更大的自治权。对于高风险软件开发，这项能力不是锦上添花，而是从“演示可用”走向“组织可用”的必要条件。

参考来源

• eighttrigrams/us-vs-them（GitHub）：本文核心项目，探索 Agent 编辑场景下基于 diff 的文本行级人类与 AI 来源追踪。