AI时代的程序员修养：AI 时代，程序员还要修什么

《AI时代的程序员修养》写到第十二篇，差不多该收束一下。

这个专栏从“程序 = 算法 + 数据结构”讲起，经过进程、线程、协程、模块通信、接口契约、数据库、缓存、队列、高并发、测试、可观测性和重构，绕了一圈，其实是在说同一件事：AI 可以帮你写代码，但它不会替你承担系统后果。

程序员长期要修的，不是背更多框架名字，而是形成稳定的工程判断。知道问题怎么拆，状态怎么流，边界怎么画，成本怎么算，结果怎么验证，风险怎么收住。

不要把 AI 当成新手程序员

很多人把 AI 当成一个写代码很快的新手程序员。这个比喻有一半对，一半错。

对的是：AI 确实需要清楚的任务、上下文和验收标准。你给一句含糊需求，它就会按概率补全。你给明确边界，它会稳定很多。

错的是：新手程序员会在项目里慢慢形成责任感，知道某段代码上线后会影响谁。AI 没有这种责任感。它不知道线上报警半夜响起来是什么感觉，也不知道一次错误扣费要怎么补偿用户。

所以程序员的角色不是“让 AI 替我写完”，而是“把问题组织到 AI 可以正确工作的形状”。

这个形状通常包含：

明确的输入输出
稳定的数据结构
清楚的状态机
可验证的测试样例
受控的副作用
可观测的运行证据
可回滚的上线方式

这些东西听起来普通，但它们就是工程。

长期能力一：问题建模

写代码之前，先把问题建模。

建模不是画漂亮图，而是把现实里的混乱概念压成程序可以处理的对象、关系、状态和约束。

比如“用户提交一个任务，系统异步执行并返回结果”。这句话太粗。真正建模时要问：

任务有哪些状态？
状态之间怎么转移？
任务是否可以取消？
重复提交怎么处理？
执行失败是终态还是可重试？
结果是否有版本？
用户是否能看到别人的任务？
任务执行是否产生扣费？
扣费发生在提交时、执行前还是成功后？

很快，你会得到一个状态机：

created -> queued -> running -> succeeded
                         ├── failed_retryable -> queued
                         ├── failed_final
                         └── cancelled

这个状态机比一句需求有用得多。

它能指导