从零开始AI应用开发：API调用、多轮对话与Streamlit实践

1. 第一天先不写代码把AI应用开发的地图铺开我给自己定的目标是用一个月时间从只会调接口的状态成长到能独立完成一个AI应用的小项目。今天是第一天但我做的第一件事并不是打开编辑器写代码而是先把“AI应用开发”这六个字拆开搞清楚它到底包含哪些东西。如果你也刚接触这个领域第一天最容易被网上铺天盖地的名词砸晕大模型、Agent、RAG、微调、提示词工程、AI Native……每一个词看起来都懂合在一起就不知道从哪下手。我今天的经验是不要急着追概念先画一张地图知道自己站在哪里终点在哪里中间有哪些里程碑。所谓AI应用开发本质上就是“利用大模型的通用能力解决某个具体场景的问题”。你的产品可以是一个聊天机器人可以是一个文档总结工具也可以是一个能调用外部工具的Agent。但不管形态是什么底层的逻辑都是输入一段文本或其他模态模型根据其训练得到的知识生成一段输出。而你作为开发者真正的价值在于设计好输入提示词怎么写上下文怎么组织数据怎么预处理。设计好输出如何让模型输出符合你的格式要求如何解析和校验结果。设计好流程一次调用不够怎么办需要多轮对话、检索增强、外部工具调用怎么办。设计好体验响应速度、成本、错误处理、并发。这一天的学习我建议你把这几个维度记下来后面所有的知识都是围绕它们展开的。不要一上来就去看Transformer论文也不要一上来就琢磨怎么微调模型——对应用开发来说你90%的时间是在和API打交道不是和模型权重打交道。2. 环境准备一台电脑一个API Key是启动一切的最小前提我列了一个清单第一天必须把这些准备好否则后面的代码寸步难行。2.1 硬件和软件到底要什么配置先说硬件如果你的开发方式主要靠调用云端API那么CPU、内存、显卡基本不是瓶颈。我的笔记本是几年前的i5处理器16GB内存跑Python、发HTTP请求完全够用。只有当你需要本地跑模型比如7B/13B的量化模型或者微调训练时才需要考虑显卡。显然第一天不需要。软件环境其实也很简单Python 3.10以上版本推荐直接用Anaconda或者Miniconda管理环境避免把系统Python搞乱。一个IDE我用的是VS Code装上Python插件和Jupyter插件就够了。一个终端Windows上PowerShell或CMD都行我习惯用Git Bash。2.2 选择哪家大模型API现在的选择很多OpenAI、Anthropic、Google、智谱、通义、文心、DeepSeek等都有对话模型的API。作为国内开发者我建议你根据实际情况决定。第一天主要学习调用逻辑建议选一家接口规范相对通用、文档清晰的。比如很多厂商的接口都兼容OpenAI格式这意味着你学会一家换另一家时只需要修改base_url和api_key其他代码几乎不用动。我用的是智谱AI的GLM系列原因有三一是国内直连访问方便不需要考虑网络问题二是它有免费额度适合新手试用三是它的API格式和OpenAI高度兼容后面的示例可以直接复用。你也可以用通义千问、文心一言、DeepSeek选你顺手的那一家。注册账号后进入控制台创建一个API Key。注意Key的创建过程一般需要实名认证这是正常流程。拿到一串类似sk-xxxxx的字符串后先复制保存到一个本地文件里但绝对不要提交到Git仓库。2.3 管理API Key和费用这里有一个新手特别容易踩的坑把API Key写死在代码里然后不小心把代码传到了公开仓库。轻则Key被盗用造成费用损失重则可能因为滥用被封号。第一天我强烈建议你养成两个习惯使用环境变量或.env文件存储Key并通过python-dotenv加载。在gitignore中忽略.env文件提交代码前确认没有Key泄露。费用方面大部分厂商按token计费输入和输出价格不同。第一天你只需要关心一件事跑通一个demo花不了多少钱几十次调用可能也就是几毛钱。但如果你在循环里不断请求或者被狂刷接口一天烧掉几百块也是可能的。后面我会专门写怎么控制成本。2.4 开发语言选Python的理由做AI应用开发Python几乎是默认选择。原因很简单生态太成熟了。不管是OpenAI的官方SDK、各种大模型的Python库还是后面的Streamlit、LangChain、Dify这些工具对Python的支持都是最优先的。即便你以后用TypeScript或Go写生产级服务学习阶段用Python理解概念也是最顺的。3. 第一个程序别搞复杂用50行代码让大模型开始干活今天下午我做了一个很小的程序在终端里输入一句话大模型给我一个回复。就这么个东西代码不到50行但跑通的那一刻对整个流程的理解完全不一样了。3.1 最简调用requests硬怼我不建议第一天直接用官方的SDK先自己用requests写一遍你会更深刻地理解HTTP请求和响应的结构。下面是核心代码import requests import json import os from dotenv import load_dotenv load_dotenv() api_key os.getenv(ZHIPU_API_KEY) url https://open.bigmodel.cn/api/paas/v4/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } def chat(question): payload { model: glm-4-flash, messages: [ {role: user, content: question} ], temperature: 0.7 } resp requests.post(url, headersheaders, jsonpayload, timeout30) data resp.json() return data[choices][0][message][content] if __name__ __main__: while True: q input(你: ) if q.strip().lower() in [quit, exit]: break print(AI:, chat(q))这段代码做的事情非常直白把用户输入放到messages数组里发送POST请求从响应里取choices[0].message.content。跑通之后你会看到终端里出现一个最原始的聊天机器人。细心的读者会发现这里并没有把之前的历史对话传回去。也就是说你问“我叫小王”下一句问“我叫什么”它是不知道的。这就是最简单的无状态调用。3.2 提示词不是玄学是格式化输入同样一个模型你问“写一段产品介绍”和“你是一名有十年经验的营销文案专家请用三句话为XX产品写一段用于朋友圈的营销文案要求突出XX卖点语气活泼”得到的结果质量天差地别。第一天我不建议深挖提示词技巧但你要建立一个意识模型是一个“凭信息补全”的工具你给的信息越明确它补全的质量越高。我习惯把提示词拆成几个部分角色设定给模型一个身份让它知道用什么口径回答。任务描述说清楚要做什么输出什么格式。上下文必要的背景信息或示例。约束条件字数、语气、不能出现什么。这样设计提示词的好处是后期你可以把不同部分做成模板变量通过程序动态填充。3.3 理解token和参数当你调用API时返回结果里除了回复内容还有一个usage字段里面写着prompt_tokens、completion_tokens和total_tokens。Token可以粗略理解成“片段”——英文里一个token大致是半个词到几个字符中文可能是半个到一两字。你会发现同样的中文句子不同模型分词方式不同token数也不一样。费用就是根据这个算的。temperature参数控制着回复的随机性值越大最高2输出越发散越小最低0输出越发确定。如果你在做抽取、总结这类任务可以设成0.3左右如果是创意写作可以设成0.8以上。第一次先不用纠结知道有这回事就行。4. 让对话有记忆手动维护messages列表是入门必修课跑完无状态版第二个自然的需求就是让它记住我们聊过什么。这一步理解透了后面学LangChain的ConversationBufferMemory、Agent的对话管理时就会轻松很多。4.1 原理API本无记忆记忆靠你搬运大模型的API本身不保存你的会话状态。每一次请求都是独立的服务器端不会记得你上一次说了什么。要实现多轮对话必须由客户端把之前的对话历史打包进messages数组。例如messages [ {role: system, content: 你是小助手回答简洁有力。}, {role: user, content: 我想学AI开发第一步该做什么}, {role: assistant, content: 先准备环境和API Key跑通一个最简单调用。}, {role: user, content: 那环境怎么准备} ]把整个数组发给模型它才能“理解”当前这句话是基于前面的上下文的。所以多轮对话逻辑本质上就是不断把用户输入和模型输出追加到这个数组里然后整体发给服务端。4.2 代码升级加一个history列表在上面的代码上稍作修改history [] def chat_with_context(question): history.append({role: user, content: question}) payload { model: glm-4-flash, messages: history, temperature: 0.7 } resp requests.post(url, headersheaders, jsonpayload, timeout30) data resp.json() answer data[choices][0][message][content] history.append({role: assistant, content: answer}) return answer就这么简单。但很快你会发现history数组无限增长每次请求的token数越来越大响应越来越慢费用越来越高。这时候就需要考虑“截断”或“摘要”。4.3 上下文窗口的硬限制和软处理每个模型都有一个最大上下文长度比如4K、8K、32K、128K tokens。如果你塞进去的历史超过这个限制要么报错要么需要自己截断。常见的做法有三种固定窗口只保留最近N轮对话。比如只取最后10轮丢弃更早的。摘要压缩每过几轮让模型把之前的对话总结成一段摘要然后用摘要代替完整的原始记录。向量检索把历史消息存入向量数据库需要时检索相关片段这就是RAG的雏形。今天我不建议直接上RAG但你要知道有这些方向。至少你得学会如何把messages数组控制在合理长度否则第二轮迭代就会碰到“历史越长越贵”的现实。4.4 用Streamlit做一个能交互的网页聊天框如果你不想一直在终端里玩可以用Streamlit快速做一个网页界面。它是一个Python库写起来像写普通脚本自动生成前端。pip install streamlit然后新建一个app.py写一个最基础的聊天界面import streamlit as st st.title(AI Demo) if messages not in st.session_state: st.session_state.messages [ {role: system, content: 你是小助手。} ] def get_ai_reply(messages): # 复用之前的requests调用这里省略头部和URL # 你需要把messages传入payload pass for msg in st.session_state.messages[1:]: st.chat_message(msg[role]).write(msg[content]) if prompt : st.chat_input(说点什么): st.session_state.messages.append({role: user, content: prompt}) st.chat_message(user).write(prompt) reply get_ai_reply(st.session_state.messages) st.session_state.messages.append({role: assistant, content: reply}) st.chat_message(assistant).write(reply)运行streamlit run app.py浏览器就会弹出聊天界面。注意st.session_state是Streamlit保存状态的机制否则每次交互时变量会被重新初始化。我第一天就忘了这个导致聊一句忘一句花了十分钟才反应过来。5. 今天实测中遇到的三个坑从Key泄露到JSON解析一天下来踩的坑比学的新概念还多。我挑了三个值得记录的希望你能避开。5.1 史上最冤把API Key写进README我一开始图省事直接在脚本里硬编码了Key想着“反正本地跑”。后来想用Git管理代码顺手写了一个README里面粘贴了测试输出而输出里居然把完整的请求头打出来了——Key就赫然在列。还好我眼疾手快没push上去及时把Key删掉重新生成了一个。这里要记住字符串格式化时别把headers或完整响应打印到日志里。如果你需要调试用脱敏函数把Key中间部分替换成星号比如sk-****abcd。5.2 模型返回的JSON不一定能直接解析很多应用需要模型输出结构化数据比如一个包含“标题”“要点”“下一篇建议”的JSON。第一天我让模型生成JSON然后直接json.loads(content)结果报错。原因是模型经常在JSON前后加一些解释文字比如“好的以下是您需要的JSON”或者把{写成了。解决方案很简单在提示词里强调“只输出JSON不要输出任何其他文字”。用正则提取第一个{到最后一个}之间的内容再解析。更稳妥的是用响应解析功能——很多SDK支持定义返回格式让模型用结构化输出这比纯字符串正则靠谱。但我要提醒你即便用结构化输出也不是100%稳定生产环境一定要加校验和重试逻辑。5.3 网络超时不设置timeout就是在赌运气我第一次写requests.post时没加timeout参数本地网络稍一抖动程序就卡住不动了。后来加了timeout30但遇到问题依然是直接抛异常导致整个脚本退出。对大模型应用来说响应时间本来就不稳定生成一段长文本可能要十几秒甚至更久所以超时策略要合理设计。我现在的做法是设置一个较大的超时时间比如30秒或60秒。使用重试机制比如请求失败后delay几秒重试一次最多三次。每次请求只做一件事不要太长的对话回合循环避免单次任务超时。第一天不需要用到多复杂你只要明白“不加超时会让程序卡死加了超时又不处理异常会让程序崩溃所以要用try-except包住请求”这个逻辑。6. 第一天收尾的体会和下一步方向晚上复盘我觉得第一天最有价值的产出不是那段能聊天的代码而是对“token往返”这个底层过程有了体感。当你能亲眼看到一次请求的payload有多大、返回的token数有多少、费用涨了多少时你自然就会思考怎么让提示词更精简怎么缓存重复结果怎么控制用户输入长度这些不是靠读文档学会的是靠跑demo跑出来的。另外我建议每个初学者都准备一个实验手册专门记录“我改了哪个参数输出发生了什么变化”。比如把temperature从0.7改成1.2对比一下回复的差异把system提示词从“你是助手”改成“你是专家”看看回答风格的改变。这些都是第一手经验比看十篇教程都管用。明天我计划做两件事一是把接到的回复改用流式输出——现在每次都要干等好几秒体验太差二是试着让模型调用一个外部工具比如让它根据用户指令查询天气接口。这一步迈出去就触及了Agent的边界。如果你也是刚入门记住第一天不需要学完所有东西把最小闭环跑通——API调用、消息传递、历史管理、异常处理——这四件事吃透你就已经踩在门槛上了。剩下的交给后面的日子慢慢来比较快。