我们每天都在跟各种软件打交道但我发现一个很有意思的现象很多熟练的开发者最后都会慢慢回归到那个黑底白字的终端窗口。原因很简单图形界面适合点选命令行适合批量、重复、可组合的操作。而“CLI-Anything”这个思路说白了就是尝试把生活和工作里一切高频、琐碎、重复的事情都封装成一条命令让终端成为真正的“万能工具箱”。这篇文章不是讲某个特定工具的使用教程而是想分享我自己的实践如何用“命令行思维”去改造日常流程包括从零设计一个属于自己的小工具、怎么选型现成的CLI项目、以及遇到各种坑时怎么排。无论你是前端、后端、运维还是数据分析师只要每天有大量重复的电脑操作这篇文章都值得看完里面给的步骤和代码都是可以直接抄作业的。1. 别再造轮子了把日常任务全塞进终端1.1 为什么我从“花里胡哨的图形工具”回到了终端先说个场景。以前我做一次周报要经历打开聊天软件翻一周的聊天记录打开浏览器看数据后台打开笔记软件找随手记的点最后打开文档软件排版。整个过程至少二十分钟而且极度容易漏东西。后来我尝试把这些信息源全部集中到一个地方用脚本去抓取、过滤、汇总一条命令直接生成Markdown草稿再花两分钟微调就完成了。这个过程让我意识到图形工具擅长“展示”而命令行擅长“执行”。你点十下鼠标能完成的事写一条命令也能完成但你写一条命令能完成的事点十下鼠标不一定能完成。CLI的核心价值不是“更极客”而是可重复、可审计、可组合。每一次操作都留下了历史记录别人拿到你的命令和执行结果就能完整重现你的工作流程。1.2 CLI-Anything 的本质不是工具是一种组装思维“CLI-Anything”并不是指某个单一仓库或者框架。我在GitHub上看到过不少叫这个名字或者类似语义的项目但多数是个人整理的命令集合、快捷键列表、别名配置等等。真正让它有价值的是背后的思维把一切操作都视为“输入-处理-输出”的流水线。举个例子。你想把一张图片压缩后发给别人。图形化的做法是打开图像处理软件导入调整参数导出再打开聊天软件上传。命令行思维的做法是一张图片作为输入进入一个压缩工具处理输出一张体积更小的图片然后再进入另一个上传工具。每一步都是独立的你可以中途替换其中任意环节甚至可以把这个流程挂到定时任务里。所以CLI-Anything在我眼里不是“用命令行做任何事”的噱头而是建立一套属于你自己的、可积木式拼接的命令工作流。这篇文章会从设计原则讲起再给一个完整的实操案例最后分享工具选型和排坑经验。2. 设计一个好用的 CLI 工作流先从这三条原则说起2.1 单一职责一个命令只干一件事很多人在做自己的命令行工具时第一个冲动就是“功能越全越好”。但命令行的生态跟图形界面完全不同。图形界面可以靠菜单、按钮、向导把复杂功能藏起来命令行没有这种缓冲参数一多心智负担就上来了。我在设计自己的命令工具时最优先的原则是一个命令只解决一个问题。如果某个操作可以拆成两个独立的阶段那就拆成两个命令或者用管道把它们串起来。举个例子我有一个用于处理会议纪要的命令最早它既能解析语音转文字的结果又能提取待办事项还能发送邮件通知。结果这个命令的参数越来越长代码里塞满了各种 if 和 flag最后维护起来特别痛苦。后来我把它们拆成了三个独立命令一个负责解析一个负责提取待办一个负责通知。每个命令都很短逻辑一目了然而且我可以只执行其中某一步不用每次都跑全流程。拆分的判断标准很简单如果一个命令中的某一部分逻辑你在另一个场景下也想单独用那它就该被拆出来。这不是过度设计而是减少耦合让工具具备更好的复用性。2.2 输入输出规范用 JSON 做接口用退出码说人话命令行工具之间的协作核心靠标准输入、标准输出、标准错误。我发现很多新手写的CLI工具输出里塞满了彩色文字、[]、-这类装饰符号人眼看着挺花哨但一旦要用脚本读取结果就会非常痛苦。我自己习惯的做法是默认输出格式保持简洁程序化场景用 JSON交互场景用表格。爱用--json这个参数来切换。这样做的好处是命令 A 的输出可以直接变成命令 B 的输入形成流水线。除此之外退出码exit code也特别重要。很多自用工具根本不设置退出码出错了也返回 0这会给上层调用埋下大坑。我的约定是0成功1常规错误比如文件不存在2参数错误比如缺少必填项3业务逻辑错误比如数据校验不过这个约定跟很多主流工具的惯例保持一致后续做脚本判断时不需要额外成本。2.3 组合优于大而全管道、别名、脚本三件套命令行最迷人的地方在于管道pipe。单个工具的能力有限但把几个工具串起来就能实现非常复杂的功能。而且这种组合是即插即用的不需要重新编译一个新命令。我举一个自己在用的例子。我需要快速查看今天新增的文件数量find ~/dropbox/notes -type f -mtime -1 | wc -l这里没有写任何新代码只是把find的输出接到wc -l上一行命令就完成了统计。这就是“CLI-Anything”思维的精髓不用等工具内置某个功能你完全可以自己用现成命令拼装一个。不过管道虽然好用但有两条经验值得注意。第一管道默认只传递标准输出不会传递标准错误所以如果中间某个环节出了错错误信息不会出现在终端里容易让你误以为一切正常。第二每条管道命令的退出码只反映最后一条命令的状态。如果中间某条命令失败了但最后一条成功了你的脚本依然是“成功”的这很坑。解决方法是在 Shell 里开启set -o pipefail在 Bash 脚本中把“任何环节失败”都视为失败。3. 实操实录把“每周工作纪要归档”变成一条命令3.1 场景分析与立项先梳理旧工作流这一节我用一个真实做过的案例来完整演示从设计到实现的全过程。任务背景是我每周会跟不同人开会会议纪要散落在各个对话软件、邮件、备忘录里。到了周末想汇总本周进展总是要来回切换十几个界面非常累。我梳理了一下旧工作流的痛点纪要散落没有统一的入口手动归类太费时间容易记错项目名汇总时经常忘记某条重要结论想翻一个月前的某条纪要根本搜不到基于这些痛点我决定写一个小工具命名为weeknote。它要解决的核心问题是从一堆零散文本中按项目维度快速归档并输出一份本周总结。3.2 第一个可用版本用 Python argparse 实现先说选型。写这种个人工具我首选 Python原因只有两个标准库足够多argparse解析参数、pathlib处理路径、json处理数据写起来快不用折腾编译环境。我的目录结构是这样规划的~/tools/weeknote/ ├── weeknote.py ├── templates/ │ └── weekly_summary.md └── data/ └── notes.jsonweeknote.py是主程序的入口notes.json是一个简单的 JSON 文件用来存储所有已归档的纪要。每个条目包含四个字段date、project、content、tags。最初版本的核心逻辑非常朴素#!/usr/bin/env python3 存档一条会议纪要并按项目输出本周汇总。 import argparse import json from pathlib import Path from datetime import date, timedelta DATA_FILE Path.home() / tools/weeknote/data/notes.json def load_notes(): if not DATA_FILE.exists(): return [] with open(DATA_FILE, r, encodingutf-8) as f: return json.load(f) def save_note(note): notes load_notes() notes.append(note) with open(DATA_FILE, w, encodingutf-8) as f: json.dump(notes, f, ensure_asciiFalse, indent2) def add_note(project, content, tags): note { date: date.today().isoformat(), project: project, content: content, tags: tags, } save_note(note) return note def weekly_summary(days7): start date.today() - timedelta(daysdays) notes [n for n in load_notes() if n[date] start.isoformat()] return notes if __name__ __main__: parser argparse.ArgumentParser(description归档和汇总工作纪要) sub parser.add_subparsers(destcommand) add_parser sub.add_parser(add, help添加一条纪要) add_parser.add_argument(project, help项目名) add_parser.add_argument(content, help纪要内容) add_parser.add_argument(--tag, actionappend, help标签可多次指定) summary_parser sub.add_parser(summary, help输出本周汇总) summary_parser.add_argument(--days, typeint, default7, help回溯天数) args parser.parse_args() if args.command add: note add_note(args.project, args.content, args.tag or []) print(json.dumps(note, ensure_asciiFalse)) elif args.command summary: for note in weekly_summary(args.days): print(f- [{note[project]}] {note[content]}) else: parser.print_help()这个版本其实已经很能用了。我可以通过python3 ~/tools/weeknote/weeknote.py add 数据平台 确认下周完成实时看板的接口改造 python3 ~/tools/weeknote/weeknote.py summary来添加纪要并查看本周汇总。看到这个基础版本你会发现它非常“朴素”没什么花哨的东西但已经具备了一个 CLI 工具的骨架子命令、参数、持久化、输出。3.3 进阶增强模糊匹配、自动统计、错误容忍基础版本能跑通之后我开始在实际使用中找痛点给自己加需求。以下三个增强最有价值。第一个增强是模糊匹配项目名。最初我必须精确输入“数据平台”四个字但有时候打成了“数平”导致归档到了一个新项目名下汇总时数据被拆散。我在add子命令里加了一个匹配逻辑如果传入的项目名在已有项目列表中找不到精确匹配就按编辑距离找最接近的项可以用difflib.get_close_matches如果相似度足够就自动纠正并提示。第二个增强是统计输出。光列出来还不够我想知道本周哪个项目投入的“话语量”最多。我加了一个选项--stats在summary子命令中输出一个简单的统计表项目名、纪要条数、字数占比。第三个增强是处理重复内容。开会时经常有人复述同一件事我可能不自觉存了两次。为了方便去重我在add时会对content做一个简单哈希存入note_id。如果发现最近20条纪要里有相同哈希就给出警告但不主动删除让用户决定。这些增强让工具从“能跑”变成了“好用”。工具的价值不在功能堆砌而是你真正用起来之后根据使用体验迭代出来的那些小细节。3.4 把命令放到全局配置 PATH 和别名一个 CLI 工具如果每次都要敲python3 ~/tools/weeknote/weeknote.py用起来动力会大打折扣。我的做法是把脚本目录加入PATH并给命令设置一个好记的名字。在~/.zshrc或~/.bashrc中加上export PATH$HOME/tools/weeknote:$PATH alias weeknotepython3 $HOME/tools/weeknote/weeknote.py重新加载配置后就可以直接用weeknote add ...了。这个小改变直接提高了工具的使用率。很多自用工具写完之后吃灰就是因为入口太麻烦这其实是可以用两个步骤解决的问题。3.5 让队友也能用整理参数帮助与示例既然要把工具分享给团队就不能只有我自己看得懂命令行。我给argparse的每个参数都写了详细的help字符串并且在 README 里加了几条“从真实使用场景出发”的例子# 典型用法 weeknote add 数据平台 完成实时看板联调 --tag 进度 --tag 联调 weeknote summary --days 7 weeknote summary --days 30 --stats写帮助文档的关键是从场景出发而不是从功能出发。不要写“本命令支持项目归档功能”而要写“每周五快速生成本周工作汇总”这样队友才能快速理解“我什么时候应该用它”。4. 别重复造轮子这些现成 CLI 值得收进你的工具箱4.1 发现工具的几个渠道不是所有东西都需要自己写。CLI-Anything 的精神首先要站在巨人的肩膀上。GitHub 上优秀的 CLI 项目非常多怎么发现适合自己的我常用的渠道有三个GitHub 的awesome-cli系列仓库汇总了大量优质命令行工具终端包管理器自带的搜索比如npx、homebrew、cargo等技术博客和社区里大家分享的“我的终端工作流”文章我挑选工具的标准有四个是否维护活跃、是否有稳定的退出码和输出规范、是否能用管道与其他工具组合、文档里是否有足够多的真实示例。其中“维护活跃”最重要否则遇到 bug 或兼容性问题时你得自己啃源码。4.2 办公与文档类这里分享几类我实际用过、且觉得靠谱的现成命令。文档转换pandoc堪称文档转换界的瑞士军刀能处理 Markdown、Word、PDF、HTML 等格式互转我写报告时经常用。表格处理xsv专门处理 CSV 文件比 Excel 里的筛选快太多适合快速查看和过滤几十万行的数据。PDF 操作pdfgrep搜索 PDF 内容、qpdf做 PDF 的基础加密解密这两个组合起来能满足大部分需求。这些工具的共同特点是不依赖图形界面输出可以用管道继续处理。4.3 开发与运维类开发场景下命令行工具本来就是主力但我特别推荐几个能显著提升效率的。jq处理 JSON 的利器。一条jq命令能完成过滤、排序、聚合等操作比写 Python 脚本快得多。ripgrep搜索工具rg速度远快于传统grep而且默认遵守.gitignore不会搜到依赖目录。fzf模糊查找工具可以跟历史记录、文件列表等任何输出组合。我经常用它来快速切换最近打开过的项目目录。tldr简化版文档显示常用命令的最常见用法比翻完整文档快。这些工具都不需要学习完整文档会搭配管道和别名就够了。4.4 AI 能力集成类近一年来命令行 AI 的组合项目特别多。这类工具的核心思路是把自然语言请求作为输入调用模型能力把结果输出到终端。例如用命令行快速生成一段文案、总结一篇长文、翻译一段代码注释。我不打算在这里具体点名某个项目但想分享一个判断思路AI 类 CLI 工具要优先选择支持自定义模型接口参数的不要选把模型地址固定死的。因为你可能要切换到本地私有模型或者切换不同的服务商自定义接口能避免被任何一家绑定。另外这类工具对输出的稳定性要求比较高你要确认它能否输出纯文本的 JSON方便下一步程序化处理。5. 常见问题与排坑实录5.1 参数解析没搞对命令行为诡异我最早写 CLI 工具时最常犯的错误就是子命令subcommand和全局参数混在一起。比如weeknote --project 数据平台 add 完成了接口改造这种写法在解析上很容易出岔子。建议养成一个习惯参数绑在哪个子命令上就放在那个子命令后面。全局参数只放“对所有子命令都生效”的选项比如--verbose、--config。另外argparse里如果一个子命令没有设置dest处理逻辑时容易混乱建议显式设置sub parser.add_subparsers(destcommand, requiredTrue)加上requiredTrue后用户没写子命令时会提示错误而不是默默啥也不干。5.2 在 Windows 下运行时要注意编码和路径问题我用了几年 Windows PowerShell 之后换到了 Linux但团队里还有同事用 Windows。Windows 下写 CLI 工具有几个大坑一是文件路径分隔符是反斜杠\二是默认编码不是 UTF-8三是终端对 ANSI 颜色支持不一致。解决路径问题很简单不要手动拼接路径用标准库的pathlib.Path。编码问题的话在进入实际业务逻辑前检查一下系统默认编码如果非 UTF-8尽量在读取时强制指定import sys if sys.stdout.encoding and sys.stdout.encoding.lower() ! utf-8: sys.stdout.reconfigure(encodingutf-8)这个处理虽然简单但能避免掉九成 Windows 上跑 Python CLI 脚本的中文字符乱码问题。5.3 输出格式混乱脚本没法接住命令行工具的输出不仅给人看也给命令看。如果输出不规范后续接管道就很痛苦。我之前在summary子命令里直接打印了带颜色和方括号的文本结果想继续传给另一个脚本做统计时还得先做一堆字符串解析。后来我统一改成这样外部程序借用的场景输出 JSON给人看的场景输出简单缩进文本只有需要强调信息的时候才加 ANSI 颜色。写工具时养成一个习惯程序自己用的数据输出默认走标准输出不要和日志打在一起。日志和调试信息走标准错误这样管道获取的数据永远是干净的。5.4 命令太长了用别名和 wrapper 脚本CLI 工作流用久了你一定会遇到一条命令特别长、参数特别多的情况。比如我需要在“本周所有纪要中筛出某个项目且包含某个关键字的记录按日期排序输出”。一开始我是这么干的weeknote summary --days 7 | grep 数据平台 | grep 接口 | sort -t -k1命令长而且每次都要敲一遍。后来我直接在 Shell 配置里加了一个函数filter_notes() { weeknote summary --days ${2:-7} | grep $1 }这样我只需输入filter_notes 接口 7就能完成同样的事。不过要提醒一句别把所有东西都堆进别名里。只有当一条命令组合确实高频、且参数相对固定的时候才值得封装成函数或脚本。否则配置里堆满了一堆所谓“方便”的别名时间长了你自己都忘了它们各自是干啥的反而增加开销。6. 踩过几次坑之后我留下的几个习惯如果让我总结一下做 CLI 工具和个人工作流最核心的几句话我会这么说第一不要追求第一次就写出完美工具。真正好用的工具是“长”出来的不是“设计”出来的。先用最笨的方式跑通再根据使用体验逐步迭代。第二把工具当作流水线来设计而不是当作软件来设计。软件追求功能完整、界面友好流水线追求每个环节简单、接口标准化、可替换。你写出的每个命令都应该能跟其他命令顺畅协作。第三文档写给你的未来自己看。很多个人工具写完之后半年没碰回头连参数怎么用都忘了。花十分钟写下“这个命令解决什么问题、怎么跑”能省下未来至少一个小时。第四优雅地接受“不完美”。很多命令初期只能处理 80% 的场景剩下 20% 需要手动补充。这是完全正常的。不必为了追求自动化的极致在工具上花过多精力否则这本身就变成了一件耗时的事违背了提效的初衷。CLI-Anything 不是让你真的用命令行做“任何事”而是让你在做“重复的事”时永远多一个“命令行方案”的备选项。这个备选项不一定每次都更快但它能留下记录、能被重复执行、能被组合扩展。从这个角度看花一点时间驯化自己的终端还是挺划算的。