最近这两年被问得最多的一个问题就是AI到底怎么学才能真的上手。我见过太多朋友兴致勃勃地下载了一堆教程今天学点提示词技巧明天看一段大模型原理后天又跑去研究某个开源框架折腾两三个月真正要做一个能用的东西时还是无从下手。我自己也走过这段弯路后来才慢慢想明白一件事ai-engineering-from-scratch 真正要解决的不是怎么理解注意力机制也不是怎么训一个自己的模型而是怎么把 AI 能力稳定地、可控地、可维护地交付成一个实际在跑的系统。换句话说engineering 的重点在于工程而不是模型研究。这篇文章我想以个人经验的形式聊一聊从零开始做 AI 应用开发时真正值得投入精力的几个方向prompt engineering 提示工程怎么从摸索变成流程、AI Agent 工作流怎么从 demo 变成可用系统、本地部署 AI 的成本和边界怎么算以及我在实际项目里踩过的一些坑。如果你是想进入 AI 应用领域但还没找到路线的开发者、测试或产品同学这篇内容应该能帮你省下不少试错的时间。1. AI工程不是训练模型而是交付稳定能力1.1 研究、开发、工程是三种不同的活很多新人会把AI工程师和算法工程师混在一起其实在大多数业务场景里两者干的完全是不同的事。算法/研究关注模型结构、训练方法、效果指标目标是让模型在某项能力上达到更好。应用开发关注 API 怎么调、数据怎么传、结果怎么解析目标是让模型能力跑进产品里。AI工程关注稳定性、成本、可观测性、回归测试、权限与合规目标是让 AI 能力持续可用、可控、可修。打个比方研究好比内燃机实验室里改进缸内燃烧效率开发好比把发动机装进车架而工程则要解决整车在不同路况下都能平稳跑、该保养时能检测、出故障时能定位。大多数公司真正缺的不是发动机狂热爱好者而是能把整辆车造好的人。所以对多数想入行的人来说从工程视角切入 AI比从算法视角切入更快、更稳、也更贴近真实商业价值。1.2 从零开始也要分层踩楼梯从零开始这四个字很多人理解歪了。一说到零基础就觉得该从线性代数、反向传播、Transformer论文读起。说实话如果你的目标是做 AI 应用这条路线很长而且中途很容易放弃。我比较推荐按应用采购 → 框架理解 → 深度定制三层来走应用级调用成熟大模型 API学会设计提示词、处理结构化输出、管理上下文做一个能跑的小应用。框架级掌握 Agent 工作流、RAG 检索、多工具调度、测评与方法搭建可扩展的应用体系。研究级如果工作需要再去深入微调、对齐、压缩甚至预训练细节。初学者应该先把第一层走通做一个真实的、别人愿意用的东西。一个跑在本地的小工具胜过十个只存在于收藏夹的教程。这也是我写这类实践分享时最想强调的一点先把交付闭环打通后面所有深层次学习才有意义。2. prompt engineering 的工程化改造从玄学到流程2.1 提示词为什么值得当成工程对待提示词看起来只是跟模型说句话但在一套稳定系统里它是需求说明书、接口契约、行为约束的合体。一个不稳定的提示词会让整个应用的表现跟着飘。把提示词当作工程资产来管理至少要做三件事版本化提示词和代码一样要入库、要记录修改历史。我在项目里会把每个场景的提示词单独写成文本或模板文件跟代码一起提交。变量化把用户输入、业务参数、历史记录这些可变部分剥离出来做成模板占位符不要在运行时用字符串拼接硬塞。回归集准备一组固定的测试样本每次改完提示词就跑一遍对比输出质量和格式防止修好一个 case 崩掉一片 case。很多人改提示词靠感觉这次加一句请更认真下次加一句如果不知道就说不知道效果时好时坏。真正该做的是把每一次改动明确成一个假设我加了什么约束它应该影响哪些样本这些样本在回归集里有没有覆盖有了这套思维提示词就从玄学变成了实验。2.2 一套够用的提示词模板结构我调过不少模型总结出一套比较通用的提示词骨架新手可以直接抄[系统角色] 你是一名资深的XX领域助手擅长处理XX类任务。 [任务目标] 根据给定的输入完成XX目标输出XX格式。 [输入约束] 只使用输入中提供的信息不要臆测信息不足时明确说明。 [处理步骤] 先分析再判断最后给出答案分析过程不写入最终输出。 [输出格式] 严格输出JSON字段包括resultstring、confidencenumber、reasonstring。 [反例警示] 禁止输出空字段禁止编造数据禁止在JSON里输出markdown代码块标记。这套结构的核心逻辑是先给模型身份和目标再给边界和路径最后卡死输出格式。每一步都在降低不确定性。身份设定影响语气和知识框架任务目标让模型知道要做什么输入约束减少幻觉处理步骤提升推理质量输出格式方便程序解析。实际测试中我最常踩的坑是输出格式这一项写得太随便。模型返回的内容里偶尔会带json 或 字段名多一个引号解析直接报错。所以我在项目里不会只靠提示词约束格式还会在代码里做一层兜底校验。2.3 用代码强制格式而不是用嘴请求格式下面是一段我常用的调用片段加了格式校验与重试逻辑保证返回结果能稳稳落到 JSON 里import json import re from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keylocal) def ask_structured(prompt: str, schema_keys: list[str]) - dict: for attempt in range(3): resp client.chat.completions.create( modelqwen2.5-7b-instruct, messages[ {role: system, content: f只输出JSON字段必须包含{schema_keys}不要输出markdown代码块。}, {role: user, content: prompt}, ], temperature0.2, ) text resp.choices[0].message.content.strip() # 去掉可能包裹的代码块 text re.sub(r^(?:json)?|$, , text).strip() try: data json.loads(text) missing [k for k in schema_keys if k not in data] if not missing: return data except json.JSONDecodeError: continue raise RuntimeError(模型输出连续三次不符合格式要求)这段代码做了三件重要的事用 schema_keys 做字段级校验、用重试容忍模型偶发抽风、用正则把 markdown 包裹剥掉。提示词负责引导代码负责兜底两者配合才是工程做法。只靠其中一环早晚要出问题。3. 从单次调用到Agent工作流把能力编排成流程3.1 什么场景真正需要 Agent并不是所有任务都要上 Agent。如果一个任务用一次提示词调用能完成硬套 Agent 只会增加延迟、成本和故障点。我判断是否值得做 Agent一般看三个信号多步骤任务没法一次回答完成需要先查资料、再分析、再汇总。工具依赖需要调用外部 API、数据库、计算器或搜索接口才能拿到关键信息。路径不确定预先写不出固定脚本需要模型根据中间结果动态决定下一步。比如做一个小型竞品分析助手用户问对比 A 产品和 B 产品最近一周的公开评价合理的做法是先检索多个来源的评论再进行归纳而不可能靠一次 prompt 调用完成。这种场景下Agent 的价值就是把检索 → 思考 → 归纳组织成可控的循环。3.2 自己写一个最简 Agent 循环比搭框架更懂原理我建议初学者至少亲手写一次最简单的 Agent 循环再决定用不用框架。最简版的思路不复杂tools { search: search_function, calc: calculator_function, summarize: summarize_function, } messages [{role: user, content: user_task}] for step in range(max_steps): # 1. 让模型决定直接回答还是调用某个工具 decision model.decide(messages, tool_nameslist(tools.keys())) # 2. 如果是最终答案退出循环 if decision.action final_answer: return decision.output # 3. 执行工具把结果作为新消息追加进对话 tool_result tools[decision.action](**decision.args) messages.append({role: tool, name: decision.action, content: tool_result})这个循环的每一步都清楚可见模型负责决策代码负责执行工具结果回到对话里再驱动下一轮决策。写一遍这个循环你对 Agent 的认知会从魔法变成一个带工具的 while 循环。理解了底层的循环逻辑后再看现成框架会发现它们解决的核心问题其实是三件工具协议统一、上下文管理、错误重试与权限控制。这些是易错的地方也是框架的价值所在。3.3 框架选型Spring AI 还是自研轻量方案框架选择没有银弹我提供一套自己的取舍逻辑团队已有 Java/Spring 技术栈可以认真看 Spring AI。它的好处是能和现有 Spring Boot 服务平滑集成Bean 管理、配置中心、监控体系都是现成的不必为 AI 功能单独搭一套基础设施。需要灵活编排复杂 Agent 图考虑 LangChain 或 LangGraph 这一系但一定要锁定版本因为这类框架的 API 演进速度很快网上教程很容易过期。只有一两个简单场景我更推荐自研轻量调用层用几十行代码封装比引入一个重框架更可控。我自己的项目里有几个线上服务用的就是简单的自研封装层。原因很朴素场景少、需求明确自研代码五十行能维护框架升级半年一次太折腾。框架的价值在于解决高频复杂问题而不是给自己增加学习税。4. 本地部署开源模型到底图什么显存账怎么算4.1 先算账再部署本地部署这个词听起来很酷但真正决定要不要部署的是几个实际问题数据隐私敏感数据能不能出内网如果答案是不能那本地部署几乎是唯一选择。离线可用业务场景断网也要能跑比如产线边缘设备那就得本地。长期成本调用量很大时按 Token 付费可能比自建推理服务器还贵这时候本地部署就有账可算。管控程度需要完全控制模型版本、量化方式、并发策略云上 API 满足不了。如果以上四条一条都不沾我劝你别折腾本地部署。直接调用成熟 API 是最省心的方案能把精力留给业务逻辑。技术选型不是为了炫技而是为了解决真实约束。4.2 显存估算一个能直接用的模型账本本地部署最常见的翻车点就是显存不够。我一般按参数量 × 每参数字节数 运行时开销来估算模型参数量精度大约显存占用显卡建议7BFP16约14GB16GB 以上如 RTX 4090、L47BINT4 量化约4-5GB8GB 以上如 RTX 3060、Arc A77014BINT4 量化约8-9GB16GB 以上32BINT4 量化约18-20GB24GB 以上如 RTX 3090/4090这里有一个新手容易忽略的点显存只满足能加载模型是不够的推理时的 KV Cache 和并发请求会额外吃掉大量显存。实际单卡部署时我会把显存预算留出 20%-30% 的余量否则一旦并发上来就会报显存不足甚至触发 OOM 崩溃。4.3 本地推理框架与调用方式推理框架我接触得比较多的是这几类Ollama适合个人电脑快速体验安装简单一条命令能起服务但它更偏单机、低并发场景。vLLM吞吐量高支持 PagedAttention适合服务端多并发推理是生产环境常见选择。llama.cppCPU/混合设备友好量化支持好适合没有大显存显卡的机器。我比较喜欢的组合是用 vLLM 起 OpenAI 兼容接口然后应用层直接走 OpenAI SDK 调它。这样业务代码和云端 API 的切换成本几乎为零。本地起服务大致是这样一个流程# 假设模型放在当前目录下的 models/Qwen2.5-7B-Instruct python -m vllm.entrypoints.openai.api_server \ --model models/Qwen2.5-7B-Instruct \ --served-model-name local-model \ --port 8000 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192启动后只需要注意一件事vLLM 的版本和解码参数会直接影响生成质量尤其要关注新版对 sampling 参数的默认值改动。我遇到过前后两个版本对同样提示词输出风格差异很大的情况后来就把版本号固定在 requirements 里升级前先跑回归集。5. 落地AI应用时我踩过的坑和当前的工程建议5.1 坑一只调提示词不复测回归集我有一次改了一个更严格的提示词当时测了十几个样本都正常上线后第二天用户反馈某些历史对话场景输出格式全乱。一查原因新的约束和旧场景想表达的立场冲突导致部分输出进入了防御性回答分支。从那以后我定了一个死规矩任何提示词改动必须连同回归测试一起过。回归样本不用多20 到 50 个典型业务输入就够关键是覆盖正常、边界、异常三类情况。自动化回归里我还会跑一个简单的指标校验比如关键字段缺失率、格式错误率、空响应率。这些指标不需要复杂的评测体系普通日志统计就能做但价值非常大。5.2 坑二把所有逻辑塞进一个超长提示词早期我做业务功能时恨不得一个提示词里包含全部业务规则、历史背景、常见问题答案结果提示词达到了三千字。后果是每次请求的 Token 成本高、响应变慢、模型注意力被稀释而且稍微改一处业务逻辑提示词整体都要调整。后来我把这个巨型提示词拆成了角色 检索片段 当前问题三段业务知识不再写进提示词而是提前离线切片、在请求时用向量检索取最相关的几段拼进去。这个改造其实就是 RAG 的朴素养成路径。5.3 坑三上下文无限增长对话后期质量劣化做聊天类应用时我早期把所有历史消息都往 messages 里塞结果对话超过二十轮后模型开始记不清前面内容甚至出现重复回答。后来做了两层改进滑动窗口只保留最近 N 轮完整消息更早的对话总结成一段摘要放进系统提示。关键信息提取从每轮对话里抽取用户偏好、已确认事项、待办内容单独维护状态需要时再注入。这个经验后来也成为我做 Agent 的一点原则上下文是一种稀缺资源必须主动管理而不是把什么都丢给模型自己消化。5.4 坑四忽略输入输出边界把日志变成安全隐患我在一个内部工具里曾把完整用户输入直接打进日志后来复盘时发现这种习惯非常危险。AI 应用里用户的提问可能包含个人信息、内部业务数据、甚至无意的敏感描述日志、缓存、监控链路都等于变相泄露渠道。做工程化时我坚持三条输入侧过滤对用户输入做基础的异常长度校验防止超长文本打爆模型上下文。输出侧脱敏API 返回结果落日志前替换掉疑似手机号、身份证号、邮箱等模式。权限隔离管理后台和普通调用走不同的 Key数据面与控制面严格分开。这些点未必直接提升模型效果但它们是工程系统能活多久的地基。一个效果惊艳但处处漏数据的应用是不具备上线资格的。最后再分享一点个人体会我见过不少起步很快的开发者也见过学了很久还在原地打转的人差距往往不在聪明程度而在是否快速完成了第一次完整交付。AI 这个领域信息密度极大今天出一个新模型明天多一个新框架但如果手里没有一个自己跑通的项目所有新东西都只是噪音。先把手头的 API 调通、提示词调稳、输出格式卡死做一个最简陋但完整的工具那之后学习曲线会突然变得顺畅许多。