事情的起因是 Dotey 在 X 上分享的那个 Obsidian CLI 项目。
看着那个在黑色背景中跳动的纯文本光标，一种久违的极客审美油然而生。这不仅是一个工具的发布，更像是一个信号：“Headless（无头化）”正在成为 Agent 时代的默认配置。
这种趋势让一直困扰我的那个选择题变得更加尖锐：在 AI 辅助编程的未来，我们到底该走向 Claude Code 这种纯命令行的极致效率，还是坚守 Cursor 这种重 UI 的集成环境？
按理说，作为一名 Linux 安全工程师，我的肌肉记忆属于终端，属于那些单行命令的组合。根据“奥卡姆剃刀”原则，我也应该拥抱 CLI——它更轻、更快、对 Agent 更友好。
但当我的手指真正悬在键盘上准备修一个复杂的线上 Bug 时，我必须承认一个反直觉的事实：我身体诚实地留在了 UI 里。
这不仅仅是习惯的惯性，而是因为我们在交付的东西，本质上不同。
效率的诱惑与隐形代价
Teri Radichel 曾详细论证过为何在安全视角下应选择 CLI。她的理由非常硬核：
- 隔离与受控：不希望 Agent 接触本地凭证，最好把它关在云端沙箱里，只通过文本交互。
- 资源与速度：远程传输文本远比 GUI 渲染快，且纯文本是 LLM 的原生语言。
- 风险规避：她观察到 Agent 可能会尝试越权（如使用 sudo），在 CLI 脚本中更容易做硬限制。
这套逻辑是工程师的典型思维：追求极致的执行效率与资源隔离。如果你的目标是让 Agent 像流水线工人一样批量处理任务，CLI 确实是最高效的通道。
然而，当我们面对线上事故或复杂重构时，交付的不仅仅是“代码执行”，而是“变更控制”。
为什么我选择留在 UI
如果你把 AI 仅仅当作“更快的键盘”，那么 CLI 胜出。但如果你把 AI 当作一个“极其勤奋但偶尔会产生幻觉的实习生”，UI 就变成了必须的审计台。
我看重 UI，并非因为我不懂命令行，而是为了以下三个控制权：
1. 把“改动”可视化为地形
CLI 的 diff 是流式的，你需要在大脑里重建上下文。而 UI 的文件树与双栏对比，本质上是一个“范围雷达”。
在涉及安全修补时，我最恐惧的不是 AI 写不出代码，而是它“顺手”改了不该改的配置。UI 让这种越界行为在视觉上无处遁形——这是对“非预期改动”的物理防御。
2. 上下文是环境，不是文本
在终端里喂给 AI 上下文，往往需要你把图片转成链接、把日志复制粘贴。这消耗的是工作记忆。
在集成良好的 UI 中，截图、Issue 链接、报错片段是环境的一部分。你不需要整理它们，只需要指向它们。当你的脑力不需要处理“数据搬运”时，才能腾出带宽去处理“逻辑判断”。
3. 可逆性带来的安全感
你敢让 AI 大胆尝试，是因为你手里攥着“撤销键”。
UI 将 Revert、Discard Changes 做成了极低成本的按钮。而在终端里，回滚往往意味着另一串指令的输入。这种操作成本的差异，决定了你在面对不确定性时的决策心理——是如履薄冰，还是大胆假设。
引擎与仪表盘
攻击者从未停止寻找开发环境的漏洞。无论是 LastPass 的泄露事件，还是 DEV#POPPER 针对开发者的社工攻击，都提醒我们：开发终端本身就是一个高价值的攻击面。
正因如此，安全工程师更应该清楚什么时候该钻进“引擎盖”，什么时候该坐在“驾驶位”。
- CLI 是引擎：这里充满噪声、热量与复杂的管线。它是动力的来源，适合 Agent 在这里榨取算力，快速运转。
- UI 是仪表盘：这里冷静、抽象。你看不到活塞的运动，但你能看到时速、油量预警、导航地图（架构）以及最重要的——刹车踏板。
当 AI 逐渐接管了引擎盖下的繁重劳动，人类工程师的价值，也许不再是比 AI 懂更多的指令细节，而是作为驾驶员，手握方向盘，盯着仪表盘上的每一个异常跳动。
问题不在于工具的优劣，而在于你此刻的角色：你是负责燃烧的燃料，还是负责方向的驾驶员？