CLI-Anything实战：用Python和Click把重复操作收进终端

“CLI-Anything”这个名字看起来像要把整个世界塞进终端实际上我最近花了两周真的把日常八成以上的重复操作都搬进了命令行批量改文件名、整理归档目录、调外部接口、存临时笔记、顺带检查服务连通性。起因很简单——每周五整理报告的流程太折磨人打开文件管理器手动改几个带日期前缀的文件再去在线工具合并PDF最后打开内部系统上传归档全程至少三个窗口、五六次点击中途只要有一个文件名不规范整套动作就要重来一遍。我决定按照技术社区里常说的“一切皆可命令行”思路给自己搭一个统一入口让所有能固化的操作都变成一条命令。这个项目就叫CLI-Anything不是什么现成的明星软件而是我自己维护的一套工作流核心就一句话任何重复能做的事都应该能用一行命令完成。这篇博客把我从需求拆解、技术选型、代码实现到真实踩坑的完整过程都整理了出来给同样折腾终端、想提升操作效率的朋友一个可照抄的参考。1. 先把“CLI-Anything”想清楚它不是单一工具而是一套工作流1.1 真正的需求不是“做一个CLI”而是“减少切换成本”做技术的人很容易陷入一个误区看到某个概念很酷就想去复刻一个全功能版本结果造了个自己每月都用不上的“大轮子”。我最早构思CLI-Anything时给它的名单列了二十多个功能从天气查询到汇率转换、从Markdown转PDF到端口扫描样样都想塞进去。后来真正跑起来发现这些功能里有大半我几个月都碰不到一次它们除了让帮助信息显得很壮观之外毫无意义。把需求重新收敛后核心只剩一个词减少切换成本。所谓切换成本就是你完成一件事时从A工具切到B工具、从一个窗口跳到另一个窗口、从键盘换成鼠标的代价。过去处理报告归档我至少要在文件管理器、在线PDF工具和公司内部系统之间来回三次哪怕只是给一个文件改名也得先选中、右键、重命名、输入、回车整套流程在命令行里可以用一条命令直接覆盖。这不是“三件事变成三行命令”这么简单——真正的价值在于这三行命令能写进同一个脚本挂到定时任务里从此每周五下午我只用看一眼运行日志而不用亲手重复一遍。所以在动手之前先用一句话定义你的项目CLI-Anything不是要做一个“什么都能干的工具”而是要把“那件每周都要干三遍的事”变成一条不会再出错的命令。功能可以慢慢加方向一旦错了后面每多写一行代码都是在增加负担。1.2 三个设计原则单一入口、幂等优先、可管道化我给自己定了三条原则之后所有子命令都围绕它们展开。第一是单一入口。所有命令都通过主程序调用不散落在一堆独立脚本里。这个原则最大的好处不是“显得统一”而是让你不需要记忆脚本的存放路径。我见过同事在自己的用户目录里堆了十几个.cmd文件名字还是“aaa”“bbb”这种过两周自己都分不清哪个是干嘛的。入口收敛之后anything --help就是全部能力清单新功能加了什么看帮助信息一目了然。第二是幂等优先。幂等就是同一个命令跑两遍和跑一遍结果完全一致。批量重命名是典型的场景第一次跑把2024-01-01改成2024_01_01如果你手一滑又跑了一次命令必须能判断出这些文件“已经是目标状态”然后跳过不能重复加变换更不能抛异常。很多命令行工具没想这一层跑第二次要么疯狂报错要么又把结果改回原样。我调整设计时养成了个习惯每个操作先检查目标状态已经满足就直接跳过没满足才执行最后把“实际改动数量”和“跳过数量”输出出来。这等于给命令加了一层安全兜底。第三是可管道化。每个子命令尽量遵循Unix哲学从标准输入读数据把结果写到标准输出错误信息走标准错误输出。这条原则让CLI-Anything的价值放大了十倍因为系统里已有的 grep、jq、sort、awk 全部可以直接接在后面。具体怎么做到后面3.5小节有代码说明这里先记住结论一个能用管道和其他工具组合的命令比一个孤立的“专用按钮”强得多。2. 落地前的准备工作环境、语言与三个关键组件2.1 为什么选择Python Click shell脚本的组合有人可能会问为什么不直接用 Go、Rust 或者纯 Shell我的选择基于三个点开发速度、生态、团队可读性。Go 编译成单个二进制确实很爽部署也干净但每加一个子命令都要重新折腾编译流程调试成本明显更高。纯 Shell 写简单胶水很快可一旦要处理 JSON、HTTP 重试、SQLite 存储代码会迅速变成“保安看不懂、自己也改不动”的字符串地狱。Python 在这两者之间是最优解——它能用最少的代码把逻辑表达清楚而且任意一个写过几年脚本的同事都能在五分钟内看懂你在做什么。命令行参数解析我选了 Click 而不是标准库 argparse。不是说 argparse 不行而是命令一多嵌套add_parser的缩进层次会越来越深帮助信息、默认值、参数校验都要手工补维护成本高。Click 用装饰器来声明命令一个函数就是一个子命令结构直观自动生成的--help也接近专业 CLI 工具的水准。至于更新的 Typer它依赖类型注解理念确实先进但强绑定 pydantic对于一个小规模个人工具来说有点用力过猛。综合下来Click 是“刚刚好”的那个选项。shell 脚本在这里的角色是胶水。Python 负责具体的功能逻辑shell 负责把系统命令和 CLI-Anything 粘成一条流水线。实际项目里我大量用到set -euo pipefail这能保证脚本里任何一步失败都会立刻终止而不是带着错误继续跑下去这比在 Python 里写一堆异常处理都更省心。2.2 目录结构与命名规范CLI-Anything 的项目结构一开始必须简单简单才能持续维护。我最终的目录长这样~/cli-anything/ ├── anything.py # 统一入口Click Group ├── pyproject.toml # 安装配置生成 anything 命令 ├── config.example.yaml # 示例配置 ├── .gitignore # 忽略配置文件、存储、日志 ├── commands/ │ ├── __init__.py │ ├── file_ops.py # 文件操作子命令 │ ├── api_calls.py # HTTP 调用子命令 │ └── note_mgr.py # 笔记管理子命令 ├── storage/ │ └── notes.db # SQLite 数据库自动生成 └── logs/ └── cli-anything.log # 运行日志这个结构把入口、子命令、数据、日志分得很清楚。新增一个功能时只需要在commands/下新建一个文件然后在anything.py里加两行——import 对应模块再add_command挂到主入口。不需要改其他任何东西。命名规范是“动词 对象”。比如file batch-rename、api call、note new、note search。这样做的好处是记忆成本低你想操作文件敲anything file --help系统会列出所有文件相关操作你想调接口敲anything api --help。不要用晦涩的缩写宁可命令长一点也要让人一眼看懂。2.3 配置和密钥安全别让一个小失误毁掉整个项目命令行工具看起来比网页后端“轻”但安全习惯一点不能省。我一开始图省事把 API token 直接硬编码在脚本里觉得“反正只有我自己用”。结果项目迭代到第二周整个目录被同步到另一台机器token 就跟着仓库走了最后只能作废重发。那次教训之后我定下了两条规矩。配置统一放在 YAML 文件里只放非敏感信息比如存储目录路径、日志文件位置、外部接口地址。密钥一律从环境变量读取或者从.env文件加载并且.gitignore里必须包含config.yaml、.env、storage/、logs/。代码中集中管理配置的做法大概是这样的import os from pathlib import Path import yaml def load_config(): config_path Path(os.environ.get(CLI_ANYTHING_CONFIG, config.yaml)) with open(config_path) as f: cfg yaml.safe_load(f) cfg.setdefault(api_key, os.getenv(CLI_ANYTHING_API_KEY, )) return cfg如果你的机器上确实需要存一份真实的.env记得把文件权限调成600仅属主可读写。别人能看到你的配置不可怕可怕的是密钥跟着 Git 仓库进了历史记录那才是真正覆水难收的地方。这个坑我在第4部分会再展开一次因为它真的值得反复强调。3. 核心实现一步步搭出你的命令行工具箱3.1 统一入口用Click做命令路由入口文件是anything.pyClick 的所有能力都从这里发起。为了保证-h也能触发帮助信息我设置了help_option_names为了保证在 Click 8 之后版本里子命令能共享全局状态我显式调用了ctx.ensure_object(dict)。import click from commands import api_calls, file_ops, note_mgr CONTEXT_SETTINGS dict(help_option_names[-h, --help]) click.group(context_settingsCONTEXT_SETTINGS) click.version_option(version0.1.0, prog_nameCLI-Anything) click.option(--verbose, is_flagTrue, help输出调试日志) click.pass_context def cli(ctx, verbose): CLI-Anything把一切重复操作收进终端。 ctx.ensure_object(dict) ctx.obj[verbose] verbose cli.add_command(file_ops.file) cli.add_command(api_calls.api) cli.add_command(note_mgr.note) if __name__ __main__: cli()这段代码的作用是搭出一棵命令树cli是根file、api、note是三个枝干每个枝干下面再挂具体动作。ctx.obj是这个树上的“公共背包”入口里定义的--verbose开关可以通过它传递给任意子命令不需要每个子命令都重新声明一遍。这里推荐使用pip install -e .而不是直接运行python anything.py因为后者在from commands import ...时极容易遇到模块路径问题。最简单的安装配置写在pyproject.toml里[build-system] requires [setuptools61] build-backend setuptools.build_meta [project] name cli-anything version 0.1.0 [project.scripts] anything anything:cli执行pip install -e .之后系统里就会多出一个anything命令这才是真的把它当成一个工具在用而不是每次都要在项目目录里找脚本。3.2 文件批量重命名子命令安全第一文件操作是 CLI-Anything 最常用的模块。我以批量重命名为例展示怎么把“安全第一”落到实处。import re import click from pathlib import Path click.group() def file(): 文件相关操作。 file.command(batch-rename) click.argument(directory, typeclick.Path(existsTrue)) click.option(--separator, default-, help日期统一后的分隔符如 - 或 _) click.option(--dry-run, is_flagTrue, help只预览不实际改动) click.option(--recursive, is_flagTrue, help递归处理子目录) def batch_rename(directory, separator, dry_run, recursive): 把文件名里的日期格式统一为指定分隔符。 root Path(directory) pattern r\d{4}[-_]\d{2}[-_]\d{2} changed 0 skipped 0 files root.rglob(*) if recursive else root.iterdir() for f in files: if not f.is_file(): continue old_name f.name if not re.search(pattern, old_name): continue new_name re.sub( pattern, lambda m: m.group(0).replace(-, _).replace(_, separator), old_name ) target f.with_name(new_name) if target f: skipped 1 continue if target.exists(): click.echo(f跳过目标文件已存在 {target.name}, errTrue) skipped 1 continue if dry_run: click.echo(f[dry-run] {old_name} - {new_name}) else: f.rename(target) click.echo(f重命名{old_name} - {new_name}) changed 1 click.echo(f完成改动 {changed} 个文件跳过 {skipped} 个。)这段代码里有三个细节值得单独说。第一使用Path.with_name(new_name)而不是手动拼字符串是为了避免 Windows 下路径分隔符和文件名拼接的各种坑。第二新增了--dry-run选项执行前先把所有将要发生的改动打印出来确认无误后再去掉--dry-run真正跑。第三正则替换把整个日期片段作为一个整体只统一分隔符不碰文件名里其他部分避免把项目名或编号改坏。执行示例anything file batch-rename ~/reports --separator _ --recursive --dry-run效果是把2024-01-05_周报.txt、2024_01_06_日报.md这类文件里的日期统一成2024_01_05或2024_01_06同时预览所有改动。这套逻辑也顺势满足了第1部分说的“幂等优先”第二次再跑所有文件已经符合目标格式会被target f直接跳过。3.3 通用API调用子命令灵活但不过度CLI-Anything 的一个重要定位是“调接口别再开 Postman”。我用一个通用的api call子命令覆盖 80% 的日常调试场景。import json import sys import time import click import requests click.group() def api(): HTTP 接口相关操作。 api.command(call) click.argument(url) click.option(--method, defaultGET, show_defaultTrue, helpHTTP 方法) click.option(-H, --header, headers, multipleTrue, help自定义请求头格式Key: Value) click.option(-d, --data, defaultNone, helpJSON 请求体传 - 从stdin读取) click.option(--timeout, default10, show_defaultTrue, help超时时间秒) click.option(--insecure, is_flagTrue, help跳过TLS证书校验仅调试用) click.option(--verbose, is_flagTrue, help显示响应头、耗时等信息) click.option(--raw, is_flagTrue, help不格式化JSON直接输出原始响应体) def api_call(url, method, headers, data, timeout, insecure, verbose, raw): 一条命令发起 HTTP 请求自动格式化 JSON 输出。 header_dict {} for item in headers: key, _, value item.partition(:) header_dict[key.strip()] value.strip() if data -: data sys.stdin.read() payload json.loads(data) if data else None try: start time.monotonic() resp requests.request( method.upper(), url, headersheader_dict, jsonpayload, timeouttimeout, verifynot insecure, ) elapsed time.monotonic() - start except requests.exceptions.Timeout: click.echo(f请求超时{timeout}s{url}, errTrue) raise SystemExit(1) except requests.exceptions.RequestException as exc: click.echo(f请求失败{exc}, errTrue) raise SystemExit(1) if verbose: click.echo(fHTTP {resp.status_code} 用时 {elapsed:.3f}s, errTrue) if raw: click.echo(resp.text, nlFalse) else: try: body resp.json() click.echo(json.dumps(body, ensure_asciiFalse, indent2)) except ValueError: click.echo(resp.text) if resp.status_code 400: raise SystemExit(1)这里有几个容易忽略的细节。第一requests如果不显式设置timeout默认会无限等待很多“命令像卡死一样”的问题都出在这里所以我给了 10 秒的默认值。第二报错信息走errTrue的stderr避免污染 stdout 里的 JSON 数据--verbose的耗时信息也走 stderr这样管道下游拿到的永远是干净的响应体。第三--raw选项保证原始返回结果可以原样交给其他命令处理比如接jq。实际调用示例anything api call https://jsonplaceholder.typicode.com/posts/1 --verbose会直接打印格式化后的 JSON并在 stderr 显示HTTP 200 用时 0.231s。如果接口返回非 2xx 状态码命令本身会以退出码 1 结束方便混在 shell 脚本里做失败判断。3.4 笔记管理子命令用SQLite存下零散灵感笔记管理乍看和“CLI”不太搭但恰恰是这种轻量功能最能提升日常使用频率。我不需要什么富文本编辑器只需要能快速记一条带标题的碎片信息然后能搜到它。SQLite 零配置、单文件是这种情况下的完美选择。import sqlite3 from pathlib import Path import click DB_PATH Path(__file__).resolve().parent.parent / storage / notes.db def get_conn(): DB_PATH.parent.mkdir(parentsTrue, exist_okTrue) conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS notes ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, body TEXT DEFAULT , created_at TEXT DEFAULT (datetime(now, localtime)) ) ) return conn click.group() def note(): 本地笔记管理。 note.command(new) click.argument(title) click.option(--body, default, help笔记正文或直接粘贴在命令行) def new_note(title, body): conn get_conn() conn.execute(INSERT INTO notes (title, body) VALUES (?, ?), (title, body)) conn.commit() conn.close() click.echo(f已保存笔记{title}) note.command(search) click.argument(keyword) def search_note(keyword): conn get_conn() rows conn.execute( SELECT id, title, created_at FROM notes WHERE title LIKE ? OR body LIKE ? ORDER BY id DESC LIMIT 20, (f%{keyword}%, f%{keyword}%) ).fetchall() conn.close() for rid, title, created_at in rows: click.echo(f#{rid} [{created_at}] {title}) note.command(list) click.option(--limit, default10, show_defaultTrue, help显示最近多少条) def list_notes(limit): conn get_conn() rows conn.execute(SELECT id, title, created_at FROM notes ORDER BY id DESC LIMIT ?, (limit,)).fetchall() conn.close() for rid, title, created_at in rows: click.echo(f#{rid} [{created_at}] {title})使用体验就是开会时随手anything note new Q3计划要点 --body 重点一降低切换成本过了三天想找相关记录敲anything note search 成本就能捞出来。数据库文件自动建在storage/下面以后备份整个目录就等于备份了全部笔记。不要低估这个简单功能它是让 CLI-Anything 经常出现在你日常操作中的黏合剂。3.5 管道的纪律让命令可以被继续组合一个命令能不能和其他工具组合取决于它是否严格遵守 stdout 纪律。我给 CLI-Anything 立了一条规矩主数据永远只输出到 stdout所有提示、日志、错误信息一律走 stderr。上面代码里的errTrue就是这个纪律的体现。一旦规矩立住了组合就变得很自然。比如anything api call https://jsonplaceholder.typicode.com/posts --raw --method GET | jq .[] | select(.id 5) | .title还有更实用的场景先用find收集一批目录名再用管道生成一个 JSON 数组最后 POST 给自己的内部接口。这个场景下一节展开这里想说的是--data -这个约定——当-d后面的值是-时脚本从 stdin 读取数据而不是从命令行参数读取。它让 CLI-Anything 能和上游命令无缝衔接而不需要中间先生成临时文件。echo {name:test} | anything api call https://httpbin.org/post --method POST -d -这使得“CLI-Anything”从单纯的一堆命令变成了整个 shell 工作流里可被自由插入的一环。4. 实操过程中的真实踩坑记录与排查技巧4.1 Click版本差异ctx.obj 不再自动初始化CLI-Anything 刚搭好的时候运行一切正常后来一次升级环境所有子命令突然报AttributeError: NoneType object has no attribute get。排查了半天发现是 Click 版本从 7 升到了 8ctx.obj不再被自动初始化为dict了。在早期版本里只要在入口装饰器上传了objdict()或者干脆什么都不传ctx.obj也会自动变成一个字典但新版里这个行为被改了必须显式ctx.ensure_object(dict)。这个问题没太多技术含量但特别容易耽误时间。解决之后我也养成了一个习惯用python -c import click; print(click.__version__)先确认版本再统一用ctx.ensure_object(dict)的方式访问全局状态这个写法在 Click 7 和 8 里都是兼容的。4.2 Windows下正则参数被命令行“吃掉”在 Windows 的 PowerShell 里跑anything file batch-rename . --pattern \d{4}这类命令时正则里的反斜杠和花括号经常被 shell 提前解释导致实际传进 Python 的 pattern 已经不是你想的那个样子。表现形式为匹配不到任何文件或者匹配到了意外的文件。这个问题的根源不在 Python而在 shell 的转义规则。我的应对有三层第一把所有可能涉及正则的参数尽量设计成简单选项比如上面--separator只有-和_两种选择绕开正则边界第二在代码里加一条调试输出像click.echo(f匹配规则{pattern}, errTrue)先确认参数到达脚本时的真实值第三如果确实需要用复杂正则在命令行传参用单引号包住整个表达式或者用环境变量中转一次。4.3 HTTP请求像“卡死”一样等半天第一次用api call调一个内网接口时命令敲下去之后没有任何输出光标一直停在那里我还以为是网络断了。查了下发现是requests默认不设超时时间连接一旦处于半死状态它能等很久很久。这个问题在api call里已经被默认的--timeout 10解决但类似现象还可能出现在 DNS 解析上——如果域名解析很慢即使设置了timeout可能也会先卡在解析阶段。处理方式是分两层一是在代码里显式设置超时二是在 shell 层面再用外部命令兜底像 Linux 上可以用timeout 15 anything api call ...给整个命令再加一道保险。命令行工具最大的优点就是能被外部工具限速、限时、重试充分利用这一点健壮性会明显提升。4.4 密钥泄漏后的处理别只改配置文件我在2.3里提过那个 token 事故这里详细说下后续处理。发现问题时第一反应肯定是把脚本里的 token 删掉、换成环境变量但如果你在 Git 仓库里提交过包含 token 的文件仅仅修改当前版本是不够的历史记录里还留着地雷。别人 clone 这个仓库时翻一下提交历史就能看到明文密钥。正确做法分三步第一步立即到服务端撤销该 token这是止损的第一动作第二步清理本地 Git 历史把包含密钥的提交从历史里彻底移除可以用git filter-repo这类的工具操作第三步如果仓库已经推到了远端且有其他协作者最好直接重置仓库或立刻通知每个人同步处理。整个过程最痛的领悟就是密钥一旦提交进 Git宁可当作已经泄露也不要抱“应该没人看到”的侥幸。4.5 “命令不存在”的幽灵Shell别名与PATH顺序有段时间anything命令在 zsh 里突然“不存在”了报command not found。检查 path、重新安装都不对最后发现是 zsh 的 alias 机制拦截了命令名——某个配置里alias anythingls之类的残留把命令替换掉了。这个坑很有迷惑性因为用which anything查的时候它返回“not found”但其实不是路径问题而是 alias 在命令解析之前就把名字给吞了。遇到这种“明明装了却找不到”的情况不要只查which要查type -a anything它会列出该命令在 shell 里的所有解析形态别名、函数、内建命令、外部命令。如果发现别名或者函数抢在前面清理对应 shell 配置文件即可。这个排查思路适用于任何新安装的命令行工具。4.6 常见问题速查表现象可能原因快速排查方法子命令里读不到全局变量Click 8 未自动初始化 ctx.obj统一使用ctx.ensure_object(dict)正则在 Windows 下匹配失败反斜杠/花括号被 shell 转义使用单引号包裹或改成简单选项接口请求长时间无响应requests 未设置 timeout或 DNS 解析慢给 api call 加--timeout外部再用 timeout 兜底命令提示 not foundshell 别名或 PATH 顺序问题用type -a查看解析顺序目标文件重名导致数据覆盖没有做冲突检查代码里必须判断target.exists()后跳过脚本退出码一直是0未在错误路径显式退出非零码错误时raise SystemExit(1)shell 才能感知失败这个表是最常被问到的问题集合也是我后来给别人讲这套工具时的第一页。5. 让CLI-Anything真正好用扩展思路与进阶技巧5.1 定时化从一个命令到无人值守CLI-Anything 真正让效率发生质变是在接上定时任务之后。我写了一个run_daily.sh放在项目根目录内容很朴素#!/usr/bin/env bash set -euo pipefail anything file batch-rename ~/Downloads --separator _ --recursive anything note list --limit 5然后用 crontab 挂上0 9 * * 1-5 cd ~/cli-anything ./run_daily.sh logs/daily.out 2 logs/daily.err这里有个细节crond 执行时的工作目录跟终端里不同所以脚本里要么用绝对路径要么先cd到项目目录。set -euo pipefail的作用是只要中间任何一条命令失败整个脚本立即停下来并把错误写进daily.err。这样我每天早上只需要扫一眼日志文件就能知道今天的归档任务有没有正常完成没完成时再去人工介入。5.2 组合拳配合find、git、jq完成真实任务CLI-Anything 的价值在它和其他命令行工具配合的时候才能完全释放。我每周会统计几个 Git 仓库的未提交变更数量再把结果汇总成一个 JSON 提交到内部数据接口整个过程可以写成一条流水线find ~/projects -maxdepth 3 -name .git -type d | sed s#/.git## | while read repo; do count$(git -C $repo status --porcelain | wc -l | tr -d ) echo $repo $count done | awk {printf {\repo\:\%s\,\dirty\:%s}\n, $1, $2} | jq -s . | anything api call https://your-server/collect --method POST -d - --raw这段命令把find、sed、git、wc、tr、awk、jq全部串起来最后通过api call的--data -把 JSON 从 stdin 发出去。整体看起来是“一长串魔法”但拆开看每一步都是清晰可查的先找到所有 Git 仓库再统计每个仓库的脏文件数转成 JSON 数组最后 POST 出去。这就是“可管道化”原则带来的真正红利——CLI-Anything 只是流水线上的一环而不是整个流程的垄断者。5.3 安全模式与日志全命令统一增强随着子命令越加越多我开始考虑给所有命令统一加上两个能力日志记录和安全标签。目前我的做法是在入口 group 增加一个全局的--log-file选项然后在cli函数里把 logger 配置存进ctx.obj子命令需要时从 ctx 里取。一个简单可行的统一增强思路是写一个装饰器把--dry-run这个通用选项加在所有会改变状态的命令上import functools import click def dry_run_option(f): click.option(--dry-run, is_flagTrue, help只预览不实际执行) functools.wraps(f) def wrapper(*args, **kwargs): return f(*args, **kwargs) return wrapper在file batch-rename这类命令上不需要写一行额外逻辑只要在命令函数前加上dry_run_option然后在函数内部判断dry_run为真时只打印不执行。批量工具最怕的永远是误操作而“先预览、再执行”是一个成本极低但收益极高的习惯。数据读错了可以重来数据被批量改错恢复起来就是一场灾难。5.4 还能塞进CLI-Anything的更多玩法做到了第三周我发现自己会不自觉地想“这种事是不是也能用命令行解决”。目前已经验证过、并且确实有用的扩展方向包括服务器端口检查anything srv check host --port 443封装一个 TCP 连接测试比手动 telnet 好用数据库查询anything db query select ...统一数据库连接配置不用记住每个环境的连接串文本抽取anything text extract --pattern ...对一批文件做正则抽取再配合 jq 处理剪贴板操作anything clip copy / paste在无图形界面的服务器上也能读写系统剪贴板定时提醒anything remind 开会 --at 14:00配合 cron 输出桌面通知。每一个扩展都不需要复杂的技术关键是保持“入口统一、幂等、可管道化”三条原则。功能数量不是目的当你发现自己能在五分钟内把一个重复了十几次的操作固化成一条命令时CLI-Anything 就已经值回票价了。最后再分享一点自己的体会。这项目规模不算大代码量也不惊人但它在三个月里实打实地帮我省出了大量时间更重要的是让我对重复操作有了掌控感——每个每周都要跑的任务我都能清楚知道它的输入、输出和失败时的行为。如果你手头也散落着一堆脚本与其急着写新功能不如先给它们一个统一入口。工具不怕简单怕的是散。把散落的命令收拢到一条anything后面这本身就是一次效率升级。