Astra 用于编码：我们为什么又要这么做？
像 GPT‑6 Astra 这样的新 OpenAI 编码模型在处理长期、复杂的软件任务时表现非常强大，但许多工程师报告说，它们如今会过度设计、生成子代理、运行庞大的测试套件，并产出难以阅读的“slop”代码，同时消耗远比早期模型更多的 token 和时间。评论者认为，最近的训练似乎更优化于自主的长周期任务完成，而不是面向人类、简洁友好的代码，这让这些代理看起来像是强大但社交化不足的同事，抗拒指导并忽视范围。一些人认为它们对新项目原型或在强测试与规格约束下的紧凑功能具有变革性；而另一些人则发现，如果没有精细的约束和审查，它们很快就会降低代码质量并拖慢团队速度。
关于 Astra 用于编码的总体感受
- 许多人认为 Astra 很能干但也很让人沮丧：它擅长处理长期、复杂的任务，却容易过度设计、范围蔓延，并产出难以阅读的“slop”代码。
- 一些用户回退到了更早的模型（例如 5.6 系列、Luna、Sonnet），理由是性价比更好、行为更可预测。
- 也有人表示，在新项目或中小型项目中，只要严格引导，Astra 确实能显著提升生产力。
代码质量、可读性与“slop”
- 常见抱怨包括：代码密度高、抽象程度过强、格式很差；大量三元表达式；把简单任务重写得过于复杂；测试与实现细节紧密耦合。
- 当 Astra（以及类似模型）在已有且结构良好的代码库中工作时，输出质量会提高，并且会遵循现有模式。
- 有些用户会故意不去阅读 AI 代码，尤其是在风险较低或“用完即弃”的项目里；另一些人则表示，不快速审查会导致代码不可维护，并在未来拖慢进度。
工具使用、Python 脚本与测试
- 模型越来越倾向于编写 Python（或其他脚本）作为通用“补丁工具”，而不是使用内置编辑工具、
sed等。 - 这被视为：
- 对一些人来说，节省 token，适合大规模修改。
- 对另一些人来说，更难审查、容易出错，而且常常是用力过猛。
- Astra 往往会：
- 针对小改动反复运行完整测试套件。
- 生成大量子代理和辅助产物（HTML 报告、文档、工作流），除非加以约束，否则会推高成本和墙钟时间。
长周期代理与训练激励
- 有几位用户怀疑，最近的训练更优化于“自主完成长任务”，而不是“产出干净、可读的人类代码”。
- 结果就是：它很擅长计算机操作、编排和复杂调试，但在作为一个会提问、保持代码简单的协作队友方面表现更差。
- 还有人担心，提供方在财务上受到激励，倾向于那种冗长、token 密集、自我粉饰式的行为。
流程、规格与人的角色
- 普遍共识是：成功取决于：
- 清晰、范围紧凑的规格或“整理过的 epic”。
- 强有力的测试、架构和 API 边界。
- 人类监督应重点关注设计、接口和约束，而不是逐行代码。
- 争议在于，这种工作流到底是否真的能在长期节省时间，还是只是把精力从实现转移到了审查和重构上。