我们与他们 行级文本来源追踪 - 这行是我们写的还是他们写的？ - 源于文本的版本历史。将其作为库或命令行工具使用。 问题 随着代理编码和编辑，来源变得尤为重要。人类创作或编辑的文本应该被视为相当神圣：一个代理在处理它时应当犹豫，并且有充分的理由去触碰它。另一方面，其他代理产生的糟糕文本完全可以修改。 一个用例：在一个主要是 vibe 编码的应用中，您希望在代码的某些角落确立您的想法和所有权。您当然不希望另一个代理在下一次会话中横冲直撞修改这一段代码。 另一个用例：README.md，最初生成的文件，您重写开头段落。代理可以随意重新修改或添加后续部分，但在更改开头部分时真的要三思而后行。 工作原理 这应工作的主要约束是，不应要求文本必须特别标记。应支持无处不在的纯文本（Markdown）。那么，可以利用的唯一条件是，每个新版本的文本是以可识别的作者身份创建的-无论是人类还是代理。对给定文本的评估输出是一组范围 - 在机器生成文本的“海洋”中人类创作行的“岛屿”。技术上基于简单的差异比较，这是算法开发的指导隐喻。我们不仅想追踪单行的作者身份，还想追踪有意义且连贯的文本片段。因此，连接、拆分和作者身份的稀释都是需要考虑的行为，并以这样的方式进行，以免我们最终完全变成海洋或完全变成岛屿。 使用 将 us-vs-them 作为命令行工具使用，需要 bbin 进行本地安装。make install 一个 Git 仓库已经是一个版本历史，每个版本都有一个来源标记 - 每个文件的修订，按顺序排列，以及进行更改的作者。要在 Git 仓库内的任何地方使用它：us-vs-them --ours dan@eighttrigrams.net README.md 这将产生如下列表 1-3 0.00 4 1.00 5-7 0.00 8-20 0.46 21-164 0.00 其中 1.0 意味着完全人类创作的范围。0.46 意味着最初由人类创作的范围，经过代理修改一定程度。0.00 意味着完全由代理创作。 参数是： --ours：这些是人类，其他人被视为代理 --theirs：这些是代理，其他人被视为人类 选择较短列表的一方名称。 동시에传递两个参数将被拒绝。 开发 make test 行为 了解行为的最佳方式是查看 caution_test.clj。