刚接触AI开发的同学十个里有八个第一周就想放弃原因不是模型太复杂而是卡在两个最基础的地方环境装不上、装上了又不知道怎么跟AI有效对话。我见过太多人把时间浪费在“pip install报错”“模型输出乱七八糟”这些和核心目标无关的事情上最后得出的结论是“我不适合学AI”。这其实是方法问题不是能力问题。这一阶段的项目标题很直白环境配置与初体验提示词Prompt与模板。说白了就是先解决两个拦路虎——一是把Python、Node.js、VSCode这一整套开发环境跑起来二是学会用规范的Prompt去驱动大模型干活并且把好用的Prompt沉淀成模板避免每次对话都从零开始。这两个能力是所有后续阶段模型微调、部署、应用搭建的底层基础也是我在带新人时反复强调的“先跑通、再优化、后深化”思路的最前置环节。这篇文章就是我在第一阶段实操中的完整记录包括选型理由、具体步骤、踩坑清单以及可以直接抄走的Prompt模板。1. 项目整体思路环境配置和Prompt为什么要放在同一个阶段很多人会疑惑环境配置是纯技术活Prompt是对话技巧这两个东西怎么就凑到一起了我的理解是它们本质上都是“人跟机器打交道”的入门课而且互为前提。1.1 环境配置是安静的地基没有它一切为零环境配置这个事说难不难说简单也不简单。难点不在“安装软件”本身而在于你需要理解一套相互依赖的逻辑关系语言解释器管什么、包管理器装什么、虚拟环境隔离什么、IDE又负责什么。这四个东西在初期经常被混杂在一起一旦出了问题新手很难判断是哪一层坏了。我见过最常见的场景是一个新人装好了Python也装好了VSCode却在命令行里敲python发现提示“不是内部或外部命令”然后开始怀疑人生。这个问题的本质只是“环境变量没有配置”但如果没有建立起“环境变量是操作系统找到程序的路径索引”这个概念就很难快速定位问题。所以这一阶段的环境配置重点不在于“装完就完”而在于理解每个配置动作背后的逻辑这样之后无论是装PyTorch还是跑Node脚本你都能举一反三。1.2 Prompt是人与模型之间的翻译层环境的目的是让模型能跑起来但模型能跑起来不等于它能把活干好。大模型的输出质量极大程度上取决于你给它的输入质量也就是Prompt。这个阶段把Prompt的“初体验”放进来就是要让你在第一天就建立起一个意识跟AI协作本质上是在做一种“需求翻译”。我之前遇到过不少已经跑通环境的人直接用一句“给我写个爬虫”就往模型里扔得到的回答要么过于泛泛、要么代码漏洞百出。这不是模型蠢是你给的需求里面缺少约束条件、缺少上下文、缺少输出格式要求。学会把模糊的想法转成结构化的指令这个能力一旦建立起来后面不管接什么模型、做什么任务效率都能翻倍。1.3 本阶段的闭环验收标准我觉得一个阶段的学习不能糊里糊涂地过去必须有一个可以自检的验收标准。第一阶段的验收我定了三条本地能从命令行正常启动Python解释器并能通过pip安装一个第三方包能写出一个包含角色、指令、上下文、输出格式四要素的Prompt能把自己调好的Prompt整理成模板并且转换到新任务时能在五分钟内改造复用。这三条都做到第一阶段就算扎实通过了。下面的内容就是我按这个标准一步步落地的全过程每一步都附上了当时的做法和为什么要这么做的思考。2. 环境配置实操记录从选型到验证2.1 环境选型为什么选定Python Node.js VSCode的组合环境配置的第一步不是动手装东西而是想清楚要装什么。我最终选定的是Python 3.10、Node.js 18 LTS和VSCode这个组合背后有三个具体考虑。第一是生态匹配度。目前主流的AI开发框架、微调工具、数据处理库绝大多数都是基于Python的所以Python是必须的。而很多前端展示工具、CLI命令行工具、自动化插件又是Node.js生态里的只装了Python后面做应用编排时会发现钳制很多。Node.js 18 LTS长期支持版之所以没选最新的20或21是因为LTS版本在稳定性和第三方库兼容性上都要好得多这是用时间验证过的最稳妥选择。第二是IDE的性价比。我推荐VSCode而不是PyCharm原因很简单VSCode足够轻量启动快再通过安装Python、Pylance、Code Runner这几个插件就能获得接近专业IDE的核心体验。同时VSCode对多语言的支持是统一的今天写Python明天写TypeScript不需要切换工具心智负担小很多。第三是虚拟环境这个“隔离舱”。同一台机器上不同项目对依赖包的版本要求经常冲突。比如项目A需要numpy 1.24项目B可能只需要numpy 1.19如果直接全局安装就会产生“装了这个坏了那个”的问题。虚拟环境就是用来创建互相隔离的Python空间的这个习惯我从第一阶段就开始强制建立后面跑微调、部署模型时受益匪浅。基于常见的工程实践这里补充一个选型细节Windows用户建议在终端里使用PowerShellmacOS用户建议配合Homebrew管理包这两个底子打好了后面会顺很多。2.2 Python安装与环境变量配置的完整步骤环境配置我按“安装解释器 → 配置环境变量 → 验证可用 → 建立虚拟环境”的顺序来。先说Python本身的安装。我使用的是官方网站下载的Python 3.10安装包这里不建议用Windows商店版本或各种“绿色版”因为它们的路径结构不标准容易在后续配置中出幺蛾子。安装时有一个关键开关一定要勾选“Add Python to PATH”这个选项会把Python解释器的路径写入系统环境变量相当于告诉操作系统“你在任意目录敲python都能找到解释器”。很多新手报错“python不是内部或外部命令”就是因为在这一步偷懒或没注意。安装完成后我会习惯性用一组命令做验证。打开终端依次执行python --version pip --version where python # Windows下查看Python实际安装路径 python -m pip install --upgrade pip执行完第一步应该能看到Python版本号第二步能看到pip版本号第三步能看到完整的安装路径。如果where python的结果为空说明环境变量没生效需要手动到“系统属性 → 环境变量 → Path”里把Python的安装目录和Scripts目录加进去。注意改完环境变量之后已经打开的终端窗口不会自动刷新必须重新开一个终端再执行验证命令这是我看到最多人忽略的细节。接着创建虚拟环境。我建议把虚拟环境统一放在项目根目录下的.venv文件夹里这样一眼就能看到而且删除也方便。然后激活虚拟环境python -m venv .venv .venv\Scripts\activate # Windows系统 source .venv/bin/activate # macOS/Linux系统激活成功后命令行提示符前面会出现一个(.venv)前缀这就是虚拟环境生效的信号。这个时候再用pip装任何包都只会装进当前项目的虚拟环境里不会污染全局也不会干扰其他项目。2.3 VSCode配置与Python解释器联动VSCode本身是个编辑器不装插件的话它跟Python一点关系都没有。所以装完VSCode之后要做的第一件事是去扩展市场装四个插件Python微软官方提供、Pylance做代码补全和类型检查、Code Runner支持右键直接运行代码片段、以及Prettier统一代码格式。插件装好之后还有一个关键动作就是让VSCode识别当前项目用的是哪个解释器。这一步经常被忽略导致代码能写、能高亮但一运行就报“找不到模块”或者用了全局的Python环境。正确的做法是用VSCode打开项目根目录然后按下快捷键CtrlShiftP输入“Python: Select Interpreter”在弹出的列表里选择你刚创建的虚拟环境对应的解释器路径。这个操作只需要做一次VSCode会在项目根目录自动生成一个.vscode/settings.json配置文件把解释器路径记录在案。配置完成后再一次验证完整链路在项目根目录新建一个test.py写入一行代码import sys print(sys.executable) print(Environment setup success)右键选择“Run Python File in Terminal”。如果第一行打印出来的路径指向你项目里的.venv文件夹说明解释器选择成功如果第二行文字正常输出了说明整个链路已经打通。这一步看起来简单但我可以负责任地说它排查掉了后续一半以上的“环境类”疑难杂症。2.4 Node.js安装与环境适配Node.js的安装相对Python要省心一些。从官网下载LTS版本的安装包后一路Next安装即可。安装完同样要做验证node --version npm --version代码运行前还需要初始化项目结构。在一个新项目目录里执行npm init -y会自动生成一个package.json文件这个文件相当于Node项目的“身份证”。之后安装任何前端依赖或者命令行工具都执行npm install 包名依赖列表会记录在package.json里。Node.js环境常见的坑和Python是类似的还是环境变量问题。但Nodejs官方安装包一般会自动写入Path所以发生率比Python低。如果npm命令提示找不到就去环境变量里检查Nodejs的安装目录是否在Path中。做完这一步整个AI开发的基础运行底座就具备了。3. 初体验Prompt先学会把需求“说清楚”环境准备好之后我并没有立刻带着大家去跑各种复杂的模型而是先停下来花时间把Prompt这个概念拆透。原因很简单你工具箱再齐全不会用也是白搭。3.1 提示词的本质一段约束条件而不是一句魔法咒语很多初学者的误区是把Prompt当成“咒语”——以为找到某个神奇句式就能让AI开窍。实际上Prompt不是咒语而是一段“需求约束文本”。它的作用是让模型在你给定的信息边界内尽量稳定地输出你想要的东西。我常用一个生活化的类比来解释你去餐厅点菜如果只说“来点吃的”厨师只能凭感觉给你做你可能不满意。但如果你说“我要一份少油少盐、不放香菜、微辣、分量够两人吃的番茄炒蛋盖饭”那么出来的结果大概率是符合你预期的。Prompt就是这份“点单说明”。它每一句话都在压缩答案的空间让模型在更明确的范围内发挥。这也是为什么我在前面强调“初体验”——第一阶段你不需要掌握多高级的Prompt技巧比如思维链、自洽性检查那些只需要建立“用约束条件说话”这个思维习惯。这个习惯一旦养成后面不管模型多强大你都能驾驭它。3.2 一条完整Prompt的四个核心要素我自己在实操中总结出一个四要素结构基本可以覆盖绝大多数场景角色、指令、上下文、输出格式。这四个要素不一定要全部出现但缺哪个对应的质量就会下降。第一个是角色Role给模型一个身份设定。比如“你是一名资深Python后端工程师”这句话的作用是让模型调用和这个身份匹配的知识体系和语言风格。没有角色设定的Prompt输出往往偏通用教科书味加了角色设定之后输出会明显更贴实际。第二个是指令Instruction这是Prompt的核心动作也就是你要模型具体做什么。指令的关键是动词明确比如“写一段”“解释一下”“对比分析”“转换格式”。很多含糊的Prompt就是因为指令动词不清晰“帮我看下这个”“处理一下”这种说法模型根本无法判断动作边界。第三个是上下文Context为模型提供完成任务所需的背景材料或已知条件。比如你在让模型写代码时附上现有的代码片段、使用的框架版本、目标平台等信息它给出的代码就能贴合你的项目而不是泛泛的示例。这个要素最容易被初学者忽略但副作用也最大——没有上下文模型就只能猜而它猜的结果往往与你的实际场景偏差甚远。第四个是输出格式Output Format告诉模型用什么形式呈现结果。比如“用Markdown输出”“用JSON返回”“分步骤说明”“控制在200字以内”。别小看这个要素它是把AI输出从“能看”变“能用”的关键一步。尤其是做自动化流程时如果把格式约定清楚你甚至可以直接把模型输出对接给下一个程序处理。3.3 一个Prompt从模糊到清晰的迭代全过程光讲理论不容易落地我拿一个真实案例演示迭代过程。第一版Prompt是帮我写个Python脚本读取Excel。这个Prompt的问题很明显没有角色、指令模糊读取之后要做什么、没有上下文Excel在哪有什么结构、没有输出格式是要代码还是要说明文字。所以我把它迭代成你是一名熟练使用Python的数据处理工程师。 请编写一个Python脚本使用pandas库读取本地/data/销售数据.xlsx文件 然后完成以下处理删除“金额”列中的空值行、按“日期”列升序排序、 统计每日销售额总和。最后将结果保存为同目录下的汇总.csv文件。 环境Python 3.10pandas已安装。请直接输出完整可运行的代码 并在代码中用注释标注每一步的作用。对比一下这一版补充了角色、具体指令、上下文、输出格式四个要素。同样是“读取Excel”但这一版模型基本不需要额外追问就能产出直接可用的代码。我建议把这个迭代过程记下来以后写Prompt之前先问自己四个问题我是谁我要模型做什么有什么背景信息结果用什么形式给我这四个问题一过Prompt基本差不了。4. 模板化把优质Prompt沉淀成可复用的资产4.1 为什么要做模板不用每次对话都“重新发明轮子”当你能写出高质量的Prompt之后很快会面临一个新问题很多需求量其实是重复的。比如你经常要做竞品分析、写周报、做代码审查每次需求的结构都差不多只是具体内容变了。如果每次都从零开始写Prompt不仅效率低而且质量还不稳定。这时候就该引入模板思维。我的理解是Prompt模板就是“把一段优质Prompt中不变的框架固定下来把会变化的局部内容替换成占位符”下次用时只需填充占位符就能快速生成一条完整可用的Prompt。这跟软件开发里的设计模式是同一个思路提取共性、抽象可变部分、提高复用效率。4.2 模板的通用结构与变量化设计一个可复用的模板结构上不宜太复杂。我推荐的通用结构是五个槽位身份定义、任务描述、输入变量、约束条件、输出要求。对应到模板写法一般会使用“{{变量名}}”这样的占位符来标识可变内容。举个例子一个通用的“代码审查”模板可以这样设计你是一名精通{{编程语言}}的资深开发工程师。 请审查以下代码找出潜在的Bug、安全隐患、性能问题和风格问题。 代码内容如下 {{代码片段}} 输出要求 1. 按“问题类型 | 代码行号 | 问题描述 | 修改建议”的表格格式输出 2. 如果没有发现问题请明确说明“未发现问题” 3. 不要修改代码只提出建议。这个模板中只有“编程语言”和“代码片段”两个槽位是每次要变的其他内容都可以不动。真正好用的模板应该让使用者在填写占位符时只需要关注业务本身而不需要重新思考Prompt结构。这里要补充一个操作细节不要把模板写得太“死”。我见过有些初学者把模板里的每句话都固定死结果遇到稍微不同的场景就套不进去反而放弃了模板思路。好的模板应该是“骨架固定血肉灵活”——核心规则和输出要求固定但任务描述和上下文可以酌情调整。4.3 三个现场可用的模板示例我把自己在过去半个月高频使用的三个模板放在这里你可以直接复制改造。第一个是“内容改写”模板适合做公众号文章、邮件、文案润色扮演一名资深中文内容编辑。请改写下面这段文字要求 1. 保持原意不变 2. 将语气调整为专业且易读 3. 把长句拆分成短句删除口头语和废话 4. 输出改写前后的对比并用一句话说明主要改动点。 原文内容 {{原文}}第二个是“学习总结”模板适合看完教程或文档后快速提炼知识点扮演一名经验丰富的技术导师。针对下面提供的学习材料 输出一份简洁的学习总结包括 1. 核心概念用200字以内的白话解释清楚 2. 关键步骤以有序列表形式列出操作流程 3. 易错点结合材料内容指出最常见的使用误区 4. 一个用于自测的小练习。 学习材料 {{材料内容}}第三个是“代码解释”模板适合理解一段晦涩代码你是一名{{编程语言}}专家。请逐行解读以下代码的执行逻辑 说明每个关键部分的作用并指出这段代码存在的设计问题与改进建议。 请用“代码行号 普通语言解释”的形式输出。 代码 {{代码}}这三个模板的共性是角色明确、指令单一、输出结构固定、留有变量槽位。你没发现它们读起来都很“不AI”因为角色和输出要求压制了模型那种空洞的“AI腔调”。这也是我推荐优先从“扮演角色限定输出格式”入手设计模板的原因见效最快。5. 常见问题与排查技巧实录这一阶段我在实操中踩了不少坑也帮其他新手排查过不少问题整理成了一份速查表。每个问题都是真实发生过的场景解决思路也尽量附上了判断依据。5.1 环境配置类问题速查问题现象可能原因排查与解决命令行提示“python不是内部或外部命令”Python未加入PATH检查系统环境变量PATH是否包含Python安装目录与Scripts目录修改后重启终端pip安装包时提示“externally-managed-environment”新版本Python对全局安装的限制优先使用虚拟环境在虚拟环境中安装第三方包不要绕过全局限制VSCode运行代码时找不到已安装的模块VSCode选择了错误解释器CtrlShiftP选择正确的虚拟环境解释器确认.vscode/settings.json指向正确路径终端执行python和VSCode中Python版本不一致全局与虚拟环境并存导致的混乱统一用where python / which python查看实际路径手动禁用不需要的环境npm安装卡在sill idealtree长时间无响应网络原因或npm镜像异常常见做法是更换npm镜像源常在文档中建议使用国内镜像加速但无论何种镜像都应从官方渠道获取地址除了表格里的问题我还要特别强调一个习惯永远不要在一个已经使用的终端窗口里改完内容就继续执行。环境变量、Path这些配置只有在“新开的终端”里才会被重新读取。我见过太多人改完配置后不重启终端反复报同样的错走了大半天弯路。5.2 Prompt使用中的“输出异常”情况Prompt使用中最大的意外是突然遇到“无效提示词”或者“提示词被标记为违规”这类报错。这类问题首次出现时确实很打击人但绝大多数情况下是内容触发了模型的合规触发词库。遇到这种情况首先不要慌也不要试图用各种去敏感化的写法去绕过限制——正确的处理方式是检查输入内容里是否包含触发词改用更中性、更客观的表达。我自己的处理流程是三步第一步把报错原文复制下来确认是内容风险报错还是格式报错第二步如果是风险类报错审视自己的原文去掉可能触发限制的词汇重新组织句式第三步如果是格式类报错检查是否超出了模型支持的输入长度或者是否有特殊字符破坏了模板结构。记住一个原则提示词安全防护是底线作为使用者应当在合规的范围内充分利用模型的表达能力而不是想方设法绕过规则。还有一个常见但没人讲的现象就是Prompt不生效但也不报错。比如你让它输出JSON它给了大段废话你让它扮演角色它还是一副通用助手的口气。这种“软失效”的排查思路是逐项删减要素验证到底是哪部分没起作用。先用最简的指令测试再逐步加回上下文和输出格式。多半是上下文太长干扰了模型指令的优先级或者输出格式的描述过于模糊。5.3 模板设计与复用的典型问题最后聊几个模板使用中的典型问题都是实际带教中反复出现的。第一个问题模板写得太复杂导致填写成本反而比直接写Prompt还高。解决方案是控制模板长度一个模板的核心规则不要超过三条其余内容都归为“可选项”。你不需要一个百科全书式的模板你只需要一个能覆盖80%需求的标准框架。第二个问题模板中占位符的命名不规范。有人用“内容1”“填这里”这种描述结果模板放了一个月自己都看不懂。我建议用“{{输入文本}}”“{{目标语言}}”这样语义明确的命名而且在模板底部附加一个使用说明区块写清每个占位符应该填什么、格式要求是什么。第三个问题模板复用后输出质量下降。这通常不是模板本身的问题而是模板缺少“自适应”能力。不同场景下模型所需的角色设定和约束条件是不同的如果固执地使用一套话术处理所有任务自然会碰到表现不好的情况。我的习惯是给每个模板做“分支版本”比如同一个代码审查模板针对Python项目和前端项目各保留一个变体改动不需要大只调整角色设定和关注点即可。这些经验一点一点积累起来你会发现第一阶段的环境配置和模板初体验其实是在为自己打造一套可复用的工作方法。我在实际使用中最大的体会是环境配置这件事一次性投入两到三个小时把事情做扎实绝对比每次项目开始时磨磨蹭蹭配环境、配完还到处报错要划算得多。很多时候“慢就是快”这个阶段走得越稳后面做Prompt工程、做模型微调时就越省心。