前一天我还在网页版聊天窗口里调教AI第二天就发觉自己不能再停在“使用者”这层了。正好手头有个小项目要用到AI能力我决定把AI应用开发的学习进度直接往前推一推。这篇day02学习记录写的是我如何从只会聊天到用代码调用大模型API、做出可交互的问答页面再在低代码平台上搭出智能体的完整过程。适合刚接触AI应用开发、有Python基础但还没写过AI项目的人参考也欢迎已经入门的同学来挑挑毛病看看我的学习路径是不是够高效。1. 第二天为什么从“聊天”切到“写代码”先定目标再动手第一天其实是挺舒服的打开几个模型平台挨个试不同模型的效果反复改提示词看模型怎么回话。舒服归舒服到了晚上我意识到一个问题——这种玩法和普通用户聊天没什么区别换个人来也一样。AI应用开发的真正门槛不在“让模型回答得好”而在“怎么把模型能力接进自己的产品和业务流程里”。所以第二天早上我先做了一件事把学习目标收敛成可验收的三条。用代码直接调用一次大模型API搞懂请求和返回的基本结构做一个能输入问题、拿到答案的Web页面而不是只在终端打印结果动手搭一个面向具体场景的智能体验证Agent到底是怎么被“编排”出来的。这样定完目标整个下午和晚上的学习就有了主线。我不打算照着几十个小时的课程慢慢刷更想先把一条最短路径走通遇到不懂的再沿路补。事实证明这个决策对想快速入门的开发者来说非常划算。很多东西你光看书是记不住的在报错和调试中撞一遍比背十遍文档都管用。1.1 学习地图从LLM调用到业务逻辑串联动手之前我先花二十分钟梳理了整个AI应用开发的常见分层。大概可以分成三层模型层大语言模型本身比如GPT、DeepSeek、文心、通义负责生成文字应用层写Prompt、做接口调用、处理上下文、接业务逻辑这部分是开发者主要发力点产品层把能力封装成API、网页、机器人、工作流让用户真正能用起来。第一天我主要在模型层玩第二天开始往下钻应用层和产品层。这正好对应热搜里常看到的“大模型应用开发”和“Agent应用开发学习路线”。我学到的一个关键认知是别把模型当成一个完整产品模型只是发动机真正值钱的是你围绕它做的逻辑、数据和交互设计。1.2 第二天先选一条最短路径技术选型上我没有去碰那些重框架只选了三个东西Python作为编程语言DeepSeek的模型API作为能力来源Streamlit用来快速做网页界面。这算是当前入门AI应用开发比较短的一条路——Python生态成熟DeepSeek的API参考OpenAI格式文档清晰Streamlit可以让我少写一大堆前端代码十分钟内看到一个能交互的页面。选Python不是因为它多高级而是因为AI领域的SDK和示例基本都先支持Python。选Streamlit不是因为它能撑起生产级应用而是因为对新手理解“请求-响应-渲染”最直观。我给自己定的原则是第二轮学习再考虑Spring AI做Java侧集成、FastAPI做高并发接口第一天先把核心链路弄通。2. 大模型应用的核心概念模型、上下文、提示词、工具如果你直接上手API很快会发现一个事实大模型就是一个“输入文字、输出文字”的函数。它可以看起来像会思考但它不保存你的聊天记录也不主动去查任何数据库更不会自己决定调用某个外部系统。要让它真正干活得靠开发者去搭桥。我习惯用一个餐厅比喻来理解这件事大模型像一位经验丰富的厨师你的提示词就是客人点的菜上下文是厨师眼前操作台上的全部食材而工具调用则是厨师喊帮厨去买菜、开火、装盘。厨师水平再高食材不够或者没人配合也办不成宴席。这个比喻帮我分清了模型、提示词、上下文和工具各自的职责后续调代码时心里特别有底。2.1 模型API调用方式为什么大多都兼容OpenAI格式几乎所有主流大模型开放平台都提供HTTP接口而且多数兼容OpenAI的Chat Completions风格。所谓“兼容”意味着我只需要知道一个固定的请求结构一个messages数组里面按顺序放着system系统设定、user用户输入、assistant模型回复等角色消息一个model参数指定用哪个模型可选参数比如temperature、max_tokens等控制生成风格和长度。这样的设计对开发者非常重要。你学会一种调用方式迁移到另一个模型平台时只需要改一下base_url、api_key和model名字代码结构几乎不动。这也是为什么第二天我只用了一个openai库就接上了DeepSeek后面如果想接其他模型几乎零成本。2.2 System Prompt、温度与上下文调优先于改代码我第一次调用API时非常天真以为把问题丢给模型就行。后来发现真正好用的AI应用几乎都会在请求前塞一段system prompt。它就是给模型的“岗位说明书”规定身份、目标、边界、输出格式。举个例子同样是“帮我写一份周报”没有system prompt时模型可能写得很宽泛加了system prompt之后它会站在某个具体岗位角度按你要求的格式产出内容。调system prompt永远比改业务代码更快地提升体验。还有一个被忽视的参数是temperature。它控制回答的随机性值越低越保守越高越发散。做知识问答、客服这种追求稳定输出的场景我习惯把温度调到0.2到0.4做创意文案、头脑风暴可以调到0.8以上。这些参数虽小却是从“能回答”到“答得好”的分水岭。上下文则更实在。API是一次性调用每个请求都携带全部聊天记录和当前输入。上下文长度等于你每次请求消耗的token总量。如果不做控制多轮对话很容易因为token超限报错或者花费激增。这块我后面专门有一节踩坑复盘。2.3 Agent的最小理解模型负责想代码负责做第二天我一直被“AI Agent”这个词包围热搜里满屏都是Agent开发。我自己的最小理解是纯问答不叫AgentAgent至少要在模型的基础上加两样东西——判断能力和行动能力。拿一个最简单的“天气查询机器人”举例。用户说“明天上海适合穿什么”模型先识别意图并提取城市和日期然后代码调用一个天气API拿到温度与降雨信息最后把天气数据传回模型由模型组织成一句自然语言回复。整个过程里模型负责理解和生成代码负责执行动作。这个闭环想清楚了那些复杂的Agent框架无非是把这个逻辑做成了可复用的流水线。所以第二天我并不急着去啃那些重型Agent框架而是先在脑子里钉死一句话模型负责想代码负责做。后面不管遇到多复杂的应用拆开看都是这条主线的延伸。3. 跑通第一个AI应用用Python调用大模型API做一个问答页面目标很明确这一天必须见血。我给自己设计的实操链路是先写一个不带任何框架的Python脚本调DeepSeek API拿到一次回复确认通了之后再套上Streamlit让它变成网页。分两步走的好处是一旦出错能快速判断是接口问题还是前端问题不用堆在一起瞎猜。环境方面我用了Python 3.11装好openai和streamlit两个库就够。奇怪的是很多人入门时会犹豫该学哪个具体框架但其实第一步根本不需要框架选型只要首先跑通“请求-返回”这一下后面所有东西都会顺理成章展开。3.1 环境准备与API Key管理用虚拟环境是必须坚持的习惯别图省事直接怼进全局环境后面装包时容易版本打架。我执行的操作如下python -m venv .venv source .venv/bin/activate pip install openai streamlit python-dotenv然后去对应模型平台的开放平台申请API Key。拿到Key之后我用.env文件保存避免把密钥直接写死在代码里。这样做有个直接好处后面把代码分享给朋友或者提交到源码仓库时不会把密钥意外带出去。.env文件里大概是这样DEEPSEEK_API_KEYsk-xxxxxxxx加载方式也很简单在脚本开头加两行先加载dotenv再用os.getenv读取变量。这一步看似无关紧要却是工程习惯的分水岭。很多人写AI应用喜欢把密钥写死一旦代码泄漏轻则被盗刷额度重则影响整个项目安全。3.2 从模型API到聊天机器人最简单的完整实现下面是当天第一个能跑通的Python脚本没有界面但已经能完成“AI应用开发”最核心的链路import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个乐于分享的AI应用开发导师回答问题简洁实用。}, {role: user, content: 请用三句话解释一下什么是RAG} ], temperature0.3 ) print(resp.choices[0].message.content)这段代码的核心就一个for循环式的逻辑准备好messages调用create拿到reply。第一次看到那串返回结构时很多人会被resp.choices[0].message.content吓到觉得解构很复杂。其实只是因为API支持一次返回多个候选结果列表里塞着不同的选项下标0就是第一个。拆开看后大脑立刻轻松了。运行后如果能看到一段通顺的中文输出就说明整条链路已经打通。接下来所有高阶玩法只是在这个基础上叠加历史消息、工具调用、多路搜索而已。3.3 Streamlit界面十分钟把命令行变成网页脚本通了之后我想给这个“问答能力”包一层壳做成能给别人用的页面。Streamlit是我见过对新手最友好的方式它不需要写HTML、CSS、JavaScript只要用Python写几个控件就会自动渲染成网页。import streamlit as st from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyst.secrets[DEEPSEEK_API_KEY], base_urlhttps://api.deepseek.com ) st.title(AI应用开发问答助手) prompt st.text_area(输入你的问题, 为什么需要Agent) if st.button(生成回答): if prompt.strip(): with st.spinner(思考中...): resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.3 ) st.write(resp.choices[0].message.content)启动命令是streamlit run app.py浏览器会自动打开一个本地页面。我第一次在输入框里敲下问题、看到页面返回答案的时候对“AI应用开发”这个短语的理解瞬间具体了。从聊天页面到自己写的页面缺的不是技术而是“动手接一次”的勇气。如果还想更进一步可以用st.chat_message和st.chat_input做成气泡对话效果。不过第二天的目标不是把界面做得多完美而是验证全链路能跑通。界面优化适合放到后面的项目里慢慢磨。4. 从“调接口”到“做Agent”在扣子上搭一个带知识的问答机器人仅仅调通API还只能算“接了个模型”离“应用开发”还有一段距离。真正的应用需要有业务知识、有流程、有对外入口。第二天下午我选择了扣子这个低代码Agent平台来做一个小实验用它搭一个带知识库的问答机器人。为什么选它因为扣子把Agent开发抽象成了可视化操作不用写太多代码就能把“知识库提示词插件”整套逻辑串起来。对新人理解Agent的工作方式非常友好。我更愿意把它看成是验证想法的试验台先在可视化界面上把业务逻辑跑通再回代码里做定制实现。4.1 扣子平台的优势零代码编排适合验证业务逻辑你可能想问有了代码能力为什么还要用低代码平台我的回答是不同阶段用不同工具。扣子能让我在半小时内做出一个能用的Bot而用代码实现同样功能至少要多写几百行还不算调试时间。我整理了一个简单的对比表方便你理解扣子和代码开发各自的适用场景对比维度扣子低代码纯代码开发上手速度快拖拽配置即可慢需要写接口、处理逻辑场景验证非常适合MVP和想法验证适合成熟业务接入知识库支持内置上传、分段、检索需要自己搭检索链路私有化部署受限完全可控深度定制边界明显几乎无边界我在扣子上做的第一个Bot是一个“入职问答助手”。它需要读一份员工手册然后回答新人关于考勤、报销、会议室预订等问题。这个场景如果纯代码实现需要处理文档上传、向量化、检索、Prompt拼装等一系列问题而扣子把这些都封装成了可用组件。4.2 实操步骤建Bot、传知识、开插件具体的操作流程分几步但每一步背后都有明确的业务含义。第一步新建Bot填一个名字和一句话简介相当于启动一个项目第二步在“人设与提示词”里写清楚这个Bot的角色、知识边界和回答风格第三步上传提前准备好的员工手册PDF或文本平台会自动完成内容分段和入库第四步按需添加插件比如搜索插件、办公应用插件让Bot具备行动能力第五步预览调试在对话框里问几个真实问题一边问一边调整提示词最后一步发布到聊天渠道或直接生成API调用地址。整个流程最耗时的部分不是操作而是想明白“这个Bot到底要解决谁的什么问题”。提示词别看只是几行字其实它就是业务规则。比如我在人设里写了“不知道答案时不要编造主动引导用户联系HR”这比让模型胡编强一百倍。4.3 什么时候需要回到代码扣子的边界在哪里扣子很好用但它不是万能的。第二天晚上我复盘时发现平台内置的编排能力解决的是“常见业务场景”真正需要深度定制的场景仍要回代码。比如涉及公司内部权限系统、需要对接自研数据库做复杂条件查询、要求本地私有化部署的合规场景低代码平台就显得力不从心。此外如果应用需要高并发、低延迟或者要把AI能力嵌进一个已有的大型系统里纯代码方案才是正道。我给自己的定位是扣子锻炼产品感代码锻炼工程能力两者结合才能把AI应用做扎实。先花一小时在可视化平台上模拟一个Agent的完整生命周期再回到代码写一个简化版这种双线学习法吸收率极高。5. 第二天的踩坑记录API错误、上下文爆掉、回答质量不稳必须承认当天的开发并没有一路绿灯。我遇到的坑大概能分出三类接口报错、上下文管理出错、回答质量不稳定。这三类坑几乎每个AI应用开发者都会撞见我把自己排查的过程写下来希望能帮你少走点弯路。下面先给一个速查表详细排查过程在后面分节展开。现象可能原因我的解决办法返回401API Key错误、有空格、读错环境变量检查.env、打印Key前缀核对返回400model名不存在、messages格式不对、max_tokens超限逐字段校验请求体返回429请求频率超过额度加time.sleep、控制并发回答为空max_tokens过短或内容被过滤调大max_tokens多轮对话失忆没把历史messages传进去维护会话消息列表回复太官方system prompt太宽泛或temperature过低细化身份与边界条件5.1 最常见的三个HTTP错误怎么定位第一个差点劝退我的错误是401。当时我在代码里写了Key运行后一直提示鉴权失败。排查后发现是.env文件里的Key被我多复制了一个换行符。这个错误很蠢但很典型处理办法是检查字符串首尾有没有隐藏字符或者用print(repr(os.getenv(KEY))看看真实内容。第二个是400错误。这个含义很广十有八九是请求体里的参数不合法。我遇到过把model名拼错的情况也遇到过messages数组里角色名写成了中文它们都会触发同样的400。定位技巧是先看错误响应里的具体message再用最小化请求逐项排查。第三个是429限流。免费额度或者低配额账号尤其容易碰到。解决办法也很朴素在每次请求之间加一个短暂sleep或者申请更高频次的配额。踩过这三个坑之后我自己的经验是别一报错就怀疑代码逻辑先看HTTP状态码对应的语义定位会快得多。5.2 上下文丢失不是模型笨是对话管理没做第一次做多轮对话时我发现一个诡异的现象第二句话还能记住聊到第五句模型就开始“失忆”。后来我查了API文档才意识到大模型接口本身是无状态的服务器不会自动记住之前的对话每次请求都必须把历史消息重新传一遍。正确做法是维护一个messages列表每轮对话后把用户输入和模型回复都append进去下一次请求带着整个列表发送。改完之后记忆问题立刻消失。但紧接着又出现新问题对话轮次一多历史消息越来越长token消耗变大响应也开始变慢。这时候需要做裁剪。我用的简单策略是只保留system message和最近四轮对话更早的内容可以总结成一段摘要塞回system里。这样既保住关键信息又控制了成本。5.3 生成质量不稳从调整参数到引入业务约束下午测试问答机器人时同样一批问题模型时而回答得很好时而答非所问。我一开始以为是模型抽风后来发现是用错了temperature。知识问答场景应该把temperature调到接近0让输出尽量确定创意场景才需要高温度。当我想让模型输出固定结构时还会在system prompt里明确要求“只输出JSON不要多余说明”。这一步能极大提升下游程序解析的稳定性。更进一步的兜底策略是约定“不确定时不回答”避免模型一本正经地胡编乱造。指令写在提示词里才叫规则写在产品需求文档里毫无意义。6. 第二天的结论和第三天的路线往哪走比走多快更重要第二天结束时让我最受用的不是学会了调一个API也不是搭出了一个页面而是把“AI应用开发”这个宏大的词拆成了一个个看得见、摸得着的模块。模型在那里接口在那里工具在那里差的只是有人把它们组织起来。6.1 第二天结束后我理清的三个认知第一个认知大模型是能力供应方不是完整产品。指望只靠模型本身交付业务是行不通的必须有工程逻辑做支撑。第二个认知提示词是应用层的第一行代码。它和代码一样需要设计、测试、迭代不能拍脑袋写一次就完事。第三个认知Agent的难点在接口和组织不在模型。只要思路清晰先定意图、再选工具、最后生成一个基础Agent并不难做。这三个认知直接改变了我接下来几天的规划。以前我总担心自己学不会“大模型应用开发”是因为数学不好、算法不懂现在明白了对于应用层开发者来说更重要的是系统工程能力和业务理解能力。6.2 第三天计划Java集成、知识库、多Agent协作第二天的收尾工作是把今天用到的所有代码和配置整理成笔记然后把扣子平台上那个机器人再拷问了几轮观察它在不好回答的问题上是如何表现的。都确认没问题后我就开始定第三天的路线。下一步我不会急着去读大模型的底层论文而是想把这条链路补完整第一用Spring AI把同样的问答能力集成到一个Java后端服务里看看生产级技术栈的写法有什么不同第二给本地知识库补上向量检索把RAG从“听说过”变成“亲手实现过”第三研究一下多Agent协作——让一个Bot拆解任务其他Bot分别执行再把结果汇总。这个方向已经在计划中等跑通了会把过程继续记录下来。对我来说学习AI应用开发最好的方式就是保持这种“带着目标项目往前冲”的节奏。如果你也卡在不知道该从哪一步开始不妨也定一个小到一天能做完的目标先把它跑通再回头补原理。你会发现原本模糊的“AI应用开发”几个字会慢慢变成具体的接口、函数、参数和一条条跑通之后的逻辑链路。