面试边注：别急着背答案，先把这道题讲明白

Mon, 31 Aug 2026 17:14:52 +0800

准备技术面试时，最容易做的事是继续收藏资料，最难的事却是把一道题讲清楚。答案看过不少，轮到自己开口，常常只剩几个关键词；隔几天再看，又像第一次见。

我做“面试边注”，就是想把刷题从“看过答案”往前推一步：先自己组织，再看结论和原理；写下回答后，可以让 AI 面试官指出哪里说对了、下一步最该补什么；如果某个地方还是绕，也可以围绕当前题继续问 AI。

目前平台整理了 14 个公开题库、50 个章节和 762 道题，覆盖前端、Java 后端、AI 应用与求职专项。游客不用注册就能读题、搜索、使用练习模式、AI 面试官评分和 AI 助手；个人学习记录需要登录后保存。

先选方向，不必从第一题硬背

题库按学习方向组织，而不是把几百道题塞进一个长目录：

方向	当前题量	主要内容
前端开发	300	JavaScript、Vue、React、浏览器、工程化与 TypeScript
后端开发	234	Java 基础、Spring、数据库、缓存、网络与部署
AI 应用开发	75	RAG、Agent、MCP、Tool Calling、流式交互与安全
求职专项	153	简历项目追问、真实面经与公司专项准备

题库中心可以按方向筛选，也可以按名称或技术关键词搜索题库；进入具体题库后，再搜索题目或按章节跳转。登录账号还能接着上次进度继续学习。首页也会直接放出真实题目，第一次访问不需要先理解整套产品。

一道题，不只放一整页答案

我希望题解先解决“面试时怎么开口”，再展开完整原理。因此每道题会尽量按同一条阅读顺序拆开：

速答：先给可以直接复述的结论。
术语：把容易卡住的关键词换成白话。
原理：说明它为什么这样工作，而不是只给定义。
实战：用代码或具体场景把概念落下来。
追问与避坑：继续准备面试官可能往下问的内容。
来源：保留可以回去核对的资料入口。

遇到流程型问题时，题解会配站内图解。例如 HashMap 的 put 不只写“数组、链表、红黑树”，而是把定位桶、处理冲突、插入节点和扩容的先后关系画出来。

社区面经主要用来确认“真实面试里问过什么”。正式答案会重新整理，并尽量用官方文档和较稳定的技术资料交叉核对；无法公开查看正文的登录墙页面，不会被当成公开证据。

从“看懂”变成“能说出来”

只读答案很容易产生一种错觉：每句话都认识，于是以为自己已经会了。练习模式会先把答案收起来，让我自己组织一遍，再提交回答、对照题解并做一次自评。

写完以后，让 AI 面试官评一次

新版本在这一步加了 AI 评分。写下答案并提交后，可以点“开始 AI 评分”，看看自己的回答在技术正确性、原理与因果、关键点覆盖、场景边界与取舍、表达结构这五项上分别说到了什么。

截图里只写了“重叠分块”。这个方向没有错，但还没解释它解决什么问题、会增加什么代价，以及什么时候该选多大的重叠，所以系统给出的重点不是一句“答错了”，而是告诉我下一次回答最先应该补哪一层。

分数也不是让模型随手报一个数字。模型先判断五项表现分别处在哪个等级，服务端再按 30 / 25 / 20 / 15 / 10 的固定权重换算总分；如果回答里出现跑题、核心概念说反、虚构机制等严重问题，还会触发扣分或总分上限。评分按回答表达的意思判断，不要求照抄标准答案，也不会单纯因为字少就机械扣分。

这项评分只用于当次练习，回答、分数和评语都不会保存到账号，也不代表真实面试结果。即使评分暂时失败，标准答案仍然可以正常查看。

AI 评分看的是这一次回答；后面的“不会、模糊、掌握”自评只决定下一次什么时候复习。三种选择分别对应 1、3、7 天后，再配合“未开始、学习中、需复习、已掌握”四种状态，形成一条比较简单的复习线。

登录后，收藏、总结、高亮、批注、掌握状态和复习安排会保存到个人账号。这样批注不只是写在某一页旁边，而是能和题目、进度一起带到下一次学习。

AI 助手只围绕当前题帮忙

AI 助手不是另开一个没有上下文的聊天窗口。打开某道题后，页面会把当前题目的必要内容和这次对话一起交给服务端；可以让它换一种说法、补一个项目场景，或者继续追问面试表达。

这条链路可以简化成：

当前题目 + 本次对话 → 同源 AI 代理 → OpenAI-compatible 模型 → SSE 流式返回 → 页面逐段显示

浏览器不会直接拿模型密钥。服务端负责附带题目上下文、限制并发与超时，并把上游的流式或一次性响应统一交给前端。AI 对话目前不会保存到账号，切换题目后也会清空；它更像阅读时的临时辅导，不是另一套长期知识库。

这里容易混淆：RAG、Agent 是题库会讲的技术主题，不是这套 AI 助手的实现。当前助手没有接向量库或全题库检索，只携带当前题和本次对话。回答仍可能出错，重要内容要回到题解与来源核对。

游客能直接用，账号只负责个人记录

我把公开阅读和个人数据分开处理：

游客可以浏览全部公开题库、搜索、切题、练习、切换阅读版式，并体验 AI 面试官评分和 AI 助手，但不会写入个人学习记录。
学习账号在游客功能之上保存进度、收藏、批注和复习计划，并支持跨设备继续。
内容编辑可以维护题库、归档恢复内容并预览 Markdown 导入；管理员还可以管理账号与邀请、处理反馈申请，并创建和下载 SQLite 备份。

服务端的 SQLite 是登录用户学习状态的最终记录。网络不稳时，浏览器会用 IndexedDB 按账号暂存尚未确认的修改，连接恢复后再同步，避免丢进度或把记录写错账号。

题库内容怎样进入页面

题库不是直接写死在 React 组件里。项目把 Markdown 和 JavaScript 内容源经过生成与检查，再导出为公开索引、按题库拆分的内容快照和 SQLite 种子。

内容源 → 生成与质量检查 → 题库索引 + 分片快照 → SQLite

页面第一次进入只读取题库索引，真正打开某个题库时才加载对应分片。实时接口暂时不可用时，游客阅读还能退回到静态快照；这类回退只保证公开内容可读，账号、批注和复习记录仍然不可用。

内容检查会关注题目结构、来源链接、首屏是否讲清“结论、为什么、怎么用”，以及代码和站内图解是否与题目匹配。当前基线中，735 道题带有可核验来源，507 道带代码示例，48 道带站内图解。

实现上怎样分工

部分	负责什么
React + TypeScript	首页、题库中心、阅读器、练习模式、AI 评分面板、批注和 AI 对话
Express	同源 API、公开题库、账号、学习状态、内容管理，以及 AI 对话与评分入口
SQLite	题库、账号、会话、个人学习记录与审计日志
内容管线	生成题库、检查结构与来源，并导出按需加载的公开快照
ECS + systemd	运行单个 Node 服务和持久化数据库
Cloudflare Tunnel	把只监听本机回环地址的服务接入 HTTPS 公网入口

正式站运行在阿里云 ECS 上，Express 同时提供 API 和构建后的前端资源。数据库放在独立持久目录，发布前先做检查与备份，再切换版本并验证健康状态。Vercel 保留公开题库的静态版本，但它不是一套独立的账号与数据后端。

现在的边界

公共注册目前关闭，普通学习账号需要邀请或由管理员创建；如果只是读题和练习，游客模式已经够用。

题量和质量指标是当前版本的快照，后续内容更新后会变化。社区来源只能说明某类问题在面试中出现过，不能替代技术事实本身；AI 对话与评分也只负责辅助理解和复盘，不替代来源核验。

现在我更愿意把面试边注看成一张可以持续修改的学习桌面：题库负责给出范围，题解负责讲清楚，练习和复习负责把内容留下来，AI 用来换一种讲法，也用来检查自己到底有没有说清楚。

平台入口：interview.linsk27.dpdns.org/app

技术面试 on 404_@林达