引言

承接上一篇模型选型的内容，在确定好使用云模型还是本地模型之后，接下来就要确定 AI 问答助手的交互形式。交互界面是用户与系统直接接触的部分，它不仅决定了使用体验，也会影响开发复杂度、部署方式和适用场景。

目前最常用、最适合入门的两种形式就是CLI与Web，这一篇我们就从实际开发角度，对比两者的差异、适用场景，帮你快速做出选择。

为什么

对于 AI 问答助手而言，模型负责 “思考”，RAG 负责 “查资料”，而交互界面则负责 “收发信息”。一个简洁、合适的交互形式，可以让整个项目更完整、更易用；反之，过于复杂的界面则会增加开发成本，甚至喧宾夺主。

尤其在项目初期，交互界面的核心目标是验证流程、快速可用，而不是追求华丽的视觉效果。选择 CLI 还是 Web，直接决定了你接下来写代码的重心和工作量。

是什么

CLI 交互

CLI，即命令行界面，是通过终端输入指令、进行问答的形式，没有图形界面，纯文本交互。

优点

（1）极快开发（最重要）

没有前端、没有页面、没有交互复杂性，只需要写main.py就能运行。

（2）专注核心逻辑

只需要关心：RAG流程、LLM调用、数据处理，非常适合学习AI工程本质。

（3）调试极其方便

无论是打印日志，还是断点调试看中间结果，亦或是进行快速修改，都可以很快完成，对新手非常友好。

（4）资源占用低

既不需要浏览器，也不需要服务器，常用的代码编辑器就可以。

缺点

（1）不适合普通用户

用户需要会CLI命令，才能进行交互，非技术人员直接劝退。

（2）交互体验差

既没有聊天界面，也没有历史记录，对大多数用户来说不直观。

Web交互

优点

（1）用户体验好（核心）

像大家常用的豆包、Deepseek一样：有输入框，是对话流，用户通过按钮操作，非技术用户也能用。

（2）更接近真实产品

如果以后要面试、做项目展示、做副业产品，那么做Web 就是必须的。

（3）支持更多功能

比如：多轮对话、文件上传、用户系统。

缺点

（1）开发复杂度高

总共需要开发的内容多： 前端（HTML / JS）、 后端（API）、通信（HTTP）

（2）调试更麻烦

自己测试过程中出现问题，可能是前端的问题，也可能是后端的问题，也有可能是网络的问题。

（3）开发时间长

实现同样一个AI功能：CLI只需要1天，Web需要3~7天。

有什么区别

本质区别（工程视角）

（1）系统结构差异

Web比CLI多了前端、网络通信这两层。

CLI交互

用户输入
  ↓
Python程序
  ↓
LLM
  ↓
输出

Web交互

浏览器
  ↓
前端（页面）
  ↓
后端API（FastAPI）
  ↓
LLM
  ↓
返回前端

（2）关注点不同

类型	关注重点
CLI	功能实现
Web	用户体验

（3）使用对象不同

类型	用户
CLI	开发者
Web	普通用户

怎么选

学习路径选择

第一阶段：CLI

学习的第一目标是搞懂本质，不需要那么多功能，只要能跑通，搞明白RAG流程、向量检索和Prompt构造。

第二阶段：Web

第二目标是做成产品，这个阶段再去做页面、API和用户体验。

很多新手会踩的坑

一上来就做Web

结果：前端不会写，后端写的很混乱，最后AI逻辑也没搞懂，自然最后项目也就做失败了。
当然还有一种可能是一开始想象理解的AI交互项目就是需要Web交互的，会感觉很复杂很难做，先被自己劝退了。

正确方式

先实现CLI版本，把项目的核心跑通，再来给它“套一层Web壳”。

彩蛋——如何切换

事实上，很多成熟项目都是：先 CLI（验证核心） → 再 Web（产品化）

结论

CLI 和 Web 本质上只是“外壳不同”，核心逻辑（RAG + LLM）是完全可以复用的。

为什么可以互相转换？

因为一个AI问答系统，其实可以拆成两层：

核心层（不变的）

这一层是真正写的“AI能力”：

def ask(question):
    docs = vector_db.search(question)
    prompt = build_prompt(question, docs)
    answer = llm(prompt)
    return answer

这部分CLI 用，Web 也用。

交互层（可替换）

只是“输入方式”和“输出方式”变了：
CLI：

question = input("请输入问题：")
print(ask(question))

Web：

@app.post("/ask")
def ask_api(question):
    return ask(question)

工程结构怎么设计才能“可转换”（重点）

如果一开始乱写，是很难改的，正确结构应该是这样：

推荐项目结构

project/
│
├── core/               # 核心逻辑（最重要）
│   ├── rag.py         # RAG流程
│   ├── llm.py         # LLM调用
│   └── vector_db.py   # 向量检索
│
├── cli/               # CLI入口
│   └── main.py
│
├── web/               # Web入口
│   └── app.py
│
└── data/              # 文档数据

核心原则：核心逻辑绝对不能写在 CLI 或 Web 里！

从CLI → Web 的转换步骤（实战路径）

假设你已经有CLI版本：

1、抽离核心逻辑

把原来写在 main.py 里的代码拆出来：

# core/rag.py
def ask(question):
    ...
    return answer

2、保留CLI（可选）

# cli/main.py
from core.rag import ask

while True:
    q = input("问题：")
    print(ask(q))

3、加一个Web接口

用 FastAPI添加Web接口：

# web/app.py
from fastapi import FastAPI
from core.rag import ask

app = FastAPI()

@app.get("/ask")
def ask_api(q: str):
    return {"answer": ask(q)}

4、运行

在代码编辑器的命令行工具输入以下命令：

uvicorn app:app --reload

浏览器访问：

http://localhost:8000/ask?q=Java是什么

以上就完成了—— CLI → Web 的升级。

再进一步：Web前端（可选）

还可以再加HTML页面、聊天界面，甚至用Streamlit（最简单）、React（更专业）。

什么时候“不能轻松转换”？（坑点）

情况1：代码写死在CLI里

比如：实现CLI版本时，把input() 直接嵌在逻辑里，导致改成Web版本无法复用。

情况2：没有模块化

所有代码都写在一个文件里，改起来会很痛苦。

情况3：强耦合

比如：把检索 + 输出 + UI 混在一起

一个非常重要的工程思想

UI 是“壳”，AI 是“核”

下一步

【人工智能】《从零搭建AI问答助手项目（四）：API调用实战》