开源新项目 BAC：给 AI 编程一个篡改可发现的贡献记录
概览 本文介绍新开源项目 BAC（Bensz Auto Contribution），一个面向 AI 编程工具的贡献归因与审计系统 BAC 的核心产物是 .bac...
BenszConan
管理员
文章目录 ⌄
概览
- 本文介绍新开源项目 BAC（Bensz Auto Contribution），一个面向 AI 编程工具的贡献归因与审计系统
- BAC 的核心产物是
.bac文件：一个绑定项目、追加式、篡改可发现的贡献记录 - 项目从 0 到 1 仅用 6 天完成 MVP，目前已迭代到 v1.2.3，支持完整的本地+远程锚定工作流
- 详细拆解 BAC 的设计理念、技术架构和使用方式，帮助读者快速理解"人机协作归因"这一新赛道
- 项目已发布到 PyPI，支持
pip install一键安装，开箱即用
前言
用过 Claude Code 或 Codex 的小伙伴大概都有过这种困惑：一个项目写下来，哪些代码是自己写的？哪些是 AI 生成的？哪些是工具自动跑出来的？到最后混成一团，根本说不清楚。尤其当你需要在团队里说明"AI 到底做了什么"，或者面对论文署名争议、合规审计这类正式场景时，这个问题就变得特别扎手。
我自己做 vibe coding 也有段时间了，这种"人机边界模糊"的痛感越来越强。所以前阵子我认真琢磨了一下这个问题，最后做成了一个开源项目——BAC（Bensz Auto Contribution）。它的定位很明确：不替你裁判谁贡献了多少，但帮你把"谁做了什么"这件事记清楚、存下来、验得明。
今天这篇文章就来聊聊这个项目的设计思路和技术实现，希望对同样在 AI 辅助开发中摸索的小伙伴有所启发 (～￣▽￣)～
人机协作归因：一个真实且紧迫的问题
先说说为什么这件事值得做。
很多团队现在都在大量使用 AI 编程工具，但问到"你的项目里 AI 到底贡献了多少"，大多数人只能凭感觉给个模糊回答。这在个人项目里也许无所谓，但在团队协作、科研合作、开源贡献这些场景下，问题就来了。比如导师问你这个方案是 AI 写的还是你自己想的，合作者质疑某段代码的来源，审稿人要求说明 AI 使用情况——这些都需要一个可追溯的记录，而不是一句"大概用了 AI 吧"就能打发的。
更关键的是，随着 AI 编程工具的能力越来越强，人机协作只会越来越多，而不是越来越少。这意味着"贡献归因"不是一个临时问题，而是一个长期需求。与其等出了问题再临时抱佛脚，不如从现在就开始建立一套可靠的过程记录机制。
这就是 BAC 想做的事情。
BAC 是什么？
用一句话概括：BAC 是一个面向 AI 编程工具的贡献归因与审计系统。它的核心产物是一个叫做 .bac 的文件，本质上是一个绑定到具体项目的、追加式的、篡改可发现的贡献记录。
这里有几个关键词需要解释一下。
**"绑定到具体项目"**意味着 .bac 文件不是随便乱记的，它会把贡献事件和项目的 git 远程地址、当前 commit、分支、dirty 状态等上下文信息绑定在一起，让记录有据可查。
**"追加式"**是指 BAC 采用的是事件模型——每次记录都是一个新事件，追加到已有的事件链后面，而不是覆盖旧记录。这样你就能看到一个完整的"贡献时间线"，谁先做了什么、后来又发生了什么，一目了然。
**"篡改可发现"**是 BAC 安全模型的核心。BAC 诚实地把自己定位为 tamper-evident（篡改可发现），而不是 tamper-proof（篡改不可能）。它通过 canonical JSON + SHA-256 哈希链来实现完整性保护：每条事件都包含前一条事件的哈希值，形成一条链；任何人如果修改了中间某条事件的内容、删除了事件、插入新事件或重排顺序，验证时都会被发现。这是一种务实的安全设计——不吹牛说"绝对改不了"，但保证"改了能查出来"。
另外，BAC 把贡献来源明确分成四类：human（人类）、ai（AI）、tool（工具）、system（系统）。每条事件都会标记自己的来源类型，这样在事后审查时就能清晰地看到"这条是人类的需求，那条是 AI 的实现，又一条是测试工具的输出"。
.bac 文件长什么样？
从用户角度看，.bac 就是一个文件（默认叫 project.bac），非常简单。但内部它其实是一个 ZIP 容器，至少包含一个 manifest.json（记录容器版本、项目绑定信息等元数据）和一组按顺序编号的事件文件 events/000000000001.json、events/000000000002.json……
每条事件的核心字段包括事件类型（比如 human_instruction、ai_generation、test_result、checkpoint）、来源类型（human/ai/tool/system）、信任等级（从 declared 到 anchored 五级）、项目上下文（git 信息）、事件摘要和载荷、证据信息（diff 摘要、文件 hash 等）、脱敏记录，以及最重要的——前一条事件的哈希值和当前事件的哈希值，形成可验证的哈希链。
这种设计的好处是既保持了用户侧"只有一个文件"的简洁体验，又为后续的签名、时间戳、索引扩展预留了充分的内部空间。
怎么用？
BAC 的使用非常轻量，整个过程只需要几个命令。
安装只需要一行：pip install bensz-auto-contribution。Python 3.10+ 即可，没有运行时第三方依赖，这点我特意保持干净的。
在项目根目录初始化后，你就可以开始记录贡献事件了。比如记录一条人类需求：
bac record --event-type human_instruction --source-type human --summary "Add BAC verification workflow"
记录 AI 的实现：
bac record --event-type ai_generation --source-type ai --summary "Implemented hash-chain verifier"
记录工具的测试结果：
bac record --event-type test_result --source-type tool --summary "Unit tests passed" --command-text "python -m unittest discover -s tests -v" --exit-code 0
随时可以用 bac verify 验证完整性，用 bac inspect 查看贡献时间线。特别实用的一个功能是 bac inspect --human，可以快速提取所有人类贡献事件，还能按日期范围过滤。
隐私保护锚定：本地优先，远程可选
这是一个我特别在意的设计点。
BAC 默认使用 hybrid 模式，但账本始终是本地优先的。如果你只想本地用，完全不需要连接任何外部服务。当需要远程锚定时，BAC 只会上传一个盲化的 anchor_hash（对原始哈希再做一次单向变换）和一个低敏感度的 client_summary（仅包含事件数量、来源/信任等级计数等聚合信息），绝不会上传文件路径、diff 内容、prompt、actor 信息、项目名或原始哈希值。
远程锚定服务会返回一个 Ed25519 签名的 receipt，本地把它存入 .bac 作为一条 anchored checkpoint。这样即使有人想篡改记录，只要 receipt 还在，就能证明"在服务端时间戳那个时刻，这个账本状态确实存在过"。
BAC 还提供了完整的云端工作流（bac cloud register/login/link/status），可以把本地项目绑定到你自托管的服务端，后续 bac record 时自动完成远程锚定，非常省心。
项目演进：6 天从 0 到 v1.2.3
回头看看这个项目的演进速度，我自己也觉得挺疯狂的。
从 5 月 26 日初始化项目指令开始，28 日完成 MVP（v1.0.0），29 日升级到 v1.1.0 引入 ZIP 容器格式和双语 README，30 日完成了 private-anchor 客户端和 reference server，31 日又加上了 BAC Cloud 账号绑定、贡献提取过滤和 DockerHub 发布流程。整个项目从零到拥有完整的本地+远程锚定、云端工作流、PyPI 发布、DockerHub 发布，只用了 6 天。
这背后的核心支撑是我自己的 AI 编程工具链——Claude Code 和 Codex。项目里同时包含了 CLAUDE.md 和 AGENTS.md，两套 AI 工具共享同一套工程原则和变更规范。说实话，如果没有 vibe coding 的工作方式，这个项目不可能在这么短的时间内完成从概念到产品的完整闭环。
项目的安全模型也经历了仔细的威胁建模：验证器会把 .bac 文件视为不可信输入，在读取前限制容器总大小、事件数量和单个 JSON 成员大小；anchor push 默认拒绝不安全 URL 和解析到内网的域名；生产模式要求 token 保护写入、管理页面和账本查询。
小结
BAC 解决的核心问题是：在人机协作日益普遍的今天，我们需要一个可靠的方式来记录"谁做了什么"。它不是最终裁判，不会自动决定学术署名或法律归属——这些判断仍然需要结合项目制度、机构规则和人工判断。但它提供了一个坚实的证据基础，让这些判断有据可依。
如果你也在用 AI 编程工具做项目，不妨试试 BAC。项目完全开源，MIT 协议，GitHub 地址是：https://github.com/huangwb8/bensz-auto-contribution。觉得有用的话帮忙点个 Star，这对独立开发者来说真的意义重大 (～￣▽￣)～
有问题或建议欢迎到 GitHub 提 Issue 或 PR，也可以在评论区留言讨论！
项目地址：https://github.com/huangwb8/bensz-auto-contribution
评论区
0 条评论