做技术内容项目久了手里自然会积累不少博主资料。最初这些资料都放在表格里博主名称、粉丝数、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适合排序。项目早期可以做转换数据继续增长后应当从源头标准化。第三公开页面只放公开资料。主页和文章链接足够用于初步筛选私人联系方式没有必要进入前端数据。最后是一个偏内容的判断少写无法验证的形容词多放能点开的链接。一个网站是否可信往往不取决于它说自己有多专业而在于用户能不能顺着页面找到真实的人和真实的内容。这套页面还会继续更新。下一步可能加入技术方向标签和更细的平台筛选但我不会急着把它做成一个庞大的系统。先让现有资料更容易查、更容易读已经解决了最常见的问题。
