CLI 设计哲学
命令行不是某个工具的专属界面，而是一套通用的设计语言。它值得长期学习，不是因为某个命令难背，而是因为真实工程环境里总会出现新的工具、新的服务器、新的脚本和新的自动化入口。能读懂 CLI 的设计，就能在陌生工具面前先判断，再查细节。
1. CLI 的本质
CLI 和 GUI 一样，都是产品界面——只是交互的媒介不同。GUI 用图形元素承载操作，CLI 用文字承载意图。文字的优势在于它是结构化的：你可以精确描述你要什么，而不是在菜单里翻找。
CLI 有三个 GUI 难以替代的特性。第一是语义化沟通：命令把动作、对象和选项直接写出来，便于复盘和讨论。第二是可组合：通过管道（|）、重定向和退出码，小工具可以串成稳定流程。第三是可自动化：同一条命令可以交给人执行，也可以交给脚本、CI、Agent 或远程机器执行。
多数 CLI 工具都遵循一组可识别的模式。它们不是随机发明的，而是从几十年的工程实践里沉淀出的约定。真正要记住的不是每个参数，而是：这个工具如何表达动作、如何表达对象、如何处理输入输出、如何把错误暴露给调用者。
到 2026 年，CLI 还有一层新的价值：它是人、脚本、CI 和 Agent 都能共同理解的接口。GUI 适合探索和观察，CLI 适合把判断固化成可复制的动作。当你让 Agent 检查仓库、跑测试、处理文本、部署服务或连接远程环境时，最可靠的交接物通常仍然是一条可审计的命令，而不是一串无法复现的点击。
2. 两大设计范式
CLI 世界有两种主流的设计哲学，它们决定了命令如何组合、数据如何流动。
文本流范式（Unix 哲学）
核心理念是 “Do one thing and do it well”。每个命令只做一件事，但做到极致。你需要完成复杂任务时，通过管道把多个小工具组合起来。
在这个范式里，文本是通用接口。每个命令从 stdin 读取文本，向 stdout 输出结果，向 stderr 输出诊断信息。因为一切皆文本，所以任何两个命令都可以连接——只要格式对得上。
Unix 哲学还有一条 “Rule of Silence”：没出错就别说话。命令只在出错时输出信息到 stderr，正常执行时保持安静。这样管道传递的才是干净的数据，不会被日志或提示污染。
代表生态是 Unix/Linux shell（bash、zsh 等）。grep、awk、sed、sort 都是这个范式的经典产物。
对象流范式（PowerShell 哲学）
核心理念不同：命令之间传递的不是文本，而是结构化对象。
Get-Process | Stop-ProcessGet-Process 输出的不是文本，而是进程对象。Stop-Process 接收的也不是文本，而是同一个进程对象。它可以直接访问对象的属性，不需要用 grep 或 awk 做文本解析。
这个范式配合 Verb-Noun 命名规范：Get-Process、Set-Location、New-Item。动词描述动作，名词描述对象，组合起来就是完整的语义。
代表生态是 PowerShell，适合 Windows 系统管理和 .NET 生态。
两者的关系
这不是”哪个更好”的问题，而是”不同场景不同选择”。
文本流灵活通用，适合一切皆文件的 Unix 世界。你不需要知道上游命令输出什么类型，只要文本格式对得上就能接。对象流类型安全，属性直接访问，适合结构化的系统管理场景。
理解这两种范式，你就能明白为什么有些工具用管道传递文本，有些工具传递对象——它们背后的设计选择不同。
3. 命令命名模式
这是 CLI 设计的核心。不同的工具采用不同的命名风格，但每种风格都有内在规律。识别出风格，你就能推导用法。
POSIX 风格
特征格式：cmd -a -b -c value operand
短参数用单横线加一个字母（-a、-v、-f）。多个短参数可以合并：-abc 等价于 -a -b -c。如果某个参数需要值，它通常是合并写法中的最后一个：-abc value 表示 -a、-b 和 -c value。
操作对象（operand）放在命令的最后。退出码有明确约定：0 表示成功，非 0 表示失败。
阅读方法：看到 cmd -x 时，先假设它是传统短参数，再查 man cmd。POSIX 工具的 man page 通常有稳定结构，OPTIONS 部分会按字母序列出短参数。短参数适合交互输入，但脚本里如果可读性更重要，长参数往往更值得优先考虑。
GNU 长参数风格
特征格式：cmd --verbose 或 cmd -v
GNU 风格提供短参数和长参数双轨。-v 和 --verbose 是等价的——短参数方便快速输入，长参数方便阅读和脚本编写。
--help 和 --version 几乎是 GNU 工具的标准配置。--help 输出用法说明，--version 输出版本信息。
GNU 风格还有一个重要约定：-- 分隔符。-- 之后的所有内容都被视为操作对象，不再被解释为参数。这在处理以横线开头的文件名时非常有用：rm -- -rf 删除名为 -rf 的文件，而不是执行递归强制删除。
阅读方法：直接运行 cmd --help，长参数列表会告诉你工具作者认为哪些选项值得暴露。长参数本身就有语义，--output 比 -o 更容易理解，也更适合写进团队脚本和自动化任务。
Subcommand 风格
特征格式：tool <command> [options] 或 tool <command> <subcommand> [options]
这是现代 CLI 最主流的设计模式。Docker、GitHub CLI、Cargo 都采用这种风格。
docker container ls
gh issue create
cargo build --release核心理念是把操作对象和动作都编码进命令结构中。docker 是工具名，container 是操作对象，ls 是动作。结构清晰，语义明确。
阅读方法：先运行 tool --help，看它如何划分对象和动作；再运行 tool <command> --help，看这一层的选项。子命令层级越深，越要警惕自己是否在操作正确的资源，例如集群、项目、仓库、环境或账号。
Resource-Action vs Action-Resource
这是 Subcommand 风格的两种变体。
Resource-Action（资源在前，动作在后）：tool <resource> <action>。例如 kubectl pod list——先指定资源类型 pod，再指定动作 list。适合资源种类多、动作相对固定的场景。
Action-Resource（动作在前，资源在后）：tool <action> <resource>。例如 az vm create——先指定动作 create，再指定资源类型 vm。适合动作种类多、资源相对固定的场景。
没有绝对的优劣，取决于工具的设计重心。资源多动作少 → Resource-Action；动作多资源少 → Action-Resource。
阅读方法：先判断工具的核心复杂度来自资源还是动作。资源复杂的系统通常把资源放前面，动作复杂的系统通常把动作放前面。这个顺序不是审美问题，而是工具作者在告诉你：他们希望你先想清楚哪一类东西。
Git 风格（多级动词）
特征格式：git <verb> [options]
Git 围绕单一核心对象（仓库）设计，在它上面执行不同的动词操作。git commit、git push、git log——每个动词都有自己的一套选项。
这种风格可以看作是 Subcommand 的特例：只有一个层级的动词，没有资源分类。因为 Git 的操作对象始终是仓库，所以不需要额外的资源维度。
阅读方法：git --help 列出所有可用动词，git <verb> --help 查看该动词的选项。每个动词背后都有独立语义，git commit 处理本地历史，git push 处理远程同步。不要只按命令记忆，要按状态变化理解。
PowerShell Verb-Noun
特征格式：Verb-Noun
PowerShell 采用连字符连接的动词 - 名词结构。动词来自标准化的 approved verb list，名词描述操作对象。
Get-Process # 获取进程
Set-Location # 设置位置（cd 的正式名称）
New-Item # 创建项目
Remove-Item # 删除项目动词是标准化的：Get（获取）、Set（设置）、New（创建）、Remove（删除）、Start（启动）、Stop（停止）。知道动词的含义，你就能理解命令在做什么。
阅读方法：先拆动作，再拆对象。想要获取进程是 Get-Process，停止服务是 Stop-Service，创建文件是 New-Item。Verb-Noun 的价值不是让命令更长，而是让命令在大型系统管理里保持可搜索、可补全、可推导。
4. 参数与标志约定
CLI 的参数和标志有一套通用约定，理解这些约定，你就能猜出大部分工具的参数用法。
布尔标志：--force 默认是 false，出现在命令行上即为 true。有些工具支持否定形式：--no-force 显式关闭。
值参数：--output file.json 或 --output=file.json。GNU 风格通常支持两种写法，空格和等号等价。短参数通常紧跟值：-o file.json。
短参数合并：-rf 等价于 -r -f。这是 POSIX 风格的经典特性，多个布尔标志可以合并成一个。如果最后一个参数需要值，值跟在后面：-I/usr/include 表示 -I /usr/include。
-- 的妙用：-- 之后的内容不再被解释为参数。rm -- -rf 删除名为 -rf 的文件。git log -- main.py 查看 main.py 的提交历史，即使 main.py 和某个分支名冲突。
环境变量替代：很多工具尊重环境变量来覆盖默认行为。$EDITOR 指定默认编辑器，$PAGER 指定分页器。工具服从用户偏好，而不是强制自己的选择。
颜色控制：--color=auto|always|never 控制输出颜色。auto 表示终端支持时启用，always 强制启用，never 禁用。NO_COLOR 是一个跨工具的环境变量约定——设置它后，支持该约定的工具都会关闭彩色输出。
5. 输出约定
CLI 的输出不是随意打印的，它有明确的结构和约定。
stdout 是结果：命令的主要输出内容。可以被管道传递给下一个命令，也可以重定向到文件。stdout 应该只包含数据，不包含提示或日志。
stderr 是诊断：错误信息、进度条、日志输出。stderr 不会进入管道——cmd 2>/dev/null 可以丢弃诊断信息，同时保留结果。把错误和结果分开，是 Unix 哲学的重要实践。
退出码：0 表示成功，非 0 表示失败。$? 查看上一个命令的退出码。脚本通过退出码判断命令是否成功，而不是解析输出文本。
机器可读输出：现代 CLI 越来越重视 --json 或 -o json 选项。CLI 不仅要给人读，还要给脚本和 AI 读。结构化输出让自动化更加可靠——你不需要写正则去解析人类友好的表格，直接解析 JSON 即可。
6. 如何阅读陌生 CLI
拿到一个陌生的 CLI 工具，不需要马上背命令。更稳的做法是先读它的设计，再决定该查哪里、该试什么、该把哪些命令写进自动化。
识别风格：看一眼命令格式，判断它属于哪种命名模式。是 POSIX 短参数、GNU 长参数、Subcommand，还是 Verb-Noun？识别风格后，你就知道该用 man、--help、补全，还是对象属性去探索它。
拆动作和对象：不要只找“我要用哪个命令”，先问“我要改变什么对象、读取什么状态、产生什么副作用”。想要列出容器，Subcommand 风格里可能是 container list 或 container ls；想要获取配置，Verb-Noun 风格里可能是 Get-Config。
看输出契约：这个命令是给人读，还是给机器接？如果有 --json、--porcelain、--quiet、--dry-run，优先理解它们。长期可维护的脚本依赖稳定输出和退出码，而不是解析漂亮表格。
检查风险开关：看到 --force、--delete、--recursive、--yes、--no-confirm 这类选项，先确认作用范围。CLI 的力量来自可组合和可重复，风险也来自可组合和可重复。
阅读错误：CLI 的错误信息通常比 GUI 的操作反馈更精确。错误会告诉你哪里错了、为什么错，有时还会告诉你该怎么改。对未来的自己和 Agent 来说，一段完整错误输出往往比一句“失败了”更有价值。
我希望自己养成的不是“会用很多命令”的姿态，而是能快速判断一个命令是否可读、可组合、可自动化、可回滚。CLI 的核心不是炫技，而是把工程判断变成可以复现的文本接口。