从去年开始我几乎把日常工作里一半以上的操作都搬进了终端。浏览器里翻书签、刷新闻、查天气文件管理器里找文件、看图片、批量重命名甚至记录灵感、管理待办统统换成了命令行工具。朋友问我图什么我说就图一个“不离开键盘”。这种把任何东西都改造成命令行操作的做法圈子里有个很形象的说法——CLI-Anything翻译过来就是“万物皆可命令行”。它不是某个具体的软件而是一整套工具思路和实现方法核心就一句话凡是你频繁要做的事都能用一条命令搞定或者被封装成一条命令。这篇文章我想按自己的实践经验把CLI-Anything从理念到落地完整拆一遍。你会看到现代CLI工具链里那些“被低估”的替代品看到怎么把一个普通API封装成顺手的命令行工具看到交互式CLI那些提升体验的细节还会走一遍真实案例的全过程。适合谁看想提升日常效率但还没系统性接触过现代CLI工具的开发者以及已经会用终端、想更进一步把自己的工作流“命令化”的人。1. CLI-Anything到底是什么一场终端里的效率革命1.1 从“万物皆文件”到“万物皆命令”Unix哲学里有个经典说法叫“万物皆文件”键盘、显示器、磁盘在系统眼里都是文件这种抽象让一切操作都有了统一入口。CLI-Anything的思路跟它一脉相承但抽象层级更高——不只是文件任何服务、任何数据源、任何重复性操作都可以被包装成一个“命令”。我给你举几个具体的例子感受一下查天气weather一条命令返回未来三天的天气和穿衣建议。管理书签bmark add 标题 URL添加书签bmark ls --tag python按标签过滤bmark rm删除。发笔记note 灵感内容直接把想法追加到本地日记文件并按日期归档。查快递track 快递单号调快递API终端里直接输出物流轨迹。你会发现这些东西本来都有对应的App或网页版但App要解锁、要点开、要一步步操作网页版要在浏览器里敲网址、等加载。而CLI版本按一下Tab、敲一行字、回车结果秒出还能跟其他命令组合成流水线。一个具体的组合例子note 开会记录 sync-notes记完笔记自动同步到远端仓库两步变一步。这种“万物皆命令”的思维本质上是把反复要做的事抽象成固定接口输入参数、输出结果。一旦你习惯了这种抽象会发现自己越来越不愿意打开那些“重型”应用因为它们的操作路径太长了。1.2 现代CLI工具链全景那些值得替换的旧工具CLI-Anything能流行起来很大程度上要归功于近几年冒出来的一批现代命令行工具。它们不是传统命令的小修小补而是完全重写的替代品在速度、可读性、交互性上都甩开旧工具一大截。我列一张表把最常用的几组对比写出来你看完会很清楚用途传统工具现代替代核心优势查看文件内容catbat语法高亮、行号、Git变更标记查找文件findfd默认忽略.gitignore、速度快到飞起搜索文件内容grepripgrep (rg)秒级搜索大型代码库自动尊重.gitignore模糊查找/切换目录cd lsz / zoxide fzf按访问频率跳转fzf支持交互式过滤查看目录树treebroot / lsd带缩略图、可交互操作、更好看的图标查看进程psprocs彩色输出、树状展示、搜索方便网络调试curlcurlie / httpie更友好的请求构造和响应展示磁盘占用duduf / ncdu图形化占比、交互式扫描JSON解析grep/sedjq结构化查询、强大的过滤能力我自己身上最典型的例子是替换grep。以前搜代码全靠grep -r结果把 node_modules 里的文件也搜出来一屏根本看不过来。换用rg之后默认就跳过隐藏目录和.gitignore里列出的内容搜索结果干净利落速度还快了不止一个量级。这类工具就是CLI-Anything的基础——好的“命令”是打磨出来的而这些现代工具就是已经被别人打磨好的“万物”。这套工具链选型的逻辑很简单旧工具设计年代早对现代工程目录、大文件、Unicode支持都不够友好。新工具普遍用Rust或Go重写天然更快、更安全、更懂得现代开发者的痛点。你不需要一次性全换先挑一个高频命令替换用两天就会明显感觉到差别。1.3 哪些场景最适合“万物皆CLI”不是什么东西都值得塞进终端。我实践中总结出的判断标准就三条高频、重复、可参数化。高频指你每周至少要操作好几次比如查快递、查天气、开机电脑后必做的事。低频操作做CLI反而浪费维护成本。重复指操作路径固定、逻辑不变比如“把当前目录下的PNG图片统一压缩到80%质量”这种场景非常适合封装。可参数化是关键只有输入和输出能用参数表达清楚才可能做成通用命令。适合做成CLI的几个典型方向个人知识管理快速记录、搜索笔记、归档网页。开发辅助创建项目模板、格式化提交信息、批量重命名分支。数据加工把一个文件从CSV转成JSON、提取日志里的错误并统计。生活效率天气、汇率、二维码生成、番茄钟。不适合做CLI的场景也有需要复杂图形交互的任务比如图像精修、视频剪辑需要团队协作同步的复杂界面比如项目管理看板频繁变化业务逻辑且没有稳定API的服务。判断一个需求是否值得“CLI化”我建议先手动操作三次以上再决定真正常用才值得投入。2. 把任意API封装成CLICLI-Anything的骨架与原理2.1 一条命令背后的四层结构绝大多数CLI工具背后都是这么一套四层架构命令入口 → 参数解析 → 业务逻辑 → 输出呈现。命令入口就是你在终端里敲的那个名字比如weather、bmark它负责找到对应的可执行程序或脚本。参数解析负责理解输入比如--city 上海、--tags python,web这是CLI的“门面”决定了命令好不好用。业务逻辑是核心调用API、处理数据、执行计算都在这一层。输出呈现负责把结果格式化后展示出来可以是纯文本、表格、彩色高亮也可以是 JSON 方便别的程序继续处理。把这四层分开设计有非常大的好处参数变了不用动逻辑输出形式变了不用动接口。我早期做CLI的时候就吃过耦合的亏——把输出格式写死在业务逻辑里后来想加一个--json参数改了三天才理清。举个例子把“查天气”做成CLI四层拆解大概是这样的入口weather对应/usr/local/bin/weather脚本。参数城市名、天数、单位通过标准参数解析库获取。逻辑调用和风天气或OpenWeatherMap的API解析返回的JSON。输出根据参数决定输出表格还是JSON。2.2 用Python Click实现一个天气查询CLIPython是做CLI最成熟的语言之一。标准库里的argparse能用但写复杂参数时比较啰嗦我推荐用Click它用装饰器定义参数代码直观自动生成帮助信息还支持参数校验和交互式确认。一个最小可用的天气CLI代码大致是这样import click import requests click.command() click.option(--city, -c, requiredTrue, help城市名如 上海) click.option(--days, -d, default3, help预报天数默认3天, show_defaultTrue) click.option(--json-output, is_flagTrue, help以JSON格式输出) def weather(city, days, json_output): 查询指定城市的天气信息 url https://api.example.com/weather params {city: city, days: days, key: your-api-key} resp requests.get(url, paramsparams, timeout10) data resp.json() if json_output: click.echo(click.style(json.dumps(data, ensure_asciiFalse, indent2), fggreen)) else: for day in data[forecasts][:days]: date day[date] temp day[temperature] desc day[description] click.echo(f{date} {temp}°C {desc}) if __name__ __main__: weather()注意几个关键的“为什么”。参数解析里requiredTrue强制用户必须输入城市提前阻断错误请求default3给可选参数设置默认值避免每次都敲一遍--json-output用is_flagTrue表示一个开关型参数存在即True。超时设置 timeout10 也很重要不设的话遇到慢接口整个命令会卡住。Click还自带帮助信息运行weather --help会清楚列出所有参数和说明这对命令行工具的可发现性是质的提升——你自己写的命令过两个月再看照样能通过帮助信息快速上手。2.3 命令行参数设计的三个原则参数设计的好坏直接决定你这个CLI是“顺手的工具”还是“劝退的麻烦”。我踩过不少坑总结出三个原则短参数优先、长参数兜底。高频参数要给短别名比如-c表示city-d表示days这样日常敲起来手不累。低频或语义复杂的参数用--长格式比如--json-output。默认值要站在大多数用户角度。如果你的工具90%的场景都是查询未来三天天气那--days的默认值就设为3而不是把默认值设为1让每个人填参数。默认值不是随便设的而是要研究真实的使用习惯。输出格式要为“管道”留口子。这是我最想强调的一点。命令行最强大的地方就是能在一个管道里串联多命令weather -c 北京 --json | jq .temperature | ...。如果你的输出只有彩色文本后面的命令没法解析而只要加一个--json开关你的CLI就瞬间从“给人看”升级成“给程序用”。我现在的习惯是优先级最高的输出格式是JSON而把彩色的表格输出当作“给人看”的友好包装。3. 交互式CLI的体验升级让终端不再冷冰冰3.1 输出美化的三个层次一个CLI工具能不能持续用下去输出体验占了很大比重。我自己把输出美化分成三个层次第一层是基础颜色。用颜色区分信息类型绿色表示成功、红色表示错误、黄色表示警告、青色表示链接或关键词。注意颜色不只是为了好看它能帮眼睛快速定位关键信息——一堆日志里扫一遍颜色就对哪里是错误一目了然。第二层是表格对齐。多字段数据尽量按列对齐字段名加下划线标记数字右对齐、文本左对齐。手工排版容易错位建议直接用表格库Python里可以用rich的Table或者tabulate。第三层是富交互。包括进度条、动态加载动画、交互式选择列表。比如下载多个文件时显示总进度占比和当前文件名搜索时弹出一个可过滤的实时列表供你上下选择。这些体验做得好的代表就是fzf、tui-rs这类工具它们让终端不再是“死板的黑框”。我的建议是个人内用的小工具至少做到第一层稍有规模、可能给别人用的做到第二层凡是涉及选择、搜索、确认的场景尽量上第三层。别一上来就追求富交互先保证颜色和表格对齐用户感受提升立竿见影。3.2 用fzf实现模糊搜索交互fzf是一个非常强悍的模糊查找工具它是CLI-Anything生态的“粘合剂”。它的基本用法是把多行数据用管道丢给它你输入关键字它实时过滤回车后输出你选中的那一行然后你可以在脚本里对这个结果做后续操作。我举一个超实用的例子——快速切换最近的Git分支git checkout $(git branch --format%(refname:short) | fzf)这行命令的运作逻辑先列出所有分支fzf弹出交互式界面你输入几个字母它按模糊匹配规则把最接近的分支顶上来回车选中分支名传给git checkout。整个过程一秒内完成比git branch一个个肉眼找快太多了。再举个例子用fzf做文件预览选择fd -e log | fzf --preview tail -n 50 {}先列出所有log文件fzf里每切换一个选项右侧实时预览该文件末尾50行。找日志的时候这种感觉简直像在IDE里查看文件一样流畅。fzf的强大之处在于它不挑数据源——列表可以来自任意命令的输出、任意文件的内容、任意数据库的查询结果。所以你在自己的CLI里集成交互式选择时最省事的方案就是把选择交棒给fzf而不是自己写一套选择界面。省力且老用户本来就有使用习惯。要注意的是fzf默认输出的是被选中的那一行原始内容如果数据源带了多余的前后缀记得在交给后续命令前先用sed或awk清洗一下。3.3 进度反馈与错误处理的常见坑任何需要网络请求或批量处理的CLI都要考虑“卡住时用户怎么知道发生了什么”。进度反馈方面最基础的要求是超过2秒的操作必须给出提示。你可以用rich.progress显示进度条也可以简单打印一行“正在下载文件A12/30”。但注意别做成每隔0.1秒刷一行日志刷屏比没有进度条更烦人。正确的做法是原地刷新当前行比如用\r回车符覆盖当前行输出让进度信息保持在一行内变动。错误处理方面我总结出几个必须避开的坑不吞异常。很多CLI最喜欢写try: ... except: pass结果用户遇到问题只看到一句话“操作失败”完全不知道卡在哪。正确做法是捕获异常后打印出具体错误来源和原始错误信息。退出码要规范。成功返回0逻辑性错误返回1网络错误返回2参数错误返回3这样别人才能在脚本里根据退出码判断执行结果。命令行世界的约定俗成是0成功、非0失败别觉得自己程序内部能处理就等于成功。输出要可解释。给错误提示带上发生错误的上下文比如“无法连接API服务响应码503请稍后重试”比“请求失败”有用太多。一个人用的小工具可能不在乎这些但一旦你要把CLI分享给团队或开源错误处理和退出码的规范性会直接影响别人愿不愿意用。4. 实际案例全流程用CLI管理书签与笔记4.1 从需求到命令拆解一个真实项目为了把CLI-Anything从理念到落地串起来看一遍我带你走一个我真实在用的项目书签与笔记管理工具名字就叫bmark。需求背景很简单我浏览器里存了几千个书签分了一堆文件夹但找起来依然要用“三明治”式路径——先开浏览器点开书签栏展开一个文件夹再翻几层才能找到目标URL。笔记就更乱了散落在各个App里很难快速搜索和归档。我想要的是一个统一的命令行入口既能存书签、又能记笔记还能快速搜索两者。核心需求拆出来就这么几条添加书签bmark add 标题 URL --tags python,web列出书签bmark ls [--tag python] [--fmt json|table]添加笔记bmark note 内容 [--title 标题]搜索两者bmark search 关键字删除书签bmark rm 书签ID数据存储方面我没有用数据库而是用最简单的本地JSON文件——个人工具的数据量级几千条用JSON完全足够读写文件比维护数据库省心得多。存放路径放在~/.bmark/data.json这样换机时拷一个文件就能迁移。选择JSON文件而非SQLite因为JSON天然可读、可手动编辑、可放进Git仓库做版本管理这对个人笔记类数据是隐形优势。4.2 核心代码实现整个工具用Python实现核心文件是bmark.py依赖Click。我先给出核心部分然后逐个解释关键点import click import json import os from datetime import datetime from pathlib import Path DATA_DIR Path.home() / .bmark DATA_FILE DATA_DIR / data.json def load_data(): if not DATA_FILE.exists(): return {bookmarks: [], notes: []} with open(DATA_FILE, r, encodingutf-8) as f: return json.load(f) def save_data(data): DATA_DIR.mkdir(exist_okTrue) with open(DATA_FILE, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) click.group() def cli(): 个人书签与笔记管理工具 pass cli.command() click.argument(title) click.argument(url) click.option(--tags, -t, default, help标签逗号分隔) def add(title, url, tags): 添加一条书签 data load_data() bm { id: len(data[bookmarks]) 1, title: title, url: url, tags: [t.strip() for t in tags.split(,) if t.strip()], created_at: datetime.now().isoformat(timespecseconds), } data[bookmarks].append(bm) save_data(data) click.echo(f已添加书签 #{bm[id]}: {title} ({url})) cli.command() click.option(--tag, default, help按标签过滤) click.option(--fmt, fmt, typeclick.Choice([table, json]), defaulttable) def ls(tag, fmt): 列出书签 data load_data() items data[bookmarks] if tag: items [b for b in items if tag in b[tags]] if fmt json: click.echo(json.dumps(items, ensure_asciiFalse, indent2)) else: for b in items: click.echo(f#{b[id]:3} {b[title]:30} {b[url]}) if b[tags]: click.echo(f tags: {, .join(b[tags])}) cli.command() click.argument(content) click.option(--title, default, help笔记标题) def note(content, title): 记录一条笔记 data load_data() note_item { id: len(data[notes]) 1, title: title or content[:20], content: content, created_at: datetime.now().isoformat(timespecseconds), } data[notes].append(note_item) save_data(data) click.echo(f已记录笔记 #{note_item[id]}) if __name__ __main__: cli()代码里几个细节值得说清楚。用click.group()实现多命令分组这样一条命令入口下挂多个子命令是CLI工具最常见的形态。Path.home()获取用户主目录不依赖硬编码路径这在多用户机器上特别重要。时间戳用datetime.now().isoformat(timespecseconds)格式是2025-06-14T12:30:00可读性和可排序性都很好。ID用len(data[bookmarks]) 1生成看起来简单但有个隐患删除书签后可能重复计数。真实项目里更稳妥的方案是维护一个全局自增计数器或者直接用UUID。个人工具数据量小如果介意ID重复的话可以改成基于当前时间戳取哈希但用户可读性就差了。我的建议是支持删除的工具用自增计数器存最大值或者每次添加时取max(id) 1。4.3 发布与日常使用技巧写好了脚本之后让它变成系统命令只差最后一步。把文件放到PATH目录里或者软链接过去chmod x bmark.py ln -s /path/to/bmark.py /usr/local/bin/bmark日常使用的时候我总结了几个高频组合实测下来非常舒服# 保存看到的好文章并顺带记个想法 bmark add CLI-Anything笔记 https://example.com --tags cli,python bmark note 今天把bmark分享给同事了反应不错 # 按标签快速找Python相关书签 bmark ls --tag python # 和fzf联动交互式选择书签后直接用浏览器打开 open $(bmark ls --fmt json | jq -r .[].url | fzf --preview echo {}) # 定期把数据备份到Git仓库 git -C ~/.bmark add -A git -C ~/.bmark commit -m backup这里特别想强调--fmt json的价值。写CLI的时候给结构化数据一个JSON输出口子哪怕你现在根本用不到将来一定会在某个脚本里用上。书签数据导出JSON后用jq做筛选再配合fzf做交互式选择能力直接翻倍——这就是CLI-Anything的哲学单个命令是积木组合起来才是乐高成品。5. 常见问题与排查技巧实录5.1 环境差异导致的路径问题Python写的CLI最容易遇到的一个坑是路径和环境不一致。最常见的情况是你用了系统自带的Python写脚本换台机器后发现/usr/bin/python没有第三方库或者脚本依赖某个全局命令结果目标机器上没装。排查思路按顺序来用which python确认解释器路径不同机器可能指向不同版本。检查脚本第一行建议写成#!/usr/bin/env python3让它自动找PATH里的python3。第三方依赖写进requirements.txt并用虚拟环境安装别强行装到全局。如果脚本依赖外部命令比如用到了ffmpeg、jq启动时最好先做一个依赖检查缺失时给出安装提示而不是直接崩。我在bmark里就吃过一次亏在Mac上开发时用brew install jq装了jq分享给Linux同事后发现他那边没有jq脚本跑一半直接报错。后来在入口处加了依赖检测逻辑哭了。经验就是CLI工具的友好度有一半体现在“缺东西的时候能告诉你缺了什么、怎么装”上。5.2 输出乱码与编码问题命令行工具输出中文乱码是另一个高频问题。根源大多是终端和Python的stdout编码不一致。Python3默认UTF-8正常但如果脚本运行环境设置了非UTF-8的locale或者重定向到文件时编码转换出问题就会乱码。应对方法脚本里明确用encodingutf-8打开文件不要依赖默认编码。JSON输出用ensure_asciiFalse保证中文可读。输出重定向到文件时指定UTF-8比如bmark ls out.txt在脚本里对stdout做编码声明或者设置环境变量PYTHONIOENCODINGutf-8。如果用的是Windows终端打开终端时确保代码页是65001UTF-8模式Windows PowerShell新版基本默认UTF-8老版本需要手动改。这类问题虽然烦人但排查起来其实有章法先确认脚本内的字符串是正常的Unicode再确认文件读写编码最后查终端渲染。绝大多数情况是第二层出了问题因为脚本内部的字符串在内存里本来就是Unicode只要打开文件时编码指定对了问题就没了。5.3 效率陷阱什么时候不该用CLICLI-Anything让一切都能变成命令但“能”跟“该”是两回事。我见过太多人为了CLI而CLI最后反而拖累效率。我给自己定的三条红线不符合“2秒内出结果”的交互式复杂任务不做成CLI。比如在线聊天、可视化数据分析这些需要持续交互和图形反馈的场景终端不是好的载体别勉强。维护成本超过使用收益的不做。一个脚本你一个月才用两次每次能省5分钟但为了修它的bug花了3小时这就不值。个人工具的真谛是先快速有再持续改不要一开始就追求完美。涉及敏感数据的场景要格外小心。命令行有个特点输入会在shell历史里留下记录。直接在命令参数里写密码、API密钥等于把密钥明文写在历史文件里这是安全隐患。这种情况优先用环境变量或配置文件去读密钥而不是作为参数传入。拿bmark举例如果某天我要让它保存账号密码类数据我一定会先做加密存储否则宁可不加这个功能。最后再分享一个我个人的心得CLI本身也是一种语言你的命令设计、参数命名、输出格式都体现着你对自己工作流的理解。做完一个工具别急着宣布完工先在实际场景里用两周把不顺手的参数改顺把多余的输出删掉直到这个命令变成你手指的肌肉记忆——到那一刻你才真正理解了CLI-Anything带来的自由感。