From Software Engineer to AI Engineer - Part 1: A whole new world
From Software Engineer to AI Engineer - Part 1: A whole new world
从软件工程师到 AI 工程师 - 第一部分：全新的世界
You are a software engineer. Your craft honed through years of careful practice. Then suddenly, there are these chatbots and agents. Overnight, your colleagues got a new title on LinkedIn: “AI engineer”. Some are already SENIOR AI engineers. You’re curious about this new world, and might want to catch up and become part of it yourself. 你是一名软件工程师，你的技艺经过多年的精心磨练。突然之间，聊天机器人和智能体出现了。一夜之间，你的同事们在 LinkedIn 上有了新的头衔：“AI 工程师”。有些人甚至已经是“资深 AI 工程师”了。你对这个新世界感到好奇，或许也想迎头赶上，成为其中的一员。
If this is you, then join me on this tour through the concepts and patterns that make up the field of AI engineering. We will find that AI application development is mostly ‘just’ software engineering, applied to one genuinely strange new non-deterministic component: the LLM. During the tour, we build a real application, end to end. Every article adds a new layer. We link the new patterns and words to existing software engineering concepts you already know. 如果你正是这样，那么请加入我的行列，一起探索构成 AI 工程领域的概念和模式。我们会发现，AI 应用开发其实“不过是”软件工程，只不过应用在一个真正陌生且非确定性的新组件上：大语言模型（LLM）。在这次旅程中，我们将从头到尾构建一个真实的应用程序。每一篇文章都会增加一个新的层面，我们会将新的模式和术语与你已经熟悉的软件工程概念联系起来。
Before take-off, I’d like to establish one vocabulary rule used throughout: “the model” means the LLM itself (large language model, like GPT or Claude), and what AI engineers build around it will be referred to as “the application”, “the agent” or “the harness”. 在起飞之前，我想先确立一个贯穿全文的词汇规则：“模型”（the model）指代 LLM 本身（如 GPT 或 Claude），而 AI 工程师围绕它构建的内容将被统称为“应用程序”（the application）、“智能体”（the agent）或“外壳”（the harness）。
What we’re building As I work at a payments company myself, I figured I’d stick to my domain. PayIQ, the application we build, is an assistant for merchants to perform payment operations: issue refunds, defend chargebacks, calculate processing fees. Give it a charge amount and a payment method, and it computes what a refund actually costs (spoiler: more than the refund amount). Ask it whether a chargeback is worth fighting, and it does the expected-value math using your knowledge base. Ask it something it can’t responsibly answer, and it asks for what’s missing. No guessing, no hallucinations. 我们要构建什么：由于我自己就在一家支付公司工作，我想还是专注于我的领域。我们将构建的应用程序 PayIQ 是一个帮助商户执行支付操作的助手：处理退款、应对拒付、计算手续费。给它一个扣款金额和支付方式，它就能计算出退款的实际成本（剧透：比退款金额本身还要高）。问它拒付是否值得申诉，它会利用你的知识库进行期望值计算。问它无法负责任回答的问题，它会询问缺失的信息。不猜测，不产生幻觉。
By the end, PayIQ will have structured outputs that can be consumed by other systems, a tool belt of financial calculators, retrieval over a knowledge base, an agent loop with persistent memory, an orchestration graph with steps the model cannot skip, token streaming behind a FastAPI service, a regression eval suite, and layered injection defense. And don’t worry if some of those words mean nothing to you. That’s only a matter of time from here. 最终，PayIQ 将具备以下功能：可供其他系统调用的结构化输出、一套金融计算工具、基于知识库的检索、带有持久化记忆的智能体循环、模型无法跳过的编排图、基于 FastAPI 服务的 Token 流式传输、回归评估套件以及分层注入防御。如果其中一些词对你来说很陌生，别担心，这只是时间问题。
Each article is 10-15 minutes of reading and builds on the earlier ones deliberately (part 2’s structured output is used in part 3’s tool usage), so I suggest going through them sequentially. This first article lays the foundations and performs a simple interaction with the model. 每篇文章阅读时间约为 10-15 分钟，并且刻意建立在之前文章的基础上（第二部分的结构化输出将用于第三部分的工具使用），因此我建议按顺序阅读。第一篇文章将奠定基础，并与模型进行一次简单的交互。
A companion repository (https://github.com/BjornvdLaan/ai-engineering-articles-code-samples) contains all the code samples so that you can try it yourself as well. The examples use Anthropic’s models. If you prefer a different provider (or locally hosted models) then I am sure your favorite chatbot can help adjust the configuration for you. No worries, LangChain’s libraries are (mostly) model-agnostic. 配套仓库 (https://github.com/BjornvdLaan/ai-engineering-articles-code-samples) 包含了所有代码示例，以便你可以亲自尝试。这些示例使用的是 Anthropic 的模型。如果你更喜欢其他提供商（或本地部署的模型），我相信你最喜欢的聊天机器人可以帮你调整配置。不用担心，LangChain 的库（大部分）是与模型无关的。
The mental model for thinking about models Before getting into the code, let’s build an accurate mental model of what models actually are. Not how neural networks or transformers work internally - we will leave that to smart scientists. What you as an aspiring AI engineer need is the operational mental model: what this thing consumes, what it costs, and what you can control. 关于模型的思维模型：在进入代码之前，让我们建立一个关于模型本质的准确思维模型。不是关于神经网络或 Transformer 内部如何运作——我们将这些留给聪明的科学家。作为一名有抱负的 AI 工程师，你需要的是操作层面的思维模型：它消耗什么、成本如何，以及你可以控制什么。
In its simplest form, a model is simply this interface: f(list of input messages) -> output message. That’s it. An important detail is that the input is a list of messages, not just the last prompt you gave. Each call to the model typically includes a system message (“application configuration”), the whole conversation so far (“the current state”), and the latest prompt. Given all these preceding messages, the model produces the next message in the conversation. 最简单的形式下，模型就是一个接口：f(输入消息列表) -> 输出消息。仅此而已。一个重要的细节是，输入是一个消息列表，而不仅仅是你给出的最后一条提示词。每次对模型的调用通常包括系统消息（“应用程序配置”）、到目前为止的整个对话（“当前状态”）以及最新的提示词。根据所有这些先前的消息，模型会生成对话中的下一条消息。
If you have used Codex, Claude Code or other “harnesses” then this might sound weird. You see it searching the internet, memorizing facts from previous sessions, keeping a todo list, reading documents you give it, writing and editing a codebase. All that magic is application logic built around the model by AI engineers, but all the model sees is just a list of input messages. 如果你使用过 Codex、Claude Code 或其他“外壳”，这听起来可能很奇怪。你看到它在搜索互联网、记住之前会话的事实、维护待办事项列表、阅读你提供的文档、编写和编辑代码库。所有这些魔法都是 AI 工程师围绕模型构建的应用程序逻辑，但模型所看到的仅仅是一个输入消息列表。
Tokens: the unit of everything Messages are sent to a model as tokens, not characters or words. A component called a tokenizer first splits the text into tokens and assigns each a numeric token ID. Common words are often a single token, while uncommon words may be split into several. The model never sees the original text: it only processes these token IDs. Token：万物的单位。消息是以 Token（标记）而非字符或单词的形式发送给模型的。一个称为分词器（tokenizer）的组件首先将文本拆分为 Token，并为每个 Token 分配一个数字 ID。常用词通常是一个 Token，而不常用的词可能会被拆分为多个。模型永远看不到原始文本：它只处理这些 Token ID。
Besides serving as a unit of computation, tokens are also important because they are the unit of billing. You pay per input and output token. Treat tokens the way you treat compute-seconds in a cloud bill. An AI feature is the first kind of backend endpoint where the cost of a single request is large enough to care about. An agent that makes five model calls per user request costs real money at production traffic volumes. 除了作为计算单位外，Token 也很重要，因为它们是计费单位。你按输入和输出的 Token 数量付费。对待 Token 就像对待云账单中的计算秒数一样。AI 功能是第一种单次请求成本高到需要关注的后端接口。一个在每个用户请求中调用五次模型的智能体，在生产流量下会产生实实在在的费用。
This is also a new security risk. Traditionally, a DDoS attack primarily consumed infrastructure resources (CPU, memory, bandwidth, and autoscaled instances). Now, every request may also consume billable tokens, adding a second, potentially much larger, cost component. The attack even has its own name: denial of wallet. 这也是一种新的安全风险。传统上，DDoS 攻击主要消耗基础设施资源（CPU、内存、带宽和自动伸缩实例）。现在，每个请求还可能消耗可计费的 Token，增加了第二个、可能大得多的成本组成部分。这种攻击甚至有自己的名字：拒绝钱包攻击（denial of wallet）。
The context window: the model’s input limit Each model has a maximum number of input tokens that it can process. This is called its context window, and can often hold hundreds of thousands of tokens. As discussed above, everything the model needs to answer a request must fit inside it: your system prompt, the conversation so far, retrieved documents, tool results, and any other context you provide. 上下文窗口：模型的输入限制。每个模型都有其能处理的最大输入 Token 数量。这被称为上下文窗口，通常可以容纳数十万个 Token。如上所述，模型回答请求所需的一切都必须放入其中：你的系统提示词、到目前为止的对话、检索到的文档、工具结果以及你提供的任何其他上下文。
Think of it as the model’s working memory. A larger context window lets you provide more information, but more context is not always better. As irrelevant information accumulates, the model has more distractions and important details become easier to miss. You will see this called context rot. More input tokens will also cost you more money! This is why “just paste everything in” doesn’t scale: context engineering is about quality over quantity. 把它想象成模型的工作记忆。更大的上下文窗口允许你提供更多信息，但更多的上下文并不总是更好。随着无关信息的积累，模型会受到更多干扰，重要的细节也更容易被忽略。你会看到这被称为“上下文腐烂”（context rot）。更多的输入 Token 也会让你花费更多的钱！这就是为什么“把所有东西都粘贴进去”是不可扩展的：上下文工程讲究的是质量而非数量。
Setup Now that… 设置：既然……