https://lucumr.pocoo.org/2026/9/7/astra-why/ 这篇文章讲了什么

这篇文章是 Armin Ronacher（Flask 作者、lucumr.pocoo.org 博主）9 月 7 日写的，标题叫「Astra for Coding: Why Are We Doing This Again?」，聊的是他对 GPT-6 Astra 写代码的真实体验。核心结论一句话：模型强得离谱，但产出的是他没法在真实软件工程里用的代码。 他的切入点挺有意思——一开头说现在整个 AI 工程就是「内卷」（Neijuan / Involution），引用的是《Agricultural Involution》那个概念：单位面积产量越来越高，但人均产出没变。他说这就是他对当下 AI 的感觉。Astra 本身绝对惊艳，computer use 强、能理解图像和复杂议题、而且有股不达目的不罢休的劲，但他不知道该怎么拿它做正经软件工程。 于是他周末做了个「软件工厂」实验，故意让模型自己决定整个 workflow，自己管上下文、自己在 agent-notes 里记笔记、自己派 subagent。目标是造一门有虚拟线程和词法作用域的 Python。结果：烧掉一整次 ChatGPT 重置配额，约 40 亿 token，跑了 35 小时，没交付任何有价值的东西，也没教会他怎么运营一个更好的工厂。 然后是文章最有意思的部分——他分析模型写出的代码风格。Astra 特别爱用 Python 做工具调用：不像 Codex 那样偏向「纯 bash + sed」，它会疯狂用 python3 heredoc 去读文件、改文件、写补丁，绕过 harness 提供的 edit/patch 工具。文章里贴了一堆真实输出，比如用一段 Python 内联脚本同时改 C 源码、改 magic number、加单测；还有更离谱的——用 Bash 跑 Python，Python 里用 prlctl 去 Windows 虚拟机上跑 Node.js，Node.js 里再调 PowerShell，套了四层。他能理解这是为了 token 效率，但人根本读不懂，一旦不用编辑工具，就只能最后看 diff 才知道发生了什么。 更麻烦的是这种「代码高尔夫」风格开始渗进应该被提交的正式代码里，尤其是测试，还有嵌在 HTML 里的 JS/CSS——凡是「离主逻辑隔了一层」的地方就复发。他贴了两个用压缩写法生成的 Python 单测，说这两段按 ruff format 展开后要多 10% 的 token，换句话说模型就是在优化 token 效率。 后半段他列了更诡异的产物：C 代码里一堆魔数，按数字做 switch，case 0 到 72 分别对应不同的对象协议探测；Python 代码里把状态塞进 list，然后 `_task_accelerator[6](task)` 这样按下标调用；任务文件名从乐观的 1、2、3、5、5a 一路退化成 8a、8a1、8b2c2b3、「8b2c2b2b checkpoint1」。他的说法是「我不知道它是从哪拿到这些数字的，也完全不明白是什么动机让模型这么写」。 他对成因的猜测：训练在快速加速，可能也在往递归自我改进走；奖励函数大概是 token 效率 + 任务完成率 + 一些容易量化的指标（比如圈复杂度）。但人判断代码好坏的标准不是这些能单独测量、能局部优化的指标。局部最优不构成全局最优，而看输出的人越少，这件事就越没人管。 所以整篇的论点是：模型在长程任务上被奖励、在「代码烂」上几乎没有惩罚，结果就是一个能连续干 35 小时、产出巨量代码、却交付不了价值的系统——正好呼应他开头那个「内卷」的比喻。