MianCoach 是一个基于检索增强生成（RAG）的技术面试陪练应用，将知识库问答、题目收藏、模拟面试和练习复盘整合在同一套题库中。系统从题库原文检索参考资料，生成带来源引用的回答，并根据标准资料提供作答反馈。
🌐 在线体验：prep.eriiagi.com
核心功能：
qwen-plusBAAI/bge-m3BAAI/bge-reranker-v2-m3系统采用 Parent-Child 分块策略：
RAG 流程：
关键实现：
面试流程：
批改提示词设计：
题库组织：
收藏功能：
-- 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;
优化策略：
m=16, ef_construction=64 平衡了索引构建速度和查询精度后端使用 SseEmitter 流式推送：
系统支持三个独立的模型端点：
chat：生成端（问答、批改、总结）embed：向量端（语料向量化、查询向量化）rerank：重排端（召回候选打分）降级策略：
user_id 隔离，API 校验归属# 1. 启动后端（需要 PostgreSQL + pgvector）
cd server
./mvnw spring-boot:run
# 2. 启动前端
cd web
pnpm install
pnpm dev
# 生产环境（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。
RAG 能减少幻觉，但不能完全消除：
经验：
HNSW 索引构建慢但查询快，适合读多写少的场景。我的题库约 2000 个 chunk，索引构建耗时约 10 秒，但查询只需几毫秒。
踩过的坑：
ef_construction 设太大（200+），索引构建卡死m=16, ef_construction=64 后平衡了性能SSE 在生产环境可能被 Nginx、CDN 缓冲，导致前端收不到实时数据。
解决方案：
proxy_buffering off;\n\n 结尾，符合 SSE 规范EventSource 或 fetch 读取流如果这个项目对你有帮助，欢迎 Star ⭐ 和提 Issue！
:::tip[RAG 应用开发建议] 做 RAG 应用时，检索质量比生成质量更重要。大模型本身已经很强，但检索不准时再强的模型也无力回天。建议先把检索调好（召回、重排、分块策略），再考虑换更好的生成模型。 :::
:::note[关于命名]
项目原名 baguwen-rag（八股文 RAG），后改为 miancoach（面试教练）。现有部署保持数据库与环境变量兼容，不影响已有用户。
:::
OCR Translate 是一个轻量级的 Windows 截图翻译工具，使用 Rust 和 egui 开发。按 Ctrl+Shift+T 框选屏幕，识别原文后在悬浮窗口中查看译文；也可以在主窗口翻译图片或直接输入的文字。
主要特性：
Ctrl+Shift+T，OCR 识别后尽早显示结果screenshots cratereqwest（异步 HTTP 客户端）使用流程：
Ctrl+Shift+T 或点击主窗口「框选屏幕」体验优化：
使用 Windows 系统自带的 OCR 引擎识别文字：
添加语言包（如果识别不准）：
内置翻译服务：
配置方式：
窗口特性：
集成 Azure 语音合成服务：
为什么选择 egui？
示例代码：
// 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();
}
});
使用 tokio 异步运行时处理 OCR 和翻译：
mpsc 通道在线程间传递结果问题：
解决方案：
安全措施：
%APPDATA%\ocr-translate\config.json在学习日语、查看外文文档时，经常需要翻译屏幕上的文字。市面上的翻译工具要么太重（带广告、后台常驻）、要么要收费、要么隐私不安全。我想要一个：
egui、reqwest、tokio 等库都很好用直接下载编译好的可执行文件：
ocr-translate.exe需要 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。
和传统的保留模式 GUI（如 Qt、GTK）不同，egui 的即时模式不需要维护复杂的状态树。每一帧都重新绘制整个界面，代码逻辑更清晰。
优点：
缺点：
Windows OCR API 是 WinRT 接口，Rust 调用需要通过 windows crate：
async/await截图、OCR、翻译都是耗时操作，不能阻塞 GUI 主线程。用 tokio 异步处理后，还要注意：
mpsc 通道传递结果欢迎 Star ⭐、提 Issue 和 PR！
:::tip[给 Rust 初学者] 这个项目很适合 Rust 入门者练手：代码量适中（约 2000 行），涉及 GUI、异步、网络请求等常见场景。egui 的即时模式比传统 GUI 框架好上手。 :::
:::note[隐私说明]