CLI 用户体验案例研究
命令行界面因其强大、可脚本化和长寿命而受到赞赏，但许多人认为，与 GUI、移动端和网页应用塑造的现代期待相比，它们的 UX 已经落后。评论者讨论如何让 CLI 更易用——通过更好的帮助系统、一致的标志约定、自动补全、交互模式、TUI，甚至基于 LLM 的 shell——同时不牺牲精确性和可组合性。其背后是更广泛的张力：一边是偏爱简洁、精确工具的专家，另一边是让觉得终端晦涩且吓人的新手降低学习门槛。
关于 CLI 的整体看法
- 许多评论者喜欢 CLI，因为它强大、可脚本化、并且长期稳定，把命令看作工具和脚本可以依赖的“契约”。
- 也有人把 CLI 视为一种必要之恶：非常适合自动化，但在记忆性、可发现性和日常轻度使用方面不如 GUI/TUI。
- 也有人明确不喜欢 CLI，尽管已经使用了几十年，仍更偏好在大多数任务中使用 GUI 或 TUI。
入门门槛与可用性问题
- 终端让人望而生畏：空白屏幕、没有明显可供操作的提示，也几乎没有上下文指导。
- 文本编辑与标准应用不同（鼠标选择、快捷键），会让新用户感到困惑。
- 语法、引号和转义的精确性对初学者来说很难，感觉像是在学习一门新语言。
- 可发现性很差：用户必须已经知道
man、历史展开，或像parallel这样的工具。 - 关于 CLI 是不是天生就比 GUI 更难，还是只是因为不熟悉且介绍得不好，存在争论。
- 有些人认为终端之所以故意保持晦涩，是由于文化上的守门行为。
CLI 与 GUI/TUI 以及混合方案
- GUI 因为能以可视化方式呈现可用操作而受到称赞；CLI 则因其可组合性和表达力而受到青睐。
- 一些人主张双接口：用 TUI（或 GUI）用于探索，用 CLI 层用于脚本化和高级使用。
- 交互式 CLI 颇具争议：一些人认为它是“两头都差”（更难自动化，同时仍受限于终端）；另一些人则表示，只要设计得当，它会获得很强的采用。
- 文中提到了一些能根据 CLI 模式自动生成 GUI/TUI 的工具，也有人呼吁更丰富、具上下文感知的终端（带颜色的校验、工具提示、类似 Plan 9 的可编辑终端）。
标准、选项与子命令设计
- 强烈希望保持一致性：始终提供
-h/--help，出错时给出有用的用法说明，对无效调用返回非零退出码。 - 对不一致的标志风格（
-helpvs--help、重复使用-f）以及直接把用户送去密集难读的 man page 的做法表示不满。 - 有人希望有更正式的 CLI 标准或 schema 来驱动文档、补全和 TUI。
- 关于子命令（
git add）与独立二进制（git-add）的争论：子命令有助于层次结构和帮助信息，但可能干扰 shell 历史技巧。
可发现性辅助与 LLM
- shell 历史、别名、自动补全和模糊搜索（例如在 shell 或工具中）被视为至关重要的辅助功能。
- 有人建议使用由 LLM 驱动的“自然语言 shell”或助手，把模糊提示转换成精确命令，但同时提醒要注意安全沙箱。