今天是我死磕AI应用开发的第二天。昨天我把环境搭好了Python、IDE、API密钥都齐了但说实话心里还是虚的——因为我不知道从哪一步开始才能真正让大模型变成我能掌控的东西而不是只在网页对话框里聊几句。今天这一整天我集中做了一件事把AI应用开发的几个核心问题彻底想明白并且亲手写出了第一个能跑的后端接口。这篇文章就是Day02的完整笔记包括AI应用开发学习路线里的关键分岔、我踩进去又爬出来的坑以及一个可以直接抄走的“最小AI应用”模板。如果你正在学大模型应用开发或者准备转岗AI应用开发这篇文章应该能帮你少走一周弯路。1. 先搞清楚AI应用开发到底在开发什么1.1 不是训练模型而是“使用模型”我在第一天的笔记里说过一个观点今天我要再强调一遍大多数人学AI应用开发根本不需要去训练模型。我们需要做的是把已经存在的GPT、通义、文心、豆包这类大模型通过API集成到自己的业务系统里。整个过程更像是“配菜师”而不是“种菜的”——模型是别人种好的菜我们的工作是怎么把它洗干净、切好、调味最后端给用户。听起来简单但实际操作时很多人容易犯迷糊。我见过一个朋友上来就研究Transformer结构、微调方法一个月后还在理论里打转连一个API请求都没发出去。这不叫AI应用开发这叫模型训练。真正的AI应用开发核心是把模型的输入输出接进业务流程让模型在特定场景下解决具体问题。你需要懂的不一定是数学公式而是API怎么调、Prompt怎么写、返回的结果怎么解析、出错怎么兜底。今天我要做的第一件事就是把这个认知彻底固化下来。我给自己规定了一个“应用开发者视角”一切从调用开始一切以需求结束。模型的内部原理能跑通之后再去补课。1.2 从“问答”到“Agent”的能力分层最近AI应用开发领域最火的关键词非“AI Agent”莫属。今天的热搜里也堆满了AI Agent相关词。但我研究了一圈之后发现很多人对Agent的理解是模糊的以为只要调一次大模型接口再返回结果就是Agent。这里我先把能力分个层级方便后续学习对标。第一层是单轮问答。我给它取名叫“一锤子买卖”。用户说一句话你把它原封不动发给模型模型返回一句话你展示给用户。这是最基础的API调用但也是最容易被忽略的地基。第二层是多轮对话加工具调用。模型不再只是“嘴上说说”它可以去查天气、查数据库、调用外部API然后把结果用自己的话讲给你听。这就像是给一个知识渊博但不动手的人装上了手和脚。实现方式通常是让模型识别用户意图然后你根据意图去执行对应工具再把结果拼进Prompt里让模型生成最终回答。第三层才是真正意义上的Agent。模型自己有目标拆解能力你说“帮我安排一条周末旅游路线”它会自己规划成几个子任务查天气、查交通、查景点、查美食然后依次调用工具最后汇总成一个完整方案。这个过程中模型扮演的是“策划者”而代码负责的是“执行平台”。我的建议是学习路线必须严格按这个层次走。第一天调通API第二天实现多轮对话第三天再加一个简单工具调用全部跑顺了再碰Agent。直接一步到位学Agent很容易被模型的“规划幻觉”打崩溃——它看起来是在思考实际上在瞎编步骤。1.3 选型思考为什么我选“大模型APIPython”组合现在的AI应用开发栈五花八门有LangChain、LlamaIndex这种框架有Dify、扣子这类低代码平台还有各种模型厂商的SDK。我今天实际动手时没有直接用框架而是用最原始的requests和Python脚本做了一轮调用。这个选择背后是有原因的。第一门槛足够低。只要电脑能装Python会写一点点HTTP请求哪怕完全不懂机器学习也能把核心流程跑通。这样可以把注意力集中在理解“应用架构”上而不是被框架抽象概念带偏。第二生态成熟。无论你接OpenAI兼容接口、通义千问还是豆包它们的API范式几乎都是“POST一个JSON过去拿回一个JSON”差异只在字段名和鉴权方式。当你手写过一次调用之后再换任何一家厂商你只需要看文档改请求体就行。第三方便排查问题。一旦接口报错或返回内容不对你能直接看到原始请求和原始响应能快速定位是哪一步出了问题。如果用框架报错信息会绕好几层新手很容易懵。第四低代码平台可以辅助快速验证想法。比如热词里提到的“扣子”这类Agent开发平台特别适合做原型验证连代码都不用写。但我始终觉得低代码是结果验证工具不是学习工具。你只有明白了底层逻辑才能在低代码平台里合理地编排节点。否则出了问题你连故障方向都说不清。2. 动手写代码前必须吃透的几个核心概念2.1 Prompt工程你与模型之间的“编程语言”今天一整天我其实有一半时间都花在调Prompt上。很多人有个误区认为写Prompt就是随便说句话。实际上Prompt就是你给程序员的“需求说明书”你描述得越精准模型产出的质量越高。我总结了一套最基础但极其管用的Prompt四要素写法角色设定。让模型知道你希望它以什么身份回答问题。比如“你是一名Python性能优化专家”就比“帮我看看代码”效果好得多。明确指令。告诉模型具体要做什么不做什么。比如“只输出优化后的代码不要解释理由”。提供约束和格式。比如“用JSON返回字段包括标题、摘要、关键词”。给出示例。一个两个示例胜过一百句口头描述。我拿一个实战例子说明。昨天我让模型写一个冒泡排序算法我是这么问的“用Python写冒泡排序。”结果确实返回了代码但还附带了一大堆解释和测试代码非常啰嗦。今天我把Prompt改成“你是一个高效的算法工程师。请用Python实现冒泡排序函数函数名为bubble_sort输入是列表返回值是排序后的新列表。只输出代码不输出任何解释。参考示例输入[3,1,2]返回[1,2,3]。”这次输出的代码干净利落直接就能往文件里贴。关键在于模型不是你肚子里的蛔虫它只能根据你给的文字去猜需求。Prompt写得好后面所有步骤都轻松Prompt写不好你后面写再多解析代码都是在补救。2.2 上下文管理与Token计算这一步是新手最容易忽略但真正决定应用能否落地的环节。先说Token。Token是模型计费和处理的基本单位可以简单理解成“字片”。中文环境下1个Token约等于0.5到0.7个汉字具体看分词方式。模型对所有输入和输出都按Token计量所以你得有个概念调一次API发出去的Prompt越长花的钱越多模型的思考负担也越大。上下文窗口就是模型能记住的Token总量。比如某模型的上下文窗口是128K你一次性最多能喂给它那么多内容。这本身没什么关键在于“多轮对话记忆”的实现。很多新手第一次做聊天机器人时只把当前用户问题发过去结果模型完全没有记忆因为他把历史消息全丢了。要实现记忆你需要把之前的会话历史作为一组消息连同当前问题一起发给模型。这里涉及一个经典问题历史消息不能无限往上堆。当对话超过上下文窗口或者超过你设置的成本上限时你需要做截断或者摘要。我今天的实现里写了一个简单策略只保留最近5轮对话更早的内容全部丢弃。如果你的业务需要记住更久以前的事可以定期把历史对话丢给模型做一次总结把总结放回上下文里代替原始内容。这招叫做“上下文压缩”是低成本高收益的技巧。还值得注意一点你发的每条消息系统都会附带角色标签通常有system、user、assistant三种。system用来放全局指令user是用户输入assistant是模型之前的输出。上下文管理就是维护好这个三元组的列表。2.3 模型参数temperature、top_p、max_tokens光会发请求还不够你要知道几个关键参数的含义。举个最直观的例子temperature控制随机性。数值范围通常是0到2数值越大回答越天马行空数值越小回答越保守。代码生成、梗概提取这种要求精确的任务我习惯调到0.2到0.3写广告语、故事这种创意类任务我会调到0.8以上。top_p是核采样参数控制模型在候选词集合里取多大的概率范围。它和temperature有类似作用但原理不同。官方文档的建议是改temperature就别动top_p改top_p就别动temperature否则结果会乱。max_tokens限制生成的最大长度。比如你让模型写一篇文章如果不设上限它可能编到天荒地老但设太小又会截断完整答案。我一般会估算答案长度再加上余量宁可长一点不能截断逻辑。今天我做了一个很重要的实操把temperature从默认值调到0.3并且在Prompt里加了“如果不确定就直接说不知道”。这一下子就解决了模型“一本正经胡说八道”的问题。所以遇到模型输出质量差建议先检查参数和Prompt而不是立刻换模型。3. 手把手写第一个AI应用本地知识问答助手3.1 项目结构设计把基础概念过完就该上手了。我今天的项目是一个“本地知识问答助手”目标是对接一个在线大模型API实现多轮对话并且能通过HTTP接口被前端或其他系统调用。我没有一上来就搭复杂目录而是保持一个最小但五脏俱全的结构day02/ ├── app.py # 主程序FastAPI服务 ├── prompt.py # Prompt模板 ├── memory.py # 对话记忆管理 ├── config.py # 配置项 └── requirements.txt # 依赖为什么要拆成这样因为每个文件职责单一后面好扩展。比如以后想换模型只改config.py和app.py里的调用逻辑想调Prompt只动prompt.py。如果你把所有逻辑都堆进一个main.py后面改起来会非常痛苦。requirements.txt内容很简单fastapi0.115.0 uvicorn0.30.0 openai1.30.0 python-dotenv1.0.1注意这里我用的是openai的SDK但连接的是兼容OpenAI协议的国内模型服务只需要改base_url和api_key就行非常方便。3.2 用FastAPI包一层HTTP接口我的目标是跑起来一个服务让任何客户端都能POST一段文本然后拿回AI生成的回答。代码如下# config.py import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(API_KEY) BASE_URL os.getenv(BASE_URL, https://api.openai.com/v1) MODEL os.getenv(MODEL, gpt-3.5-turbo-instruct)密钥绝不能写死在代码里。我吃过这个亏有一次把测试密钥推到了自己的公开仓库里半小时后就收到警告邮件说密钥被滥用。所以现在一律用环境变量管理。主程序# app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from openai import OpenAI import config app FastAPI() client OpenAI(api_keyconfig.API_KEY, base_urlconfig.BASE_URL) class ChatRequest(BaseModel): message: str class ChatResponse(BaseModel): reply: str app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): try: resp client.chat.completions.create( modelconfig.MODEL, messages[ {role: system, content: 你是一个简洁的AI助手回答尽量控制在200字以内。}, {role: user, content: req.message} ], temperature0.3, max_tokens500 ) return ChatResponse(replyresp.choices[0].message.content) except Exception as e: raise HTTPException(status_code500, detailf模型调用异常: {str(e)})启动服务uvicorn app:app --host 0.0.0.0 --port 8000我用curl测试curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 用一句话说明什么是Agent}返回结果{reply: Agent是大语言模型驱动的智能体能够自主规划任务并调用工具完成复杂目标。}到这一步一个完全没有AI实战经验的人也能跑通的“AI后端”就出现了。很多框架里那些花哨的Agent编排最底层也是这样一个请求-响应循环。3.3 加入流式输出与对话记忆单纯返回完整结果在网络慢的时候体验很糟糕。用户会看到接口转圈几秒钟然后突然蹦出整段话。为了优化体验我加上了流式输出。传输层还是同一个接口但请求时加上streamTrue然后不断从响应里取增量token通过FastAPI的StreamingResponse把内容一点一点推给前端。# 流式请求核心逻辑 stream client.chat.completions.create( modelconfig.MODEL, messagesall_messages, streamTrue ) for chunk in stream: delta chunk.choices[0].delta.content if delta: yield delta同时我把memory.py里维护的对话列表也接进来。核心代码如下# memory.py MAX_HISTORY 5 class Memory: def __init__(self): self.history [] def add_user(self, content): self.history.append({role: user, content: content}) def add_assistant(self, content): self.history.append({role: assistant, content: content}) def get_messages(self): # 只保留最近MAX_HISTORY轮完整对话 recent self.history[-(MAX_HISTORY * 2):] return [{role: system, content: 你是一个知识问答助手。}] recent这样当用户持续提问时模型就能“记住”前面聊了什么。注意这里多轮记忆是“伪记忆”本质上是把历史文本一起发给模型重新推理并没有真正的状态存储。这个认知很重要因为到Agent阶段你还需要引入外部存储和记忆检索才能实现更复杂的长程规划。3.4 低代码平台“扣子”快速验证Agent想法手写代码固然能学原理但实际工作里有些场景用低代码平台效率更高。我今天下午专门花了一个小时研究热词里反复出现的“扣子开发AI Agent智能体应用”。扣子这类平台最大的价值是让你在拖拽节点、配置插件的过程中快速验证一个Agent逻辑。我在扣子上创建了一个“旅行规划助手”Bot。流程是用户提出需求Agent节点拆解任务插件节点搜索景点和天气最后用大模型节点汇总回答。整个过程不需要写后端代码模型调用、工具调用、上下文管理都被平台封装好了。对一个刚学AI应用开发的人来说用扣子搭一个原型来理解Agent的“规划-执行-响应”流程比硬啃代码要直观得多。但我也要说句大实话低代码平台能做70分的产品很难做到95分的产品。原因是高度封装让你失去对底层行为细节的控制比如自定义截断策略、精确的异常捕获、深度调优Prompt。所以我给出的建议是学习阶段用低代码理解思路实战阶段手写代码掌握细节。两者不是二选一而是前后衔接的关系。4. 从Demo到能用避坑与进阶4.1 效果评测别靠感觉打分Demo跑通后我面临一个新的问题这个AI助手到底好不好用如果光靠我自己问几个问题感觉“还行”那是不够的。今天我盘了一下自己踩过的坑整理出一套最低成本的效果评测方法。第一步建立测试集。我准备了20个问题覆盖四类常见业务问题、边界问题一句话说不清的问题、对抗性问题故意诱导模型出错的问题、完全超出知识范围的问题。第二步给每次输出打分维度包括准确率、完整性、语气自然度、安全性。每天让同一个模型跑一遍测试集分数对比就能看出改动是变好还是变坏。这个习惯可能比调参本身更有价值。这一步千万不能省。很多AI应用真正上线后口碑崩掉不是因为模型不行而是因为没做评测光靠开发者的自我感动。4.2 AI测试开发关注鲁棒性和异常场景既然提到了测试就必须说说“AI测试开发”这个方向。传统软件测试关注功能逻辑AI应用测试还要多关注一层模型输出是概率性的同样的输入两次结果可能不一样。所以测试不能只断言“返回了什么”还要设计容错策略。我今天在代码里加了两个测试用例用来验证异常输入import pytest from fastapi.testclient import TestClient from app import app client TestClient(app) def test_empty_input_returns_400(): response client.post(/chat, json{message: }) assert response.status_code 400 def test_normal_input_returns_200(): response client.post(/chat, json{message: 你好}) assert response.status_code 200 assert reply in response.json()这只是最原始的用例真正做AI测试开发还需要覆盖模型接口超时、第三方API限流、并发请求下是否会串号、用户恶意输入是否会被拦截。这些场景今天我没有全部实现但先列成清单后续逐步补充。4.3 安全与合规绕不开的底线我刻意把安全放在最后一部分不代表它最不重要而是因为它是所有工作的前提。做一个大模型应用如果只追求“输出看起来聪明”不考虑安全那上线就是给自己埋雷。几个每天都要对自己喊一遍的原则用户输入不要直接拼进系统提示词里而不做隔离。否则用户可以通过“忽略以上指令”等方式劫持你的系统设定。我今天的实现里其实就存在这个隐患只是开发阶段没触发。正确做法是把用户输入作为独立的user消息传入而不是拼接进system里。输出内容需要做敏感词过滤或人工审核机制。尤其是公开面向用户的场景。大模型有时候会生成看似合理但实际有害的内容单纯靠模型自身安全对齐是不够的。隐私数据不能发送给外部模型。用户手机号、身份证、内部业务数据一旦发到第三方模型接口你无法控制数据流向这是红线问题。保留操作日志。谁在什么时间发了什么请求模型返回了什么都要有记录。否则出了问题你连排查的依据都没有。这些不是空话而是我见过太多项目因为不做安全控制上线第二天就收到投诉甚至更严重的后果。所以今天哪怕是写这个最小应用我也在代码里加了异常日志输出并且用mock数据测试了明显敏感的输入确保系统不会被一句话引爆。5. Day02的复盘与明天计划今天这一整天的实践我最大的体会是AI应用开发没有想象中那么玄但也绝对不只是“调用一个接口”。它的核心复杂度在于两点一是把模糊的业务需求翻译成模型能理解的Prompt和上下文结构二是围绕模型这个“概率引擎”设计出确定性高的工程框架。我今天踩的最大的坑是花了一个小时试图让模型“记住”用户之前提到的所有细节最后发现根本原因是上下文长度不够而不是模型不开窍。后来我会主动控制对话轮次才正常起来。这个过程也让我意识到学习和调试AI应用最重要的能力是“定位边界”模型的能力边界在哪里程序的边界在哪里你输入的数据边界在哪里。明天我计划把工具调用跑通也就是让模型在回答问题时能够根据用户意图去查询本地文件或者调用一个天气API。这正好是通往AI Agent的关键一步。如果你也在学AI应用开发我建议你也找一个小的应用场景比如“AI周报总结助手”或者“AI商品描述生成器”哪怕只写二十行脚本也比看十篇教程有用得多。把第一个能跑的小项目挂在你的仓库里之后的路会越走越顺。