【S3W3 交叉评测】问渠:多轮上下文、学习证据链与本地数据安全建议 #3

Open
opened 2026-08-06 14:33:48 +08:00 by Michael · 2 comments

1. 项目理解

我理解“问渠”是一款面向学生的桌面 AI 学习助手。

它将 PDF、Word、图片和文本阅读,与 AI 对话、截图提问、语音输入、悬浮窗、会话管理和学习笔记整合在一个 Electron 应用中。

学生可以一边查看学习资料,一边框选文档区域并向 AI 提问;对话结果还可以整理成知识重点、解题技巧或其他类型的笔记,并按照学科长期管理。

2. 项目亮点

  • 项目已经形成可安装的 Windows 桌面应用,不只是静态原型或概念页面。
  • 文档阅读、AI 对话、截图提问、悬浮窗、语音输入、会话和笔记形成了较完整的学习流程。
  • 支持用户配置多个 OpenAI 兼容服务和模型,降低了对单一模型供应商的依赖。
  • PDF、Word、图片和文本分别有独立查看组件,阅读和对话可以在同一界面完成。
  • 支持按学科管理会话和笔记,具备长期学习资料整理的产品基础。
  • AI 回答支持流式输出、思考内容和数学公式渲染,学习场景适配较好。
  • Electron 已启用沙箱、上下文隔离和 IPC 白名单,并对文件大小、文件类型、外部链接和可执行文件做了安全限制。
  • 项目已经发布 Windows 安装程序,评审和普通用户可以直接安装体验。

3. 当前问题和疑点

3.1 正常回答没有进入下一轮模型上下文

这是当前最影响核心学习体验的问题。

发送问题时,程序会先把用户消息加入 contextWindow,然后使用该窗口调用模型。

模型成功返回后,AI 回答只被加入页面展示使用的 messages,没有同步加入 contextWindow

因此可能出现:

  1. 用户提出问题 A;
  2. AI 返回回答 B;
  3. 用户针对 B 继续追问 C;
  4. 下一次模型调用收到 A 和 C,却没有收到 B。

用户界面看起来是连续对话,但模型看不到自己上一轮的完整回答,容易造成:

  • 不知道“刚才第二步”指什么;
  • 前后解释不一致;
  • 无法根据上一轮答案纠错;
  • 追问时重复回答;
  • “层层追溯”在多轮对话中失效。

停止生成的路径会把部分 AI 回答加入 contextWindow,正常完成路径却没有加入,两条路径行为也不一致。

建议在成功生成后同时更新:

  • messages
  • contextWindow
  • 持久化状态。

并增加回归测试,明确验证第二轮请求同时包含:

  • 第一轮用户问题;
  • 第一轮 AI 回答;
  • 第二轮用户追问。

3.2 多张截图只在当前请求中完整存在

输入区最多允许添加多张截图,当前请求会把这些截图全部发给模型。

但用户消息结构只保存一个 screenshotData,实际只记录第一张截图。后续追问或重新加载会话时,其余截图不会进入上下文。

如果用户一次框选一道题的题干、图表和选项,第一轮模型可以看到全部图片,但下一轮可能只保留第一张。

建议将消息结构改为:

screenshotData: string[]

并确保:

  • 当前调用;
  • 后续追问;
  • 本地持久化;
  • 会话恢复;
  • 笔记溯源

都使用同一组附件。

3.3 “划词即问”目前实际是框选截图

当前实现不是选中文本后直接提问,而是截取屏幕区域,将截图交给视觉模型。

这种方式的优点是可以覆盖扫描版 PDF、公式、图表和图片,但也意味着:

  • 无法获得原始文本;
  • 无法标记 PDF 页码;
  • 无法记录具体段落;
  • 无法复制引用原文;
  • 无法证明回答依据来自哪个位置;
  • 视觉模型可能出现 OCR 识别错误。

建议区分两个能力:

  1. 文本划词提问:保存选中文本、文档名、页码和段落位置;
  2. 图像框选提问:保存截图、页码和选区坐标。

界面名称也可以从统一的“划词”调整为“划词 / 框选提问”,避免功能描述与实际行为不一致。

3.4 尚未形成“层层追溯”的学习证据链

当前回答主要来自通用系统提示词和对话上下文,没有看到文档切块、检索、页码引用、原文证据或答案来源链。

建议每次基于文档的提问都生成一组来源信息:

  • 文档 ID 和文件名;
  • 页码;
  • 选中文本或截图;
  • 选区位置;
  • 原文摘要或哈希;
  • 对应的用户问题;
  • AI 回答;
  • 模型和配置;
  • 生成时间。

用户点击回答中的来源标记后,应能够直接跳回文档对应位置。

这样“层层追溯”才能从连续聊天升级为:

问题 → 回答 → 原文证据 → 文档位置 → 后续追问

3.5 AI 笔记没有保存来源和生成依据

当前笔记结构只保存:

  • 标题;
  • 正文;
  • 学科;
  • 分类;
  • 章节;
  • 创建和更新时间。

笔记是根据“学生问题 + AI 回答”再次调用模型生成的,但没有保存:

  • 来源文档;
  • 页码和选区;
  • 原始对话消息 ID;
  • 生成模型;
  • 引用内容;
  • 用户是否人工确认;
  • 后续内容是否被重新生成。

如果上一轮 AI 回答存在错误,错误内容可能被再次总结并沉淀为长期“知识重点”。

建议为笔记增加来源字段,并在保存前展示:

  • 原始问题;
  • AI 回答;
  • 文档证据;
  • 生成后的笔记;
  • 用户确认或修改记录。

笔记页面还应支持“一键回到原文”和“一键回到原对话”。

3.6 API Key、会话和笔记均以明文保存在 localStorage

当前设置状态会把完整 apiConfigs 写入 localStorage,其中包含 API Key。

会话、截图和笔记也分别保存在浏览器式本地存储中。

这虽然实现了本地保存,但不能等同于安全存储。渲染进程注入、本地应用数据目录泄露或同一系统账户下的其他程序,都可能读取这些内容。

建议:

  • API Key 使用 Electron safeStorage 或操作系统凭据库保存;
  • 渲染进程只持有短期凭据或配置引用;
  • 会话和笔记使用应用数据目录下的数据库或文件;
  • 敏感学习资料支持加密;
  • 提供全部数据导出、备份和删除;
  • 在设置页明确展示本地保存位置和隐私边界。

3.7 非 HTTPS API 地址只警告但仍继续发送

程序发现外部 API 地址不是 HTTPS 时,只会输出日志警告,随后仍然发送:

  • API Key;
  • 对话内容;
  • 截图;
  • 语音;
  • 学习资料摘要。

如果用户误填普通 HTTP 地址,密钥和学习内容可能被明文传输。

建议:

  • localhost127.0.0.1 外,默认拒绝 HTTP;
  • 用户确需使用局域网 HTTP 服务时,必须进行显式风险确认;
  • 设置页显示本次调用将发送哪些数据;
  • 对自定义服务商展示域名、协议和隐私提示;
  • 提供“仅本地模型”模式。

3.8 麦克风权限配置与语音输入功能冲突

语音输入使用 navigator.mediaDevices.getUserMedia({ audio: true }) 请求麦克风。

但 Electron 主进程当前会拒绝所有权限请求,包括麦克风。

因此按照当前代码路径,打包后的桌面应用可能无法正常获得录音权限。

建议:

  • 只允许可信主窗口申请 media 权限;
  • 仅在用户主动点击录音按钮后授权;
  • 对其他窗口和权限继续默认拒绝;
  • 增加一次真实安装包的麦克风端到端测试;
  • 明确测试 Windows 首次授权、拒绝后重试和无麦克风设备等情况。

3.9 最新安装包未覆盖后续安全加固

公开的 v1.0.1 Windows 安装包早于后续的全面安全审计提交。

后续源码已经增加:

  • Electron 沙箱;
  • IPC 速率限制;
  • 文件扩展名白名单;
  • 可执行文件拦截;
  • IPC 参数大小限制;
  • CSP;
  • DOMPurify 加固;
  • Electron 版本升级。

但目前公开下载的 v1.0.1 安装包无法证明包含这些后续修复。

建议发布新的安装包,并明确记录:

  • 版本号;
  • 对应 Commit;
  • 构建时间;
  • SHA-256;
  • 安全修复清单;
  • 构建环境;
  • 自动化测试结果。

评审和用户才能确认下载到的二进制与当前源码一致。

3.10 存储不足时会自动删除一半旧数据

localStorage 空间不足时,程序会自动删除较早的会话或笔记,直到数量大约减半,然后重新保存。

虽然界面会发出存储警告,但删除前没有:

  • 用户确认;
  • 自动备份;
  • 导出机会;
  • 恢复站;
  • 明确列出将被删除的数据。

对于学习笔记和长期会话,这种自动清理可能造成不可恢复的数据损失。

建议改为:

  1. 停止继续写入;
  2. 明确提示空间不足;
  3. 允许用户导出;
  4. 展示占用空间最大的项目;
  5. 用户确认后再清理;
  6. 提供回收站或临时备份。

3.11 Agent 与 Skills 的公开证据仍不够清楚

当前代码可以证明 AI 对话、截图提问和笔记生成真实存在,但主要流程仍是:

界面操作 → 固定提示词 → 模型调用 → 展示结果

没有看到明确的:

  • Agent 状态机;
  • Skill 注册表;
  • Skill 输入输出契约;
  • 模型自主选择工具;
  • 工具调用结果;
  • 执行轨迹;
  • 失败恢复;
  • 评测用固定任务。

建议把现有产品能力正式定义为可验证 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 检查命令,但没有测试命令;仓库中也没有看到测试目录。

建议至少补充以下自动化验证:

  • 正常多轮对话完整保留用户和 AI 上下文;
  • 停止后追问与正常完成后追问行为一致;
  • 多张截图可以在后续对话恢复;
  • 麦克风权限在安装包中真实可用;
  • API Key 不进入 localStorage;
  • 非 HTTPS 外部地址被阻止;
  • 文档选区能够跳回原页;
  • 笔记保留来源;
  • 存储不足不会未经确认删除数据;
  • Markdown、公式和外部内容无法绕过安全清洗。

README 还需要同步当前 Electron 版本、实际依赖、安装包版本、截图和 Demo 验证路径。

4. 优先改进建议

建议优先处理以下事项:

  1. 修复正常回答未写入 contextWindow 的问题,并增加多轮回归测试。
  2. 将多截图消息改为数组结构,保证后续追问和恢复时附件完整。
  3. 建立文档、选区、回答和笔记之间的来源追溯链。
  4. 使用 Electron 安全存储保存 API Key,并限制非 HTTPS 外部服务。
  5. 修复麦克风权限与语音输入的冲突。
  6. 发布包含最新安全加固的新安装包,并绑定精确 Commit 和校验值。
  7. 将存储溢出处理改为用户确认、导出和可恢复的清理流程。
  8. 将现有功能整理成明确的 Agent Skills 和可观察执行轨迹。
  9. 补充端到端测试、应用截图和固定 Demo 验证案例。

建议提供一条固定演示链:

  1. 打开一份带页码的 PDF;
  2. 选中一段原文或框选一道题;
  3. 向 AI 提问;
  4. 回答展示页码和原文依据;
  5. 用户连续追问两轮;
  6. 每轮都能看到完整上下文;
  7. 将结果生成笔记;
  8. 从笔记跳回原文和原对话;
  9. 关闭并重新打开应用;
  10. 会话、来源和笔记关系仍能恢复。

5. 综合评价

问渠已经具备较完整的桌面学习产品形态。文档阅读、截图提问、悬浮对话、模型配置、学科管理和笔记沉淀之间已经建立了实际连接,Electron 安全边界也经过了明显加固。

当前最需要解决的是“界面上连续”和“模型实际连续”之间的差异。正常 AI 回答没有进入下一轮上下文,会直接削弱追问和层层学习;截图式框选、AI 回答和笔记之间也还没有形成可核验的来源链。

完成多轮上下文修复、文档证据追溯、密钥安全存储、安装包更新和 Skills 证据化后,问渠才能更充分地证明其核心价值不是“文档旁边放一个聊天框”,而是一套能够持续追问、回到原文并沉淀可信学习成果的 AI 学习助手。

## 1. 项目理解 我理解“问渠”是一款面向学生的桌面 AI 学习助手。 它将 PDF、Word、图片和文本阅读,与 AI 对话、截图提问、语音输入、悬浮窗、会话管理和学习笔记整合在一个 Electron 应用中。 学生可以一边查看学习资料,一边框选文档区域并向 AI 提问;对话结果还可以整理成知识重点、解题技巧或其他类型的笔记,并按照学科长期管理。 ## 2. 项目亮点 - 项目已经形成可安装的 Windows 桌面应用,不只是静态原型或概念页面。 - 文档阅读、AI 对话、截图提问、悬浮窗、语音输入、会话和笔记形成了较完整的学习流程。 - 支持用户配置多个 OpenAI 兼容服务和模型,降低了对单一模型供应商的依赖。 - PDF、Word、图片和文本分别有独立查看组件,阅读和对话可以在同一界面完成。 - 支持按学科管理会话和笔记,具备长期学习资料整理的产品基础。 - AI 回答支持流式输出、思考内容和数学公式渲染,学习场景适配较好。 - Electron 已启用沙箱、上下文隔离和 IPC 白名单,并对文件大小、文件类型、外部链接和可执行文件做了安全限制。 - 项目已经发布 Windows 安装程序,评审和普通用户可以直接安装体验。 ## 3. 当前问题和疑点 ### 3.1 正常回答没有进入下一轮模型上下文 这是当前最影响核心学习体验的问题。 发送问题时,程序会先把用户消息加入 `contextWindow`,然后使用该窗口调用模型。 模型成功返回后,AI 回答只被加入页面展示使用的 `messages`,没有同步加入 `contextWindow`。 因此可能出现: 1. 用户提出问题 A; 2. AI 返回回答 B; 3. 用户针对 B 继续追问 C; 4. 下一次模型调用收到 A 和 C,却没有收到 B。 用户界面看起来是连续对话,但模型看不到自己上一轮的完整回答,容易造成: - 不知道“刚才第二步”指什么; - 前后解释不一致; - 无法根据上一轮答案纠错; - 追问时重复回答; - “层层追溯”在多轮对话中失效。 停止生成的路径会把部分 AI 回答加入 `contextWindow`,正常完成路径却没有加入,两条路径行为也不一致。 建议在成功生成后同时更新: - `messages`; - `contextWindow`; - 持久化状态。 并增加回归测试,明确验证第二轮请求同时包含: - 第一轮用户问题; - 第一轮 AI 回答; - 第二轮用户追问。 ### 3.2 多张截图只在当前请求中完整存在 输入区最多允许添加多张截图,当前请求会把这些截图全部发给模型。 但用户消息结构只保存一个 `screenshotData`,实际只记录第一张截图。后续追问或重新加载会话时,其余截图不会进入上下文。 如果用户一次框选一道题的题干、图表和选项,第一轮模型可以看到全部图片,但下一轮可能只保留第一张。 建议将消息结构改为: `screenshotData: string[]` 并确保: - 当前调用; - 后续追问; - 本地持久化; - 会话恢复; - 笔记溯源 都使用同一组附件。 ### 3.3 “划词即问”目前实际是框选截图 当前实现不是选中文本后直接提问,而是截取屏幕区域,将截图交给视觉模型。 这种方式的优点是可以覆盖扫描版 PDF、公式、图表和图片,但也意味着: - 无法获得原始文本; - 无法标记 PDF 页码; - 无法记录具体段落; - 无法复制引用原文; - 无法证明回答依据来自哪个位置; - 视觉模型可能出现 OCR 识别错误。 建议区分两个能力: 1. 文本划词提问:保存选中文本、文档名、页码和段落位置; 2. 图像框选提问:保存截图、页码和选区坐标。 界面名称也可以从统一的“划词”调整为“划词 / 框选提问”,避免功能描述与实际行为不一致。 ### 3.4 尚未形成“层层追溯”的学习证据链 当前回答主要来自通用系统提示词和对话上下文,没有看到文档切块、检索、页码引用、原文证据或答案来源链。 建议每次基于文档的提问都生成一组来源信息: - 文档 ID 和文件名; - 页码; - 选中文本或截图; - 选区位置; - 原文摘要或哈希; - 对应的用户问题; - AI 回答; - 模型和配置; - 生成时间。 用户点击回答中的来源标记后,应能够直接跳回文档对应位置。 这样“层层追溯”才能从连续聊天升级为: `问题 → 回答 → 原文证据 → 文档位置 → 后续追问` ### 3.5 AI 笔记没有保存来源和生成依据 当前笔记结构只保存: - 标题; - 正文; - 学科; - 分类; - 章节; - 创建和更新时间。 笔记是根据“学生问题 + AI 回答”再次调用模型生成的,但没有保存: - 来源文档; - 页码和选区; - 原始对话消息 ID; - 生成模型; - 引用内容; - 用户是否人工确认; - 后续内容是否被重新生成。 如果上一轮 AI 回答存在错误,错误内容可能被再次总结并沉淀为长期“知识重点”。 建议为笔记增加来源字段,并在保存前展示: - 原始问题; - AI 回答; - 文档证据; - 生成后的笔记; - 用户确认或修改记录。 笔记页面还应支持“一键回到原文”和“一键回到原对话”。 ### 3.6 API Key、会话和笔记均以明文保存在 localStorage 当前设置状态会把完整 `apiConfigs` 写入 `localStorage`,其中包含 API Key。 会话、截图和笔记也分别保存在浏览器式本地存储中。 这虽然实现了本地保存,但不能等同于安全存储。渲染进程注入、本地应用数据目录泄露或同一系统账户下的其他程序,都可能读取这些内容。 建议: - API Key 使用 Electron `safeStorage` 或操作系统凭据库保存; - 渲染进程只持有短期凭据或配置引用; - 会话和笔记使用应用数据目录下的数据库或文件; - 敏感学习资料支持加密; - 提供全部数据导出、备份和删除; - 在设置页明确展示本地保存位置和隐私边界。 ### 3.7 非 HTTPS API 地址只警告但仍继续发送 程序发现外部 API 地址不是 HTTPS 时,只会输出日志警告,随后仍然发送: - API Key; - 对话内容; - 截图; - 语音; - 学习资料摘要。 如果用户误填普通 HTTP 地址,密钥和学习内容可能被明文传输。 建议: - 除 `localhost` 和 `127.0.0.1` 外,默认拒绝 HTTP; - 用户确需使用局域网 HTTP 服务时,必须进行显式风险确认; - 设置页显示本次调用将发送哪些数据; - 对自定义服务商展示域名、协议和隐私提示; - 提供“仅本地模型”模式。 ### 3.8 麦克风权限配置与语音输入功能冲突 语音输入使用 `navigator.mediaDevices.getUserMedia({ audio: true })` 请求麦克风。 但 Electron 主进程当前会拒绝所有权限请求,包括麦克风。 因此按照当前代码路径,打包后的桌面应用可能无法正常获得录音权限。 建议: - 只允许可信主窗口申请 `media` 权限; - 仅在用户主动点击录音按钮后授权; - 对其他窗口和权限继续默认拒绝; - 增加一次真实安装包的麦克风端到端测试; - 明确测试 Windows 首次授权、拒绝后重试和无麦克风设备等情况。 ### 3.9 最新安装包未覆盖后续安全加固 公开的 v1.0.1 Windows 安装包早于后续的全面安全审计提交。 后续源码已经增加: - Electron 沙箱; - IPC 速率限制; - 文件扩展名白名单; - 可执行文件拦截; - IPC 参数大小限制; - CSP; - DOMPurify 加固; - Electron 版本升级。 但目前公开下载的 v1.0.1 安装包无法证明包含这些后续修复。 建议发布新的安装包,并明确记录: - 版本号; - 对应 Commit; - 构建时间; - SHA-256; - 安全修复清单; - 构建环境; - 自动化测试结果。 评审和用户才能确认下载到的二进制与当前源码一致。 ### 3.10 存储不足时会自动删除一半旧数据 当 `localStorage` 空间不足时,程序会自动删除较早的会话或笔记,直到数量大约减半,然后重新保存。 虽然界面会发出存储警告,但删除前没有: - 用户确认; - 自动备份; - 导出机会; - 恢复站; - 明确列出将被删除的数据。 对于学习笔记和长期会话,这种自动清理可能造成不可恢复的数据损失。 建议改为: 1. 停止继续写入; 2. 明确提示空间不足; 3. 允许用户导出; 4. 展示占用空间最大的项目; 5. 用户确认后再清理; 6. 提供回收站或临时备份。 ### 3.11 Agent 与 Skills 的公开证据仍不够清楚 当前代码可以证明 AI 对话、截图提问和笔记生成真实存在,但主要流程仍是: `界面操作 → 固定提示词 → 模型调用 → 展示结果` 没有看到明确的: - Agent 状态机; - Skill 注册表; - Skill 输入输出契约; - 模型自主选择工具; - 工具调用结果; - 执行轨迹; - 失败恢复; - 评测用固定任务。 建议把现有产品能力正式定义为可验证 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 检查命令,但没有测试命令;仓库中也没有看到测试目录。 建议至少补充以下自动化验证: - 正常多轮对话完整保留用户和 AI 上下文; - 停止后追问与正常完成后追问行为一致; - 多张截图可以在后续对话恢复; - 麦克风权限在安装包中真实可用; - API Key 不进入 localStorage; - 非 HTTPS 外部地址被阻止; - 文档选区能够跳回原页; - 笔记保留来源; - 存储不足不会未经确认删除数据; - Markdown、公式和外部内容无法绕过安全清洗。 README 还需要同步当前 Electron 版本、实际依赖、安装包版本、截图和 Demo 验证路径。 ## 4. 优先改进建议 建议优先处理以下事项: 1. 修复正常回答未写入 `contextWindow` 的问题,并增加多轮回归测试。 2. 将多截图消息改为数组结构,保证后续追问和恢复时附件完整。 3. 建立文档、选区、回答和笔记之间的来源追溯链。 4. 使用 Electron 安全存储保存 API Key,并限制非 HTTPS 外部服务。 5. 修复麦克风权限与语音输入的冲突。 6. 发布包含最新安全加固的新安装包,并绑定精确 Commit 和校验值。 7. 将存储溢出处理改为用户确认、导出和可恢复的清理流程。 8. 将现有功能整理成明确的 Agent Skills 和可观察执行轨迹。 9. 补充端到端测试、应用截图和固定 Demo 验证案例。 建议提供一条固定演示链: 1. 打开一份带页码的 PDF; 2. 选中一段原文或框选一道题; 3. 向 AI 提问; 4. 回答展示页码和原文依据; 5. 用户连续追问两轮; 6. 每轮都能看到完整上下文; 7. 将结果生成笔记; 8. 从笔记跳回原文和原对话; 9. 关闭并重新打开应用; 10. 会话、来源和笔记关系仍能恢复。 ## 5. 综合评价 问渠已经具备较完整的桌面学习产品形态。文档阅读、截图提问、悬浮对话、模型配置、学科管理和笔记沉淀之间已经建立了实际连接,Electron 安全边界也经过了明显加固。 当前最需要解决的是“界面上连续”和“模型实际连续”之间的差异。正常 AI 回答没有进入下一轮上下文,会直接削弱追问和层层学习;截图式框选、AI 回答和笔记之间也还没有形成可核验的来源链。 完成多轮上下文修复、文档证据追溯、密钥安全存储、安装包更新和 Skills 证据化后,问渠才能更充分地证明其核心价值不是“文档旁边放一个聊天框”,而是一套能够持续追问、回到原文并沉淀可信学习成果的 AI 学习助手。
Owner

额,你说的是我这个项目嘛?怎么完全对不上啊,我没用Electron 啊,划词也不是截图
但是仍然感谢你的评价,我们会持续优化

额,你说的是我这个项目嘛?怎么完全对不上啊,我没用Electron 啊,划词也不是截图 但是仍然感谢你的评价,我们会持续优化
Owner

之后会考虑推出本地桌面版,有信息安全的小伙伴可以考虑一下,但我更倾向于打造一个开放的知识共享平台

之后会考虑推出本地桌面版,有信息安全的小伙伴可以考虑一下,但我更倾向于打造一个开放的知识共享平台
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
panic/Ascend#3
No description provided.