60%代碼是AI寫的，出Bug時人類背鍋

你的團隊用Claude Code、Cursor或Gemini寫代碼，60%-80%的新提交都是AI生成的。但當線上崩潰時，你能回答那個致命問題嗎——這行代碼是哪個AI寫的？

傳統git blame（代碼溯源）告訴你誰提交的。可問題是：當整個團隊都在用AI代理時，"提交者"永遠是那個按回車的人類——哪怕Claude寫了90%的文件。責任鏈斷了。

一個開源工具Origin想補上這個缺口。它做的不是追蹤"誰按了提交鍵"，而是記錄AI的完整"作案痕跡"：哪個代理生成的代碼、什么提示詞（prompt）產生的、用了什么模型、花了多少錢。

Hook進AI的每一次"腦電波"

Origin的工作原理像給AI裝黑匣子。每次AI代理啟動會話，鉤子（hook）自動觸發：

Claude Code的鉤子通過origin init自動安裝，捕獲會話開始、用戶提交提示、停止三個關鍵節點。Cursor和Gemini CLI同理。

提交發生時，Origin把會話數據寫入git notes（Git的元數據存儲區），而非修改代碼本身。這意味著：

git notes show HEAD
# Origin-Session: abc123
# Agent: claude-code
# Model: claude-opus-4-6
# Cost: $2.40
# Prompts: 12

這些信息跟著代碼走，但不會被常規diff顯示，需要專門命令查看。

AI Blame：一行一行拆穿作者

Origin的核心命令是origin blame。它把文件拆成人類和AI的"合著"：

origin blame src/api.ts

Line Tag Model Content
────────────────────────────────────────
1 [HU] import express from 'express'
2 [AI] claude-opus-4-6 const app = express()
3 [AI] claude-opus-4-6 app.use(express.json())
4 [HU] // my custom middleware

[HU]是人類，[AI]是代理，后面跟著具體模型版本。當Claude Opus 4.6和GPT-4o混用同一個文件時，你能精確定位哪行是誰的手筆。

這對調試意味著什么？假設第47行有個邊界條件bug，origin blame顯示它來自claude-sonnet-3.5，而你知道這個模型在特定提示結構下容易生成錯誤的null檢查。排查方向瞬間收窄。

回溯：給沒裝Hook的歷史"補錄口供"

最實用的功能可能是origin backfill。很多團隊已經用了幾個月AI工具，歷史提交全是"黑箱"。

origin backfill --apply

這個命令分析提交信息模式、作者郵箱、代碼風格，推斷哪些提交是AI生成的——即使沒有當時的Hook記錄。它不是100%準確，但能給出一個概率分布，讓你對技術債務的"AI含量"有數。

Origin還在提交前設卡。預提交鉤子（pre-commit hook）從儀表盤拉取活躍策略，攔截含密鑰的提交、限制文件的修改、甚至按代理設置預算上限。比如你可以規定：Claude Code單會話不得超過5美元，超出就阻斷。

無服務器架構：數據主權換便利

Origin的設計有個微妙取舍。數據存在git notes里，單機模式不需要服務器。這對安全敏感團隊是賣點——你的AI使用記錄不會流向第三方SaaS。

但團隊儀表盤是云端服務。想要可視化報表、策略集中管理，就得把元數據同步上去。開源CLI和托管服務的關系，有點像Git和GitHub。

安裝兩條命令：

npm i -g https://getorigin.io/cli/origin-cli-latest.tgz
origin init

支持Claude Code、Cursor、Gemini CLI、Codex。項目已開源在GitHub，團隊功能需要注冊getorigin.io。

一個值得玩味的細節：Origin的README里埋著一句"Templates let you quickly answer FAQs or store snippets for re-use"——這句話在原文末尾孤立出現，沒有上下文。是文檔沒寫完，還是功能還沒發布？

如果你的代碼庫已經有40%以上提交來自AI，你會愿意為了可追溯性，給每個開發者再裝一層工具鏈嗎——還是說，"誰寫的"這個問題，在AI時代已經不那么重要了？