WorkBuddy 两种权限模式 vs CodeBuddy CLI 的七种，形态不同粒度也不同
同一家团队的两个产品，权限设计差得很远：WorkBuddy 桌面端是两档，CodeBuddy CLI 有七种以上。
第一反应可能是「CLI 更强」——但这个判断没意义。面向的人不一样，粒度自然不一样：一个是给运营、财务、市场用的桌面工作台，一个是给开发者用的命令行工具。
这篇把双方官方文档写明的机制并列出来，各标来源。不做优劣评价、不做性能对比——我们没有安装任何一方的客户端。
依据：WorkBuddy 官方英文文档
Function-Description/Permission-Modes（中文文档站暂无此页）与官方中文 FAQ「数据安全说明」；CodeBuddy 官方中文文档cli/permission-modes。核对日均为 2026-08-16。
一、先说形态前提
| WorkBuddy | CodeBuddy CLI | |
|---|---|---|
| 形态 | 桌面客户端 | 命令行工具 |
| 官方描述的用户 | 产品页场景包写的是个体创业者、自由职业者、运营、客户成功、管理等角色 | 面向命令行工作流的开发者 |
| 切换方式 | 新建任务的输入区下拉选择 | Shift+Tab 循环、CLI 参数、settings 配置文件 |
粒度差异的根源在这儿：下拉框里放七个选项，对办公用户是负担；而命令行用户本来就习惯用参数和配置文件管理行为。
二、WorkBuddy 侧：两档
官方英文文档给的两种模式：
| 模式 | 官方描述 |
|---|---|
| 默认权限（Default Permissions） | 官方推荐日常使用。AI 在工作空间内正常干活，高风险操作停下来等你确认 |
| 完全访问（Full Access） | 关闭上面那套确认流程，高风险操作不再逐步询问 |
默认权限下需要确认的四类操作：写入受保护或敏感路径、删除受保护文件或重要文件夹或大量文件、运行脚本命令外部程序、网络访问或敏感能力。
三层兜底：沙箱约束、删除保护、文件备份（仅 Windows 支持）。
官方对完全访问的表述很克制但意思很硬：完全访问并不更安全，它也不会自动理解每一种风险，它只是让 AI 自动跳过确认步骤。
另外，官方中文 FAQ 的「数据安全说明」里提到了另一层描述：分层权限系统，支持 allow（允许）、ask（询问）、deny（拒绝）三种权限规则，以及启动时仅拥有只读权限。
三、CodeBuddy CLI 侧：多种模式
CLI 官方文档列的用户可手动切换的模式：
| 模式 | 官方描述的「不询问就能跑什么」 | 官方给的适用场景 |
|---|---|---|
default | 信任目录内的 Read 工具 | 默认；适合敏感工作 / 上手期 |
acceptEdits | 信任目录内的 Read + Edit 系列工具 | 边写边走 git diff 复核 |
auto | 原本会 ask 的动作，交给分类器判定 allow / deny | 想减少打断，但保留安全边界 |
dontAsk | 仅已预批准动作继续执行；其余不询问直接拒绝 | 非交互自动化 / 固定白名单代理 |
plan | 委托给进入 plan 前的模式；额外允许写入会话计划文件 | 落手改动前先摸清代码 |
bypassPermissions | 跳过绝大多数审批 | 沙箱容器 / VM / 离线 dev container 才用 |
delegate | 仅协调类工具，实现类工具被屏蔽 | 主代理只做拆派，执行交给子代理 |
另有三个程序化 / 集成模式（不在 Shift+Tab 循环里）：fullAccess（IDE 客户端传入，语义接近 bypassPermissions）、work（IDE 客户端传入）、ignore（仅子代理场景）。
切换方式：会话中按 Shift+Tab 循环（Windows 上 Alt+M 是兼容别名）；启动时用 --permission-mode 指定；也可在 settings 里配 permissions.defaultMode 持久化。
四、几处值得并列细看的机制
1）「更宽松」的那一档，两边都强调不是护身符
- WorkBuddy：完全访问并不更安全，只是让 AI 自动跳过确认步骤；官方列了五种不该开的情形（唯一副本/生产/客户/财务数据、工作空间靠近桌面下载文档根或仓库根、批量删改移覆盖、跑你看不懂的脚本、机器上有没备份的重要文件）。
- CLI：
bypassPermissions官方标注的适用场景是沙箱容器 / VM / 离线 dev container 才用；文档还写明它也不是绝对无条件放行——前面的 deny / ask 规则与交互态危险命令检查仍可能拦住它。
两边口径一致：最宽松的那一档，是给隔离环境用的。
2）CLI 有一档比默认更严
dontAsk 是 WorkBuddy 侧没有对应物的一档。官方原文：任何本来要弹审批的动作，都不要弹，直接拒绝；并明确说它不是 bypassPermissions 的别名，恰好相反，它更严格。
官方给的适用场景是 CI / 批处理 / 后台代理——「能做就做，不能做就立即失败」。
3）plan 模式的「委托」设计
CLI 的 plan 不是独立的只读模式，官方写的是委托给进入 plan 前的模式：从 default 进 plan，普通 Edit / Bash 仍然会 ask；从 acceptEdits 进 plan，非计划文件的 Edit 仍按 acceptEdits 自动放行。plan 真正额外放行的只有当前 session 的计划文件写入，退出时恢复先前模式而不是掉回 default。
4）两边都强调「模式只是一层」
- CLI 文档开篇就写：权限模式决定的是会话节奏，不是整套权限系统的全部逻辑；每次工具调用会先后经过 hooks、deny 规则、可信 allow 规则、命令安全检查、ask 规则、bypassPermissions 短路、不可信 allow 规则、当前模式基线策略、非交互兜底。结论是 deny 永远比 mode 更强。
- WorkBuddy 侧对应的是：命令先在沙箱约束下运行，被拦了再按风险判断需不需要确认；中文 FAQ 另有 allow / ask / deny 分层权限系统的描述。
两边都不是「选个模式就决定一切」。
五、有一处差异值得使用者知道
WorkBuddy 的「文件备份」这一层，官方明确写了仅 Windows 支持（修改已有文件前先存副本，新建文件不重复备份）。
CLI 文档在权限模式这一页没有对应的跨平台差异说明。
这条差异对实际使用有影响：Mac 上用 WorkBuddy 做批量改写类任务，少了一层自动兜底，「先把文件复制进任务目录」这个习惯就更重要。
六、什么情况用哪个（按官方自述的定位归因）
强调一次：这是按双方官方自述的定位做的场景归因，不是评测结论。
- 做办公交付物（周报、PPT、表格清洗、调研报告），不想碰命令行 → WorkBuddy 官方产品页写的场景包正是这些；
- 在命令行工作流里改代码、跑测试、走 git diff → CLI 官方给
acceptEdits写的适用场景就是「边写边走 git diff 复核」； - 要做 CI / 批处理 / 固定白名单代理 → CLI 的
dontAsk是为这个设计的，WorkBuddy 侧没有对应粒度； - 要在隔离环境里跑可信任务 → 两边都有对应的一档（WorkBuddy 的完全访问、CLI 的
bypassPermissions），且两边都明确说了只在隔离环境用。
七、我们不写的东西
- 不写谁的权限系统更好、更安全——这需要在同等条件下做安全评估，我们没做；
- 不做「WorkBuddy 的默认权限约等于 CLI 的 default」这类对应——两边的工具面、判定链、适用形态都不同，画等号会误导；
- 不预测 WorkBuddy 会不会加更多模式；
- 不写社区评价与实测数据——不在双方官方文档里。
小结
- 形态前提不同：WorkBuddy 是桌面客户端（下拉切换两档），CodeBuddy CLI 是命令行工具（Shift+Tab 循环 / 参数 / settings，七种以上）。
- WorkBuddy：默认权限（四类操作要确认）与完全访问（跳过确认）；三层兜底中文件备份仅 Windows。
- CLI：
default/acceptEdits/auto/dontAsk/plan/bypassPermissions/delegate，另有三个集成模式。 - 两边口径一致的一点：最宽松那一档是给隔离环境用的，且都写明它不等于更安全 / 不是无条件放行。
- CLI 独有一档
dontAsk比默认更严（不弹框、直接拒绝未预批准动作），官方定位是 CI / 批处理。 - 两边都强调权限模式只是一层——CLI 说「deny 永远比 mode 更强」，WorkBuddy 侧是沙箱先拦再判断。
- 本文只并列官方事实，不做优劣判断、不做模式对应。
双方功能与文档表述均以各自官方为准，核对日 2026-08-16。