Question 1

如何解决在 Windows 上从包含空格的路径启动程序时出现的 exec-server 错误 -32603“os error 123”（文件名语法无效）？

Accepted Answer

原因：在 `apps/desktop/src/main/remote-agent/controller/execServerRelay.ts` 中，`mapExecServerParams()` 对每个 argv 元素（包括 `argv[0]`）都调用了 `workspace.mapCommand()`。当虚拟程序目录映射到包含空格的 Windows 路径（例如 `C:\Program Files\PowerShell\7`）时，shell 引号会成为可执行文件名的一部分（例如 `"C:/Program Files/PowerShell/7"/pwsh.exe`）。由于在 `CreateProcess` 之前没有 shell 解析这些引号，Windows 会以 `ERROR_INVALID_NAME`（os error 123）拒绝该调用。修复：仅对 `argv[0]` 使用 `workspace.mapAlias()`，其余元素仍使用 `mapCommand()`：

```diff
- if (Array.isArray(result.argv)) result.argv = result.argv.map((part) => typeof part === 'string' ? workspace.mapCommand(part, resolveExecutorShell().dialect) : part);
+ if (Array.isArray(result.argv)) result.argv = result.argv.map((part, index) => {
+   if (typeof part !== 'string') return part;
+   return index === 0 ? workspace.mapAlias(part) : workspace.mapCommand(part, resolveExecutorShell().dialect);
+ });
```

这样只会映射已注册的别名，而原生路径、裸 PATH 名称和相对名称均保持不变。使用以下命令验证：`pnpm --dir apps/desktop exec vitest run src/main/remote-agent/__tests__/execServerProjection.e2e.test.ts --maxWorkers=1` 和 `pnpm --filter desktop run --if-present typecheck`。

Question 2

为什么在 Cindy 桌面应用中，不做任何更改就重新保存群组设置会触发 REVISION_CONFLICT 错误？

Accepted Answer

根本原因：在 `apps/desktop/src/renderer/features/bots/ChatGroupSettings.tsx` 中，`draftRevision` ref 仅在初始化时和首次编辑时（即进入 dirty 状态时）被设置。保存成功后，负责同步刷新后群组数据的 effect 会更新表单字段，但从不推进 `draftRevision`。因此，如果在未做任何编辑的情况下再次点击"保存"，请求仍会发送旧的 `expectedRevision`（例如发送 1 而不是 2），服务器可能会将其误报为配置冲突。

修复：在从更新后的群组数据同步表单数据的 `useEffect` 中，添加：
```ts
if (!dirty.current && typeof group.revision === 'number') draftRevision.current = group.revision;
```
并将 `group.revision` 添加到该 effect 的依赖数组中。这样仅在用户没有待处理编辑时才推进版本号，从而保留真正的并发编辑冲突保护。

验证：在 `__tests__/ChatGroupSettings.test.tsx` 中添加回归测试，覆盖以下场景：(1) 保存刷新 revision 后，第二次提交携带最新的 `expectedRevision`；(2) 当表单处于 dirty 状态时有外部更新到达，仍保留旧 revision，以确保真实冲突依然会触发。请勿移除 `expectedRevision` 校验——那样会失去对其他成员并发修改的防护。

Question 3

为什么带编号的文件在 Cindy 文件浏览器中排序错误（10 排在 2/3 之前），以及如何修复？

Accepted Answer

这是一个已知的 bug：文件树将名称按纯字符串排序，因此带编号的文件会显示为 `01, 02, 10…29, 3, 30`（并且 `chapter10` 排在 `chapter2` 之前）。该问题已由 PR #7069 修复：`packages/file-browser-core/src/scanner.ts` 中的共享扫描器现在使用 `Intl.Collator(undefined, { numeric: true })` 进行自然排序，保持目录排在最前，保留小写归一化和区域设置规则，并对数值相同的数字（`1`、`01`、`001`）回退到旧的文本比较。要获得此修复，请将 Cindy 更新到包含 PR #7069 的构建版本；对于 SSH 远程浏览，远程 file-service 包已从 0.2.6 升级到 0.2.7，因此旧的远程安装会自动升级并获得修正后的排序。

Question 4

为什么在 React Native 中进行语音录制时麦克风图标会变得不可见，尽管按钮仍然可以正常工作？

Accepted Answer

录音状态代码将图标颜色切换为专为纯色背景设计的反转文本颜色（例如 `colors.ctaText`），却未给 `Pressable` 设置背景，导致图标融入卡片表面（浅色主题下白底白图标，深色主题下近黑底黑图标），而点击区域、状态和无障碍标签仍然正常工作。修复位置为 `apps/mobile/src/session/InteractionPanel.tsx`（`AskCardVoiceButton`）：当 `listening=true` 时，为 `Pressable` 添加纯色胶囊背景——`backgroundColor: colors.cta` 和 `borderRadius: radius.pill`——并保持图标使用 `colors.ctaText`。替代方案：将录音状态的图标颜色改为前景色，例如 `colors.textPrimary`，而不是反转的 `ctaText`。添加一个回归测试，断言监听状态下的 `Pressable` 具有非透明的 `backgroundColor`，因为仅检查 testID/label/disabled 的测试无法捕获对比度失效问题。

Question 5

为什么在问题卡片（移动应用）上进行语音录制时麦克风图标不可见，该如何解决？

Accepted Answer

麦克风图标在录音状态下消失，是因为 `AskCardVoiceButton`（位于 `apps/mobile/src/session/InteractionPanel.tsx`）错误地将图标颜色设置为了 `colors.ctaText`。`ctaText` 是一种反转前景色（浅色模式下为白色 `#FFFFFF`，深色模式下为深色 `#121212`），仅设计用于实心 CTA 按钮背景。由于语音按钮在卡片颜色 `surfaceElevated`（浅色 `#FFFFFC` / 深色 `#1E1E1E`）之上使用透明背景，图标在浅色模式下变成了白底白图标，在深色模式下变成了深色底深色图标。

修复（PR #7078，关闭 #6778）：将录音状态下的图标颜色改为始终使用中性的 `colors.textSecondary`，而非 `colors.ctaText`。透明背景、44×44 触控区域、图标大小、启动期间的加载指示器以及开始/停止/提交行为均保持不变。`apps/mobile/src/__tests__/InteractionPanelReceipt.test.tsx` 中的回归测试覆盖了所有三个入口点（自由回答、自定义折叠、自定义展开）在浅色/深色主题下的录音可见性和停止恢复。

cindy

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐