1. 项目概述：当命令行遇上大模型

如果你和我一样，每天有大量时间“焊”在终端里，那么一个想法可能会自然而然地冒出来：能不能让大模型也住进命令行？不是打开网页，不是切换应用，就是在那个熟悉的黑框框里，直接和AI对话、让它写代码、分析日志、甚至帮你规划复杂任务。这个想法，就是“cli + 智谱 glm-5”项目的核心。它不是一个简单的API调用封装，而是旨在打造一个深度集成到开发者工作流中的命令行智能伙伴。智谱的GLM-5模型，以其在代码生成、系统设计思考和多步骤任务处理上的能力，成为了实现这个想法的绝佳“大脑”。而CLI（命令行界面），则是将这个大脑的能力无缝注入到你指尖的最短路径。

简单来说，这个项目就是为GLM-5模型打造一个功能强大、体验流畅的命令行客户端。它解决的痛点非常明确： 效率断层 。当你正在终端中调试一个复杂脚本，突然需要AI辅助理解一段错误堆栈或生成一个补丁时，频繁切换上下文到浏览器或桌面应用是极其打断心流的。一个本地的CLI工具，可以让你用一条命令，比如 glm ask “如何用Python优雅地合并这两个JSON文件？” ，瞬间获得答案，并直接在当前目录生成代码文件。这不仅仅是快，更是对工作专注度的最大保护。

这个工具适合所有以终端为主要战场的开发者、运维工程师、数据科学家乃至技术管理者。无论你是想快速生成一个脚本脚手架，还是让AI帮你分析服务器日志中的异常模式，或是进行一场关于系统架构的“头脑风暴”，一个设计良好的CLI大模型工具都能让你事半功倍。接下来，我将拆解如何从零开始构建这样一个工具，并分享其中涉及的核心技术选型、设计思路以及我趟过的一些坑。

2. 核心设计思路与架构选型

构建一个“cli + 大模型”应用，远不止是调用API那么简单。它需要在前端交互、后端通信、状态管理、安全性等多个层面进行精心设计。我们的目标是打造一个既强大又易用的工具，让用户感觉它就像 git 或 curl 一样自然。

2.1 核心功能定义与用户旅程

首先，我们需要明确这个CLI工具的核心价值，并将其转化为具体功能。基于GLM-5的特性，我规划了以下几个核心模块：

1. 交互式对话 ：这是基础。用户输入 glm chat 即可进入一个持续的、带上下文记忆的对话会话。这对于调试、设计讨论等需要多轮交互的场景至关重要。
2. 单次指令执行 ：快速问答模式。例如 glm ask “用Go写一个HTTP服务器的健康检查端点” ，工具执行后直接输出结果并退出。这适合一次性任务。
3. 代码文件操作 ：这是提升效率的关键。支持 glm gen -f output.py “生成一个FastAPI的CRUD模板” ，让AI直接将代码写入指定文件。更进一步，可以支持 glm explain path/to/file.py ，让AI解释现有代码的逻辑。
4. 上下文管理 ：GLM-5支持长上下文。CLI需要能管理不同的“会话”，允许用户保存、加载和切换对话上下文，甚至将本地文件内容作为上下文喂给模型。
5. 流式输出与格式化 ：大模型生成内容是流式的。CLI必须支持流式打印，让用户能实时看到生成过程，而不是干等。同时，对代码、JSON等结构化内容进行语法高亮，提升可读性。

用户典型的使用旅程可能是：在终端中，用户通过 glm chat 进入交互模式，描述他正在构建的一个微服务认证模块遇到的困难。经过几轮讨论，GLM-5给出了一个使用JWT的方案概览。用户然后退出聊天，使用 glm gen -f auth_service.py 并附上刚才讨论的要点，让AI生成具体的代码框架。最后，他用 glm ask “如何为这个auth_service.py编写单元测试？” 快速补全测试用例。整个过程无需离开终端。

2.2 技术栈选型与考量

选型决定了开发的效率和最终工具的质量。以下是我的选择及其背后的逻辑：

• 开发语言：Python

  • 理由 ：这是最自然的选择。首先，智谱AI官方提供了Python SDK，集成成本最低。其次，Python在构建CLI工具方面有极其成熟的生态，如 argparse 、 click 或 typer 库，能快速构建出功能丰富、支持自动补全和彩色输出的命令行应用。最后，我们的目标用户（开发者）对Python普遍熟悉，便于他们自行扩展或排查问题。
  • 备选考量 ：Go或Rust在生成单一二进制文件、启动速度上有优势，但初期开发效率和SDK支持度不如Python。我们优先保证核心功能的快速实现和稳定。

• CLI框架：Typer

  • 理由 ：相比传统的 argparse ， Typer 基于Python类型提示，声明式地定义命令和参数，代码更简洁、直观。它自动生成帮助文档，并天然支持Shell补全（bash, zsh, fish）。这对于一个命令可能有多重参数的工具来说，能极大提升用户体验。
  • 实操心得 ：使用 Typer 时，务必为每个命令函数和参数添加清晰的 help 描述。这不仅能生成友好的 --help 文档，未来在实现AI自动理解命令意图时（如果要做），这些描述也是宝贵的数据源。

• HTTP客户端与异步：httpx 与 asyncio

  • 理由 ：智谱API调用是网络I/O密集型操作。使用同步请求（如 requests 库）在流式输出时会阻塞，体验不流畅。 httpx 库支持全功能的异步HTTP请求，与Python的 asyncio 结合，可以轻松实现不阻塞终端的流式内容打印。这对于保持CLI的响应性至关重要。
  • 注意事项 ：异步编程在CLI中需要小心处理事件循环。通常在主入口函数使用 asyncio.run(main()) 。要确保所有I/O操作（API调用、文件读写）都放在异步函数中，避免混用同步代码导致意外阻塞。

• 配置管理：Pydantic + dotenv

  • 理由 ：API Key等敏感信息绝不能硬编码在代码中。采用 python-dotenv 从 .env 文件加载环境变量，再用 Pydantic 做配置验证和类型转换，是既安全又优雅的做法。可以定义一个 Settings 类，强制要求必须配置 ZHIPU_API_KEY 和 ZHIPU_API_BASE （如果需要），并在应用启动时进行校验。
  • 配置示例结构 ：

    # .env 文件
    ZHIPU_API_KEY=your_api_key_here
    MODEL=glm-5
    # 可选：设置代理、超时时间等
    HTTP_PROXY=http://your-proxy:port
    REQUEST_TIMEOUT=30
    

• 上下文与记忆：SQLite

  • 理由 ：我们需要持久化存储聊天会话的历史记录。虽然简单的JSON文件也能胜任，但SQLite作为一个轻量级、无服务器的数据库，能更方便地进行会话的查询、更新和管理（例如，为每个会话打标签、按时间排序）。Python标准库自带 sqlite3 ，无需额外依赖。
  • 设计要点 ：数据库表设计至少包含 sessions （会话元数据）和 messages （消息内容）两张表。 messages 表通过 session_id 外键关联，并存储角色（user/assistant）、内容和时间戳。这样，恢复历史会话时，可以直接按顺序查询出完整的对话上下文。

2.3 项目结构规划

一个清晰的项目结构是长期可维护性的基础。我建议的目录结构如下：

glm-cli/
├── glm_cli/          # 主包目录
│   ├── __init__.py
│   ├── main.py       # Typer应用主入口，命令定义
│   ├── core/         # 核心逻辑
│   │   ├── __init__.py
│   │   ├── client.py # 封装智谱API客户端，处理流式响应
│   │   ├── config.py # 配置加载与验证 (Pydantic)
│   │   └── context.py # 上下文管理（数据库操作）
│   ├── models/       # 数据模型
│   │   ├── __init__.py
│   │   └── message.py # 消息、会话的Pydantic模型
│   └── utils/        # 工具函数
│       ├── __init__.py
│       ├── printer.py # 美化输出（颜色、高亮、流式打印）
│       └── helpers.py # 通用辅助函数
├── .env.example      # 环境变量示例文件
├── requirements.txt  # 项目依赖
├── setup.py          # 打包配置
└── README.md         # 项目说明文档

这个结构将不同职责的代码分离，使得测试、扩展和理解都变得更加容易。例如，当智谱API升级时，我们只需要修改 core/client.py ；当需要增加新的输出格式时，只需改动 utils/printer.py 。

3. 核心模块实现细节解析

有了清晰的架构，接下来我们深入几个核心模块，看看具体如何实现，以及其中有哪些需要特别注意的“魔鬼细节”。

3.1 智谱API客户端的封装

这是与GLM-5模型通信的核心。官方SDK提供了基础功能，但为了更好的CLI体验，我们需要进行二次封装，重点是 处理流式响应 和 错误重试 。

首先，安装官方SDK： pip install zhipuai 。然后创建 core/client.py 。

# core/client.py
import asyncio
from typing import AsyncGenerator
import httpx
from zhipuai import ZhipuAI
from ..config import settings # 导入配置
from ..utils.printer import stream_print # 导入我们的流式打印工具

class GLMClient:
    def __init__(self):
        self.client = ZhipuAI(api_key=settings.ZHIPU_API_KEY)
        # 可以在这里配置base_url、超时等，如果官方SDK支持的话
        # 否则可能需要用httpx自定义异步客户端

    async def chat_completion_stream(self, messages: list, model: str = None) -> AsyncGenerator[str, None]:
        """
        发起流式聊天补全请求。
        Args:
            messages: 消息列表，格式 [{"role": "user", "content": "..."}, ...]
            model: 模型名称，默认为配置中的模型
        Yields:
            模型返回的每个chunk中的文本内容
        """
        model = model or settings.MODEL
        try:
            # 注意：官方SDK的stream调用可能是同步的，这里展示理想化的异步接口
            # 实际可能需要根据SDK调整，或用httpx直接调用原始API
            response = self.client.chat.completions.create(
                model=model,
                messages=messages,
                stream=True,
                # 可以传递其他参数，如temperature, max_tokens等
            )
            for chunk in response:
                if chunk.choices and chunk.choices[0].delta.content:
                    content = chunk.choices[0].delta.content
                    yield content
        except Exception as e:
            # 这里可以细化异常处理，如网络错误、认证错误、额度不足等
            yield f"\n[API错误] 请求失败: {e}\n"
            # 或者抛出特定异常，由上层处理

关键点与避坑指南 ：

1. 流式处理 ： stream=True 参数是实现逐字打印的关键。接收到的 chunk 是一个增量数据，需要判断 chunk.choices[0].delta.content 是否存在并取出。 特别注意 ：流式响应结束时，可能会收到一个 content 为 None 的chunk，表示结束，你的代码需要能优雅处理。
2. 错误处理 ：网络请求可能失败。必须用 try...except 包裹，并将错误信息以用户友好的方式输出。对于可重试的错误（如网络超时），可以考虑加入简单的重试逻辑（例如，最多重试2次）。
3. 异步与同步 ：如上代码注释所述，官方SDK的调用方式需要核实。如果它是同步的，在流式输出时可能会阻塞。一个更彻底的方案是，不使用官方SDK，直接使用 httpx.AsyncClient 调用智谱的原始HTTP API，这样可以获得完全的异步控制权。这增加了复杂度，但能提供最佳的响应体验。
4. 参数配置 ：除了必填的 model 和 messages ，记得暴露一些关键参数给用户，比如 temperature （创造性）、 max_tokens （生成长度）。可以在CLI命令中通过选项提供，例如 glm chat --temperature 0.7 --max-tokens 2000 。

3.2 交互式聊天会话的实现

这是CLI工具的“面子工程”，用户体验直接由此决定。我们需要实现一个循环，不断读取用户输入，调用上面的客户端，并流式打印输出，同时维护对话历史。

在 main.py 或一个专门的 chat_session.py 中：

# 部分核心代码示意
import typer
from typing import Optional
from glm_cli.core.client import GLMClient
from glm_cli.core.context import SessionManager
from glm_cli.utils.printer import print_assistant, print_user, stream_print

app = typer.Typer()
client = GLMClient()
session_manager = SessionManager()

@app.command()
def chat(
    session_name: Optional[str] = typer.Option(None, "--session", "-s", help="指定或加载一个已有会话"),
    temperature: float = typer.Option(0.8, help="生成文本的随机性，0-1"),
):
    """进入与GLM-5的交互式对话。"""
    # 1. 初始化或加载会话
    if session_name:
        messages = session_manager.load_session(session_name)
        typer.echo(f"已加载会话: {session_name}")
    else:
        messages = []
        session_name = session_manager.create_new_session()
        typer.echo(f"新会话已创建: {session_name}")

    typer.echo("开始对话吧！输入 '/exit' 退出， '/save' 保存， '/help' 查看帮助。")

    # 2. 主聊天循环
    while True:
        try:
            user_input = typer.prompt("\n[你]")
        except EOFError: # 处理Ctrl+D
            typer.echo("\n检测到输入结束，退出。")
            break

        # 3. 处理内置命令
        if user_input.strip() == '/exit':
            if typer.confirm("是否保存当前会话？"):
                session_manager.save_session(session_name, messages)
            break
        elif user_input.strip() == '/save':
            session_manager.save_session(session_name, messages)
            typer.echo("会话已保存。")
            continue
        elif user_input.strip() == '/help':
            typer.echo(HELP_TEXT)
            continue

        # 4. 将用户输入加入消息历史
        messages.append({"role": "user", "content": user_input})
        print_user(user_input) # 美化打印用户输入

        # 5. 调用API并流式打印
        typer.echo("[GLM-5]: ", nl=False) # nl=False表示不换行
        full_response = ""
        try:
            async for chunk in client.chat_completion_stream(messages, temperature=temperature):
                typer.echo(chunk, nl=False) # 流式打印每个chunk
                full_response += chunk
            typer.echo() # 最后换行
        except KeyboardInterrupt:
            typer.echo("\n\n生成被中断。")
            # 可以选择是否将不完整的回复加入历史，通常不建议
            continue

        # 6. 将AI回复加入消息历史
        if full_response:
            messages.append({"role": "assistant", "content": full_response})

实操心得与注意事项 ：

1. 输入处理 ：使用 typer.prompt 可以方便地获取用户输入，并支持历史记录（如果系统支持）。一定要捕获 EOFError （Ctrl+D）和 KeyboardInterrupt （Ctrl+C），为用户提供优雅的退出方式。
2. 内置命令 ：像 /exit ， /save ， /help 这样的命令极大提升了工具的可用性。实现时，需要在将输入发送给AI之前进行拦截和判断。
3. 会话管理 ： session_manager 负责将会话ID和对应的消息列表 messages 持久化到SQLite。每次循环后，理论上都应该保存，但为了性能，可以在退出时或用户显式调用 /save 时保存。 注意 ：GLM-5有上下文长度限制， SessionManager 还需要实现一个“裁剪”策略，当历史消息总token数接近限制时，自动移除最早的一些对话轮次，但尽量保留系统提示词和最近的对话。
4. 流式打印的美化 ： print_assistant 和 print_user 函数可以使用 typer.style 或 rich 库来为不同角色的输出上色，使其一目了然。流式打印时，确保光标行为正确，避免换行混乱。

3.3 配置与安全最佳实践

安全是命令行工具，尤其是涉及API密钥的工具的重中之重。

1. 环境变量与配置文件 ： 永远不要将API密钥写入代码。使用 .env 文件，并通过 python-dotenv 加载。同时，提供一个 .env.example 文件，指导用户如何配置。

# core/config.py
from pydantic_settings import BaseSettings
from pydantic import Field

class Settings(BaseSettings):
    ZHIPU_API_KEY: str = Field(..., min_length=1, description="智谱AI平台的API密钥")
    MODEL: str = "glm-5" # 默认模型
    REQUEST_TIMEOUT: int = 30
    HTTP_PROXY: str | None = None # 可选代理

    class Config:
        env_file = ".env"
        env_file_encoding = "utf-8"

settings = Settings() # 全局配置对象

注意 ： pydantic 的 Field(..., min_length=1) 中的 ... 表示该字段是必需的。如果 .env 文件中没有 ZHIPU_API_KEY ，程序启动时会抛出清晰的验证错误。

2. 密钥的输入与存储 ： 对于首次使用的用户，如果他们没有设置环境变量，我们可以提供一个友好的引导命令，比如 glm setup ，通过 typer.prompt 交互式地询问API Key，并指导他们如何安全地保存到 .env 文件。

@app.command()
def setup():
    """交互式配置GLM CLI工具。"""
    api_key = typer.prompt("请输入您的智谱AI API Key", hide_input=True)
    # 这里可以进行简单的格式校验
    # 然后指导用户写入.env文件，注意提醒不要提交到版本控制
    typer.echo(f"请将以下内容添加到项目根目录的 .env 文件中：")
    typer.echo(f"ZHIPU_API_KEY={api_key}")
    typer.echo("\n⚠️  重要：请确保 .env 文件已被添加到 .gitignore 中，避免密钥泄露！")

3. 网络代理支持 ： 很多国内开发者在访问外部API时需要配置代理。我们的客户端应该支持通过环境变量 HTTP_PROXY / HTTPS_PROXY 或命令行参数来设置代理。 httpx 和 requests 库通常会自动读取这些环境变量，但为了更可控，可以在初始化客户端时显式传入代理配置。

4. 进阶功能与体验打磨

基础功能跑通后，我们可以添加一些“甜点”功能，让这个工具从“能用”变得“好用”。

4.1 文件作为上下文与代码生成

这是提升开发效率的杀手锏。允许用户将本地文件内容发送给AI进行分析或修改。

@app.command()
def explain(
    file_path: str = typer.Argument(..., help="需要解释的代码文件路径"),
):
    """让GLM-5解释指定代码文件的功能。"""
    if not os.path.exists(file_path):
        typer.echo(f"错误：文件 '{file_path}' 不存在。")
        raise typer.Exit(code=1)

    try:
        with open(file_path, 'r', encoding='utf-8') as f:
            code_content = f.read()
    except Exception as e:
        typer.echo(f"读取文件失败: {e}")
        raise typer.Exit(code=1)

    # 构建一个包含文件内容的提示词
    prompt = f"""请分析以下代码文件（路径：{file_path}）：

{code_content}

请用简洁的语言说明这个文件的主要功能、核心函数或类的作用，以及可能的依赖关系。"""
    # 然后调用单次问答的接口，将prompt发送出去

对于代码生成，可以更智能一些：

@app.command()
def gen(
    output: str = typer.Option(..., "-o", "--output", help="生成的代码输出文件路径"),
    instruction: str = typer.Argument(..., help="代码生成指令"),
    overwrite: bool = typer.Option(False, "--force", "-f", help="强制覆盖已存在文件"),
):
    """根据指令生成代码并保存到文件。"""
    if os.path.exists(output) and not overwrite:
        typer.echo(f"错误：文件 '{output}' 已存在。使用 --force 参数覆盖。")
        raise typer.Exit(code=1)

    # 调用API生成代码
    full_response = client.ask_once(instruction)
    # 尝试从响应中提取代码块（如果AI用```包裹）
    code_to_write = extract_code_block(full_response) or full_response

    try:
        with open(output, 'w', encoding='utf-8') as f:
            f.write(code_to_write)
        typer.echo(f"代码已成功生成并保存至: {output}")
    except Exception as e:
        typer.echo(f"写入文件失败: {e}")

4.2 流式输出的极致优化

原生的 typer.echo 逐字打印在慢速网络下可能显得卡顿。我们可以引入 rich 库来创建一个更优雅的“Live Display”，或者实现一个简单的缓冲区，积累少量字符再打印，使输出更平滑。同时，为代码块自动检测语言并进行高亮。

# utils/printer.py 简化示例
from rich.console import Console
from rich.syntax import Syntax
import re

console = Console()

def stream_print_rich(text: str, language: str = None):
    """使用rich进行智能打印。"""
    # 如果是代码块，尝试高亮
    if language and code_block_pattern.match(text):
        syntax = Syntax(text, language, theme="monokai", line_numbers=False)
        console.print(syntax)
    else:
        console.print(text, end="", highlight=False)

# 在主循环中，可以积累一定字符或按行处理，而不是每个chunk都print，减少刷新次数。

4.3 会话的智能管理

除了基本的保存/加载，可以实现更强大的会话管理：

• 会话列表与搜索 ： glm session list 列出所有历史会话，显示时间、标题（可自动从首条消息生成）和消息数量。
• 会话归档与删除 ： glm session delete <id> 。
• 上下文摘要 ：对于非常长的会话，可以在保存时自动生成一个摘要（可以调用AI的摘要功能），方便日后回顾。
• 多模型支持 ：虽然项目聚焦GLM-5，但架构可以设计成支持多个后端模型（如DeepSeek、Claude等），通过配置切换。这需要定义一个统一的客户端接口。

5. 打包、分发与持续集成

要让其他人方便地使用你的工具，打包和分发是关键一步。

1. 使用 setuptools 或 poetry 打包 ： 创建 setup.py 或 pyproject.toml ，定义包名、版本、依赖、入口点等。

# setup.py 示例
from setuptools import setup, find_packages

setup(
    name="glm-cli-tool",
    version="0.1.0",
    packages=find_packages(),
    install_requires=[
        "typer>=0.9.0",
        "zhipuai", # 智谱官方SDK
        "httpx",
        "pydantic>=2.0",
        "python-dotenv",
        "rich", # 可选，用于美化输出
        "sqlalchemy>=2.0", # 可选，如果用ORM管理数据库
    ],
    entry_points={
        "console_scripts": [
            "glm=glm_cli.main:app", # 这行是关键！将 `glm` 命令映射到你的Typer app
        ],
    },
)

安装后，用户就可以直接在终端使用 glm 命令了。

2. 发布到 PyPI ： 使用 twine 工具可以将包上传到PyPI，这样用户就可以通过 pip install glm-cli-tool 全球安装。

3. 编写完善的文档 ： 一个清晰的 README.md 至关重要，应包含：特性介绍、快速安装指南、API密钥获取方式、基础使用示例、所有命令的详细说明、配置项解释以及常见问题。

4. 实现持续集成 ： 使用GitHub Actions等工具，在代码推送时自动运行测试、代码风格检查（black, isort, flake8）和打包测试，确保代码质量。

6. 常见问题与排查实录

在开发和测试过程中，你肯定会遇到各种问题。这里记录一些典型场景和解决方案。

问题1：流式输出时，内容堆积在一起不换行，或者出现乱码。

• 原因 ：终端缓冲区和字符编码问题。AI返回的文本可能包含控制字符或与终端不兼容的编码。
• 解决 ：
  1. 确保在打印时使用正确的编码（通常是 utf-8 ）。在Python中打开文件或处理字符串时明确指定。
  2. 对于流式打印，强制刷新输出缓冲区。 typer.echo(text, nl=False) 后，有时需要调用 sys.stdout.flush() 。但 typer / click 通常已处理。
  3. 最稳妥的方法是使用 rich.console.Console 进行输出，它更好地处理了终端兼容性。
  4. 乱码有时是因为AI返回了Markdown格式或其他特殊字符。可以尝试在打印前进行简单的过滤或转换。

问题2：API调用经常超时或失败。

• 原因 ：网络不稳定，或智谱服务器端负载高。
• 解决 ：
  1. 增加超时时间 ：在客户端初始化时，设置合理的 timeout 参数（如30秒或更长）。
  2. 实现重试机制 ：对于网络错误（如 ConnectTimeout , ReadTimeout ）或服务器5xx错误，可以实现一个带有指数退避的简单重试逻辑。

     import time
     from httpx import ConnectTimeout, ReadTimeout
     
     async def chat_with_retry(messages, max_retries=3):
         for attempt in range(max_retries):
             try:
                 return await client.chat_completion_stream(messages)
             except (ConnectTimeout, ReadTimeout) as e:
                 if attempt == max_retries - 1:
                     raise
                 wait_time = 2 ** attempt # 指数退避
                 print(f"请求超时，{wait_time}秒后重试 ({attempt+1}/{max_retries})...")
                 time.sleep(wait_time)
     

  3. 检查代理配置 ：如果身处特殊网络环境，确保 HTTP_PROXY 环境变量设置正确且代理服务可用。

问题3：历史会话越来越长，导致后续API调用速度变慢甚至因超出token限制而失败。

• 原因 ：GLM-5有上下文窗口限制（例如128K tokens）。无限累积历史消息最终会超限。
• 解决 ：实现一个 上下文窗口管理策略 。
  1. 统计Token ：在每次保存消息时，估算该消息的token数（可以使用 tiktoken 类似的库，或智谱可能提供的token计算工具）。维护当前会话的总token数。
  2. 裁剪策略 ：当总token数接近限制（如达到90%）时，触发裁剪。一个简单的策略是移除最早的一对 user 和 assistant 消息，直到总token数低于安全阈值。更复杂的策略可以尝试总结早期对话内容后再移除。
  3. 系统提示词 ：将最重要的指令放在 system 角色的消息中，并确保它在裁剪时被保留。

问题4：生成的代码或建议不完全符合预期。

• 原因 ：大模型具有随机性，且提示词（Prompt）的质量直接影响输出结果。
• 解决 ：
  1. 优化提示词 ：这是最重要的技巧。在提问时，要 具体、清晰、提供上下文 。例如，不要问“怎么写一个排序函数？”，而要问“用Python写一个快速排序函数，要求处理整数列表，包含详细的注释，并提供一个使用示例。”
  2. 调整参数 ：通过CLI参数暴露 temperature 和 top_p 。对于需要确定性输出的代码生成，可以尝试较低的 temperature （如0.2）。对于需要创意的头脑风暴，可以调高（如0.9）。
  3. 迭代式交互 ：不要期望一次得到完美答案。使用 chat 模式，根据AI的回复进行追问、修正或要求它换一种方式实现。CLI工具的优势就在于支持这种快速迭代。

问题5：在Windows系统上，Ctrl+C中断后程序没有完全退出，或者颜色显示异常。

• 原因 ：Windows终端对信号和ANSI转义码（用于颜色）的支持与Unix系统（Linux/macOS）有差异。
• 解决 ：
  1. 信号处理 ：确保正确捕获 KeyboardInterrupt 异常，并在退出前执行必要的清理工作（如关闭数据库连接、保存会话）。
  2. 颜色支持 ：使用像 rich 或 colorama 这样的库，它们能自动检测终端并适配Windows的颜色输出。避免直接使用ANSI转义码。
  3. 测试 ：务必在目标平台（Windows, macOS, Linux）上进行测试，特别是交互式和流式输出部分。

构建一个成熟的CLI工具是一个持续迭代的过程。从最核心的“问答”功能开始，逐步添加会话管理、文件操作、配置优化和错误处理。每一次迭代都让工具更贴合实际工作流。最重要的是，你自己要高频使用它，在真实场景中感受它的不足，这才是驱动它变得更好的根本动力。当你发现自己越来越离不开这个终端里的智能伙伴时，这个项目就真正成功了。