说实话学习AI编程的第三天我已经从“这玩意儿怎么装”过渡到“原来还能这么玩”。早晨打开编辑器写了一个几十行的小脚本把一段两千字的项目说明丢给大模型它不但给我总结了要点还帮我标出了可以直接用Python自动化的部分。放在三天前我不敢信自己能做到。这篇文章不是从零开始的系统教程也不是那种劝你“先学三个月Python再说”的劝退文。它就是我第三天的完整实操记录做了什么、为什么这么做、踩了哪些坑、下一步打算怎么学。如果你和我一样不是科班出身在产品和运营岗上摸爬滚打又对AI应用开发有好奇心这篇应该能给你一个可以直接照抄的路线。哪怕你完全没写过代码只要愿意花一个周末大概率也能走完我这条路径。先给个结论第三天能做事的核心不是先把Python学到精通而是直接站在大模型肩膀上用AI编程的方式反向补课。下面从头讲这三天我到底怎么安排的。1. 三天入门路线为什么第三天就能做出小项目1.1 Day1先把环境跑顺别急着啃教材第一天我犯过最大的错误就是打开一本Python教材从第一章“变量和数据类型”开始慢慢啃。结果啃了两个小时连一个真正能跑起来的项目都没有。下午我换了个策略先装环境再跑通一个hello world哪怕这个hello world只是把“你好”打印出来。目标只有一个让电脑按我的指令执行代码先建立正反馈。环境方面我建议直接装Python 3.10以上版本顺手装一个Anaconda或者Miniconda。很多人问为什么还要装Conda直接用Python官网的安装包不行吗行但我后面要装各种库不同项目依赖经常冲突。Conda能帮我隔离出独立的虚拟环境相当于一台电脑上开了好几个互不影响的“小房间”这个房间装Python 3.10那个房间装Python 3.12互不干扰。对零基础的人来说这一步会省掉后面80%的环境问题。编辑器我选的是VS Code不是因为它多好用是因为它市场占有率最高遇到问题随便一搜就是答案这一点对新手比什么都重要。装好之后我顺手装了几个插件Python扩展、Pylance还有后面要用的Jupyter插件。Jupyter虽然对新手友好但你真正要做自动化脚本、接API的时候还是得回到.py文件。所以我的建议是第一天就用.py文件练习别给自己养成“永远在笔记本里写代码”的错觉。第一天还有一个必修项命令行。Windows上打开PowerShellMac上打开终端至少要会cd进入目录、ls或者dir查看文件、python xx.py运行脚本。这三个命令就够了。为什么必须会命令行因为后面配置环境变量、安装依赖、启动本地服务全部都在命令行里操作绕不开。一个很关键的经验第一天别追求理解所有语法只要做到“我能改一个变量然后让程序输出不同结果”就行。当时我的练习是写一个程序读取一个text文件统计里面有多少个字。脚本本身很简单但跑通那一刻我对“编程”这两个字的恐惧感少了一大半。因为编程说白了就是你告诉电脑做什么它按步骤执行出错就改直到它听你的话。1.2 Day2只学20%的Python够用就停第一天跑通基础脚本之后第二天我开始学Python核心语法。这里有个重要判断学AI编程的人不需要先把Python全书学完再动手成年人学编程应该是“用啥学啥”而不是“学完再用”。我给自己划定了一个最小语法集变量、字符串、列表、字典、if条件、for循环、函数、文件读写、异常处理以及调用第三方库。这套东西听起来多其实对应到使用场景就是读入一个文件、处理里面的数据、调用一个API、把结果写出来。比如列表和字典我只需要知道它们是“装东西的容器”列表用方括号字典用花括号键值对取值用dict[key]。不需要知道底层内存是怎么分配的那是计算机专业的事不是应用开发者的事。第二天下午我重点练了requests这个库。它是Python里发HTTP请求的基础库也是后面调大模型API的必经之路。当时我写了一个小脚本从网上拉取一个公开接口的数据解析出里面的标题和链接然后保存到本地CSV。这三天里我觉得这个练习对后面的帮助是最大的。因为大模型API本质上也是发一个HTTP请求只是多带一个密钥和一段JSON格式的请求体。把requests搞明白就等于学会了大模型API的大半工序。第二天的成品是一个“天气问答”小程序用户输入城市名程序请求一个天气接口解析温度、湿度用自然语言回答“今天出门要不要带伞”。代码不到80行却把“输入、处理、输出”的完整编程链路走了一遍。那会儿我对编程的理解已经变成编程不是背语法而是“把一个问题翻译成计算机能执行的步骤”。1.3 Day3从“调用”开始理解大模型第三天早上我没继续啃语法而是直接去调用大模型API。这一步是整个学习过程的分水岭前两天的Python是“术”今天接触的才是“道”——理解了自然语言接口的用法AI编程的大门才算真正打开。现在国内外的模型厂商基本都提供OpenAI兼容接口这意味着我可以只用一套代码改一个base_url和model名称就能切换不同家的大模型。我用的是Python的requests库没有装SDK。为什么不装官方SDK因为我想先用最原始的方式搞清楚请求结构。SDK就像自动挡汽车省心但新手还是应该先开两圈手动挡知道换挡原理后面开什么车都不慌。调用大模型API的本质是什么你可以把它理解成向一个极聪明的“实习生”描述任务他会按你的要求返回一段文本。但这位实习生有几个性格特点很聪明但偶尔会一本正经地胡说八道这就是行业里常说的“幻觉”很会接话你说得模糊他就答得模糊他的“记忆”有限一次只能看到一定长度的上下文超出部分会被截断。理解这三点后面很多问题都能自动找到答案。第三天上午我终于跑通了一个最原始的对话请求传一句“用三个词形容春天”模型返回“温暖、生长、希望”。说实话那一刻的震撼不在于文字本身而在于我突然理解了原来AI编程不是自己写逻辑而是写“如何让模型帮你干活”的规则。这个认知转变比任何代码都值钱。2. 第三天的小项目自动摘要加关键词提取2.1 把需求拆到不能再拆既然已经跑通了最基础的调用我开始琢磨第三个下午干点什么。如果只是“和AI聊天”那和玩网页版没什么区别学不到编程的精髓。我的目标是做一个真正有用的小工具输入一大段文本自动输出摘要、关键词、以及“这段文字里能自动化的动作”。这个需求听起来不大但拆解下来其实有几个关键步骤读取输入文本、构造提示词、调用大模型、解析返回结果、把结果保存成结构化文件。拆需求这件事对刚学编程的人来说特别重要。很多人卡住不是因为不会敲代码而是一上来就想做一个“智能助手”结果不知道第一个字符该写什么。我的经验是把一个模糊愿望变成可执行的三句话。比如我的需求可以拆成输入一份本地txt文件内容是项目说明。处理调用大模型要求它按指定格式返回摘要、关键词、可自动化操作清单。输出把返回的JSON解析后打印在屏幕上同时保存在一个新的txt文件里。这样一拆每一步都是已验证过的技能文件读取我Day1做过API调用我Day2练过JSON解析虽然没正式学过但借着这个项目十分钟就学会了。这就是“项目驱动学习”的节奏不是学完再做而是做了才知道要学什么然后立刻学立刻用。2.2 提示词决定效果的一半编程界有句话叫“垃圾进垃圾出”在AI编程里尤其成立。同一个模型同一个参数提示词写得潦草和写得严谨输出质量能差出一整条街。第三天下午我一半以上的时间都花在“怎么写好一段提示词”上。我先用了一个普通版本把原文贴进去加一句“帮我总结一下”。模型确实返回了总结但格式不稳定有时是一大段话有时列三个要点完全不固定。这不行因为我后面要写程序解析它。于是我在提示词里明确要求必须输出JSON并且严格遵循以下格式。这招立竿见影返回结果立刻变得规整。这里有一个重要技巧叫“少样本提示”。只告诉模型要输出JSON还不够最好再给它一个具体例子。比如请根据以下文本生成JSON格式参考 {summary: 一句话摘要, keywords: [关键词1, 关键词2], actions: [可自动化任务1]} 文本内容 这里放原文为什么给例子这么有用因为大模型是在模仿概率分布你给了它一个标准答案的形态它就会沿着这个形态生成。比你在提示词里写十句“输出格式要规范”都管用。另外还要注意system和user角色的分配我把规则类信息放在system里把具体文本放在user里这和真实世界的“老板交代实习生任务”很像先给岗位职责再给具体任务。还有一个参数必须认识temperature。它控制模型的“随机性”取值范围一般是0到2。追求确定性结果比如抽取关键词、生成JSON时把它调到0或者0.2想让模型更有创意比如写文案、写故事时可以调到0.8甚至1.0。这个项目里我直接设成0因为我要的是稳定的结构化输出。2.3 完整流程代码实现与逐行解释接下来是当天最有成就感的环节写完整脚本。以下是我第三天下午的最终版代码去除了密钥保留了核心逻辑。为了通用性我用了环境变量存放密钥和模型配置如果你跟着做需要把代码里的占位符替换成你自己的配置import os import json import requests # 读取本地文本 def read_file(path): with open(path, r, encodingutf-8) as f: return f.read() # 调用大模型API输入文本返回解析后的JSON def ask_model(text, base_url, api_key, model_name): headers { Authorization: fBearer {api_key}, Content-Type: application/json } system_prompt ( 你是一个文本分析助手。请严格按照用户要求的JSON格式输出 不要输出多余的解释性文字。 ) user_prompt f 请阅读下面的文本并输出JSON。JSON必须包含三个字段 summary: 用一句话概括文本核心内容 keywords: 提取3到5个关键短语使用中文列表 actions: 列出文本中提到的、可以程序化执行的任务最多3条如果没有返回空列表 参考格式{{summary: ..., keywords: [...], actions: [...]}} 文本内容 {text} payload { model: model_name, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: 0, max_tokens: 800 } response requests.post( f{base_url}/chat/completions, headersheaders, jsonpayload, timeout60 ) response.raise_for_status() data response.json() content data[choices][0][message][content] # 模型可能把JSON包在代码块标记里这里做一个清理 content content.strip() if content.startswith(): start content.find(\n) end content.rfind() content content[start:end] return json.loads(content) if __name__ __main__: base_url os.getenv(LLM_BASE_URL) api_key os.getenv(LLM_API_KEY) model_name os.getenv(LLM_MODEL) text read_file(input.txt) result ask_model(text, base_url, api_key, model_name) print(json.dumps(result, ensure_asciiFalse, indent2)) with open(result.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)这段代码里有几个值得反复看的细节。第一response.raise_for_status()是在说“如果请求出错了就直接抛出异常”这比闷声返回一个错误结果好得多让我能立刻在命令行里看到问题。第二我把max_tokens设成800这是控制模型最长生成长度的参数防止它一口气写一堆无关内容。第三关于JSON清理那段逻辑是因为我实测发现有些模型会在JSON外面再包一层代码块标记如果不处理json.loads会直接报错。这个脚本跑通之后我只做了一件事把input.txt里的项目说明换成了一篇行业分析文章。模型返回的summary虽然不是满分但已经达到了“可以先读摘要再决定要不要看原文”的可用度。keywords里的五项有三个确实是一眼就能抓住重点的词。那一刻我意识到这个工具以后可以用来处理各种文档不只是项目说明。2.4 自测和边界处理脚本能跑通只是第一步真正让我费时间的是各种边界情况。一个只会在“正常数据”下运行的脚本和能应对“脏数据”的脚本差距就在这里。我拿了几种不同类型的文本测试空文件、只有一行的文本、全英文文本、混合编码文本。结果马上暴露问题空文件会让模型返回空摘要keywords变成空列表超长文本会突破API的上下文限制直接报错。这说明我需要在业务层做防护。针对空文本我在调用模型前加了一个判断如果去掉空格后文本长度小于10个字符直接返回友好提示不调用API。针对超长文本我暂时做的是“按字符数截断到3000字”虽然粗暴但至少能保证脚本不崩。后来我了解到正规做法是文本分块后多次调用模型再用“整段摘要的摘要”汇总这是RAG和MapReduce思想在文本处理上的变体。第三天的我还做不到那么完整但至少意识到了方向。另一个测试点是模型的“不稳定输出”。哪怕我要求JSON格式它偶尔还是会返回“好的我将为你生成JSON”这种多余的前缀。这也是我加清理逻辑的原因。这件事给我的启发是和AI协作永远不要假设它100%听话程序里要留一些兜底层。3. 第三天踩过的坑环境、请求、幻觉、成本3.1 环境和密钥管理的教训第三天上午我被一个低级失误卡了整整四十分钟不小心把API密钥写在了代码里。当时只是想着“先跑通再改”结果一刷新Git提交记录发现密钥已经躺在版本历史里。虽然我用的测试额度很快注销了账号重新申请但这个教训让我牢记所有密钥必须放进环境变量或者.env文件绝不能硬编码进代码更不能提交到Git仓库。具体操作其实很简单。在项目根目录下创建一个.env文件内容类似LLM_BASE_URL你的接口地址 LLM_API_KEY你的密钥 LLM_MODEL你的模型名然后在代码里用python-dotenv加载from dotenv import load_dotenv load_dotenv()再把之前的os.getenv接上就行。同时必须在.gitignore里写上.env防止误提交。这个习惯越早养成越省钱因为泄露密钥最直接的后果是被人盗刷一天晚上扣光几百块额度的事在技术社区里不算新鲜。还有一个小坑Windows上命令行设置环境变量用setMac和Linux用export语法不一样。用.env文件之后这些平台差异基本就能抹平了这也是我推荐新手上手就用dotenv的原因。3.2 请求失败与超时重试没那么简单调API第一天就遇到请求超时是很正常的事。我当时的错误做法是把整个请求重试了十几次然后连续收到十几个429状态码。429的意思是“请求太多服务端让你慢一点”连续快速重试只会让情况更糟。后来我改成了“指数退避”策略第一次失败等1秒再重试第二次等2秒第三次等4秒最多重试4次。这样既给了服务端恢复的时间也不会把自己逼疯。这个策略其实在很多成熟库内部都有实现但手写一遍能让我真正理解它的原理。代码大致是import time def request_with_retry(func, max_retries4): for attempt in range(max_retries): try: return func() except requests.exceptions.RequestException: wait 2 ** attempt time.sleep(wait) raise RuntimeError(请求多次仍失败)现在我终于明白为什么市面上所有大模型SDK都把重试逻辑内置了网络请求本身就不是100%可靠这个世界的网络随时会抖动。当成败取决于运气时唯一能做的就是增加重试次数同时祈祷服务端快点恢复。当然如果能用更高效的异步方式写并发请求那体验又会不一样不过我决定把那部分放到更后面学。3.3 模型输出不稳定让JSON别乱跑第三天下午我一度怀疑自己写的JSON解析代码有bug因为模型返回的内容怎么都解析不成功。后来把原始返回打印出来才看到模型在前面加了一句“这是你的结果”后面才跟着JSON。这让我明白了一个真理和模型对话你要预设它不听话然后写代码处理它不听话的结果。我采用的清理方案是把返回内容首尾用中括号和花括号定位截取从第一个{到最后一个}之间的子串再用json.loads解析。但这也只能在模型“基本听话”的前提下兜底如果模型真的放飞自我输出大段散文那只能靠更强大的约束手段了。后来我查资料发现很多平台支持“结构化输出”或“函数调用”能力可以在请求体里声明一个JSON Schema强迫模型按这个Schema输出。这比我在提示词里苦口婆心说十遍“你必须输出JSON”都可靠。但它的前提是模型本身支持这个特性而且需要我学会JSON Schema的写法这已经不是第三天的能力范围了。我只记住一点大模型不是函数它是概率系统任何使用它的代码都必须对输出做校验和降级。3.4 Token和成本一晚上烧掉好几块说实话第三天晚上查询账单之前我对Token完全没有概念。直到看到“累计消耗Tokens”和对应的金额我才意识到每一次调用都是真金白银。虽然各家模型价格已经很低但如果写一个死循环不断调API几个小时也能烧掉几十块。Token可以粗略理解为“模型处理文本的最小单位”英文一个单词大概对应1到2个Token中文一个汉字大概对应1到2个Token1个Token约等于0.75个英文单词。我请求文本越长、返回内容越长消耗就越大。更关键的是输入文本和输出文本都计费连我之前写进system里的那段提示词每次调用都要算一次费用。所以控制成本的第一招就是精简提示词第二招用便宜的模型处理简单任务第三招本地缓存重复请求同一个文本只分析一次。我当时的优化方案很朴素把分析过的文本哈希值存到本地文件里第二次遇到相同文本直接读缓存不再重复调模型。这个方案效果立竿见影成本直接砍半。它虽然不是多高深的技术但让我理解了“在大模型应用里成本和性能是需要一起设计”的。4. 第三天后看AI编程和传统编程差在哪4.1 从“命令计算机”到“表达意图”三天前我以为编程是掌握一门机器语言学着用if、for、while这些精确指令指挥计算机。三天后我发现AI编程的思维方式变了很多传统编程是你事无巨细地规定每一步AI编程是你描述目标、提供上下文、设定约束剩下的交给模型。这个转变对我来说很震撼。传统编程里如果我想要“提取关键词”我需要自己写分词算法、停用词表、统计词频可能还得学一下TF-IDF。但用大模型我只要说“请从这段文本中提取3到5个关键词”它就能给出一个相当不错的结果。不是说算法没用了而是模型的泛化能力把很多领域的门槛直接削平了。我能把精力花在“定义问题”和“校验收官”上而不是“实现算法”。当然AI编程不等于没有逻辑。恰恰相反AI编程更需要逻辑你要理清楚数据从哪来、往哪去请求失败怎么办输出的内容怎么检查。传统编程的严谨性没有消失只是从“写每一行代码”转移到了“设计整个流程”。第三天后半段我的注意力几乎都在流程上读取、构造、请求、解析、存储、异常处理每一环节都有明确的责任这比追逐新框架重要得多。4.2 AI Agent是什么第三天能理解到什么程度最近“AI Agent”这个词特别火我也好奇第三天能不能理解它。查了一圈资料外加动手试我的简单理解是Agent就是让模型不只是“你问一句它答一句”而是给它工具让它拆解任务、调用工具、根据结果决定下一步直到完成任务。传统聊天模型是“嘴巴”Agent是“嘴巴加手”。第三天下午我做了一个特别简化的实验把“文本摘要工具”和“关键词提取工具”写成两个Python函数然后给模型返回的actions字段做循环如果解析出来的动作列表里有“todo”就调用对应函数。这个流程虽然简陋但已经算是Agent的雏形了。将来要进阶还需要学“函数调用”、记忆机制、多轮规划这些我打算放到第七天以后。不过这里想提醒和我一样的初学者别被概念绕晕。Agent听起来很玄本质仍然是“模型加工具加循环”。先把我这三天做的小脚本跑通再谈Agent不迟。如果一个人连requests.post都还不太明白上来就研究LangChain或者多智能体协作大概率会变成调包侠出了问题连日志都读不懂。4.3 接下来每天练一个什么样的小项目三天下来我给自己定了一个原则每天至少写一个能跑的小项目哪怕再小也要串起完整的“输入-处理-输出”闭环。因为AI编程这门手艺反射弧必须靠练才能建立。以下是我贴在自己的学习计划表里的未来一周安排第四天做一个批量文件整理工具按后缀名自动归档顺便让大模型给每个文件起个可读的新名字。第五天做一个本地知识问答脚本把几份文档分段存储检索后送到大模型回答这就是最简RAG。第六天给摘要工具加上“文本分块再汇总”的功能顺便学一下MapReduce的基本思路。第七天尝试给大模型接一个“计算器工具”让模型在遇到数学题时先调用工具再回答。第八天做一个简单的异步并发请求脚本一次性向模型发多个摘要请求学一点asyncio。第九天把前面所有小工具合并成一个带菜单的命令行程序顺便用Git管理代码版本。这份计划不一定完美但它保证我每天都有产出。因为我发现对零基础的成年人来说最大的敌人不是难度而是中断。一旦连续两天不写代码之前建立的手感就会变得模糊报错信息都变得陌生。反过来只要每天都碰代码哪怕只写二十行编程的感觉就会一直在线。我自己第三天最大的感受是AI编程没有想象中那么高深它更像是“学会如何指挥一个极其聪明的合作者”。这位合作者懂很多知识做事很快但偶尔会自作主张也会偷懒敷衍。你要做的不是替它把每一步都想好而是把规则定清楚、把边界画明白、把结果验仔细。三天前我连一个requests请求都可能写不对三天后我已经能借助模型构建一个能帮自己处理文档的小工具。这种“被工具增强”的感觉比单纯学语法有意思太多了。如果你也正打算零基础开始学AI编程我唯一的建议是别从教材第一页开始看就从今天开始写一个“让大模型帮你干活”的脚本。上手之后你会发现编程这件事真的没你刷到的那些帖子说的那么难。