欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

Qwen3.8-Max发布 自进化编程是噱头吗

6 天前 AI模型Qwen自主编程工程实践

Qwen3.8-Max发布 自进化编程是噱头吗

Qwen3.8-Max自主编程场景

一个模型拿到任务后，自己建 GitHub Issue、自己写代码、自己触发 CI、测试挂了自己回退修复、修好了自己合并 PR——整个过程没有人在中间点确认。这是 Qwen3.8-Max 发布材料里最值得看的部分。参数规模是 2.4 万亿、激活参数 95B，这个数字对大多数团队没有操作意义，但"模型开始自己跑一个开发流程"这件事，直接影响我们怎么看待 AI 写代码。

十天编程里真正跑起来的是什么

官方演示里，模型独立完成了一个十天级的编程任务，过程中产出了 265 次 commit。数字本身不重要，重要的是背后的结构：模型自己构建了一个自进化 harness，用 GitHub Issue 状态机管理任务进度，靠 CI 检查结果做验证，再综合社区反馈、用户反馈和模型自测来驱动下一轮迭代。

这跟过去两年主流的 coding agent 用法有本质区别。之前的 agent 是"指令-执行"：你给一个任务，它写一版代码，然后等人来 review，链条的终点永远是人的判断。这次演示里，验证和迭代的循环被模型自己接管了——CI 成了裁判，状态机成了项目管理工具，人的位置从"每个环节都要确认"变成"只在起点和终点出现"。

自主编程反馈闭环示意

对做工程平台的人来说，这个变化值得琢磨。过去我们讨论 AI 编程，核心问题是谁来保证代码质量；现在模型把质量验证也纳入了自己的闭环，问题就变成：这个闭环本身可不可信。

从复现论文到超过原结果

另一组演示是科研场景。模型复现论文实验之后没有停下来，而是继续自我进化，AIME24 分数提升了 2.7 分。还有 24 小时内在竞赛场景击败 458 支人类队伍的记录。这类数字看看就好——竞赛环境跟生产环境差得很远——但它和"自动编程"指向同一个机制：模型不只是生成内容，而是在一个反馈回路里反复调整自己的产出。

无监督闭环的代价

这里有个容易被忽略的工程问题。模型自己搭的状态机，异常情况下怎么办？多源反馈——社区、用户、模型自测——的优先级怎么定？CI 因为环境问题误报失败，状态机选择重试还是回退？模型陷入"修改-失败-再修改"的循环时，算力成本谁来买单？

公开资料里没有这些细节。演示里的状态机运行正常，但没有鲁棒性测试数据说明它在异常输入、网络抖动、CI 误报下的表现。从工程角度看，这正是落地前最需要回答的问题——一个会自己合并 PR 的系统，一旦判断失误，影响范围比一个只会生成代码的助手大得多。

我的判断是，参数规模是这轮发布里最不重要的部分。真正值得关注的是"模型开始运行自己的开发流程"这个方向，它把 AI 编程从"生成代码"推进到了"管理代码变更"。反过来也要承认，这个方向目前还停在演示阶段——状态机的鲁棒性、反馈的优先级、资源消耗的边界，都没有公开数据支撑。

对企业团队来说，短期内能观察的是：这类能力进入生产环境，大概率从"人工审核仍然保留"的半自动模式开始。完全无人值守的自动编程，在状态机异常处理被证明可靠之前，更适合出现在演示视频里。

目前没有公开信息说明状态机在异常情况下的表现，也没有多源反馈优先级的具体实现。一个还没被回答的问题是：当反馈互相矛盾时，模型凭什么决定听谁的——这个问题的答案，决定了自进化编程离真实项目还有多远。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。