熟悉这个项目的小伙伴，应该还记得 Bensz Channel 上那篇《开源新项目 BAC：给 AI 编程一个篡改可发现的贡献记录》：当时我们聊的是，如何给人类和 AI 共同完成的工作留下一份可复核的过程记录。随后，bensz skills v4.1.0 → v4.1.1 的文章介绍了它怎样接进项目初始化；6 月 13 日的《BAC 更新手记：让人类贡献不再隐形，账本也更扛造了》，又把人类输入记录、并发写入和历史账本修复讲到了 v1.3.2。顺着这条线往下看，最近的 BAC 开始认真打磨另外几件事：让自托管部署更稳妥，让第一次接触它的人更容易上手，也让“这些记录究竟能帮我们判断什么”有一套更扎实的验证思路。今天就接着上次，聊聊这段进展。(～￣▽￣)～

对日常使用者而言，这轮最值得关注的变化，是部署配置对密钥和数据库的保护更细了，中英文使用文档更贴近真实协作场景了，项目也开始系统地研究过程记录的实际价值。先交代一下版本情况：截至 2026 年 10 月 2 日查询，上篇文章之后，主分支新增了 13 个 commit，最近一次提交在北京时间 9 月 20 日；正式 GitHub Release 仍然是 6 月 7 日的 v1.3.2。因此，这篇介绍的是主分支后续的部署、文档和研究进展。已经发布过的人类输入记录、云端锚定、账本锁和安全修复，本次就不再当作新功能重复介绍了。

1 自托管的小伙伴，先关注这次部署加固

BAC 的一个实用设计，是完整账本留在本地，远程服务只接收用于锚定的盲化摘要，以及可选的低敏统计信息。对个人项目，这让你可以保留自己的工作上下文；对愿意自托管的团队，则多了一条独立保存签名回执的路径。8 月 9 日的部署提交，主要是在这条已有路径上把配置做得更稳妥。

1.1 给签名密钥一个更合适的位置

远程回执靠签名提供可核验的证据，签名私钥自然是服务端最需要照顾好的东西。新的 Compose 配置把它放在独立的 secret 文件里，以只读方式挂载到应用容器。同时，各个服务按自身需要接收配置：PostgreSQL 只拿数据库初始化相关变量，Redis 不接收业务密钥，应用也不再把整份 .env 直接装进容器。

对部署者来说，变化很具体：需要管理的凭证有了更清楚的位置，哪些服务接触哪些信息，也更容易检查。复制配置、检查容器或者排查故障时，少一些“不小心把不相关的凭证也带过去”的机会。这里没有什么神秘技术，真正有用的是把默认配置里的权限和信息分布收拾清楚。

还有一个容易忽略的细节：部署文件把服务环境固定为 production。此前依赖环境变量填值的地方，现在少了一个因拼写或配置遗漏而让生产保护意外降级的入口。长期维护过 Docker 服务的小伙伴应该懂，这种小地方，比表面上看起来更值得较真。

1.2 数据库收进去，应用入口留清楚

新的网络布局把 PostgreSQL 和 Redis 放到内部后端网络，只有应用同时连接反向代理网络。用于本地联动验收的端口绑定在服务器的回环地址，可以通过 SSH 隧道访问。

这会让自托管时的入口更容易理解：数据库和缓存作为后端组件待在内部；应用负责提供服务；需要公网访问时，再配置域名、反向代理和 HTTPS。照着示例起容器之后，仍然需要完成正式的公网接入配置，部署文档已经把这一步写明白了。对准备把 BAC 用到长期项目中的朋友，这种分工能减少后续维护时的猜测。

镜像也同时固定了版本和已核验的摘要。版本号方便人理解，摘要则让拉取对象更明确。当你需要复现一次部署、比较两台机器的环境，或者确认更新前后究竟运行了什么，这份确定性就派上用场了。这些更新目前在仓库的部署资产中，现有服务器需要主动同步对应配置才能受益；单独升级本地 Python 包，不会替你修改服务器上的 Compose 文件。

2 第一次接触 BAC，终于更容易知道从哪里开始

6 月的 README 优化之后，8 月 27 日又对中英文首页做了一次较完整的叙事调整。现在打开项目，先看到的是一个很熟悉的协作场景：Git diff 告诉你哪些代码变了，但那条关键需求是谁提出的、方案为什么被否决、测试究竟观察到了什么，往往还散落在对话和命令输出里。

BAC 要保存的，正是这些过程上下文。人类提出目标或做出决定，AI 提出方案或生成内容，工具给出可观察结果，人类再审阅和批准。先理解这条工作线，后面再看 .bac 文件、验证器和锚定，就容易得多。

这种调整对新用户很有意义。过去你可能得先读懂一串格式名、字段和命令，才能判断“它和我有什么关系”；现在可以先判断自己的项目是否需要保留协作过程，再选择记录哪些阶段、是否使用远程服务。对于准备把工具介绍给合作者的朋友，中英文两份文档也有了更一致的阅读顺序。

2.1 快速开始围绕一次完整协作展开

当前首页把安装、初始化、人类输入、AI 工作、测试证据、验证与查看时间线，放在同一个快速开始流程里。默认账本仍然是 docs/contribution.bac，原有命令也没有因为这次文档重写而换一套。变化在于，示例更清楚地告诉你：一次协作里，哪些信息应该分开记录，之后又怎样把它们串起来看。

例如，人类输入的推荐记录时机，是 AI 工具宿主收到用户消息的时候；历史 Prompts.md 则适合补录或交叉核验。接好宿主调用之后，关键约束更有机会在发生时留下记录。如果尚未接入，这部分也需要你或工作流主动调用命令，仅仅安装 BAC，并不会让它自动监听所有编程工具的对话。

已有用户同样能从这次文档里得到几个实用答案：只想提取人类贡献，可以用 bac inspect --human；要细分时间段，可以按来源和日期过滤；验证失败时，先读报告，再判断是不是受限尾部修复能处理的机械性问题。它们都已是此前版本的能力，这次改善的是查找路径和解释方式，让你少花时间在文档里来回翻。

2.2 把判断边界讲清楚，也是一种体验优化

新版首页把“批准不等于创作”放在核心理念里，还补齐了适用场景、安全边界和常见问题。你同意 AI 生成的代码进入项目，账本应保留 AI 生成的来源，再追加你的批准事件。你向 AI 提交了一段外部材料，记录能说明你提供了这段上下文，至于材料的原创来源，仍然需要其他证据。

读起来好像比较克制，但这对真正准备使用 BAC 的人很重要。它帮助你理解一份报告可以拿来回答什么，也避免合作者对“验证通过”产生过高期待。账本完整性、记录覆盖程度、现实中的作者归属，是需要分别审视的事情。能让用户正确理解结果，工具才更容易进入正式协作。

3 接下来最值得期待的，是验证这些记录有没有实际价值

8 月下旬之后，仓库新增了人机协作贡献溯源的文献综述和研究计划。综述除了可阅读的 PDF、Word 版本，也保留了源文件、参考文献、结构化证据卡和验证报告。愿意深入了解这个方向的小伙伴，可以在 docs/reviews/ 里找到背景材料。

这批提交的产品意义，在于项目开始追问一个很实际的问题：同一段人机协作，交给一个没有参与过的人复核，BAC 的记录能不能帮助他更准确地还原过程？

想象一个常见场景：你要求某项重构必须兼容旧数据，AI 先提出一个方案，你指出它会破坏兼容性，工具随后验证了调整后的实现。几周后，接手者看到最终 diff，知道代码已经变了，却未必知道那条约束怎样影响了方案。过程记录的潜在价值，就在于把关键需求、被否决的选择、实际修改和测试结果放回各自的位置。

研究计划准备把同一批底层事实组织成 Git、Git 加普通日志、BAC 等不同证据视图，再让独立审计者回看。这样才能分辨，改善究竟来自记录组织方式，还是因为某一组材料碰巧比其他组多提供了信息。对用户来说，关心的结果也很朴素：关键决定更容易找回来吗？来源和先后关系更容易看清吗？为此多付出的记录时间和隐私成本是否值得？

这些是正在形成的研究方案，尚不能写成已经证明的产品效果。 现阶段没有新的自动贡献评分功能，也没有正式实验结果可以支持“BAC 已经优于 Git 加日志”这样的结论。项目把比较对象、独立证据和停止条件提前写下来，是为了让后续投入有一个可检查的依据。

3.1 从真实使用里找问题，才知道该优化哪里

8 月的研究计划还纳入了一次真实项目的只读盘点。公开方案记录的当时快照，包含 24 个账本、6,361 条事件；这是单一使用者项目生态中的历史材料，数量本身不能代表普遍效果，但已经能帮助发现一些真实使用问题。

例如，很多账本里并没有充分记录人工批准，工作区经常处于未提交状态，也存在 Git 上下文缺失或来源语义冲突。对产品来说，这些都很有价值：它们提示后续需要继续改善记录覆盖、宿主集成和报告解释。让账本积累更多事件只是起点，关键阶段有没有留下证据、结果能不能被下一位读者理解，还需要持续打磨。

我挺看重这种从实际使用出发的推进方式。它愿意把缺口拿出来分析，也明确区分初步盘点与正式研究。至于某个账本出现 warning 或 fail，还需要结合历史版本、项目上下文变化和实际完整性问题逐项复核，不能直接给人扣上“篡改”的帽子。这种解释能力，对以后真正参与团队对账的工具尤其重要。

3.2 最近的讨论，进一步追到了证据和干预的关系

9 月的提交与变更记录，又把研究方向推进到两个相互关联的问题：证据不完整时，来源主张能被支持到什么程度；人类在关键节点上的真实干预，是否改善了最终结果。

这和小伙伴们平时的使用感受很接近。你指出一次失败测试、补充一个限制条件，或者拒绝一个看似合理的方案，可能只留下短短一句话，却改变了后续工作的方向。怎样保留它的证据，怎样判断它是否发挥作用，都比单看修改行数更接近协作现场。

目前这部分属于研究方向和计划沉淀，部分进展以 CHANGELOG 条目记录，还没有成为可直接使用的 CLI 新功能。我个人更期待它最后带来的是：复核时能更清楚地说明哪些判断有证据、哪些仍缺材料，并帮助我们找到最值得保留的人类决策节点。这样的改善，才会让日常记录真正服务于下一次协作。

4 现有用户该怎么跟进

如果你主要在本地记录贡献，继续使用 v1.3.2 即可。本轮没有新的正式 Release，也没有更换账本格式；可以先读一遍当前中文 README，把人类输入、工具证据和人工批准的记录时机检查一下。

如果你自托管了 BAC Anchor，建议重点查看仓库当前的 docs/deploy/。这轮实际落地的配置变化集中在签名密钥、镜像固定、服务变量分配和网络布局。更新部署时，也记得同步准备独立密钥文件，并按自己的环境配置反向代理与 HTTPS。

如果你关注人机协作审计，或者愿意参与后续验证，可以继续跟进公开综述和研究计划。现阶段最有帮助的反馈，可能就是一个具体的工作片段：某条关键需求在哪里漏掉了，某份测试证据为什么难以复核，或者交接时哪一个判断仍然说不清。这样的场景，往往更能推动产品下一步的优化。

5 小结

上次我们把 BAC 讲到 v1.3.2，重点是补齐人类输入、稳住账本写入。这次主分支的 13 个提交，则把注意力推进到部署、上手和实际效用：自托管配置更清楚地管理密钥与网络，中英文首页围绕协作场景解释使用路径，研究材料开始认真检验记录能否帮助他人恢复贡献边界。正式 Release 暂时没有变化，后续研究也还需要执行和验证。我更期待这些积累最终让 BAC 成为一个容易接入、便于复核、能在项目交接时帮上忙的工具。小伙伴们如果也遇到过“成果留下了，过程却说不清”的问题，欢迎继续关注，或者分享自己的使用场景。

项目 GitHub 地址：https://github.com/huangwb8/bensz-auto-contribution