这两年，AI工程成了技术圈最热门的话题之一。打开GitHub，各种学习路线图、入门教程多如牛毛，但我个人最认可的是“from-scratch”这个思路——从头、从地基开始，一步步搭建自己的AI工程能力体系，而不是跟着热门框架跑、最后学了一堆碎片。

我从提示工程入门，到做Agent，再到把AI能力接到真实业务里，前后踩了不少坑。这篇文章就把这套从零开始的完整路径拆开讲讲：AI工程到底是什么、需要哪些能力、怎么一步步练、哪些坑最值得注意。适合想系统学AI工程的新手，也适合已经在用AI、但觉得始终停留在零散工具层面的朋友。

1. 为什么AI工程值得从零系统学一遍

1.1 先搞清楚：AI工程到底在解决什么问题

很多朋友学AI的第一反应是“学个提示词，会聊天、会写文案就够了”。说实话，我自己一开始也是这么想的。但真正做到项目中就不行了：客户的真实需求不是“给我一个会聊天的机器人”，而是“这个机器人能稳定、准确地帮我完成日常业务处理”。

“稳定”“准确”这两个词，就是AI工程和AI玩具之间的分水岭。

AI工程的定义我梳理一下：它是一整套把大模型能力落地为可复用、可维护、可评估、可迭代的软件系统的方法论。它横跨了提示工程、Agent架构、AI编程、工作流自动化、评估与调优几个层面。

为什么值得从零系统学？因为这套体系是嵌套的：提示工程是地基，Agent是在地基上盖的房子，AI编程是盖房子的工具，工作流是管多个房子的物业体系，评估是验收标准。你不把地基打牢，后面每一层都会出问题。

如果你只是偶尔用AI写个周报，那确实不需要学这些。但如果你希望让AI真正成为生产力——无论是你个人的生产力还是团队的生产力——这些就是绕不过去的功课。

1.2 五个核心能力板块，一张地图看清楚

我用一张“能力地图”的方式来整理AI工程需要的东西，五个板块，缺一不可：

第一板块：提示工程。核心目标是“约束模型行为”。你需要理解token、上下文窗口、Few-shot、输出格式控制。这里我要强调一点：提示工程不是魔法咒语，而是信息架构设计。你把任务背景、目标、约束条件结构化地组织好，模型才有更大的概率给出你想要的输出。

第二板块：Agent编排。当AI需要调用工具、执行多步骤任务时，就需要Agent。这块的核心是工具调用（Function Calling）、循环控制、记忆管理和异常处理。很多人的理解误区是“Agent是一个智能体产品”，实际上Agent是一种程序架构，是把模型、工具、流程组合起来的工程方案。

第三板块：AI编程。这里有两层含义，一是用AI辅助你写代码，二是开发和维护AI应用本身的工程能力。现在主流的AI编程工作流已经不是“人写代码、AI补全”，而是“人做设计决策、AI批量实现”。能不能把这种协作方式跑顺，决定了你的开发效率上限。

第四板块：工作流与自动化。把AI放到多个业务节点里，让它在不同系统之间扮演“中场大脑”的角色。比如你写一份行业调研报告，从信息采集、数据整理、框架生成、初稿撰写到排版推送，AI可以在各个环节扮演不同角色。这部分的重点是流程设计、节点拆分、状态管理和错误处理。

第五板块：评估与调优。这是最容易被忽略、但也是最要命的板块。没有评测数据，就没有迭代依据；没有日志，就没有调优入口。很多项目上了线才发现效果忽好忽坏，就是因为少了这个环节。

这五个板块不用一次学完，但你的脑子里得有这张地图，不然学起来容易变成一团浆糊——今天看个提示词技巧，明天玩个Agent案例，后天又去折腾框架，最后什么都学不深。

2. 提示工程：绕不开的第一课

2.1 先理解模型到底在做什么：token与上下文

我们先把“模型像人一样思考”这个错觉去掉。

大模型的工作方式，简单说是：你给出一段token序列，它预测下一个token的概率分布，然后生成长度不等的后续token。也就是说，它没有除上下文之外的“记忆”，也没有“坚定的立场”。

有一个特别经典的生活类比：使用大模型，就像雇佣一个记忆力只有几十分钟的实习生。你和他说什么、给他什么资料，他当下能记住；一旦超过上下文窗口，他就忘得一干二净。所以你要把目标、背景、范例、边界条件，都尽可能清晰地写进“当天任务单”里。

理解这一层，你就能解释很多现象：

• 为什么模型有时会一本正经地胡说八道？因为它没有“事实校验”的意识，只会按概率生成最流畅的内容。
• 为什么同一个prompt换个模型结果就乱了？因为不同模型的参数、训练数据、对齐策略不同，概率分布也不同。
• 为什么长对话越聊越偏？因为早期信息被挤出上下文窗口，模型“忘”了你的原始目标。

带着这三个问题去调提示词，你的水平就能超过大部分只把AI当聊天工具的人。

2.2 一套可复用的结构化提示词模板

这里给你一个我自己用了很久的结构化模板，每个模块都可以直接套：

【角色】 你是一名在XX领域有10年经验的资深专家。 【任务】 请完成下面这件事：…… 【背景信息】 当前场景是……；目标用户是……；你手里的资料有…… 【输入数据】 （这里放用户输入或待处理的数据） 【输出要求】 - 格式：使用Markdown，用二级标题分节 - 长度：控制在800字以内 - 语言：专业、简洁，避免空话套话 - 如果信息不足以作答，请明确列出缺少的信息，不要编造 【参考示例】 输入：…… 输出：…… 【约束条件】 - 不要输出任何主观价值判断 - 如涉及数据，保留原始来源标注

每个模块的用意我拆解一下：

• 角色：约束模型的知识视角和语体风格。同样是“写一封邮件”，“资深商务经理”和“技术主管”的写法完全不同。
• 任务：用一句话说清楚目标，避免歧义。任务描述越模糊，模型发挥的空间越大，你的预期就越难被满足。
• 背景：提供给模型足够的情境，让它知道“站在哪里说话”。模型不会读心术，你不给上下文，它就默认用通用常识回答。
• 输出要求：这层是整个模板里最大的价值所在，它直接决定输出的结构和边界。很多人不加这一层，所以得到一堆冗长、松散的回答。
• 参考示例：给模型一个“锚点”，大幅提升格式稳定性。一个高质量的示例，顶得上十句抽象的描述。
• 约束条件：这是防止模型放飞自我的兜底条款，也是防幻觉的最常用手段。

注意，“参考示例”和“输出要求”是一个组合拳。单给示例，模型可能学会示例里的语气甚至毛病；只给格式要求、不给示例，模型可能理解不了你要的“感觉”。

2.3 一套完整的调优流程与几个硬经验

调prompt和调bug一样要有方法。我现在的流程是这样：

1. 定基线：先用最简单的prompt跑一次，记录输出质量。这个基线是你后续所有改动的参照。
2. 逐层加约束：先加角色，看输出变化；再加背景、格式约束、示例。每加一层，都对照基线评估一次效果。
3. 小步验证：每次只改一个变量，跑3到5个不同的输入，对比输出质量。不要同时改角色、格式、示例三个东西，否则你永远不知道是什么起的效果。
4. 沉淀模板：验证有效的模板，记到自己的模板库里。下次遇到类似任务直接套用。

几个硬经验，都是我实际调优中被坑出来的：

第一，温度参数要分场景。信息抽取、分类、格式化输出这类任务，温度调到0到0.3，输出更稳定；创意写作、头脑风暴，温度调到0.7到1.0，输出更多样。别全凭感觉调。

第二，长任务必须拆台阶。让模型一口气写一份两万字的分析报告，效果多半像摊大饼，没有重点。拆成“先列大纲、逐节写、统一风格、校对”四步，每一步的质量都可控。

第三，及时做版本记录。prompt修改容易，“改坏了回不去”才头疼。用一个Git仓库管理prompt版本，每次改动记录差异，迟早用得上。

第四，模型差异是常态。同一套prompt在A模型上表现稳定，到B模型上可能直接崩。生产环境里为每个模型单独维护一套提示词，别指望一套提示词通吃所有模型。

2.4 提示工程常见问题速查

3. Agent实战：从“会说话”到“会做事”

3.1 Agent架构拆解：一个会工具的“实习生”

Agent不是一种神秘的技术，它只是一种程序架构。一句话总结：Agent = 大模型决策 + 记忆 + 工具 + 事件循环。

用生活类比来解释：你雇了一位“数字实习生”。大模型是他的大脑，负责思考、规划和决策；工具是他的双手，能查网页、写文件、调API、发消息；记忆是他的笔记本，把对话历史和任务进度记下来；循环是他的工作方式——一次任务要经历“观察、思考、执行、反馈、再思考”的循环。

管理好这个“实习生”，关键在三个地方：给他清晰的工具清单，给他明确的办事流程，给他一套出错后的恢复机制。

我看到很多文章把Agent说成“能自己规划完成任务”，这个说法有点危险。当前Agent的规划能力还没有到“全自动”的程度，你的工作是设计好它的边界和兜底，而不是指望它包打天下。这也是AI工程和AI玩具在体系设计上的本质区别。

3.2 手写一个最小ReAct循环

为了理解Agent的原理，建议你亲手写一个最简单的ReAct（Reasoning and Acting）循环。下面是我用Python伪代码做的示意：

def run_agent(task, tools, llm, max_steps=8): messages = [ {"role": "system", "content": "你是一个可以通过工具完成任务的助手。" "当需要外部信息时，请用JSON格式调用工具。"} ] for step in range(max_steps): response = llm(messages) # 1. 模型思考并输出回复 messages.append(response) if response.is_final: # 2. 模型认为可以产出最终结果 return response.answer tool_call = response.tool_call if tool_call is None: continue # 3. 执行工具 try: result = tools[tool_call["name"]](**tool_call["arguments"]) except Exception as e: result = f"工具执行失败: {str(e)}" # 4. 把结果反馈给模型 messages.append({"role": "tool", "content": str(result)}) return {"error": "超过最大步数，任务中止"}

这段代码的核心逻辑就是“循环”：模型提出调用工具的请求，程序执行工具，把结果以tool消息的形式喂回模型，模型再根据结果决定下一步操作。

这里面有三个不能省的设计：

• 步数上限：没有max_steps的Agent很容易陷入死循环，这是我最早踩的坑之一。一次真实任务，超过8步还没完成，多半是设计有问题。
• 异常捕获：工具很可能失败——网络超时、参数格式错误、服务不可用。必须捕获异常并反馈给模型，让它有机会修正参数重新调用。
• 结果回传：工具执行结果必须原样、结构化地放入消息列表。模型“看不到”工具结果就无法继续推理，这是ReAct循环能运转的前提。

3.3 工具调用（Function Calling）的三个细节

Function Calling是Agent的核心机制之一。工具描述怎么写才有效？我的经验是三条：

第一，工具名要短。比如search_web、send_email、read_doc，一看就懂。不要搞出“query_external_knowledge_base_v2”这种名字，模型调用时容易出错。

第二，description要“啰嗦”。工具名简单，但描述要把“这个工具做什么、什么时候用、什么时候不要用”写清楚。模型是靠description判断是否调用工具的，描述越准确，误调用的概率越低。

第三，参数schema要严格。必填参数写清楚，可选参数给默认值，类型要精确。一次我忘了把“query”定义成string，模型传了一个object，后面整条链路全崩了。

给一个真实工具定义的JSON示例：

{ "name": "search_docs", "description": "在内部知识库中检索与用户问题相关的文档片段。" "当用户的问题可能涉及公司内部流程、历史项目或资料库时使用。", "parameters": { "type": "object", "properties": { "keywords": { "type": "array", "items": {"type": "string"}, "description": "检索关键词列表，建议2-5个，涵盖问题核心。" }, "limit": { "type": "integer", "description": "最多返回的文档片段数，默认5。", "default": 5 } }, "required": ["keywords"] } }

我再补充一点：工具数量不要无谓地多。工具越多，模型越容易用错。宁可把三四个相关功能的工具合成一个带type参数的“搜索”工具，也别一次性喂十五个细碎工具给模型。

3.4 多Agent协作：我踩过的坑

等单Agent跑顺了，你自然会想尝试“多Agent协作”——让负责调研的、负责写作的、负责审查的Agent各司其职。方向是对的，但坑也不少。

我做过一个内容生产实验：AgentA做选题，AgentB做资料调研，AgentC写初稿，AgentD做质量审查。跑了几轮之后发现几个典型问题：

坑一：分工边界不清晰。两个Agent都认为“定稿”是自己的职责，互相覆盖对方的输出。解决方法是把每个Agent的任务说明书写细，包括它负责什么、不负责什么、输出交接给谁、输入从哪里来。

坑二：上下文格式没对齐。AgentA输出的是一段自然语言摘要，AgentB却以为输入是结构化JSON，一解析就失败。解决办法是给每个Agent定义明确的输入输出结构，两个Agent之间只走标准接口。

坑三：卡死与无限循环。AgentC等AgentD的结果，AgentD又等AgentC先更新，两边互相等待，直接超时。解决办法是给每一条协作链路都加超时、重试和熔断机制。

这些坑在真实项目里会以更隐蔽的方式出现。所以我的建议是：一开始别急着上多Agent，先把单个Agent的稳定性打磨好。一个稳定的Agent，永远好过五个互相扯皮的Agent。

4. AI编程与工程化落地：把Demo变成产品

4.1 我的AI编程工作流实录

说说我现在每天在用的AI编程工作流，不是教程里的理想流程，是我实际跑通的版本：

第一步：需求拆解。先不碰AI，自己把需求拆成3到5个任务，每个任务包括输入、处理、输出、验收标准。这是整个流程的根基，AI的能力再强，需求不清也白搭。

第二步：生成骨架。给AI交代清楚项目背景（技术栈、目录结构、接口约定），让AI先生成项目骨架、数据模型、接口定义。这一步的输出要人工review一遍，因为架构决策不能全交给AI。

第三步：分模块实现。一个模块一个模块地让AI编码，每完成一个模块立刻本地跑通。禁止“一口气生成3000行代码”的用法——生成得越多，出错了越难定位。

第四步：AI写测试，人写边界用例。让AI把单元测试的框架写出来，但核心的边界条件和异常路径，要由人自己补上。AI擅长覆盖常规路径，但极端情况的想象力还是人强。

第五步：代码审查。用AI过一遍代码找风格问题和潜在bug，但所有涉及资金、安全、竞态条件的逻辑，必须人肉严格review。

这套流程的核心是：AI负责产能，人负责控制。你越能把AI当成一个“手速极快但需要监督的开发搭档”，越能享受到它带来的效率提升。

4.2 AI工程落地最容易翻车的三个环节

第一个：过度信任AI生成的代码。AI生成的代码经常“看起来都对”——风格工整、注释齐全，但一跑就炸。常见雷区是并发控制、边界条件、异常处理路径。我的经验是：review时必须带着“这代码一定有问题”的心态去看，而不是“这代码写得真好”。

第二个：上下文管理失效。大项目里AI常常“忘记”你之前说过的约束。解决思路是把项目的关键约束写进文档，每次开工前让AI先读取一遍。这就像给新同事一份带着项目文化的README。

第三个：成本失控。AI接口不是免费的，一个Agent跑一次任务就可能消耗几十万token。优化方法：用便宜的小模型处理简单任务，用贵的大模型处理难任务；对常用信息做缓存；限制Agent单次任务的最大步数和token上限。

4.3 从Demo到生产的四个关键动作

第一，建立评测集。你需要一个包含几十到几百个样本的验证集，每个样本有输入和预期输出。以后每次改prompt、换模型、调参数，都拿它跑一遍，质量升降一眼可见。没有评测集的AI项目，上线全靠运气。

第二，把配置纳入版本管理。Prompt、模型版本、参数设置，所有东西都应该像代码一样纳入版本管理。我有一次改了一个prompt，效果直接崩了，但因为预先做了版本管理，一分钟内回滚到上一版本。

第三，做可观测性。上线之后，你要能看到每次请求的输入、输出、token消耗、耗时、调用了哪些工具、走到了哪个分支。没有这些，你连排查问题的入口都找不到。

第四，灰度发布。AI应用的输出是概率性的，全量上线风险极大。正确做法是让新prompt先跑5%的流量，对比评测后再逐步放量，异常自动回滚。

这四个动作，每一个看起来都像“多加了环节”，但每一个都是救命的。跳过它们的项目，我见过太多上线的第一个星期就被用户骂回来。

5. 写给从零开始的你：一个可执行的学习路径

5.1 三个月路线图

如果让我给一个从零开始的人排学习计划，我会安排成这样，这是一条我自己验证过的路径：

第一个月：打地基。只做提示工程，不做其他。目标：能用结构化提示词稳定完成文档生成、信息抽取、代码生成、格式转换等任务。第一周先搞清楚token、上下文窗口这些基础概念，第二周开始用结构化模板，第三周学会拆长任务，第四周做一个小项目，比如“用AI自动生成周报”。每天至少做3个实际案例，每周把当周的模板汇总整理。

第二个月：学Agent。搭建一个最小的Agent工程环境，学会调用大模型API、实现Function Calling、搭建一个单Agent项目。目标是做一个能“查资料并整理成结构化报告”的Agent。这个阶段你会第一次真正理解：AI的“做事”和“聊天”完全是两回事。

第三个月：工程化。把第二个月做的Agent放到一个真实的业务场景里，补充评测集、日志、版本管理、成本控制。同时开始用AI编程辅助开发日常项目，体会“人机协同”的工作方式。

最后给个建议：这三个月里，别急着追新框架、新工具。AI圈的工具迭代太快，今天的热门框架三个月后就没人提了，但底层的能力——提示工程、Agent架构、评测意识——永远是通用的。

5.2 必备工具与学习资源

工具方面，我建议分三组：

• 基础模型API：至少熟悉两家主流大模型的接口差异，通过实际使用建立“模型特性直觉”。知道哪个模型擅长什么、短板在哪，是选型的基础。
• AI编程助手：选一款用得顺手的编码辅助工具，把它嵌入你的日常开发流程。重点不是工具本身，而是你能否用它提升自己的开发效率。
• Agent开发框架：可以用开源框架快速起步，但强烈建议先手写一次Agent循环，搞清楚原理后再用框架。否则你只是在“用框架”，不是在“做工程”。

学习资源方面，我推荐几类：

• 官方文档：优先读大模型厂商的官方文档，尤其是提示词教程和Function Calling文档。信息密度比二手教程高得多。
• 经典论文：理解Transformer、Agent能力的技术背景。不需要啃得深，但知道原理骨架，能帮你判断“什么能做、什么不能做”。
• 开源项目：找一个还在维护的Agent开源项目，Clone下来读源码，看它怎么处理工具调用、错误恢复和上下文管理。读代码永远比看教程学得快。

5.3 几条给新手的真心话

第一，别囤课程。收藏夹里100个教程，不如亲手写完10个案例。动手练是最快的路径，AI工程尤其如此。

第二，找一个真实的业务场景。哪怕是你自己的个人周报、家里的账单整理、朋友的毕业论文辅助，都可以。真实场景会逼你面对脏数据、歧义和不确定性，这是教程给不了你的。

第三，把“稳定”和“准确”当成最高优先级。你调出来的prompt如果能稳定复现80分的输出，比偶尔100分、经常40分的输出值钱得多。工程思维的底色就是“可重复性”。

第四，保持怀疑。对模型输出保持怀疑，对工具宣传保持怀疑，对任何号称“AI能搞定一切”的论调保持怀疑。AI工程的魅力恰恰在于，它是一个需要人持续做出判断和决策的领域。

最后再分享一点实操经验：我的学习方法是做一个自己的“AI工程笔记”，把每个实验记录成同一个模板——目标、方案、结果、教训。三个月之后翻出来看，你会直观感受到自己走了多远，哪些经验有效、哪些弯路不用再走。这就是从零开始这条路最迷人的地方：每一步都是你自己的地基。