我第一次真正把 Cursor 用进一个稍微复杂点的后端项目时，有一个瞬间印象特别深。
当时只是要加一个接口。
如果放在以前，我大概会先翻一下项目结构，看看现有的 Model（数据模型）、Service（业务服务层）怎么组织，再补 Request、Response，接着写数据库逻辑，最后补测试。
不算难，但怎么也得花点时间。
那次我直接把需求交给了 AI。
没多久，代码出来了。
目录放对了。
接口有了。
SQLAlchemy 也写了。
异常处理看上去像那么回事。
连 pytest 测试都顺手补上了。
我跑了一遍。
通过。
那一刻其实挺容易产生一种错觉：
后端开发好像突然不值钱了。
以前需要半小时、一小时甚至更久完成的事情，现在 AI 几分钟就能干完。
如果顺着这个感觉继续想，很自然就会问：
既然 Cursor、Codex 以后越来越强，后端工程师还剩下什么？
后来我发现，这个问题从一开始就问错了。
真正值得问的不是：
AI 能不能替我写代码？
而是：
当代码越来越容易被生成以后，到底什么东西还需要工程师负责？
我想把这个问题作为整个系列的第一课。
因为如果这件事没想明白，后面不管学 Cursor、Codex、Agent（智能体）、RAG（检索增强生成）还是 MCP（模型上下文协议），最后很容易走向同一个结果：
AI 写得越来越多，人却越来越不知道代码为什么是对的。
而这恰恰是最危险的状态。
先别谈 AI，我们看一段普通得不能再普通的代码
假设产品给了一个需求：
用户提交订单，后端把订单保存下来。
AI 很快写出了这样一个接口：
@app.post("/orders") def create_order( request: CreateOrderRequest, db: Session = Depends(get_db) ): order = Order( user_id=request.user_id, product_id=request.product_id, quantity=request.quantity ) db.add(order) db.commit() db.refresh(order) return order先不要急着往下看。
我希望你真的停几秒，自己判断一下：
这段代码到底对不对？
如果发送一个请求：
POST /orders
数据库里成功多出一条订单记录。
接口返回 200。
订单 ID、商品 ID、数量全部正确。
测试也通过。
那它是不是已经完成需求了？
如果这是刚学后端的时候，我大概率会说：
完成了。
但工作时间越长，我越发现：
“代码对不对”其实是一个非常容易骗人的问题。
因为“对”至少有好几个层次。
而 AI 今天最擅长解决的，恰恰是最表面的那几层。
第一层：代码能运行
最简单的一层叫 Syntax Correctness（语法正确性）。
Python 没报语法错误。
FastAPI 能正常启动。
SQLAlchemy 调用没有写错。
函数能执行。
这一层今天已经越来越不稀缺。
以前忘了某个 API 怎么写，还要翻文档、搜 Stack Overflow。
现在很多时候一句话就够了。
甚至你根本不需要记住某个参数叫什么。
AI 会帮你补。
所以如果一个程序员最大的优势只是：
“这个框架的 API 我特别熟。”
这项能力不会消失，但它的稀缺程度一定会下降。
因为“记住怎么写”这件事，机器已经越来越擅长。
但事情才刚刚开始。
第二层：正常情况下，它能完成需求
再往上一层，是 Functional Correctness（功能正确性）。
也就是：
用户正常调用接口的时候，系统能不能给出正确结果？
刚才那个订单接口显然可以。
用户提交：
商品 1001，数量 2。
数据库插入一张订单。
接口返回订单信息。
所以它在 Happy Path（正常路径）上是正确的。
很多 Demo（演示程序）其实做到这里就结束了。
“看，AI 三分钟帮我们完成订单系统。”
如果你只是演示一个概念，完全没问题。
但真实系统最麻烦的地方，从来不是 Happy Path。
真实世界不会一直按照你写 Demo 时设计的剧本运行。
我们稍微改变一下条件。
用户连续点了两次“提交订单”，会发生什么？
第一次请求已经到达服务器。
数据库也成功创建了订单。
但是返回结果的时候，用户网络突然抖了一下。
前端没有收到响应。
用户看到页面一直转圈。
他不知道订单到底成功没有，于是又点了一次。
于是服务器收到了两个请求。
刚才那段代码会怎么做？
很简单。
创建两张订单。
注意这里最有意思的地方：
每一行代码可能都是正确的。
数据库没有报错。
框架没有报错。
两个请求也都返回了 200。
可整个系统就是错了。
为什么？
因为真正的业务规则可能是：
同一次下单行为，无论客户端重复提交多少次，都只能产生一张订单。
这时候你才真正进入后端工程。
这里会碰到一个词：
Idempotency（幂等性）。
第一次看到这个词，很容易觉得玄乎。
其实意思非常朴素：
同一件事情重复执行，不应该产生你不希望出现的额外结果。
查询订单重复执行十次，通常没什么。
但是：
支付接口执行两次呢？
扣库存执行两次呢？
优惠券领取执行两次呢？
发货指令执行两次呢？
到了这些场景，幂等就不是一个“高级知识点”。
它直接决定系统会不会出事故。
所以你现在应该已经能感觉到一个变化。
我们讨论的已经不再是：
“Python 怎么写？”
而是：
真实世界出现重复、失败和异常以后，系统应该保持什么状态？
这就是 Engineering（工程）。
代码能跑，和系统真的正确，中间隔着很远
我们继续把订单场景往真实世界推一步。
真实下单通常不会只做一件事情。
它可能需要：
创建订单。
扣减库存。
写支付记录。
发送消息。
记录操作日志。
现在假设创建订单成功了，库存也扣了。
但是发送消息的时候，MQ（Message Queue，消息队列）突然超时。
怎么办？
订单应该保留还是回滚？
如果保留，消息怎么补发？
如果回滚，库存怎么办？
再换一个情况。
数据库已经 Commit（提交）成功，但服务器在把结果返回给客户端之前挂掉了。
客户端不知道到底成功还是失败，于是 Retry（重试）。
第二次请求应该返回第一次的订单，还是重新创建？
再来一个。
库存只剩 1 件。
两个用户几乎同时提交订单。
请求 A 查询：
库存 = 1。
请求 B 也查询：
库存 = 1。
于是 A 认为可以买。
B 也认为可以买。
最后卖出了两件。
代码还能不能运行？
当然能。
甚至两个请求都有可能返回 200。
但是你的库存已经变成了一个谎言。
这就是为什么我后来越来越不喜欢一句话：
“这个接口已经写完了。”
我更愿意问：
它已经解决了哪些情况？还有哪些情况没有被定义？
这两个问题听起来差不多，背后的工程水平完全不同。
真正的后端工程，往往从“失败”开始
刚学后端的时候，我们通常是顺着成功路径理解系统的。
请求进来。
参数校验。
调用 Service。
写数据库。
返回结果。
这个学习顺序没问题。
但是一旦进入真实项目，我建议你开始训练另一种思维：
不要只顺着成功往下走，要故意把系统“掰断”。
数据库写到一半失败了呢？
Redis 不可用了呢？
第三方接口 30 秒不返回呢？
客户端重复请求呢？
两个请求同时修改同一条数据呢？
Worker（后台任务进程）执行到一半重启呢？
一条消息被消费两次呢？
代码发布了一半需要回滚呢？
用户没有权限却构造请求呢？
日志只有一句 “Internal Server Error”，线上怎么定位呢？
这些问题第一次看，会觉得特别杂。
实际上它们背后都在问同一件事情：
当现实世界不配合你的代码时，系统还能不能保持正确？
这句话，我认为是理解 Production Engineering（生产级工程）非常重要的一把钥匙。
Demo 关注：
成功的时候能不能跑通。
Production（生产环境）更关心：
失败的时候会不会失控。
一旦真正理解这句话，很多以前觉得“为什么要学”的东西就突然串起来了。
Transaction（事务）为什么重要？
因为执行到一半可能失败。
Retry（重试）为什么危险？
因为同一件事可能被执行两次。
Idempotency（幂等）为什么重要？
因为网络世界里你永远不能假设请求只到一次。
Lock（锁）和 Concurrency Control（并发控制）为什么存在？
因为两个正确的请求同时执行，也可能得到错误结果。
Logging（日志）和 Tracing（链路追踪）为什么不是“上线以后再说”？
因为系统一旦复杂，你必须知道到底是哪一步出了问题。
这些词并不是后端工程师故意把事情搞复杂。
它们都是现实世界逼出来的。
到这里，我们终于可以重新看 AI Coding
现在再回过头看 Cursor 和 Codex，就会清楚很多。
AI 今天非常擅长什么？
你给它一个相对明确的需求，它可以快速把这个需求翻译成代码。
例如：
“实现一个分页查询接口。”
“给这个模型增加 CRUD（增删改查）。”
“按照现有模式补一个 Service。”
“给这些函数生成单元测试。”
这些事情本质上有一个共同点：
目标已经比较明确，剩下的是实现。
而软件开发过去最耗时间的一部分，恰恰就是把这些明确意图一点点翻译成代码。
以前你脑子里知道应该怎么做，还需要：
找 API。
写样板代码。
改类型。
补 import。
调格式。
写重复的 Repository。
补测试骨架。
现在 AI 把这段距离大幅压缩了。
所以我更愿意这样描述 AI Coding 带来的变化：
AI 没有先拿走“软件工程”，它先拿走的是大量“把明确设计翻译成代码”的劳动。
这两件事情不是一回事。
一个非常关键的分界线：AI 可以替你实现，但它不能凭空知道你的业务世界
还是刚才那个订单接口。
如果你只告诉 AI：
“实现创建订单。”
它不知道什么？
它不知道同一个请求能不能重复。
不知道库存是否必须同时扣减。
不知道订单创建和库存修改是否要求强一致。
不知道失败后是 Rollback（回滚）还是 Compensation（补偿）。
不知道系统有没有 Redis。
不知道有没有统一错误码。
不知道数据库事务在哪一层管理。
不知道这个项目禁止不禁止 Controller（控制器）直接访问数据库。
不知道你的日志规范。
不知道历史架构为什么这么设计。
那它怎么办？
它只能根据过去学过的大量代码，给你一个“通常看起来合理”的答案。
这里有一个我觉得非常值得警惕的地方：
生成式 AI 最危险的能力之一，是它可以把“合理猜测”写得非常像“确定答案”。
代码命名很好。
注释很完整。
抽象看起来也专业。
甚至还有测试。
人一看，很容易放松。
传统的新手代码有时候反而比较安全。
因为写得乱，你一眼知道需要 Review（审查）。
AI 代码的问题是：
它经常长得太像正确答案。
所以我现在拿到 AI 生成代码，首先看的已经不是：
“写得漂不漂亮？”
而是：
它做出这些决定时，到底掌握了哪些信息？
这个问题会直接把我们带到整套课程后面一个非常重要的主题：
Context Engineering（上下文工程）。
Prompt 不是最重要的，AI 知道什么才重要
Prompt（提示词）当然有用。
但很多人刚开始 AI Coding 时，会把大量时间花在研究：
有没有“万能 Prompt”？
怎么写一句话让 Cursor 更聪明？
有没有一段神级指令，让 AI 一次写对？
后来我越来越觉得，方向有点偏。
比如还是做登录。
你只说：
“帮我实现用户登录。”
AI 必须自己猜：
密码算法是什么？
JWT 放在哪里？
Token（令牌）多久过期？
用户不存在返回什么错误？
密码错误返回什么？
Controller 能不能碰数据库？
项目有没有 Repository Pattern（仓储模式）？
测试放在哪？
安全模块能不能改？
这种情况下 Prompt 再漂亮，AI 还是缺信息。
换一种方式。
我会先让它读项目里的架构说明、用户模型、现有认证 Service、安全模块和测试。
然后告诉它：
这次需要增加什么能力。
哪些现有设计不能改。
必须复用哪些已有组件。
错误响应必须遵守什么规范。
需要补哪些测试。
最后再加一句：
先分析，不要写代码。
差别马上就出来了。
第一种方式本质上是在问：
“你觉得登录应该怎么写？”
第二种方式是在告诉它：
“在我的系统里，登录应该满足什么规则。”
这就是 Prompt 和 Context（上下文）的区别。
Prompt 更像是：
你现在想让我做什么？
Context 更像是：
我在做决定之前，应该知道哪些事实？
复杂项目里，后者通常更重要。
有一个概念，我希望你从第一课就学会：Invariant
Invariant，中文一般翻译为“不变量”。
名字有点数学味。
但它是一个非常适合工程师思考问题的概念。
什么叫不变量？
最简单的理解：
无论系统经历多少请求、失败、重试和并发，有些规则始终不能被破坏。
比如库存系统：
库存不能无缘无故变成负数。
支付系统：
同一笔业务不能因为重试被重复扣款。
权限系统：
普通用户不能读取管理员数据。
优惠券系统：
如果规则规定每人只能领取一次，同一个用户就不能因为并发请求拿到两张。
转账系统：
钱不能凭空产生，也不能凭空消失。
你会发现，这些才是真正应该被系统保护的东西。
代码只是保护这些规则的一种手段。
这会彻底改变你看需求的方式。
新手拿到需求：
“做一个优惠券领取接口。”
第一反应往往是：
URL 怎么设计？
POST 还是 GET？
Service 怎么写？
高级一点的工程师会先问：
这个功能有哪些规则绝对不能被破坏？
比如：
优惠券必须存在。
必须在有效期内。
库存必须大于 0。
同一用户只能领取一次。
总领取数量不能超过发行量。
没有登录不能领取。
失败不能留下半条脏数据。
注意，我们现在还没有写任何代码。
但真正重要的设计已经开始了。
接下来才轮到：
这些规则由数据库约束保证，还是业务层保证？
需要唯一索引吗？
需要事务吗？
需要锁吗？
需要幂等 Key（幂等键）吗？
哪些场景必须测试？
这就是我认为 AI 时代一个非常值得训练的习惯：
拿到需求，先找不变量，再想代码。
因为 AI 特别擅长写代码。
但“不变量到底是什么”，往往来自你对业务和系统的理解。
为什么高级工程师经常不急着写代码？
以前我刚开始做开发的时候，也不太理解。
明明需求已经来了，为什么有些人还要开会、画流程、看旧代码、讨论边界？
赶紧写不就行了吗？
后来做的系统越复杂越明白：
工程里最贵的错误，往往不是代码写错，而是把错误的理解实现得非常完整。
这件事在 AI Coding 时代会更加明显。
以前一个错误方案，你可能写两天才写完。
写到一半发现不对，还有机会停下来。
现在呢？
AI 十分钟就能改十几个文件。
Service 写完。
Repository 写完。
Migration（数据库迁移）写完。
测试也写完。
甚至文档都给你补好了。
看上去效率爆炸。
问题是：
如果方向错了，它只是帮你更高效地走错路。
所以我现在越来越重视一个很简单的习惯：
Plan First，先做方案，再写代码。
“给任务增加取消功能”，到底难在哪里？
举一个后面做 AI Backend 时特别常见的例子。
需求只有一句：
“给 AI Task（AI 任务）增加取消功能。”
看起来简单。
可能很多人已经准备让 Cursor 写：
Implement task cancellation。
也就是：
实现任务取消。
但先别写。
问一个问题：
什么叫“取消成功”？
任务还在 Pending（等待中）状态，很简单，改成 Cancelled（已取消）。
如果任务已经被 Worker 取走了呢？
如果正在调用 LLM（大语言模型）呢？
如果 LLM 已经返回，正在写数据库呢？
如果用户点击取消的同时，Worker 正好把任务执行完成呢？
如果客户端连续发两次取消请求呢？
如果取消后服务重启呢？
取消以后还能不能 Retry（重试）？
用户看到的是“取消请求已接收”，还是“任务已经停止”？
这时候你会突然发现：
真正困难的不是：
cancel() 这个函数怎么写。
真正困难的是：
系统对“取消”这两个字到底怎么定义。
定义没弄清楚之前，让 AI 开始写代码，本质上就是让它替你做产品定义和架构决策。
它当然可以给答案。
但你凭什么认为那个答案适合你的系统？
所以复杂 Feature（功能）以后不要习惯：
Requirement（需求）→ Code（代码）。
更合理的顺序是：
Requirement（需求）→Analysis（分析）→Plan（方案）→Review（审查）→Code（编码）
表面上多了几步。
实际上项目越大，越省时间。
我现在使用 AI Coding，基本遵循这样一个循环
这也是整套课程后面会反复使用的一条主线。
我把它叫做：
AI Native Development Loop（AI 原生开发循环）。
很简单，六步：
Context→Plan→Code→Test→Review→Production
不要急着背。
我们把它翻译成人话。
Context：先让 AI 有资格回答这个问题
第一步不是问：
“我要它写什么？”
而是：
“它如果想把这件事情做对，必须先知道什么？”
可能是项目架构。
可能是数据库模型。
可能是现有 Service。
可能是团队的 Coding Rules（编码规则）。
可能是 API 规范。
可能是历史设计决策。
可能是哪些目录允许改、哪些禁止改。
可能是现有测试。
Context 做得差，AI 就是在一个它自己想象出来的项目里写代码。
Context 做得好，它才真正开始在你的项目里工作。
Plan：让错误尽量死在代码出现之前
让 AI 先告诉你：
它理解的需求是什么？
准备修改哪些模块？
为什么改这些地方？
有没有数据库变化？
会不会影响已有接口？
有哪些并发风险？
有没有安全问题？
测试准备怎么做？
有没有更简单的方案？
这一步有一个非常重要的经济账。
修改一段 Plan，成本可能是几分钟。
AI 已经改完十五个文件之后再推倒重来，成本就完全不同了。
所以 Plan 不是形式主义。
它是在控制错误扩散的成本。
Code：AI 最应该发挥优势的地方
前面两步完成以后，才真正开始 Coding（编码）。
这时候 AI 手里已经有：
需求。
上下文。
约束。
方案。
测试要求。
于是它的任务发生了变化。
不再是：
“你猜一下这个功能应该怎么做。”
而是：
“按照已经确认的工程方案，把它实现出来。”
这才是 Coding Agent（编程智能体）最舒服的位置。
我一直觉得一句话很重要：
Agent 应该承担大量执行，但不应该在你毫不知情的情况下替你决定系统长什么样。
Test：测试不是证明代码跑过一次
AI 很会写 Test（测试）。
但“会生成测试代码”和“知道什么值得测试”是两回事。
比如创建订单。
AI 很容易写：
def test_create_order(): response = client.post("/orders", json=data) assert response.status_code == 200没有问题。
但它只证明了一件事：
正常情况下接口返回成功。
真正更值钱的测试是什么？
同一个请求执行两次呢？
库存不足呢？
两个用户同时购买最后一件商品呢？
数据库在执行中间报错呢？
Retry 会不会重复创建订单呢？
没有权限呢？
参数刚好在边界值呢？
你会发现：
好的测试，本质上是在保护前面找到的那些 Invariant（不变量）。
一旦理解这个逻辑，Testing（测试）就不再是：
“写几个 assert。”
而是在问：
我怎么证明系统最重要的规则不会被破坏？
这是完全不同的层次。
Review：别再只看代码风格
AI 时代 Review（代码审查）会越来越重要。
原因很简单：
AI 生成代码的速度，已经开始超过人类认真阅读代码的速度。
以前一天写三百行，你 Review 三百行。
以后 Agent 十几分钟改两千行。
难道真的逐字符看两千行？
不现实。
所以 Review 思路本身也要升级。
你需要看：
Architecture（架构）有没有被破坏。
Transaction Boundary（事务边界）对不对。
Data Consistency（数据一致性）有没有风险。
Concurrency（并发）有没有问题。
Security（安全）有没有漏洞。
Failure Path（失败路径）有没有遗漏。
Observability（可观测性）够不够。
Test（测试）到底证明了什么。
这时候你会发现：
AI Coding 并没有让工程判断变少。
恰恰相反。
因为机器可以更快地产生更多代码，判断哪些代码可以进入系统反而更重要。
Production：真正精彩的地方，从“代码能跑”之后才开始
这是整个系列我最想反复讲的一件事。
很多教程在这里结束：
“运行成功。”
我更关心后面。
比如 AI 写了这样一段逻辑：
for item in items: result = call_llm(item) save_result(result)本地跑十条数据，完美。
现在放到 Production（生产环境）。
如果是五千条呢？
LLM 第 237 条调用超时呢？
跑了二十分钟服务重启呢？
第三方模型接口限流呢？
前三千条已经成功，后两千条失败呢？
重新执行会不会把前三千条再处理一次？
用户关掉浏览器以后，任务还继续吗？
进度保存在哪里？
任务怎么取消？
失败以后能不能恢复？
调用费用怎么限制？
线上出了问题，怎么找到这一次 Task 的完整执行链路？
看到了吗？
代码没变。
环境一变，问题完全不同。
所以 Production Engineering（生产级工程）真正研究的是：
如何让一个功能在真实流量、真实失败、真实并发和真实运维条件下继续可信。
这才是后端工程师越来越值钱的地方。
如果以后只允许我给 AI Coding 用户一张检查清单，我会留下这 8 个问题
以后拿到任何稍微重要一点的后端需求，不管代码准备自己写还是交给 AI，先问：
1. 到底什么才算成功？
“取消成功”“支付成功”“发送成功”“保存成功”，这些词必须能被精确定义。
定义不清楚，后面的代码一定会乱。
2. 什么事情绝对不能发生？
找 Invariant（不变量）。
钱不能重复扣。
库存不能乱。
权限不能越界。
数据不能无缘无故丢。
3. 做到一半失败怎么办？
考虑 Transaction（事务）、Rollback（回滚）、Compensation（补偿）。
4. 同一个请求来两次怎么办？
考虑 Idempotency（幂等性）。
尤其涉及扣款、下单、发券、发送消息时。
5. 两个请求同时发生怎么办？
考虑 Concurrency（并发）、Race Condition（竞态条件）以及必要的锁或数据库约束。
6. 依赖的系统不工作怎么办？
数据库慢了。
Redis 挂了。
LLM 超时了。
第三方 API 返回 500。
这时要考虑 Timeout（超时）、Retry（重试）、Fallback（降级）等策略。
7. 出问题以后，我怎么知道发生了什么？
考虑 Logging（日志）、Tracing（链路追踪）、Metrics（指标监控）。
8. 我怎么证明这个实现真的没有破坏规则？
这才轮到 Test（测试）。
而且不要只测正常路径。
重复、失败、边界、并发，往往才是最值钱的地方。
这八个问题不是什么高级架构师专属能力。
我反而认为，AI Coding 普及以后，它们会逐渐变成后端工程师的基本功。
现在，我们终于可以回答文章开头的问题了
Cursor、Codex 越来越强之后，后端工程师还重要吗？
重要。
但值钱的部分正在发生变化。
以前，一个工程师要花大量时间亲自把设计变成代码。
记 API。
写 CRUD。
补样板代码。
查文档。
改重复逻辑。
这些工作不会一夜之间消失。
但是 AI 会持续降低它们的成本。
真正开始变贵的是什么？
是这些问题：
这个需求到底应该怎么定义？
系统有哪些不能被破坏的规则？
这段操作应该同步还是异步？
为什么这里必须幂等？
事务边界应该在哪里？
Retry 为什么可能造成重复副作用？
这个方案在并发下还成立吗？
AI 第一次生成的代码，到底哪里“不够对”？
怎么证明它可以进入生产环境？
这些事情有一个共同名字：
Engineering Judgment（工程判断）。
所以我越来越认可一个结论：
代码生成正在变便宜，工程判断正在变贵。
AI Native Backend Engineer，到底“Native”在哪里？
这套课程后面会反复出现一个词：
AI Native Backend Engineer（AI 原生后端工程师）。
它不是指：
“100% 的代码都必须让 AI 写。”
也不是：
“谁 Prompt 写得厉害，谁就是 AI Native。”
我理解的 AI Native，是：
从开发流程设计开始，就默认 AI 是工程执行体系的一部分。
你会主动思考：
AI 需要读取哪些 Context（上下文）。
哪些架构规则必须提前告诉它。
哪些文件可以改。
哪些文件不能碰。
复杂需求是不是必须先 Plan（规划）。
什么测试必须通过。
生成完以后应该做哪些 Review（审查）。
上线前必须做哪些 Production Check（生产检查）。
也就是说，你已经不是单纯在“用一个写代码工具”。
你开始设计：
AI 应该怎样参与软件工程。
这是两个完全不同的层级。
我们真正要走的，不是 Prompt to Code
现在大量 AI Coding 内容都停在一条很短的路线：
Prompt→Code
给一句提示词。
生成代码。
运行成功。
结束。
但真实的软件世界远远不是这样。
我们真正要走的是：
Prompt→Context→Plan→Architecture→Code
↓
Test→Review→Deploy→Observe→Production
也就是：
Prompt to Production（从提示到生产）。
从一个模糊需求开始。
直到它成为一个真实用户可以放心使用、出了问题工程师也有能力定位和恢复的系统。
这才是整套课程真正要研究的事情。
我们当然会写 FastAPI。
会碰 PostgreSQL。
会用 Redis。
会做异步任务。
会接 LLM（大语言模型）。
会做 RAG（检索增强生成）。
会实现 Agent（智能体）。
会研究 Tool Calling（工具调用）和 MCP（模型上下文协议）。
最后还会走到 Docker、CI/CD（持续集成与持续交付）、Observability（可观测性）和 Production（生产环境）。
但所有这些技术都只是手段。
真正想训练的是同一种能力：
AI 可以替你大量生成实现，但你必须越来越清楚什么才叫正确。
第一课学到这里，我只希望你真正带走三件事
第一件：
代码能跑，和系统正确，不是一回事。
以后看到 AI 生成代码，不要只验证“成功路径”。
主动去找重复、失败、并发、边界和真实生产环境里的问题。
第二件：
AI 最擅长降低的是实现成本，不是替你定义业务世界。
需求的边界、不变量、风险和工程约束，仍然需要有人真正理解。
第三件：
复杂任务不要从 Requirement（需求）直接跳到 Code（编码）。
逐渐形成自己的开发节奏：
Context→Plan→Code→Test→Review→Production
如果这三件事真的进入你的开发习惯，那么以后即使 Cursor 被另一个工具替代、Codex 继续升级、Coding Agent 再强十倍，这套方法依然成立。
因为工具会变。
框架会变。
模型会变。
但只要软件最终还要运行在真实世界里，就一定有人需要回答：
什么叫正确？
失败了怎么办？
我怎么证明它值得上线？
这个人，依然是工程师。
只不过从今天开始，我们要学着成为另一种工程师：
AI Native Backend Engineer。
不是比 AI 更快地敲代码。
而是比以前更清楚：
什么代码值得被写出来。
下一课，我们继续往下拆：
当 Coding（编码）越来越容易以后，程序员真正稀缺的能力，到底还剩什么？
答案会比“学好架构”这四个字具体得多。
