初级
我想成为一名AI工程师（完整课程）
我想成为一名AI工程师（完整课程）
我想成为一名AI工程师（完整课程）#
你们大多数人认为掌握AI只需要精通提示工程（剧透：并非如此），事实上，与上下文工程和意图工程相比，它是最不重要的。今天我将教你如何学习这一切，并提供你可以直接“偷走”的提示，让成为AI工程师变得容易。是的，我明白这其中的讽刺意味，但稍后你会明白提示仍然重要，但AI工程师的技术栈远不止于此。
以下是大多数人学得太晚的残酷真相：你在提示框中输入的文字，对于构建真正有效的AI来说，是最不重要的部分。行业预测显示，由于缺乏治理和结构框架，到2027年底，超过40%的智能体AI项目面临直接被取消的风险。
如果你仍然把AI当作聊天界面，并且优化方式仅仅是改进措辞，那么兄弟，你已经落后了大约两年。让我们帮你快速赶上……
本指南将带你了解完整的工程栈，从提示设计到自主系统架构。
文章结构如下：
- 提示工程控制即时指令（语法）
- 上下文工程架构环境和记忆（基础设施）
- 意图工程定义组织目标和约束（战略）
- AI工程帮助你学习完整的技术栈（把这玩意儿组装起来）
每一层都建立在下一层之上。你不能跳过任何一层。让我们逐一分解。
哦，快速说明一下：你会看到大写的加粗文本，那是主标题；当你看到引用块中的加粗文本，那是子标题（现在它是了，哈哈）。我只是想让你知道这一点，这会让文章更容易浏览。
1: 提示工程#
目前这仍然是基础，但并非全部。事实上，随着模型的发展，它的重要性正在逐渐减弱。但作为这个技术栈的一部分，它在AI工程中仍然扮演着重要角色。
当你编写提示时，引擎盖下实际发生的是：你正在操纵模型生成下一个令牌的概率分布。语言模型根据之前的所有内容计算每个后续令牌的统计可能性。你作为提示工程师的工作就是缩小那个概率空间。
当你仔细选择动作动词、建立清晰的角色设定，并用精确的分隔符格式化输入时，你就减少了模型的认知负荷并最小化了幻觉。这就是提示工程的精髓：
> 上下文学习：示例范式
提示工程中最基本的杠杆是你在提示本身中给模型提供多少示例。这被称为上下文学习。模型使用其注意力机制来识别你提示中的模式，从而适应新任务，而无需改变其底层权重。
零样本提示意味着你给模型一个任务，但完全不提供示例。它完全依赖于其预训练的知识。这对于简单、常见的任务（总结这段文本、翻译这个句子）效果很好。但当你需要特定领域的格式、复杂逻辑或精确的输出结构时，它通常会失败。用零样本提示要求一个特定的JSON模式？你通常会得到对话式的散文。
单样本和少样本提示通过将一个或几个高质量的输入-输出示例直接注入你的提示来解决这个问题。这同时做了两件事：
- 它明确地演示了你期望的确切输出模式
- 它迫使模型的注意力机制在生成响应之前识别语义模式
当零样本和少样本提示仍然不够时，这就是你的信号。你已经触及了架构天花板。仅靠预训练的权重无法合成你所需的内容。此时，你要么微调模型，要么转向高级的认知脚手架技术。
> 认知脚手架：让模型“大声思考”
这里有一个关键点需要理解：LLM没有内部独白。它们的“思考”只发生在生成令牌时。通过强制模型输出中间推理步骤，你实际上是在给它提供临时的工作记忆。
这是所有高级提示技术背后的关键见解：
给你一张信息图！
> 像工程师一样构建提示
2026年的专业提示工程意味着从底层开始，使用明确的结构化格式构建提示。你不能将提示写成连续的散文。你需要用分隔符来“工程化”它们。
像
<context>、<task> 和 <example> 这样的XML标签严格地将你的指令与数据负载分开。这不仅仅是良好的实践，它还能防止提示注入漏洞，并确保模型的注意力机制能正确权衡指令与数据。一个完整的提示“契约”通常包括：
- 一个定义的角色
- 广泛的背景上下文
- 逐步的任务指令
- 明确的输出格式规范
- 少样本示例
审核每个提示中隐藏的歧义。像“更好”或“有创意”这样的词需要被结构化地定义。如果提示试图一次执行太多任务，就拆分它。
> 提示工程失效之处
尽管有这些技术，提示工程在企业级规模上存在严重的结构局限性。
这种方法论将每次交互都视为孤立事件。它优化的是即时任务的措辞。但当你的工作流程需要长时间的多步骤执行时（例如，一个自主智能体运行为期一周的代码库审计、管理复杂的客户纠纷或协调多云部署），静态提示会在不断累积的上下文和变化的变量下崩溃。
随着AI系统从聊天助手演变为自主智能体，行业意识到：优美的措辞无法替代结构化的记忆和系统性的感知。
提示工程将AI视为一个强大但无智能的工具，需要持续操控。要构建能够推理、适应和持久化的系统，你需要编排环境本身。
这就是上下文工程登场的地方。
> 引用推文
> 提示工程已死。上下文工程万岁。（好吧，并非完全死亡——但它肯定正在演变成更强大的东西）认识一下上下文工程——构建动态系统的艺术，为LLM提供它们所需的……
> https://x.com/i/web/status/1950841048491565500
（忽略她的点击诱饵标题，它正在演变）
2: 上下文工程#
上下文工程是设计、优化和维护LLM在推理期间可用的确切令牌配置的系统性实践。
核心原则是：你的AI智能体的能力，仅取决于它能立即访问的信息。
如果说提示工程是给数字工作者一个具体的任务，那么上下文工程就是为他们提供执行该任务所需的正确文件、历史记录、工具和环境感知。
使用语言模型进行构建，与其说是寻找完美的措辞，不如说是回答这个问题：哪种特定的上下文配置最有可能产生期望的行为？
这包括内存管理（短期状态和长期向量存储）、提示链管理、动态变量注入（时间、系统状态、用户角色）、噪声过滤，以及检索增强生成管线的庞大编排。
> 高级RAG：智能体如何访问真实知识
RAG系统是将外部专有知识注入LLM上下文窗口的主要机制。通过将生成过程基于可验证的外部数据，RAG减轻了幻觉并确保了事实准确性。
早期的RAG实现存在严重的可靠性问题：原始的数据处理和稀疏检索方法（如TF-IDF或BM25）仅匹配关键词而不理解含义。到2025-2026年，上下文工程正式确立了复杂的分块策略和密集的、基于Transformer的嵌入（如BERT），这些嵌入能够捕捉语义含义。你的系统现在能理解“猫科宠物”的查询与关于“猫”的文档在语义上是相同的。
现代上下文工程将RAG管线解耦为两个不同的阶段：搜索和检索。查找文档所需的文本粒度与理解文档所需的文本粒度大不相同。
搜索阶段（语义匹配）：可以将其视为扫描海量数据库寻找线索。你需要小的、语义纯净的文本单元，通常是100到256个令牌。小分块提供清晰的语义焦点、高精度召回和更少的噪声。
检索阶段（上下文理解）：可以将其视为阅读完整章节以掌握概念。你需要更大的分块，通常是1024+个令牌，以确保逻辑完整性、充分的背景信息和持续的推理。
你的检索系统的成功完全取决于你在向量化之前如何对原始数据进行分块。选择正确的分割逻辑是你将做出的最关键的上文工程决策之一。
工程师使用像Docling（用于从PDF和表格中提取多模态数据）和像Chroma或Pinecone这样的向量数据库来实现这些。现代RAG系统根据“分块归因”和“分块利用率”进行评估，衡量检索到的上下文实际影响模型输出的程度。
> 上下文即代码：范式转变
这是上下文工程中最重要的演变：将上下文视为版本控制的软件基础设施。
历史上，系统提示、数据模式和API文档都是手动粘贴到聊天界面中，或硬编码为字符串字面量。这导致了会话间的失忆、无法追踪的幻觉，以及零能力审计驱动智能体行为的知识。2024年的一项研究发现，程序员花费高达11.56%的编码时间仅仅用于向LLM提供上下文指令，几乎与编写实际代码的14.05%相当。
上下文即代码范式将严格的GitOps原则应用于AI内存管理。
上下文文件、业务逻辑规则、架构定义、安全边界、工具模式——它们都被编码到结构化文件（JSON、YAML）中，并与你的应用程序代码一起直接提交到版本控制中。
最明显的例子？仓库级的指令文件，如
AGENTS.md 或 context.yaml。与为人类编写的标准
README.md 不同，这些文件提供了机器可读的蓝图。当一个智能体指向一个代码库时，AGENTS.md 文件标准化了上下文注入，无论仓库使用snake_case还是CamelCase，哪些测试框架是活跃的，以及正在使用的架构约定。为什么这很重要：如果一个自主编码智能体引入了回归，你可以通过审查在该时间戳指导智能体的上下文文件的确切Git提交来进行确定性审计。上下文从短暂的聊天状态转变为持久的、可审计的企业资产。
这也实现了“上下文捆绑”，确保大型团队中部署的每个AI工具都共享关于产品愿景、语气、边缘情况和合规要求的相同、版本控制的记忆。
> MCP：AI智能体的通用接口
上下文工程的爆炸式增长需要一个标准化的框架来将数据和工具访问路由到LLM。2025年底，模型上下文协议作为一个开源标准出现，重塑了AI架构。
可以把MCP看作是“AI应用的USB-C端口”。它标准化了LLM客户端（桌面应用、IDE、云智能体）如何连接到外部数据源、企业数据库和执行工具。
在MCP之前，开发者为每个集成编写脆弱、自定义的粘合代码。MCP通过一个语言无关的两层架构消除了这种技术债务：
数据层（JSON-RPC 2.0）：定义了客户端-服务器通信的严格协议，管理连接生命周期，并建立三个核心原语：
- 资源：只读的、类似文件的数据，提供基础上下文（数据库模式、API日志、策略文档）
- 工具：LLM可以调用的可执行函数以采取行动（SQL查询、Shell脚本、API调用）
- 提示：用于标准化任务的可重用、服务器端指令模板
数据层支持实时、双向通知。如果服务器的工具发生变化或资源更新，它会向客户端发送通知——你的AI上下文会动态变化，无需人工干预。
传输层：
- STDIO传输：用于本地集成（例如，Claude Desktop访问本地代码库）。作为本地子进程通过标准I/O运行。零HTTP开销。本地数据完全保留在主机上。
- HTTP with SSE / 可流式HTTP：用于分布式企业部署（查询远程BigQuery、AWS基础设施、Sentry）。支持跨云环境的安全、无状态扩展。
MCP的强大之处在于：一个MCP服务器完全不知道是哪个LLM在与它交互。服务器通过结构化模式暴露其能力。协议处理安全握手和格式转换。构建一次工具，将其容器化，并暴露给任何支持该协议的当前或未来的AI模型。
3: 意图工程#
这是提示工程和上下文工程无法回答的问题：系统在长时间内应该优化什么？
一个拥有完美语法、尖端上下文缓存和通过MCP完全访问你企业数据的智能体，如果其底层目标与你的组织目标不一致，仍然可能造成灾难性的损害。
意图工程是围绕目标、约束和可衡量的业务成果（而非表面指令）进行AI系统结构设计的过程。
它位于上下文工程之上，就像战略位于战术之上一样。它将智能体的身份从回答查询的数字助手转变为执行复杂目标的负责任的企业操作员。
> 意图鸿沟：Klarna的灾难
你需要理解为什么这很重要。2025年1月的Klarna部署是决定性的案例研究。
Klarna推出了一个具有出色上下文集成和优化提示的自主AI客户服务智能体。第一个月，它处理了23个市场、35种语言的230万次对话——这相当于853名全职员工的工作量。平均工单解决时间从11分钟下降到2分钟。CEO预计节省4000万美元。实际结果：成本降低了6000万美元。
从技术上讲，指标是完美的。
但到2025年中，Klarna被迫重新雇佣了它解雇的人类客服。
失败完全是一个意图工程失败。AI被隐式告知“快速解决工单”。它无情地优化了这个指标。
以下是AI做不到的：人类客服凭直觉知道，当一个高利润的3年老客户极度沮丧时，正确的做法是忽略解决时间指标，升级问题，并优先考虑同理心和长期保留。这是隐含的组织知识。这就是意图。
AI缺乏平衡权衡的能力。它残酷地优化速度，技术上解决了工单，却深深地疏远了客户。它节省了6000万美元，却成了“AI出错的公众面孔”。
这就是“意图鸿沟”。一个技术上卓越的智能体完美地优化了完全错误的目标。为什么？因为组织目标从未被编码到基础设施中。
> 7组件意图框架
意图工程用机器可读的结构化模式取代模糊的任务陈述，这些模式定义了决策边界、权衡层次和升级触发器。
当你的自主智能体遇到冲突时（速度 vs. 准确性，短期成本 vs. 长期满意度），意图框架提供了解决冲突的数学层次结构，而无需猜测。
以下是完整的框架。每个组件都直接转化为可工作的代码：
在实践中，这些不是以散文形式传递的。它们表现为带有冲突解决协议和权衡矩阵的结构化JSON或YAML模式。例如，在软件定义网络环境中，结构化的意图提示明确地将排队意图与转发规则分开，防止AI在优化流量时意外阻塞关键基础设施。
> 氛围编码 vs. 确定性意图
意图工程直接与2025年初出现的一种文化趋势——“氛围编码”——背道而驰。
氛围编码是指开发者使用自然语言模糊地描述应用程序的“氛围”，然后让LLM生成架构、API集成和样板代码。这对于快速原型设计非常强大。它使非技术产品经理能够参与。
但在企业环境中，它带来了巨大的系统性风险。
基于模糊情感而非基于确定性设计生成的代码，会产生脆弱、无法追踪的代码库，充满了潜在的漏洞。没有人能够完全追踪、信任或维护它。企业仓库充斥着机器人生成的噪音和技术债务。
意图工程是专业的解药。它强制将非正式的“氛围”转化为严格的提示契约和意图模式，将AI的生成能力与可验证的逻辑、组织战略和可维护的标准联系起来。
你的角色从编写代码转变为编排可验证的意图管道。如果你使用像Claude Co-worker这样的无代码版本，情况也是如此。
> 引用推文
> 这是我读过的最有见地的关于智能体与框架工程的博客之一，来自OpenAI。1. 工程师（我认为是所有知识工作者）成为环境设计师——工作转变为设计系统、指定意图、构建反馈循环——当某些东西失败时，修复方法是……
> https://x.com/i/web/status/2029427980699644360
4: 成为一名AI工程师#
优秀的提示技巧为上下文工程奠定了基础，而上下文工程又为正确的意图对齐提供了基础。以下是如何正确学习每一层：
以下内容本身就可以成为一篇文章，事实上，我觉得我可能可以出售这些信息，哈哈。相反，我将在这里免费提供给你们所有人，所以至少，如果可以的话请收藏，想的话请关注我，如果你想在你的时间线上获得绝对的金玉良言，请开启帖子通知。让我们开始吧：
1: 学习提示工程#
> 技能1：使用分隔符进行结构化格式化
学习内容：停止将提示写成随意的段落。提示质量最大的飞跃来自于使用明确的结构化分隔符——XML标签、Markdown标题或清晰的部分标记——来将你的指令与数据分开。
为什么重要：当你将指令和数据混合在一个连续的文本块中时，模型必须猜测“我应该做什么”在哪里结束，“我应该处理什么”在哪里开始。这种歧义是大多数输出不一致的根本原因。分隔符消除了猜测。
大多数人犯的错误：像写电子邮件一样写提示。“嘿，你能看看这些数据，也许用一个好的格式总结一下吗？”这给模型零结构指导，并给了它最大的幻觉空间。
如何练习：拿出你上周使用过的任何提示。使用明确的XML标签重写它，将角色、上下文、任务、格式和示例分成不同的部分。运行两个版本并比较输出。
提示模板 - 结构化格式化：
<role>
你是一个[具体角色，例如，专注于SaaS指标的高级数据分析师]。
你用[语气，例如，适合非技术高管受众的清晰、直接的语言]进行沟通。
</role>
<context>
[在此处粘贴你的背景信息、数据或参考资料。
此部分应仅包含模型需要处理的信息——没有指令。]
</context>
<task>
[在此处写下你的具体指令。以强烈的动作动词开头。
明确说明“完成”是什么样子。
示例：“分析<context>中的季度收入数据，并解释第三季度12%下降的三大趋势。”]
</task>
<format>
[定义你期望的确切输出结构。
示例：
- 以一句执行摘要开始
- 接着是3个编号的发现，每个包含：趋势、支持数据点和建议行动
- 以一段总结如果不采取行动的风险的段落结束
- 总长度：300-400字]
</format>
<constraints>
[列出模型绝对不能做的事情。
示例：
- 不要推测<context>中提供的数据之外的内容
- 不要使用行话——用通俗易懂的英语解释任何技术术语