【S3W3 交叉评测】问渠:多轮上下文、学习证据链与本地数据安全建议 #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
1. 项目理解
我理解“问渠”是一款面向学生的桌面 AI 学习助手。
它将 PDF、Word、图片和文本阅读,与 AI 对话、截图提问、语音输入、悬浮窗、会话管理和学习笔记整合在一个 Electron 应用中。
学生可以一边查看学习资料,一边框选文档区域并向 AI 提问;对话结果还可以整理成知识重点、解题技巧或其他类型的笔记,并按照学科长期管理。
2. 项目亮点
3. 当前问题和疑点
3.1 正常回答没有进入下一轮模型上下文
这是当前最影响核心学习体验的问题。
发送问题时,程序会先把用户消息加入
contextWindow,然后使用该窗口调用模型。模型成功返回后,AI 回答只被加入页面展示使用的
messages,没有同步加入contextWindow。因此可能出现:
用户界面看起来是连续对话,但模型看不到自己上一轮的完整回答,容易造成:
停止生成的路径会把部分 AI 回答加入
contextWindow,正常完成路径却没有加入,两条路径行为也不一致。建议在成功生成后同时更新:
messages;contextWindow;并增加回归测试,明确验证第二轮请求同时包含:
3.2 多张截图只在当前请求中完整存在
输入区最多允许添加多张截图,当前请求会把这些截图全部发给模型。
但用户消息结构只保存一个
screenshotData,实际只记录第一张截图。后续追问或重新加载会话时,其余截图不会进入上下文。如果用户一次框选一道题的题干、图表和选项,第一轮模型可以看到全部图片,但下一轮可能只保留第一张。
建议将消息结构改为:
screenshotData: string[]并确保:
都使用同一组附件。
3.3 “划词即问”目前实际是框选截图
当前实现不是选中文本后直接提问,而是截取屏幕区域,将截图交给视觉模型。
这种方式的优点是可以覆盖扫描版 PDF、公式、图表和图片,但也意味着:
建议区分两个能力:
界面名称也可以从统一的“划词”调整为“划词 / 框选提问”,避免功能描述与实际行为不一致。
3.4 尚未形成“层层追溯”的学习证据链
当前回答主要来自通用系统提示词和对话上下文,没有看到文档切块、检索、页码引用、原文证据或答案来源链。
建议每次基于文档的提问都生成一组来源信息:
用户点击回答中的来源标记后,应能够直接跳回文档对应位置。
这样“层层追溯”才能从连续聊天升级为:
问题 → 回答 → 原文证据 → 文档位置 → 后续追问3.5 AI 笔记没有保存来源和生成依据
当前笔记结构只保存:
笔记是根据“学生问题 + AI 回答”再次调用模型生成的,但没有保存:
如果上一轮 AI 回答存在错误,错误内容可能被再次总结并沉淀为长期“知识重点”。
建议为笔记增加来源字段,并在保存前展示:
笔记页面还应支持“一键回到原文”和“一键回到原对话”。
3.6 API Key、会话和笔记均以明文保存在 localStorage
当前设置状态会把完整
apiConfigs写入localStorage,其中包含 API Key。会话、截图和笔记也分别保存在浏览器式本地存储中。
这虽然实现了本地保存,但不能等同于安全存储。渲染进程注入、本地应用数据目录泄露或同一系统账户下的其他程序,都可能读取这些内容。
建议:
safeStorage或操作系统凭据库保存;3.7 非 HTTPS API 地址只警告但仍继续发送
程序发现外部 API 地址不是 HTTPS 时,只会输出日志警告,随后仍然发送:
如果用户误填普通 HTTP 地址,密钥和学习内容可能被明文传输。
建议:
localhost和127.0.0.1外,默认拒绝 HTTP;3.8 麦克风权限配置与语音输入功能冲突
语音输入使用
navigator.mediaDevices.getUserMedia({ audio: true })请求麦克风。但 Electron 主进程当前会拒绝所有权限请求,包括麦克风。
因此按照当前代码路径,打包后的桌面应用可能无法正常获得录音权限。
建议:
media权限;3.9 最新安装包未覆盖后续安全加固
公开的 v1.0.1 Windows 安装包早于后续的全面安全审计提交。
后续源码已经增加:
但目前公开下载的 v1.0.1 安装包无法证明包含这些后续修复。
建议发布新的安装包,并明确记录:
评审和用户才能确认下载到的二进制与当前源码一致。
3.10 存储不足时会自动删除一半旧数据
当
localStorage空间不足时,程序会自动删除较早的会话或笔记,直到数量大约减半,然后重新保存。虽然界面会发出存储警告,但删除前没有:
对于学习笔记和长期会话,这种自动清理可能造成不可恢复的数据损失。
建议改为:
3.11 Agent 与 Skills 的公开证据仍不够清楚
当前代码可以证明 AI 对话、截图提问和笔记生成真实存在,但主要流程仍是:
界面操作 → 固定提示词 → 模型调用 → 展示结果没有看到明确的:
建议把现有产品能力正式定义为可验证 Skills,例如:
capture_selection:获取文档选区;extract_document_context:提取原文和页码;answer_with_evidence:依据原文回答;continue_learning_thread:保持多轮学习上下文;generate_note:生成可追溯笔记;revisit_source:跳回原文;export_learning_record:导出学习记录。每个 Skill 都应公开输入、输出、错误状态和代表性执行轨迹。
3.12 缺少自动化测试和当前交付说明
公开镜像的
package.json提供了构建和 TypeScript 检查命令,但没有测试命令;仓库中也没有看到测试目录。建议至少补充以下自动化验证:
README 还需要同步当前 Electron 版本、实际依赖、安装包版本、截图和 Demo 验证路径。
4. 优先改进建议
建议优先处理以下事项:
contextWindow的问题,并增加多轮回归测试。建议提供一条固定演示链:
5. 综合评价
问渠已经具备较完整的桌面学习产品形态。文档阅读、截图提问、悬浮对话、模型配置、学科管理和笔记沉淀之间已经建立了实际连接,Electron 安全边界也经过了明显加固。
当前最需要解决的是“界面上连续”和“模型实际连续”之间的差异。正常 AI 回答没有进入下一轮上下文,会直接削弱追问和层层学习;截图式框选、AI 回答和笔记之间也还没有形成可核验的来源链。
完成多轮上下文修复、文档证据追溯、密钥安全存储、安装包更新和 Skills 证据化后,问渠才能更充分地证明其核心价值不是“文档旁边放一个聊天框”,而是一套能够持续追问、回到原文并沉淀可信学习成果的 AI 学习助手。
额,你说的是我这个项目嘛?怎么完全对不上啊,我没用Electron 啊,划词也不是截图
但是仍然感谢你的评价,我们会持续优化
之后会考虑推出本地桌面版,有信息安全的小伙伴可以考虑一下,但我更倾向于打造一个开放的知识共享平台