作者 | 褚杏娟

據 Business Insider 報道，Anthropic 正在通過一個由約 1000 名人類軟件工程師參與的項目，提升旗下 AI 編程工具 Claude Code 的表現。

該項目在數據標注公司 Snorkel AI 內部代號為 “Marlin”，核心目標并不是簡單讓模型“會寫代碼”，而是讓 Claude Code 的回答更接近專業開發者的真實工作方式：代碼更干凈、更可靠，也更容易維護。

這次曝光的 Marlin 項目，揭開了 Claude Code 能力迭代背后的另一層基礎設施：不是單純依賴模型自我進化，而是引入大量具備軟件工程背景的人類承包商，對模型輸出進行高質量反饋。

根據報道，兩名參與 Anthropic 項目的承包商表示，他們每完成一項創建提示詞和審查代碼的任務，可獲得 280 美元報酬。每項任務通常耗時約一小時，但部分提交內容還需要與 Snorkel 的審核層進行多輪溝通。

根據 Business Insider 查閱到的 Snorkel 項目指南，參與 Marlin 項目的自由職業者需要對兩個不同模型生成的代碼進行 A/B 測試。他們會比較兩組輸出，選擇自己更偏好的結果，并判斷模型是否真正達到了提示詞要求的細節程度。一名承包商稱，該項目本質上是在訓練 Claude Code 寫出更簡化、更易維護的代碼。

從任務設計看，Marlin 更像是在模擬真實開發場景，而不是傳統意義上的低門檻數據標注。承包商會從包含數千個代碼倉庫的列表中選擇 GitHub 倉庫，創建一個類似真實開發流程中的 PR，例如新增功能、修復漏洞或重構代碼。隨后，他們還需要編寫提示詞，說明希望模型完成什么任務。

在一項任務中，承包商要求模型重新組織系統存儲和處理“執行元數據”（execution metadata）的方式。該任務的重點不是改變產品功能，而是在不影響實際運行邏輯的前提下，讓代碼結構更清晰、更方便開發者后續維護。

在另一項任務中，模型被要求完成一項安全修復，涉及開源機器學習平臺 MLflow 在加載部分模型時下載 Python 軟件包的方式。任務說明要求承包商從正確性、安全性、可靠性和可維護性角度評估代碼，并確保修復方案既能阻止命令注入攻擊，又不會誤傷合法的白名單 pip 選項。

這意味著，Claude Code 的提升并不只是靠“寫得更多”，而是靠專業工程師不斷告訴模型：什么樣的代碼才算能進生產環境，什么樣的修改只是表面可用，什么樣的實現會在長期維護、安全邊界和工程協作中留下隱患。

據悉，目前 Marlin 項目仍在進行中，參與評估的承包商也并不知道自己正在測試的是哪個版本的模型。

值得注意的是，這也反映出了數據標注行業的結構性變化。過去，AI 數據工作往往被視為低門檻、重復性勞動；但隨著模型能力提升，訓練數據本身正在變得更加專業化。Snorkel 由斯坦福研究人員創辦，公司會與擁有高等學位或同等經驗的人合作，包括博士、醫學博士和法學博士等，頂級專家每周收入可超過 3000 美元，其客戶包括 Google、Mistral 和 Anthropic 等。除 Snorkel 外，Scale AI、Mercor 等平臺也在為軟件工程師提供最高每小時 110 美元的報酬。

1 越復雜、Claude Code 錯越多，靠人救？

Claude Code 正在被 Anthropic 推向更復雜的工程場景，但用戶反饋也顯示，這類 AI 編程工具距離穩定承擔復雜工程任務仍有距離。

作為一個完全用 AI 寫出來的編程工具，Claude Code 官方倉庫里的用戶反饋幾乎每天都在刷新。近期就有用戶稱，自 2 月更新后，Claude Code 在復雜工程任務中的表現明顯退化，已經“無法被信任用于復雜工程工作”。該 issue 已被關閉，但內容提供了一份非常詳細的用戶側實測報告。

提交者稱，Claude Code 會忽視指令、聲稱采用“最簡單修復”，但結果錯誤、執行與要求相反的操作，并在沒有真正完成任務的情況下宣稱完成。

提交者表示，他們擁有一個高度穩定、復雜度較高的工程環境，并分析了從 1 月到 3 月的大量 Claude Code 會話日志。報告稱，對 6852 個 Claude Code 會話文件、17871 個 thinking blocks 以及 234760 次工具調用的定量分析顯示，所謂“thinking content redaction”的推出，與復雜、長會話工程工作流中的質量退化高度相關。

其認為，當模型的思考深度下降時，它的工作模式會從“先研究、再修改”轉向“先編輯、少研究”，進而導致多步驟研究、項目約定遵循、謹慎代碼修改等能力下降。

數據顯示，Claude Code 在修改代碼前的閱讀行為明顯減少。在表現較好的階段，模型每次編輯前平均有 6.6 次文件讀取；而在退化階段，這一數據降至 2.0，相當于修改前研究量減少約 70%。這讓模型更容易做出“沒讀就改”的操作。該用戶認為，這會導致模型破壞周邊代碼、違反文件級約定、把新代碼插入注釋塊中間，或者重復實現文件中已經存在的邏輯。

除了代碼修改方式變粗糙，用戶還記錄了更多行為層面的異常。例如，模型出現更多推理循環，輸出中頻繁出現“等等”“實際上”“讓我重新考慮”等自我修正；“simplest”一類表達出現頻率上升，被用戶解讀為模型開始傾向于選擇最低成本方案，而不是正確方案；模型也更容易提前停止、請求許可，或者把問題歸因于“已有問題”“已知限制”。

這種質量下降的反饋并不是偶然。4 月，一位自稱過去四個月幾乎每天大量使用 Claude Code 的用戶表示，近期體驗明顯變差。過去，處理網站、落地頁等任務時，Claude Code 可以產出不錯結果；現在則經常需要反復解釋需求，甚至在模型開始執行明顯錯誤的方向時，不得不立刻中止。

該用戶提到，Claude Code 頻繁出現“做錯后道歉”的情況，而自己的提示詞、工作類型和使用方式并沒有變化。后來問題嚴重到，他在用 Claude Code 構建內容后，還需要轉向 Codex 對其結果進行事實核查。 此外，Claude Code 還出現了忘記一些基礎工作流程、執行任務時突然停止等問題。

這反映了 Claude Code 乃至整個 AI 編程工具的關鍵矛盾：越深入復雜工程場景，就越不能只追求“快”和“會改代碼”，而必須具備長期上下文理解、工程約定遵循、多文件推理等。要知道，開發者對工作流級別的可靠性下降是很敏感的。

因此，Anthropic 引入約 1000 名人類軟件工程師，實際上是在用專業工程實踐為 Claude Code 補課，用資深開發者的判斷標準來彌補當前能力的不足。

頗具諷刺意味的一點是，從“vibe coding”走向“工程化 coding”過程中，我們越想讓 AI 像高級軟件工程師一樣工作，似乎就越需要大量真正的軟件工程師參與訓練。

2 AI 帶來“代碼過剩”：有人拒絕，有人審慎治理

去年 3 月，Anthropic CEO Dario Amodei 曾預測，未來 3—6 個月，AI 可能寫出 90% 的代碼；12 個月后，AI 甚至可能幾乎寫出全部代碼。這也是 Anthropic 發力編程的很大現實動力。

有段時間，“AI 代碼占比”一度成為科技公司展示 AI 化程度的新指標。

谷歌是最典型的案例。2024 年第三季度財報電話會上，谷歌 CEO Sundar Pichai 表示，公司超過四分之一的新代碼由 AI 生成，隨后再由工程師審查和接受。而到了今年 4 月，Pichai 又表示，谷歌 75% 的新代碼已經由 AI 生成。

相比大公司，創業公司對 AI 編程的接受程度更激進。此前有報道稱，YC 管理合伙人 Jared Friedman 表示，在 W25 批次中，約四分之一創業公司的代碼庫有 95% 由 AI 生成。這在當時還引發了大量開發者質疑。

而 Anthropic 在今天發布文章《When AI builds itself》指出，在 AI 發展史上，模型研發過去主要由人類驅動；但在 Anthropic 內部，越來越多 AI 開發工作已經交給 AI 系統完成，這正在顯著加快公司的研發速度。

根據其披露的數據，截至 2026 年 5 月，Anthropic 合并進生產代碼庫的代碼中，超過 80% 由 Claude 編寫；而在 Claude Code 于 2025 年 2 月發布研究預覽版之前，這一比例還只是個位數。

此外，截至 2026 年第二季度，其典型工程師每天合并的代碼量已經達到 2024 年的 8 倍。 不過，Anthropic 承認，代碼行數并不是完美的生產力指標，因為它更強調數量而非質量。因此，“8 倍代碼量”很可能高估了真實生產力提升。但 Anthropic 認為，這至少證明了內部研發速度正在顯著加快。

無論如何，在 Claude Code、Codex 等工具推動下，AI 編程工具已經席卷海內外。而隨著 AI 代碼越來越多，如何做好 AI 代碼治理則成為社區的頭等大事。

對此，認為 AI 已經接近人類水平的 Anthropic，并沒有提及過相關信息，僅僅是在博文中呼吁建立可驗證的減速或暫停機制。

現在，開源社區在各自探索對 AI 代碼的處理方式。

有些社區做法比較簡單：開源編程語言 Zig 明確禁止提交 AI 輔助生成的代碼，包括大模型生成的內容和大模型改寫、編輯、構思或調試過的內容。簡單來說，就是不要把 AI 帶進來。

Zig 總裁 Andrew Kelley 將 AI 輔助貢獻稱為“基本都是垃圾”。“有人給我們發來的貢獻沒有任何價值。它們甚至是負價值，因為它們占用了團隊的代碼審查時間。”

在 Kelley 看來，這些 AI 編程者更像是“路過式貢獻者”：他們可能會提交一兩個 pull request，但永遠不會真正加入核心團隊。他表示，如果他說只接受“好的”AI PR，那么審查者就必須逐一判斷每個提交是否合格。“但如果我說一律不接受，那這個政策就非常容易執行。”

雖然 Zig 規模相對較小，但它已經產生了超出體量的影響。例如，Bun 就是用 Zig 創建的，而 Bun 后來被 Anthropic 收購。Zig 的 AI 禁令隨后也在 Bun 與 Zig 之間引發了一些爭議。

Kelley 表示，對 Zig 來說，“導師制”本身就是項目核心使命的一部分，因此 AI 生成的貢獻反而會適得其反。“我們都在努力讓自己成為更好的程序員。那些發送 AI PR 的人，并不會幫助實現這個目標。”

另一方面，Linux 社區則已經開始探索 AI 工具如何更加規范。

此前官方發布的《AI Coding Assistants》指導文件，給 AI 參與嚴肅開源基礎設施開發提供了一套清晰邊界。文件明確，AI 工具可以輔助 Linux 內核開發，但相關貢獻必須嚴格遵守內核現有開發流程、許可證要求和補丁提交規范。

根據文檔，所有使用 AI 輔助提交到 Linux 內核的代碼，仍然必須遵循標準內核開發流程，包括內核開發流程指南、Linux 內核編碼風格，以及補丁提交規范。

在許可證方面，文檔明確要求，所有貢獻都必須符合 Linux 內核的許可規則，即代碼必須與 GPL-2.0-only 兼容，并使用合適的 SPDX 許可證標識。

最關鍵的規定出現在 Signed-off-by 和 DCO 部分。Linux 內核文檔明確寫道，AI agent 不得添加 Signed-off-by 標簽。原因是，只有人類才能在法律意義上認證 Developer Certificate of Origin，也就是 DCO。人類提交者必須審查所有 AI 生成代碼，確保其符合許可要求，并添加自己的 Signed-off-by 標簽，對貢獻承擔全部責任。

這條規定直接劃清了 AI 編程助手在開源貢獻中的責任邊界：AI 可以寫代碼、改代碼、輔助分析，但不能成為法律責任主體。真正提交補丁的人類開發者，仍然是代碼來源、許可證合規、質量和后續維護責任的承擔者。

文檔同時要求，當 AI 工具參與內核開發時，應當通過 Assisted-by 標簽進行歸因，以便追蹤 AI 在開發流程中的作用。推薦格式為：

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

其中，AGENT_NAME 指 AI 工具或框架名稱，MODEL_VERSION 指具體模型版本，后面可以列出使用過的專業分析工具，例如 coccinelle、sparse、smatch、clang-tidy 等。但 git、gcc、make、編輯器等基礎開發工具不需要列入。文檔給出的示例是：

Assisted-by: Claude:claude-3-opus coccinelle sparse

可以看出，相比直接拒絕 AI 輔助貢獻，Linux 采取的是更工程化的治理方式：允許使用，但必須透明披露；可以輔助，但不能簽署；可以生成代碼，但人類必須 review、作證并承擔責任。

在 AI 編程野蠻生長一段時間后，現在人類工程師依然重要。

3 大廠實踐：AI 審代碼，而不是替人類負責

除了開源社區，大廠也在探索如何把 AI 放進軟件交付流程。

Cloudflare 在今年 4 月 20 日發布博客披露，公司已在內部 CI/CD 流程中部署一套 AI 代碼審查系統。工程師提交 merge request 后，系統會自動啟動七個專門化 AI reviewer，對代碼進行初步審查，并根據風險等級決定批準、評論或阻止合并。

Cloudflare 稱，該系統已內部運行約一個月，覆蓋 5169 個代碼倉庫，完成 131246 次審查，涉及 48095 個 merge request。平均每個 MR 被審查 2.7 次，審查完成時間中位數為 3 分 39 秒。平均每次審查成本為 1.19 美元，P99 成本為 4.45 美元。

Cloudflare 在博客里提到，有效的 AI 審查不僅要告訴模型“看什么”，更要明確告訴它“不要看什么”。例如，安全 reviewer 只標記可利用或具體危險的問題，如注入漏洞、認證 / 授權繞過、硬編碼密鑰、不安全加密用法、缺失輸入驗證等；但不標記理論風險、無關舊代碼問題或泛泛的“建議使用某個庫”。

Cloudflare 為 AI 審查結果設置了明確決策規則：如果沒有問題或只有輕微建議，系統會批準；如果存在警告（Warning）但沒有生產風險，可以帶評論批準；如果多個警告交織形成風險模式，系統會撤銷機器人批準；如果出現嚴重（Critical）問題或生產安全風險，系統會 提出修改請求（Request changes），從而阻止合并。

但是，Cloudflare 也保留了人工“break glass”通道。人類 reviewer 可以通過評論 break glass 強制批準，用于緊急 hotfix 或避免被模型服務故障卡住發布。系統會在 telemetry 中記錄這類覆蓋行為。

Cloudflare 明確表示，這套 AI code review 系統還不能替代人類 reviewer。AI 在架構判斷、跨系統影響、復雜并發問題和大型重構方面仍有明顯限制。

例如，AI 能看到 diff 和周邊代碼，但不一定理解系統為什么這樣設計；它可以發現 API 合約變化，卻無法確認所有下游消費者是否已更新；它能看到缺少鎖，但未必能推斷完整死鎖路徑。

因此，Cloudflare 對 AI 代碼審查的定位不是取代人類，而是自動化第一輪、重復性、跨領域的初篩：讓 AI 先發現明顯 bug、安全風險、性能問題、文檔遺漏和內部規范沖突，再由人類處理更復雜的架構判斷和責任決策。

不過，值得注意的是，Anthropic 認為，隨著人類代碼和 AI 代碼質量趨近，人類可能會逐漸停止親手寫代碼，轉向主要審查 AI 寫出的代碼。但如果人類無法像 Claude 生成代碼那樣快速審查代碼，人類 review 就會成為 AI 研發的新瓶頸。

另外，為控制成本，Cloudflare 將 MR 分為 trivial、lite 和 full 三檔。trivial 適用于 10 行以內、文件數不超過 20 個的小改動；lite 適用于 100 行以內、文件數不超過 20 個的改動；full 則適用于超過 100 行、超過 50 個文件，或涉及安全敏感路徑的改動。任何觸及 auth/、crypto/ 或安全相關文件的改動，都會觸發 full review。

模型選擇也按任務復雜度分層：Claude Opus 4.7 和 GPT-5.4 主要用于最復雜的 coordinator；Claude Sonnet 4.6 和 GPT-5.3 Codex 用于代碼質量、安全、性能等重型 reviewer；Kimi K2.5 用于文檔、發布、AGENTS.md 等偏文本和輕量任務。

一個月內，這套系統處理了約 1200 億 token，其中大部分是 cache reads。Cloudflare 稱，系統緩存命中率達到 85.7%，相比按完整輸入 token 計價，節省了估計五位數美元成本。

從 Cloudflare 的實踐可以看出，對于 AI 編程工具，具備更可靠、生產級標準的工程能力，會成為下一階段的重要競爭力。

https://www.businessinsider.com/anthropic-improve-claude-code-snorkel-data-training-contractors-2026-6

https://github.com/anthropics/claude-code/issues/42634

https://www.businessinsider.com/zig-programming-language-ai-rules-2026-5?utm_source=chatgpt.com

https://blog.cloudflare.com/ai-code-review/?utm_source=chatgpt.com

https://docs.kernel.org/process/coding-assistants.html?utm_source=chatgpt.com

https://www.anthropic.com/institute/recursive-self-improvement

聲明：本文為 InfoQ 原創，不代表平臺觀點，未經許可禁止轉載。

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題。如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6 月 26-27 日，AICon 全球人工智能開發與應用大會·上海站國內頭部公司的 Agent 實踐，一次說透。