FACET：当AI给自己出题时，怎么保证题目不出错？

2026年初，如果你去问任何一个做AI智能体训练的团队："你们现在最头疼的事情是什么？"得到的答案大概率不是"模型不够聪明"，而是"题目不够好"。

这话听起来有点反常识。毕竟我们平时的印象是，AI能力的瓶颈在算法、在算力、在数据规模。但对于训练能操作电脑终端的AI智能体来说，真正卡脖子的环节变成了：怎么给它出一道"靠谱"的练习题。

这篇论文叫FACET，来自中国科学技术大学和上海AI实验室的联合团队。它要解决的问题说起来很朴素：让AI自己给自己出题、自己解题、自己判卷，这个闭环里到底会出什么岔子，以及怎么把这些岔子一个个堵上。

**核心问题：一道题的四个部分，只要有一个对不上，整道题就废了**

先说清楚，训练一个"终端智能体"到底需要什么样的练习题。

**终端智能体**：指能够操作命令行界面完成任务的AI系统，比如帮你安装软件、整理文件、跑数据处理脚本，它需要像人类工程师一样在电脑终端里敲命令、看反馈、解决报错。

一道合格的终端任务，长得不像我们熟悉的选择题或者填空题。它是一个"四件套"：一段任务说明（告诉AI要做什么）、一个初始化好的运行环境（提前装好的电脑系统，里面有该有的文件和软件）、一份参考答案（证明这道题真的能被解出来）、一套自动判分程序（用来检查AI做得对不对）。

这四个部分必须严丝合缝地对上。任务说明里提到"处理销售数据.csv"，环境里就真的要有这个文件；参考答案里用了某个Python库，环境里就得装好这个库；判分程序检查的状态，必须是解题过程真能达到的状态。

论文里给出的一个数字很能说明问题：在没有优化的对照流程里，AI生成了449个看起来完整的任务包，但真正能通过"环境能跑、答案能过关、判分程序认可"这套完整验证的，只有139个，合格率27.8%。换句话说，超过七成的题目看着像那么回事，实际一跑就崩。

这就好比你去买家具，说明书写着"A零件插入B孔"，结果拆开箱子发现根本没有B孔，或者B孔是给别的型号留的。说明书本身写得挺像样，可就是装不起来。如果厂家从不实际组装一遍就发货，这种货不对板的情况只会越来越多，最后消费者收到的不是家具，是一堆互相不兼容的木板。

论文识别出两个具体的病根。第一个是"信息在传递中丢失"：原始的技能素材里其实包含很多细节，比如某个操作依赖什么工具、中间会产生什么临时文件、有什么步骤上的限制，但是经过多轮AI生成加工，这些细节会被逐渐简化掉，最后剩下的题目又浅又干。第二个是"各部分自说自话"：任务说明可能提到一个文件，但环境里没建这个文件；参考答案假设用某种数据格式，但判分程序按另一种格式检查。就算把文字说明在各个生成步骤间传递，也没法保证大家用的是同一个"真实世界"。

**FACET的解法：先想清楚故事，再动手布置场景，最后才写考题**

面对这两个问题，FACET没有走"多生成几遍然后挑好的"这条捷径，而是重新设计了整个流程的顺序。

它把整个任务生成拆成三个阶段。

第一阶段是**素材收集**。团队从OpenClaw、ClawHub和GitHub上收集了超过7.1万个公开的"智能体技能包"（可以理解成一个个打包好的操作教程，比如"如何用ffmpeg压缩视频"、"如何用SQL清洗一批脏数据"）。这些技能会先经过安全过滤，剔除涉及隐私、需要访问私有网站的内容，然后被结构化整理，记录清楚每个技能需要什么工具、输入输出是什么。

接着系统会给每个技能设想可能的应用场景，把语义相近的场景聚在一起，凑出"技能组合"。比如"读取Excel表格"和"生成可视化图表"这两个技能，很可能会被识别为经常一起出现的组合，因为现实中用户往往是先处理数据再画图。

第二阶段是这篇论文里我觉得最有意思的设计，叫**场景重构**。

**场景重构**：不直接把技能组合翻译成任务描述，而是先通过五个维度（目标、场景背景、能力关系、状态变化、输入输出与工具）重新理解这组技能之间到底应该怎么配合，恢复出一个完整连贯的用户使用故事，再把这个故事转成正式的任务文档。

为什么要多这一步？直接翻译不好吗？

论文给出的理由是，如果直接把技能组合转成任务描述，生成出来的东西往往只用到每个技能最表面的功能，技能之间真正的依赖关系、生成过程中的中间状态、需要遵守的约束条件，全都被压扁抹平了。就像你请了两位专业厨师来做一顿饭，一位擅长炖汤一位擅长烤肉，如果不给他们讨论菜单的机会，直接各自随便做一道菜端上桌，那顿饭大概率是两道互不相干的菜，而不是一顿有主次搭配的完整晚餐。真正好的晚餐，得先有人想清楚"这顿饭想给客人什么体验"，然后再分派任务，炖汤要炖成什么口味要跟烤肉的调味呼应，上菜顺序怎么安排。场景重构做的就是这个"想清楚整顿饭该怎么做"的工作。

具体来说，场景重构分五步走：先分析每个技能有什么能力和限制，再设想这些技能可能被用在什么真实场景里，然后筛掉那些技能之间关联性不强、只是硬凑在一起的组合，接着把留下的技能编排成一个有逻辑先后的工作流程，恢复出技能之间的依赖和中间产物，最后把这个流程用具体的文件格式、资源、约束条件填充丰满。

这五步跑完，会产出一份"五维场景表示"，包括目标、背景、能力关系、状态、输入输出与工具这五个方面的描述，最终整合成一段完整的自然语言场景说明。基于这份说明，系统先生成"解决方案参考"（记录该怎么一步步解决问题），再依据解决方案参考生成"指令参考"（记录任务到底要求什么）。这两份参考文档生成完，还有个专门的模型去检查它们是不是在讲同一件事：初始状态一致不一致、指令里提的每个要求解决方案里有没有对应、解决方案产生的每个效果最终状态里能不能观察到。

这个先讲故事、再定文档、后核对一致性的顺序，本身就是在做"防止各说各话"这件事。

**第三阶段是这篇论文的另一个核心创新，我把它称为"先搭好房子再写房产证"。**

具体来说，这个阶段先根据前面整理出的场景说明，规划出需要哪些文件、哪些服务、哪些依赖包，然后真的动手在一个容器里把这些东西全部造出来，包括必要时联网抓取真实的公开资源，把它们本地化，甚至对收集到的数据做适当扩充和干扰（比如往一份结构化数据表里加一些额外记录、干扰字段），让环境看起来不那么像模板化的空壳。

环境搭建完之后，会先启动这个环境，验证它能不能正常跑起来。跑不起来就报错回退给"环境修复"环节，最多允许修三次。修复的时候特意会带上原始的场景说明，防止AI图省事，直接把有难度的任务要求删掉换取"能跑起来"的假成功，那样虽然环境能跑但已经不是原来想要的那道题了。

环境真的搭好之后，系统才开始生成任务说明、解决方案代码和判分程序，而且这三者都能读取同一个已经跑起来的真实容器状态。

**容器状态共享**：环境搭建成功后，把这个真实运行的系统状态（有哪些文件、什么路径、哪些服务在跑、依赖版本是什么）当作一个共享的参考基准，让指令、解决方案、判分程序这三个生成步骤都对照同一份真实信息去写，而不是各自凭空想象。

这一步的价值在哪里？想象你在装修房子，如果水电工、木工、油漆工完全不看现场实际情况，只是分别照着图纸各干各的，最后大概率会出现油漆工的开关面板位置和水电工实际布线对不上的尴尬。真正靠谱的做法是，水电走完线之后，把实际走线图给后面的工种看，让大家照着"真实发生的情况"而不是"最初的设想"去继续干活。FACET就是让指令、答案、判分程序都对照这份"真实发生的容器状态"去写，谁也不会写出一个环境里根本不存在的文件。

生成完指令后，系统会拿指令和解决方案参考去生成具体的解决方案代码，然后真的执行这份代码，观察执行完之后环境变成了什么样子。判分程序是最后生成的，它能同时看到指令、解决方案、执行前状态和执行后状态，这样写出来的判分逻辑更贴近"检查行为和最终状态"而不是死板地比对某一条具体命令，这样即便AI用了另一种同样正确的解法，也能通过验证。

整个任务包最后要经过一套完整的验证：环境能不能正常构建、判分程序在初始状态下是不是正确地判定为"未完成"、参考解法能不能顺利跑完、判分程序在解法跑完之后是不是正确判定为"已完成"。如果哪一步失败了，系统会有一个专门的"路由器"去判断问题出在哪个部件，是环境、解决方案还是判分程序，然后只修那一个部件，而不是推倒重来。最多允许修五轮，修不好就直接丢弃这道题。

这种"哪坏修哪"的策略听起来简单，但背后是个很实际的效率考量。如果每次验证失败都整体重新生成一遍任务，成本会指数级增长，而且很可能把已经正确的部分也改坏了。

**数据说话：题目变难了，但训练效果反而更好**

理论说完了，实际效果怎么样？论文给出了一系列对比数据，我把关键几组列出来。

首先是和其他现有终端智能体数据集的比较。

| 数据集 | 轨迹数 | 平均交互轮数 | 任务数 | 每任务测试点数 | P@1 | P@3 |

| Nemotron-Terminal | 5K | 6.12 | 15K | 6.18 | 40.67 | 48.00 |

| Endless-Terminals | 200 | 4.53 | 2,492 | 5.51 | 83.00 | 87.00 |

| Terminal-Lego | 32K | 5.77 | 15K | 16.60 | 47.00 | 49.00 |

| TerminalWorld | 200 | 11.94 | 1,530 | 3.98 | 57.00 | 82.00 |

| Tmax | 500 | 11.14 | 15K | 3.29 | 80.00 | 86.00 |

| **FACET（本文）** | 1.2K | **11.86** | 6K | **22.77** | 27.00 | 35.00 |

**P@1**：模型第一次尝试就成功解出任务的概率。**P@3**：三次尝试中至少成功一次的概率。

这张表最有意思的地方是，FACET在训练轨迹数量上明显偏少（1.2K，别人动辄几千上万），单个任务的测试点数量却是所有数据集里最多的，达到22.77个，是排名第二的Terminal-Lego（16.60）的将近1.4倍。与此同时，FACET数据集上的解题成功率（P@1只有27%）是所有数据集里最低的。

这不是bug，是feature。测试点数量多，意味着一道题里塞进了更多个独立检查项，AI必须把所有要求都满足才能算通过，只完成主线任务但漏掉一两个细节要求，照样判失败。这就好比一场考试，别的卷子只考三道大题答对方向就给分，FACET这份卷子拆成了二十多个小项逐一打钩，漏一项就扣分，整体通过率自然会被拉低。

真正决定这份"难题"有没有价值的，是拿它训练出来的模型表现如何。

论文团队用DeepSeek-V4-Pro跑了大约6千道FACET生成的验证过任务，收集了1200条完整成功的解题轨迹，拿这些轨迹去微调三个不同规模的Qwen3.5模型，然后在权威的Terminal-Bench 2.1基准上测试效果。

| 模型 | 参数规模 | 微调前 | 微调后 | 提升幅度 |

| Qwen3.5-4B | 4B | 17.60 | 24.72 | +7.12 |

| Qwen3.5-9B | 9B | 27.34 | 35.58 | +8.24 |

| Qwen3.5-27B | 27B | 40.82 | **47.57** | +6.75 |

三个规模的模型都获得了实打实的提升，9B模型的绝对涨幅最大，4B模型的相对涨幅最猛（40.5%的相对提升）。更值得说道的是，27B模型微调之后达到47.57分，只比参数量是它15倍的Qwen3.5-397B（在相同评测设置下拿到49.06分）低了1.49分。用1.2K条精心构造的训练轨迹，追平了近乎大十几倍的模型规模差距，这说明数据质量本身能在一定程度上替代模型规模。

**"几乎做对了但没完全对"，才是终端智能体最大的敌人**

论文还挖出了一个挺扎心的现象。研究团队统计了那6千多个任务的解题过程，发现单个检查项的通过率高达89.40%，但整体任务的完全成功率只有20.94%。

这意味着什么？意味着AI在绝大多数细节上都做对了，但只要漏掉一两个小要求，整道题依然记作失败。进一步细分发现，在所有失败的尝试里，有54%只是差了一两个检查项没通过。

这就好比你考驾照科目二，五个项目里前四个都精准无误，最后一个倒车入库压了一点点线，整体结果依然是不及格。你可能觉得自己已经开得很不错了，但规则不认这个账。这种设计不是为了刁难，而是终端任务本身的真实性质决定的：现实世界里让电脑执行一个操作，只要有一处细节没做对，整个流程就是失败的，不存在"大部分对就算过"这回事。

论文特别强调，任务的难度并非来自单一步骤的复杂性，而是来自"要求的数量和相互关联性"。指令越长，涉及的文件和约束条件越多，牵扯的中间依赖越复杂，一次性把所有要求都精准满足的难度就呈非线性增长。这也解释了为什么处理结构化数据的任务通常比处理长篇文档的任务更容易被AI做对，因为前者的检查点相对独立，后者往往环环相扣。

**先写答案还是先写判分标准？顺序真的很重要**

论文里做了一个特别扎实的对照实验，专门验证生成顺序对任务质量的影响。他们用同样的100组场景素材，分别测试了三种生成顺序：正序（先生成指令，再生成解决方案，最后生成判分程序，这是FACET采用的方式）、逆序（先生成指令，再生成判分程序，最后才生成解决方案）、以及联合生成（三样东西一次性生成完）。

结果差异非常明显。

正序方式的初始有效率是46.5%，逆序只有24.2%，联合生成是37.5%。

为什么先写判分程序再写解决方案会出问题？道理其实不复杂：判分程序是根据一份还不存在的解决方案凭空想象出来的检查标准，就像老师在还没批改学生作业之前，先按照自己脑补的"理想答案"定好评分细则，等真正的学生作业交上来，很可能和脑补的答案对不上号，甚至根本没有标准答案里假设的那种解法。逆序生成失败原因里，"跨部件契约不匹配"占到56.5%，正是这个道理在数据上的体现。

联合生成则把契约不匹配的比例压到了13.3%，但代价是"文件路径和数据结构错位"的比例飙升到38.3%。原因也不难理解，一次性生成三样东西，模型很容易在细节上前后不一致，比如指令里提的文件名和解决方案代码里用的文件名对不上。

论文还做了一个更严格的配对检验，只挑出88组同时通过三种流程验证阶段的场景，两两比较成败情况。正序方案战胜逆序方案的场景有29组，逆序反过来战胜正序的只有9组，用统计检验算出来的p值是0.0017，这个数字小得足以说明这不是偶然。正序对联合生成的胜负比是27比18，统计上没有那么显著（p=0.233），说明这两种方式的差距不算特别悬殊，但正序仍然在初始有效率和最终修复成功率上都占优。

**这套流程真的比现有方案强吗？一场公平的正面对决**

论文最后还做了一个端到端的横向对比，拿FACET和另外两条流程在完全相同的500组技能对输入上做比较：一条是没有场景重构环节的简化版基线流程，另一条是团队复现的TerminalWorld风格构建流程（这是另一篇相关论文提出的方法）。

结果是这样的：基线流程生成了437个看起来完整的任务包，真正通过验证的只有78个，成功率15.6%；TerminalWorld风格流程生成了449个，验证通过139个，成功率27.8%；FACET生成的完整包数量反而最少，只有395个，但通过验证的多达350个，成功率高达70.0%。

这个数字对比很说明问题。FACET没有在"生成数量"上取巧，反而是三者里生成包最少的，却在"能真正跑通"这件事上远远甩开了另外两条流程。350个通过验证的任务里，有182个是第一次就通过验证，另外168个是经过针对性修复才通过的，修复机制在这里发挥了实打实的作用。

更值得注意的是，FACET产出的这些任务并不是靠"简单"取巧换来的高通过率。用DeepSeek-V4-Pro实际去解这些任务，FACET版本的P@1只有25.1%，是三者里最低的，平均需要的终端命令数量高达21.5条，也是三者里最多的。换句话说，FACET生成的任务不仅通过率高，难度也没有被稀释，依然是货真价实的高质量、高复杂度任务。

写在后面

读到这篇论文的时候，最触动我的其实不是那些提升几个百分点的实验数字，而是那个89.40%对20.94%的对比。一个AI系统能把接近九成的细节做对，最后却因为剩下的一成而被判定"完全失败"，这种落差揭示了一件我们平时容易忽略的事：智能体任务的评价标准和人类日常做事的评价标准是完全不同的两套逻辑。人类做事讲究"抓大放小"，容错率高；机器执行任务讲究的是"全对或全错"，一步都不能松懈。这也许正是为什么让AI真正胜任严肃的自动化工作，比让它写一篇看起来还不错的文章要难得多。

另一个让我反复琢磨的细节是那个生成顺序实验。先写答案再写判分标准，和先定判分标准再凑答案，看起来只是流程步骤颠倒了一下，结果却是接近两倍的成功率差距。这多少提醒我们，很多系统性问题的根源，可能不在算法本身够不够聪明，而在于最基础的"先做什么后做什么"这种流程设计上。

论文里还有一个没有深入展开的问题，就是这套流程目前依赖的是公开的技能包和场景素材，如果换成某个高度专业化、素材极其稀缺的垂直领域，场景重构这一步还能不能重构出足够丰富的故事？这大概是留给后续研究者的一道真正的考题。

Q&A

Q1：FACET是什么？

A：FACET是中国科学技术大学和上海AI实验室团队提出的一套自动生成终端任务的框架，用来给AI智能体制造训练用的练习题，核心解决的是任务说明、运行环境、参考答案、判分程序四部分互相对不上的问题。

Q2：FACET生成的任务和其他数据集比有什么不同？

A：FACET生成的任务平均每个任务有22.77个独立检查点，远高于同类数据集，虽然导致解题成功率看起来偏低（P@1只有27%），但拿这些任务训练出来的模型在Terminal-Bench 2.1基准上提升明显，27B模型微调后从40.82分提升到47.57分。

Q3：为什么先生成解决方案再生成判分程序比反过来更好？

A：论文实验显示，先写判分程序再写解决方案的方式初始有效率只有24.2%，而先写解决方案再写判分程序的正序方式有效率达到46.5%，因为判分程序如果脱离真实解法凭空设计，很容易和实际解法对不上号。