《AI时代的程序员修养》写到第十二篇，差不多该收束一下。这个专栏从“程序 = 算法 + 数据结构”讲起，经过进程、线程、协程、模块通信、接口契约、数据库、缓存、队列、高并发、测试、可观测性和重构，绕了一圈，其实是在说同一件事：AI 可以帮你写代码，但它不会替你承担系统后果。程序员长期要修的，不是背更多框架名字，而是形成稳定的工程判断。知道问题怎么拆，状态怎么流，边界怎么画，成本怎么算，结果怎么验证，风险怎么收住。不要把 AI 当成新手程序员很多人把 AI 当成一个写代码很快的新手程序员。这个比喻有一半对，一半错。对的是：AI 确实需要清楚的任务、上下文和验收标准。你给一句含糊需求，它就会按概率补全。你给明确边界，它会稳定很多。错的是：新手程序员会在项目里慢慢形成责任感，知道某段代码上线后会影响谁。AI 没有这种责任感。它不知道线上报警半夜响起来是什么感觉，也不知道一次错误扣费要怎么补偿用户。所以程序员的角色不是“让 AI 替我写完”，而是“把问题组织到 AI 可以正确工作的形状”。这个形状通常包含：明确的输入输出 稳定的数据结构 清楚的状态机 可验证的测试样例 受控的副作用 可观测的运行证据 可回滚的上线方式这些东西听起来普通，但它们就是工程。长期能力一：问题建模写代码之前，先把问题建模。建模不是画漂亮图，而是把现实里的混乱概念压成程序可以处理的对象、关系、状态和约束。比如“用户提交一个任务，系统异步执行并返回结果”。这句话太粗。真正建模时要问：任务有哪些状态？ 状态之间怎么转移？ 任务是否可以取消？ 重复提交怎么处理？ 执行失败是终态还是可重试？ 结果是否有版本？ 用户是否能看到别人的任务？ 任务执行是否产生扣费？ 扣费发生在提交时、执行前还是成功后？很快，你会得到一个状态机：created - queued - running - succeeded ├── failed_retryable - queued ├── failed_final └── cancelled这个状态机比一句需求有用得多。它能指导