1. 项目概述：当命令行成为我的AI对话主界面

最近我做了一个决定，把我日常使用的那些花里胡哨的AI聊天网页界面全给关了，转而用终端（Terminal）里的Shell来和AI对话。这听起来可能有点“返祖”或者极客，但实际体验下来，它带来的效率提升和专注度是那些图形界面难以比拟的。这个项目的核心，就是用最朴素的命令行工具，构建一个高效、可定制、且完全属于我自己的AI交互环境。

你可能会问，现在各种AI应用的客户端、网页版不是挺方便吗？确实，它们提供了开箱即用的体验。但问题也随之而来：频繁的网页切换打断工作流、界面加载消耗时间、历史记录管理不便，以及最关键的——无法深度融入我已有的开发工具链。作为一名长期与终端打交道的开发者，我的核心工作流都在命令行里：代码编辑用Vim/Neovim，版本控制用Git，系统管理用Bash/Zsh脚本。当AI能力也需要被高频调用时，让它也成为这个工作流的一部分，就成了一个自然而然的需求。

这个“终端化”的AI接口，解决的正是“无缝集成”与“极致效率”的问题。它不是一个玩具，而是一个生产力工具。通过它，我可以直接在写代码时向AI提问并获得即时反馈，可以用管道（Pipe）将系统命令的输出直接交给AI分析，可以编写脚本批量处理AI任务，甚至可以将AI的回复作为另一个命令行工具的输入。这一切，都发生在我最熟悉、最可控的黑色窗口里。接下来，我将详细拆解我是如何实现这一转变的，包括工具选型、核心配置、实战技巧以及那些只有踩过坑才知道的注意事项。

2. 核心思路与工具选型：为什么是Shell，以及用什么连接AI

2.1 图形界面与命令行界面的本质差异

在深入工具之前，我们需要理解图形界面（GUI）和命令行界面（CLI）在交互模式上的根本不同。GUI是面向“探索”和“直观”的，它通过按钮、菜单、富文本渲染来降低使用门槛，但交互路径相对固定。而CLI是面向“精确”和“自动化”的，它要求你明确地输入指令，但换来的是极高的灵活性与可编程性。

将AI对话从GUI迁移到CLI，本质上是将一种“对话式探索”行为，转变为“指令化任务”行为。这并非要否定对话的灵活性，而是为其赋予更强的目的性和可重复性。例如，在网页里，你可能会和AI就一个错误信息进行多轮闲聊式提问；在Shell里，你更可能倾向于用一条精心构造的命令直接获取解决方案，并将这个命令保存为脚本或别名（Alias），以备下次一键执行。

2.2 核心工具链选型解析

实现终端AI交互，核心在于一个能在命令行中调用AI模型API的客户端。市面上有多种选择，我的选型基于以下几个原则： 1. 纯命令行工具，无GUI依赖；2. 支持主流AI API（如OpenAI、Anthropic等）；3. 配置灵活，易于集成；4. 社区活跃，维护良好。

基于此，我主要考察并最终选定了以下工具组合：

  1. ollama + 本地模型 ：这是我的主力方案。Ollama是一个强大的本地大模型运行和部署框架。它的命令行客户端 ollama 使用极其简单。

    # 拉取一个模型（如 Llama 3.1）
ollama pull llama3.1
# 直接与模型对话
ollama run llama3.1

    选择它的理由： 数据完全本地，无网络延迟，隐私无忧，可离线使用 。对于代码生成、文档总结、脚本编写等对实时性要求不高但对隐私和可控性要求高的任务，它是完美选择。性能取决于本地硬件，但在配备现代GPU的机器上，体验已非常流畅。

  2. openai 官方CLI / llm ：用于连接云端AI服务。

    • OpenAI CLI : 官方出品，与API同步更新，功能最准确。 
      # 需要先设置环境变量 OPENAI_API_KEY
export OPENAI_API_KEY='your-key-here'
# 调用GPT-4进行对话
openai api chat_completions.create -m gpt-4 -g user "Hello, world"
    • llm ：一个由Simon Willison开发的通用AI命令行工具，其设计哲学是“为语言模型提供统一的命令行界面”。它通过插件系统支持数十种模型（OpenAI, Anthropic Claude, Google Gemini， 甚至本地Ollama模型）。 
      # 安装后，配置API Key
llm keys set openai
# 然后就可以用统一的命令调用了
llm "用Python写一个快速排序函数"

    我最终更倾向于使用 llm 。理由在于其 统一的语法 和 强大的管道与日志功能 。无论后端是GPT-4还是Claude，我都是用 llm 这个命令，大大降低了记忆成本。它的对话模式 ( llm -c ) 和聊天日志存储功能也非常实用。

  3. Shell自身： bash / zsh + 文本编辑器 ：这是我们的“画布”。通过编写Shell函数、别名和脚本，我们将上述AI工具深度集成到工作流中。例如，我可以创建一个别名，将 llm 命令缩短为 g （代表“问”），或者写一个函数，自动将当前Git diff的内容发送给AI分析。

2.3 辅助工具：提升终端内体验

仅有核心调用工具还不够，终端内的交互体验也需要优化：

  • fzf (模糊查找器) ：用于交互式选择历史提问或模型。可以配置成用 Ctrl+R 搜索AI对话历史。
  • jq ：当API返回JSON格式的结果时， jq 是解析和提取信息的利器。
  • 终端多路复用器 ( tmux 或 screen ) ：可以在一个终端窗口内创建多个面板，一个写代码，一个运行AI，一个看日志，实现真正的并行工作流。
  • 高级Shell ( zsh 或 fish ) ：它们提供更强大的自动补全和语法高亮，对于编写复杂的AI调用脚本很有帮助。

选型心得 ：没有“唯一正确”的工具链。我的建议是， 从 ollama 搭配一个中小参数模型（如 llama3.1:8b ）开始 。它免去了API Key和网络的烦恼，让你快速体验终端AI的流畅感。待熟悉后，再引入 llm 来接入更强大的云端模型，应对复杂任务。这种组合兼顾了隐私、成本、性能和能力。

3. 环境配置与核心脚本编写

3.1 基础安装与配置

首先，确保你的系统上安装了选定的工具。以 macOS (使用Homebrew) 和 Ubuntu/Debian 为例：

# 安装 ollama (macOS & Linux)
# 访问 https://ollama.com 下载安装包，或使用Linux curl脚本安装。

# 安装 llm (Python包)
pip install llm
# 或者使用 pipx 进行全局安装（推荐，避免污染环境）
pipx install llm

# 安装辅助工具
# macOS
brew install fzf jq
# Ubuntu/Debian
sudo apt install fzf jq

接下来是关键的配置环节。对于 llm ，你需要设置API密钥。 永远不要将密钥硬编码在脚本中！ 使用环境变量或 llm 的密钥管理功能。

# 方法1：设置环境变量（放入 ~/.zshrc 或 ~/.bashrc）
export OPENAI_API_KEY='sk-...'
export ANTHROPIC_API_KEY='your-claude-key'

# 方法2：使用 llm keys set 命令（更安全，密钥存储在本地数据库）
llm keys set openai
# 然后粘贴你的OpenAI API Key
llm keys set anthropic
# 然后粘贴你的Anthropic API Key

3.2 打造你的核心AI Shell函数

这是将AI能力“内化”为Shell本能的关键。我们将在Shell的配置文件（ ~/.zshrc 或 ~/.bashrc ）中编写一系列函数和别名。

3.2.1 基础问答函数

创建一个最简单的函数，让我们能用 ask 命令向AI提问。

# 添加到 ~/.zshrc
ask() {
    if [ -z "$1" ]; then
        echo "Usage: ask <你的问题>"
        return 1
    fi
    # 使用 llm，默认模型为 gpt-4o-mini
    llm -m gpt-4o-mini "$*"
}

现在，在终端里输入 ask "如何用awk统计文本行数？" ，你就能直接获得答案。

3.2.2 带上下文的对话函数

单次问答不够？我们需要一个能进行多轮对话的函数。这里利用 llm 的 -c (continue) 选项和系统临时文件来维护上下文。

# 添加到 ~/.zshrc
# 定义一个全局变量来存储对话ID（可选，更复杂但更优雅的方式是使用文件）
# 这里展示一个简单版本：使用一个固定的临时文件来存储最近对话的ID
AI_CHAT_LOG="$HOME/.ai_chat_log"

chat() {
    local prompt="$*"
    if [ -z "$prompt" ]; then
        # 如果没有输入，且日志文件存在，则继续上次对话
        if [ -f "$AI_CHAT_LOG" ]; then
            echo "继续上次对话（输入内容，空行结束）:"
            local multi_line_input=$(cat)
            llm -c "$(cat $AI_CHAT_LOG)" "$multi_line_input" | tee >(tail -n 1 > $AI_CHAT_LOG)
        else
            echo "开始新对话（输入内容，空行结束）:"
            local multi_line_input=$(cat)
            llm -m gpt-4o "$multi_line_input" | tee >(tail -n 1 > $AI_CHAT_LOG)
        fi
    else
        # 如果有输入参数，则作为单次提问或开始新对话
        llm -m gpt-4o "$prompt" | tee >(tail -n 1 > $AI_CHAT_LOG)
    fi
}

# 清空对话历史
alias clear-chat='rm -f $HOME/.ai_chat_log'

这个 chat 函数实现了基本的多轮对话记忆。 llm -c 参数会自动引用上一次对话的ID。我们通过一个临时文件来记录最后一次交互的模型输出，以此维持会话状态。

3.2.3 代码专项处理函数

作为开发者，让AI审查或生成代码是高频需求。我们可以创建一个函数，专门处理代码片段。

# 添加到 ~/.zshrc
code_review() {
    if [ -z "$1" ]; then
        # 如果没有参数，从剪贴板读取
        local code_to_review=$(pbpaste) # macOS
        # Linux 使用: local code_to_review=$(xclip -selection clipboard -o)
    else
        # 如果参数是一个文件，则读取文件内容
        if [ -f "$1" ]; then
            local code_to_review=$(cat "$1")
        else
            # 否则将参数视为代码字符串
            local code_to_review="$1"
        fi
    fi

    local prompt="请对以下代码进行审查，指出潜在的错误、风格问题、性能瓶颈，并提供改进建议。代码语言根据内容自行判断。\n\n\`\`\`\n$code_to_review\n\`\`\`"
    llm -m gpt-4o "$prompt"
}

alias cr=code_review

现在，你可以将一段代码复制到剪贴板，然后在终端运行 cr ，或者直接 cr myfile.py ，AI就会给出代码审查意见。

3.3 高级集成：让AI融入现有工作流

真正的威力在于将AI与现有Unix工具链结合。

3.3.1 与Git集成

创建一个命令，让AI总结本次提交的更改：

# 添加到 ~/.zshrc
git-ai-summary() {
    local diff_content=$(git diff --cached) # 查看已暂存的更改
    if [ -z "$diff_content" ]; then
        diff_content=$(git diff HEAD~1 HEAD) # 或者总结最近一次提交
    fi
    if [ -z "$diff_content" ]; then
        echo "没有找到可总结的git diff内容。"
        return 1
    fi
    local prompt="请根据以下git diff输出，用一句简洁的话概括本次代码更改的核心内容，适合用作提交信息（commit message）。\n\`\`\`diff\n$diff_content\n\`\`\`"
    llm -m gpt-4o-mini "$prompt"
}

运行 git-ai-summary ，AI会帮你生成一个建议的提交信息。

3.3.2 与系统诊断集成

当服务器出现问题时，可以将一系列诊断命令的结果喂给AI分析。

# 添加到 ~/.zshrc
diagnose() {
    echo "正在收集系统信息..."
    local sysinfo=$(echo "--- Top Output ---"; top -l 1 -n 0; echo; echo "--- Disk Usage ---"; df -h; echo; echo "--- Memory Info ---"; vm_stat; echo; echo "--- Recent Logs (tail) ---"; tail -20 /var/log/system.log 2>/dev/null || echo "无法访问系统日志")
    local prompt="我遇到了系统性能问题。请分析以下系统诊断信息，指出可能的问题根源和排查建议。\n\n$sysinfo"
    llm -m gpt-4o "$prompt"
}

3.3.3 利用管道 (Pipe) 进行流式处理

这是Shell AI的杀手级特性。你可以将任何命令的输出直接作为AI的输入。

# 查找当前目录下所有.py文件，让AI找出哪些文件可能定义了‘calculate’函数
find . -name "*.py" -exec grep -l "def calculate" {} \; | llm -m gpt-4o “这些Python文件路径可能包含了‘calculate’函数的定义。请根据路径名，推测这个项目的可能功能结构。”

# 分析最近的服务器访问日志，寻找异常模式
tail -100 /var/log/nginx/access.log | llm -m gpt-4o “这是Nginx访问日志的最后100行。请快速扫描，是否有异常的访问模式（如大量404、单一IP高频访问等）？简要列出你的观察。”

配置要点 ：在配置Shell函数时， 务必做好错误处理 。检查命令是否存在、参数是否为空、API是否响应。初期可以多使用 echo 打印调试信息。另外，将你的配置脚本（如 .zshrc 中AI相关部分）进行版本控制（如放到GitHub Gist），方便在多台机器间同步。

4. 实战应用场景与效率提升案例

理论说再多，不如看看实际怎么用。以下是我日常工作中，终端AI接口如何具体提升效率的几个场景。

4.1 场景一：沉浸式编程与即时调试

我正在用Vim写一个Python数据处理脚本，遇到了一个 pandas 合并操作性能瓶颈。传统做法是：1. 切出Vim；2. 打开浏览器；3. 可能先打开Stack Overflow标签页；4. 再打开AI聊天网页；5. 描述问题；6. 等待回答；7. 复制代码回终端测试。流程冗长，上下文切换成本高。

现在，我只需要在Vim中按下 :! （执行外部命令），或者直接在一个相邻的tmux面板里，输入：

ask “我有一个大型的pandas DataFrame `df1` 和 `df2`，需要根据‘id’列进行左连接（left join），但`df2`中有重复的‘id’。我希望合并时只取`df2`中每个‘id’的第一行，并且想知道最高效的写法。用Python实现。”

答案直接显示在终端里。如果答案包含代码块，我甚至可以用终端鼠标选择或配合 tmux 的复制模式，快速将代码粘贴回Vim。整个过程视线无需离开终端，思维流不被中断。

更进一步 ：我可以写一个Vim映射（mapping），将当前选中的代码段直接发送给AI审查。

" 在 ~/.vimrc 中添加
vnoremap <leader>ai :!llm -m gpt-4o “审查以下代码：”<CR>

选中代码，按 \ai ，审查意见就回来了。

4.2 场景二：数据处理与即时分析

我手头有一个CSV文件 sales.csv ，想快速了解其结构和数据概况。传统做法可能是用Excel打开，或者写几行Python的 pandas 代码。

在终端里，我可以通过管道组合命令：

# 1. 先看前几行和结构
head -5 sales.csv | ask “这个CSV文件的前5行数据如下，请推测各列的含义和数据格式。”

# 2. 进行快速统计分析
awk -F',' '{sum+=$3} END {print “总销售额:”, sum}' sales.csv
# 假设第3列是销售额，上面命令算出总和。但我想知道更多。
# 我可以将多个统计结果组合起来提问
echo “文件 sales.csv 共有 $(wc -l < sales.csv) 行数据。总销售额为 $(awk -F',' '{sum+=$3} END {print sum}' sales.csv)。请根据这些信息，给出进一步的数据分析思路。” | llm -m gpt-4o

AI可能会建议我检查销售额的分布、按类别聚合等。我可以继续用 awk , sort , uniq 等命令生成新数据，再喂给AI解读。这种“命令行计算 + AI洞察”的循环，对于探索性数据分析（EDA）初期非常高效。

4.3 场景三：学习与文档查阅

我在学习一个新的命令行工具，比如 jq 。手册（man page）信息量大但不够直观。我可以：

# 直接问AI要常用例子
ask “给我10个最实用的jq命令例子，用于处理JSON API响应。”

# 结合实践：我有一个复杂的JSON，想提取特定路径
cat complex.json | jq . | ask “这个JSON数据结构很深。我的目标是提取所有‘user’对象下的‘email’字段。请写出正确的jq命令，并解释路径是如何确定的。”

AI给出的例子和解释，通常比静态文档更贴合我当下的具体上下文和认知水平。

4.4 场景四：自动化与脚本编写

我需要定期清理某个目录下超过30天的日志文件，并发送摘要邮件。我可以让AI帮我起草这个脚本的框架。

ask “写一个Bash脚本，功能是：1. 查找 /var/log/myapp/ 目录下所有超过30天的.log文件；2. 将它们压缩打包，以当前日期命名；3. 删除原.log文件；4. 将本次清理的文件列表和总大小通过邮件发送给 admin@example.com。请添加详细的注释。”

得到脚本草案后，我在终端里直接 vim cleanup.sh 开始编辑和调试。由于整个过程都在终端内，修改、测试、运行非常顺畅。

场景心得 ：终端AI的核心优势是 “缩短反馈回路” 。它将提问、获取信息、执行命令、获得结果这几个步骤压缩在同一个极简环境中。关键在于培养一种“遇到问题，先想想能不能用一条命令+AI解决”的思维习惯。一开始可能需要刻意练习，但一旦形成肌肉记忆，效率提升是指数级的。

5. 性能优化、成本控制与隐私考量

5.1 响应速度优化

云端API的响应速度受网络延迟影响。为了获得更快的体验：

  • 使用流式输出（Streaming） ：许多CLI工具支持流式输出，就像在网页里看到AI一个字一个字打出来一样。 llm 默认就是流式输出。这虽然不减少总时间，但能让你尽早看到部分结果，感知延迟更低。
  • 选择合适的模型 ：对于不需要最强推理能力的任务（如简单的文本格式化、基础代码补全），使用更轻量的模型，如 gpt-4o-mini 或 claude-haiku ，它们的响应速度通常更快，成本也更低。
  • 本地模型优先 ：对于延迟敏感型任务（如IDE内联补全）， ollama 运行的本地模型是终极解决方案，延迟可以降到毫秒级。你需要权衡的是模型能力与本地硬件资源。

5.2 使用成本控制

直接使用OpenAI、Anthropic的API是按Token计费的，无节制使用账单可能飙升。

  • 设置使用预算和提醒 ：在API提供商后台设置每月预算和用量警报。
  • 善用本地模型 ：将大部分日常的、对能力要求不高的对话（如解释概念、修改简单代码、总结文本）交给本地模型（如通过 ollama 运行的 llama3.1:8b ）。仅在处理复杂逻辑、需要最新知识或极高准确性的任务时，才调用GPT-4或Claude Opus。
  • 精心设计提示词（Prompt） ：清晰、具体的提示词能减少不必要的来回对话轮数，从而节省Token。在Shell中，你可以将精心打磨的提示词保存为模板文件或Shell变量。 
    # 定义一个代码审查的提示词模板
CODE_REVIEW_PROMPT="请扮演资深代码审查员。请严格审查以下代码，按以下顺序输出：1. [安全性] 潜在的安全漏洞；2. [性能] 性能瓶颈；3. [可读性] 代码风格与可读性问题；4. [改进] 具体的重构建议。代码："
# 使用
cat myfile.py | llm -m gpt-4o "$CODE_REVIEW_PROMPT"
  • 利用 llm 的日志功能 ： llm 会默认记录所有交互。定期查看日志 ( llm logs )，分析哪些提问是低效或重复的，优化你的提问方式。

5.3 隐私与数据安全

这是终端AI方案相比网页版的一大优势，但也需注意：

  • 本地模型是隐私冠军 ：所有数据都在本地计算，绝不离开你的机器。 ollama 是此场景下的首选。
  • 云端API的数据政策 ：当你使用OpenAI、Anthropic等API时，你的提示词和结果会发送到他们的服务器。根据其政策，这些数据可能被用于一段时间内的模型改进（某些情况下可主动选择退出）。 切勿通过API发送敏感个人信息、商业秘密、未脱敏的代码或数据。
  • Shell历史记录 ：你的提问命令会被记录在Shell历史（如 ~/.zsh_history ）中。如果提问中包含敏感信息，这是一个风险点。
    • 应对方法1 ：在命令前添加一个空格（在Bash/Zsh中，如果设置了 HISTCONTROL=ignorespace ，则带空格的命令不会被记录）。
    # 这条命令不会被记录到历史
 llm “我的密码是...”
    • 应对方法2 ：对于高度敏感的操作，使用临时环境变量或在脚本中从文件读取内容，避免在命令行中直接输入。
    sensitive_prompt=$(cat sensitive_input.txt)
llm -m gpt-4o <<< "$sensitive_prompt"
    • 应对方法3 ：定期清理Shell历史，或配置历史记录不包含包含 llm 或 ask 的命令（通过 HISTIGNORE 环境变量设置）。

安全与成本心得 ：建立分层使用策略。我的策略是： 日常问答、学习、非敏感代码 -> 本地模型 ( ollama )；复杂设计、深度分析、需要联网知识 -> 云端经济模型 ( gpt-4o-mini , claude-haiku )；关键系统设计、重要文档撰写 -> 云端顶级模型 ( gpt-4o , claude-opus ) 。同时，所有涉及公司代码或数据的工作，坚决使用本地模型或经过严格审查的隔离环境。

6. 常见问题、故障排查与进阶技巧

6.1 安装与配置问题

  • 问题： llm 命令未找到。

    • 排查 ：确认安装方式。如果使用 pip install llm ，请检查 ~/.local/bin 是否在系统的PATH环境变量中。如果是 pipx install llm ， pipx 通常会自动处理PATH。
    • 解决 ：对于 pip install ，在 ~/.zshrc 中添加 export PATH="$HOME/.local/bin:$PATH" ，然后执行 source ~/.zshrc 。

  • 问题：Ollama 拉取模型速度慢或失败。

    • 排查 ：网络连接问题，或镜像源问题。
    • 解决 ：可以尝试配置Ollama使用国内镜像源（如果存在且可信）。对于下载中断，可以使用 ollama pull <模型名> --verbose 查看详细进度，并支持断点续传。

  • 问题：API调用返回认证错误 (401, 403)。

    • 排查 ：API密钥未设置或设置错误；密钥对应的账户余额不足或权限受限。
    • 解决 ：使用 echo $OPENAI_API_KEY 检查环境变量是否正确。使用 llm keys 检查 llm 存储的密钥。前往API提供商后台检查账户状态和额度。

6.2 使用过程中的问题

  • 问题：AI的回答不准确或胡言乱语（特别是本地模型）。

    • 排查 ：提示词不清晰；模型能力有限；上下文长度超限。
    • 解决 ：
      1. 优化提示词 ：遵循“角色-任务-上下文-格式”的结构。例如：“你是一个经验丰富的Linux系统管理员。请分析以下 top 命令输出，找出占用CPU最高的进程，并给出下一步排查建议。请以要点列表形式输出。”
      2. 切换模型 ：对于复杂任务，尝试能力更强的模型（如从 llama3.1:8b 切换到 llama3.2:3b 或云端模型）。
      3. 控制上下文 ：如果对话很长，本地模型可能会“遗忘”开头的内容。对于长文档处理，考虑将其分段总结，或者使用支持更长上下文的模型。

  • 问题：流式输出在终端中显示乱码或格式错乱。

    • 排查 ：终端对控制字符（如用于渲染Markdown的ANSI转义码）支持不佳。
    • 解决 ：可以尝试禁用流式输出，一次性获取完整响应。在 llm 中使用 -s/--no-stream 参数。或者，升级或更换一个更现代的终端模拟器（如 iTerm2, WezTerm, Alacritty）。

  • 问题：Shell函数在管道中使用时行为异常。

    • 排查 ：Shell函数内可能使用了 read 或依赖终端输入，而管道传递的是标准输入。
    • 解决 ：在函数中，如果需要从管道读取输入，应使用 cat - 或直接处理 $1 。确保函数能正确处理两种输入方式（参数和标准输入）。

6.3 进阶技巧与个性化

  1. 模型别名管理 ：为常用的模型创建短别名。

    # 在 ~/.zshrc 中
alias gpt='llm -m gpt-4o'
alias claude='llm -m claude-3-5-sonnet'
alias llama='ollama run llama3.1'

    这样， gpt “你好” 和 llama “你好” 就能快速调用不同模型。

  2. 提示词模板库 ：将常用的、复杂的提示词保存为文本文件。

    # ~/prompts/code_review.txt
你是一位注重安全性和性能的资深工程师。请审查以下代码。
重点关注：
1. 潜在的安全漏洞（如注入、溢出）。
2. 明显的性能反模式（如循环内的重复计算、未使用索引）。
3. 代码可读性和一致性。
请按[安全]、[性能]、[可读性]分类列出问题，并为每个问题提供具体的代码修改建议。

代码：
{{CODE}}

    使用时：

    prompt=$(cat ~/prompts/code_review.txt)
# 用实际代码替换占位符
prompt=${prompt/\{\{CODE\}\}/"$(cat myfile.py)"}
echo "$prompt" | llm -m gpt-4o

  3. 集成到IDE/编辑器 ：虽然我们在用终端，但现代IDE（如VSCode）的集成终端同样强大。你可以在VSCode的终端面板里运行这些AI命令，并轻松地在编辑器和AI回答之间复制代码。更进一步，可以寻找或开发使用Language Server Protocol (LSP) 的AI插件，但那就超出了纯Shell的范畴。

  4. 日志与知识管理 ： llm 的日志 ( ~/.llm/log.db ) 是一个SQLite数据库。你可以用SQL查询自己的对话历史，甚至构建一个简单的个人知识库。

    # 使用 sqlite3 命令行工具查询过去一天内所有包含‘error’关键词的对话
sqlite3 ~/.llm/log.db “SELECT prompt, response FROM conversations WHERE datetime(timestamp) > datetime(‘now’, ‘-1 day’) AND prompt LIKE ‘%error%’;”

从图形界面切换到终端Shell来与AI交互，远不止是换个“皮肤”。这是一次工作流范式的转变，它迫使你更精确地思考问题，并将AI能力无缝编织进已有的、以文本和自动化为核心的生产力体系中。它剥离了所有视觉干扰，让你专注于信息和逻辑本身。初期可能会有些许不适应，但一旦你习惯了用几条命令和管道来驱动AI完成工作，那种流畅感和掌控感会让你再也回不去频繁切换标签页的时代。这不仅仅是使用了一个新工具，而是培养了一种更高效、更专注的人机协作思维。

Logo
加入AMD AI开发者计划！

免费领 200 小时云算力，进群参与显卡、AI PC 幸运抽奖

更多推荐

主流大模型推理部署框架：vLLM、SGLang、TensorRT-LLM、ollama、XInference

本文系统梳理了当前主流的大模型推理部署框架，包括vLLM、SGLang、TensorRT-LLM、Ollama、XInference等。vLLM基于PyTorch，采用PagedAttention和ContinuousBatching技术，适合高并发企业级应用；SGLang通过RadixAttention优化缓存复用，擅长多轮交互场景；TensorRT-LLM由NVIDIA深度优化，在GPU上性能

avatar AMD开发者中国社区
cover

实战教程：如何在 GitHub Copilot CLI 中配置与调用自定义智能体

avatar AMD开发者中国社区

SGLang 结合 TileLang 打造高吞吐推理引擎

本文详解如何结合 SGLang 调度框架与 TileLang 算子优化，在 AMD ROCm 环境下打造高吞吐推理引擎。通过自定义 Flash Attention 内核，显著降低长序列场景下的首字延迟并提升解码吞吐量，为构建高效大模型服务提供实战指南。

avatar AMD开发者中国社区