Us vs. Them 登上 Hacker News：其人类与 AI 标签依赖 Git 身份

Us vs. Them 在 Hacker News 上获得了 42 分，也带来了智能体编辑器日益制造的一种冲突：AI 应该对哪些代码行的修改保持谨慎？

这项开源实验通过重放文件的 Git 历史，为文本区段分配人类与智能体作者归属评分。它不需要在文档内部添加标签。这让其方法与现有代码库有着不同寻常的兼容性，但这种简洁也掩盖了一个关键依赖。

该系统并不检测文字是否具有合成风格。相反，它信任每次修订所附带的身份，并计算后续编辑如何改变先前的作者归属。因此，真正的对立并非人类与模型，而是明确的修订历史与不确定的身份。

随着编程智能体获得修改整个代码库的权限，这一区别愈发重要。模型如今可以在一次会话中重写文档、配置、测试和生产代码。团队在决定哪些改动应当接受严格审查时，需要的不只是最终 diff。

Us vs. Them 提出了一种小巧但颇具挑衅性的控制信号。人类编写的区域成为受保护的“岛屿”，而机器编写的区域则更容易被另一名智能体替换。这个想法将溯源从披露标签转化为编辑策略。

Hacker News 项目将 Git 历史转化为作者归属评分

Us vs. Them 将每次保存的修订视为证据，并在后续作者修改同一文本时持续传递这些证据。

开发者在 GitHub 上的身份为 eighttrigrams，他将该项目描述为面向智能体编辑的文本逐行溯源工具。其项目仓库同时提供库和命令行界面。

该实现从一系列按顺序排列的文档版本开始。每个版本都必须拥有可识别的作者，并且该作者可被归类为人类或智能体。随后，该工具比较这些版本，而不是只检查最终文本。

其输出会将代码行分组成区段，并为每个区段分配评分。1.00 表示完全由人类撰写的区段，0.00 则表示完全由智能体撰写的区段。

中间值描述混合的历史。仓库以 0.46 为例，表示最初由人类创作、后续又被智能体修改的区段。这形成了一个连续谱系，而不是强迫将每一行保留下来的文本归入二元类别。

该项目将连贯的人类区域称为生成文本“海洋”中的“岛屿”。这个比喻反映了一项重要设计决定：被保护的单位并不总是一行未改动的文本。

编辑器可能会拆分段落、合并两句话，或调整人类所写文本块的一部分。严格按最后编辑者判定的规则，会将所有被触及的内容都宣布为机器创作。Us vs. Them 尝试在部分修改后保留先前贡献的一部分。

当前界面要求用户通过 Git 身份对作者进行分类。--ours 参数指定人类，而其他所有身份都被视为智能体。反向的 --theirs 选项指定智能体，并将其余所有人视为人类。

用户选择身份较少的一方即可。该工具拒绝同时使用两个选项。这样能让命令保持简洁，尽管也将分类责任交给了操作人员。

其动机示例十分具体。开发者可能使用智能体生成应用的大部分内容，随后亲自重写一个敏感组件。另一轮会话不应随意替换这个由人类控制的区域。

文档中也会出现同样的问题。智能体可能起草整个 README，然后由维护者仔细重写开头部分。未来的智能体应在其他地方保有操作自由，同时将开头视为经过深思熟虑的编辑判断。

这不仅仅是一个花哨的可视化。评分可以成为智能体、审查界面或代码库检查机制的上下文。各类使用者都可以应用不同阈值，而无需修改底层文档。

编程助手可能会在编辑高分区段前收到警告。拉取请求可以高亮那些移除了人类创作“岛屿”的修改。审查者也可优先检查这些改动，而无需同等细读每一行生成文本。

这正是该项目带来的直接变化。通常在问题发生后才查阅的 Git 历史，成为下一次智能体操作的输入。

人类作者归属正在成为一种编辑权限

关键问题并非每个 token 应由谁获得署名，而是自动化编辑应在哪些地方遭遇阻力。

传统版本控制记录改动，却不为改动赋予道德价值。无论由谁编写，一行文本不是当前版本，就是已过时版本。智能体编辑改变了这种中立性的实际含义。

智能体可以检查任务、选择文件、编写修改、运行测试并修订自己的工作。更广泛的自主权增加了可纠正错误的数量，也扩大了人类意图可能在审查前消失的范围。

设想一个主要由助手生成的配置文件。工程师可能亲手收紧一项权限、添加一条警告，并记录这项限制存在的原因。除非历史进入其上下文，否则后续智能体看到的只是文本。

普通 diff 会显示后续智能体改了什么，却不会自动提示其中一行被删除的文本代表经过深思熟虑的人类例外。审查者必须从评论、提交信息或记忆中重建其重要性。

Us vs. Them 将作者归属历史转化为机器可读的提示。较高的人类溯源评分并不能证明某一行正确，而是表明有人在此投入了直接的编辑工作，其中可能包含值得保留的判断。

这一信号同时对两类群体施加压力。智能体开发者需要找到尊重局部意图的方法，而工程团队需要制定政策，避免让每一次人类敲击键盘都冻结代码库。

必然的回应是更好地确定改动审查优先级。随着自动化编辑增加，以同等强度审查每一项生成修改会越来越困难。溯源评分提供了一种引导稀缺人类注意力的方法。

这一想法也适用于源代码之外。政策文档、研究笔记、产品需求和内部知识库，往往将生成草稿与经过仔细修订的段落结合在一起。它们的最终形式掩盖了协作过程。

产品经理可能接受智能体给出的市场摘要，却亲自重写决策及其约束。另一名智能体应能区分支撑性文字与已经批准的决策。扁平文档并不提供这种层级。

人们已经在创建非正式的保护机制。他们会添加“请勿修改”之类的注释、隔离文件、强化测试，或在提示词中反复说明指令。这些方法传达了重要性，但需要人工标记或配套基础设施。

基于 diff 的溯源有望降低摩擦，因为 Git 已经记录了版本。团队无需采用自定义文档格式。现有的 Markdown、源代码文件和其他纯文本都可以保持不变。

这种兼容性构成了这个 Hacker News 项目最强的实用价值。许多溯源方案一开始就要求在创建时添加新的元数据。Us vs. Them 试图从团队已在维护的历史中恢复出有用信号。

该项目也契合了溯源感知型知识工作这一更广泛的转变。可搜索的工程知识库可以保存文档，但仅靠检索并不能解释是谁塑造了每一段内容。

智能体系统既需要上下文，也需要边界。上下文告诉智能体代码库包含什么；边界则告诉它哪些部分体现了有意的人类控制，值得额外谨慎。

这种压力可能会持续存在，因为生成文本的替换成本很低，而人类注意力并非如此。能够识别集中人类判断的系统，有助于保护这种更稀缺的资源。

该机制避开 AI 检测，却继承了 Git 的假设

只有当作者身份和编辑路径仍值得信赖时，版本历史提供的证据才会比写作风格更可靠。

大多数 AI 文本检测器会分析完成的段落，并估计其语言模式是否类似模型输出。这种方法在人类修订、改写或领域特定写作之后会变得不稳定。

Us vs. Them 提出的问题更为狭窄。它并不从风格推断最终文本由谁写成，而是重建每个已声明作者引入并修改了哪些区域。

这更接近会计而非检测。系统观察交易，并在后续改动中传递归属信息。它不会检查文字，再猜测其产出来源。

研究将人类与 AI 的共同创作描述为一个独特的归属问题。一项广泛的作者归属综述将人类归属、AI 检测、模型归属以及人机混合归属区分为不同任务。

对于只分析输出的分类器而言，混合情形尤其困难。一段文字可能始于模型文本，经过人类改写后又回到智能体手中，随后再经历一次人类修正。最终风格无法可靠地揭示这一序列。

版本历史会保留这一序列，前提是每个相关状态都已提交。它也提供了一条可解释路径。审查者可以检查评分背后的修订，而非信任分类器给出的不透明概率。

该项目的区段模型又增加了一层复杂性。简单的逐行归属通常会找出最后一次触及每行的提交。Us vs. Them 则尝试对连贯区段、拆分、合并和被稀释的作者归属进行计算。

Git 自己的blame 文档说明了为何这会变得复杂。Git 提供独立选项，用于检测文件内移动的行或跨文件复制的行。这些操作需要相似度阈值，且本身无法确立创作来源。

diff 能看到删除和插入，却无法理解智能体在改写语法的同时是否保留了人类想法。任何数值化溯源系统都必须将文本相似性转化为作者归属规则。

假设某人写下一个四行的安全检查。智能体重命名变量并重构条件，但没有改变其目的。一种策略可能因为意图得以保留，而保留较大比例的人类溯源。

另一种策略则可能将大部分作者归属分配给智能体，因为表面文本已经变化。这两种选择都无法从 Git 中自动推导出来。评分算法实际上编码了贡献如何在转换后存续的判断。

当智能体原封不动地移动一段人类段落时，也会出现同样的模糊性。基于位置的方法可能丢失其历史；识别移动的方法可以保留它，但前提是匹配机制能识别出复制的段落。

短行带来另一项挑战。像“安全要求”这样的标题，文本太少，难以进行可靠的相似度分析。但它的位置和周围结构可能代表一项重要的人类决策。

生成材料也可能吸收人类内容。智能体可能取用三句人类写作，并将其扩展为十句。由此形成的区段包含人类方向、机器措辞，以及可能新增的主张。

我们与他们通过“稀释”的概念承认了这一点。中间分数表达的是混合历史，而非确定性。这很合理，但用户仍需了解每次转换如何改变该数值。

像 0.46 这样的分数看似精确。其实际含义取决于算法、阈值和可用提交记录。团队应将其视为政策信号，而不是对创作归属的法证式衡量。

这一界定保护了项目的实用价值。基于 diff 的溯源不必裁定法律意义上的作者身份，也能改善 agent 的行为。它只需要识别出应当谨慎处理的区域。

在人类与 AI 溯源中，提交身份是最薄弱的一环

该工具能够追踪声明的作者身份，但无法独立验证被声明为人类的身份是否确实撰写了某次修订。

Git 提交包含作者和提交者字段。这些字段有助于重建历史，但普通仓库无法保证所列身份对应实际进行修改的键盘操作者或模型。

一个 agent 可以通过开发者的本地账户运行。由于这些值来自 Git 配置，其提交可能带有开发者的姓名和电子邮件。我们与他们会根据配置的身份对该修订进行分类。

反过来的情况也可能发生：当某人通过自动化账户编辑时，人类创建的修正可能显示在 bot 身份之下。由此得出的分数会低估人类参与程度。

共享会话会让边界更加模糊。一个人可能请求 agent 提供补丁，自己再修改若干行，随后一次性提交合并后的结果。提交身份只为这一混合过程记录了一位作者。

Git 支持共同作者 trailers，但它们是提交级别的声明，无法将不同贡献者映射到具体行。它们同样依赖参与者准确记录协作情况。

签名提交能更有把握地证明某个特定密钥批准了一个 Git 对象。GitHub 说明，签名提交会基于加密签名及关联身份获得验证。

有效签名仍不能证明内容由人工手动编写。开发者可以在审阅后为 agent 生成的补丁签名。该签名证明的是批准与完整性，而不是每一行的实际来源。

这一限制清晰界定了首要对手。历史记录可信时，显式历史优于风格猜测。身份不确定会在评分算法开始前就削弱整条链路。

历史缺失构成第二个弱点。有些团队会将许多修订压缩为一次提交。另一些团队会粘贴模型输出，在本地编辑后只保存最终状态。

在这两种情况下，中间的协作过程都会消失。该工具只能分析留存下来的版本。因此，干净的线性历史可能比杂乱的一连串小提交提供更少的溯源信息。

Rebase 可以重写提交结构，而 cherry-pick 可以在新元数据下复制变更。仓库导入可能将此前的开发压缩成单个初始快照。文件生成也可能覆盖内容，却不保留有价值的中间状态。

这些并非罕见的边缘情况。团队通常会压缩 pull request，以维持清晰易读的历史。Agentic 工作流也常会产生从未获得单独提交的临时变更。

项目的分类选项引入了第三个弱点。凡是未被列入指定一方的身份，都会被归入另一方。未知承包商、集成服务或配置错误的账户可能在无声无息间被打上错误标签。

这种二元设置便于制作原型。生产环境会受益于“未知”状态。证据不完整时，未分类作者不应自动被认定为人类或 agent。

成熟的政策可能至少需要四个类别：已验证的人类、声明的 agent、混合会话和未知。批准可以与作者身份分开。这将避免经审阅的 agent 变更伪装成手动编写的文本。

还有一种风险是对质量不高的人类作品过度保护。溯源分数衡量的是贡献历史，而不是正确性。人类编写的代码同样可能包含缺陷、过时假设和不安全模式。

Agent 应对高分区间保持谨慎，但不应将其视为不可触碰。恰当的响应可能是请求审阅、提供更有力的证据，或提出附有清晰解释的变更。

反过来，低分文本也并非可以随意丢弃。Agent 生成的迁移、测试或合规声明在部署后可能变得具有运营重要性。运行时依赖和审阅者批准的重要性可能超过初始作者身份。

因此，团队需要多种信号。溯源可以与所有权规则、测试覆盖率、安全敏感性、近期事件和明确批准并列考虑。任何单一分数都不应决定是否继续编辑。

项目最有力的定位是提供建议。它可以揭示人类贡献的集中区域，并触发不同的审阅行为。若将其输出呈现为来源证明，就超出了仓库历史所能确立的范围。

真正的竞争是基于历史的控制与嵌入式元数据之间的较量

我们与他们在采用摩擦方面胜出，而更丰富的溯源系统则在身份、上下文和可移植性方面占优。

基于历史的溯源不要求在受跟踪文件中添加特殊标记。这保留了纯文本，并使文档能与现有编辑器、渲染器和仓库兼容。

这种方法也能追溯性地工作。只要历史和身份信息仍可用，团队便能分析一个既有项目。它不要求每位贡献者都先安装专门的创作应用程序。

嵌入式元数据采取相反路线。编辑器或 agent 可以在操作发生时记录每个区块由谁生成、接受、修订或批准。它能捕捉后来 diff 无法重建的细节。

代价是集成。元数据需要 schema、存储位置、身份模型，以及在系统之间复制内容的规则。用户导出、合并或粘贴文本时，工具必须保留这些信息。

内联标记也可能使源文件变得杂乱。如果每个区块都携带作者身份标签，Markdown 文档会失去一部分简洁性。旁挂文件可避免视觉噪音，但可能与其描述的内容逐渐脱节。

我们与他们以完整性换取兼容性。其“无需标记”的约束使立即实验成为可能。但这也意味着，每当文本发生变化，系统都必须推断连续性。

基于事件的溯源可以记录的不只是作者身份。它还可以捕捉模型、提示上下文、批准操作、源材料、工具调用和审阅者。这些细节有助于解释 agent 为什么会产生某项变更。

不过，更多元数据并不等于更高信任度。Agent 可能错误标记自己的活动，集成可能遗漏事件，用户也可能绕过已植入追踪功能的编辑器。溯源的可靠性始终取决于其采集路径。

结合模型提供了最可信的方向。Git 历史可以提供独立的结构性记录，而签名的 agent 事件可以提供更丰富的创建数据。两种记录之间的差异可以触发审阅。

例如，一个 agent 平台可以使用专用且已签名的身份创建提交。它可以附加机器可读的声明，描述生成的文件和经人类批准的范围。仓库将同时保留最终文本及其声明的生成过程。

在该平台之外进行的人类编辑仍会通过正常历史显现。基于 diff 的层可以继续传递其溯源信息。未知或冲突事件将获得更低的置信度，而非被强制贴上标签。

这种架构将分数从单一的作者身份数字转变为多个维度。一个范围可以同时具有较高的人类贡献、已确认的 agent 修改和明确的人类批准。

这些维度回答的是不同问题。贡献关注谁塑造了文本。批准关注谁接受了责任。完整性关注记录是否在签名后发生变化。

对工程团队而言，批准通常比创作更重要。模型可以生成正确的代码，并由合格的维护者进行严格审阅。人类同样可以在缺乏实质审阅的情况下写出不安全代码。

对作者和研究人员而言，贡献可能更重要。他们可能需要披露哪些段落源自模型，即使之后经过人类编辑。版本感知系统能比单一最终标签更准确地揭示这种协作。

对组织而言，保留和可移植性成为核心问题。仅存储在某个 agent 平台内部的溯源信息，会在组织切换工具时消失。无论仓库迁移到何处，Git 派生记录仍然可用。

这使我们与他们与其说是完整的溯源平台，不如说是一个有用的基线。它展示了普通版本历史可以衍生出多少政策能力，也暴露了版本历史从未捕获的信息。

Hacker News 读者接下来应关注什么

该项目的价值将取决于三个信号：评分测试、agent 集成和更强的身份处理。

第一个信号是仓库是否围绕真实编辑模式扩展其行为测试。项目已经引导读者将测试视为理解其算法最清晰的说明。

接下来有价值的案例包括段落重写、区块重新排序、复制章节、压缩合并、生成文件，以及人类与 agent 交替编辑。公布预期分数将使系统更容易评估。

如果独立用户能够预测并复现其输出，这一信号将增强项目的可信度。若细微格式变化导致分数大幅变动，则会削弱“连贯的作者身份能够经受日常编辑”的主张。

第二个信号是与实际编码 agent 或审阅工作流的集成。命令行报告证明分数可以计算，但并未表明这些信息会改变 agent 行为。

一个实际实验可以要求 agent 在修改超过阈值的范围之前请求确认。另一个实验可以在某项变更移除高溯源孤岛时，优先安排 pull request 审阅。

成功应以结果而非截图来衡量。有用的指标包括被撤销的编辑、审阅者修正、遗漏的缺陷以及不必要的批准提示。

过多警告会造成溯源疲劳，过少则会使系统沦为装饰。最佳阈值很可能取决于仓库以及每个文件的敏感程度。

第三个信号是超越允许列表的身份模型。专用 agent 身份、签名提交、混合会话标签以及明确的未知状态，将解决项目最重要的限制。

这一变化将增强基于历史的溯源，因为它改善了进入算法的证据。否则，能力日益增强的 agent 可能仍会通过人类账户提交，从而抹去两者之间的区分。

用于导出范围的公共格式同样重要。其他 agent 和审阅工具需要一种稳定的方式来消费结果。可移植的旁挂文件可以在保留纯文本的同时，避免依赖某条命令。

更广泛的教训已经显现：当 AI 溯源用于指导决策，而非只是在文档上装饰一个标签时，它会更有价值。

对开发者而言，这一决策是 agent 能否自动修改某一行。对审阅者而言，这决定了应将注意力投入何处。对组织而言，这决定哪些变更需要可追责的人类批准。

我们与他们并未解决这些治理问题。它为这些问题提供了一个具体输入，而该输入源自许多团队已经在使用的基础设施。

这种方法仍容易受到不完整提交、共享身份和含义模糊的重写影响。这些局限应从一开始就影响采用决策。评分应当开启审查，而不是终结审查。

如果你管理着一个由智能体编辑的代码仓库，不妨检查某个文件的历史记录，找出真正承载人类判断的位置。然后问问：你的下一个智能体能否看见这条边界？

这一练习比争论最终文本“看起来是否由 AI 撰写”更能说明问题。Hacker News 上的讨论引出了一个更好的问题：你的编辑系统是否保留了足够的证据，以尊重人类意图？