企业官网建设流程全解析

面试鸭从立项到正式上线，前后花了三个月。这三个月里，我几乎每天都在和题目、代码、反馈打交道，中间踩了不少坑，也把一些一开始没想清楚的问题慢慢理明白了。做这款在线面试刷题工具的初衷其实很朴素：每到招聘季，技术群里总能看到大量程序员在多个平台之间来回切换——在力扣刷算法、在牛客翻面经、在小程序里背八股、在博客翻源码解析，准备一次面试至少要开五个网站。信息太碎，效率太低。我就想做一个把面试准备真正串起来的工具，让准备面试的人只打开一个页面就够了。面试鸭就是带着这个目的上线的。

这篇文章不做什么产品宣讲，纯粹从产品思路、题库体系设计、技术实现和运营踩坑几个维度做个复盘。如果你也在做工具型产品，或者正在准备面试，这应该能给你一些参考。

1. 立项思考：程序员刷题这件事，到底差一个什么工具

1.1 刷题之痛：不是题不够，而是场景太碎

先聊几个实际场景。校招同学准备秋招，通常要做这几件事：算法题要去力扣刷，这是基本功；计算机网络、操作系统这些基础题要去牛客或者别人整理的PDF背；Java或前端框架的原理要去掘金、CSDN找文章；最近的大厂面试题要去小红书、公众号里搜；项目讲解思路又要单独准备。每样都是"还行"，但组合起来就是一团乱麻。

我见过有人把PDF题手动做成刷题软件，也见过有人专门买纸质题库逐页扫描。这些做法本身很聪明，但它恰好说明一个事实：市面上的工具没有解决好"系统化准备面试"这件事。PDF和刷题软件的差别在于交互，不在内容。你照样不知道该先刷哪些题、哪些是高频考点、自己的薄弱点到底在哪。

另一个痛点是"无重点刷题"。不少人打开力扣，从第1题开始往下一题一题做，做到第800题就坚持不下去了。这种刷法看起来很努力，实际上前100题里超过一半都不太可能在面试中出现。力扣的题是给算法训练用的，不是给面试准备的，两者有关联但不完全是一回事。

准备面试最需要的不是无限多的题目，而是一条清晰的路径：先掌握哪些知识点，每个知识点做哪些代表性题目，达到什么程度算过关，然后进入下一个阶段。而市面上的刷题工具，很少有把这件事讲明白的。

1.2 产品定位：从"刷题工具"升级为"面试陪练"

面试鸭这个产品名，取的是"面试压"的谐音，意思有两层：一是帮你压中面试题，二是帮你压过面试。名字听起来轻松一点，程序员之间聊天氛围也比较随意，太正经的名字反而没有传播感。

定位上，面试鸭不是另一个力扣，做得是"面试全流程"的陪练。力扣解决的核心问题是"你会不会写这段代码"，而面试鸭要解决的问题是"你能不能通过这场面试"。这两个目标的高度不一样。能不能通过面试，除了算法能力，还涉及基础知识的准确度、表达的逻辑性、面对追问时的临场反应。

我们的目标用户主要有三类。第一类是校招应届生，他们最大的困惑是怎么在有限时间内覆盖尽量多的考点；第二类是准备跳槽的社招程序员，他们需要的是按岗位方向定制的面试题，而不是泛泛的算法题；第三类是转码人群，他们大多自学了编程基础，但对整个知识体系没有完整概念，需要有一条清晰的学习和刷题路径。

从这三类人群出发，面试鸭在功能上做了三个取舍：一是明确按岗位方向分题库，后端、前端、算法岗各看各的内容；二是在题目之外加入"回答思路"和"考察点"模块，引导用户理解题目背后的真实意图；三是增加了模拟面试模式，尽可能还原面试现场的提问节奏。

2. 题库体系：把力扣刷题攻略变成真正可落地的路线

2.1 题库不是越大越好

内容产品冷启动最大的坑，就是想着"我先把题库做到一万题再上线"。事实证明，题库数量根本不是核心竞争力，用户要的是"质量"和"路径"，不是"数量"。

力扣现在已经有三千多道题，但大多数人真正认真做完的不会超过两百道，热门经典题其实就那几百道。很多人收藏了一堆"力扣刷题攻略""leetcode刷题指南"，但真正能按攻略执行下来的人少之又少，原因不是攻略写得不对，而是攻略和题库之间没有打通——你在攻略里看到"建议刷数组专题"，还得回到题库里去手动找对应的题单。

面试鸭的做法是直接砍掉低频知识，只保留高频考点。题库按知识点树组织，每个知识点下只收录最经典、面试中出现频率最高的题目。算法部分，我们把力扣里出现频率最高的 hot 100 和剑指 Offer 经典题做了重组，不是照搬原题，而是参考同样的考点，用同类型题目或者改编题来承载。这样既规避了直接搬运的版权问题，也让用户练的题目和面试场景更贴合。

除了算法题和岗位基础题，我们还保留了一些细分场景的题库方向，比如针对软考初级程序员的公共基础题，或者网络设备方向的数通刷题需求。这些需求量不大，但用户群非常精准。做这类细分子题库的初衷，是看到了专业领域刷题工具的参考价值，比如 hdlbits 这种专门做数字电路刷题的网站，用户量不大但评价极高。它验证了一件事：在一个足够垂直的领域里，把题库做到"够用、准确、有讲解"，比大而全的题库更有生命力。

2.2 从力扣刷题顺序中提炼的知识点树

面试准备最需要的是"顺序感"。刷题顺序不对，会极大打击信心。我见过不少人一上来就啃动态规划，被难题劝退之后放弃了整个准备计划。正确的路径绝对不应该是从题目编号第1题开始，而应该按照知识点本身的依赖关系来推进。

面试鸭在冷启动阶段就内置了一份标准刷题顺序，这个顺序参考了主流"力扣刷题顺序"攻略，也参考了各个大厂实际面试中出现知识点的频率：

• 第一梯队：数组、链表、栈、队列、哈希表。这五个知识点是面试中最基础也是最高频的，双指针、滑动窗口等技巧也都建立在这上面。
• 第二梯队：二叉树、堆、排序、二分查找。树结构是面试常客，大多数中等题都跟二叉树有关。
• 第三梯队：回溯、贪婪、动态规划、图。这些属于进阶内容，通常出现在二面或三面。

每个知识点下，我们会明确标注"必刷题单"和"扩展题单"。必刷题单控制在十道左右，都是这个知识点里最典型、面试最高频的题；扩展题单留给学有余力的人。用户完成了必刷题单，系统才会解锁下一个知识点的推荐。这样做的好处是，用户不需要自己去研究刷题攻略，产品已经把路线踏好了。

这套设计的核心思想是"少而精"。每周认真消化十道高质量题目，弄懂每道题的考察点、解题思路、可能出现的追问，远比每天刷五十道题但转头就忘更有效。很多人刷题数量不少，面试一追问就露馅，原因就是"看过答案"和"真正理解"之间差了十万八千里。

2.3 面试真题与场景模拟题的建设

算法之外，面试里更让人头疼的是"八股文"和场景题。所谓八股，并不是贬义词，它就是岗位基础知识。Java后端要会聊JVM内存模型、并发编程、Spring的Bean生命周期、MySQL索引结构和Redis缓存策略；前端要会聊事件循环、闭包、虚拟DOM、组件通信。这些知识点都有标准答案，但面试官在简历上随便挑一个点就能问出三层：是什么、为什么、有什么坑。

面试鸭对这类题目的处理方式是：每道题提供"考察点解析"和"回答框架"，而不是直接甩一个标准答案。比如"讲一下MySQL的索引失效场景"，回答框架会让你先答索引失效的几种典型场景，再补充底层原因（基于最左前缀匹配、基于回表的成本分析），最后结合实际业务给一个优化的例子。这样，用户不是背答案，而是在学一套组织表达的方式。

场景题更考验经验。比如"你的服务突然变慢了，怎么排查"，这种题没有标准答案，但回答的广度、顺序、深度能直接反映出候选人有没有做过线上问题处理。面试鸭把这类场景题和具体的知识点绑定，比如排查类问题绑定Linux命令、JVM调优、数据库慢查询优化几个知识点，用户做完题会收到一份能力雷达图，能直观看出自己在哪个环节最薄弱。

做这些内容最大的感受是，题目本身只是骨架，讲解和引导才是血肉。用户需要的不是一个答案，而是"怎么想到这个答案"的完整链路。

3. 核心功能与实现细节：让刷题真正有效

3.1 记忆曲线与错题回流机制

第一次做刷题类产品的人，容易忽略"复习"这个环节。刷题只完成了一半，另一半是巩固。产品里如果只有做题和看解析，用户大概率是"刷了就忘"，过两周又回来从第一题开始。

面试鸭内置了一套轻量级的复习机制，参考艾宾浩斯遗忘曲线，但做了简化，没有搞得很玄乎。具体逻辑是：用户每做错一道题，系统会把这个题目自动加入"错题本"，并按照第1天、第3天、第7天、第15天四个时间点生成复习任务。每完成一次复习，用户可以标记"已掌握"或者"仍不熟"，不熟的题会延长到第30天再次出现。

这个功能落地的时候，一开始想得很复杂：要给每道题建立用户状态，要用定时任务扫描数据库，还要计算复习计划。后来想开了，其实就是一个任务表加一个定时查询。用户相关的状态存在 MySQL 里，当天需要复习的用户 ID 列表用 Redis 存一个集合，定时任务每小时扫一次，向有复习任务的用户推送站内信和邮件通知。

这里有一个非常关键的设计：复习题的排序不能是简单的 FIFO，要让用户感觉"越来越会"。我们的策略是优先出那些"曾经做错、最近复习过、再次做对率达到 80% 以上"的题目，让用户每次打开复习列表都有一种"我都学会了"的正反馈，而不是连续看到一堆完全不会的题，导致直接关掉页面。

下面是复习任务的数据结构设计，简单但够用：

CREATE TABLE review_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, question_id BIGINT NOT NULL, task_due_date DATE NOT NULL, review_times INT DEFAULT 0, last_review_result TINYINT DEFAULT 0, status TINYINT DEFAULT 0, KEY idx_user_due (user_id, task_due_date) ) ENGINE=InnoDB;

3.2 模拟面试模式怎么设计

很多刷题工具都有"模拟考试"功能，但做得好的不多。原因在于考试和面试是两种完全不同的场景。笔试要求的是"在规定时间内把代码写出来"，面试考查的是"思考过程、表达和应对追问"。

面试鸭的模拟面试分三种模式。基础模式是限时答题，适合算法练习；岗位定制模式是按照用户选择的岗位方向随机抽题，题目混合了算法、基础和场景题；自由组卷模式适合已经有明确目标公司的用户，比如选了字节和阿里，系统会按这两个公司历年面试的知识点分布权重来出题。

模拟面试的核心功能有两个：录音和自评。做题过程中，用户可以用录音功能录下自己的口述答案，结束后回放。这个功能看着简单，实际效果出奇地好。大多数人第一次听自己的面试回答录音，都会惊到——原来自己的表达这么混乱、停顿这么多、废话词那么密集。这是任何文字解析都给不了的反馈。

自评环节我们做了四个等级选项："完全不会、不太会、基本掌握、非常熟练"。不少用户会在这四个选项里纠结，觉得自己"基本掌握"了但其实只是勉强做对。所以我们在提交自评后，会弹出一个思考提示，让用户尝试在 60 秒内不看解析，用自己的话把这道题的思路讲出来。能讲清楚才算真的会。

3.3 技术选型与架构取舍

技术选型没有太多花哨的地方，核心原则是"团队熟悉、生态成熟、扛得住初期流量"。

前端选了 Vue3 加 TypeScript，构建工具用 Vite。选择 Vue 而不是 React，很大程度上是因为团队几个人对 Vue 更熟，而且中文社区资料极其丰富，遇到问题基本都能搜到答案。现在很多从黑马程序员这类机构出来的前端同学，学的就是 Vue3 的整套体系，后续社区合作也方便。前端项目的整体结构参考了目前主流的 Vue3 基础到实战的项目组织方式：request 封装、路由守卫、Pinia 状态管理、组合式 API 拆分请求逻辑。

后端用的是 Java Spring Boot。没有选 Go 或者 Node，也是同样的原因——团队主力语言是 Java，Spring 生态成熟，后面要加功能、招人、扩展都方便。

数据存储方面，题目、用户、做题记录这些核心数据放 MySQL 里，表结构按业务拆得比较散，用多张表组织而不是单表大字段。热题数据、排行榜、打卡状态放 Redis，这一块一定要放缓存，因为刷题列表的访问频率极高，直接打 MySQL 会被打穿。搜索功能前期用 MySQL 的全文索引，等题库量上来之后再考虑上 Elasticsearch 做更复杂的搜索和标签过滤。

部署用 Docker Compose 加 Nginx，一台 4 核 8G 的云服务器就够了。上线初期根本不需要上 K8s，那是给自己找事。

上线前我们还做了两个细节优化。一个是打点日志，用户每一次进入页面、点击题目、提交答案、标记复习，都会产生一条日志。这一步前期觉得麻烦，后期做留存分析和内容优化的时候帮了大忙。另一个是接口幂等，用户在移动端网络不稳定时容易重复提交答案，前端做了防抖，后端做了基于请求 ID 的去重，防止同一道题被记录两次做题结果。

// 前端提交答案时的防抖处理 const answerSubmitLock = ref(false); async function submitAnswer(questionId, answer) { if (answerSubmitLock.value) return; answerSubmitLock.value = true; try { await api.submitAnswer({ questionId, answer }); await loadReviewTask(); } finally { setTimeout(() => { answerSubmitLock.value = false; }, 300); } }

3.4 移动端适配和小程序规划

上线第一周，后台统计里有 40% 的访问来自手机浏览器，这让我们意识到移动端体验比想象中更重要。程序员刷题场景大量发生在通勤地铁、午休间隙，不是所有人都愿意坐电脑前刷题。

移动端第一步没有做原生 App，而是先做了响应式适配，同时考虑后期做微信小程序。小程序对这类工具型产品很友好，不需要下载、分享方便、还能通过服务号做复习提醒。技术方案上，后续会尝试用 uni-app 或者 Taro 复用现有 Vue3 的代码基础，不用完全重写。

4. 冷启动与增长运营：一个刷题产品如何让用户留下来

4.1 内容共建：发动有经验的人写题

工具型产品最尴尬的是内容冷启动。没有用户就没有人贡献题解，没有题解就没有用户来看。为了打破这个循环，我们走了"先线下后线上"的路子。

上线之前，我找了技术社群里十几位在大厂工作的朋友，每人认领一个专题，负责写这个专题下的题目讲解和回答框架。报酬不高，主要靠"共建者"这个身份认同来驱动，大家愿意帮忙是因为自己跳槽时也被刷题折磨过，想为后来的人做点实事。

题目讲解有个硬性要求：不能只给答案，必须写出思考链路。比如一道二叉树的中序遍历题，讲解中要说明为什么递归写法空间复杂度是 O(log n)、迭代写法怎么用显式栈模拟递归、morris 遍历怎么做到 O(1) 空间。用户看一道题，相当于体验到三种层次的解法。

上线之后，我们开放了用户投稿入口，每个人都可以提交题目解析或者面经。为了保证质量，所有投稿走"投稿-初筛-专业审核-上线"四道流程。专业审核由共建者轮流负责，保证每篇内容至少经过两个人的校验。

4.2 与程序员内容生态的联动

内容产品最有效的推广方式不是投广告，而是和技术内容生态做联动。这个领域里有一批非常优秀的内容创作者，比如做编程导航的程序员鱼皮，他们对工具型产品的认知很深，帮忙推荐的转化效果远远好过广告投放。

我们在推广上做了三类事情。第一是和培训机构的知识体系结合，比如不少后端同学都是沿着黑马程序员这条学习路线走过来的，从 Java 基础入门到框架进阶。面试鸭试着把这些学习路线的知识点和题库做了映射，学完一章就可以在平台上做配套练习，相当于把刷题变成了课程的"课后作业"。

第二是深入到程序员聚集的社群里做口碑。程序员接单群、外包交流群、技术交流群，这些地方的共同特征是大家经常讨论面试行情、接单报价、职业规划。表面看接单和刷题没什么关系，但仔细观察会发现，接单群里最活跃的那批人，恰恰是最在意自身技术积累的人。不少人开玩笑说，刷题刷好了，接单报价都能谈高一点。这话虽然不够严谨，但把技术水平提上来之后再去面试或者接单，底气确实会不一样。

第三是内容种草。我们写了免费的《程序员面试高频 100 题》手册，放在官网可以留邮箱领取。手册把面试中最高频的一百个考点整理成了目录，每个考点只写要点，不展开，用户想深入看就得来平台。这个钩子看着简单，实际引流效果最稳定。

4.3 留存手段与产品迭代节奏

工具型产品的生死线是留存，刷题工具更是如此。用户可能因为一次面试准备下载下来，面试结束后就再也不用。这种事想挡是挡不住的，不如接受它，然后把"准备周期内"的体验做到极致。

留存手段我们做了四层。第一层是每日一题和连续打卡，最基础的激励方式，不复杂但有效。第二层是排行榜，但不是总榜，而是"本周榜"和"知识点榜"。总榜永远是前面几个大神，新人看不到希望，周榜给了每个人上榜机会。第三层是错题周报，每周末把用户这周的刷题数据、薄弱知识点、需要复习的题目用邮件发过去。打开率意外地高，很多人是在周报邮件里才第一次注意到自己的知识薄弱点。第四层是社区氛围，每道题下面可以评论求助，老用户会帮新用户答疑，问答之间就会产生内容沉淀。

产品迭代上，我们的原则是"每周一个小版本，每两周一个大版本"。第一个月重点做功能和题库补全；第二个月开始根据用户反馈做体验优化，比如把题目加载速度提上去、把解析区的排版调清晰；第三个月才慢慢开始做运营向的功能，比如打卡分享图、邀请奖励。这个节奏很重要，千万别在早期堆运营功能，产品和内容都还没稳，搞再多活动也留不住人。

5. 上线踩坑实录：这些问题你也会遇到

5.1 题目内容与版权风险

这是刷题类产品最容易踩的坑，而且是那种踩了就可能直接导致项目终止的坑。

最早我们想省事，直接抓取力扣的题面、牛客的面经、其他博客的解析。还好在正式上线之前，团队里有人提了一句"题面也是受版权保护的，别乱抓"，我们才停下手。后来花了一周时间，把所有直接抓取的题目全部换掉。方法是自己按照考点编写同类型题目，或者使用开源协议明确的题库，面经全部做脱敏处理，去掉公司名、面试官姓名等可识别信息。

这里建议大家一定要重视。做题库类产品，题目内容来源必须合规。如果用别人的原题和题解，哪怕只差一个"转载注明出处"也会出问题。正确做法是：要么完全原创，要么找到授权明确的开源题库，要么只做考点归纳和思路整理，不复制原文。

5.2 推荐系统冷启动难题

我们一开始就上了个性化推荐，结果效果很惨。没有用户行为数据的时候，推荐算法做出来的结果和随机排序差不多，甚至更差，因为算法会把一些冷门题推给新用户，用户一看不会做，直接流失。

后来把推荐策略退回到"冷启动模式"：新用户注册后，先按标准知识点顺序推荐必刷题单，收集到足够的做题数据（大约 20 道题）之后，再根据对错情况调整推荐权重。同时我们给每道题打上了"难度、知识点、面试热度、公司偏好"几个标签，推荐时优先推面试热度高、知识点匹配度高的题目。

这个调整上线后，新用户第二天的做题量提升了 30% 左右。这告诉我们一个朴素的道理：在产品早期，不要迷信算法，老老实实把内容组织好，比任何炫技的推荐模型都管用。

5.3 技术层面的性能问题

上线第一天就遇到了慢查询。用户集中访问题目列表页，数据库 CPU 直接飙高。排查后发现是题目表缺少组合索引，列表页筛选条件里"岗位 + 知识点 + 难度"三个字段没有走到索引。加了一个联合索引之后问题立刻缓解。

第二个坑是打卡接口的并发问题。每天早高峰（9点到10点）和晚上（22点到23点），会有大量用户集中打卡。我们一开始是直接写 MySQL 计数表，结果数据库连接池被占满。后来改成 Redis 先记打卡状态和计数，再异步把明细刷到 MySQL。用户看到的是秒级响应，数据库压力也降下来了。

第三个是图片资源加载慢。题解里配的示意图比较多，一开始直接放服务器本地，访问量一大就拖慢页面。后来把图片全部搬到了对象存储，用了 CDN 加速，问题解决。这种问题属于"不做不知道，做了才后悔没早点做"。

5.4 上线初期常见的运营问题

运营上我们很快发现，用户自驱力远比想象中低。很多用户注册后第一天刷了十几道题，第二天就忘记登录了。单纯的签到提醒不够，我们做了更"侵入"的触达：每天固定时间推送"你有一道复习题待完成"的通知，标题会带上题目类型和知识点名称，比如"【今日复习】数组：三数之和的思路你能复述吗？"。

这种带具体内容的推送效果比"快来打卡"好得多，因为用户点进来知道自己要干什么。

另一个容易忽略的点是用户反馈渠道。产品刚上线时，用户会在各个地方吐槽：在技术群里说、在小红书发帖、在应用商店打分，唯独不在产品里点"反馈"按钮。我们花了很大力气把应用商店评论、社区帖子里的反馈捞回来，整理成需求池，然后定期在更新公告里说明"你提的需求这周已经上线了"。当用户感觉自己的建议被采纳时，传播意愿是非常强的。

下面整理一下上线以来遇到的主要问题，做成一个速查表，后续做同类产品的朋友可以直接参考：

5.5 对后续版本的想法

面试鸭肯定不是做一个刷题网站就结束了。下一步计划有几个方向，但都不会一次性全铺开，会按优先级逐步推进。

第一优先是微信小程序版。程序员刷题的时间碎片化严重，小程序是最轻的载体，也能配合服务号做复习提醒。目前移动端 H5 版已经适配得差不多了，小程序只是在工程层面重写，业务逻辑可以复用。

第二是 AI 模拟面试官。这个功能需要接大模型能力，让 AI 扮演面试官，根据用户的回答进行追问。难点不是识别语音，而是怎么设计追问逻辑，让追问真的往深处挖，而不是每次都问同样的套话。这一步需要比较多的语料打磨，不会很快上线。

第三是企业端合作。现在题库里的大厂面试题，都是来自面经和公开资料，缺少真正来自企业内部的一手题目。如果能和企业 HR 或技术团队合作，做"企业真题专区"，对企业和求职者都有价值。当然这个牵扯到授权和合规问题，要谨慎推进。

结尾：一点实操体会

做了三个月面试鸭，最大的体会是：工具本身只是壳，真正难的是内容质量和用户信任。刷题这件事，用户投入的是时间，时间比钱更值钱。如果我们的题目不准确、讲解不清晰、推荐路径不合理，用户试个两三次就会彻底离开，而且会告诉身边所有人别来。

所以我的建议是，做任何工具型产品，第一版宁可功能少一点，也要把核心内容做扎实。把 100 道题的命中率和讲解质量提上去，比堆 1000 道凑数题有用得多。第二是要建立反馈闭环，每个版本都要告诉自己"我改了什么"，改完之后要看数据变化，而不是自嗨。第三是别怕用户用完就走，刷题产品本身就带有阶段性属性，用户来的时候让他觉得值，比想方设法把他留在产品里更有意义。

最后分享一个我们总结出来的刷题小技巧：每周挑出十道题，不多刷，但每道题都要做到能不看解析、完整口述一遍解题思路，并且把题目和答案里的"为什么"都讲清楚。坚持一个月，你会发现面试时的表达能力和思维清晰度上升一个台阶。面试鸭后续也会沿着这个方向继续迭代，做一个对程序员真正有用的在线面试刷题伙伴。