后端转型 AI 工程师：第一个月该看什么代码，不该看什么

一、打开 GitHub，Star 最多的 AI 项目都看不懂

转 AI 的第一步，往往是在 GitHub 上搜"LLM application"。出来的结果是 LangChain、LlamaIndex、AutoGPT。Clone 下来打开源码，类继承关系深到让人窒息。Callback 嵌套 Callback，Prompt 模板套 Prompt 模板。

一个后端工程师的本能反应是：看源码，理解全貌。但在 AI 工程化的第一个月，这个策略是错误的。你不需要理解 LangChain 的所有抽象层。你需要理解的是：一个请求从用户输入到模型输出，中间经过了几步。

转型期的核心矛盾是：框架太厚，原理太薄。一个月的时间应该花在原理上，而非框架上。框架可以后面再看源码了解细节，但第一个月的目标不是"看懂框架源码"，而是"能独立写代码完成一个端到端的 AI 功能"。

二、第一个月的学习路径：先看"输油管"，再看"炼油厂"

AI 工程化的本质是把模型能力接入业务系统。把 LLM 当作一个强大的 API，而非黑魔法。

flowchart LR
    A[Week1: 理解 API] --> B[Week2: 读写 Context]
    B --> C[Week3: 工具调用]
    C --> D[Week4: 评估与排错]

    subgraph "该看的代码"
        A1[OpenAI SDK 基础调用]
        B1[Prompt Template 实现]
        C1[Function Calling Demo]
        D1[LangSmith/LangFuse 链路]
    end

    subgraph "不该看的代码"
        E1[LangChain 源码全量]
        E2[Transformer 模型实现]
        E3[向量数据库内核]
        E4[自建训练 Pipeline]
    end

    A -.-> A1
    B -.-> B1
    C -.-> C1
    D -.-> D1

    A -.->|跳过| E1
    B -.->|跳过| E2
    C -.->|跳过| E3
    D -.->|跳过| E4

第一周：从 OpenAI Python SDK 的示例代码开始。理解 Chat Completion API 的基本调用。理解 System Prompt、User Prompt、Assistant 消息的角色。用不超过 50 行代码写一个命令行问答程序。

第二周：深入 Prompt 工程。读 Anthropic 的 Prompt Engineering Guide。动手改 Prompt，观察输出变化。理解 Few-shot、Chain-of-Thought 的实际效果。

第三周：Function Calling。这是后端工程师最有优势的环节。理解模型的 tool_choice 机制。写一个带函数调用的 Agent 原型——比如查询天气、查数据库、发邮件，三个工具让模型自己决定调用哪个。

第四周：可观测性。接入 LangFuse 或 LangSmith。查看真实的 token 消耗、延迟分布、错误率。这是从原型到生产的桥梁。你能看到每一次调用的完整轨迹：输入 prompt 是什么、模型返回了什么、花了多少 token 和时间。

每周结束后都应该能拿出一个可运行的 Demo。不是看完资料就行，是代码能跑、能看到结果。后端工程师最知道"看了一百篇文档不如调通一次 API"。

三、不该花时间的领域

第一，不要深入 Transformer 架构底层。自注意力机制的数学推导对应用开发帮助有限。把这部分当作"操作系统内核"——知道接口即可。你可以花一个小时了解 Transformer 的直觉理解：它其实就是"计算一个词和上下文中其他词的关联度"。这个直觉理解足够支撑应用开发。

第二，不要纠结模型微调。一个月的窗口期，微调一个模型并上线不现实。先用好 API，再考虑微调。而且现在 API 模型的能力越来越强，大部分场景微调的收益在缩小——与其花大量时间准备训练数据和微调，不如把时间花在 Prompt 优化和 RAG 设计上。

第三，不要盲目追新框架。AI 框架的迭代速度是传统后端框架的 10 倍。今天学的 API 下个月可能 deprecated。投资在稳定的概念上：Prompt、Context、Tool。这三样东西不管框架怎么变，概念不会变。框架只是封装方式不同，核心概念才是能迁移的资产。

四、后端技能如何迁移

你已有的技能在 AI 工程化中价值很高。

Go 的并发模型可以直接用于 Agent 的工具并行调用——多个工具同时调用时，goroutine 天然适配。数据库设计能力用于构建向量检索的元数据层——权限过滤、租户隔离这些概念在 RAG 系统中同样适用。API 设计能力用于封装模型服务——对外屏蔽模型供应商差异，对内统一调用接口和错误处理。

但有一个心态陷阱需要警惕。后端工程师习惯精确控制——每个 if-else 都是确定的。AI 的输出是不确定的。需要从"保证正确"转变为"降低错误率"。从二值思维（对/错）转变为概率思维（P99 准确率 95%）。

这个心态转变不是一蹴而就的。我的经验是：先用确定性思维搭好框架（超时、重试、权限、缓存），再用概率思维评估模型输出（允许不确定、设计降级、接受误差）。两者不是矛盾的——确定性框架保护的恰恰是概率性模型。框架越确定，模型的不确定性越可控。

五、总结

转型第一个月应聚焦 API 调用、Prompt 工程、Function Calling、可观测性。避免深入模型训练、框架源码、前沿论文。后端技能（并发、API 设计、数据库）可直接迁移。心态上需要从确定性编程转向概率性编程。一个月后，你能独立搭建一个带工具调用的 AI Agent 原型——这就够了，接下来的路是用项目继续深化。