企业官网建设流程全解析

做技术内容项目久了，手里自然会积累不少博主资料。最初，这些资料都放在表格里：博主名称、粉丝数、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){constnumber=Number.parseFloat(value.replace(/[^\d.]/g,""))||0;return/w/i.test(value)?number*10000:number;}

这段代码先去掉数字和小数点以外的字符，再判断是否包含W。2.8W+会转成28000，8000+则是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适合排序。项目早期可以做转换，数据继续增长后应当从源头标准化。

第三，公开页面只放公开资料。主页和文章链接足够用于初步筛选，私人联系方式没有必要进入前端数据。

最后是一个偏内容的判断：少写无法验证的形容词，多放能点开的链接。一个网站是否可信，往往不取决于它说自己有多专业，而在于用户能不能顺着页面找到真实的人和真实的内容。

这套页面还会继续更新。下一步可能加入技术方向标签和更细的平台筛选，但我不会急着把它做成一个庞大的系统。先让现有资料更容易查、更容易读，已经解决了最常见的问题。