国庆假期，一条来自澳大利亚的微博换机记录，戳中了不少天天跑 AI agent 的人。
博主 JaiLatte 的 M1 MacBook Air，8GB 内存、512GB 硬盘，本是几年前的轻办公标配。拿 Codex 和 Claude Code 干日常开发之后，浏览器加几个项目一起开，机器很快就不行了：CPU 温度冲到 89°C，操作越来越卡；8GB 内存捉襟见肘，系统只能拿硬盘空间做 swap 周转；最惨的是硬盘——每个项目的 worktree（给 agent 开的独立工作副本）在硬盘里"繁衍"，512GB 最后只剩不到 9GB。微博
他最后换了台 Mac mini M6，32GB 内存 + 1TB 硬盘。也考虑过更高配的 M5 Pro / 48GB，同样 1TB 要多花 1250 澳元，放弃了。他的理由值得原样抄一遍：“先解决已经撞上的内存和空间限制，不急着为还没用到的负载买单”。微博
注意一个关键前提：他主要用的是云端 AI，模型全在厂商的服务器上算。那么反常识的问题来了——AI 编程不是不吃本机算力吗，为什么电脑先垮了？
一、压垮电脑的从来不是模型，是 agent 的"干活方式"
知乎上有篇流传很广的文章《用 AI 到底需不需要高配电脑》，把很多人混淆的事情讲透了：要分清"本地部署模型"和"API 接入云端模型"。你通过 Claude Code、Codex 这类工具调用云端模型时，推理发生在服务商的服务器上，本机负责的是文件读写、命令执行、构建测试、调用本地软件——典型的"云端推理 + 本地处理"。这类任务不吃显卡，但实打实吃 CPU、内存和硬盘。知乎
而 agent 式编程和过去的聊天式编程，本地负载完全不是一个量级：
一个 agent 任务往往对应一个独立工作区（worktree），外加一整套依赖目录和构建产物；
同时开三四个会话并行干活，已经是很多人的标准操作；
每改一轮，本地就要跑一遍测试、起一遍预览、重建一次索引；
浏览器、MCP 服务、文件索引常驻后台。
模型在远处算，但"干活的手"在你桌上。所以"用云端 AI 编程就不挑电脑"这句话，在 agent 工作流普及后已经过时了——不是模型搬到了本地，是本地变成了流水线车间。
二、先确诊：三种人，三种瓶颈
换机之前，先搞清楚自己是不是真的撞墙了。小红书上一个"一人公司"博主的案例正好当反面参照：她帮 IP 客户选电脑，结论是内容工作流 + Codex 轻度使用，MacBook Air 16GB + 512GB 就够，“这些任务吃的是内存和续航，不是显卡算力”。小红书
对照下来，大致是三类人：
轻度对话型（偶尔让 AI 写段脚本、改改文案）：16GB 内存的现役机器大概率还能战，不用动。
重度 agent 并行型（每天多会话跑 Claude Code / Codex / DSH，本地构建测试频繁）：32GB 内存是起跑线，1TB 硬盘是舒适线。JaiLatte 那台 8GB 的 Air 就是典型案例——瓶颈不是算力，是内存余量和硬盘空间。
本地模型型（跑 RAG、量化模型、本地生图）：逻辑完全不同，统一内存/显存容量为王。小红书上有个 MacBook Pro M5 用户，当初把钱花在了 2TB 硬盘上，内存只选了 24GB，结果做了 AI 开发才发现 unified memory 的价值——本地跑量化模型性能甚至超过一台 8 核 16G A6000 的服务器。他的原话是：“如果上天还能给我一次机会，我一定会选 64G。”小红书
自查也简单，三步：一看内存压力和 swap 用量是否长期飘红；二看硬盘剩余空间，以及是谁在吃（worktree、node_modules、Docker 镜像还是模型文件）；三看温度和持续负载，无风扇轻薄本撞温度墙会直接降频。三项里有两项中招，再谈换机。
三、今年的换机账单，比去年贵得多
如果你确诊了，还有一个坏消息：这轮涨价正好撞在存储上。
美国银行统计过一组数字：DDR5-5600 和 DDR5-6400 两款 24GB 内存芯片，2026 年 8 月现货价同比涨了 483%。知乎
国产颗粒也没能拉低行情，七彩虹本周上架的 32GB DDR5 内存条，定价 3999 元。
TrendForce 最新预测：四季度常规 DRAM 合约价环比再涨 10%-15%，NAND 闪存最高涨 20%。知乎
微软甚至被涨价逼得给 Win11 “瘦身”，官方表态要降低系统 RAM 占用。
涨价也已经在往终端传导。界面"电厂"去年底的调查里，广州一家装机工作室老板已经开始劝退客户：“不是刚需就别装电脑”——内存、硬盘涨价直接抬高整机价，不了解行情的客户还以为 DIY 商家在宰人。TrendForce 的数据更直观：涨价压力下，智能手机和笔记本的单机 DRAM 容量规格出现了明显的降配回退，厂商把成本压力悄悄转嫁到了配置表上。当然，社区里也有反方声音——小红书上一条"内存缺货是集体演戏"的笔记拿了 3.8 万赞，理由很直接：“真缺货是加钱都抢不到，现在的内存缺货，是你多掏几百块，第二天就能送到家”。零售端的紧张和渠道端的溢价，哪个是真实短缺、哪个是顺势抬价，普通消费者确实难分辨，但至少"现货价在涨、合约价在涨、整机价在涨"这三件事都是真的。界面新闻小红书
要不要当等等党？知乎上一个 233 万浏览的问题正在吵。等等党的论据是上一轮矿难：2022 年底，被炒到 8000 元的 3060 一千块就能收。但这次的结构不太一样——涨价主力是需求端，AI 数据中心把 DRAM 和 NAND 的产能整段吃掉了，不是渠道囤货等着崩盘。美光 CEO 的表态更直接：即使 AI 泡沫破裂，内存仍将涨价，2027、2028 年供需可能比 2026 年更紧。厂商在赌哪边，一目了然。知乎知乎
翻译成 AI 编程用户的决策语言就是两句话：瓶颈已经发生的，等的成本大概率是负的——价格在涨，你每天还在为卡顿和清硬盘付时间税；瓶颈没发生的，别被焦虑营销劝着超额消费——那篇知乎文章的原话同样直接：“别还没开始用 AI，先被评论区劝着升级了一台自己根本用不满的机器。”
四、明晚的 RTX Spark：谁该等，谁不该等
还有一个变量就悬在头顶：10 月 7 日（北京时间 8 日凌晨），微软和英伟达联合办发布会，黄仁勋确认出席，主角就是 RTX Spark 平台的 PC。微博
规格此前已经官方口径放出来了：20 核 Grace CPU + 6144 核 Blackwell GPU，最高 128GB 统一 LPDDR5X 内存，AI 算力最高 1 PFLOP（FP4），ARM 架构跑 Windows，华硕、戴尔、惠普、联想、微软、微星六家首发。联想 YOGA Pro 15 Spark 的资料最细：128GB 统一内存里最多 96GB 可划作显存，宣称能本地跑 26B 模型，机身 1.65kg。小红书微博
有个细节很值得品：六款首发全是创作本和生产力本，没有一款游戏本。PC 的分工线正在被重新画——游戏归游戏本，AI 归工作本。小红书
对本地模型党，这是大事：128GB 统一内存意味着 70B 参数模型量化后（约 40GB）装进去还剩下大半，够放长文档和上下文。但对三件事要保持清醒：
ARM 兼容性：很多 x86 老软件要靠模拟层跑，开发工具链、特殊驱动得逐个验证；
价格：首发撞上内存涨价周期，"不便宜"几乎是明牌，泄露口径本就不亲民；
实测真空：目前没有任何独立实机评测，社区对 LPDDR5X 带宽的争论也没停过——有人吐槽统一内存配 LPDDR5 是短板，也有人认为高速互联能补回来，吵到最后还得等真机数据。
所以结论可以切得很干净：要跑本地模型的、深度绑定 CUDA 和 Windows 工具链的，值得等明晚看完价格和首批实测再动手；纯云端 AI 编程的用户不必等——你缺的是内存和硬盘余量，不是那 1 PFLOP 算力，"128GB 统一内存"对调 API 的活儿帮助有限，而新机首发价大概率站在高位。
五、三条路，把账算完再动手
路线 A：现在换（瓶颈已发生 + 主力云端编程）
花钱顺序记住一条：内存 > 硬盘 > CPU > 显卡。不跑本地模型，就不用为独显多掏一分钱。重度 agent 用户直接 32GB 起步、1TB 硬盘；预算宽裕又担心未来碰本地模型的，参考那位 MacBook Pro 用户的教训——内存优先级在硬盘之上，容量焦虑比空间焦虑更难补救，而且内存在涨价，"一步到位"这轮比往年更成立。
路线 B：等（要本地模型 / 瓶颈还没到）
明晚发布会之后，看三样东西再掏钱：最终售价、独立实机评测、软件兼容清单。等的期间顺手盯两个行情信号：四季度 DRAM/NAND 合约价是否如期落地到整机售价，以及内存现货价有没有出现拐点（目前主流容量 DDR5 仍在涨）。
路线 C：上云（老机器还能撑 / 预算紧）
把开发环境整体搬到云端：知乎上有用户实测了一套方案，在云服务器跑 code-server，装官方 Claude Code 扩展，本机浏览器当操作入口——8GB 的老 Air 只负责渲染网页，顺手还解决了"agent 到底在哪台机器上执行"的安全边界问题。不想全搬的，也可以低成本续命：定期清理已合并的 worktree、删 Docker 悬空镜像、关掉常驻索引服务，硬盘压力往往先松一口气。知乎
换电脑这件事，过去是性能焦虑驱动的"追新"，这次不一样：一边是 agent 工作流重塑了本地负载，一边是存储涨价改写了时间窗口，明晚还悬着一场可能重新画线的发布会。确诊自己的瓶颈，算清三条路的账，再决定掏不掏钱——这一次，慢一步不一定亏，快一步也未必贵。
接下来值得盯的信号：RTX Spark 发布会的最终定价与首批实测、四季度存储合约价落地情况、内存现货价走势，以及你自己机器的 swap 频率和硬盘余量。有变化，我们再接着算。
