你讓AI寫一段分頁代碼，它30秒交卷。但沒人告訴你：這段代碼是從哪學來的，為什么這樣寫，以及——哪些部分是AI自己"腦補"的。

GitHub上那個花了兩小時解釋"游標分頁為何優(yōu)于偏移量"的工程師，Stack Overflow里那個調(diào)試一周才寫下并發(fā)寫入陷阱的開發(fā)者，他們的心血被AI吞掉后，連一句致謝都沒有。

更隱蔽的代價是：新加入的程序員面對這段代碼，找不到任何可追溯的線索。六個月后，沒人記得當初的設計決策。bug出現(xiàn)時，你只能像考古一樣挖兩天git記錄。

一位開發(fā)者決定阻止這種"知識的隱形消失"。

他造了一把"代碼族譜"的鏟子

工具叫proof-of-contribution，一個Claude Code技能插件。核心邏輯很樸素：AI生成的每段代碼，必須系上一根繩子——繩子那頭是真實的人類知識來源。

不是文件頂部的注釋（沒人看），而是結構化、可查詢、甚至可強制執(zhí)行的溯源記錄。

舉個例子。你運行poc.py trace src/utils/paginator.py，30秒內(nèi)看到：

——這段游標分頁模式來自GitHub用戶@tannerlinsley的討論，鏈接直達原文，核心洞見是"游標在實時更新數(shù)據(jù)集時優(yōu)于偏移量"。

——同時標紅兩段"知識缺口"：錯誤重試策略、并發(fā)寫入處理，均標注"AI合成，無人類來源"。

「考古優(yōu)先，而非強制優(yōu)先」，這是設計者反復強調(diào)的原則。不是逼AI必須引用，而是先把"哪部分代碼沒有人類背書"暴露出來。

為什么"無來源"比"有來源"更關鍵

上面那個例子里的并發(fā)寫入處理，正是bug的藏身之處。AI做了一個未經(jīng)評審的選擇，而舊的工作流里，這個選擇被埋在一堆看似正常的代碼中。

設計者描述了一個典型場景：新開發(fā)者加入團隊，面對六個月AI輔助積累的代碼庫，遇到分頁邏輯異常。傳統(tǒng)路徑是git blame→"fix pagination"→"implement pagination"→死胡同。

有了溯源塊，他直接看到：核心模式有出處，但邊緣決策是AI的黑箱。

這種區(qū)分能力，在AI代碼占比越來越高的團隊里，可能是救命稻草。

一個被忽視的系統(tǒng)性風險

這件事的底層邏輯值得拆開看。

AI訓練時吃掉了海量人類知識，但生成輸出時卻切斷了回饋鏈條。沒有引用，原作者收不到信號；沒有溯源，后續(xù)維護者無法判斷代碼的可信度；沒有記錄，組織層面的知識積累被逐步掏空。

長此以往，一個反直覺的循環(huán)形成：AI越依賴人類知識庫，人類越缺乏動力維護知識庫。因為貢獻者看不到自己的作品被使用、被認可、被迭代。

proof-of-contribution嘗試在工程層面打斷這個循環(huán)。它不解決版權問題（那是法律層），也不解決模型訓練倫理（那是政策層），它解決的是一個更務實的問題：在AI已成標配的開發(fā)流程里，如何保留人類的可追溯性。

這工具能活嗎？看一個細節(jié)

它的設計選擇透露了真實意圖。

溯源塊是自動附加的，但"知識缺口"的標注是AI自己完成的——Claude被提示去識別"這部分我沒找到人類來源"。這是一種有趣的元認知：讓AI標記自己的不確定性。

這比強制引用更輕量，也更誠實。畢竟，逼AI編造一個來源，比承認"我不知道"危害更大。

另一個細節(jié)是格式：溯源塊用結構化文本（## PROOF OF CONTRIBUTION），不是專有格式。這意味著它可能被其他工具解析，形成生態(tài)。

不過挑戰(zhàn)也很明顯。如果團隊不強制執(zhí)行，溯源塊會變成新的"沒人看的注釋"；如果AI生成的代碼量爆炸，人工審核"知識缺口"的成本會壓垮團隊。

設計者目前的定位是"考古工具"而非"合規(guī)框架"，這個克制可能是對的——先讓人用起來，再談制度化。

數(shù)據(jù)收束

這個工具的GitHub倉庫目前處于早期階段，具體star數(shù)和貢獻者數(shù)據(jù)原文未披露。但從設計思路看，它切中了一個正在快速放大的痛點：2024年GitHub報告顯示，AI輔助編碼工具的全球開發(fā)者使用率已超過70%，但配套的知識管理基礎設施幾乎為零。

當AI生成的代碼占比從10%爬到50%再爬到90%，"這段代碼從哪來"會從一個nice-to-have變成blocking issue。proof-of-contribution的價值不在于它現(xiàn)在的功能完整度，而在于它提出了一個正確的問題——并且用工程手段給出了可驗證的答案。