1. 从零开始学AI先搞清楚你到底要学什么很多人一说“从零开始学AI”脑子里第一反应就是去啃《深度学习》花书、推导反向传播公式、手撸一个Transformer。我见过太多人卡在这一步三个月过去还在跟偏导数较劲最后热情耗尽连一个能跑起来的小项目都没做出来。问题出在哪出在把“学AI”当成了一个单一目标但实际上它至少分成四条完全不同的路径每条路径的入门方式、所需基础、见效周期都不一样。第一条路径是AI应用使用者。你不需要懂模型怎么训练只需要知道怎么把现有工具用好。比如用AI辅助写代码、用AI做PPT、用AI整理会议纪要、用AI生成图片素材。这条路门槛最低今天看完今天就能用适合绝大多数非技术岗位的人。第二条路径是AI应用开发者。你要会调用大模型的API会写提示词会搭建简单的AI Agent能把AI能力嵌入到自己的产品或者工作流里。这条路需要一点编程基础但不需要你懂模型底层原理属于“会用轮子造车”的层次。第三条路径是AI算法工程师。你要理解模型结构、训练流程、微调方法、推理优化能根据业务场景选择合适的模型并做针对性调整。这条路需要扎实的数学和编程功底学习周期以年为单位。第四条路径是AI研究者。你要能读懂最新论文、复现实验结果、提出改进方案。这条路对天赋和平台都有要求不是单靠自学能走通的。我写这篇东西的定位很明确帮你走通前两条路。也就是说让你从一个完全不知道AI能干什么的人变成一个能用AI解决实际问题、能搭建简单AI应用的人。第三条路我会告诉你需要补哪些基础但不会在这篇文章里展开讲数学推导。原因很简单——对于90%的人来说先能用起来比先搞懂原理重要一百倍。你在用的过程中自然会遇到“为什么这个提示词效果好那个不好”“为什么模型会胡编乱造”这类问题带着这些问题再去补理论效率比干啃教材高得多。下面这张表可以帮你快速定位自己该从哪条路切入路径类型需要的基础典型产出建议学习周期应用使用者无用AI提效的工作流1-2周应用开发者基础编程AI小工具、Agent2-6个月算法工程师数学编程框架微调模型、推理服务1-2年研究者上述全部科研训练论文、新方法3年以上注意不要因为“应用使用者”听起来不够高级就跳过它。我见过不少算法工程师理论功底很强但让他用现成工具快速搭一个demo出来反而不如一个熟练的产品经理。先用起来再往下钻这条路对所有人都成立。2. 零基础起步环境搭建与第一个AI对话程序2.1 你真正需要装的东西没那么多网上很多教程一上来就让你装CUDA、配PyTorch、搞虚拟环境把新手直接劝退。但如果你走的是“应用开发者”路线前期根本不需要本地跑模型。你需要的只是一个能写Python的环境加上一个能调用大模型API的账号。具体来说你需要准备这些东西Python 3.10或以上。别纠结版本3.10到3.12都行。安装的时候记得勾选“Add Python to PATH”这个选项不勾后面会多出很多麻烦。一个代码编辑器。VS Code就够了免费且插件生态好。如果你已经习惯PyCharm也没问题PyCharm的AI插件Fitten Code在代码补全方面确实好用但这不是必须的。一个终端。Windows用PowerShell或者Windows TerminalMac用自带的Terminal就行。一个大模型API Key。国内可以用智谱、通义、豆包、DeepSeek等国外可以用OpenAI、Anthropic等。选一个你方便注册的就行前期花不了几块钱。这里我要特别说一下为什么不建议新手一上来就本地部署模型。本地跑模型需要显卡一张能跑7B模型的显卡至少得RTX 3060 12G起步成本两三千块。而且本地部署涉及环境配置、模型下载、量化、推理框架选择等一系列问题任何一个环节出错都够你折腾一整天。用API的话你只需要一个HTTP请求就能拿到结果把精力集中在“怎么用”而不是“怎么跑”上。2.2 第一个能跑的AI程序装好Python之后打开终端安装OpenAI的SDK大多数国内模型也兼容这个接口格式pip install openai然后新建一个文件叫first_ai.py写入以下代码from openai import OpenAI client OpenAI( api_key你的API_KEY, base_url你的模型服务商提供的base_url ) response client.chat.completions.create( model模型名称, messages[ {role: system, content: 你是一个乐于助人的助手。}, {role: user, content: 用三句话解释什么是大模型。} ] ) print(response.choices[0].message.content)把api_key、base_url、model三个参数替换成你实际使用的服务商信息然后在终端运行python first_ai.py如果一切正常你会看到模型返回的三句话解释。恭喜你你已经完成了从零到一的跨越。这里有个细节值得展开说为什么请求格式里是messages而不是input。有人在用豆包的时候发现它的请求格式是input而不是message这其实是不同厂商对API的封装差异。OpenAI定义的Chat Completions接口用的是messages数组里面包含role和content两个字段role可以是system、user、assistant。国内大部分模型为了兼容OpenAI生态都沿用了这个格式。但豆包在某些版本里用了自己的格式这属于厂商实现差异不影响你理解核心概念——你发给模型的是对话历史模型返回的是下一条回复。2.3 理解对话格式这是最重要的基础概念messages数组的结构看起来简单但它是你后面学一切AI应用开发的基础。我把它拆开讲system消息设定模型的角色和行为边界。比如“你是一个专业的法律顾问只回答法律相关问题”。这条消息通常放在数组第一位模型会优先遵循它。user消息你输入的内容。assistant消息模型之前的回复。多轮对话时你需要把历史回复也放进数组里模型才能“记住”之前聊了什么。很多人以为大模型有记忆其实不是。模型本身是无状态的它不记得你上一句说了什么。你之所以感觉它在跟你连续对话是因为你的程序把历史消息都带上了一起发过去。这就是为什么对话越长消耗的token越多响应也越慢。理解这一点之后你就能明白很多现象为什么刷新页面后AI就“失忆”了为什么长对话到后面AI会“忘记”前面的内容为什么有些AI聊天记录需要你自己保存。这些都不是bug而是大模型工作原理决定的。3. 提示词工程从“能用”到“好用”的关键一跃3.1 提示词不是玄学是有结构的很多人写提示词就是一句话扔过去“帮我写个方案”。然后抱怨AI输出质量差。问题不在AI在于你没给它足够的信息。一个好的提示词通常包含这几个要素角色设定让模型知道它以什么身份回答。比如“你是一个有十年经验的Python后端工程师”。任务描述明确你要它做什么。比如“帮我审查下面这段代码的性能问题”。上下文信息提供必要的背景。比如“这段代码运行在每天处理百万级请求的服务上”。输出格式告诉它你希望结果长什么样。比如“用表格列出问题、原因、修改建议三列”。约束条件限定范围。比如“不要建议引入新的第三方库”。把这五个要素组合起来你的提示词就从“帮我写个方案”变成了你是一个有十年经验的Python后端工程师。帮我审查下面这段代码的性能问题。这段代码运行在每天处理百万级请求的服务上。用表格列出问题、原因、修改建议三列。不要建议引入新的第三方库。后者的输出质量会比前者高出一个数量级。这不是什么秘密技巧就是把需求说清楚而已。你在跟人协作的时候也会这样给的信息越具体对方交付的结果越符合预期。3.2 几个我反复验证有效的提示词技巧技巧一让模型先思考再回答。在提示词里加一句“请先分析问题再给出结论”。这个简单的改动能让模型在推理类任务上的准确率明显提升。原理是模型在生成分析过程的时候相当于在做“思维链”后面的结论会基于前面的分析来生成而不是直接凭直觉蹦出一个答案。技巧二给例子比给描述更有效。如果你希望模型按照某种特定格式输出与其用文字描述格式不如直接给一两个输入输出示例。比如你想让模型把产品评论分类成“好评/中评/差评”与其写“请判断评论的情感倾向”不如写输入这个产品质量很好物流也快 → 输出好评 输入东西一般凑合用 → 输出中评 输入收到就坏了客服还不理人 → 输出差评 输入{待分类的评论} → 输出这种方式叫“少样本提示”在分类、抽取、格式转换类任务上效果非常稳定。技巧三分步骤拆解复杂任务。不要指望一个提示词解决所有问题。如果你要模型帮你写一份行业分析报告拆成“先列大纲→确认大纲→逐节展开→最后润色”四步每步单独对话效果比一次性让它写完整报告好得多。这跟人做事的逻辑是一样的复杂任务拆成子任务每个子任务专注做好。技巧四用分隔符隔开指令和内容。当你把一段文本交给模型处理时用三个引号或者XML标签把内容包起来避免模型把你的指令和内容搞混。比如请把下面三个引号内的文字翻译成英文 {待翻译的内容} 3.3 提示词工程的天花板在哪里提示词工程能解决很多问题但它不是万能的。有些场景下无论你怎么优化提示词效果都到不了可用水平。这时候你需要考虑的是换模型、微调模型、或者用RAG检索增强生成。举个例子如果你要让AI回答关于你公司内部产品文档的问题光靠提示词是不够的因为模型根本没看过你的文档。你需要把文档内容检索出来拼到提示词里一起发给模型。这就是RAG的基本思路。再比如如果你要让模型学会一种非常特定的输出风格而这种风格很难用文字描述清楚那可能需要准备一批训练数据做微调。微调的成本比提示词高得多但在某些场景下是唯一可行的方案。我的建议是先用提示词解决80%的问题剩下20%再考虑其他方案。很多新手一上来就想搞微调、搞Agent结果连基本的提示词都没写明白做出来的东西自然不好用。4. 搭建你的第一个AI Agent从对话到行动4.1 Agent和普通对话的本质区别普通对话是你问一句它答一句Agent是你给它一个目标它自己决定怎么一步步完成。比如你问“今天北京天气怎么样”这是对话。你说“帮我规划一个北京三日游行程要考虑天气、交通和我的预算”Agent会自己去查天气、查景点、查交通、算预算最后给你一个完整方案。Agent的核心能力是调用工具。大模型本身只能生成文字它不能上网、不能查数据库、不能发邮件。但如果你给它定义好工具接口它就能在需要的时候调用这些工具。比如你定义一个get_weather(city)函数模型在需要天气信息时会输出一个调用请求你的程序执行这个函数把结果返回给模型模型再继续处理。4.2 用不到100行代码搭一个能用的Agent下面是一个最小可用的Agent实现框架我用的是OpenAI的function calling能力import json from openai import OpenAI client OpenAI(api_key你的KEY, base_url你的BASE_URL) # 定义工具 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ] # 模拟工具执行 def get_weather(city): # 实际项目中这里调用真实天气API return f{city}今天晴气温15-25度适合出行。 # Agent主循环 def run_agent(user_input): messages [{role: user, content: user_input}] while True: response client.chat.completions.create( model模型名称, messagesmessages, toolstools ) msg response.choices[0].message # 如果模型没有调用工具直接返回结果 if not msg.tool_calls: return msg.content # 处理工具调用 messages.append(msg) for tool_call in msg.tool_calls: func_name tool_call.function.name args json.loads(tool_call.function.arguments) if func_name get_weather: result get_weather(args[city]) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) # 测试 print(run_agent(帮我查一下北京今天的天气))这段代码的核心逻辑是一个循环模型判断是否需要调用工具→如果需要就执行工具→把结果返回给模型→模型继续判断。直到模型认为不需要再调用工具了就输出最终结果。4.3 Agent开发中最容易踩的坑坑一工具描述写得太模糊。模型是根据你的description来决定什么时候调用工具的。如果你写“查询天气”模型可能在你问“今天适合穿什么”的时候也去调天气工具。更好的写法是“当用户明确询问某个城市的天气状况时调用此工具”。坑二没有设置最大循环次数。上面的代码里while True是个隐患。如果模型一直觉得需要调用工具程序会无限循环下去。实际项目中一定要加一个最大迭代次数比如10次超过就强制退出。坑三工具执行失败没有兜底。真实环境中API可能超时、可能返回错误。如果你直接把异常抛出去整个Agent就崩了。正确的做法是捕获异常把错误信息返回给模型让模型决定是重试还是换一种方式回答。坑四忽略token消耗。Agent每调用一次工具对话历史就增长一截。多轮工具调用下来token消耗可能比你想象的大得多。在成本敏感的场景下需要定期清理或压缩历史消息。实操心得我建议新手先用“假工具”练手也就是工具函数直接返回硬编码的结果。这样你可以专注于理解Agent的控制流程而不用被API调试分散精力。等流程跑通了再把假工具替换成真实调用。5. 常见问题与排查技巧实录5.1 API调用类问题问题现象可能原因排查方法返回401错误API Key无效或过期检查Key是否复制完整是否有多余空格返回429错误请求频率超限或余额不足查看服务商控制台的用量和限额返回400错误请求格式不对检查messages格式、model名称是否正确连接超时网络问题或base_url错误确认base_url是否包含正确的路径前缀返回内容为空模型名称错误或参数冲突换一个模型名称试试检查temperature等参数5.2 输出质量类问题问题模型总是胡编乱造。这是大模型的“幻觉”问题目前没有根治方法。缓解手段包括在提示词里明确要求“如果不确定就说不确定”提供参考资料让模型基于资料回答降低temperature参数减少随机性。问题模型不遵循输出格式。首先检查你的格式要求是否足够明确。如果写了“用JSON输出”但模型还是输出自然语言试试在提示词末尾加一句“只输出JSON不要输出任何其他内容”。如果还不行考虑用function calling或者JSON mode来强制格式。问题多轮对话后模型忘记前面的内容。这是正常的因为模型本身没有记忆。检查你的程序是否把历史消息都带上了。如果带上了但还是忘记可能是对话太长超出了模型的上下文窗口需要考虑截断历史或者做摘要压缩。问题同样的提示词每次输出差异很大。这是temperature参数在起作用。temperature越高输出越随机。如果你需要稳定的输出把temperature设成0或者一个很小的值。但要注意即使temperature0也不能保证每次输出完全一致因为底层还有采样随机性。5.3 开发工具类问题VS Code里怎么调试AI程序用launch.json配置调试环境在代码里打上断点按F5启动调试。重点观察messages数组在每一步的变化这是排查Agent类问题最有效的方法。PyCharm有什么好用的AI插件Fitten Code在代码补全和生成注释方面表现不错安装后在设置里配置好API Key就能用。但要注意插件生成的代码一定要自己审查不要直接复制到生产环境。怎么管理API Key才安全绝对不要把Key硬编码在代码里然后提交到代码仓库。用.env文件加python-dotenv库来管理把.env加到.gitignore里。这是最基本的操作但每年都有无数人因为把Key传到公开仓库而被盗刷。5.4 学习路径类问题数学不好能学AI吗走应用开发路线的话高中数学基础就够了。你不需要会推导梯度下降但需要理解“模型是通过大量例子来学习规律”这个直觉。等你真正遇到需要理解原理的场景时再针对性补数学效率更高。英语不好能学AI吗能。大部分主流文档都有中文版或者中文社区翻译。但最新的论文和部分工具文档还是英文为主所以至少要做到能借助翻译工具读懂技术文档。这不是门槛是慢慢积累的过程。要不要报培训班我的观点是入门阶段不需要。网上免费资源足够你走到“能搭建简单应用”的水平。等你到了需要系统提升算法能力的阶段再考虑付费课程或者系统学习。前期花大价钱报班大概率是浪费钱。学多久能做出东西如果你每天能投入1-2小时按照这篇文章的路径走一周内能跑通第一个AI程序一个月内能搭建一个带工具调用的Agent三个月内能做出一个解决自己实际问题的AI小工具。这个速度不算快但足够扎实。6. 从玩具到工具把AI嵌入你的真实工作流6.1 找到你的第一个真实场景学AI最怕的就是一直在做“玩具项目”——今天写个聊天机器人明天写个翻译工具做完就扔没有积累。真正让你进步的是找到一个你日常工作中真实存在的痛点用AI去解决它。怎么找拿一张纸把你每天重复做的事情列出来。哪些事情是“有固定流程但需要动脑子”的哪些事情是“需要处理大量文本但不需要创造性”的哪些事情是“需要查资料然后整合”的这些就是AI最擅长的地方。举几个我实际用AI解决过的场景周报生成把一周的git commit记录和会议纪要扔给AI让它生成结构化的周报。省下来的时间大概每周半小时。代码审查把diff发给AI让它先过一遍标出潜在问题。我再针对它标出的地方重点看。效率提升明显尤其是排查边界条件的时候。文档问答把产品文档做向量化存储搭一个简单的RAG问答。新同事问问题的时候直接查不用每次都来问我。数据清洗把格式混乱的Excel数据发给AI让它写清洗脚本。比我自己写pandas快得多而且它考虑的情况比我全面。6.2 多AI协作的实践思路一个人用多个AI工具协作效率比只用一个高。我的做法是写代码用专门的编程助手比如Codex或者Fitten Code它们在代码补全和调试上比通用聊天模型强。写文档用通用聊天模型因为它们对自然语言的理解更细腻。查资料用带联网能力的AI避免模型胡编乱造。做设计用专门的图像生成工具通用模型在图像生成上不如专用工具。关键不是用多少个工具而是知道每个工具的边界在哪里。通用模型什么都能聊但什么都不精。专用工具在特定任务上效果好但换个场景就不行了。组合使用各取所长。6.3 持续学习的资源和方法AI领域变化太快今天学的东西可能三个月后就过时了。所以比“学什么”更重要的是“怎么学”。我的方法是跟人不跟技术。找几个你认可的技术博主或者开源项目维护者关注他们的动态。他们发新东西你就跟着看比自己漫无目的地刷信息流高效得多。另外动手比看书重要。看到一个新概念不要只停留在“我知道了”要动手写几行代码验证一下。比如你看到“function calling”这个词不要只记住定义去写一个能调用工具的demo。写的过程中你会遇到各种文档里没写的问题解决这些问题才是真正的学习。最后输出倒逼输入。把你学到的东西写成笔记、博客、或者分享给同事。教别人的过程会逼你把模糊的地方搞清楚。我很多次都是在写文章的时候才发现自己对某个概念的理解有漏洞然后回头去补。6.4 关于AI学习的一些个人体会我刚开始学AI的时候总想着要把所有基础都打牢再动手。结果花了大量时间看视频、看教材真正写代码的时间不到十分之一。后来我换了个方式先定一个具体目标比如“做一个能自动整理下载文件夹的脚本”然后缺什么学什么。遇到不会的就查查完立刻用上。这种方式学得快得多而且学到的都是真正用得上的东西。另一个体会是不要追求完美方案。我见过很多人卡在“选哪个模型”“用哪个框架”“要不要微调”这些问题上纠结了好几天代码一行没写。其实对于大部分场景先用最简单的方案跑起来跑通之后再优化。你跑通一个粗糙的版本比在脑子里设计一个完美方案有价值得多。还有一点AI不是万能的知道它不能做什么和知道它能做什么一样重要。模型不擅长精确计算、不擅长实时信息、不擅长需要严格逻辑推理的长链条任务。遇到这些场景该用传统方法就用传统方法不要硬套AI。7. 进阶方向当你跑通第一个项目之后7.1 值得深入的技术方向如果你已经能熟练调用API、写提示词、搭简单Agent接下来有几个方向可以深入RAG检索增强生成让AI基于你的私有文档回答问题。核心技术点包括文档切分、向量化、相似度检索、重排序。这是目前企业落地最多的AI应用形态需求量大技术栈成熟。模型微调当提示词和RAG都解决不了问题时考虑微调。主流方法有LoRA、QLoRA等可以在消费级显卡上微调7B级别的模型。微调的关键不是技术而是数据——你有没有足够多、足够好的训练数据。多Agent协作让多个Agent分工合作完成复杂任务。比如一个Agent负责规划一个负责执行一个负责审查。这个方向目前还在早期但潜力很大。AI应用架构如何设计一个高可用、低延迟、成本可控的AI应用。涉及缓存策略、降级方案、并发处理、成本监控等工程问题。7.2 不同职业的AI结合点AI不是独立的技术它需要跟具体行业结合才能发挥价值。不同职业的人可以把AI用在不同的地方程序员代码生成、代码审查、调试辅助、文档生成、测试用例生成。产品经理需求分析、竞品调研、原型设计、用户反馈分析。设计师素材生成、风格探索、设计稿转代码。运营文案生成、数据分析、用户分层、活动策划。教师课件制作、题目生成、作业批改、个性化辅导。律师合同审查、案例检索、法律文书起草。医生文献检索、病历整理、辅助诊断需严格合规。找到你的专业领域和AI的结合点比单纯学AI技术更有价值。因为技术会过时但行业知识不会。7.3 保持竞争力的核心能力AI工具会越来越强很多现在需要人工做的事情以后可能一键就能完成。在这种趋势下什么能力是真正重要的定义问题的能力。AI能回答问题但不知道什么问题值得问。能准确定义问题、拆解问题的人永远比只会执行的人有价值。判断质量的能力。AI能生成大量内容但判断哪个内容好、哪个内容有问题需要人的审美和经验。这种判断力来自大量实践和反馈不是看几篇教程就能获得的。整合资源的能力。AI只是工具箱里的一把锤子真正解决问题需要组合使用多种工具、协调多方资源。这种整合能力是AI替代不了的。持续学习的能力。AI领域变化快今天的热门工具明天可能就没人用了。保持好奇心保持动手习惯比掌握任何具体技术都重要。我在实际使用中的一个深刻体会是AI放大了人与人之间的差距。会用AI的人效率翻倍不会用的人还在手动搬砖。但这个差距不是天赋决定的是愿不愿意花时间学、愿不愿意动手试决定的。你现在开始就已经比大多数人领先了。
