最近经常有人问我一个特别基础、但特别难回答的问题想从零开始搞AI工程到底该学什么、该怎么做问的人里有刚毕业的软件工程师有做了几年后台想转型的开发也有一些非技术出身、但想让业务更智能的团队负责人。大家有个共同点手上并没有一个真正跑起来的AI项目但又非常迫切地想知道这条路从头走到尾是什么样子的。我在这个领域摸爬滚打了几年经历过从调接口到搭系统从Demo很惊艳到上线就想哭的全过程。所以这篇内容我不打算给你列一份课程大纲也不打算讲什么高深的数学而是用最朴素的思路拆解一个人从零开始把AI工程做起来会遇到的全部关键节点你要解决什么问题、怎么选型、怎么搭管线、怎么评测、怎么把模型真正嵌进业务里以及那些没人写进文档的坑。1. 先搞清楚AI工程到底在解决什么问题如果只看字面意思很多人会把AI工程理解成训练模型或调Prompt。这也不能说错但它更像用会写几行SQL来定义数据工程师一样方向是对的深度远远不够。真正的AI工程是让一个AI能力在真实环境里稳定、可控、可维护地运行起来。它的重心不在AI而在工程。1.1 三种角色之间的认知差我见过太多团队在做这件事之前连自己属于哪条路线都没想清楚算法研究者关心的是模型效果能不能再涨两个点他们的产出是论文、权重文件、实验记录。Prompt工程师现在自媒体喜欢叫提示词工程师关心的是这个Prompt能不能稳定触发目标行为他们的产出是模板、few-shot示例、调优记录。AI工程师关心的则是一个更大的闭环数据从哪来、模型在哪跑、推理延迟多少、出错怎么兜底、成本谁买单、效果怎么量化。这三者之间不是取代关系而是上下游关系。你从零开始做AI工程先要知道自己大概率不需要天天训练模型也不需要追求Prompt的奇技淫巧你要做的是把算法、数据、系统、业务四件事粘合起来做成一个哪怕明天流量翻十倍也还能扛住的系统。1.2 一个AI系统的完整骨架我在动手任何项目前都会先在纸上画出一张系统骨架清单大部分从零起步的项目都离不开这七层层次要回答的问题典型组件业务入口谁在什么场景下使用AI能力Web页面、IM机器人、API接口应用编排用户请求进来后走什么流程工作流引擎、Agent框架、状态机交互层怎么处理上下文、记忆、多轮对话向量库、短期记忆、会话缓存模型层大脑本身是谁开源模型、商用API、微调模型推理层模型跑在哪里、延迟多高本地GPU、云推理服务、量化部署数据层知识从哪来来、怎么更新数据管道、文档解析、向量化观测与运维效果好不好、系统稳不稳、花了多少钱日志、评测集、监控看板、成本报表对初学者最忌讳的事情是先选模型、先调Prompt然后才去想业务。正确顺序永远是反过来先定义你的系统骨架再往骨架里填零件。1.3 from scratch的真实含义标题里这个from scratch我个人的理解不是从零写大模型——那是科研任务不是工程任务。这里的从零指的是你不需要依赖任何已有的AI基建能够从一台干净的机器、一个明确的问题出发亲手把数据、模型、推理、应用、评测、运维这一整条链路打通。这个过程的价值不在于代码本身而在于你会对整个系统形成肌肉记忆哪个环节慢了你能立刻判断出瓶颈在哪模型突然回答变差了你知道该去查数据还是查Prompt还是查上游依赖。2. 环境与工程骨架先把最小的可运行管线搭起来很多教程一上来就让你复现GPT或者微调一个Llama说实话这对从零开始的人来说是灾难级的误导。我第一次就栽过这样的跟头花了两天时间配环境还没等到训练跑起来心态已经崩了。真正务实的路径是先不管训练把一个最简单的输入文本到输出文本的管线跑通再逐步工程化。2.1 环境准备里最容易被忽视的几件事Python版本统一AI生态的依赖现在越来越挑Python版本。建议直接上3.10或3.11别用系统自带的老版本也别追最新的3.13很多库还没适配。虚拟环境隔离优先用uv或poetry管理依赖。uv胜在快poetry胜在项目文件语义清晰。这一步看似琐碎但能救你于水火——我见过无数人因为全局装包导致版本冲突最后项目跑不起来。硬件评估如果没有本地GPU别硬跑大模型。一台带4GB显存的消费级显卡跑7B量化模型都勉强不如直接调用云上推理API。推荐补充如果公司有GPU服务器一定要用Docker固化环境否则别人换台机器整个环境就玄学了。2.2 最小的AI工程管线长什么样第一步目标不是做产品而是拥有一段随时可以复制的最小代码路径输入一段用户文本。经过预处理清理、截断、格式化。送进模型本地模型加载或远程API调用。拿到原始输出。后处理去噪、转JSON、限长。返回结果。我用一个极简示例说明大家就懂了这段代码是伪结构但每一步都是真实项目里会出现的def build_pipeline(model_loader, preprocessor, postprocessor): def run(user_input: str) - dict: # 1. 预处理把用户输入转成模型需要的指令格式 payload preprocessor.build_prompt(user_input) # 2. 调用模型这里统一抽象本地和远程都能适配 raw model_loader.infer(payload) # 3. 后处理把模型回答解析成结构化结果 result postprocessor.parse(raw) return result return run # 使用示例 pipe build_pipeline( model_loaderload_chat_model(qwen2.5:7b), preprocessorPromptTemplate(system你是智能客服助手回答要简洁。), postprocessorJSONExtractor(), ) answer pipe(我的订单什么时候发货)写好这样一段代码的另一个好处你可以把model_loader这个抽象作为设备插座今天插开源模型明天插闭源API后天插微调模型业务层完全不用改动。2.3 模型选型的逻辑别用大炮打蚊子从零开始最容易犯的错是看到什么模型强就用什么模型。我的建议是建立一个任务-模型匹配表任务类型推荐思路原因简单分类、抽取3B-8B开源小模型或文本模型延迟低、便宜、可控开放域问答、写作14B以上开源模型或中档API语义能力强复杂推理、代码生成顶级闭源API效果天花板高私有数据强依赖开源模型本地部署或微调隐私可控记住一个原则选型的核心依据是你的任务约束数据隐私、成本预算、延迟预期而不是模型榜单。榜单第一名的模型如果每次调用要等十秒、花五块钱对你的业务可能是一个负资产。3. 数据与评测决定工程上限的隐形基建有个残酷的事实我在文章开头就想告诉你一个AI工程的迭代速度不取决于模型多强而取决于数据和评测做得多扎实。没有这部分你的模型再厉害也只是裸奔的天才。3.1 数据管线不是收集一堆文本那么简单从零开始做数据至少要想清楚四件事来源真实业务数据、公开数据集、合成数据、用户反馈回流。其中用户反馈回流是最有价值但也最容易忽略的——产品上线后用户怎么改你的Prompt这是免费的高质量标注。清洗去重、脱敏、过滤低质量内容、修正格式错误。一份用户输入的日志经常藏着大量会话编码错误不洗出来直接喂给模型效果会莫名其妙地差。切分训练集、验证集、评测集要分开且评测集一旦确定尽量少动否则你会在过拟合的错觉里越走越远。版本管理数据也要像代码一样做版本管理。模型效果一退步第一步永远是回头查数据最近改了什么。3.2 怎么搭建一个最基础的评测集刚开始不需要搞复杂的大模型评分体系你只需要做一件事把业务中最典型的50到200个问题整理成一个黄金评测集并给每一条写上期望的行为特征。比如输入问题期望行为不允许的行为你们能退款吗明确告知退款条件并引导操作流程直接说能却不说条件推荐一部适合老人看的电影给出2-3个选项说明理由只给一个名字不做解释我不会用这个功能教我分步骤说明操作一次性把十步全砸出来每次改Prompt、换模型、调参数后都拿这个评测集跑一遍逐条记录通过率。这套东西就是你的AI回归测试比任何花哨的可视化面板都有用。3.3 可观测性你必须知道模型在真实世界里表现如何在线系统一定要有日志和链路追踪。每次请求至少记录以下几项用户的原始输入和上下文字数Prompt最终形态模板渲染后的完整内容模型返回的原始输出和后处理后的输出响应耗时、调用模型名称、Token用量、成本估算是否有重试、是否命中了安全过滤、最终是成功还是走了兜底。这些日志前期不会带来直观收益但一旦出问题它就是唯一的破案线索。我操盘过的一个客服机器人项目上线后用户投诉率上升查询日志才发现是某个上游接口把用户手机型号误传成了上下文导致模型频繁以为用户在骂它。4. Prompt Engineering与Agent编排从单次调用到多步决策如果说数据与评测是AI工程的地基那Prompt工程和Agent编排就是你能不能把模型能力变成业务能力的那座桥。这里面被自媒体吹得最玄但工程上其实是有一套非常清晰的拆解方法的。4.1 别再神化Prompt它本质是一个结构化接口很多人以为Prompt写得好坏是文字感觉的事从我踩过的坑来说真正有效的Prompt有四个工程化要点角色与目标要精确定义与其写你是一个助手不如写清楚你是电商平台售后客服目标是在不承诺超出政策范围的前提下解答用户问题。输出格式要可解析直接在Prompt里声明只输出JSON包含result和reason两个字段并给出示例。这样后处理解析几乎零成本。边界条件要显式声明如果不知道答案输出不支持字段而不是编造。把动态内容变量化所有用户输入、业务参数都通过模板变量注入绝不直接在代码里拼字符串。我用一套自己的模板结构分享出来供参考[系统指令] 你是{role}。你的目标是{goal}。 规则 1. {rule_1} 2. 如果{edge_case}请输出{fallback}。 [业务上下文] 实时商品库存{inventory} 用户最近订单{order_history} [用户请求] {user_input} [输出要求] 仅输出JSON结构{reply: 给用户的回答, confidence: 0到1}这个结构的好处是角色、规则、上下文、输入、输出被拆成独立区块后续调任何一个维度都不会牵一发动全身。它让Prompt变成了配置而不是文学作品。4.2 Agent不是银弹什么时候该上编排现在圈内最热词之一就是AI Agent很多项目从零开始就直接上Agent框架让模型自主规划-调用工具-完成任务。我的态度是先别急着让模型做复杂度高的决策一定要评估清楚。适合用Agent的场景有几个特征任务可以分解成多个独立步骤且每一步都有明确的工具可调用模型不需要做出高风险的价值判断允许失败并重试且失败成本低。不适合的恰恰相反单一问答、强流程约束、错误代价高、必须秒回的场景用工作流确定性编排而不是Agent。比如下单支付这种涉及资金的操作你就别让模型自由发挥了——老老实实用工作流把每一步钉死模型只负责抽取意图和参数。4.3 多AI协作的工程实践热搜里有个词是多AI协作我也聊一下我的真实感受。多模型协作不是拿着十个模型一起上而是把任务按能力域拆分给不同模型各司其职。典型的分工方式是一个轻量小模型负责意图识别和路由速度快、成本低主模型负责复杂生成只在被路由到时才调用一个校验模型专门做结果审核比如检测主模型输出是否偏离事实如果需要长期记忆则把向量检索作为独立的检索模块挂在旁边。我自己做过的一次实践里把原来单个大模型承担的意图路由生成审核三合一任务拆成小模型路由大模型生成规则校验三段式成本直接降了六成效果反而更稳。原因是每个模型都只专注自己最擅长的事出问题时定位起来也容易得多。5. 把AI接入真实业务稳定性、成本与安全护栏前面所有工作做完项目在Demo环境里能跑了很多人就觉得大功告成。但我可以负责任地说真正的工程挑战是从Demo能跑到上线不崩这段路。这个阶段我习惯称之为让AI学会在真实世界里谋生。5.1 稳定性模型不可能永远在线哪怕是最好的模型服务也会有超时、限流、返回乱码甚至宕机的时候。所以你的工程骨架里必须内置防御逻辑重试机制对瞬时错误超时、限流做指数退避重试但最多重试两次否则用户会被活活卡死。降级路径定义好模型挂了怎么办。对客服场景可以降级到简单的关键词知识库检索对生成场景可以降级到预设的兜底话术。千万别让系统在模型不可用时直接瘫痪。超时控制调用模型必须设置硬性超时宁可返回我暂时无法回答也不要让用户转圈三十秒。并发隔离一个慢请求不能拖垮整个进程用异步和队列把高延迟的模型调用隔离开。这些做起来不性感但恰恰是工程和脚本的分界线。5.2 成本AI工程的隐形天花板多少从零开始的项目是死在了月末账单上的。成本控制要从第一天就纳入设计Token预算前置设计Prompt时先预估每次请求的Token消耗再乘以预期调用量你会得到一个让人清醒的数字。缓存策略对同一类问题或相同上下文的请求做结果缓存能去掉大量重复计算。模型分级优先用便宜的小模型处理大部分请求只有小模型搞不定时再升级到贵的大模型。输出长度限制在Prompt里限死max_tokens很多时候削减一半输出长度效果损失很小成本下降很大。我之前接手过一个报表分析项目原始实现每次都把全年的数据塞进Prompt里让大模型算一次要烧几十万Token。后来我改成预处理模块先把数据聚合成摘要再让模型分析摘要成本降到了原来的二十分之一分析质量并没有明显下降。这就是工程优化比模型升级更值钱的最典型例子。5.3 安全护栏内容安全与提示注入接入真实用户后你会面对各种意想不到的输入。现阶段做AI工程至少要有四道护栏输入过滤在把用户内容送入模型前做敏感词、异常链接、超长文本检测。超长文本可以直接截断或拒绝省得模型被横向越权。输出过滤模型生成的回答要过一道过滤器防止它输出不该输出的内容如果接到企业私有知识库还要防止模型把内部信息泄露到公共输出。提示注入防护用户可能试图让模型忘记角色设定或执行危险指令。工程上的应对思路是用户输入永远被当作不可信数据来处理用显式的角色隔离和指令边界把系统Prompt与用户输入隔开对于高风险操作还要加一道人工确认或二次校验。隐私合规涉及真实用户数据手机号、地址、聊天记录务必做好脱敏和访问控制。这部分不是附加题而是必答题在项目第一天就要想清楚。5.4 案例切入Harness Engineering思维最近圈子里还流行一个词叫Harness Engineering听起来高级说白了就是给AI戴上缰绳——通过工程机制把模型的输出约束在可控范围之内。我在一个实际项目里做过一次完整的落地需求是从用户的长篇投诉中自动生成工单摘要。乍一看这只是一个调用大模型总结一下的需求。但从Harness Engineering的角度我拆成了四层第一层输入约束投诉文本进来先做分类和长度归一超过限制的自动分片。第二层Prompt护栏系统指令里明确只提取事实不评价情绪不输出推测并给出三个不同长度的摘要示例。第三层输出校验程序解析摘要检查是否包含用户ID、订单号等关键实体缺失则触发重跑。第四层人工兜底置信度低于阈值时自动转交人工审核。这个案例给我最大的启发是AI能力的价值不在于模型有多聪明而在于你给它设计的缰绳有多周到。这也是AI工程和单纯调接口之间最本质的区别。写在最后动手永远比围观重要如果你看到这里我想你已经明白了一条核心规律从零开始做AI工程真正的路径不是学习—储备—再动手而是动手—卡住—补课—再动手。我在最初的半年里走了特别多弯路最大的弯路就是总想等自己准备得足够充分再开始结果等来的只有焦虑。后来我调整了策略拿一个极小的真实场景比如把机器人客服的回答在用户提问前先过滤一遍脏话用最快速度把前面说的管线、评测、日志、护栏全部过一遍哪怕代码写得丑、方案不优雅先让它完整地run起来。等到再遇到第二个项目时秩序感就出来了。最后再分享一个小技巧每个AI工程都要维护一份卡住记录文档把你遇到的每一个问题、排查过程、最终解法写进去。这比任何课程笔记都值钱。因为AI领域的问题重复率极高你今天花三小时解决的环境问题记录下来后下次五分钟就能搞定。AI工程的魅力就在于你永远有学不完的新东西但只要你的工程骨架足够扎实任何新技术都只是骨架上的新器官。希望这篇基于我真实经验的内容能帮你把从零到一的第一步迈得更踏实。
