如何反馈

Tip

AI攥写，待完善

问题反馈的目标是让其他人可以按相同步骤观察故障，并判断它发生在音频、模型、网络、记录还是浏览器连接。先查阅常见问题，再搜索 GitHub Issues中的相同现象。

本页说明如何组织报告、取得诊断、检查隐私和跟进处理。反馈不要求上传真实会议，也不需要提交整套模型或应用数据目录。

一、选择反馈类型

类型	应说明什么	通常不需要
软件故障	复现步骤、预期与实际、版本及日志	整个磁盘截图或完整配置目录
文档错误	页面、错误段落、实际行为及来源	与该页面无关的长篇运行日志
模型建议	官方卡、格式、语言、许可证与使用场景	无法验证的性能宣传
功能建议	具体任务、现有方式的不足和期望行为	只写“优化一下”
安全与隐私问题	影响版本和最小必要信息	公开密钥或可直接利用的细节

一个报告尽量围绕一个问题。多个独立故障分别记录，避免后续讨论无法对应。

二、先做一次最小复现

1. 记录当前环境

记下桌面版本、Windows 版本与系统类型。涉及浏览器时还需浏览器和扩展版本，三个版本不能互相替代。

按问题记录识别服务、具体模型、翻译服务、API 格式、语言方向、音源类型、运行组件组合和实际计算设备。只写“用大模型”“用 GPU”不足以复现。

2. 缩小操作

用没有敏感内容的短语音复现，尽量移除不相关操作。每次只改一项配置，并记录是否改变现象。不要先重置全部设置，否则原问题可能无法定位。

浏览器问题给出站点和播放器类型，说明标签页声音还是系统音频、是否首次授权、是否发生暂停或跳转。音频问题说明两秒试听是否正常。

3. 对比预期和实际

写出可观察的结果。例如，“播放英语后有原文，但目标日语译文没有出现”，比“翻译坏了”更明确。能稳定重现、偶发或只发生一次也应说明。

三、复制诊断信息

出现错误时保留用户支持码和请求关联 ID。可以从错误反馈入口复制相关信息，或在“设置 → 更多 → 问题反馈”使用“复制诊断信息”。高级页提供引擎与诊断字段的只读查看。

复制内容用于关联 UI、IPC 与引擎中的同一次操作。若错误未进入引擎，可能没有引擎请求 ID，不要为了填满模板编造编号。

复制会写入系统剪贴板，不代表已发送给项目。粘贴到公开 Issue 前检查路径、设备名称、内部端点及其他个人信息。

四、取得本次启动日志

1. 找到正确文件

在“设置 → 更多 → 问题反馈”使用“打开日志目录”。每次启动生成一份当前 .jsonl，旧启动分别压缩为 .jsonl.gz，保留最近 10 次。软件不会把一次启动拆成多个按大小轮转文件。

复现后记录时间，并优先提供同一次启动日志。重新启动会产生新文件，不应只凭“最新文件”名称猜测旧故障记录。

2. 日志记录范围

日志记录应用操作、组件检查、引擎状态、采集阶段、网络错误和请求关联。原始音频、字幕、译文、密钥及携带这些内容的提示词被省略或脱敏。

设备 ID、名称、本地路径、异常堆栈、错误原因和进程输出仍可保留，因此日志不等于匿名材料。即使软件已有脱敏，也需人工检查后再分享。

3. 日志位置与数据位置不同

会议、模型和配置位于可迁移的数据根目录；启动日志位于 Electron 用户目录下的 logs。移动数据后不应按新的模型位置推断日志位置，优先使用软件入口定位。

不要为了找日志把 credentials.json、会议目录或浏览器配置一并打包。

五、截图与样例的隐私检查

截图应显示相关错误、设置名称和状态，去掉密钥、个人路径、真实会议文字、账户余额及不必要的桌面内容。若录屏包含系统通知和麦克风声音，也需要先检查。

材料	提交前检查
诊断文字	路径、设备名、内部域名、账户标识
JSONL／GZIP 日志	原始异常及进程输出中的个人信息
截图	密钥、会议字幕、其他应用窗口
音频	是否获准分享，是否含他人或敏感内容
API 请求	不含认证头、Token、原文提示词和私有 URL

优先使用可公开的合成短语音或自行朗读样例。没有必要时不提供真实音频。公开 Issue 的附件可能长期被访问，删除原帖不能保证已下载副本消失。

六、提交故障报告

复制以下模板，替换说明，无法取得的项写“未取得”并交代原因，不填虚构值：

问题标题：
[使用入口 + 具体失败，例如：系统音频试听正常，但本地识别启动失败]

版本与环境：
- 桌面版本：
- Windows 版本、系统类型：
- 浏览器版本（如适用）：
- 扩展版本（如适用）：

会话配置：
- 快速同传／悬浮字幕／浏览器字幕：
- 音源类型及两秒试听结果：
- 识别服务与具体模型：
- 翻译服务、模型及 API 格式：
- 原文与目标语言：
- 组件组合与实际设备：
- 是否使用未定稿翻译／备用翻译：

复现步骤：
1.
2.
3.

预期结果：
实际结果：
发生频率：
错误支持码／关联 ID：
发生时间及对应日志：
已尝试的单项修改和结果：
附件：[已检查的日志、截图或可公开样例]

不要直接把“已保存”或“检查密钥成功”作为远程连接有效的依据，报告中应说明真正调用时的结果。

七、文档与功能建议

文档错误给出页面链接、段落、实际界面或源码依据及希望改正的内容。能直接修正时可按如何贡献提交 Pull Request。

功能建议说明真实任务，例如“需要在两台显示器上保持不同字幕位置”，再说明现有操作为什么无法完成。对成本、数据、兼容性有要求时一并列出，不要求维护者从设计稿猜测使用场景。

模型建议提供官方仓库、模型卡、权重格式、语言证据和许可证。搜索到仓库、成功下载文件或他人宣传支持，都不足以证明本引擎可以加载。

八、泄露与安全问题

密钥泄露后，先在服务商处撤销并更换，再处理已公开内容。删除截图或 Issue 不能让已泄露的凭据失效。

漏洞报告优先使用仓库已提供的私密渠道（如果已启用）。没有确认私密入口时，不要先公开可利用步骤、用户资料或凭据；可以先提出不含敏感细节的联络请求。

项目不在本页虚构专用邮箱、处理时限或保密承诺。第三方账户和数据删除请求也需要向相应服务提出。

九、跟进报告

维护者可能要求补充版本、失败阶段或最小样例。尽量在原 Issue 中补充，说明新尝试是否改变现象，不为每次回复重复创建新报告。

问题消失时，记录使用版本、修改项和验证结果。无法再复现应如实说明，不把偶然恢复写成已确认根因。涉及新的独立问题，再单独提交。