AI 编程现在的主流玩法还是人下指令、模型写代码、人 review。Frontis-MA1 这篇工作把链条往前推了一步让模型在机器学习工程任务上自己完成写草稿、改进、调试、杂交的进化循环人在旁边只维护验证环境。四个算子写、改、调、杂交Frontis-MA1 是一个 350 亿参数的 AI4AI 模型基于 OpenMLE 框架训练。框架包含可验证的任务环境、操作学习模块和长时程搜索。模型通过执行反馈驱动的强化学习和监督微调掌握了四个程序进化算子Draft起草、Improve改进、Debug调试、Crossover交叉。整个过程可以这样理解模型先写一版实现跑任务环境拿到反馈根据反馈改进出错了自己调试两个不同方案之间做交叉产生新方案再进入下一轮。人不需要逐行介入只负责保证验证环境可信。放到机器学习工程的具体场景里这个循环其实很像一个资深工程师的日常写训练脚本看 loss 曲线改超参数跑实验对比觉得思路不对就换个方向。区别在于这套循环跑在可验证的任务环境里每一轮改进都有客观反馈而不是靠人肉盯实验日志。算子里的 Debug 尤其值得注意——模型需要先定位自己实现里的错误再修复这比照着提示改代码要难一层。39.39%到71.21%这个数字怎么读论文在 MLE-Bench Lite 上报告了成绩基础模型的奖牌平均分是 39.39%叠加 OpenMLE-Evo 后到 60.61%OpenMLE-Evo-Max 进一步到 71.21%。提升幅度相当可观而且是在机器学习工程这类真实任务上的结果不是玩具级 benchmark。有两点需要放在一起看。训练时对评测基准做了数据去重这是 benchmark 可信度的基本要求说明分数不是背题背出来的但也要意识到这个成绩是在特定评测集上的表现跨任务的泛化能力还没有公开数据。部署之前要算清楚的账落到实际部署这套流程有两个现实问题。一个是算力。长时程搜索的代价是推理时要跑多轮生成→执行→反馈→再生成的循环开销比单次生成高得多。生产环境要不要开这个循环、开几轮是纯粹的成本决策。论文没有给出这部分的数据。考虑到搜索轮次和模型参数量这个成本不是所有团队都愿意承担的。另一个是验证反馈环。如果模型输出的改进直接进代码库测试、静态检查、环境还原这些验证环节的可靠性就成了安全边界。反馈信号错一次模型就沿着错误方向迭代一轮。论文讨论的是训练方法没有展开生产环境里验证链路怎么设计。从工程自动化的角度看真正值得关注的是验证环境在整个链路里的角色——模型自我改进能走多远取决于反馈信号的质量而不是模型本身。对自动化工程团队来说与其纠结模型会不会失控不如先把可验证的任务环境搭好。至于执行反馈驱动的强化学习会不会让模型在特定环境上过拟合影响它在未见过的工程任务上的表现目前没有公开数据能回答这可能是接下来最值得追踪的问题。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版