第一课写到最后我留下了一个问题当 Coding编码越来越容易以后程序员真正稀缺的能力到底还剩什么这个问题其实是上一课最重要的延伸。上一课我们花了很大篇幅讲一件事代码能运行不等于系统是正确的。一个接口可以返回 200测试可以全部通过每一行代码甚至都没有明显错误但放进真实系统以后仍然可能因为重复请求、失败、并发、权限、状态不一致而出问题。最后我们得到一个结论代码生成正在变便宜Engineering Judgment工程判断正在变贵。但如果第二课只停在这里其实还是没讲明白。因为“工程判断”这四个字太大了。它到底是什么是会画架构图吗是熟悉 Redis、MQ、微服务吗是工作年限够长吗还是出了几个线上事故以后自然就会了我后来发现都不是。真正把普通开发者和成熟工程师拉开差距的往往发生在第一行代码出现之前。而 AI CodingAI 编程越强这件事就越明显。一、我后来越来越警惕一句话这个需求很简单假设今天产品找到你订单后台加一个导出功能。是不是很简单如果是以前你可能需要自己找 Excel 库、写查询、处理 Response响应、测试文件下载。但现在把需求扔给 Cursor 或 Codex参考现有订单查询接口实现订单导出支持当前筛选条件生成 Excel并补测试。可能几分钟以后接口有了。Service业务服务层有了。SQLAlchemy 查询有了。Excel 也生成了。测试还能跑。你点一下后台按钮。文件下载成功。第一反应非常容易是做完了。但现在我问你一个问题一次最多允许导出多少条500 条5000 条50 万条如果最多 500 条这个功能可能真的非常简单。HTTP 请求进来查询数据库↓生成文件↓返回下载↓结束。↓可如果是 50 万条呢↓事情立刻变了。↓你不可能舒服地让一个 HTTP 请求↓查询 50 万行数据↓全塞进内存↓慢慢生成 Excel↓用户浏览器一直等↓因为这时候你马上会遇到↓Timeout超时。↓内存占用。↓数据库压力。↓网关超时。↓用户关闭页面。↓任务执行失败。↓文件生成到一半服务重启。↓于是“订单导出”开始变成↓用户点击导出↓创建 Export Task导出任务↓立即返回 task_id↓Worker后台工作进程执行分批查询↓生成文件↓上传对象存储↓更新任务状态↓用户下载注意这里最有意思的地方。产品需求根本没变。产品从头到尾只说了一句话加一个订单导出。但是因为“数据量”这个隐藏条件不同你设计出来的已经是两套完全不同的系统。这就是我想从第二课开始让大家建立的第一个习惯不要只听需求说了什么还要主动寻找它没有说什么。很多真正值钱的工程能力就藏在这些“没说出来”的地方。二、AI最擅长的恰恰是需求已经变清楚之后的那一段我们把刚才的事情再拆开一点。假设我已经把所有东西都告诉 AI最多导出 50 万条。必须异步执行。导出文件放私有 OSS。下载地址 30 分钟过期。普通运营人员手机号必须脱敏。失败允许重试。重复提交相同任务时不能无限产生新任务。Worker 必须分批读取数据库。任务状态需要记录进度。到了这里你再让 AI Coding。你会发现它非常舒服。因为现在的问题已经很明确了。它需要做的事情是设计数据库 Model数据模型。写 API。写 Service。写 Worker。写 OSS 调用。补测试。处理状态更新。这些事情依然需要技术能力但它们有一个共同特点目标已经相对确定剩下的是实现。英文里可以把这一部分理解成Implementation实现。而这一层恰恰是 AI 进步最快的地方。以前软件开发里有大量时间花在我知道要干什么。但我要一行一行把它写出来。现在 AI 正在大幅压缩这段距离。所以 AI Coding 真正首先降低的其实不是“软件工程的价值。”而是Implementation Cost——实现成本但是另外一种成本并没有同步消失。甚至正在变得更加重要Decision Cost——决策成本也就是到底应该做成什么样哪些情况必须考虑这个功能的边界在哪里同步还是异步哪些地方允许失败哪些东西绝对不能发生我们凭什么认为这个实现正确这些问题才是第二课真正要讨论的东西。三、为什么两个人用同一个 Codex最后做出来的东西可以差一个级别我们做个非常简单的对比。还是增加订单导出。开发者 A 拿到需求以后直接让 AI 实现。AI 很快给出GET /orders/export查询订单。生成 Excel。返回文件。A 本地测试一下。能下载。完成。如果数据量很小这甚至可能没有问题。开发者 B 拿到需求以后第一反应却不是写代码。他先问一次最大导出数量是多少哪些角色允许导出手机号、地址这类敏感信息怎么处理导出过程中订单发生变化怎么算导出的应该是点击那一刻的数据还是执行过程中不断变化的数据如果任务需要五分钟用户关闭浏览器以后还继续吗任务执行失败怎么办用户连续点击三次怎么办文件保存多久下载链接是不是永久有效导出任务会不会把主库打满50 万行应该一次读还是分批读最终他可能决定小数据量同步导出。大数据量异步。私有对象存储。Signed URL签名链接限时访问。批量读取数据库。敏感字段按角色脱敏。导出行为写 Audit Log审计日志。重复任务短时间复用。然后才让 AI Coding。现在请注意A 和 B 使用的是同一个模型。甚至 Codex 生成代码的水平一模一样。真正产生差距的不是谁 Prompt提示词写得更花哨。而是AI 开始生成代码之前人类到底做了多少正确决策。这就是 AI Coding 时代一个非常容易被低估的变化。过去一个判断能力普通的人和一个判断能力很强的人代码产出速度可能不会差得特别夸张。因为大家都得自己敲。但今天 AI 把执行速度提高以后上游决策质量的差距会被下游生成速度迅速放大。方向对了AI 帮你高速推进。方向错了AI 帮你高速走错。所以 AI 越强我反而越来越不喜欢一句话先让 AI 写出来再说。小功能当然可以。但复杂 Feature功能里这句话可能非常贵。四、真正的第一个分水岭你能不能把“人话”翻译成“工程定义”产品世界和工程世界其实说的不是同一种语言。产品可能会说“支持任务取消。”“把消息发出去。”“删除用户。”“增加自动重试。”“做一个订单导出。”这些句子人类完全能听懂。问题是计算机听不懂“差不多”。所以工程师必须完成一次转换自然语言需求↓工程定义这一层英文里常叫Problem Framing问题定义。我觉得这个词特别重要。因为很多项目真正的问题并不是答案写错了。而是一开始解决的就不是正确的问题。比如一句非常普通的话任务取消需求是给 AI Task 增加取消功能。你很容易告诉 CursorImplement task cancellation.实现任务取消。但真正成熟的工程师会先问什么叫“取消成功”任务还在 Pending等待中。那简单。直接变成 Cancelled已取消。但如果 Worker 已经开始执行了呢如果正在调用 LLM大语言模型呢如果 LLM 已经返回正在把结果写入数据库呢如果用户点击取消的时候Worker 刚好执行完成呢如果用户连续点击两次取消呢如果取消以后服务重启呢如果任务已经产生了一部分副作用呢取消以后还能 Retry重试吗到这里你会突然意识到真正困难的根本不是cancel_task()怎么写。而是我们的系统到底如何定义“取消”这件事定义没有完成之前开始 Coding其实就是把产品定义权和架构决策权一起丢给 AI。AI当然可以给你一个答案。但那个答案只是“通常别人可能会这么做。”不代表“你的系统就应该这么做。”五、所以我现在特别喜欢拆需求里的“动词”这是一个非常实用的习惯。看到需求以后专门盯着里面的动词。比如保存。发送。删除。取消。同步。完成。成功。这些词在人类语言里特别自然。但在工程世界里经常模糊得可怕。“保存成功”是什么意思已经写入 Redis数据库执行了 INSERT数据库事务 Commit提交成功搜索索引也更新了对象存储文件也上传完成如果数据库成功但 Elasticsearch 更新失败呢到底算成功还是失败“发送成功”是什么意思消息放进 MQ消息队列Consumer消费者拿到了调用第三方 API 返回 200还是用户手机真的收到了短信完全不是一个层面的“成功”。“删除用户”是什么意思直接从数据库 DELETESoft Delete软删除只是不能登录历史订单保留吗聊天记录呢发票呢日志呢对象存储里的文件呢法律合规要求的数据呢你会发现很多需求之所以后面越做越乱不是代码能力不够。而是开头那个动词从来没有被真正定义。所以以后遇到复杂需求我建议养成一个条件反射先不要问“怎么实现”先问“这句话在我们的系统里到底是什么意思”。这是第一种越来越稀缺的能力Define——定义六、一个需求什么时候才算真正“可以开发”这里再教一个非常重要的概念Acceptance Criteria——验收条件简单理解就是做到什么程度我们才承认这个功能完成了比如“支持订单导出。”这不是一个好的验收条件。因为我无法判断什么叫“支持”。换成用户可以基于当前筛选条件创建导出任务。任务创建后立即返回 task_id。任务执行期间可以查看状态。任务完成后提供下载入口。普通运营人员导出的手机号必须脱敏。文件下载链接 30 分钟后失效。失败任务状态必须进入 Failed。这时候情况完全不同。因为它已经开始变得可验证。你会发现一个特别漂亮的关系需求↓Acceptance Criteria验收条件↓Test测试↓Verification验证这也是为什么真正好的工程需求不只是“方便程序员理解”。它会直接影响后面到底该怎么测试。所以有时候我看一个需求是否成熟不是看写了多少字。而是看它有没有办法被明确地证明“做到了”。如果没有那开发其实还没有真正准备好。七、第二种越来越值钱的能力Model——把现实世界变成系统里的模型需求定义清楚以后并不会直接来到代码。中间还有一个非常重要的过程Modeling——建模很多人第一次看到“建模”第一反应是数据库建表。其实数据库只是建模的结果之一。真正的建模是在回答我们的系统认为这个世界里到底存在哪些东西还是订单导出。Demo 里你可能觉得不就是一个接口吗但真正把它当成一个长期存在的系统能力以后你可能会发现系统里其实多了一个新的对象ExportJob——导出任务它可能拥有job_iduser_idstatusprogressquery_conditionfile_keyerror_messagecreated_atfinished_at到这里我们甚至还没有讨论FastAPI。Celery。Redis。RabbitMQ。我们只是在描述业务世界本身。然后继续。ExportJob 可能有这些状态Pending等待↓Running执行中↓Succeeded成功↓也可能↓Running↓Failed失败↓还可能↓Pending↓Cancelled取消这时候又会出现一个真正的工程问题Running 能不能变成 Cancelled别急着回答。想象 Worker 正在执行它已经生成了 90% 的文件。用户点击取消。Worker 正好准备上传 OSS。取消请求和任务完成几乎同时发生。最后应该是什么状态CancelledSucceeded谁赢这就是一个典型的Race Condition竞态条件。但我们这一课暂时不深入并发。我要你看到的是另一件事情状态不是数据库里随便存的一个字符串。状态其实是在定义系统允许发生什么。哪些路径合法。哪些路径非法。这就是 State Machine状态机的思想。八、很多所谓“代码越来越难维护”其实是模型一开始就没想明白假设你的 Task 最开始只有runningsuccess两个状态。后来产品说增加失败重试。于是你开始硬塞error。过几天又说支持取消。再塞cancel。后来还需要waiting。retrying。timeout。partial_success。最后代码里到处都是if status ...elif status ...为什么会这样不一定是因为程序员不会重构。很可能是一开始对业务世界的理解太粗糙。这就是建模的重要性。好的工程师在写代码之前会开始问系统里有哪些 Entity实体有哪些 State状态状态之间有哪些 Transition迁移哪些事情绝对不能发生哪些规则必须永远成立最后一个问题其实就是第一课讲过的Invariant——不变量所以你会发现第一课和第二课已经开始接起来了。第一课我们知道系统必须保护不变量。第二课进一步追问这些不变量从哪里来答案之一就是来自你对业务世界的正确建模。所以第二种能力叫Model——建模九、第三种能力才真正来到“工程判断”的核心Decide——做选择现在需求清楚了。模型也大致有了。是不是终于有标准答案了还是没有。因为真正的软件工程从来充满Trade-off权衡。还是订单导出。现在摆在你面前的问题可能有同步还是异步CSV 还是 Excel主库还是只读库Offset Pagination偏移分页还是 Cursor Pagination游标分页Redis 要不要参与MQ 要不要上文件保存一天还是七天失败自动 Retry 还是人工重试这些问题没有一个简单的“最先进答案”。十、工程师成熟的一个标志是开始不相信“哪个技术更高级”刚开始学后端的时候我们特别容易有一种技术排行榜思维微服务 单体。异步 同步。Redis 数据库查询。Kafka 普通消息队列。分布式 单机。复杂架构 简单架构。工作几年以后慢慢会发现事情根本不是这么回事。真正合理的表达应该是在什么条件下A 比 B 更合适比如还是订单导出。如果这是一个内部后台每天 10 个人用。一次最多导出 300 条。查询 100ms。生成 CSV 再花 100ms。你非要设计MQ。Redis。Worker Cluster。Task Scheduler。状态恢复。任务清理。失败补偿。可能不是“生产级”。可能叫Overengineering——过度设计一个普通同步接口也许就是最好的选择。但是如果一次 50 万条。生成需要 5 分钟。同时几百个导出任务。必须支持失败恢复。还要做进度查询。那你继续坚持同步就是在制造问题。所以真正值钱的不是“我知道异步任务。”而是我知道什么时候应该使用异步任务。这就是 Knowledge知识和 Judgment判断的区别。知道 Redis 怎么用是知识。知道现在到底需不需要 Redis是判断。知道 Kafka 怎么部署是知识。知道这个项目是否值得引入 Kafka是判断。知道微服务怎么拆是知识。知道现在到底该不该拆是判断。AI 可以越来越容易地把“知识”变成代码。但“判断”仍然需要依赖上下文和约束。这也是为什么 Context Engineering上下文工程会在后面的课程里越来越重要。十一、我后来才真正理解架构不是不断加东西而是不断管理复杂度刚开始学习架构时很容易有一种错觉图越复杂架构越高级。于是一个简单系统也想放进去API Gateway。Redis。MQ。Event Bus。Worker。Scheduler。Microservice。Service Mesh。看起来很专业。但后来我越来越喜欢一个词Complexity Budget——复杂度预算可以简单理解成系统能够承受的复杂度是有限的。你每增加一个组件都不是只增加一个图标。比如“加 Redis。”听起来只有三个字。实际上你同时增加了部署。配置。连接池。鉴权。监控。高可用。TTL。缓存一致性。缓存穿透。缓存击穿。数据过期。故障降级。Redis 挂了之后怎么办这些全都是系统以后必须承担的东西。所以技术组件从来不是免费的。一个优秀架构师真正厉害的地方很多时候不是能想到多少组件。而是知道哪些组件不应该出现。这点在 AI Coding 时代尤其重要。因为以前过度设计还有一个天然阻力你得自己写。写五层 Factory工厂、Strategy策略、Adapter适配器写着写着可能自己都烦了。现在 AI 不烦。你想抽象十层它真能给你十层。于是出现一个很有意思的变化生成复杂度的成本下降了。但是维护复杂度的成本没有消失。代码是 AI 写的。以后出问题还是你查。新人还是得理解。测试还是得维护。依赖还是得升级。系统还是得部署。所以 AI 时代我反而认为一个越来越重要的能力叫知道什么不要做。这也是 Decide决策的一部分。十二、第四种能力是我认为以后越来越值钱的一种能力Verify——证明它是对的现在假设前面全做完了。AI 把代码生成了。你运行测试 37 个。全部通过。是不是可以 Merge不一定。因为这里有一个非常危险的问题测试是谁写的AI。代码也是谁写的AI。如果 AI 一开始就理解错了怎么办比如真实业务规定普通运营人员不能导出完整手机号。但是 AI 理解成所有后台用户都可以导出完整手机号。于是它写出代码普通运营可以导。然后它又写测试普通运营导出。检查 HTTP 200。检查文件中存在手机号。测试结果PASS。漂亮。所有测试绿色。但是整个实现错得非常完整。这是 AI Coding 时代特别值得警惕的一件事。因为代码和测试可能来自同一个错误假设。所以以后一定要记住Test Pass ≠ Requirement Correct测试通过不代表需求正确。十三、真正可靠的验证必须有一个“代码之外的锚”还是刚才的手机号。如果我们的 Acceptance Criteria验收条件已经明确写着普通运营人员导出的手机号必须脱敏。那么这条规则就独立存在于AI 生成的代码之外。于是我们才能真正验证普通运营登录↓创建导出任务↓获取导出文件↓解析文件↓检查手机号字段确认完成脱敏现在这个 Test 才真正有价值。因为它不是在验证“代码是不是按照代码作者的理解运行。”而是在验证系统有没有遵守业务本身的规则。所以我现在越来越喜欢这样理解测试测试不是几个assert。测试是在回答我有什么证据证明系统最重要的规则没有被破坏这就是Verification验证。十四、到这里我们终于可以把“工程判断”拆开了上一课结束的时候我们说工程判断越来越贵。现在它已经不再是一个模糊词。至少可以先拆成四层Define——定义到底要解决什么问题“成功”“取消”“发送”“删除”分别是什么意思Model——建模这个业务世界里有哪些对象有哪些状态有哪些关系哪些规则必须永远成立Decide——决策同步还是异步缓存还是不缓存要不要 MQ要不要拆服务当前约束下什么方案最合适Verify——验证我们怎么证明系统真的正确测试什么哪些失败场景必须覆盖什么证据足够让它进入 Production生产环境于是整条链路变成Define → Model → Decide → Implement → Verify定义↓建模↓决策↓实现↓验证注意中间那个词Implement——实现这正是 AI 进步最快的部分。所以真正发生的不是“AI 把程序员消灭了。”而是AI 正在把 Implementation 从 Engineering 中高速压缩。于是以前被“写代码”遮住的能力开始全部露出来。十五、为什么我现在越来越不喜欢“让 AI 先写一个看看”不是因为不能这么做。简单需求当然可以。但复杂需求里真正危险的是AI 的实现速度已经开始超过人的理解速度。以前你想一个方案。开始写。写了一下午。发现方向不对。可能也就改了三个文件。现在你一句话。Agent 开工。十五分钟以后改了 26 个文件。新增两个表。做了 Migration数据库迁移。加了 Worker。补了缓存。测试写了 40 个。README 都改好了。看起来效率爆炸。问题是如果最开始那个方案错了呢你得到的不是一个小错误。而是一整套非常完整的错误实现。所以我后来越来越能理解为什么 AI Native Development LoopAI 原生开发循环应该是Context↓Plan↓Code↓Test↓Review↓Production↓而不是↓Prompt↓Code上一课已经把这条循环作为整套课程的主线之一。现在第二课我们可以真正理解为什么一定要先有 Context上下文。为什么复杂任务应该先 Plan规划。不是流程洁癖。而是在控制一个新的风险AI 可以比你想清楚问题更快地把代码写出来。十六、这也意味着未来一个优秀程序员的角色会慢慢发生变化以前一个程序员大量时间在理解需求↓设计↓写代码↓Debug↓测试↓上线↓其中“亲自生产代码”占据非常大的一部分。↓未来越来越可能变成↓理解需求↓定义问题↓建立约束↓设计模型↓拆任务↓做技术决策↓AI 高速实现↓人验证↓AI 修正↓Production Check生产检查你会发现人的工作逐渐从Code Writer——代码编写者往Engineering Director——工程导演移动。我用“导演”这个词不是说以后工程师只动嘴。恰恰相反。你仍然必须懂技术。甚至很多地方需要懂得更深。为什么因为 AI 写了错误 Transaction Boundary事务边界你得看得出来。出现 N1 QueryN1 查询问题你得看得出来。锁范围错了你得看得出来。Retry重试可能制造重复副作用你得看得出来。权限漏洞你得看得出来。数据库设计不合理你得看得出来。所以 AI 时代绝对不是技术不重要了。而更准确的说法应该是“记住怎么写”的价值在下降“理解为什么这样设计”的价值在上升。十七、以后“只懂业务不懂技术”同样会非常危险讲到这里有人可能会走向另一个极端既然 AI 会 Coding那以后工程师是不是只需要会提需求不是。还是订单导出。一个不了解数据库的人可能会认为50 万条一次查出来不就行了吗一个不了解 HTTP 的人不知道为什么五分钟的同步请求非常危险。一个不了解分布式系统的人不知道为什么 Retry 可能让同一任务执行两次。不了解数据库事务就不容易理解为什么“执行到一半失败”需要考虑状态一致性。不了解安全就可能觉得 OSS 文件生成一个永久公开 URL 最方便。不了解并发就很难发现两个看起来都正确的请求同时执行可能产生错误结果。所以未来并不是懂业务 懂技术。而是技术知识的使用方式正在变化。以前很多时候我学 SQLAlchemy因为我要亲自把 ORM 代码写出来。以后还会多一层我理解 Transaction事务因为我要判断 AI 为什么在这里写错了。我理解索引因为我要判断这个查询上线以后会不会拖垮数据库。我理解消息队列因为我要决定这里到底有没有必要引入异步。技术仍然是工程判断的底座。只是它不再只服务于“写”。它越来越服务于判断。十八、如果把未来后端工程师的能力画成四层我会这么分最底下一层Level 1Implementation——实现能力Python 怎么写。FastAPI 怎么写。SQLAlchemy 怎么用。Redis 怎么接。Docker 怎么配。这层依然重要。但是 AI 正在高速增强它。第二层Level 2Modeling——建模能力系统里到底有哪些对象状态是什么关系是什么生命周期是什么哪些规则不能被破坏第三层Level 3Decision——决策能力什么方案适合现在为什么成本是什么风险是什么什么时候需要升级架构什么复杂度根本不值得引入第四层Level 4Verification——验证能力我们怎么证明它是正确的正常路径怎么测失败路径呢边界呢权限呢并发呢上线以后通过什么指标判断系统仍然健康最终你会发现越往上走工作的核心越不像“我会不会写。”而越来越像我能不能定义正确并证明正确。十九、从今天开始拿到复杂需求先问这六个问题如果第二课最后只留一个你明天上班就能用的东西我建议记住下面这套方法。不要背术语。真的拿去用。第一问我们到底在解决什么问题不要重复产品原话。你必须能用自己的话解释。如果自己都说不清楚说明问题还没有定义完成。第二问什么才叫成功尽量给出可验证的定义。不要只说“支持任务取消。”而应该继续定义哪些状态允许取消取消接口返回成功到底代表什么重复取消怎么办已完成任务怎么办第三问什么事情绝对不能发生找 Invariant不变量。不能重复扣款。不能越权。不能让库存凭空减少。不能让任务永久停留在 Running。不能因为 Retry 重复产生业务副作用。第四问这个业务世界应该怎么建模有哪些 Entity实体有哪些 State状态状态如何迁移哪些数据需要长期保存谁拥有生命周期第五问当前条件下最简单的正确方案是什么不是最先进。不是最酷。不是简历上最好看。而是满足当前约束同时保留合理演进空间的最简单方案。这条特别难。但也特别值钱。第六问我怎么证明它真的对不要等 AI 写完才想测试。开始 Coding 之前就应该问哪些行为必须被验证哪些规则必须被测试保护上线以后哪些指标能够证明系统仍然可信如果这一问完全答不上来代码写得再快也应该谨慎。二十、现在再回来回答文章开头的问题AI Coding 越来越强以后程序员真正稀缺的能力到底是什么不是一个答案。而是一条能力链模糊需求↓Define把问题定义清楚↓Model把现实世界建模↓Decide在约束中做正确选择↓Implement把设计实现出来Verify证明实现真的正确而 AI 当前正在最猛烈地压缩的恰恰是中间的 Implementation。这也是为什么我现在越来越觉得以前我们容易把程序员理解成把需求翻译成代码的人。未来这个定义会越来越不准确。更成熟的描述应该是把模糊问题变成一个可执行、可验证、可以在真实系统中长期成立的工程方案的人。代码依然重要。只是代码不再是全部。二十一、这就是 Coding → Engineering 真正发生的地方所以这节课最重要的不是记住Problem Framing。Modeling。Trade-off。Verification。这些英文以后自然会熟。我真正希望你建立的是一种新的开发直觉。以后再打开 Cursor、Codex。看到一个复杂需求。不要第一反应就是帮我实现 XXX。先多想几秒这个问题真的定义清楚了吗AI 现在有哪些东西只能靠猜这里有哪些业务规则它不知道哪些架构决策我不应该无意识地交给它最简单的正确方案到底是什么最后我准备用什么证据证明它真的做对了一旦这几个问题开始变成你的习惯你使用 Coding Agent 的方式会发生非常明显的变化。你不再只是让 AI 帮你写代码。而是在逐渐学习怎样让 AI 进入一个被人类正确理解、正确约束、并且可以验证的工程空间里工作。这才是我理解的AI Native Backend EngineerAI 原生后端工程师。第一课我们得到代码生成越来越便宜工程判断越来越贵。这一课我们终于把“工程判断”拆开了定义、建模、决策、验证。课程最初对第二课的定位本来就是完成一次从Coding → Engineering的认知切换而不是马上进入某个具体框架。而当你真正理解这一点之后下一个问题就自然出现了既然 AI 实现能力已经这么强为什么网上那些“10 分钟写完整系统”的 Demo 看起来一个比一个惊艳可真的到了 Production生产环境事情却突然完全不一样这就是下一课要解决的问题为什么 AI 写 Demo 快得吓人一到 Production 就开始露馅下一课我们不再只讨论抽象能力。我们会拿一个“已经运行成功”的后端功能一层一层往真实生产环境里推。你会看到一个很反常识的事实很多时候功能跑通的那一刻并不是软件工程结束。恰恰是软件工程真正开始的地方。