自由翻滚的风铃草
@nanting
有人把一个"类 Jev 模型微调"项目全权交给 GPT-6 Astra 在 Codex 里推进——项目叫 Necro，目标是把 Qwen3.5-0.8B 微调成能在本地做分类、条件判断和打分的小模型；实验设计、数据准备、训练、评估全部放手。结果：跑完 20 次训练、烧掉两份 Pro 的周额度，项目彻底失败、最终废弃。
最能说明问题的是一个细节：新开发集上 1600 条条件题全部答对，换到另一组完整记录上准确率只有 58.33%。复盘才发现训练集与开发集漏掉了同一批情况——比如判断 a ≥ b，生成的数据里只有"等于"和"小于"，唯独缺了"大于"，实际评估这一类时 16 题全错。一个只要查一遍数据生成逻辑就能发现的问题，被开发集满分死死掩盖住了。
过程形态更值得记：修好一种错误、另一项能力就退步，补数据再训、再漏；文档和检查流程写得极细，最关键的数据覆盖却一次次漏掉；最后一次统一重训连中间 checkpoint 都没保存，想回头检查训练过程都没有证据。
他的结论很直接：Astra 会写代码、会调工具、能连续执行很多步，但一旦需要自己设计实验、判断结果、调整方向，就暴露出严重局限——把目标交出去之后，他仍然要替它发现关键问题、决定什么时候该停、哪个方向值得继续，而这些恰恰是"全权负责"最核心的工作。
我的看法：这是一份含金量很高的失败复盘，它把两件常被混为一谈的事分开了——"能连续执行很多步"和"能负责一个实验"。前者是流程自动化，今天已经不稀奇；后者要验数据、敢说停、知道哪一步是关键，那才是判断力。
它还留下一条可迁移的教训：开发集满分永远值得怀疑——先查数据生成有没有系统性缺口，再谈准确率，否则指标越漂亮、跑得越远、错得越彻底。
边界：这是一人一手实测（221 赞、6.9 万阅），任务构造与数据未公开、无法复现；"过度营销"是他的个人判断，Astra 的表现也会随版本变化。
