Google用1個(gè)評(píng)分拯救了網(wǎng)頁(yè)性能，代碼倉(cāng)庫(kù)卻還在裸奔

2017年之前，網(wǎng)頁(yè)性能是個(gè)玄學(xué)問(wèn)題。用戶(hù)說(shuō)"卡"，工程師說(shuō)"不卡"，產(chǎn)品經(jīng)理站在中間干瞪眼——直到Google把Lighthouse塞進(jìn)Chrome，輸入U(xiǎn)RL就能蹦出一個(gè)0-100的分?jǐn)?shù)。代碼倉(cāng)庫(kù)今天面臨的困境，和當(dāng)年一模一樣：你能感覺(jué)某個(gè)項(xiàng)目"維護(hù)得不錯(cuò)"，但沒(méi)法量化，沒(méi)法橫向?qū)Ρ龋鼪](méi)法跟老板解釋為什么需要撥預(yù)算。

AI寫(xiě)代碼的速度，已經(jīng)超過(guò)了人類(lèi)收拾爛攤子的速度。Claude Code、Cursor、Windsurf這些工具讓開(kāi)發(fā)者幾小時(shí)就能交付過(guò)去幾周的活，但它們的優(yōu)化目標(biāo)只有一個(gè)：跑起來(lái)。CI配置？測(cè)試覆蓋？依賴(lài)安全？那是"以后再說(shuō)"的事。問(wèn)題是，這個(gè)"以后"往往永遠(yuǎn)不會(huì)來(lái)。

開(kāi)源依賴(lài)鏈正在批量制造技術(shù)債

現(xiàn)在的項(xiàng)目啟動(dòng)方式變了。不再是白手起家，而是克隆一個(gè)starter template，npm install，改改配置就上線(xiàn)。這個(gè)選擇的代價(jià)被嚴(yán)重低估：你繼承的不只是功能，還有它的基礎(chǔ)設(shè)施基因。模板沒(méi)寫(xiě)測(cè)試？你的項(xiàng)目也不會(huì)有。模板沒(méi)配分支保護(hù)？你也得自己加。

GitHub上最熱門(mén)的React模板之一，去年被曝出直接引用了三個(gè)有CVE（通用漏洞披露）記錄的依賴(lài)，而它的下載量每周還在漲。這不是個(gè)案。依賴(lài)層級(jí)越深，"能跑就行"的慣性就越難打破——因?yàn)闆](méi)人看得見(jiàn)問(wèn)題在哪。

RepoFortify的創(chuàng)始團(tuán)隊(duì)算過(guò)一筆賬：一個(gè)中等規(guī)模的Node項(xiàng)目，平均繼承自上游的依賴(lài)超過(guò)1200個(gè)，其中約15%的倉(cāng)庫(kù)本身處于"低維護(hù)"狀態(tài)——最近半年沒(méi)有更新、沒(méi)有回應(yīng)issue、沒(méi)有合并PR。這些數(shù)字分散在各種角落，直到有人把它們聚合成一個(gè)可見(jiàn)的分?jǐn)?shù)。

9個(gè)信號(hào)的"體檢報(bào)告"

RepoFortify的做法是直接對(duì)標(biāo)Lighthouse：粘貼GitHub公開(kāi)倉(cāng)庫(kù)鏈接，返回0-100分，拆解成9個(gè)維度。CI/CD配置、測(cè)試覆蓋率、依賴(lài)健康度、分支保護(hù)規(guī)則、類(lèi)型安全、死代碼檢測(cè)、安全漏洞掃描——這些原本需要逐個(gè)檢查的配置，被壓縮成一張可對(duì)比的卡片。

他們的MCP（模型上下文協(xié)議）包更直接：npx @repofortify/mcp裝完，Claude Code和Cursor能在對(duì)話(huà)里直接調(diào)用掃描。AI生成的代碼剛落地，就能被另一個(gè)AI審計(jì)——這個(gè)閉環(huán)聽(tīng)起來(lái)有點(diǎn)荒誕，但確實(shí)解決了"人懶得查"的問(wèn)題。

公開(kāi)倉(cāng)庫(kù)免費(fèi)，這是刻意的設(shè)計(jì)。創(chuàng)始人之一在HN（黑客新聞）上解釋?zhuān)骸肝覀兿胂茸寴?biāo)準(zhǔn)本身流行起來(lái)，再考慮變現(xiàn)。」這種策略在開(kāi)發(fā)者工具領(lǐng)域不算新鮮，但前提是標(biāo)準(zhǔn)真的能被廣泛接受。Lighthouse當(dāng)年也是免費(fèi)的Chrome內(nèi)置功能，直到成為行業(yè)默認(rèn)語(yǔ)言。

從"能跑"到"能維護(hù)"的鴻溝

一個(gè)被反復(fù)引用的案例是某獨(dú)角獸公司的內(nèi)部系統(tǒng)：核心模塊由AI生成，三個(gè)月內(nèi)從2000行膨脹到8000行，沒(méi)有單元測(cè)試，沒(méi)有類(lèi)型定義，原開(kāi)發(fā)者離職后，接手團(tuán)隊(duì)花了六周才理清調(diào)用關(guān)系。這個(gè)項(xiàng)目的業(yè)務(wù)價(jià)值很高，但技術(shù)債務(wù)的利息已經(jīng)開(kāi)始復(fù)利計(jì)算。

RepoFortify的掃描結(jié)果里，這類(lèi)項(xiàng)目通常卡在40-60分區(qū)間：基礎(chǔ)功能完整，但運(yùn)營(yíng)就緒度（operational readiness）不及格。諷刺的是，很多團(tuán)隊(duì)并非不想改進(jìn)，而是不知道從何下手——9個(gè)維度的拆解至少給出了優(yōu)先級(jí)。

測(cè)試覆蓋率低但CI已配置？先補(bǔ)測(cè)試。依賴(lài)有漏洞但分支保護(hù)完善？先修安全。這種排序?qū)Y源有限的小團(tuán)隊(duì)尤其重要。

不過(guò)工具本身也有邊界。RepoFortify目前只支持公開(kāi)倉(cāng)庫(kù)掃描，私有代碼需要自托管或企業(yè)版。更關(guān)鍵的是，分?jǐn)?shù)高不等于代碼好——就像Lighthouse 100分的網(wǎng)站也可能用戶(hù)體驗(yàn)稀爛，RepoFortify的100分項(xiàng)目也可能架構(gòu)設(shè)計(jì)糟糕。它解決的是"基礎(chǔ)衛(wèi)生"問(wèn)題，不是"建筑美學(xué)"問(wèn)題。

這個(gè)定位本身值得玩味。Google做Lighthouse時(shí)，網(wǎng)頁(yè)性能已經(jīng)有很多專(zhuān)業(yè)工具，但缺少一個(gè)"能讓老板看懂"的通用語(yǔ)言。代碼倉(cāng)庫(kù)今天處于同樣的節(jié)點(diǎn)：SonarQube、Snyk、Codecov各自深耕細(xì)分領(lǐng)域，但沒(méi)有一個(gè)跨維度的、零門(mén)檻的評(píng)分體系。

RepoFortify能不能成為這個(gè)標(biāo)準(zhǔn)，取決于兩個(gè)變量。一是AI編碼工具的集成深度——如果Cursor把它做成默認(rèn)功能，普及速度會(huì)指數(shù)級(jí)上升；二是開(kāi)源社區(qū)的采納意愿，畢竟評(píng)分體系的權(quán)威性來(lái)自共識(shí)，而不是算法。

一個(gè)早期用戶(hù)的反饋被放在產(chǎn)品首頁(yè)：「終于不用在代碼評(píng)審時(shí)扯皮'這算不算技術(shù)債'了，分?jǐn)?shù)說(shuō)話(huà)。」這種場(chǎng)景聽(tīng)起來(lái)很小，但恰恰是Lighthouse當(dāng)年破局的路徑——先讓對(duì)話(huà)成為可能，再讓改進(jìn)成為習(xí)慣。

如果明年這個(gè)時(shí)候，GitHub倉(cāng)庫(kù)的README里開(kāi)始流行貼RepoFortify分?jǐn)?shù)徽章，我們會(huì)知道這場(chǎng)實(shí)驗(yàn)成功了。但更有可能的是，某個(gè)大廠(chǎng)會(huì)推出自己的版本，或者這個(gè)需求被AI編碼工具原生消化。無(wú)論哪種結(jié)局，問(wèn)題本身已經(jīng)被擺上了臺(tái)面：當(dāng)代碼生產(chǎn)速度超過(guò)質(zhì)量感知能力時(shí)，我們需要一個(gè)新的感官器官——而分?jǐn)?shù)，是最古老的界面語(yǔ)言。

你的團(tuán)隊(duì)現(xiàn)在怎么判斷一個(gè)倉(cāng)庫(kù)"能不能接手"——是靠直覺(jué)，還是已經(jīng)有了一套內(nèi)部標(biāo)準(zhǔn)？