AI时代的程序员修养：别让 AI 替你猜执行模型

《AI时代的程序员修养》前两篇讲了程序和数据结构。这一篇进入另一个很容易被 AI 编程掩盖的问题：代码到底由谁执行，在哪里执行，什么时候让出 CPU，什么时候会把整个服务卡住。很多并发 bug 不是因为代码太难，而是因为执行模型一开始没有说清楚。你让 AI “并发处理一批任务”，它可能写线程池；你让它“改成异步”，它可能只是在函数前面加async；你让它“提高吞吐”，它可能多开几个 worker，却没有发现数据库连接池已经被打满。执行模型不是底层八股。它决定系统能不能扛住慢接口、突发流量、CPU 计算、文件读写和外部服务抖动。并发不是一个词“并发执行”这句话太粗了。它可能表示多个独立进程同时跑，也可能表示一个进程里多个线程抢时间片，还可能表示一个线程里用协程在等待 I/O 时切来切去。它们看起来都能“同时处理多个任务”，但成本、隔离性、共享状态和故障模式完全不同。执行模型常见场景优点风险多进程Web worker、批处理 worker、CPU 密集任务隔离强，单进程崩溃影响小，能利用多核内存占用高，进程间通信成本高多线程阻塞 I/O 并发、后台任务、GUI 程序共享内存方便，切换成本低于进程竞态、死锁、线程池耗尽协程 / async高并发网络 I/O、API 网关、爬取、长连接单线程可承载大量连接，等待时切换便宜一个阻塞调用就能卡住事件循环事件驱动消息消费、前端 UI、Node.js 服务、异步框架适合大量短小事件和 I/O 回调调用链分散，错误传播和上下文追踪复杂批处理数据同步、报表、离线任务吞吐高，容易做批量优化延迟高，失败恢复和断点续跑要设计AI 很容易把这些模型混在一起。比如在 FastAPI 里生成一个async def接口，然后里面调用同步数据库驱动、同步 HTTP 客户端或者本地大文件读取。代码语法上是异步的，运行时却会把事件循环堵死。所以写 prompt 时不要只说“异步处理”，要说清楚：这是一个 async Web 接口，运行在单进程事件循环中。 请求路径不能执行阻塞 I/O。 数据库访问必须使用 async driver。 CPU 密集计算必须 offload 到进程池或独立 worker。 外部 HTTP 调用必须设置超时和并发上限。这几句话比“帮我优化性能”有用得多。进程：隔离很贵，但很可靠进程是操作系统给程序划出的隔离空间。每个进程有自己的地址空间、文件描述符、环境变量、堆栈和运行状态。一个进程崩溃，通常不会直接踩坏另一个进程的内存。Web 服务里常见的多进程模型，是一个 master 拉起多个 worker：master ├── worker-1 ├── worker-2 ├── worker-3 └── worker-4每个 worker 都能接请求。对 Python、Node.js 这类运行时来说，多进程也是绕开单进程 CPU 限制、利用多核的常见办法。但进程不是免费的。如果一个模型加载到内存需要 2GB，开 8 个进程可能就不是 2GB，而是接近 16GB，具体还取决于 copy-on-write、模型是否被修改、运行时内存分配方式。数据库连接也类似。每个进程一个连接池，4 个 worker、每个池 20 条连接，总连接数就是 80，不是 20。让 AI 配 Web worker 时，很容易得到这种建议：CPU 是 8 核，所以 worker 数设为 8。这句话只对一小部分场景成立。更合理的估算