AI正在吃掉代码的"族谱"，有人写了个工具找回它

你让AI写一段分页代码，它30秒交卷。但没人告诉你：这段代码是从哪学来的，为什么这样写，以及——哪些部分是AI自己"脑补"的。

GitHub上那个花了两小时解释"游标分页为何优于偏移量"的工程师，Stack Overflow里那个调试一周才写下并发写入陷阱的开发者，他们的心血被AI吞掉后，连一句致谢都没有。

更隐蔽的代价是：新加入的程序员面对这段代码，找不到任何可追溯的线索。六个月后，没人记得当初的设计决策。bug出现时，你只能像考古一样挖两天git记录。

一位开发者决定阻止这种"知识的隐形消失"。

他造了一把"代码族谱"的铲子

工具叫proof-of-contribution，一个Claude Code技能插件。核心逻辑很朴素：AI生成的每段代码，必须系上一根绳子——绳子那头是真实的人类知识来源。

不是文件顶部的注释（没人看），而是结构化、可查询、甚至可强制执行的溯源记录。

举个例子。你运行poc.py trace src/utils/paginator.py，30秒内看到：

——这段游标分页模式来自GitHub用户@tannerlinsley的讨论，链接直达原文，核心洞见是"游标在实时更新数据集时优于偏移量"。

——同时标红两段"知识缺口"：错误重试策略、并发写入处理，均标注"AI合成，无人类来源"。

「考古优先，而非强制优先」，这是设计者反复强调的原则。不是逼AI必须引用，而是先把"哪部分代码没有人类背书"暴露出来。

为什么"无来源"比"有来源"更关键

上面那个例子里的并发写入处理，正是bug的藏身之处。AI做了一个未经评审的选择，而旧的工作流里，这个选择被埋在一堆看似正常的代码中。

设计者描述了一个典型场景：新开发者加入团队，面对六个月AI辅助积累的代码库，遇到分页逻辑异常。传统路径是git blame→"fix pagination"→"implement pagination"→死胡同。

有了溯源块，他直接看到：核心模式有出处，但边缘决策是AI的黑箱。

这种区分能力，在AI代码占比越来越高的团队里，可能是救命稻草。

一个被忽视的系统性风险

这件事的底层逻辑值得拆开看。

AI训练时吃掉了海量人类知识，但生成输出时却切断了回馈链条。没有引用，原作者收不到信号；没有溯源，后续维护者无法判断代码的可信度；没有记录，组织层面的知识积累被逐步掏空。

长此以往，一个反直觉的循环形成：AI越依赖人类知识库，人类越缺乏动力维护知识库。因为贡献者看不到自己的作品被使用、被认可、被迭代。

proof-of-contribution尝试在工程层面打断这个循环。它不解决版权问题（那是法律层），也不解决模型训练伦理（那是政策层），它解决的是一个更务实的问题：在AI已成标配的开发流程里，如何保留人类的可追溯性。

这工具能活吗？看一个细节

它的设计选择透露了真实意图。

溯源块是自动附加的，但"知识缺口"的标注是AI自己完成的——Claude被提示去识别"这部分我没找到人类来源"。这是一种有趣的元认知：让AI标记自己的不确定性。

这比强制引用更轻量，也更诚实。毕竟，逼AI编造一个来源，比承认"我不知道"危害更大。

另一个细节是格式：溯源块用结构化文本（## PROOF OF CONTRIBUTION），不是专有格式。这意味着它可能被其他工具解析，形成生态。

不过挑战也很明显。如果团队不强制执行，溯源块会变成新的"没人看的注释"；如果AI生成的代码量爆炸，人工审核"知识缺口"的成本会压垮团队。

设计者目前的定位是"考古工具"而非"合规框架"，这个克制可能是对的——先让人用起来，再谈制度化。

数据收束

这个工具的GitHub仓库目前处于早期阶段，具体star数和贡献者数据原文未披露。但从设计思路看，它切中了一个正在快速放大的痛点：2024年GitHub报告显示，AI辅助编码工具的全球开发者使用率已超过70%，但配套的知识管理基础设施几乎为零。

当AI生成的代码占比从10%爬到50%再爬到90%，"这段代码从哪来"会从一个nice-to-have变成blocking issue。proof-of-contribution的价值不在于它现在的功能完整度，而在于它提出了一个正确的问题——并且用工程手段给出了可验证的答案。