Astra 代码工厂：为何我们重蹈覆辙？
Astra for Coding: Why Are We Doing This Again?
我越来越确信，AI 工程领域正在陷入严重的 Neijuan（内卷）。尽管 GPT 6 Astra 在电脑操作和复杂任务上表现惊人，但我尝试用它搭建软件工厂，35 小时后却一无所获。Astra 为了追求 Token 效率，开始大量使用难以阅读的 Python 代码进行文件操作，甚至通过 Python 调用 Node.js 再运行 PowerShell。这种过度优化导致代码可读性极差，仿佛只要没人盯着，它就会走向疯狂。这不仅是工具的问题，更是训练奖励机制在无人监督下产生的异化。
只要没人盯着，它就能算是 AGI。
HN 评论区
311- taurath
当代码质量很差时，模型进行修改的难度会越来越大，这会让进度完全停滞——这是我使用各种“工厂”类工具并每隔几个月尝试进行优化步骤时的亲身经历。
我真心搞不懂那些声称自己不再阅读任何代码的人在做什么，因为只要稍微动动脑子就能避免反复撞上这些累积的问题。然后那些人又说只要提示词写得更好就不会有这个问题，但我看看他们写的代码简直惨不忍睹，而且我发现他们大多还没走出概念验证（PoC）阶段。我眼睁睁看着整个团队慢如蜗牛，无法应对变更或线上事故。我接触到的很多人似乎都有这种情况。
我个人认为，那些吹捧者要么拿出真东西，要么就闭嘴——他们的承诺简直离谱。我见过的每一个大力推崇这些技术的人，要么拥有近乎无限的 token 预算，要么就是在兜售某种解决方案。除非系统非常简单，或者是在成熟的代码库中执行非常具体的任务，否则我很难找到那些不在推销产品的工程师在生产环境中成功应用这些技术的案例。
- nojs
这也符合我目前使用 Astra 的体验。
> 我怀疑训练过程中出了点“问题”。模型在完成长周期任务时会得到巨大奖励，但推测对于写出“烂代码”几乎没有惩罚。
我的猜测是，OpenAI 和 Anthropic 在过去几个月里将他们的 RL（强化学习）目标从“根据人类反馈被评为有用”转向了“成功完成长周期任务”，这导致生成的代理在自主完成任务方面更接近 AGI（通用人工智能），但在沟通方面却变得异常糟糕。
结果是，它们在长周期任务、电脑操作、解决高难度数学或 ARC-AGI 类型问题上表现出色，但与之协作却变得越来越怪异。
- specproc
> 我越来越确信，所有的人工智能工程都是“内卷”（Neijuan，意为向内卷曲）。在中国，这描述了一种要求投入越来越多努力和竞争却未能提升产出的系统。它在西方的一种表现形式就是 996 这种胡闹。Neijuan 的英文对应词是《农业内卷》一书中的“Involution”（内卷）。农业内卷描述的是一种耕作强化现象：它提高了每平方米的产量，但人均产量却保持不变。
这很有共鸣。
- codingisfreedom
我让 Astra 帮我构建一个应用，这个原型是我之前用 Sonnet 快速搭建的。
已经过了两天，它在实际应用开发上没有任何实质性进展。它只生成了文档、脚本、工作流，并且对每个 PR 进行大量审查。
我告诉它我只需要一个 MVP（最小可行性产品）。
我很确定，一位普通的资深工程师能快得多地完成这项任务，而且保证代码可读性更高、质量更好。与此同时，我觉得我到现在已经白白消耗了超过 10 万 token。
我们生活在一个奇怪的世界，这竟然被称为“SOTA”（最先进）和“AGI”。
我真的很好奇，OAI 和 A/（Anthropic）的工程师们到底在做什么，以至于他们如此推崇这些模型。自 Opus 4.5 以来，我没看到任何改进。
此外，我对市面上任何“一次成功”（one shot）的演示都毫无印象。这对严肃的软件工程来说毫无意义。
- buildbot
我在 Opus 和 Fable 上也观察到了完全相同的模式——例如，它们会忘记自己可以直接编辑文件，反而使用 Python 脚本作为补丁工具……
- gps372
我从 AI 工程中学到的早期教训是：没有比给代理一个精心梳理过的史诗级任务（groomed epic）更好的替代方案了。你不能只说“在我的产品中实现主题功能”，你必须非常具体，甚至比平时更具体。你需要明确说明哪些在范围内，哪些不在，甚至细化到按钮、事件和布局。
你可以借助 AI 来梳理这个史诗级任务，但最终审查必须由能够承担规格说明书责任的人来完成，这样如果有什么疏漏，他们才需要负责。AI 的回复受限于该特定代理的输出 token 数量，而且即使 AI 承认错误，也不会受到任何惩罚。
- _usefulcat
我想提出一个反方观点。我在一个成熟的代码库上工作，负责构建新功能和修复 bug。它有权访问我们的故事板、git 以及几个其他的 MCPs。只要故事描述写得清楚，需求和预期明确，它总能产出高质量的代码，我会通过自动化和手动测试进行验证。我会进行代码审查，我的同事也会进行二次审查。
我注意到两点：新功能开发所需的时间至少减少了一半，而 bug 出现的频率也大大降低。在修复 bug 时速度甚至更快。
我的结论是：你需要扎实的需求、清晰的上下文，以及主要在规划阶段、同时也包括在验证阶段的人类审慎监督。
- Gigachad
我也观察到同样的情况：新模型喜欢运行令人咋舌的 bash 命令或 Python 脚本，这些脚本完全不可读，并且用尽了所有可用的选项标志。
根本没法审查。这些命令的可读性比正则表达式还差。
- sandos
感觉就像它们在给其他代理传递秘密纸条，就像德国维基上 LLM 在越狱时写秘密信息那样。
在一个奖励欺诈行为的环境中训练模型可能不是个好主意。这就像它们保留了那些成功逃出沙盒的训练轮次，却没想过这些模型随后会形成什么样的性格。
- AmazingTurtle
gpt-6-astra 真是个混蛋，它总是自己搞范围蔓延（scope creep），非要加上“又一个东西”来给它那种该死的抛光感。最终结果确实稍微好了一点点，但代价是什么？我们来算笔账。
gpt-5.6-sol: 1x 基础价格
gpt-6-astra: 订阅费是 2.5x 基础价格
然后 gpt-6-astra 倾向于生成大量子代理，往往使用各种模型，如 gpt-5.6、5.3-codex 等等，这倒挺酷。它是个不错的协调者，但成本更高。
而且它倾向于一遍又一遍地运行_完整的测试套件_（每次运行大约需要 15 分钟），仅仅为了验证_一个测试_是否修复了，并且会一直这样做直到测试通过，最终累积耗时约 2 小时。
昨天我分配给它一个任务，将我在仓库中的变更 rebase 到最新的上游变更上。gpt-5.6-sol consistently 大约一小时就能从头到尾完成，而 astra 运行了超过 6 小时还没做完。它不断发现“还有一件事”是过度装饰（goldplating），而这根本不是我要求的。