北京
学生社团换届时，上一届负责人脑子里的东西怎么办？一份交接文档可能躺在某个文件夹里，一些解释埋在聊天记录中，还有更多只存在于某个人的记忆里：为什么选了这个场地、那次工作坊哪里出了岔子、下一个团队该接着做哪个项目。
在尼日利亚联邦技术大学米纳分校（FUTMinna）参与学生社区的经历，让这位开发者对这个问题格外在意。下一个团队理应有一些能直接拿来用的东西。于是他做了 OnboardX，一个本地运行的社区记忆与交接应用：保存决策、教训和未完成的工作，针对这些记录提问，再生成一份可编辑的交接草稿。
他对赛题“机器中的幽灵”的理解，落在上一届团队留下的知识上。前任负责人可能已经离开，但他们记录下来的经验仍能帮下一个人做决定。OnboardX 让这些记录更容易被找到和使用。它不冒充前任负责人，只根据他们记录过的内容作答，并展示出处。
应用内置了一个虚构的示例社区，不需要真实的内部文档就能上手。主流程分四步：
- 保存一条记忆，填写标题、分类和内容；
- 针对档案提出问题；
- 阅读答案，同时看到支撑它的原文摘录；
- 生成交接草稿，审阅后导出为 Markdown。
他测试过的一个问题是：“我们为什么选了图书馆？”OnboardX 回答，图书馆供电和座位都可靠。答案下方，它展示了那条包含该解释的“工作坊场地决策”记录。
他还问了会长的电话号码，这个信息不在记录里。系统回应：在已保存的记录中找不到。第二个结果对他同样重要——交接工具必须让缺口可见，因为下一个团队可能会照着它说的去做。
技术实现上，前端用 React 和 Vite，后端用 Express，持久化靠一个本地 JSON 文件。保存的记忆会被切成更小的摘录。有人提问时，轻量级关键词检索挑出相关摘录，通过 Ollama 交给 Gemma 3 1B。模型输出结构化的 JSON 响应，后端检查格式和引用 ID，再把 ID 解析成界面上展示的存档摘录。
这样做能让引用绑定到真实记录上，但不保证生成的每一句都正确，所以原文始终可供查阅。交接功能则利用档案起草各个部分：背景、决策、教训、未完成的工作和缺口，用户可以在导出前编辑草稿。
选择本地推理有现实考虑。社区交接记录可能包含内部讨论和决策，他希望有一个版本能让记录和模型跑在同一台机器上。通过 Ollama 使用开放权重模型，核心工作流不依赖托管式 AI API，模型还能通过配置更换。代价是安装门槛：用户需要装依赖、装 Ollama 和模型，本地推理也会占用笔记本资源。但按这个方案，没有按请求计费的托管 AI 开销。对一个用来保存知识的工具来说，能自己持有并运行这套系统，本身就是价值的一部分。
开发过程并不顺利。他用 GitHub Copilot 应用逐步搭建和调试，包括 React 界面、Express 接口、检索、引用校验和交接导出，实现由他主导，并在本地手动测试。起初终端里没有 Node，装好后又碰上缺失的依赖；等他打开后端地址想看前端，得到的是 Cannot GET /。这些步骤让他弄清了 React 开发服务器和 Express API 各自的分工。
测试还暴露了一个更有意义的问题：一个没有答案的问题，仍可能在“来源”下显示一条不相关的检索记录。这让他看清了检索到的文本和支持答案的证据之间的区别——找到一条记录，不等于它支撑了这个答案。最让他满意的时刻，是看到一个问题被回答，下面正好附着那条保存过的解释。这让他觉得这个想法不只是又一个聊天界面。
当前版本是一个范围聚焦的本地原型，限制也很明确：
- 没有账号，也没有共享的在线工作区；
- 关键词检索在提问措辞不同时可能漏掉相关记录；
- Gemma 3 1B 会出错；
- 生成的交接内容需要人工审阅；
- Markdown 导出得到的是一份可读的交接文档，不会自动把可检索的档案转移到另一台设备。
他下一步想改进检索和档案的可移植性。这一版的重点，是先跑通一条从保存知识、到提问、再到准备交接的可用路径。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
