新智元報(bào)道

編輯：好困

【新智元導(dǎo)讀】70萬行祖?zhèn)鞔a，人走了一撥又一撥，爛尾工程停擺三年沒人敢碰。直到首席開發(fā)者給Claude Code寫了份「說明書」，項(xiàng)目兩周收工。

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

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

寫它的開發(fā)者畢業(yè)離開了實(shí)驗(yàn)室，留下一個(gè)半成品。放在以前，這種爛尾工程只有一個(gè)結(jié)局，永遠(yuǎn)躺在倉庫里，沒人敢碰，沒人想碰。

但這次不一樣。

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

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

Skyline是MacCoss實(shí)驗(yàn)室的開源軟件，用來幫研究人員檢測和量化血漿、組織中的蛋白質(zhì)，對生物標(biāo)志物發(fā)現(xiàn)、疾病研究和藥物開發(fā)至關(guān)重要。

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

這可不是什么普通的實(shí)驗(yàn)室。

Anthropic聯(lián)合創(chuàng)始人Dario Amodei曾經(jīng)是MacCoss Lab的成員，2012年還和Brendan合著過一篇Nature Biotechnology的論文。

那時(shí)候Skyline才開發(fā)四年，Dario還在斯坦福放射科。

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

Brendan是這個(gè)項(xiàng)目的首席開發(fā)者，也是唯一的「核心紐帶」。

近二十年來，本科生來了又走，研究生畢業(yè)了，博士后跳槽了，實(shí)習(xí)生暑假結(jié)束就再也不會回來。

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

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

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

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

靈光一閃，把AI當(dāng)實(shí)習(xí)生來「帶」

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

體驗(yàn)可以用四個(gè)字概括，非常痛苦。

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

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

等一下，這個(gè)痛點(diǎn)他太熟了。每次帶新人進(jìn)實(shí)驗(yàn)室，不就是這樣嗎？

新人不知道項(xiàng)目全貌，不知道代碼之間的關(guān)系，不知道那些只有老人才懂的潛規(guī)則。

區(qū)別只是，新人會慢慢學(xué)會，而Claude每次對話結(jié)束就全忘了。

所以他做了一個(gè)決定，像帶實(shí)習(xí)生一樣帶Claude Code。

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

項(xiàng)目地址：https://github.com/ProteoWizard/pwiz-ai

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

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

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

再加上MCP集成，讓Claude能讀取真實(shí)的測試數(shù)據(jù)、異常報(bào)告和用戶工單。

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

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

因?yàn)樗呀?jīng)知道代碼是干什么的了。交互的起點(diǎn)是理解，不再是空白。

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

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

這事要從三年前說起。

當(dāng)時(shí)負(fù)責(zé)維護(hù)Skyline每晚測試管理模塊的開發(fā)者離開了。這個(gè)模塊是用Java寫的，技術(shù)棧和Skyline主體的C#完全不同。

放在以前，這種半途而廢的爛尾工程只會被丟進(jìn)垃圾桶。學(xué)術(shù)實(shí)驗(yàn)室里，人員流動(dòng)是常態(tài)。任何進(jìn)行中的半成品，基本就等于永遠(yuǎn)的半成品。

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

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

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

更狠的在后面。

Skyline有2000多張教程截圖，以前全靠手動(dòng)維護(hù)?，F(xiàn)在全部實(shí)現(xiàn)自動(dòng)化，近乎100%可復(fù)現(xiàn)。

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

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

實(shí)驗(yàn)室里原本對AI編程工具最不感冒的開發(fā)者，現(xiàn)在用Claude Code構(gòu)建并發(fā)布了一個(gè)全新的數(shù)據(jù)可視化面板。

這個(gè)變化，不只發(fā)生在MacCoss實(shí)驗(yàn)室。

同一周，OpenAI亮出了另一個(gè)答案

就在Anthropic發(fā)布這篇博客的前一天，OpenAI也放出了一個(gè)開源項(xiàng)目——Symphony。

目前，它已經(jīng)在GitHub上已經(jīng)拿下了超過1.8萬顆Star。

項(xiàng)目地址：https://github.com/openai/symphony

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

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

每一個(gè)Open狀態(tài)的Issue自動(dòng)分配一個(gè)Agent，Agent在獨(dú)立工作區(qū)里持續(xù)運(yùn)行，崩了自動(dòng)重啟，新任務(wù)來了自動(dòng)接手。

人類只需要做一件事，Review結(jié)果。

根據(jù)OpenAI的統(tǒng)計(jì)，部分團(tuán)隊(duì)在上線Symphony的頭三周，成功merge的PR數(shù)量暴漲了500%。

但產(chǎn)出量暴漲只是表面，真正的變化是團(tuán)隊(duì)對「工作」的認(rèn)知被徹底顛覆了。

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

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

甚至產(chǎn)品經(jīng)理和設(shè)計(jì)師也能在Symphony里提Feature Request，不需要Git Clone倉庫，不需要開Codex會話。

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

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

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

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

當(dāng)然，OpenAI自己也承認(rèn)，不是所有任務(wù)都吃這一套。

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

「帶徒弟」和「開工廠」

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

Anthropic的答案是「深度」。一個(gè)資深開發(fā)者花時(shí)間構(gòu)建上下文層，像帶實(shí)習(xí)生一樣教會AI理解一個(gè)特定的代碼庫。CLAUDE.md、skills、MCP，每一層都是在加深A(yù)I對項(xiàng)目的理解。核心信念是，上下文的質(zhì)量決定一切。

OpenAI的答案是「規(guī)?！?。搞一個(gè)編排層，每個(gè)任務(wù)自動(dòng)派Agent，Agent永不停歇，崩了就重啟。工程師從「寫代碼的人」變成「管看板的人」。核心信念是，編排的效率決定一切。

一個(gè)是師傅帶徒弟，一個(gè)是開自動(dòng)化工廠。

有意思的是，兩條路線在一個(gè)關(guān)鍵點(diǎn)上殊途同歸。

Brendan寫了CLAUDE.md和skills來固化項(xiàng)目知識，OpenAI寫了WORKFLOW.md來固化開發(fā)流程。

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

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

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

面對一個(gè)70萬行的老代碼庫，你需要Brendan那種深度上下文工程。面對一個(gè)團(tuán)隊(duì)級別的新項(xiàng)目，Symphony那種大規(guī)模并行調(diào)度更合適。

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

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

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

對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/