微软程序员刷完800道算法题，建了个让面试官沉默的网站

刷LeetCode的人分两种：一种收藏夹吃灰，一种真把题量变成了生产资料。后者最近搞了个东西，直接把个人笔记变成了1380个预渲染页面的静态站点。

从「刷题」到「建站」：一个.NET开发者的效率执念

这事的主角是个用C#（微软开发的面向对象编程语言）刷题的开发者。C#在算法竞赛圈属于冷门选项，大多数人选Python或Java——写起来快，语法糖多。但他盯准了一个场景：如果你要面微软、亚马逊或者任何.NET技术栈的公司，用C#刷题等于提前熟悉战场环境。

800多道题刷下来，他做了个观察：很多题解网站的代码直接甩给你，没有思路说明，读起来像考古。于是他的每个题解文件顶部都带一段注释，先讲核心思路，再上代码。比如两数之和那题，注释先点破「用字典存索引，找补数」这个关键洞察，时间空间复杂度也标清楚。

这种写法不是炫技，是降低认知负荷。读代码的人先知道「要干什么」，再看「怎么干的」，调试时脑子不打架。

技术选型：为什么选Next.js 14做静态生成

题解数据存在GitHub仓库里，每个.cs文件对应一道题。站点用Next.js 14（React框架的最新版本，支持服务端组件）的App Router架构，构建时一次性生成1380多个静态页面，部署在Vercel（前端部署平台）上。

这个方案有几个好处。第一，零服务器成本，流量大了也不慌。第二，访问速度极快，页面是提前编译好的HTML，不是实时查询数据库。第三，SEO友好——算法题解天然适合搜索引擎流量，「C# 两数之和」这种长尾词能精准命中。

代码高亮用的是Shiki（基于TextMate语法解析的代码着色工具），比Prism.js更轻量，主题也更贴近VS Code的观感。对C#开发者来说，这种熟悉感很重要，像回家看到家具摆在自己习惯的位置。

内容组织：40多个标签的检索逻辑

站点支持按主题筛选：动态规划、树、图、滑动窗口、双指针……一共40多个分类。也能按难度过滤，Easy/Medium/Hard三档。这种设计对应了刷题者的真实行为模式——不是随机乱刷，而是集中突破某类题型，或者按难度梯度推进。

有个细节：他没有做用户系统、没有评论区、没有点赞数。整个站点就是内容+检索，极简到近乎固执。这种克制反而让核心体验很纯粹：你来找题解，找到，看完，走。

对比国内某些算法平台，广告、课程推销、社交功能层层嵌套，这个站点的「减法」反而成了差异化。

同步运营：Java版本的GFG题解站

除了LeetCode的C#版本，他还在维护另一个站点，专门放GeeksforGeeks的每日一题，用Java实现，已经积累了530多道。两个站点并行运营，技术栈类似，内容来源不同，覆盖了两大刷题平台的核心用户群。

这种双线操作暴露了他的策略：不是做一个「大而全」的算法社区，而是做多个「小而准」的垂直工具站。每个站点的受众明确——C#刷题者、Java刷题者——SEO关键词也互不干扰。

模板功能是个隐藏设计。FAQ回复、代码片段复用，这些重复劳动被抽象成可快速调用的模块。对独立开发者来说，时间是最贵的成本，能省则省。

现在的问题是：当AI编程助手（比如GitHub Copilot、Cursor）能直接生成题解代码，这种人工整理的题解站还有多大价值？是变成「人类精选」的差异化内容，还是被大模型的即时生成能力逐步替代？