OpenShell：用自然语言驱动终端的AI助手

写这个项目的时候，我其实已经忍了命令行很久了。每天在终端里敲那些又长又容易忘的参数组合，awk、sed、grep连招每次都要现场查手册，Git命令除了add和commit之外全靠肌肉记忆，碰到要查端口、看日志、批量改文件这种稍微绕一点的活儿，整个人就开始烦躁。

后来GPT这类大模型出来之后，我一度觉得救命稻草来了，但实际用下来发现还是不够顺手——你切到浏览器打开对话框，把问题描述清楚，复制结果回终端再粘贴执行，来回折腾几趟下来，时间根本没省多少。我当时就在想：能不能直接在终端里，把自然语言变成可执行命令？OpenShell就是在这个想法上长出来的东西。

1. 项目定位：不是重写Shell，而是给Shell装一颗AI大脑

我这个项目不打算做一个新的Shell解释器。市面上的Shell已经够成熟了，bash、zsh、fish各有各的生态和用户群，想替换掉它们基本是异想天开。OpenShell的定位是：一个运行在终端里的AI助手，它读你输入的自然语言，理解之后生成对应的命令行指令，经过你确认后再执行。

从这个定位出发，整个项目就围绕三条核心原则展开。

第一，不做“黑盒代理”。用户输入“帮我杀掉占用8080端口的进程”，OpenShell不能直接把它翻译成fuser -k 8080/tcp然后偷偷执行掉。Shell命令有权限，有破坏性，一个误操作可能把整个环境搞乱。所以所有的命令执行前必须经过用户确认，OpenShell只负责给出建议和解释，决策权永远在用户手里。

第二，要原生支持管道和组合命令。自然语言描述一个复杂操作的时候，往往会牵扯到多条命令的组合，比如“把所有大于100M的日志文件移动到/tmp/old_logs”。这需要AI不仅能生成单条命令，还要能组合出find ./logs -type f -size +100M -exec mv {} /tmp/old_logs/ \;这样带exec的复杂结构。如果模型能力不够，这个项目就会显得特别笨。

第三，要适配真实的工作场景。真实终端场景不只是“问一句答一句”，还要能结合当前目录、环境变量、操作系统类型来给出更准确的命令。比如在Windows的PowerShell下和Linux的bash下，清理DNS缓存的命令完全不同，OpenShell需要感知运行环境，才能给出可用的结果。

基于这三点，OpenShell最终采用的架构是“大模型解析 + 本地执行器”。大模型负责理解自然语言并输出结构化命令结果，本地脚本负责解析结果、展示给用户、等待确认、执行并捕获输出。

这个架构的最大好处是扩展性够强——大模型部分可以随时切换供应商或者替换成本地部署的开源模型，而本地执行器完全独立，不依赖特定模型API，将来想支持新的终端环境也只需要改动执行器部分，不用动大模型逻辑。

2. 核心设计拆解：从自然语言到可执行命令的完整链路

OpenShell的完整工作链路可以拆成五个环节：输入捕获、环境感知、模型推理、交互确认、执行回传。每一个环节都有各自的坑和设计取舍。

2.1 输入捕获：支持自然语言和快捷指令的双通道

输入捕获这件事，听起来简单，做起来最容易翻车。终端程序的输入处理和普通Web应用完全不一样，涉及标准输入、终端原始模式、快捷键捕获等一系列问题。

我最开始用Python的input()函数来做，结果发现用户体验很糟糕：不能用方向键翻历史、不能用Tab补全、粘贴多行文本时直接乱掉。后来换成了prompt_toolkit库，这个问题才算是彻底解决。这个库提供了类似IPython的交互体验，支持历史记录、自动补全、多行输入，而且跨平台表现一致，非常适合做命令行交互工具的底座。

除了自然语言输入，OpenShell还做了一条快捷指令通道。我用/作为指令前缀，比如/status查看当前环境信息、/clear清空对话上下文、/mode safe切换执行模式、/model gpt-4o切换模型。这个设计让工具更像是“原生长在终端里的助手”，而不只是一个会翻译命令的Web页面壳子。

2.2 环境感知：上下文是准确率的第一保障

大模型生成的命令如果不结合运行环境，那它就是在“闭眼开车”。同样一句“查看本机IP地址”，在Linux上可能是ip addr，在macOS上可能是ifconfig，在Windows上则是ipconfig，甚至Linux还得分新旧版本系统。

我的做法是在每次发起模型请求前，自动采集一组环境上下文数据：

• 操作系统类型和版本
• 当前Shell类型（bash/zsh/fish/powershell）
• 当前工作目录和目录内容摘要
• 常见工具链版本信息（git、python、node、docker等，存在才采集）
• 当前登录用户和权限级别

这些信息全部拼进系统提示词里。实测下来，加入环境感知之后命令生成的准确率提升非常明显，尤其在涉及文件操作、进程管理这些跟系统强相关的场景下，模型不再是“凭空翻译”，而是真的在“看着你的电脑操作”。

2.3 模型推理：Prompt工程才是这个项目的灵魂

模型推理是整个项目最核心也是最需要打磨的部分。大模型本身的能力决定了上限，但Prompt设计决定了下限。我试过好几版Prompt，光是系统提示词就迭代了十多次，这里分享一下最终版的几个关键设计。

第一版Prompt写得很简单：“你是一个Shell命令助手，请将用户的自然语言翻译成Shell命令。”结果就是灾难——模型经常生成一些“看起来对但实际跑不了”的命令，漏掉转义字符、用错引号、该加sudo的地方没加。

第二版加入了格式约束，要求输出JSON格式的命令和解释，准确率有提升，但依然不够稳定。

最终版的Prompt设计，我总结了几个关键点：

• 明确角色和环境。告诉模型它现在运行在什么操作系统、什么Shell环境下，要求输出适配当前环境的命令。
• 严格输出格式。要求输出JSON对象，包含command字段和description字段，其他任何内容都不返回，方便程序解析。
• 给出安全规则。要求模型对危险操作（删除、覆盖、权限变更、批量修改）在描述里给出明确的警告提示。
• 提供Few-shot示例。在Prompt里放几个典型的输入输出对，让模型模仿示例的语感和格式。

这里附加一个基于常见实践补充的经验：Few-shot示例不要选太简单的例子。比如只给“列出当前目录文件 -> ls -la”这种示例，模型就会倾向于生成简单命令；如果给一个“找出所有超过100M的日志文件并移动到指定目录”的复杂示例，模型的输出水平会整体上一个台阶。这种“用复杂示例拉高模型输出上限”的思路，在Prompt工程里非常实用。

2.4 交互确认：把危险命令的决策权交还给用户

交互确认机制是这个项目安全性的核心。我设计了三档执行模式：

• 安全模式：所有命令执行前都要经过用户确认，输入y才执行，这是默认模式。
• 自动模式：高风险命令需要确认，低风险命令直接执行。风险判断靠大模型返回的risk字段，分为low、medium、high三档。
• 手动模式：只生成命令，不执行。用户自己复制到Shell里跑。

判断一个命令是否“高风险”，我总结了几个硬指标：命令包含rm、dd、mkfs、> /dev/sda这类关键词；命令涉及递归删除或批量覆盖；带sudo提升权限；删除数据库表或生产环境文件。出现任何一项都直接归为高风险。

确认提示的交互设计也有讲究，不能只是一个干巴巴的y/n问句。OpenShell执行前的提示会展示三块内容：完整的命令文本、通俗易懂的功能解释、风险警告。用户在敲下回车之前能完整理解“这条命令到底会干什么”，这也是避免误操作最好的方式。

2.5 执行回传：把报错上下文喂回给模型

命令执行完之后，OpenShell会把标准输出和标准错误都捕获下来，存到上下文里，供后续对话引用。这个设计的实际价值极大——用户让OpenShell跑一条命令，命令报错了，接下来自然的一句话往往是“怎么回事”，如果OpenShell还记得刚才命令的完整报错信息，就能直接分析问题原因，并给出修复命令，形成“生成—执行—反馈—修正”的闭环。

我甚至专门为这个功能加了一个上下文压缩策略：当对话轮次超过一定数量或者上下文Token接近上限时，自动把历史命令、输出和模型回复做摘要，只保留摘要作为后续对话的上下文背景。这样长会话下记忆不会丢，Token成本也可控。

3. 实操过程全记录：从零到一跑通OpenShell

下面记录一个完整的搭建和运行过程，你可以照着实操。我在一台纯净的Ubuntu 22.04服务器上做过一遍完整测试，Windows和macOS环境大致相同，只有小区别会在文末提醒你。

3.1 环境准备与依赖安装

OpenShell的运行环境要求是Python 3.10及以上版本，推荐3.11或3.12，主要原因是新版本对异步IO和类型注解的支持更好，解析大模型输出时稳定性更高。

创建专门的虚拟环境是好习惯，不然依赖装到全局环境里迟早会有冲突。我的固定流程是这样的：

mkdir -p ~/projects/openshell cd ~/projects/openshell python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip

依赖方面只用了三个核心库，我都列出来并说明原因：

• openai>=1.0：官方SDK，新版采用直接实例化client的方式调用接口，支持流式输出，体验比老版本好太多。
• prompt_toolkit>=3.0：提供终端交互支持。没有它，方向键、历史记录、多行编辑全是问题。
• pyyaml：用于管理本地配置文件。选址上，其实用tomllib也行，但YAML写注释和层级结构更方便。

安装完依赖之后，还需要在项目目录下新建一个配置文件，存放API相关参数。这里有个安全习惯建议：API Key不要直接写进代码文件里，用环境变量加载会更安全。

export OPENAI_API_KEY="sk-你的密钥" export OPENAI_BASE_URL="https://api.openai.com/v1" export OPENAI_MODEL="gpt-4o-mini"

选gpt-4o-mini是我实测下来的最优解。这个模型在命令生成任务上的表现稳定，速度明显比大杯型号快，而且成本低到你基本不用担心跑爆账单。如果你有更强的推理需求，可以随时在配置里换成gpt-4o或者o3-mini，OpenShell的模型名是从环境变量读取的，切换成本为零。

3.2 核心代码实现：自然语言到命令的映射

下面给出OpenShell核心逻辑的精简实现。完整功能版比这个复杂不少，但这一段足以让你理解整个工作流程。

第一步，定义调用大模型的基础函数。这一步的关键是把系统提示词、用户输入和历史上下文组装成messages列表，然后调用Chat Completions接口。

from openai import OpenAI import os, json client = OpenAI( api_key=os.environ.get("OPENAI_API_KEY"), base_url=os.environ.get("OPENAI_BASE_URL"), ) SYSTEM_PROMPT = """你是一个运行在终端里的AI命令行助手。 你的任务是把用户用自然语言描述的操作意图，转换成一到多条可在当前环境执行的Shell命令。 当前环境信息：{env_info} 要求： 1. 只输出JSON，不要输出任何多余的解释文字。 2. JSON格式为：{{"command": "...", "description": "...", "risk": "low|medium|high"}} 3. command必须是可直接粘贴到Shell中执行的完整命令，注意转义和引号。 4. 如果用户请求的操作涉及删除、覆盖、批量修改或提升权限，risk必须标记为high或medium。 5. 如果无法转换或用户意图与命令无关，输出{{"command": "", "description": "无法理解的操作，请补充说明", "risk": "low"}} """ def chat_with_model(user_input, history, env_info): messages = [ {"role": "system", "content": SYSTEM_PROMPT.format(env_info=env_info)}, ] for item in history: messages.append({"role": item["role"], "content": item["content"]}) messages.append({"role": "user", "content": user_input}) resp = client.chat.completions.create( model=os.environ.get("OPENAI_MODEL", "gpt-4o-mini"), messages=messages, temperature=0.1, response_format={"type": "json_object"}, ) return json.loads(resp.choices[0].message.content)

这里有两个很容易被忽略但非常关键的细节。第一是temperature=0.1，生成命令的任务绝对不能给模型太高的“自由发挥空间”，temperature越高，命令越容易出幺蛾子。第二是response_format={"type": "json_object"}，这是强制模型输出JSON的关键开关，不加的话模型动不动就在JSON前后加一些解释性文字，解析时会把你搞疯。

第二步，实现命令执行的确认机制和输出捕获。这一步的核心是两个subprocess参数的灵活运用。

import subprocess, sys def run_command(cmd, shell_type="bash"): print(f"\n[执行] {cmd}") try: result = subprocess.run( cmd, shell=True, executable=shell_type, capture_output=True, text=True, timeout=120, ) if result.stdout: print(result.stdout) if result.stderr: print(result.stderr, file=sys.stderr) return result.returncode, result.stdout, result.stderr except subprocess.TimeoutExpired: print("[超时] 命令执行超过120秒，已终止。") return -1, "", ""

capture_output=True和text=True这两个参数的组合能拿到纯文本的stdout和stderr，方便后续喂给模型做错误分析。timeout=120是为了防止某些命令卡死，不设这个参数的话，碰到一个无限等待的命令整个工具就挂掉了。

第三步，是IDE层面的对话循环。完整版会用到prompt_toolkit，这里先用一个简单的while循环演示主流程。

def main_loop(): history = [] env_info = detect_environment() # 采集环境信息，见下文 print("OpenShell 已启动。输入你的操作意图，输入 exit 退出。") while True: user_input = input("\n❯ ").strip() if user_input in ("exit", "quit"): break if user_input.startswith("/"): handle_special_command(user_input, history) continue result = chat_with_model(user_input, history, env_info) if not result.get("command"): print(result["description"]) continue history.append({"role": "user", "content": user_input}) print(f"\n[解释] {result['description']}") if result["risk"] == "high": print("[警告] 这条命令属于高风险操作，请务必确认影响范围！") confirm = input(f"\n是否执行这条命令？(y=执行 / n=跳过 / s=跳过并保存到剪贴板) ").strip().lower() if confirm == "y": code, stdout, stderr = run_command(result["command"]) history.append({ "role": "assistant", "content": json.dumps({ "command": result["command"], "stdout": stdout[:2000], "stderr": stderr[:800], "returncode": code, }, ensure_ascii=False) }) else: history.append({"role": "assistant", "content": f"用户跳过了命令：{result['command']}"}) if __name__ == "__main__": main_loop()

这里把命令执行结果（包括stdout和stderr的截断内容）追加回history，是实现“报错后追问原因”的关键机制。你不把这个结果喂回去，模型就完全不知道刚才发生了什么。截断到2000字符和800字符是为了控制上下文体积，避免输出太长把Token预算吃光。

3.3 环境信息采集工具函数

环境采集函数决定了模型输出的“本地化”程度，值得单独讲一讲。我采集的这些信息，每一项都有明确用途：

• 系统类型：决定命令风格，比如ls和dir的区别。
• Shell类型：决定是否能用alias、export这类语法。
• 当前目录：让find .这样的相对路径命令能正确运行。
• 关键工具链版本：判断哪些命令可以用，比如系统里没有docker，模型就不该推荐docker ps。

import platform, os, shutil, subprocess def detect_environment(): env = { "os": platform.system(), "release": platform.release(), "shell": os.path.basename(os.environ.get("SHELL", "bash")), "cwd": os.getcwd(), "user": os.environ.get("USER", ""), "python_version": platform.python_version(), } # 检测常见工具是否安装 for tool in ["git", "docker", "node", "npm", "python3", "pip3", "curl", "wget", "jq", "tmux"]: path = shutil.which(tool) if path: try: ver = subprocess.run([tool, "--version"], capture_output=True, text=True, timeout=5) env[tool] = ver.stdout.strip().split("\n")[0][:60] except Exception: env[tool] = "installed" return json.dumps(env, ensure_ascii=False)

这个函数有两点值得优化，我在实际迭代中也确实踩过坑。第一点是--version判断不一定通用，像ffmpeg、openssl这些工具不看--version参数，直接跑会报错，所以异常处理要兜底成installed。第二点是采集耗时问题，每轮对话都跑一遍subprocess会拖慢响应，优化办法是把采集结果缓存起来，只在用户显式要求刷新或者启动时重新采集。

3.4 跑通一个完整场景：用自然语言处理端口占用

光说不练假把式，拿一个真实场景完整演示一下。假设服务器上某个进程占用了8080端口，你希望找到这个进程并终止它。

你在OpenShell里输入：

看一下是谁占用了8080端口，如果是我自己的测试进程就杀掉它

OpenShell调用模型后返回：

• 命令：lsof -i :8080
• 解释：列出占用8080端口的所有进程及详细信息
• 风险：低

执行结果显示8080端口被PID为12345的java进程占用。你继续说：

这个是我上午启动的测试服务，帮我把它停掉

OpenShell生成的命令是：

• 命令：kill 12345
• 解释：终止PID为12345的进程，向该进程发送SIGTERM终止信号
• 风险：高

OpenShell给出警告提示，你确认后执行，进程被成功终止。整个过程如果走老路子，你要至少三步：lsof -i :8080、ps -fp 12345确认进程身份、kill 12345执行终止。现在只需要两句话就搞定了。

这个场景看着简单，但背后演示了OpenShell最核心的“多轮交互”能力——第二轮的命令生成依赖了第一轮的命令输出，没有完整的上下文管理链路，模型根本不可能做到这种流畅的跨轮推理。

4. 常见问题与排查技巧实录

整个开发和使用过程中，我遇到的坑不少，挑几个典型的问题分享出来，应该能帮你少走弯路。

4.1 高频问题速查表

问题现象	根本原因	解决方案
模型返回的内容解析失败	忘了用response_format开启JSON模式	在API请求中加上response_format={"type": "json_object"}
生成的命令在macOS上跑不了	环境感知没做好	确认环境信息是否正确传给系统提示词，注意Linux和macOS的lsof参数差异
生成的命令引号总是出错	模型对转义理解不足	在Prompt中加入明确的转义示例，也可以用base64编码方式传参解决极端情况
长会话后模型开始“失忆”	上下文超过了模型窗口，被截断	加上下文摘要压缩，定期把历史归并为摘要
输出中文乱码	子进程编码设置不兼容	在subprocess.run里显式指定encoding="utf-8"，Windows下建议用gbk做fallback
API请求超时	模型响应过慢或网络不稳定	客户端设置timeout参数，并加上重试机制

4.2 实战避坑：那些文档里不会写的细节

第一个坑是Shell类型匹配问题。同样是pip install这个命令，在bash和zsh里没问题，但在fish shell里语法就完全不同，fish的变量赋值和条件判断跟bash差异极大。环境检测函数必须准确判断出用户的Shell类型，并把类型传到subprocess.run的executable参数里，否则命令可能在bash里好好的，换到用户的fish环境下直接报语法错误。

第二个坑是sudo命令的交互问题。sudo会申请终端Tty，但subprocess.run默认不开Tty，这会导致sudo密码提示符直接消失，命令看起来像卡死了一样。我的解决思路是检测命令里是否包含sudo，如果包含就提示用户在外部终端手动执行，或者改用sudo -S配合密码管道输入。这两种方式各有弊端，手动执行最安全，密码管道最省事但会泄露密码到shell历史里，权衡之下OpenShell默认推荐手动执行。

第三个坑是大模型对“危险命令”的识别并不完美。我实测过让OpenShell“清空所有日志文件”，模型给出的命令是rm -rf /var/log/*，这极其危险。虽然OpenShell有风险提示和确认机制，但机制毕竟不是万能的，用户自己还是得有基本的判断力。后来我给Risk判断逻辑加了“权威兜底”：不管模型怎么判断，只要命令中包含rm -rf、dd if=、mkfs这类关键词，本地代码直接强制标记为高风险。

4.3 指令解析的边界问题

大量实测后发现，response_format开启JSON模式确实能稳定输出JSON，但偶尔会出现JSON里的字符串包含换行符没转义的情况，导致json.loads直接报错。后来我写了一个容错解析函数：先尝试json.loads，失败后用正则把最外层的{...}抓出来，再做一次转义修复。这个概率在1%以下，但你要是跑一整天自动化任务，1%的概率一定会遇到。

另一个边界问题是模型生成的命令中可能包含内联Python代码，比如python3 -c "..."这种。这类命令通常没问题，但要注意引号嵌套的正确性，尤其是外层是JSON字符串时，内层的双引号必须转义成\"。我的做法是让Prompt里明确要求“命令中如果包含内联代码，优先使用单引号包裹代码片段”，实测能显著降低转义错误率。

5. 能力边界与安全策略：什么时候该信AI，什么时候必须靠自己

把OpenShell用得越久，我越清楚它的能力边界在哪里。有些命令生成得又快又准，有些场景它天生就力不从心。

能放心交给它的场景有三个特征：操作可逆、影响范围有限、有标准化的命令方案。查DNS记录、看系统资源、搜日志关键字、批量重命名文件，这些都很适合。危险度高的场景也有三个特征：影响不可逆、操作对象是生产环境、破坏面无法预估。删除数据库、格式化磁盘、清空生产日志、批量修改线上配置，这些我强烈建议你手动敲命令，哪怕OpenShell给出的命令看起来没问题，也请每个参数都确认一遍再执行。

OpenShell内部做了四层安全防线：环境隔离层只输出命令不碰系统底层、解析层强制模型输出结构化JSON、判断层对高危关键词做二次覆盖、执行层必须经过用户确认。但说句实在话，安全策略做得再好，也只是把“误操作”的概率从“高”降到“低”，绝对消除风险靠工具是做不到的，最后一道防线永远是坐在电脑前面的那个人。

我再分享一个个人习惯：在真正重要的机器上，把OpenShell的执行模式固定成“手动模式”，只让它生成命令，所有执行都在我自己手里。多费两秒复制粘贴，换来的是万一出问题时的安全感，这笔账怎么算都划算。

6. 从v1到v2：复盘迭代中的几个关键决策

项目从第一个能跑的版本到现在的形态，中间经历了几次重要的设计转向，每次转向都有明确的原因。

第一版，也就是原型验证版，架构是最简单的“模型直出命令直执行”，Prompt写得也粗糙，安全机制几乎为零。这个版本验证了一个关键假设：大模型确实能把自然语言转成Shell命令，而且准确率远超预期。当时我做了一个一百条命令的测试集，涵盖了文件操作、进程管理、网络诊断、日志分析、Git操作五大类，模型的原始准确率在70%左右，如果允许模型在报错后根据错误信息自我修正，最终成功率能到85%以上。这个数据让我决定把项目从“玩具”升级成“工具”。

第二版的核心工作是安全机制和交互体验。全部命令改为JSON结构化输出、加入风险字段、引入三档执行模式、用prompt_toolkit重构交互层。这一版让OpenShell从“能跑但不敢用”变成了“敢在开发机上日常使用”。

第三版也就是当前版本，重点转向了上下文管理。加入了环境感知、历史摘要压缩、报错回传机制。第三版上线后的最大感受是：多轮对话能力才是这类工具的真正门槛，单轮命令翻译本不难，难的是让模型“记得住”几轮之前发生过什么，并且能在连续对话中保持状态一致性。

迭代中我还做了三个小决策值得一提：第一，默认模型从gpt-4o降级到gpt-4o-mini，速度提升明显，成本降低了一个量级，准确率差距微乎其微；第二，命令的历史记录默认同步写入.openshell_history文件，方便回溯审计，这个为排查“到底执行了什么命令”提供了很大的便利；第三，把Prompt中的示例从两条增加到五条，覆盖不同的风险等级和命令复杂度，模型的输出稳定性立刻上了一个台阶。

7. 未来的方向：本地模型与深度集成的空间

OpenShell现在的形态已经能解决日常终端里的很多烦恼，但它的天花板还远远没到。我自己最想做的几个扩展方向，也分享出来，供你参考。

一个是接入本地部署的开源模型。现在的方案完全依赖云API，虽然快且准，但存在两个问题：数据要送到外部API，敏感环境里不合规；离线场景下完全不可用。如果能把推理端切到本地运行的Qwen、Llama等开源模型，哪怕速度慢一点，准确率差一点，对特定用户群也有不可替代的价值。架构上OpenShell已经做好了准备，模型来源只是环境变量里的一个配置项，切换成本不高。

另一个方向是深度集成终端生态，比如让OpenShell读取Shell的历史记录文件做个性化行为建模。如果模型能了解你常去的目录、常用的工具链、习惯的命名方式，生成的命令会更贴近你的个人操作习惯，而不是冷冰冰的教科书写法。这个方向困难点和隐私风险都不小，但做好了体验确实会很惊艳。

最后畅想一下，这类工具最终形态可能不是站在Shell前面的“助手”，而是隐形地嵌入终端工作流里。你敲完前三个字符，它预测你想要敲的完整命令；你的脚本报错了，它直接从stderr里判断出错因并给出修复建议；你想不起来一条很绕的find命令怎么写，它像补全注释一样把命令补在光标前面。到那个阶段，人与终端的交互方式才算是真正被重塑了。

OpenShell的路还长，但这个方向我走得很坚定。希望这篇文章能给你一些启发——不管你是想直接复刻一个类似的工具，还是想在AI辅助命令行这个方向做点不一样的东西，都欢迎在评论区聊聊你的想法。