一个模型拿到任务后自己建 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 编程从生成代码推进到了管理代码变更。反过来也要承认这个方向目前还停在演示阶段——状态机的鲁棒性、反馈的优先级、资源消耗的边界都没有公开数据支撑。对企业团队来说短期内能观察的是这类能力进入生产环境大概率从人工审核仍然保留的半自动模式开始。完全无人值守的自动编程在状态机异常处理被证明可靠之前更适合出现在演示视频里。目前没有公开信息说明状态机在异常情况下的表现也没有多源反馈优先级的具体实现。一个还没被回答的问题是当反馈互相矛盾时模型凭什么决定听谁的——这个问题的答案决定了自进化编程离真实项目还有多远。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版