Skip to content

兼容性与注意事项

ADHDev 提供了广泛的内置提供方清单,但兼容性仍应保守看待。本页是你在依赖某个特定工作流之前设定预期的最快方式。

清单在先,验证在后

请遵循以下经验法则:

  • 内置意味着该提供方存在于随附的清单中。
  • 已验证意味着该提供方已被手动测试并提升。
  • 在某个提供方被提升之前,即使它出现在启动器、文档或能力页面中,也请将其视为未验证。

重新验证进行中

验证状态目前正处于全面重新验证阶段(所有者决定,2026-08-03)。在有新的验证证据之前,所有提供方均为「未验证」—— 在选择起点之前,请到支持的提供方查看当前状态。

实用的起点

提供方的选择目前应基于哪个类别适合你的工作流,而不是基于 Partial 提升 —— 目前没有任何活跃的提升。按类别查看完整清单请参见支持的提供方

IDE 工作流

原生 IDE 控制、Remote View 和会话切换通过 ide 类别实现。完整列表请参见支持的 IDE

扩展工作流

IDE 扩展(Cline、Roo Code、Codex、Claude Code for VS Code)通过 extension 类别实现。在提供方被提升之前,请将它们全部视为探索性的。

CLI 工作流

CLI 代理(Claude Code、Codex CLI 等)通过托管的 PTY/session-host 栈运行,通常是验证远程监控和恢复流程最容易的地方。

已知注意事项

IDE 支持以 Electron 为先

ADHDev 依赖 Chrome DevTools Protocol 进行 IDE 控制。这意味着基于 Electron 的 IDE 是当前的主要目标。

  • 当前以 Electron 为先的目标集合:Cursor、Windsurf、Kiro、PearAI、Antigravity、Trae
  • 检测/启动覆盖:VS Code、VSCodium
  • 当前不适配:非 Electron 的 IDE,如 Zed、IntelliJ 及类似的原生桌面应用

VS Code 家族与 Cursor/Windsurf 不同

VS Code 和 VSCodium 可以被检测和启动,但它们与原生集成的 AI IDE 不是一回事。当你加入诸如 Cline、Roo Code、Codex 或 Claude Code 之类的扩展流程时,它们的相关性会大得多。

Trae 有一个真实的注意事项

Trae 在聊天和控制方面可用,但其模型和模式控件仍然依赖通用 UI 交互,并且可能因应用版本和布局而失败。

实际上:

  • 读取聊天可用
  • 发送消息可用
  • Remote View 可用
  • 模型切换和模式切换应视为部分可用

ACP 启动标志跟随上游

每个 ACP 适配器都使用其底层工具所需的标志启动,随着代理从实验性走向稳定,这些标志会跟随上游变化。

  • Qwen Code(ACP)以 --acp 启动

如果上游工具重命名或移除了某个标志,请相应更新适配器的启动参数。

认证仍然是工具专属的

ADHDev 不会替代每个工具自己的登录流程。

  • CLI 和 ACP 代理仍然需要它们自己的 API 密钥或登录状态
  • 如果你尚未认证底层工具,缺少 API 密钥可能看起来像启动失败
  • 这对 Claude、Codex 和许多 ACP 代理尤其重要

推送通知取决于平台

当仪表板作为 PWA 安装时,推送通知效果最佳。

  • iOS 需要 PWA 安装路径才能使用 web push
  • 通知操作按钮在所有平台上并不一致地显示
  • 即使操作按钮不可用,通知本身仍可能到达

Windows 当前阻止 Node.js 24+

ADHDev 目前将 Windows + Node.js 24+ 视为常规 npm/全局 CLI 安装和启动不受支持。

  • PowerShell 单行安装程序现在在检测到此组合时会引导一个可移植的 Node.js 22 运行时
  • 如果你计划在 Windows 上直接使用 npm install -g adhdev,请使用 Node.js 22.x
  • 这是在 Windows PTY/session-host 路径于更新的 Node 版本上稳定之前的临时保护措施

Linux 仍然以清单为先

一些文档和清单表格提到了 Linux,是因为随附的提供方/检测器清单包含了面向 Linux 的进程名、端口和 Unix 风格的命令路径。

这尚不应被解读为公开支持承诺。

  • 当前经过公开安装测试的路径是 macOS 和 Windows
  • Linux 尚未得到足够验证,无法作为受支持的路径呈现
  • 如果你今天在 Linux 上试验,请将其视为未验证,并预期需要手动排查

Cloud vs Standalone 预期

Cloud

当你需要以下内容时使用 Cloud:

  • 从本地网络外部访问
  • 推送通知
  • 多机器管理
  • API 密钥和 webhook

Standalone

当你需要以下内容时使用 Standalone:

  • 仅本地的设置
  • 无云依赖
  • 基于局域网的监控和控制

Standalone 对 OSS 用户和本地团队非常适合,但诸如推送通知和面向互联网的远程访问之类的仅云功能不在该路径之内。

当前通常表现最佳的组合

如果你想要对产品最具代表性的第一印象,这里有一个不依赖任何特定提供方提升状态的一般性方法:

  1. 如果你想要原生控制、移动端批准或 Remote View,选择桌面 IDE 工作流
  2. 只有在你特别想要某个扩展集成时,才选择扩展工作流
  3. 如果你想要最简单直接的工作流,通过仪表板终端选择 CLI 代理
  4. 先用一台机器加一个提供方,等基础感觉稳定后再上多机器

在哪里查看当前状态

关于当前的提升列表和逐类别状态,请使用支持的提供方。该页面是关于仅存在于清单中的内容与背后有明确验证的内容的公开参考。

相关页面

托管云端文档在此。开源与自托管文档位于 OSS 仓库。