企业官网建设流程全解析

1. 为什么AI时代反而成了CLI的黄金时代

观察一个很有意思的现象：2025年最火的开发者工具，不是那些界面精美的GUI应用，而是一大堆黑底白字的命令行程序。OpenAI的Codex CLI、Anthropic的Claude CLI，这些头部AI实验室推出的官方编程代理工具，统统选择了最朴素的命令行形态。

CLI-Anything这个项目从这个现象切入——把一切能数字化的东西都做成CLI工具。我当初做这个项目，起因其实特别实际：日常工作里要反复执行一类操作——创建项目脚手架、批量处理文件、调AI接口、跑数据管道。每次打开浏览器点来点去，或者在不同工具之间来回切换，效率低得让人抓狂。后来我强迫自己养成了一个习惯：凡是重复三次以上的操作，就花半小时把它封装成一条命令行。

这个思路后来演变成了CLI-Anything：一套通用CLI工具框架，配上大量可以直接抄作业的命令实现。

CLI工具在AI时代反而更重要的原因，我总结有三点：

• 可脚本化：GUI操作没法写进自动化流程，命令行可以。AI编程代理要真正落地干活，操作的对象只能是一系列命令。
• 可组合性：单一命令能力有限，但通过管道、参数传递和子命令嵌套，可以组装出非常复杂的工作流，这种灵活性是GUI做不到的。
• 可审计和可复现：命令行天然自带日志和参数记录，跑过什么一清二楚。对程序员的项目总结、对团队的协作交接，这条价值远超表面。

所以CLI-Anything表面是在做工具，本质上是在建立一套"万物皆可命令行"的思维模式。这篇文章我会把从零搭建CLI工具的完整路径捋一遍：框架选型、骨架搭建、参数设计、AI工具集成、发布维护，每个环节都说透。

2. 框架选型：主流CLI框架横向对比与我的选择逻辑

做CLI第一步不是写代码，而是选框架。市面上各语言都有成熟的CLI脚手架方案，我实际对比过几套主流方案，先说结论：日常通用型项目，我用的是TypeScript + Commander.js；涉及复杂数据处理和AI接口调用，我用Python + Typer。后面我会解释为什么这样选。

2.1 主流CLI框架的实际表现

以下是几套主流方案的真实使用感受，参数基于我踩坑后的归纳：

直接说我的使用倾向：如果你是一个前端或者全栈开发者，日常跟Node生态打交道比较多，那Commander.js是最省心的选择，API设计自然，写起来几乎零心智负担。如果你平时做数据处理、算法、AIGC相关的工作，Python天然更适合，Typer用起来简直像在写普通函数一样舒服。

Cobra我也试过，性能确实好，编译出来一个二进制文件扔哪都能跑，不用考虑用户的Node或Python环境。但Go的泛型和类型系统对CLI这种偏胶水性质的开发来说，开发速度会拖慢，如果不是做那种需要极致性能和分发体验的工具，不推荐杀鸡用牛刀。

2.2 我为什么主推TypeScript + Commander.js

CLI-Anything里大部分子命令我选的是TypeScript写，原因有两个。

一是类型安全。CLI工具最头疼的就是参数解析，拿到一个参数你不知道它是字符串还是数字，要不要转布尔值，有没有默认值。TypeScript可以让你在编译期就把这些约束卡死，配合zod做运行时校验，基本杜绝了"参数传错类型"这种低级bug。

二是跟AI生态无缝衔接。现在最火的Codex CLI、Claude Agent都是Node/TypeScript生态的产物，你要在自己的CLI里调用它们的能力，JSON格式的配置文件、Node API，都是同构的，集成时零摩擦。

举个例子，CLI-Anything里我封装了一条自动生成项目脚手架的指令，核心参数校验逻辑大概是这样的：

import { Command } from 'commander'; import { z } from 'zod'; const ProjectOptions = z.object({ name: z.string().min(1, '项目名不能为空'), template: z.enum(['react', 'node', 'cli', 'python']), packageManager: z.enum(['npm', 'pnpm', 'yarn']).default('pnpm'), typescript: z.boolean().default(true), }); const program = new Command(); program .name('cli-anything') .description('万物皆可命令行 - 通用脚手架生成器') .version('1.0.0'); program .command('scaffold') .description('生成新项目脚手架') .argument('<name>', '项目名称') .option('-t, --template <template>', '模板类型', 'react') .option('-p, --package-manager <pm>', '包管理器', 'pnpm') .option('--no-typescript', '不使用TypeScript') .action((name, options) => { const result = ProjectOptions.safeParse({ name, ...options }); if (!result.success) { console.error('❌ 参数校验失败:', result.error.issues); process.exit(1); } runScaffold(result.data); }); program.parse();

这段代码里值得注意的细节是zod的safeParse模式，它不在parse失败时抛异常中断程序，而是返回一个包含错误信息的结果对象，让我能控制错误输出的格式。CLI工具对用户来说是"黑盒"，错误提示写得好不好直接决定这个工具好不好用。

2.3 数据密集型场景切换到Typer的理由

CLI-Anything里跟数据打交道的子命令（比如批量处理CSV、调用大模型API、文本分析这类），我全部用Python写。原因也很直接：Python在数据处理上的库支持比TypeScript强太多，pandas、numpy这些就不用说了，关键是AI相关的SDK，OpenAI、Anthropic官方Python SDK的完整度和更新速度永远是第一梯队的。

Typer写CLI体验可以用"离谱"来形容，它的核心承诺是"你不用单独学CLI参数解析，类型标注写对了，一切就都对了"。看个实际例子——调用AI模型批量给文本打标签的命令：

import typer from enum import Enum from openai import OpenAI app = typer.Typer() class ModelName(str, Enum): gpt4o = "gpt-4o" claude = "claude-sonnet-4-20250514" qwen = "qwen-plus" @app.command() def tag( input_file: str = typer.Argument(..., help="输入文本文件路径"), output_file: str = typer.Option("output.json", "--output", "-o", help="输出结果文件"), model: ModelName = typer.Option(ModelName.qwen, help="选择模型"), max_tags: int = typer.Option(3, min=1, max=10, help="最大标签数量"), ): """批量给文本生成标签""" texts = open(input_file, encoding="utf-8").read().strip().split("\n") client = OpenAI( api_key=load_api_key(model), # 从环境变量或配置读取 ) results = [] for text in texts: resp = client.chat.completions.create( model=model.value, messages=[ {"role": "system", "content": f"请给下面文本生成{max_tags}个中文标签，输出JSON数组"}, {"role": "user", "content": text} ], temperature=0.3, ) results.append({"text": text, "tags": json.loads(resp.choices[0].message.content)}) with open(output_file, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) typer.echo(f"✅ 已完成 {len(results)} 条文本的标签生成，结果写入: {output_file}") if __name__ == "__main__": app()

注意这段代码里模型的枚举定义，这个是我强烈推荐的模式。把可选的模型名定义为枚举类型，Typer会自动生成下拉选项一样的参数补全提示，用户根本不可能传错值。这就是类型标注驱动CLI设计的精髓。

3. 骨架搭建：一个能跑的最小CLI是怎么长出来的

选好框架，接下来要解决的是一套通用的骨架设计问题。CLI工具最怕写成一坨"面条代码"——所有的逻辑全堆在一个文件里，参数解析、业务逻辑、错误处理、输出格式化搅在一起。我建议从第一天就把骨架拆好。

3.1 推荐的目录结构

CLI-Anything遵循的是一个非常经典的分层结构：

cli-anything/ ├── package.json ├── tsconfig.json ├── src/ │ ├── index.ts # 入口，注册所有命令 │ ├── commands/ # 每条命令一个文件，参数定义写在文件顶部 │ │ ├── scaffold.ts │ │ ├── tag.ts │ │ └── ai-query.ts │ ├── core/ # 核心基础设施 │ │ ├── logger.ts # 日志模块，统一输出风格 │ │ ├── config.ts # 配置加载/保存 │ │ └── errors.ts # 自定义错误类型 │ ├── services/ # 业务逻辑层，跟具体命令解耦 │ │ ├── scaffold-generator.ts │ │ └── ai-service.ts │ └── types/ # 类型定义 ├── templates/ # 脚手架模板文件 │ ├── react/ │ └── node-cli/ └── bin/ └── cli-anything.js # 可执行入口

这个结构的好处是职责边界清晰：commands层只负责"读懂用户想干什么"，services层负责"把事干完"，core层负责"怎么干得舒服"。改业务逻辑不影响参数接口，加新命令不需要碰旧代码。

3.2 可执行入口的注意事项

这里有个Node生态的经典坑：当你用TypeScript写CLI时，最终发布时编译成JavaScript，bin字段指向的应该是编译产物。但开发过程中你又想直接跑TS源码，方便热更新。

我的做法是用tsx这个运行时来跑TS文件，在package.json里这样配置：

{ "name": "cli-anything", "version": "1.0.0", "bin": { "cli-anything": "./bin/cli-anything.js" }, "scripts": { "dev": "tsx src/index.ts", "build": "tsc -p tsconfig.json", "watch": "tsc -w -p tsconfig.json" }, "devDependencies": { "tsx": "^4.7.0", "typescript": "^5.4.0" } }

然后在bin目录放一个极简的启动脚本：

#!/usr/bin/env node require('../dist/index.js');

开发时用npm run dev直接跑tsx，体验跟脚本语言一样顺滑；发布前npm run build编译到dist目录，bin脚本指向编译产物。实测这个开发流程很稳，不会有"改了代码忘了编译"这种尴尬。

3.3 配置和日志：CLI的"基本盘"

CLI工具的用户体验差距，一半在配置管理，一半在日志输出。

配置管理我建议统一走"三段式"：默认配置 -> 用户配置文件覆盖 -> 环境变量覆盖。优先级是环境变量最高，其次用户配置文件，最后默认值。实现上不需要引入复杂的配置库，一条命令就够：

import fs from 'node:fs'; import path from 'node:path'; import os from 'node:os'; const configDir = path.join(os.homedir(), '.config', 'cli-anything'); export function loadConfig() { const defaults = { model: 'gpt-4o', maxTokens: 2048, concurrency: 3 }; const configPath = path.join(configDir, 'config.json'); if (fs.existsSync(configPath)) { const userConfig = JSON.parse(fs.readFileSync(configPath, 'utf-8')); return { ...defaults, ...userConfig }; } return defaults; } export function getEnvOverrides() { return { model: process.env.CLI_ANYTHING_MODEL, maxTokens: process.env.CLI_ANYTHING_MAX_TOKENS, concurrency: process.env.CLI_ANYTHING_CONCURRENCY, }; }

日志模块我选择的是结构化的JSON输出模式。可能有人觉得CLI日志应该是简洁的文本，但我发现当输出要喂给其他程序或者写进CI日志时，结构化的JSON才是真正好用的。一行日志里包含level、时间戳、message、metadata，既方便人看（我封装一层美化打印），也方便机器处理。

4. 子命令设计：怎么让一个CLI自己会"长命令"

CLI-Anything我的目标不是一个单一功能的小工具，而是一棵能不断生长的命令树。这就涉及子命令设计这个关键问题。很多人的CLI命令用着别扭，根因是父命令和子命令的职责边界没切清楚。

4.1 命令树的切分原则

我的切分原则是三个"一"：

• 一个动词一条命令：每条命令只做一件动词，比如scaffold就是生成项目，tag就是打标签，query就是问AI。
• 一层参数一层职责：全局参数负责"横切关注点"（比如debug开关、输出格式、并发数），子命令参数负责"这个命令特有的业务参数"。不要把业务参数放到全局里。
• 一个子命令一个配置文件位置：如果子命令需要单独的配置，配置项就放在配置文件里跟子命令对应的key下，这样用户能按图索骥。

举个例子，CLI-Anything的命令树设计：

cli-anything ├── scaffold <name> 生成项目脚手架 │ ├── --template 模板类型 │ └── --package-manager 包管理器 ├── tag <file> 批量文本打标 │ ├── --output 输出路径 │ ├── --model 模型选择 │ └── --max-tags 标签数量 ├── ai-query <prompt> 直接跟AI对话 │ ├── --model 指定模型 │ ├── --system 系统提示词 │ └── --json 输出JSON结构化结果 └── doctor 环境诊断（检查依赖是否齐全）

这里doctor这个子命令我觉得每个CLI都要有。它是一个"自查"命令，检查当前环境是否满足所有依赖（Node版本、Python版本、API Key是否配置、模板目录是否存在），把不满足的项目用醒目的错误信息列出来。这条命令在用户遇到问题时，能帮你省掉80%的答疑时间。

4.2 参数解析的三个大坑

子命令设计完成后，接下来就是参数解析。作为资深用户，我总结出三个常见问题，每个都踩过坑。

第一个坑：布尔参数和可选值混在一起。比如--no-typescript这种取反参数，如果用字符串去解析就非常痛苦。Commander.js和Typer对布尔开关的支持都很完善，但要注意传参时Boolean类型必须显示标注，否则库会把"false"当成true传给业务逻辑。

第二个坑：全局参数位置的灵活性。用户可能习惯把参数放在命令的任何位置，你的参数解析器要支持参数和选项的任意顺序。如果真的用了不支持任意顺序的框架，建议统一调到命令后、子命令前传全局参数。

第三个坑：帮助信息的友好度。一个CLI的工具，帮助信息就是它的说明书。我要求每条命令的help里必须写清楚：参数说明、默认值、示例。用Commander.js的.addHelpText()和Typer的docstring都能做到。帮助信息写详细，用户可以减少一半的试错时间。

4.3 可组合性：让你的CLI能当"积木"用

真正让我对CLI-Anything产生质变感觉的，是给命令加上了可组合性设计。具体来说就是：所有命令默认从stdin读取输入，默认输出到stdout，这样就能用Unix管道把命令串联起来。

比如我想做"批量把markdown文件转成带AI摘要的JSON报告"，原本需要写一个新的子命令。但现在我可以直接用管道：

cat *.md | cli-anything summarize --format json | cli-anything tag --model qwen > report.json

第一段cat负责收集文件，第二段调用CLI-Anything的summarize子命令生成摘要，第三段再调用tag子命令给每篇打标签，最终结果统一入库。这就是组合的威力——不需要写新代码，两个已有命令就能配对实现新功能。

实现stdin支持的代码很简短：

import readline from 'node:readline'; async function readStdin() { const rl = readline.createInterface({ input: process.stdin }); const lines: string[] = []; for await (const line of rl) lines.push(line); return lines.join('\n'); } program .command('summarize') .option('-f, --format <format>', '输出格式', 'text') .action(async (options) => { const input = process.stdin.isTTY ? await promptInput() : await readStdin(); // 处理逻辑... });

这里的process.stdin.isTTY判断很关键：如果用户没管道输入（终端直接跑），就交互式获取内容；如果管道来了数据，就直接读stdin。两条路径都照顾到，用户体验才完整。

5. 把AI装进CLI：接入Codex CLI和Claude CLI的实战玩法

聊完了CLI本身的骨架和设计，接下来是重头戏——怎么把AI能力真正整合进CLI工作流。这一块我只分享实际跑通的方案和踩过的坑。

5.1 先搞清楚AI CLI生态的现状

目前主流的AI CLI分成两条路：一条是官方出品的编程代理类工具，Codex CLI和Claude Agent为代表，它们是完整的会话式助手，能读写代码、执行命令；另一条是DIY路线，自己写脚本调大模型API，把AI能力封装成自己的CLI子命令。

我的思路是两条都用：官方工具处理"需要理解上下文"的复杂任务，我自己的CLI处理"固定模式的批量任务"。前者是智力劳动者，后者是流水线工人，各司其职。

5.2 Codex CLI的安装与基础使用

Codex CLI是OpenAI出的开源编程代理，安装非常简单，一条命令：

npm install -g @openai/codex

安装后第一次运行需要配置API Key，支持OpenAI官方Key和兼容的第三方Key（实测用中转商的Key也可以，只要接口兼容HTTPS协议就行）。不过这里要提醒一句：环境变量配置Key比交互式输入更可靠，因为交互式配置会把Key明文写进配置文件，有泄漏风险。

export OPENAI_API_KEY=sk-xxxx codex

跑起来之后，你会在终端里看到一个交互式会话界面，可以自然语言描述需求，比如"给这个项目加一个readme生成脚本"，Codex会分析代码库、给出修改建议、执行命令。它最核心的价值是能自己读写文件、跑命令、根据错误输出自我修正，是真正的"代理"而不是"聊天机器人"。

但我也踩过Codex CLI的坑：它默认依赖Node环境和一些原生模块，如果在受限环境里部署，可能报"unable to locate the codex cli binary or required runtime components"这类错误。遇到这种情况，优先检查Node版本（要求>=18），其次检查npm全局路径有没有加到PATH里面：

echo $PATH | grep -oE 'npm[^:]*' # 检查npm全局bin目录是否存在

5.3 Claude CLI和第三方模型Key的混用方案

Claude CLI的官方安装方式跟Codex类似：

npm install -g @anthropic-ai/claude-code

这里有个现实的问题：不是每个人都能直接拿到Claude官方Key，很多人用的是其他厂商的模型。好消息是Claude Code支持通过环境变量指定兼容的API地址和Key，网上流传很广的玩法是配置成通义千问（Qwen）等国内模型的OpenAI兼容接口。基本配置思路：

export ANTHROPIC_API_KEY=sk-你的key export ANTHROPIC_BASE_URL=https://你的兼容网关地址 claude

不过我要提醒一句：别太指望非官方模型能完全复刻官方Claude Code的效果。Claude Code对工具调用、上下文缓存等能力有深度依赖，切换成第三方模型后，代码修改能力、长上下文记忆会大打折扣。实测下来，日常聊天、文案生成这些场景用第三方模型完全够用，但严肃的代码库重构还是建议回到官方模型。

5.4 在自有CLI里集成AI能力的三种姿势

如果不想依赖外部CLI，想在自己的CLI-Anything里直接集成AI能力，有三种方案。

第一种：直接调模型API。这种最灵活，代码已经在前面Typer的例子见过。适合固定逻辑的批量任务，比如批量打标签、文本分类、信息抽取。

第二种：包装外部CLI。用child_process调用Codex CLI或Claude CLI，适合需要"让AI完整操作一个项目"的场景。比如我的CLI里有个子命令叫ai-fix，就是调用Codex CLI自动修复代码风格问题：

import { exec } from 'node:child_process'; export function runCodexFix(projectDir: string, prompt: string) { const cmd = `cd ${projectDir} && codex exec "修复当前项目的代码风格问题，${prompt}"`; exec(cmd, (error, stdout, stderr) => { if (error) { console.error(`❌ Codex 执行失败: ${error.message}`); return; } console.log(stdout); }); }

第三种：混合模式。先用API做预处理（比如把代码库生成一份摘要JSON），再把摘要传给外部CLI作为上下文。这样既能享受外部CLI的完整能力，又能塞入自有CLI特有的业务信息。

我在CLI-Anything里实测过，第三种模式在"给一个大型代码库生成架构说明文档"的场景效果非常惊艳。先用自己的脚本做代码扫描和调用大模型API生成模块清单，再把清单文件路径作为上下文参数传给Claude CLI，让它在完整理解代码结构的基础上写文档。整个过程跑下来，比纯靠人去读代码快一个量级。

5.5 AI CLI的高频痛点与解法

跟AI CLI打交道多了，有几个高频痛点必须说透。

Token消耗不可控。AI CLI的每次会话都会消耗Token，特别是Codex这样的代理，一轮对话可能包含多次工具调用和大量文件读取。解法是给CLI加上"预算控制"：环境变量里设定单次会话最大Token数，超限自动终止；或者用--max-iterations参数限制代理的思考循环次数，防止它死循环烧钱。

结果不稳定。同一任务两次运行，代码可能不一样。解法是把AI输出纳入CI流程做自动化回归测试，每次生成内容跑一遍测试，通不过就重试或回滚。这是把AI当作"团队成员"而不是"魔法按钮"来看待的正确心态。

安全性。让AI代理自动执行命令，风险很高。我强烈建议在沙箱环境先试跑一遍，或者给AI代理指定白名单目录。至少在CLI层面要加一条强制确认机制：所有会修改文件系统的命令，执行前必须按一次y确认。

6. 发布、分发和长期维护：CLI工具从"自己用"到"别人用"

做到这一步，CLI-Anything已经能高效服务我的日常开发了。但是一个CLI工具的真正价值，在于能不能分享给别人用，或者自己在不同机器上无缝部署。这一章聊聊发布和长期维护。

6.1 让CLI工具能"装"进任何机器

对于TypeScript写的CLI，发布到npm是最顺的路。核心步骤就三步：

# 1. 编译 npm run build # 2. 本地测试发布后的包 npm link # 在全局做一个符号链接，直接能用 cli-anything 命令 # 3. 发布 npm publish

发布之前有几个关键配置要检查：

{ "files": ["dist", "bin", "templates"], "engines": { "node": ">=18.0.0" }, "preferGlobal": true, "keywords": ["cli", "scaffold", "ai", "command-line"] }

files字段只打包必要目录，避免把源码、测试文件一起发上去，包体小安装快。engines声明Node版本要求，让用户在错误环境里安装时能提前看到警告。

对于Python写的CLI子命令，用pip发布到PyPI同理。但我现在的策略是混合仓库：TypeScript是主仓库，Python子命令放在py-cli/子目录独立发布。npm包在安装时通过postinstall脚本自动检查Python依赖，缺什么自动装。这样用户只装一次，两个生态的命令都能用。

6.2 跨机器部署时的真实踩坑记录

跨机器部署这件事，我踩过的坑比写代码时多得多。挑三个最有代表性的说：

坑一：全局路径污染。之前我把CLI-Anything装在一台服务器上，另一个项目里有个依赖的Python版本不同，导致CLI-Anything的Python子命令直接ImportError。解决方案是给Python子命令加一层独立的虚拟环境：npm的postinstall脚本里自动创建.venv并安装依赖，命令运行时用.venv/bin/python执行，跟系统Python彻底隔离。

坑二：模板文件丢失。CLI的scaffold子命令依赖templates目录里的模板文件。npm默认会打包含在files字段里的文件，但如果你忘了加上，用户装完跑scaffold就会报"找不到模板文件"。解决方法是把模板文件打包成JSON或字符串常量嵌进dist，或者至少加一条启动自检，文件不全就明确报错。

坑三：API Key管理。直接让用户手工配置环境变量，操作门槛太高。后来我改成了cli-anything config子命令，交互式引导用户输入Key并写入配置文件，同时文件权限设为0600（仅当前用户可读写）。既好用又安全。

6.3 长期维护的核心策略：让CLI自己"报修"

CLI工具发布出去最怕的不是功能不完善，而是用户遇到问题不知道怎么反馈。我给CLI-Anything设计了一个"自动上报"机制：

• 当命令运行失败并输出错误时，自动生成一份调试日志（包含版本号、Node版本、操作系统、错误堆栈、输入参数脱敏后的副本），存入~/.local/state/cli-anything/logs/。
• 同时提示用户：可执行cli-anything doctor自查，或将日志文件提交到GitHub Issue。

有了这个机制，你在维护阶段会轻松很多。用户提问时你可以直接让他贴日志文件路径，不再需要反复猜他机器上发生了什么。

6.4 性能优化：让CLI跑得更快

CLI工具给人的第一印象往往是"响不响应"。慢吞吞的命令会被所有人嫌弃。我在CLI-Anything里做了几个针对性的优化：

• 惰性加载子命令。Commander.js默认会注册所有子命令，但实际执行时只用到一条。我给每条子命令的action都用动态import()，只有执行到才加载对应模块。实测启动时间从800ms降到了200ms以下。
• 并行执行。tag子命令批量处理文本时，默认并发数为3。增加--concurrency参数让用户按需调整。但并发太高会触发AI API的限流，所以代码里用p-limit这类库严格控制数量。
• 缓存响应。对于重复性高的操作（比如查帮助、查看版本、检查模板列表），结果缓存到临时目录，二次执行直接读缓存，秒回。

这里有一个经验：CLI工具的性能瓶颈90%在外部IO（磁盘读取、网络请求、进程启动），你的代码本身很少是瓶颈。所以优化的重点放在"减少外部IO次数"上，而不是抠自己的代码效率。

7. 从我踩过的坑里，总结几条CLI开发的"保命"心得

CLI开发做到这个份上，回头看看那些折腾过的问题，有三条心得我觉得值得任何一个CLI开发者刻在脑子里。

第一条：永远不要相信用户会按你的预期输入。参数校验、错误处理、帮助信息，这几件事做的完善程度，直接决定了工具从"能用"到"好用"的差距。我见过很多CLI工具逻辑写得很好，但用户一传错参数就退出一串看不懂的堆栈，这种体验很劝退。

第二条：CLI也是软件工程，不是脚本。很多人写CLI工具时觉得"就几个命令而已"，于是不设计目录结构、不写测试、不搞类型定义，结果工具一复杂就变成一团乱麻。我后来把CLI的代码当成正式的后端服务来对待，写单元测试、做CI、加日志追踪，开发效率反而提高了——因为重构的时候不怕改坏东西。

第三条：AI能大幅提升CLI开发效率，但你要给AI"带路"。我用Codex CLI写过CLI-Anything的几个子命令，效果很好，但前提是我先给AI讲清楚项目结构、设计思路和约束条件。你让AI盲目生成，它会给出一堆很漂亮但跟现有代码风格不一致的东西。这跟带一个新同事干活是一样的道理，训好"提示词上下文"就有好结果。

最后还有一条很玄学的经验：CLI工具的"手感"很重要。加载动画是不是流畅、错误信息是不是有颜色、进度条是不是精确，这些细节用户未必会说出来，但他们会直接告诉你"感觉好用"还是"感觉别扭"。我在CLI-Anything里花了大量时间打磨这些非核心功能，收获的好评远超预期。

CLI开发这件事，看起来简单，做起来全是细节。从CLI-Anything这个项目里学到的，不只是"如何写一个命令行工具"，更是一整套"如何设计一个能长期用、能分享、能生长的工具"的方法。希望这篇经验能让你少走点我走过的弯路。