我如何搭建一个 LLM 学习工作台

刚开始系统学习大模型应用时，我经常在教程、编辑器、终端和聊天窗口之间来回切换。单个知识点并不难，真正影响效率的是上下文不断丢失：文档讲到流式输出，代码却在另一个目录；终端报错后，又要重新向模型解释环境。于是我做了一个桌面学习工作台，希望把“阅读、动手、验证、提问”放在同一个窗口中。

这篇文章记录的是项目起点和实现思路，不代表其中列出的所有模型方向都已经完成生产级验证。对应仓库创建于 2026 年 1 月 7 日，因此笔记也沿用这个日期。

把学习过程组织成一个界面

项目使用 Electron 作为桌面容器，React 负责课程导航和内容展示。左侧按周次和步骤组织学习内容，中间渲染 Markdown，底部嵌入基于 xterm.js 与 node-pty 的终端。这样做的重点不是“再写一个 Markdown 阅读器”，而是让教程里的命令可以立即执行，错误输出也能留在当前学习上下文中。

课程目录按十五周组织，从 Prompt、SSE、多轮对话逐步延伸到 Function Calling、Agent、MCP、Embedding、RAG、Ollama、vLLM 与量化。这里的 105 个步骤是一种内容编排方式，表示我为学习路径准备了对应章节，并不等价于我已经独立训练或部署过其中所有模型。

前端、桌面壳与服务端的边界

我把应用拆成三个边界。Electron 主进程只处理窗口、IPC 和本地终端能力；React 渲染进程负责交互，不直接接触系统权限；Express 服务负责扫描课程内容，并代理模型请求。这个划分让我可以继续使用熟悉的前端开发方式，同时避免把文件系统和进程能力直接暴露给页面。

模型问答通过服务端路由访问 DeepSeek 兼容接口。API Key 从环境变量读取，不进入前端包，也不写进课程 Markdown。对一个学习项目来说，这个边界看似多了一层服务，但它提前建立了正确习惯：浏览器只提交问题和上下文，密钥、模型地址和异常处理留在可信服务端。

AI 问答只是辅助层

我没有把 AI 问答做成自动代写答案的入口。更合适的用法是：阅读某个步骤后，把当前章节和具体报错交给模型，请它解释协议、比较实现方式，或者指出遗漏的边界条件。终端仍由我自己执行，代码是否有效仍以真实输出为准。

这种安排也暴露了上下文工程的重要性。如果只发送一句“为什么失败”，模型几乎只能猜；加入当前章节、运行命令、错误片段和期望行为后，回答才稳定。后来我在 Claude Code、Codex 和其他 Agent 项目中反复使用的“先准备证据，再请求模型”的习惯，就是从这类学习实验逐步形成的。

当前限制

这个仓库更接近个人学习工具，而不是面向多人使用的教育产品。课程完成度并不完全一致，部分后期章节侧重知识整理；集成终端依赖本机环境，跨平台打包仍需要处理 node-pty 的原生依赖；AI 问答也没有账号、配额和完整评测体系。它验证了桌面学习闭环是否顺手，但没有证明大规模分发和长期维护能力。

这次实践带来的收获

对我来说，最有价值的不是 Electron 本身，而是把零散学习动作变成可观察的流程：文档提供目标，终端给出事实，AI 帮助解释，最终仍由执行结果完成验证。前端工程经验让我可以快速搭出承载这些动作的界面，而服务端代理、权限边界和上下文组织，则让我开始从“调用一个模型”走向“设计一个可靠的 AI 使用过程”。

相关代码与课程结构可以在 LLMStudyLS 中查看。