和Anthropic CEO一起發過Nature，他用Claude Code復活三年爛尾代碼

新智元報道

編輯：好困

【新智元導讀】70萬行祖傳代碼，人走了一撥又一撥，爛尾工程停擺三年沒人敢碰。直到首席開發者給Claude Code寫了份「說明書」，項目兩周收工。

在華盛頓大學基因組科學系，干了快二十年的首席開發者Brendan MacLean，正盯著屏幕上那段代碼，眉頭越鎖越緊。

這段代碼屬于Skyline的一個功能模塊，文件視圖面板，擱置了整整一年。

寫它的開發者畢業離開了實驗室，留下一個半成品。放在以前，這種爛尾工程只有一個結局，永遠躺在倉庫里，沒人敢碰，沒人想碰。

但這次不一樣。

兩周后，這個面板開發完成，所有最終代碼提交里都多了一個共同作者的名字，Claude。

17年，70萬行，人走了代碼還在

Skyline是MacCoss實驗室的開源軟件，用來幫研究人員檢測和量化血漿、組織中的蛋白質，對生物標志物發現、疾病研究和藥物開發至關重要。

70萬行C#代碼，每晚跑20萬個自動化測試，從2008年開始一直在迭代。

這可不是什么普通的實驗室。

Anthropic聯合創始人Dario Amodei曾經是MacCoss Lab的成員，2012年還和Brendan合著過一篇Nature Biotechnology的論文。

那時候Skyline才開發四年，Dario還在斯坦福放射科。

論文地址：https://www.nature.com/articles/nbt.2377

Brendan是這個項目的首席開發者，也是唯一的「核心紐帶」。

近二十年來，本科生來了又走，研究生畢業了，博士后跳槽了，實習生暑假結束就再也不會回來。

每一撥人走的時候，代碼留下了，理解代碼的人沒了。到2024年，代碼庫里有些區域，字面意義上沒人敢碰。

Brendan花了幾十年時間做同一件事，帶新人。

手把手教他們熟悉這套龐大的代碼庫，搞懂組件之間的關系，搞懂17年沉淀下來的規范。這套方法論他爛熟于心。

但他從來沒想過，有一天會把同樣的方法論用在一個AI身上。

靈光一閃，把AI當實習生來「帶」

Brendan一開始試的是瀏覽器里的Claude.ai。

體驗可以用四個字概括，非常痛苦。

他描述一個問題，得到回復，然后把整個C#文件復制回項目里。只能處理那種不需要參考項目其他代碼就能描述清楚的孤立問題，稍微涉及漸進式修改，就完全不行了。

每次對話都像從零開始。Claude不知道Skyline是什么，不知道組件之間怎么關聯，不知道17年積累下來的規范。

等一下，這個痛點他太熟了。每次帶新人進實驗室，不就是這樣嗎？

新人不知道項目全貌，不知道代碼之間的關系，不知道那些只有老人才懂的潛規則。

區別只是，新人會慢慢學會，而Claude每次對話結束就全忘了。

所以他做了一個決定，像帶實習生一樣帶Claude Code。

具體來說，他建了一個獨立的代碼倉庫叫pwiz-ai，專門存放給AI看的上下文，和主代碼庫完全分開。根目錄下的CLAUDE.md是「地形圖」，告訴Claude項目的結構、編譯方式、測試流程。

項目地址：https://github.com/ProteoWizard/pwiz-ai

但地形圖只解決「知道在哪」的問題，不解決「知道怎么干活」的問題。

真正的專業知識存放在skills里。比如他寫了一個debugging skill，專門把Claude從「盲猜試錯」模式里拽出來。

這個skill的描述里寫得非常硬核，「在排查bug、失敗或意外行為時始終加載」，逼Claude在動手之前先做根因分析。

再加上MCP集成，讓Claude能讀取真實的測試數據、異常報告和用戶工單。

三層上下文疊滿，效果立竿見影。

建好上下文之后，教Claude調試代碼庫的溝通成本斷崖式下降。

因為它已經知道代碼是干什么的了。交互的起點是理解，不再是空白。

沒人敢碰的代碼，兩周收工

上下文建好之后，Brendan開始用它清理積壓多年的技術債。

這事要從三年前說起。

當時負責維護Skyline每晚測試管理模塊的開發者離開了。這個模塊是用Java寫的，技術棧和Skyline主體的C#完全不同。

放在以前，這種半途而廢的爛尾工程只會被丟進垃圾桶。學術實驗室里，人員流動是常態。任何進行中的半成品，基本就等于永遠的半成品。

Brendan的處理方式也不例外，人走之后，他就不再為這個模塊添加任何新功能。一停就是三年。

直到最近，他讓一位LabKey開發者用Claude Code寫了一份配置文檔。

然后，自己花了不到一天，就把惦記了好幾年的功能給加上了，順手還用CSS更新了頁面布局。

更狠的在后面。

Skyline有2000多張教程截圖，以前全靠手動維護�，F在全部實現自動化，近乎100%可復現。

Claude還寫了一個C# MCP服務器，讓自己能「看到」截圖之間的差異。

每天早上Brendan坐下來開始工作之前，Claude自動生成的日報已經躺在收件箱里了，匯總夜間測試失敗、異常和未解決的工單。

實驗室里原本對AI編程工具最不感冒的開發者，現在用Claude Code構建并發布了一個全新的數據可視化面板。

這個變化，不只發生在MacCoss實驗室。

同一周，OpenAI亮出了另一個答案

就在Anthropic發布這篇博客的前一天，OpenAI也放出了一個開源項目——Symphony。

目前，它已經在GitHub上已經拿下了超過1.8萬顆Star。

項目地址：https://github.com/openai/symphony

起因是，工程師有時需要同時開3到5個Codex會話，但上下文的切換會把人直接「逼瘋」。

Symphony的思路簡單粗暴，把Linear項目看板變成AI編程的控制中心。

每一個Open狀態的Issue自動分配一個Agent，Agent在獨立工作區里持續運行，崩了自動重啟，新任務來了自動接手。

人類只需要做一件事，Review結果。

根據OpenAI的統計，部分團隊在上線Symphony的頭三周，成功merge的PR數量暴漲了500%。

但產出量暴漲只是表面，真正的變化是團隊對「工作」的認知被徹底顛覆了。

當工程師不用再盯著Codex會話的時候，每一次代碼變更的「感知成本」直線下降。

想試一個重構方案？提個Ticket就行，跑出來不滿意直接扔掉，成本幾乎為零。

甚至產品經理和設計師也能在Symphony里提Feature Request，不需要Git Clone倉庫，不需要開Codex會話。

用人話描述需求，過一會就能收到一份帶演示視頻的Review包。

更有意思的是Symphony的誕生方式。

它的核心其實就是一份SPEC.md，一個用Markdown寫的規范文檔。OpenAI讓Codex用TypeScript、Go、Rust、Java、Python、Elixir六種語言全都實現了一遍，借此打磨規范里的模糊地帶。

最終他們甚至用Symphony編排Codex，重寫了Symphony本身。

當然，OpenAI自己也承認，不是所有任務都吃這一套。

需求極其模糊、嚴重依賴直覺和專業判斷的活兒，還得工程師打開交互式Codex會話親自下場。

「帶徒弟」和「開工廠」

雖然路線不同，但Anthropic和OpenAI在回答同一個問題，怎么讓AI在真實的工程流程里干活。

Anthropic的答案是「深度」。一個資深開發者花時間構建上下文層，像帶實習生一樣教會AI理解一個特定的代碼庫。CLAUDE.md、skills、MCP，每一層都是在加深AI對項目的理解。核心信念是，上下文的質量決定一切。

OpenAI的答案是「規�！埂８阋粋�編排層，每個任務自動派Agent，Agent永不停歇，崩了就重啟。工程師從「寫代碼的人」變成「管看板的人」。核心信念是，編排的效率決定一切。

一個是師傅帶徒弟，一個是開自動化工廠。

有意思的是，兩條路線在一個關鍵點上殊途同歸。

Brendan寫了CLAUDE.md和skills來固化項目知識，OpenAI寫了WORKFLOW.md來固化開發流程。

兩邊都發現，以前靠口口相傳和肌肉記憶的東西，現在必須白紙黑字寫成文檔，AI才能接得住。

「上下文工程」也好，「Harness工程」也好，說到底是同一件事，把人類的隱性知識變成機器可讀的顯性資產。

兩條路線都管用，適用場景也不一樣。

面對一個70萬行的老代碼庫，你需要Brendan那種深度上下文工程。面對一個團隊級別的新項目，Symphony那種大規模并行調度更合適。

但有一件事，兩家公司是完全一致的。

AI編程的瓶頸，已經不是模型寫不寫得出好代碼。瓶頸是人類有沒有學會「管理」AI。

正如Brendan所言，「你不會把70萬行代碼庫甩給一個新員工，然后指望他第一天就出活�！�

對AI也一樣。

參考資料：

https://claude.com/blog/onboarding-claude-code-like-a-new-developer-lessons-from-17-years-of-development

https://openai.com/index/open-source-codex-orchestration-symphony/