从散装脚本到统一命令：用Python构建CLI-Anything工具集

从“脚本散落”到“一切皆可命令”：我的 CLI-Anything 工具集构建手记

每个干了三五年的开发、运维或者技术博主，电脑里多少都有点“私房脚本”：批量改文件名的、调接口查数据的、一键起服务的、生成项目模板的……最开始可能是几个.sh文件，后来越写越多，散落在~/bin、~/scripts、项目根目录甚至某个记不清的文件夹里。到头来，真正用的时候常常是这种情况：想找个脚本，得先“grep 自己”，找到之后还得先读一遍源码，才想起来这玩意儿到底要传什么参数。

“CLI-Anything”这个词在圈子里火起来，其实反映的就是这个痛：我们真正需要的不是一个又一个孤立的脚本，而是一个“把任何操作都变成一条命令”的统一入口。你不管底层是 Python、Node、Shell 还是 curl，对用户来说只有一条路：anything <命令> <参数>。这篇文章，就是我从一个“脚本收藏家”变成一个“命令封装强迫症患者”的完整经验总结。我会把整套 CLI 框架的设计思路、核心实现、实战封装案例和踩坑记录都摆出来，适合那些已经写过不少脚本、但还没花时间把它们“收编成军”的开发者参考。

1. 内容整体设计与思路拆解：为什么需要“统一命令入口”

1.1 散装脚本的三大痛点：检索、记忆、复用

先说个真实场景。我原来有个scripts目录，里面有类似这样的东西：

  • rename_all_v3_final.py（你看这名字就知道改了多少版）
  • check_api.sh（参数飘忽，有时候传 URL，有时候直接读文件）
  • start_server.py（只在公司内网用，端口写死在代码里）
  • create_blog_post.py（只在一台机器上配置对了）

这些脚本单独看都没问题，但放在一起就有三个很要命的问题：

第一，检索成本高。脚本一多，命名是最大的玄学。有人喜欢tool_x.py，有人喜欢xTool.sh，还有的直接叫aaa.py占位。等你想用一个脚本，发现根本不知道这个功能有没有被实现过，往往就重新写了一份。最后系统里一大堆功能重复、实现各异的脚本，连删都不敢删。

第二，记忆成本高。每个脚本的参数都是自己定的，有的用-f传文件名，有的用--file，有的干脆用位置参数$1。你不可能记住每个脚本的参数格式，于是每次用之前都要--help一下。如果脚本写的粗糙，连 help 都没有，就得打开源码数sys.argv。

第三，复用成本高。脚本之间没法互相调用。我在 A 脚本里写的日期处理函数，在 B 脚本里想复用，只能import或者复制粘贴——一粘贴就会有分歧，A 脚本修了一个 bug，B 脚本还是旧的。

CLI-Anything 要解决的，正是上面三件事。它不是一个具体的工具，而是一套约定：所有命令统一注册、统一参数解析、统一帮助信息、统一输出格式。你不再需要记住“哪个脚本叫什么”，只需要知道“我想干什么”，然后用anything 功能名去调用就行。

1.2 技术选型：为什么用 Python 做“胶水层”

做统一 CLI 入口，语言选型上其实有几个选项：

方案优点缺点适用场景
纯 Shell 脚本零依赖、进程管理方便参数解析弱、数据结构处理差、跨平台差简单系统管理
Node.js异步 IO 强、生态丰富依赖安装较重、单文件脚本不够轻快前端工具链
Go编译单二进制、分发方便每次加命令要重新编译、上手成本略高对外分发安装
Python开发效率高、文本处理强、argparse/typer 成熟需要解释器环境个人/团队内部工具集

我最终选了 Python，而且这套框架可以直接装在系统里，放下方代码即可用。原因很直接：Python 是“开发效率和表达能力”的均衡点。我需要处理 JSON、YAML、文件枚举、HTTP 请求，这些活儿用 Shell 写会想骂人，用 Node 写有点“杀鸡用牛刀”，用 Go 呢——我每加一个小命令都要重新 build，太费事。CLI-Anything 这种“快速把散装脚本收编成规范命令”的场景，Python 的Typer/argparse生态可以让我把 90% 的精力放在命令逻辑本身，而不是框架上。

注意这里的取舍：如果你是要做一个对外分发的商业化 CLI 工具，我建议直接上 Go，因为用户端不用装 Python 环境。但如果你是给自己、自己的团队用的内部工具集，Python 的灵活性和开发速度无可匹敌。方向不同，选型不同，别强行套用。

1.3 核心设计理念：约定大于配置

我的 CLI-Anything 设计遵循三条约定，这是整套框架的灵魂：

  1. 一个入口，N 个命令：所有功能都是anything <命令名>的子命令，不存在“单独执行某个脚本”的情况。
  2. 命令即函数：每个命令就是一个 Python 函数，参数签名就是 CLI 参数。def rename_files(path: str, prefix: str)会直接变成anything rename-files ~/test --prefix "abc"。
  3. 可插拔注册：新增命令不需要改入口文件，只要把新模块放到约定目录，或者用装饰器标注一下，就能被自动发现。

有了这三条约定，整个框架的扩展性就闭合了。你后续的每一个新脚本，都不再是“往 scripts 目录扔一个文件”，而是“往命令仓库里提交一个插件”。从开发习惯到心智模型，这才是真正的升级。

2. 核心细节解析与实操要点：命令注册、参数解析与配置管理

2.1 命令注册的两种机制：装饰器与目录扫描

CLI-Anything 的注册机制是整个框架的“地基”。我实现了两种，分别对应不同场景。

机制一：装饰器注册（显式）

适合命令数量少、需要精细控制的情况。核心代码长这样：

# registry.py import importlib import pkgutil import inspect from collections import OrderedDict _COMMANDS = OrderedDict() def command(name: str): """装饰器：将一个函数注册为 CLI 命令""" def decorator(func): _COMMANDS[name] = func return func return decorator def get_all_commands(): return _COMMANDS

用起来非常直接：

# commands/hello.py from registry import command @command("hello") def hello(name: str, greeting: str = "Hello"): """Say hello to someone.""" print(f"{greeting}, {name}!")

@command("hello")一挂，函数签名直接变成命令行参数。str类型对应字符串参数，带默认值的参数自动成为可选参数。

机制二：目录扫描（隐式）

适合命令多、每个命令独立成文件的场景。核心逻辑是用pkgutil.iter_modules遍历commands包下的所有模块，自动发现所有用@command注册的函数：

# main.py import pkgutil import importlib import commands from registry import get_all_commands def discover_commands(): """自动导入 commands 包下所有模块，触发装饰器注册""" for mod_info in pkgutil.iter_modules(commands.__path__): importlib.import_module(f"commands.{mod_info.name}") def main(): discover_commands() # 之后从 get_all_commands() 里查命令并执行

这两种方式不是互斥的。需要“隐藏命令”“特殊逻辑”时用显式注册；需要“丢一个 .py 文件就生效”时用目录扫描。我推荐默认用目录扫描，因为新增命令的成本最低——你只要新建commands/xxx.py，写好函数、挂上装饰器，不需要改动任何入口代码，重启一下命令就出现了。

2.2 参数解析：让函数签名告诉你“怎么传参”

CLI-Anything 的核心魔法在于，它可以把 Python 函数的类型注解直接翻译成 argparse/Typer 的参数定义。我用的是 Typer 作为底层解析器，但做了一层薄封装，让它更贴合“函数即命令”的体验。

不用 Typer 也可以，因为思路是一样的。以 Typer 为例，上面的 hello 函数会自然变成：

anything hello alice # 输出 Hello, alice! anything hello alice --greeting Hi # 输出 Hi, alice! anything hello --help # 显示完整参数说明

这里有几个关键点值得展开：

参数类型的自动映射。函数注解name: str会变成字符串参数，count: int = 1会变成整型参数，verbose: bool = False会自动变成--verbose/--no-verbose开关。你可以直接用 Python 原生类型表达参数格式，不用手写add_argument()。

命名风格转换。Python 函数参数习惯用snake_case（下划线风格），但 CLI 参数惯例是kebab-case（短横线风格）。Typer 默认帮你做这种转换：project_path: str在命令行里是--project-path而不是--project_path。默认用户不用理解什么 snake/kebab 这类概念，直接用最顺手的风格就行。

依赖注入的隐藏价值。如果你一个命令需要读配置文件，你不再需要命令自己去open配置文件、解析 YAML、处理缺省值。你直接在参数列表里声明一个ctx: ProjectContext类型的参数，框架自动从全局配置构建好这个对象传进来。这就是依赖注入带来的好处——命令逻辑与配置细节彻底解耦。

2.3 配置管理：密钥、路径、环境差异的优雅处理

CLI 工具最烦人的就是“换了台机器就不能跑”，因为配置散落在代码里。CLI-Anything 对配置做了三层分级：

  1. 默认配置（defaults.yaml）：所有机器一致的公共参数，比如日志格式、超时时间。
  2. 用户配置（~/.config/anything/config.yaml）：跟个人习惯相关的，比如默认编辑器、默认输出目录。
  3. 环境变量 /.env文件：所有敏感信息（API Key、数据库密码、内部接口 Token）全部从这里读，绝不进代码仓库。
# config.yaml log_level: INFO output_dir: ~/Downloads api_token_env: ANYTHING_API_TOKEN # 从环境变量里取

在代码里读取的优先级是：环境变量 > 用户配置 > 默认配置。比如默认配置里output_dir: ~/output，用户配置里改成了~/Downloads，那实际拿到的是用户配置的值。如果你在 shell 里设置了ANYTHING_OUTPUT_DIR=/tmp/x，那/tmp/x的优先级最高。

这一套设计下来，同一个命令在不同环境的表现基本一致，唯一差异都集中在配置层，而不是代码层。

3. 实操过程与核心环节实现：五个真实场景的封装实录

3.1 场景一：批量重命名文件（文件处理）

第一个实战案例是批量重命名。这个场景特别适合展示“参数即逻辑”的设计思路。

# commands/rename.py import re from pathlib import Path from registry import command @command("rename") def rename_files( path: str, pattern: str = r"", replace: str = "", prefix: str = "", ): """ Batch rename files in a directory. 支持两种模式： 1. --pattern/--replace 正则替换 2. --prefix 加前缀 """ target_dir = Path(path).expanduser() if not target_dir.exists(): raise ValueError(f"目录不存在: {target_dir}") for file_path in sorted(target_dir.iterdir()): if not file_path.is_file(): continue new_name = file_path.name if pattern: new_name = re.sub(pattern, replace, new_name) if prefix: new_name = prefix + new_name if new_name == file_path.name: continue new_path = file_path.with_name(new_name) file_path.rename(new_path) print(f"重命名: {file_path.name} -> {new_name}")

使用示例：

# 把所有图片文件名里的空格全部去掉，并加上 vite_ 前缀 anything rename ~/Pictures/scan --pattern "\s+" --replace "" --prefix "vite_" # 把 log_20240101.txt 这类文件的时间戳去掉 anything rename ~/logs --pattern "_\d{8}" --replace ""

这个命令的开发加测试总共用了不到十分钟。关键是：你以后再也不需要为了“批量重命名”去百度“Linux 批量重命名工具”，也不需要去下载一个 GUI 改名软件。一条anything命令，永久解决问题。

3.2 场景二：调用内部 API 查数据（HTTP 交互封装）

第二个场景是调内部接口。这个需求在开发日常里太常见了：联调阶段查订单状态、查用户数据、触发某个任务。每次都去 curl 里敲一长串带认证头的命令，很快就会放弃。

# commands/api.py import os import httpx import json from registry import command @command("api") def call_api( endpoint: str, method: str = "GET", data: str = None, ): """Call an internal API with unified auth.""" base_url = os.getenv("ANYTHING_API_BASE", "http://localhost:8000") token = os.getenv("ANYTHING_API_TOKEN", "") headers = {"Authorization": f"Bearer {token}"} if token else {} url = base_url.rstrip("/") + "/" + endpoint.lstrip("/") with httpx.Client(timeout=15) as client: resp = client.request(method, url, json=json.loads(data) if data else None, headers=headers) print(json.dumps(resp.json(), ensure_ascii=False, indent=2)) if resp.status_code >= 400: raise SystemExit(f"请求失败: {resp.status_code}")

使用示例：

# 查询订单 12345 状态 anything api orders/12345 # 创建一条测试任务（POST 方式，Body 是 JSON） anything api tasks --method POST --data '{"name": "测试任务", "priority": "high"}'

关键细节在于base_url和token都从环境变量读取。团队成员只要在自己的.env里配好ANYTHING_API_BASE和ANYTHING_API_TOKEN，就可以共享同一条命令，不需要在聊天工具里传 URL 和 Token。Token 不会出现在 shell 历史里，也不会被写进alembic之类的迁移脚本里。

实操心得：用httpx.Client(timeout=15)而不是 requests，是因为 httpx 默认支持 HTTP/2 和超时控制，接口慢的时候不至于悬挂。如果你在 Python 3.10 以下版本上跑，把http库换成requests即可，整体逻辑不变。

3.3 场景三：一键启动/停止本地服务（子进程管理）

第三个场景是本地服务管理。开发的时候要起后端、起前端、起 Redis、起队列 worker，环境五花八门。CLI-Anything 可以把它们统一成一个命令。

# commands/dev.py import subprocess import sys import time from pathlib import Path from registry import command SERVICES = { "backend": ("python", "manage.py", "runserver"), "worker": ("celery", "-A", "proj", "worker"), "web": ("npm", "run", "dev"), } def _find_project_root(): """从当前目录向上找到项目根（包含 .git 的目录）""" current = Path.cwd() for parent in current.parents: if (parent / ".git").exists(): return parent raise FileNotFoundError("无法定位项目根目录，请在项目内运行") @command("dev") def dev_service(service: str, action: str = "start"): """启动/停止本地开发服务。例如 anything dev backend""" if service not in SERVICES: print(f"可选服务: {', '.join(SERVICES)}") raise SystemExit(1) root = _find_project_root() cmd = list(SERVICES[service]) log_file = root / "logs" / f"{service}.log" log_file.parent.mkdir(exist_ok=True) if action == "start": with open(log_file, "ab") as f: proc = subprocess.Popen(cmd, cwd=root, stdout=f, stderr=f, text=True) print(f"{service} 已启动，PID={proc.pid}，日志: {log_file}")
elif action == "stop": result = subprocess.run(["pkill", "-f", cmd[0] + " " + cmd[1]], capture_output=True) if result.returncode == 0: print(f"{service} 已停止") else: print(f"{service} 好像没在跑")

使用效果：

anything dev backend start anything dev worker start anything dev web start anything dev backend stop

也许有人会说“这不是有 docker compose 吗？”而本地开发场景恰恰是最不需要 Docker 的：你改了代码，要的是即时热加载，不是镜像重启。CLI-Anything 在这里的价值是，把团队的“怎么起服务”从口头传话变成了可执行命令。

3.4 场景四：生成项目脚手架（模板渲染）

最后一个高频场景是脚手架。每开始一个新模块、新页面、新微服务，都有固定的文件结构要搭。写文档的时候说“创建试一下”很简单，真搭起来目录一堆、文件一长串，脚本也要写很久。封装成命令后体验完全不同。

# commands/scaffold.py import string import pathlib from registry import command @command("scaffold") def create_scaffold( kind: str, name: str, **kwargs, ): """生成项目模板。支持 page / module / service""" templates = { "page": [ ("templates/page.txt", "frontend/src/pages/{name}/index.tsx"), ("templates/page-style.txt", "frontend/src/pages/{name}/index.css"), ], "module": [ ("templates/module.txt", "src/modules/{name}/__init__.py"), ("templates/module-code.txt", "src/modules/{name}/core.py"), ], } for src, dst in templates.get(kind, []): src_path = pathlib.Path(__file__).parent / src content = src_path.read_text(encoding="utf-8") content = string.Template(content).safe_substitute(name=name, **kwargs) dst_path = pathlib.Path.cwd() / dst.format(name=name) dst_path.parent.mkdir(parents=True, exist_ok=True) dst_path.write_text(content, encoding="utf-8") print(f"生成: {dst_path}")

用起来就是：

anything scaffold page UserProfile

框架设计的目的不是让你“背命令地址”，而是让你“把命令做得足够好用”。当anything scaffold page Xxx成为团队的肌肉记忆时，新同学上手项目就少了一个“猜目录结构”的环节，效率提升是实实在在的。

3.5 场景五：集中式工具集目录规划

工具集规划得清晰，命令再多也不会乱。我个人把anything的命令分了四个维度：

维度说明代表命令
文件操作处理和当前项目相关的文件rename、scaffold、clean
开发辅助本地服务、环境管理、依赖检查dev、env、deps
数据查询读写内部 API、查日志入库api、log、sql
运维发布部署、回滚、状态确认deploy、rollback、status

这个分类不是死规矩，它的作用只是让你新增命令的时候能快速判断应该放到哪个模块、用什么样的命名前缀。比如你想加一个“清理 Python 缓存文件”的命令，自然会想到anything clean pycache，而不是anything rm-pycache。有一个清晰的命名空间，命令才会越用越顺手。

4. 常见问题与排查技巧实录：CLI-Anything 落地避坑指南

框架用起来简单，但真到落地阶段，坑也不少。这块内容是我花了最多时间整理的部分，每条都是实际踩过后的复盘。

4.1 安装后anything命令找不到

解决一个问题：

pip install -e .

前提是你的pyproject.toml里通过[project.scripts]声明了入口：

[project.scripts] anything = "main:main"

这条配置的意思是：安装后，系统会在 PATH 里生成一个anything可执行文件，执行它的时候调用main.py里的main()函数。

问题是，很多人在pip install -e .之后直接敲anything，报command not found。这大概率是安装到了用户的 site-packages，没有暴露到系统 PATH。两个解决办法：

  1. 检查当前 Python 环境是否有完整 PATH：which pip和which python指向同一个环境。
  2. 如果是虚拟环境，先pip install -e .再which anything，看是否在虚拟环境目录的bin下。如果不在，说明pyproject.toml脚本声明写错了，回去核对[project.scripts]节。

4.2 命令自动补全：补全不是“锦上添花”

CLI 命令多了以后，你会发现自己开始用肌肉记忆敲命令，但参数不一定记得准。Typer/Click 都支持生成 shell 自动补全脚本，但很多教程一带而过，我用实际步骤说一下。

假设你的命令入口是main.main，你只需要：

# 针对当前 shell 生效 eval "$(anything --completion-script-bash)" # 永久生效（bash 把下面这行加到 ~/.bashrc） source <(anything --completion-script-bash)

这样你输入anything dev，会自动补全backend、worker、web` 这些参数值。不用记参数列表，Shell 帮你记。

4.3 依赖管理：避免“环境灾难”

CLI-Anything 最怕的是全局环境被各种依赖污染。Python 的包冲突是出了名的闹心，你装了一个新命令，结果它依赖的requests新版本把你的老脚本搞挂了。我的经验是：

所有 CLI-Anything 项目都要有自己的虚拟环境，然后用 Python 支持的管理脚本直接指向虚拟环境的解释器。具体做法：

# 项目目录下创建虚拟环境 python -m venv .venv # 安装依赖（注意用 -e 以便后续命令修改即时生效） .venv/bin/pip install -e . # 用 activate 后执行 anything，而不是直接用系统 python

如果你跟我一样懒，每次不想 activate，可以写一个简单的 runner：

#!/usr/bin/env bash # bin/anything exec "$(pwd)/.venv/bin/anything" "$@"

然后把bin/加入 PATH。从此你不需要关心激活虚拟环境，直接敲anything。这个方式在我们团队里被验证了一年多，再也没人抱怨“我的环境坏了”。

4.4 Windows 兼容：shebang 和路径分隔符

如果你的团队里有 Windows 开发者，别指望.sh脚本能跑。CLI-Anything 用 Python 做底层后，Windows 兼容性主要靠这两点：

  1. 统一用pathlib.Path（而不是os.path.join拼接字符串），路径分隔符问题自动解决。
  2. 所有文件操作都明确指定编码encoding="utf-8"，字符串处理用内容判断而不是==，避免跨平台的行尾差异。

当然，subprocess.Popen里的命令参数（比如pkill）在 Windows 上是不存在的。这种服务管理类命令我给它们加了平台判断，要么直接提示不支持，要么用 Windows 对应的taskkill。真正要让工具集跨平台，最稳妥的方式还是跑在一致的容器/虚拟环境里。

4.5 性能优化：懒加载命令

本来以为“所有命令都在启动时扫描一遍”没问题，但当你命令数量到 50+ 的时候，启动速度会明显变慢。原因是扫描目录会 import 所有命令模块，而每个模块可能加载它的第三方库（httpx、yaml、pandas…），光初始化就得好几百毫秒。

解决思路是懒加载：注册时不 import 函数体，只记录元信息，等真正执行时才 import 对应的模块。Typer 自带这个能力：你可以用@app.command()注册一个延迟函数，但框架本身做这个会稍显复杂。简单粗暴的替代方案是：把重依赖库（比如 pandas、pydantic）的 import 全部放到函数体内部，而不是模块顶层。

# 错误的写法 import pandas as pd # 顶部导入 => 每次启动都会加载 pandas @command("report") def report(path: str): pass # 正确的写法 @command("report") def report(path: str): import pandas as pd # 延迟到真正执行才导入

不要把 import 本身当成代码必需内容，而是把它当成“执行时资源”。这个优化在命令数量增长后效果立竿见影——启动速度从 800ms 降到 150ms 以内。

4.6 日志与输出规范化

命令多了后，输出风格不一致是很容易被忽视的痛点：有的命令打[OK]，有的打Success，有的直接毫不客气地打done。我统一了所有命令的输出规范：

import sys def log_info(msg): print(f"[·] {msg}", file=sys.stderr) def log_ok(msg): print(f"[✓] {msg}", file=sys.stderr) def log_warn(msg): print(f"[!] {msg}", file=sys.stderr) def log_err(msg): print(f"[x] {msg}", file=sys.stderr); sys.exit(1)

约定两条规则：

  • 所有[✓]、[!]这样的状态信息一律输出到stderr，因为stdout是留给真正结果数据的。
  • 如果命令允许和其他工具链一起用（管道、重定向），那stdout只输出机器可解析的数据，比如纯数字、JSON 或纯文件名列表。

这样你的anything命令就能被塞进更复杂的 pipeline 里。比如说anything api orders/12345 | jq .data—— 输出格式规范，让命令变得可组合，价值翻倍。

4.7 测试与回归：别让老命令被默默改坏

CLI-Anything 没有特别的测试框架，就靠标准的unittest写命令级测试。测试点很简单：给定参数，验证执行结果（文件是否创建、接口是否被调用、stdout/文件内容是否符合预期）。

# tests/test_rename.py import unittest import tempfile from pathlib import Path from commands.rename import rename_files class TestRename(unittest.TestCase): def test_rename_with_prefix(self): with tempfile.TemporaryDirectory() as tmp: Path(tmp, "old_name.txt").touch() rename_files(tmp, prefix="new_") self.assertTrue(Path(tmp, "new_old_name.txt").exists())

这种测试的价值在于：你以为是在“重构旧命令”，结果把一个调用参数改错了，或者把输出格式破坏了，测试会第一时间报警。没有回归保护的 CLI 工具集，最终一定会退化成“谁都不敢改”的僵尸代码。

5. 更进一步：把命令做成团队共享

5.1 团队共享的三种模式

自己用爽了，一定会想让团队一起用。共享时根据团队规模是不同的三种模式：

  • 人肉共享（1-5 人）：把项目git clone到本地，自己pip install -e .安装。适合小团队快速试水。
  • 统一构建分发（5-20 人）：用 GitHub Actions / GitLab CI 自动构建 wheel 包，团队内用一个私有包索引统一安装升级。优点是版本可控，缺点是搭建和维护成本高。
  • 内网二进制定制（20 人以上）：提前用 PyInstaller 打包好目标平台的二进制，放在内部服务器上直接下载。此时 Go 编译成二进制的优势就体现出来了，但 Python 不是不能做。

说实话，我大部分个人项目的分享就是“人肉共享”。它听起来没那么酷，但它简单到让你不会因为“分发太麻烦”而放弃共享。快速让命令在队友电脑上跑起来、产生价值，远比纠结用 wheel 还是二进制更重要。

5.2 命名与文档：命令也要“接口文档”

命令是给机器看的接口，也是给人看的功能。每个命令我都要求写 help 文本，而且规定至少两个示例行：

@command("img-check") def check_image( path: str, timeout: int = 10, ): """ 检查图片文件是否为有效图片（非空、非损坏）。 例：anything img-check ./cover.png 例：anything img-check ./cover.png --timeout 30 """

你会发现这个习惯特别重要，因为三个月后的你，就是那个最需要帮助文档的“陌生人”。有了示例，所有使用过的痕迹都变成了可搜索的线索，团队交流成本明显下降。

5.3 扩展生态：让“anything”成为你的工具箱入口

CLI-Anything 最大的价值在于，它重新定义了你电脑上“脚本”的组织方式。比如：

  • 把定时清理日志的 cron job 封装成anything clean logs
  • 把 Git 分支清理封装成anything git tidy
  • 把资料归档封装成anything archive move ~/Downloads --category pics

如果我们把日常所有频繁但不成体系的重复动作都收编进这个统一入口，状态是完全可追踪、可补全、可组合的。这比“到处找脚本、临时敲命令”的价值要高得多。

6. 经验沉淀：这套框架对我日常工作方式的重塑

做 CLI-Anything 这一年多，最大的感受不是“写了多少条命令”，而是工具思维变了。

以前碰到一个需要反复做的操作，我的第一反应是“打开一个 REPL、跑一段 Python、然后关掉”；现在我的第一反应是“给 anything 加一个功能代码”。这个转变看着不大，但它带来几件实实在在的好处：

  • 操作可复现：不会出现“昨天会跑今天忘了参数”的情况，--help一键兜底。
  • 操作可传递：同事只需要安装、看提示信息，不需要读源码就能使用。
  • 操作可审计：命令调用方式、输出格式都是规范的，复盘排查问题的路径干净很多。

如果你也攒了一堆脚本，我建议一个最简单、立刻能做的小动作：选一个你每周至少用三次的脚本，按“函数即命令”的方式封进 CLI-Anything，然后观察自己使用它的体验差异。一个两个可能感觉不明显，等封装到十几个命令的时候，你会立刻发现回不去了——再也无法容忍打开一个目录去右键改名、在浏览器里一次次复制 URL 去调接口。

最后再分享一个小技巧：封装anything时，最值得优先封装的不是“复杂逻辑的项目代码”，反而是那些“你每天都在做的琐碎动作”。比如打开某个固定文档、生成一个时间戳文件名、把剪贴板内容存成文件。因为这些琐碎假设频率决定了你每天高频体验到统一命令的爽感，也最能让你走上“一切皆可命令”的路。