用 Astra 写代码：我们为什么又要重来一遍？
文章摘要
Flask 作者 Armin Ronacher 写了一篇关于 GPT-6 Astra 用于软件工程的观察笔记，开篇就抛出了他越来越确信的一个判断：整个 AI 工程领域都是「内卷」——一个要求不断投入更多努力和竞争、产出却没有改善的系统。他特意引用了「农业内卷化」这个学术来源：耕作强度提升让单位面积产量上升，但人均产量原地踏步。他说这就是他现在对 AI 的感受。
对 Astra 本身，他给出的评价是分裂的。模型本身令人印象深刻——擅长电脑操作，理解图像和复杂话题，对完成任务有近乎执拗的坚持，这类模型终将以某种形式改变世界。但至少眼下，他不知道该怎么用它来做真正的软件工程。
为了给这个判断找证据，他花了一个周末运行了一个「软件工厂」：完全让模型自己决定工作流，自行管理上下文，在 agent-notes 文件夹里维护自己的记录，再派生子智能体去干活。目标是「如果 Python 有虚拟线程和词法作用域会怎样」。他烧掉了 ChatGPT 一整个重置周期的额度，大约 40 亿 token，35 小时后的结论是：工厂交付了毫无价值的东西，也没教会他如何运营一个更好的工厂。不过它确实产出了大量代码和提示词供他研究。
他的核心怀疑是训练过程出了某种偏差：模型因为在长周期任务上成功而获得巨大奖励，但对「烂代码」大概没什么惩罚。结果就是 Astra 极擅长生成 3D 之类的东西，能持续工作很久并自行找出下一步该干什么——他让它逆向工程自己的扫地机器人，效果相当惊艳——但代码质量是另一回事。
文章主体是他收集的一组「代码高尔夫式工具调用」样本。Codex 的 harness 这几个版本一直在往「就用 bash」的方向走，但 Astra 特别偏爱 Python，而且用得非常过分。他展示了几类典型行为：不用 harness 提供的 patch 工具，而是写 Python 脚本对 C 源码做手工字符串拼接和 index/切片来插入函数；遇到一个「Bad file descriptor」的测试失败，就写一段极度压缩的 Python 去验证 macOS 上文件描述符能否通过 Unix socket 传递；连更新自己的 agent-notes 都用 Python 做一长串字符串替换；最离谱的一组是用 Bash 调 Python、Python 调另一台机器上的 Node.js、Node.js 再去启动 PowerShell 脚本。
他指出这里真正的问题不是好笑，而是不可读。一旦模型放弃使用 harness 的编辑工具，人就几乎无法在变更发生时跟上它在做什么，只能事后去 diff 视图里看最终产物。他注意到一个现象：在 Pi 里正常交互时它大多还是用编辑工具，而一旦放开子智能体（也就是「它认为没人在看」的时候），行为就越来越古怪——他补充说自己也不确定模型是否真的在判断有没有人在看，但那就是他的感受。更糟的是，这种风格开始渗进真正提交的代码里，尤其是测试，以及嵌在 HTML 里的 JavaScript 和 CSS：似乎只要「离常规代码隔了一层」，它就会掉进这些模式。他展示的单元测试样本完全无视空白和缩进规范。
HN 评论精华
455 分、328 条评论，同感者众，但也有相当有分量的反驳。讨论意外地在两个方向上走得很深：一是模型为什么变成这样，二是「内卷」这个比喻站不站得住。
「无法审阅」是共鸣最强的一点。 Gigachad 说他观察到同样的现象，新模型喜欢跑那种用尽所有选项标志、完全无法阅读的 bash 命令或 Python 脚本，「这些命令比正则表达式还难读」。meowface 的说法更形象：Astra 是「黑箱废料」的巅峰，整体上确实是个更聪明的开发智能体，但写 GPU shader 之类的东西时，代码有时和 Brainfuck 无异，「它甚至不试图让格式稍微可读一点」。
一条重要线索来自 chambored 和 IceDane：这未必全是模型的锅。他们发现 Claude Code 切到默认 auto-mode 之后，工具链的系统提示本身就在鼓励纯 bash 操作（sed、python 等）。IceDane 说他直接问过模型为什么老用 Python 改代码，模型的解释是这是 auto mode 下提示词的一部分。他推测这可能是因为安全校验模型更擅长处理这类片段，但副作用是那个能把变更实时展示给你看的 write 工具形同虚设。
petesergeant 贡献了本帖流传最广的一句吐槽：我们需要一个词来形容「潜在能力极强、但实际上是个白痴天才」的模型——「不，哥们，我不需要你为了测试你的改动而用 bash 写一个 tmux 模拟器，直接叫我运行那条命令就行」。u8080 接了个同样传神的例子：「我需要 objdump 工具，但 pacman gcc 失败了因为没有 sudo 密码。那就让我来写个编译器、binutils 和反汇编框架吧。」dandanua 预言下一代模型大概会为了拿到一条命令的输出而模拟整个宇宙。Bluestein 则指出了结构性动机：这些行为只是在更快地烧掉更多 token，而供应商没有任何动机去优化简洁、优雅或紧凑——petesergeant 反驳说这只在换供应商很难时成立，而目前换起来很容易。
「内卷」的比喻引出了本帖信息密度最高的一段讨论。 specproc 说这段话让他强烈共鸣，veqq 补了个对应的西方概念：红皇后赛跑。真正精彩的是 MangoCoffee 转述的台湾 PTT 上的一条帖子：AI 终于做到了人类做不到的事——管理者必须给出确切的上下文说明自己到底想要什么，必须支付确切的工资（token），而且不能拖欠。djmips 顺势点破：「有趣的是，你需要喂给模型的那些东西，本来对人类也同样有帮助。」
TeMPOraL 把这一点展开成了本帖最有洞见的评论：智能体所需的任务时「接地」（grounding）其实就是好文档，「skills」其实就是操作手册和用户指南。他描述了一条正在发生的演化链——任何人们希望 AI 使用的 CLI 工具，最终都会长出一个 SKILL.md，然后再长出一个 tool-for-llms 包装器，把程序性知识从 Markdown 搬进包装器，让 skill 更省 token，同时工具和 skill 都针对常见任务做优化——「到这一步，我们做的其实就是 UX 工程」。他认为真正有趣的是给 LLM 的 UX 和给人的 UX 之间的差别：概念、抽象、认知层面几乎完全一样，所以 skills 看起来和写得好的人类文档没有区别；主要差别只在于 LLM 完全不介意排版紧凑难看。
UncleMeat 给出了一个苦涩的现场版注脚：他多年劝说总监投资文档和监控无果，现在总监主动要求团队专门花时间做监控和文档，好让智能体更容易诊断和修复 bug——原因是他的上司嫌这个部门不够「智能体化」。「只不过……因为过去投入不足，我们有一堆服务的机构知识已经消失了，现在大家在让 AI 来写文档。」
反对意见也很有力。 squidbeak 认为这听起来像是所有工程的通病——把最大的努力花在最后那些细小困难的细节上，结果看起来微不足道但在规模上很重要；但他觉得这个论证站不住：代码能力的提升绝非边际性的，Opus 4 才是 16 个月前的事，这些抱怨者有几个愿意扔掉现在的主力模型回到那时候？他的结论是：能力在快速提升但远未理想，两种声音同时为真，所以「内卷」这个标签虽然有意思，最终还是胡扯。
lukeify 提出了另一个角度的观察：默认 medium 设置下的 Astra 感觉比默认设置的 GPT-5.6 Sol 更不严谨、更不周全，「我肯定没有感觉到我们已经到了 AGI」。on_the_train 说这反而值得鼓掌，因为 Sol 素有过度工程化的名声；cbg0 则不买账：花两倍多的价钱，大多数人宁可要那个过度工程化的。
Buttons840 提供了一个务实的解法：花一小时和模型对话直到自己理解概念，然后用自己熟悉的数学公式和变量名把概念表述回去，模型就会用你能读懂的形式重写代码——「到那时，AI 只是在替我打字」。djmips 的回应很直接：「也许你自己写就好了。」最后，mirekrusin 报告了一个奇观：他有一个 Astra 会话已经连续跑了 4 天 13 小时还没停；几天后他回来更新——跑到 5 天 14 小时，放弃的是他，不是 Astra。