feat(desktop): add voice notifications to shell ball#557
Conversation
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
![fennoai[bot]](https://avatars.githubusercontent.com/in/1924301?s=60&v=4){kind=small}
|
@xgopilot 用简单易懂的方式详细跟我解释 #557 (comment) 和 #557 (comment) 提出的问题 （“一定要最合理的判断，review提到的问题不是都要修改的，可能问题已经解决了，也可能会没问题就乱找问题”）。这些问题的严重性，需要修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响 |
结论这两条 review 目前都不是“乱找问题”，而且在当前 PR 代码里都还没有被后续修改解决。 我先给最直接的判断：
它们都不会导致任务主链路坏掉，也不会导致数据错乱，但会直接影响“语音通知这个功能本身是否真的按设置工作”。 问题 1位置： 这个问题在说什么：
也就是说，后两种正式通知明明是中文播报场景，代码却还在优先找日语女声。 为什么这会出问题：
这不是理论问题，是当前代码按分数算出来就可能发生的行为。 需要修改的原因： 修改后可能出现的现象： 如果不修改，具体影响是：
所以这条我认为应该改，不属于可改可不改的那种。 问题 2位置： 这个问题在说什么： 当前代码是：
这意味着什么： 需要修改的原因： 修改后可能出现的现象：
也可能带来一个副作用： 如果不修改，具体影响是：
所以这条我认为也应该改，但严重性比第一条低一些，因为它不是每次必现，也不是所有通知都会错。 哪个更值得优先处理如果只能先修一个，我建议先修第 1 条。 原因很简单：
最合理的总判断这次 review 的两条意见都成立，而且当前 PR 里看不出已经被解决。 更具体地说：
这次只做了分析，没有改代码。 |
|
@xgopilot 对 #557 (comment) 和 #557 (comment) 问题进行相应的判断是否选择修改，结合 #557 (comment) （“一定要最合理的判断，review提到的问题不是都要修改的，可能问题已经解决了，也可能会没问题就乱找问题”）。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，第一问题就采用“直接用中文的，不要用日文的”，接着我希望对于系统语音播报服务再多一些，特别是适合实机演示时容易触发的地方。 以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
结论这次我判断两条被点名的 review 都应该改，而且都不是只改文档就能收口。
我改了什么
为什么这么改
修改后可能出现的现象
如果不改的具体影响
其他检查结果
|
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot 现在这个PR有实现了什么想要的效果 |
这次 PR 实现的效果现在这个 PR 带来的主要是“桌面端 shell-ball 本地语音提示真正接通了”，不是新增任务能力，也不是新增后端 TTS。 用户实际能感知到的效果有：
这次实现的边界也比较明确：
补充一句，PR 里还加了 contract test，专门校验了启动问候、非 |
|
@xgopilot 现在还有其他会影响实机演示的问题吗。 |
结论有，当前我还看到 2 个会直接影响实机演示稳定性的剩余问题。它们都不是 task 主链路阻断，但都很容易在现场被看出来。 Findings
判断除了上面两条，我这次没有再看到别的明显“会直接打坏演示”的新增问题。现在更像是“演示时容易暴露的本地播报去重策略问题”，不是协议、任务状态或正式通知链路的问题。 残余风险当前环境仍然没法跑 |
|
@xgopilot 对 #557 (comment) 问题进行相应的判断是否选择修改 （“一定要最合理的判断，review提到的问题不是都要修改的，可能问题已经解决了，也可能会没问题就乱找问题”）。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
结论这次提到的 我已经按最小且合理的方式修掉，并顺手检查了相关文件里同类的语音去重逻辑，没有再发现同类遗漏。这个修复不需要再扩文档，因为语音通知的能力范围没有变化，改的是演示时的去重稳定性。 修改了什么
已提交并推送到当前 PR 分支，commit: 为什么改
修改后可能出现的现象
如果不修改的具体影响
文档判断这次不需要继续改文档。 原因很简单：控制面板和 最后核查
还有没有其他问题这次我没有在相关文件里再看到同类、且会直接影响实机演示的新增问题。剩余风险主要是前端依赖没装、当前 TypeScript 版本又比仓库配置更严，所以完整的 |
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot 现在还有其他会影响实机演示的问题吗。 |
结论还有 1 个我认为会影响实机演示稳定性的剩余问题，位置在语音服务的异步播放时序上。除此之外，这次改动里我没有再看到别的同等级演示阻断点。 Findings
判断这条我建议改代码，不是改文档能解决的问题。比较合理的修法是给每次播报加一个递增 request id， 其他说明当前环境仍然没法补跑 |
|
@xgopilot 对 #557 (comment) 问题进行相应的判断是否选择修改（“一定要最合理的判断，review提到的问题不是都要修改的，可能问题已经解决了，也可能会没问题就乱找问题”）。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
结论这次我判断 原因很直接：问题出在 我修改了什么
为什么这么改
修改后可能出现的现象
如果不修改的具体影响
其他检查结果
这三项在当前环境都无法执行，原因是 |
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot 现在还有其他会影响实机演示的问题吗。 |
结论按当前分支重新复查后，我没有再看到新的、会明显影响这次实机演示的代码级问题。 前面提过的几处演示风险，现在都已经在当前 PR 里收住了：
当前判断如果这次演示重点是：
那以现在这版代码来看，我没有再发现新的明显阻断点。 还需要注意的边界我这次没法把下面三项真正跑起来，所以这部分仍然只能算残余验证风险，不是我在代码里已经确认存在的问题：
所以最稳妥的说法是： |
|
@xgopilot 现在重新具体告诉我该怎么本地测试这个PR是否有实现预计的想要的所有效果 |
最省事的本地测试方法如果你要验证“这个 PR 是否把预期的桌面本地语音通知完整接通了”，不要一上来全量乱点，按下面顺序测最稳。 先准备环境先在仓库根目录执行： pnpm install
pnpm dev:service保持第一个终端别关。 pnpm --dir apps/desktop exec tauri dev如果你还没配模型，再去控制面板的“模型与安全”里先配一个可用模型并保存。否则你只能验证“启动 / 选中 / 剪贴板”这 3 条本地播报，没法完整测 先跑静态检查本地先跑这 4 个命令，确认不是基础构建就已经坏了： git diff origin/main...HEAD --check
pnpm --dir apps/desktop typecheck
pnpm --dir apps/desktop lint
pnpm --dir apps/desktop test:shell-ball这一步主要验证这次改动相关的桌面 contract 和类型没有漂。 再做 8 个手工场景
额外补 2 个边缘检查
你最后应该得到的结论如果这个 PR 达到预期，你本地应该看到的是：
这次我只做了分析，没有改代码。 |
|
@xgopilot 设置面板的通用的“语音控制”关闭后，选中文字时还是会有语音。对这个问题进行相应的判断选择修改。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，同时我希望在单独点击悬浮球（没有任何事件时），悬浮球也可以发出“CialloClaw”的声音，然后我希望换个小女孩的声线。以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
处理结果已按“代码 + 文档”一起收口，并推到当前 PR 分支，commit: 修改了什么
为什么这样改
修改后可能出现的现象
如果不修改的具体影响
额外检查这次把相关文件里同类语音触发点、去重逻辑和控制面板提示又过了一遍；在当前改动范围内，没有再看到同级别、需要这次一起继续扩散处理的同类问题。 验证
|
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot 现在重新具体告诉我该怎么本地测试这个PR是否有实现预计的想要的所有效果 |
本地测试怎么做这次 PR 的目标不是新增后端能力，而是把已有桌面设置真正接到本地
先准备环境建议在 Windows 上测，因为这条链路依赖桌面端 Tauri 运行时，而且选中文本承接本身就带 Windows 宿主侧采集语义。 先确保本机有：
从仓库根目录启动桌面端，优先用： corepack pnpm install
corepack pnpm --dir apps/desktop exec tauri dev如果你的本地脚本更习惯直接在 可选自动检查： corepack pnpm --dir apps/desktop typecheck
corepack pnpm --dir apps/desktop lint
corepack pnpm --dir apps/desktop test:shell-ball先做设置面板校验先打开控制面板，在“通用设置 > 系统行为”里检查这两个项：
这里先做两轮：
注意：这条 PR 的设置语义是“保存后才同步到悬浮球等其他窗口”，不是面板里一改立刻生效，文档也这样写了，见 control-panel-settings.md。 六个正向触发点逐个测1. 启动问候重启桌面端或重新拉起悬浮球窗口。 预期：
额外要看：
2. 空闲单击悬浮球确保悬浮球处于真正空闲态：
然后单击悬浮球一次。 预期：
3. 选中文本提醒在浏览器、编辑器或任意支持宿主选区采集的窗口里选中一段非空文本。 预期：
建议额外测两次：
4. 剪贴板提醒复制一段非空文本。 预期：
5.
|
|
@xgopilot 如图片所示的设置面板的提示声线不能切换多种，请提供按钮来选择。然后默认声线完全不像小女孩，继续细化。关于空闲单击悬浮球喊“Ciallo”的触发条件变成“选中文本时，悬浮球会弹出提醒气泡，当用户点击这个气泡时，悬浮球喊“Ciallo”“，注意：只是触发条件变了，提醒气泡是已经有的实现，不要另外实现。 对 以上问题进行相应修改。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
Result已按这次评论的要求直接修改代码，并同步更新了测试与文档；不是只改说明文档收口。修改已推送到当前 PR 分支，commit: What Changed
Why This Needed To Change
Expected Behavior After The Change
If This Were Not Changed
Verification
Additional Check这次顺手再查了一遍相关文件，没有再看到同类的旧触发残留：旧的空闲点击 |
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot ”检测到选中文本“和”检测到剪贴板内容”这些内容太死板单调了，体现不出CialloClaw的活泼可爱特点，换个文本，然后我希望同个操作，触发的语音文本有五种，每次随机触发一种。 对以上问题进行相应修改。如果需要是修改代码还是选择修改文档，还是都要修改。如果决定修改，以最合理的方式修改,不要做向下兼容从而过拟合。然后再详细检查相关文件的内容是否还有类似的问题，要求一次性解决完，最后核查一遍，修改后直接告诉我修改了什么、修改的原因、修改后的可能出现的现象以及如果不修改所带来的具体影响。然后再查看是否还有其他问题。 |
完成情况这次我判断需要改代码，而且需要连同测试和设置文档一起改；只改文案说明收不住，因为问题本身就在桌面端本地播报实现里。修改已经提交并推送到当前 PR 分支，commit: 修改了什么
为什么这么改
修改后可能出现的现象
如果不修改的具体影响
其他检查结果
|
Generated with [codeagent](https://github.com/qbox/codeagent) Co-authored-by: Blackcloudss <161042579+Blackcloudss@users.noreply.github.com>
|
@xgopilot 现在重新具体告诉我这个PR怎么实现预计的想要的所有效果 |
这个 PR 是怎么把“预期效果”真正做出来的这次我重新按当前分支代码核对了一遍。它做的事情可以概括成一句话：不新增后端 RPC、不新增 TTS 服务，而是在桌面端把已有设置、已有 shell-ball 本地入口、已有正式通知，统一接到本地 1. 设置先变成真正可消费的正式输入第一步不是先播报，而是先把“用户改的设置”变成稳定输入。
这一步解决的是：用户在控制面板里开的开关、选的声线，后面确实会被播报服务读取，而不是只停留在 UI。 2. 新增一个桌面本地语音服务，统一负责播什么、用什么声线、什么时候播核心实现都在 它做了 4 件关键事：
也就是说，这个 PR 不是把 3. shell-ball 本地入口被接到这个服务上了用户在桌面上最容易感知到的几个入口，现在都已经接上本地语音了。
这里的重点是：语音只是附着在现有 shell-ball 本地交互上，没有改任务协议，也没有发明新的正式对象。 4. 正式通知链路也被接上了，但只消费合适的那一部分除了本地入口，这个 PR 还把正式任务通知接进来了，但边界收得比较克制。
这个判断很关键。它避免了“所有结果都念一遍”的噪音，同时保留了真正需要用户注意的正式交付提醒。 5. 文档和测试也跟着收口了，所以这不是只改代码表面这次不是“代码偷偷变了，文档没跟上”。
用户最终能看到的效果如果只站在实机演示角度看，这个 PR 现在实现的是这些效果：
它没有做什么为了避免把范围说大，这个 PR 没有 做下面这些事：
当前还没做的事这次我只做了分析，没有改代码，也没有补跑新的命令。当前环境里仍然看不到 |
3 participants
Requested by @Blackcloudss
This PR wires the existing desktop voice settings into real local playback without introducing new backend RPCs or TTS services.
Summary
approval.pending, and non-bubbledelivery.readyVerification
git diff --checkpnpm --dir apps/desktop typecheckcould not run becausepnpmis unavailable in this workspacepnpm --dir apps/desktop lintcould not run becausepnpmis unavailable in this workspacepnpm --dir apps/desktop test:shell-ballcould not run becausepnpmis unavailable in this workspace