先把两个词拆开看到“联名警告”和“3天奇迹”放在一起很容易产生一种错觉好像 AI 已经能自己造 AI而且几天就能完成所以人类需要紧急刹车。这里其实混了两个层面。一个是治理层面。2023 年 3 月Future of Life Institute 发起了一封公开信呼吁至少暂停训练比 GPT-4 更强大的 AI 系统六个月直到建立共同治理机制。签署者包括 Elon Musk、Steve Wozniak 等人。我没有逐条核验当前公开名单里的所有签名者也没有对这封信的政策主张做价值判断。另一个是工程层面。所谓“AI 造 AI”在真实开发里通常不是“一个模型凭空发明另一个模型”而是用自动化流程完成模型搜索、训练、蒸馏、评估、部署。它可以提效但不能自动解决数据质量、评测可信度、安全边界和工程成本问题。我的判断是AI 造 AI 有几分真取决于你问的是哪一层。如果问“能不能让机器自动筛选模型和超参数”这是真的。如果问“能不能让模型辅助生成训练代码”这也是真的。如果问“能不能让一个模型蒸馏另一个模型”这也是真的。如果问“能不能 3 天从零训练一个强通用大模型”这个说法基本不可信。如果问“能不能让 AI 自己完成数据、训练、评估、对齐、上线、回滚全闭环并且不需要人负责”至少在当前工程实践里不能当成确定事实。“AI 造 AI”到底在说什么很多宣传里的“AI 造 AI”其实至少包含四类技术。它们经常被混成一个词但工程含义完全不同。方案/特性优点缺点适用场景AutoML / 自动模型搜索能自动比较多个模型和超参数减少人工试错只能搜索预设空间不会真正发明新范式结构化数据、小模型、传统机器学习任务LLM 生成训练代码能快速写数据预处理、训练循环、评估脚本代码可能有幻觉需要人审和测试工程脚手架、实验脚本、重复性代码模型蒸馏 / 教师学生能把大模型知识压缩到小模型降低推理成本依赖高质量教师模型和合适评测集端侧部署、低延迟服务、成本优化合成数据 评估 Agent能批量生成样本、自动跑评测、辅助发现问题容易数据污染、指标虚高、分布偏移数据不足、评估自动化、实验编排这里的关键是这些技术可以组合但不能把组合后的结果简单包装成“AI 自主造 AI”。一个更准确的说法是AI 系统可以帮助工程师更快地完成模型生命周期中的一部分但模型生命周期仍然需要人定义目标、设计数据、设置边界、审查结果。3 天奇迹能发生但要看起点“3 天做出一个 AI 系统”这句话单独看并不荒谬。真正的问题在于3 天从什么开始如果起点是一个成熟平台已经具备这些东西现成基座模型已清洗的业务数据可复用的训练 pipeline已建好的评测集模型部署和回滚机制GPU 资源队列日志、监控、权限系统那么 3 天做一个可演示系统不是完全不可能。但这类“3 天”通常不是从零造模型而是站在已有模型和已有工程平台上做集成。如果起点是“没有任何基座模型、没有数据、没有评测、没有算力”那 3 天从零训练一个强通用模型工程上不成立。原因不是概念上做不到而是现实约束太硬高质量语料需要长时间采集、清洗、去重大规模训练需要稳定集群和容错机制模型能力需要多轮评测、对齐和红队训练失败、中断、数据污染、指标漂移都需要处理商业上线还需要安全、隐私、合规、监控和回滚。对于某个具体商业项目是否真用 3 天从零完成我没有拿到可复核的训练日志、数据快照和评测代码因此不把它当作事实。更稳妥的判断是3 天可以做出一个应用原型但很难做出一个可审计、可长期运行的模型工程。一个可验证的最小工程骨架自动选模型不是自动造模型先看一个比较朴素但真实的例子用 Python 自动选择模型和超参数。下面示例按 Python 3.11、scikit-learn 1.4 常见 API 组织。不同版本可能有差异但核心思路一致。fromsklearn.datasetsimportmake_classificationfromsklearn.model_selectionimporttrain_test_split,GridSearchCVfromsklearn.pipelineimportPipelinefromsklearn.preprocessingimportStandardScalerfromsklearn.ensembleimportRandomForestClassifierfromsklearn.treeimportDecisionTreeClassifier X,ymake_classification(n_samples2000,n_features20,n_informative8,n_redundant2,random_state42,)X_train,X_eval,y_train,y_evaltrain_test_split(X,y,test_size0.2,random_state42)pipePipeline([(scaler,StandardScaler()),(clf,DecisionTreeClassifier()),])param_grid{clf:[DecisionTreeClassifier(random_state42),RandomForestClassifier(random_state42),],clf__max_depth:[3,5,None],}gridGridSearchCV(pipe,param_grid,cv3,scoringaccuracy,n_jobs-1,)grid.fit(X_train,y_train)best_modelgrid.best_estimator_ best_model.fit(X_train,y_train)print(Best params:,grid.best_params_)print(Best CV score:,grid.best_score_)print(Eval accuracy:,best_model.score(X_eval,y_eval))这段代码说明的是“自动搜索”不是“AI 造 AI”的神话。它做的事情很有限在预设模型里比较决策树和随机森林在预设超参数里搜索max_depth用交叉验证选择看起来更好的组合在独立评测集上看最终表现。为什么这么写因为真实项目里模型选择往往不是拍脑袋决定的。工程师需要知道在当前数据分布下哪个候选模型更稳定。但这里也有明显限制搜索空间是人给的指标是人选的数据是人准备的过拟合风险仍然需要人审查如果评测集泄漏自动搜索会放大错误。所以它只能叫“自动化建模”不能叫“模型自主创造模型”。更接近“模型造模型”的是蒸馏真正有“模型生成模型”味道的技术是知识蒸馏。常见场景是教师模型很强但推理成本高学生模型更小部署更便宜。学生模型不直接只看真实标签还学习教师模型的输出分布。下面代码按 PyTorch 2.2 常见训练循环写法组织。它不是完整工程只说明结构。importtorchimporttorch.nnasnnimporttorch.nn.functionalasF teacher.eval()student.train()criterion_klnn.KLDivLoss(reductionbatchmean)criterion_hardnn.CrossEntropyLoss()T2.0alpha0.5forepochinrange(num_epochs):forxb,ybintrain_loader:withtorch.no_grad():teacher_logitsteacher(xb)teacher_probsF.softmax(teacher_logits/T,dim1)student_logitsstudent(xb)student_log_probsF.log_softmax(student_logits/T,dim1)distill_losscriterion_kl(student_log_probs,teacher_probs)hard_losscriterion_hard(student_logits,yb)lossalpha*distill_loss(1-alpha)*hard_loss optimizer.zero_grad()loss.backward()optimizer.step()为什么这里会出现teacher_probs和student_log_probs因为 KL 散度损失要求输入是 log 概率目标可以是概率分布。F.log_softmax给模型输出做对数概率归一化F.softmax给教师模型输出做概率分布。温度T越高软标签越平滑学生越容易学到类别之间的关系。蒸馏看起来像“模型教模型”但它仍然有几个前提教师模型不能随便用必须质量可靠学生模型的容量要足够损失函数、温度、权重需要人调评测集必须独立否则会出现“教师和学生一起错”的情况如果教师模型存在偏见或幻觉蒸馏会把问题压缩进小模型。我没有在这篇文章里实际执行上述脚本并给出准确率、损失下降曲线或推理速度提升数字。这里只讨论代码结构避免把示例数字当成实验结论。Agent 调度让“造”变成可审计流程如果用 LangChain 这类框架可以把实验流程封装成 Agent 或工具链。具体 API 会随版本变化我没有在本文验证某个具体 LangChain 版本的接口写法所以不展开框架细节。更底层、更稳定的做法是用普通 Python 写实验编排。fromdataclassesimportdataclassfromtypingimportAny,CallabledataclassclassExperimentResult:name:strmetric:floatmetadata:dict[str,Any]defrun_one(name:str,model_factory:Callable[[],Any],X_train,y_train,X_eval,y_eval,metric:Callable[[Any,Any],float],)-ExperimentResult:modelmodel_factory()model.fit(X_train,y_train)predmodel.predict(X_eval)scoremetric(model,pred)returnExperimentResult(namename,metricscore,metadata{model_type:type(model).__name__,trained_on_size:len(X_train),eval_size:len(X_eval),},)defrun_campaign(candidates:dict[str,Callable[[],Any]],X_train,y_train,X_eval,y_eval,metric:Callable[[Any,Any],float],)-ExperimentResult:results[]forname,factoryincandidates.items():resultrun_one(namename,model_factoryfactory,X_trainX_train,y_trainy_train,X_evalX_eval,y_evaly_eval,metricmetric,)results.append(result)bestmax(results,keylambdar:r.metric)best.metadata[all_results][{name:r.name,metric:r.metric,model_type:r.metadata[model_type],}forrinresults]returnbest这个例子看起来简单但它比很多宣传更接近真实工程。它解决的问题不是“AI 自己创造模型”而是一次跑多个候选模型保留每个候选的评估结果把最优模型和所有结果记录下来后续可以审计“为什么选这个模型”。为什么要把all_results写进 metadata因为模型选择最怕只看最终指标。工程师需要知道第二名、第三名差多少需要知道最优模型是不是只在某个评测集上侥幸胜出需要知道候选池是否足够合理。没有这些记录“AI 造 AI”很容易变成“黑盒选择器”。哪些地方最容易失真1. 把“应用集成”说成“从零训练”很多演示里所谓 3 天做出 AI 系统实际是调用现成大模型 API用提示词做任务拆解用向量数据库做检索用 LangChain 或类似框架编排 Agent用少量数据做微调或评测。这确实能快速出产品原型但不能等同于训练了一个新模型。【注意】工程汇报里要区分三件事模型训练模型微调模型应用集成。这三者成本、风险和时间完全不同。2. 把“自动评测”说成“自动可信”自动评测可以跑得快但可信度取决于评测集质量。如果评测集存在这些问题和训练集重叠样例太少只测 happy path没有困难样本没有安全样本没有边界样本那么自动评测只会把错误结论包装得更漂亮。3. 把“合成数据”说成“真实数据替代”合成数据很有用尤其在冷启动、数据脱敏、困难样本生成、评估集构造里。但它不能天然替代真实数据。原因很直接合成数据可能继承生成模型的偏见可能缺少真实世界噪声可能不符合业务分布可能形成“模型教模型越教越自洽但越来越偏”的循环。我见过一些自动数据增强流程最终把模型指标抬高了但线上真实反馈变差了。这里没有公开实验数据支撑所以我不把它写成普遍结论。但从工程机制看这个问题确实存在合成数据如果没有真实采样验证就容易造成指标漂移。4. 把“代码生成”说成“工程完成”LLM 写训练代码确实快比如生成 PyTorch 训练循环写 Hugging Face 数据加载写评估脚本写 Dockerfile写 CI 流程生成单元测试。但它不能自动完成工程责任。代码生成后仍然需要版本控制静态检查单元测试集成测试数据契约校验随机种子记录资源配额控制失败重试机制模型卡和数据卡。否则“AI 写代码”只是把错误生成得更快。联名警告对工程师意味着什么公开信呼吁暂停训练更强大模型这个主张本身是否合理不是这篇文章要争论的重点。从工程落地看它至少提醒了一件事能力越强越需要可审计。如果“AI 造 AI”真的进入生产系统上线前至少要留下这些记录训练脚本和配置文件的 git commit数据版本、数据快照或数据哈希随机种子模型权重哈希训练资源消耗包括 GPU、时长、成本评测集来源和切分方式离线指标和在线指标失败样例集合安全红队测试记录回滚策略和人工接管入口。为什么需要记录数据哈希因为模型效果变化时很难判断到底是训练代码变了、数据变了、评测集变了还是环境依赖变了。没有数据哈希排查会非常痛苦。为什么需要记录随机种子因为深度学习训练有不确定性。同一个脚本两次跑结果可能不同。如果没有种子你很难复现实验。为什么需要失败样例集合因为只看平均指标会掩盖风险。一个模型可能总体准确率很高但在关键边界上严重错误。【关键结论】AI 造 AI 的工程价值不在于“去掉人”而在于“把人从重复劳动里解放出来同时让人能更好地审计系统”。3 天奇迹里真正能压缩的是哪部分如果把模型工程拆成阶段自动化能压缩的地方其实比较明确。阶段是否能被 AI/自动化压缩压缩程度需求定义能辅助整理但不能替代人低数据收集能辅助标注、去重、合成中数据清洗能自动化很多规则中高模型选择AutoML 可以比较中超参数搜索自动搜索可提效中训练代码LLM 可生成脚手架中训练执行调度系统可自动化中离线评测可自动跑但质量依赖评测集中高安全对齐可辅助红队但不能全自动低到中上线审批可辅助材料但责任不能转移低生产监控可自动采集和告警高从这张表能看出所谓 3 天奇迹通常压缩的是“训练代码、数据清洗、超参搜索、评测执行”这些工程环节。它很难压缩的是“需求判断、数据真实性、安全边界、责任归属”。哪些“AI 造 AI”说法可以认真听我认为下面几类说法有工程价值。1. 自动搜索小模型比如结构化数据分类、回归、排序、异常检测。AutoML、贝叶斯优化、超参搜索确实能减少人工试错。适合场景是任务边界清楚数据量中等指标明确不需要复杂安全对齐模型可解释性要求可控。2. 用大模型辅助写实验代码这很实用。工程师不需要每次手写数据加载、训练循环、评估指标、日志记录。但前提是代码必须进版本控制必须跑测试必须有数据校验必须保留人工 review。3. 用蒸馏降低部署成本这是真实收益。很多业务不需要把巨大模型直接上线。通过蒸馏、量化、裁剪可以做出更小、更快、更便宜的模型。但要注意小模型可能在大模型擅长的长尾问题上失败蒸馏不能修复教师模型的系统性错误评测必须覆盖真实业务分布。4. 用 Agent 编排实验流程Agent 可以负责跑实验、收集日志、比较结果、生成报告。但它不能替代最终判断。【注意】Agent 越自动越需要清晰权限和审计日志。否则一个错误配置可能触发大量无效训练浪费 GPU还会污染模型仓库。哪些说法要谨慎听下面几类宣传需要额外证据。1. “完全无人干预训练出可用大模型”如果没有人定义目标、没有数据契约、没有评测标准、没有安全审查这个说法不能接受。2. “3 天从 0 到 1 训练强通用模型”如果没有公开算力、数据、训练日志、评测方法我不把它当作可验证事实。3. “模型自己证明自己安全”模型可以辅助生成红队样例但安全结论不能只由模型给出。4. “自动对齐已经解决幻觉和偏见”目前自动化对齐可以辅助评估但不能宣称彻底解决。不同任务、不同数据、不同用户场景都需要持续验证。我的结论AI 造 AI有几分真如果按工程实现看我认为“自动化”是真的“辅助生成”是真的“压缩部署成本”是真的“实验编排提效”也是真的。但如果把它理解成“模型可以完全自主发明、训练、评估、对齐并上线另一个强模型”当前还不能这样判断。3 天奇迹也不是完全不可能但必须问清楚起点。3 天做一个基于现成模型的应用原型可以。3 天在一个成熟平台上微调某个任务模型有可能。3 天自动搜索多个小模型并选出最优有可能。3 天从零训练一个可验证、可部署、可审计的强通用模型工程上很难成立。联名警告和 AI 造 AI 并不是对立关系。它们指向同一个问题技术能力扩张的速度正在超过很多工程治理和评估机制的成熟速度。对一线工程师来说真正要做的不是简单站队“暂停”还是“加速”而是把 AI 造 AI 放进可审计流程里数据要能追溯训练要能复现评测要能质疑模型要能回滚风险要能记录责任要能落到人。能做到这些AI 造 AI 才是工程工具。做不到这些它更像一个被包装得很快的黑盒。