Elaina

MianCoach · AI 面试陪练

Sat, 14 Nov 2026 00:00:00 GMT

项目简介

MianCoach 是一个基于检索增强生成（RAG）的技术面试陪练应用，将知识库问答、题目收藏、模拟面试和练习复盘整合在同一套题库中。系统从题库原文检索参考资料，生成带来源引用的回答，并根据标准资料提供作答反馈。

🌐 在线体验：prep.eriiagi.com

核心功能：

💬 知识库问答：支持流式回答、来源引用和多轮追问，可打开引用核对原文
📚 题库浏览：按板块、类目浏览题目，支持搜索高亮、题目定位和原文图片查看
⭐ 个人收藏：从知识库或问答来源原文收藏整道题，按用户隔离，支持板块筛选和分页复习
🎯 模拟面试：按范围抽题，对照题库原文批改，展示得分、命中的知识点与补充建议
📊 面试复盘：历史记录和面试场次，带 AI 总结，可回放对话

技术架构

后端技术栈

核心框架：Spring Boot 3.3.5
数据库：PostgreSQL 17 + pgvector 0.8
AI 集成：
- 生成：阿里云百炼 qwen-plus
- 向量化：硅基流动 BAAI/bge-m3
- 重排：BAAI/bge-reranker-v2-m3
部署：Docker Compose

前端技术栈

框架：Vue 3.5 + TypeScript
构建：Vite 6
UI 库：Element Plus
状态管理：Pinia

功能详解

1. RAG 知识问答

系统采用 Parent-Child 分块策略：

检索粒度：小块（child chunk），提升召回精度
回答上下文：大块（parent chunk），保留完整语义
多路召回：向量检索 + BM25 混合召回，pgvector 负责向量相似度计算

RAG 流程：

用户提问经过意图分类（安全审查、拒答）
查询向量化，从 PostgreSQL 检索 Top-K 候选
Reranker 对候选重排，筛选最相关片段
组装上下文，调用大模型流式生成
答案带来源引用，点击可查看原文

关键实现：

使用 pgvector 的 HNSW 索引加速向量检索
支持多轮对话，前端传递最近一轮历史
游客模式不保存对话，登录用户按会话隔离

2. 模拟面试与批改

面试流程：

选择范围（板块 + 类目），设置抽题数量
系统随机抽题，用户依次作答
AI 对照题库原文批改，给出：
- 得分（0-100）
- 命中的知识点
- 补充建议
面试结束后生成场次总结，可回放对话

批改提示词设计：

使用题库原文作为标准答案
要求 AI 明确指出遗漏的关键点
给出具体的补充建议，不只是泛泛的鼓励

3. 题库与收藏

题库组织：

板块（如 Agent、RAG、工具调用）
类目（二级分类）
题目（Markdown 格式，包含代码、图片）

收藏功能：

从问答的来源引用直接收藏
从题库浏览页收藏
按板块筛选，分页复习
用户数据隔离，支持删除

技术亮点

1. pgvector 向量检索优化

-- HNSW 索引创建
CREATE INDEX chunks_embedding_hnsw_idx 
ON chunks USING hnsw (embedding vector_cosine_ops) 
WITH (m = 16, ef_construction = 64);

-- 向量相似度查询（余弦距离）
SELECT parent_id, content, 1 - (embedding <=> $1) AS score
FROM chunks
WHERE board_id = ANY($2)
ORDER BY embedding <=> $1
LIMIT 20;

优化策略：

使用 HNSW（Hierarchical Navigable Small World）索引，查询速度快
m=16, ef_construction=64 平衡了索引构建速度和查询精度
板块过滤在向量检索前执行，减少计算量

2. 流式回答与引用

后端使用 SseEmitter 流式推送：

答案逐 token 流式输出，降低首字延迟
引用信息在流结束后单独推送
前端按行解析 SSE，实时渲染 Markdown

3. 多模型配置与降级

系统支持三个独立的模型端点：

chat：生成端（问答、批改、总结）
embed：向量端（语料向量化、查询向量化）
rerank：重排端（召回候选打分）

降级策略：

Rerank 失败时降级为向量检索排序
向量化失败时返回空结果，不阻断用户操作
生成失败时返回错误提示，不影响历史记录

4. 安全与权限

JWT 认证：HS256 签名，1 天过期
密码加密：BCrypt，防止彩虹表攻击
数据隔离：会话、收藏按 user_id 隔离，API 校验归属
管理员保护：禁止删除自己、禁用自己或取消自己的管理员角色

部署运行

本地开发

# 1. 启动后端（需要 PostgreSQL + pgvector）
cd server
./mvnw spring-boot:run

# 2. 启动前端
cd web
pnpm install
pnpm dev

Docker Compose 部署

# 生产环境（PostgreSQL + 后端 + 前端 Nginx）
docker compose -f compose.prod.yml up -d

# 查看日志
docker compose -f compose.prod.yml logs -f server

环境变量配置：

AI_CHAT_*：生成模型配置（API Key、Base URL、模型名）
AI_EMBED_*：向量模型配置
AI_RERANK_*：重排模型配置
JWT_SECRET：JWT 签名密钥（生产必须修改）
POSTGRES_*：数据库连接信息

详细配置见 .env.example。

开发心得

1. RAG 不是银弹

RAG 能减少幻觉，但不能完全消除：

检索召回不准时，答案仍会偏离
题库内容质量直接影响回答质量
需要持续优化分块策略和检索参数

经验：

Parent-Child 分块比固定窗口效果好
混合检索（向量 + BM25）召回更全
Rerank 对提升精度帮助很大，但有额外成本

2. 向量索引的权衡

HNSW 索引构建慢但查询快，适合读多写少的场景。我的题库约 2000 个 chunk，索引构建耗时约 10 秒，但查询只需几毫秒。

踩过的坑：

初次部署时忘记建索引，查询超时
ef_construction 设太大（200+），索引构建卡死
调整为 m=16, ef_construction=64 后平衡了性能

3. 流式回答的坑

SSE 在生产环境可能被 Nginx、CDN 缓冲，导致前端收不到实时数据。

解决方案：

Nginx 配置 proxy_buffering off;
每条消息以 \n\n 结尾，符合 SSE 规范
前端使用 EventSource 或 fetch 读取流

4. 用户体验细节

游客模式：不登录也能问答，降低试用门槛
引用可点击：直接查看原文，增强可信度
暗色模式：长时间复习不刺眼
响应式设计：移动端也能流畅使用

未来规划

[ ] 支持更多向量模型（OpenAI、本地模型）
[ ] 增加语音面试功能（语音识别 + 实时批改）
[ ] 面试题库自动扩充（爬虫 + 去重）
[ ] 导出复习笔记（PDF、Markdown）
[ ] 跨模型对比（A/B Test 不同大模型的批改质量）

项目地址

🔗 GitHub: elaina-agi/miancoach
🌐 在线体验: miancoach.elaina.icu

如果这个项目对你有帮助，欢迎 Star ⭐ 和提 Issue！

:::tip[RAG 应用开发建议] 做 RAG 应用时，检索质量比生成质量更重要。大模型本身已经很强，但检索不准时再强的模型也无力回天。建议先把检索调好（召回、重排、分块策略），再考虑换更好的生成模型。 :::

:::note[关于命名] 项目原名 baguwen-rag（八股文 RAG），后改为 miancoach（面试教练）。现有部署保持数据库与环境变量兼容，不影响已有用户。 :::

OCR Translate - 轻量级截图翻译工具

Sat, 14 Nov 2026 00:00:00 GMT

项目简介

OCR Translate 是一个轻量级的 Windows 截图翻译工具，使用 Rust 和 egui 开发。按 Ctrl+Shift+T 框选屏幕，识别原文后在悬浮窗口中查看译文；也可以在主窗口翻译图片或直接输入的文字。

主要特性：

📸 框选截图翻译：快捷键 Ctrl+Shift+T，OCR 识别后尽早显示结果
🚀 轻量快速：Rust 编写，启动快、占用低
🪟 多悬浮窗口：固定的结果窗会保留，新结果窗会避开已有窗口
🔄 最新截图优先：翻译过程中可再次框选，新截图会取代旧任务
🌐 多翻译服务：支持 DeepL、百度、火山引擎、OpenAI Vision 等
🎙️ 语音朗读（可选）：Azure 语音合成，支持多种语言

📥 下载 Windows 版本

技术栈

语言：Rust 1.82+
GUI 框架：egui + eframe（即时模式 GUI）
OCR 引擎：Windows OCR（系统自带，无需联网）
截图：screenshots crate
网络请求：reqwest（异步 HTTP 客户端）
平台：Windows 10/11

功能详解

1. 屏幕框选翻译

使用流程：

按 Ctrl+Shift+T 或点击主窗口「框选屏幕」
鼠标拖动框选识别区域
系统 OCR 识别原文，结果窗口尽早显示
翻译服务返回译文，更新到结果窗口

体验优化：

OCR 识别完成后立即显示原文，不等翻译完成
翻译过程中可继续框选，新截图成功后会取代旧任务
旧任务的迟到结果不会覆盖新结果，避免混乱

2. 本地 Windows OCR

使用 Windows 系统自带的 OCR 引擎识别文字：

无需联网：完全离线识别
多语言支持：中文、英文、日文等（取决于系统安装的语言包）
轻量快速：直接调用系统 API，不依赖第三方服务

添加语言包（如果识别不准）：

打开「设置」→「时间和语言」→「语言和区域」
点击「添加语言」，搜索你需要的语言（如日语）
安装后，OCR Translate 会自动检测并使用

3. 多翻译服务支持

内置翻译服务：

DeepL API：翻译质量高，支持免费层和 Pro
百度翻译：中文支持好，需要百度翻译 API Key
火山引擎：字节跳动的翻译服务
OpenAI Vision：使用视觉模型直接识别图片并翻译（可跳过 OCR）

配置方式：

在主窗口点击「设置」
填入对应服务的 API Key
密钥使用 Windows DPAPI 加密存储，只能由同一台电脑的同一用户解密

4. 悬浮结果窗口

窗口特性：

可拖动、可缩放
可复制译文到剪贴板
固定后会在后续截图中保留
新窗口会自动避开已有窗口，不重叠
点击「打开主窗口」可回到设置界面

5. 语音朗读（可选）

集成 Azure 语音合成服务：

支持中文、英文、日文等多种语言
支持调整语速、音调
需要 Azure 语音服务的订阅密钥

技术亮点

1. Rust + egui 的即时模式 GUI

为什么选择 egui？

即时模式：不需要维护复杂的状态树，代码更简洁
跨平台：理论上可以移植到 macOS、Linux（但 Windows OCR API 不跨平台）
性能好：Rust 原生性能，启动快、占用低
内置布局：flexbox 风格的布局系统，易用

示例代码：

// egui 的即时模式写法
egui::Window::new("结果")
    .resizable(true)
    .show(ctx, |ui| {
        ui.label(&self.original_text);
        ui.separator();
        ui.label(&self.translated_text);
        if ui.button("复制译文").clicked() {
            self.copy_to_clipboard();
        }
    });

2. 异步任务处理

使用 tokio 异步运行时处理 OCR 和翻译：

OCR 和翻译在后台线程执行，不阻塞 GUI
使用 mpsc 通道在线程间传递结果
超时控制：网络请求 20 秒超时，避免卡死

3. 截图取消机制

问题：

用户快速连续截图时，旧的翻译任务可能还在进行
如果不处理，旧结果会覆盖新结果

解决方案：

每次新截图时，生成一个唯一的任务 ID
翻译完成时，检查任务 ID 是否匹配
不匹配则丢弃结果，不更新窗口

4. 配置加密存储

安全措施：

API Key 使用 Windows DPAPI 加密后存储在 %APPDATA%\ocr-translate\config.json
只能由同一台电脑的同一 Windows 用户解密
临时截图保存在系统临时目录，程序退出时自动清理

开发动机

为什么要做这个工具？

在学习日语、查看外文文档时，经常需要翻译屏幕上的文字。市面上的翻译工具要么太重（带广告、后台常驻）、要么要收费、要么隐私不安全。我想要一个：

轻量级：启动快，占用少，用完就关
离线 OCR：不把截图传到云端，隐私安全
开源免费：代码透明，可审计

为什么用 Rust？

性能好：Rust 编译出的可执行文件小、启动快
学习曲线：正好在学 Rust，拿来练手
生态成熟：egui、reqwest、tokio 等库都很好用

部署运行

下载使用

直接下载编译好的可执行文件：

下载最新版本
解压后运行 ocr-translate.exe
首次运行会要求设置翻译服务（可选 DeepL、百度等）

从源码构建

需要 Rust 1.82+ 和 Visual Studio C++ Build Tools：

# 克隆仓库
git clone https://github.com/elaina-agi/ocr-translate.git
cd ocr-translate

# 开发运行
cargo run

# 测试
cargo test --locked

# 发布构建
cargo build --release --locked

构建产物位于 target/release/ocr-translate.exe。

开发心得

1. egui 的即时模式很爽

和传统的保留模式 GUI（如 Qt、GTK）不同，egui 的即时模式不需要维护复杂的状态树。每一帧都重新绘制整个界面，代码逻辑更清晰。

优点：

不需要手动同步状态和 UI
调试方便，状态变化立即体现

缺点：

复杂动画不如保留模式流畅
需要注意避免每帧都做重复计算

2. Windows API 的坑

Windows OCR API 是 WinRT 接口，Rust 调用需要通过 windows crate：

异步 API 要转成 Rust 的 async/await
语言包检测依赖系统设置，需要给用户明确提示

3. 多线程的挑战

截图、OCR、翻译都是耗时操作，不能阻塞 GUI 主线程。用 tokio 异步处理后，还要注意：

GUI 更新必须在主线程
使用 mpsc 通道传递结果
任务取消要及时响应

4. 用户体验细节

快捷键全局生效：不需要窗口在前台
结果窗避开已有窗口：减少重叠，一次截图能看到多个结果
OCR 先显示，翻译后更新：即使翻译慢，也能先看到原文

未来规划

[ ] 支持 macOS 和 Linux（需要替换 Windows OCR）
[ ] 增加 OCR 结果编辑（识别错误时手动修正）
[ ] 支持更多翻译服务（Google Translate、彩云小译等）
[ ] 历史记录功能（保存最近的翻译结果）
[ ] 划词翻译（监听剪贴板）

项目地址

🔗 GitHub: elaina-agi/ocr-translate
📥 下载: Releases

欢迎 Star ⭐、提 Issue 和 PR！

:::tip[给 Rust 初学者] 这个项目很适合 Rust 入门者练手：代码量适中（约 2000 行），涉及 GUI、异步、网络请求等常见场景。egui 的即时模式比传统 GUI 框架好上手。 :::

:::note[隐私说明]

OCR 使用 Windows 系统本地引擎，截图不上传
翻译需要调用在线 API，但只传送文本，不传送图片
API Key 加密存储在本地，不上传到任何服务器 :::