做技術內容項目久了手里自然會積累不少博主資料。最初這些資料都放在表格里博主名稱、粉絲數、CSDN 主頁、知乎、掘金、公眾號再加幾列合作記錄。表格自己看沒問題一旦要給別人看事情就麻煩了。品牌方經常會問“有沒有長期寫 Java 的博主”“這位作者除了 CSDN還在哪些平臺更新”“公眾號矩陣能不能單獨看”每次收到問題我都要打開文件、篩選、復制鏈接再重新整理一份。名單一多同一個博主可能在幾個項目表里重復出現粉絲數的寫法也五花八門。所以我做了一個小改造把部分公開的技術博主資料放進網站做成可以搜索、排序和直接訪問主頁的頁面。它現在是 Dream 工作室合作博主矩陣 的一部分。這件事看著像“把 Excel 搬到網頁”真正動手后卻涉及數據清洗、React 交互、頁面路由和 SEO。更有意思的是技術實現和內容運營在這里剛好接上了。為什么不直接發一張名單截圖名單截圖是最快的做法。我以前也這么發過但很快就發現幾個問題。第一截圖里的鏈接點不了。看到感興趣的博主后品牌方還得手動搜索名字重名時不一定找得準。第二名單會變。粉絲數增加、主頁地址調整、新博主加入都意味著重新截圖。舊圖片已經散落在聊天記錄里很難統一更新。還有一個問題與搜索有關。圖片里的名字和平臺信息搜索引擎未必能穩定識別。即使識別到了也不知道每個名字對應哪個鏈接。網頁中的文本、標題和超鏈接更容易被理解也更方便后續維護。我最后保留了表格作為內部工作文件網站只展示適合公開的部分。兩者用途不一樣表格負責項目執行網頁負責瀏覽、檢索和建立基本認知。先把博主資料變成結構化數據頁面第一版沒有接數據庫而是把資料整理成 TypeScript 數據。對于更新頻率不高的展示型網站這種方案夠直接也減少了后臺和接口的維護。每位博主的結構大致如下exporttypeCreator{name:string;followers:string;csdn?:string;juejin?:string;zhihu?:string;wechat?:string;xiaohongshu?:string;};除了名稱和粉絲數其他字段都是可選的。原因很簡單并不是每位作者都運營全部平臺。有的人主要寫 CSDN 和掘金有的人把精力放在公眾號還有作者會同步知乎或小紅書。數據結構必須允許這些差異存在。一條實際數據是這樣的{name:一只牛博,followers:2.8W,csdn:https://blog.csdn.net/Mrxiao_bo,juejin:https://juejin.cn/user/1722263248317024,zhihu:https://www.zhihu.com/people/zhong-xian-sen-51-54/posts,wechat:https://mp.weixin.qq.com/s/ZFB23O8Bll-N60l8p87S_g}這里沒有存作者的私人聯系方式。網頁只放公開主頁或公開文章鏈接合作溝通仍通過工作室統一進行。這樣既能讓品牌方查看作者內容也不會把內部資料直接暴露在網上。粉絲數排序比想象中麻煩我希望主理人 Dream 固定顯示在第一位其余博主按粉絲數從高到低排列。問題是原始數據不是統一的數字20W、2.8w、8000、5047都存在中英文大小寫也不完全一致。如果直接按字符串排序8000可能會排在20W前面因為程序比較的是字符不是實際人數。于是我寫了一個很小的轉換函數functionfollowerValue(value:string){constnumberNumber.parseFloat(value.replace(/[^\d.]/g,))||0;return/w/i.test(value)?number*10000:number;}這段代碼先去掉數字和小數點以外的字符再判斷是否包含W。2.8W會轉成280008000則是8000之后才能正常排序。主理人固定在首位的邏輯單獨處理const[dream,...others]creators;constrankedCreators[dream,...others.sort((a,b)followerValue(b.followers)-followerValue(a.followers)),];這不是多高級的算法但它解決了真實數據里的臟格式。很多內容項目的技術工作都類似難點不在算法本身而在輸入數據從來沒有想象中整齊。當前轉換方式也有邊界。如果以后出現“1.2 萬”“約 3k”或區間數據就需要繼續補規則。更穩妥的長期方案是同時保存展示文本和標準數值例如{followersLabel:2.8W,followersCount:28000}頁面顯示followersLabel排序使用followersCount。現在的數據量還能人工檢查所以暫時沒有為了規范而做一次大遷移。搜索功能先做最小版本品牌方查看名單時最常見的動作不是復雜篩選而是輸入一個名字確認作者是否在列表中。因此第一版搜索只支持按博主名稱匹配。const [query, setQuery] useState(); const visible useMemo( () creators.filter(item item.name .toLowerCase() .includes(query.trim().toLowerCase()) ), [creators, query] );輸入變化后頁面在已有數組中進行過濾。trim()用來處理前后空格轉成小寫則方便匹配英文名稱。技術博主數量在當前規模下這種前端過濾已經足夠快沒有必要為了一個輸入框單獨搭搜索服務。渲染平臺鏈接時我沒有給每位博主寫一套判斷而是先定義平臺字段與名稱的對應關系constplatforms[[csdn,CSDN],[juejin,掘金],[zhihu,知乎],[wechat,公眾號],[xiaohongshu,小紅書],];組件遍歷這個數組字段存在就生成鏈接不存在就跳過。以后增加 51CTO 或華為云只要擴展數據類型和平臺映射不用重寫整行 UI。這里我刻意沒有一開始就做十幾個篩選項。方向標簽、平臺組合、粉絲區間都可以繼續加但篩選條件越多維護數據的成本越高。先把名稱搜索和公開主頁做好比堆一排暫時用不到的下拉框實際。為什么公眾號矩陣要單獨放在前面技術社區博主和公眾號作者有一部分重合但用戶查看它們時關注點不同。選擇 CSDN 博主時品牌方常會看技術方向、歷史教程和搜索表現。選擇公眾號時更關心賬號定位、訂閱讀者以及是否長期寫 AI 或 IT 技術。兩類數據混在一個超長列表里公眾號很容易被埋在后面。所以我把公眾號矩陣拆成獨立區域放在技術博主名單之前。公眾號數據也使用單獨的類型exporttypeWechatCreator{name:string;followers:string;wechat:string;category:AI/人工智能|IT技術;};目前頁面精選展示部分公眾號作者整個合作矩陣是 100。技術內容平臺的合作博主矩陣是 500網頁同樣只展示其中一部分。這個說明必須寫清楚否則訪問者容易把“當前展示數量”和“全部資源數量”混為一談。粉絲數據也不是永久不變的。我在頁面底部加了提示說明數據來自整理時的公開信息后續可能隨平臺變化。這句話不夠漂亮但比把歷史數字當成實時數據更誠實。案例不能只剩一句“我們做過”博主名單解決的是“可以找誰”案例頁面要回答“具體做過什么”。早期的網站文案只有項目名稱和一兩行結果用戶看完仍然無法判斷內容質量。后來我把重點項目做成獨立路由例如飛算 JavaAI、華為昇騰及鯤鵬、ToDesk 長期內容項目并補上公開文章鏈接。案例數據同樣結構化保存{slug:huawei-kunpeng-ascend,client:華為昇騰及鯤鵬,tag:國產算力生態,result:150 位,resultLabel:萬粉博主參與,metrics:[150 位萬粉博主統一組織,300 篇技術文章規模化交付,覆蓋 16 個核心技術專題]}slug用來生成固定網址項目結果與公開內容在詳情頁呈現。這樣做有兩個好處品牌方可以直接把某個案例鏈接發給同事搜索引擎也能把每個項目當成獨立頁面理解而不是只看到首頁上一張信息卡片。我越來越不喜歡“服務過眾多知名品牌”這種寫法。它聽起來很滿信息卻很少。把參與規模、文章數量和公開鏈接放出來讀者能自己判斷這比再加幾個形容詞有用。SEO 沒有神秘開關先把頁面關系講清楚網站上線后我補了 Metadata、站點地圖、robots.txt和 JSON-LD。它們都不復雜作用也各不相同。Metadata 告訴搜索結果頁面該顯示什么標題和描述。例如博主名單頁的配置是export const metadata { title: 合作博主名單, description: Dream內容推廣工作室合作技術博主名單覆蓋 CSDN、掘金、知乎、微信公眾號等平臺。, alternates: { canonical: /creators }, };站點地圖負責列出首頁、服務頁和案例頁robots.txt再把站點地圖地址告訴搜索引擎。JSON-LD 則用結構化方式說明網站名稱、業務類型和服務范圍。這些配置只能幫助搜索引擎理解頁面不能替代內容。真正決定頁面有沒有價值的還是里面是否提供了明確的信息。博主名單有公開主頁案例頁有項目結果和文章鏈接服務頁說明具體執行方式。關鍵詞自然出現在這些內容中不需要把“CSDN KOL 投放”機械地重復十幾遍。內鏈也很重要。首頁可以進入服務、案例和博主矩陣案例頁能返回其他項目名單頁則連接到各平臺公開主頁。頁面不再是一座孤島訪問者和搜索引擎都能順著鏈接繼續瀏覽。為什么我暫時沒有接數據庫和后臺從開發角度看給博主資料做一個后臺很自然登錄、增刪改查、批量導入再配一套數據庫。問題是系統復雜度會立刻上升。現在網站展示的是精選公開資料更新由我統一整理。使用 TypeScript 文件的優點是改動可審查、可以跟隨 Git 版本記錄部署后也沒有數據庫連接和后臺安全問題。缺點同樣明顯批量更新不如表格方便非開發人員也不適合直接修改代碼。什么時候值得接數據庫我給自己定了幾個判斷條件需要多人維護、更新頻率明顯增加、網頁要展示全部 500 博主或者需要按技術方向和合作狀態做組合檢索。到了那一步表格可以作為導入源網站通過后臺管理標準化數據。目前還沒到那個階段。過早做后臺最后可能花很多時間維護一套沒人使用的系統。技術頁面本身也是內容做完這個頁面后我對“內容”有了一個更具體的理解。內容不一定都是長文章。一份能搜索的博主目錄、一頁帶公開鏈接的項目案例、一個解釋服務流程的頁面本身也是內容而且比泛泛的品牌介紹更耐看。這與技術產品推廣的邏輯很接近。開發者搜索問題時希望盡快看到可驗證的信息代碼、過程、數據或真實鏈接。品牌網站也一樣。把資料組織清楚比首頁堆滿口號更容易建立信任。Dream 內容推廣工作室 現在主要提供技術內容策劃、CSDN KOL 投放、公眾號博主推廣和多平臺內容分發。網站沒有把所有內容壓在首頁而是把服務、創作者和案例拆開。對訪客來說更好找對搜索收錄也更友好。這次改造留下的幾個實際結論第一先定義數據再設計頁面。原始名單沒有統一字段時界面畫得再漂亮也會被各種缺失值拖住。第二展示文本和計算數據最好分開保存。2.8W適合人看28000適合排序。項目早期可以做轉換數據繼續增長后應當從源頭標準化。第三公開頁面只放公開資料。主頁和文章鏈接足夠用于初步篩選私人聯系方式沒有必要進入前端數據。最后是一個偏內容的判斷少寫無法驗證的形容詞多放能點開的鏈接。一個網站是否可信往往不取決于它說自己有多專業而在于用戶能不能順著頁面找到真實的人和真實的內容。這套頁面還會繼續更新。下一步可能加入技術方向標簽和更細的平臺篩選但我不會急著把它做成一個龐大的系統。先讓現有資料更容易查、更容易讀已經解決了最常見的問題。