外围那套编排，比模型本身更决定成败

admin

同一个模型，换个外壳结果差很多

有个朋友做安全自动化，他跟我抱怨说，同一个模型，换个壳子跑同一套检查任务，结果能差一大截，有时连结论都反过来。我一开始不信，直到看到一份基准测试。有机构把八款主流模型放进同一类自动化检查任务里做对比，结论是围绕模型的那套编排，比模型本身聪不聪明更管用。同一块底子，外围不一样，出来的东西完全两样。壳子，真的是门学问。这话我信了。

所谓编排，就是任务怎么拆、每一步给什么输入、结果怎么合并、错了怎么退。同一块模型，你把它直接丢进一个长流程，它可能中途就晕了。你要是把任务切细、每步只喂它该看的东西，它反而稳。这就是外壳的作用。换个壳，效果差很多。拆得顺，模型才使得上劲。

所以选型的时候，先别急着比谁的榜单分高。你要问的是，这套活谁在拆、拆成几步、每一步的可信度怎么验。别只盯着模型。模型是发动机，编排是底盘和变速箱。发动机再好，传动配不上，车照样跑不起来。选型的第一步不是跑分，是把你自己那条流程先摊开看。先看流程，再挑工具。这话听着像老生常谈，但踩过坑的人都懂。

覆盖率和单价，怎么一起看

再看一组数字，很多做方案的人会忽略。测试里覆盖率最高的一款做到七成七，但单次成本明显更贵；一款小一点的模型覆盖率五成二，单次跑下来大约五点四二美元。数字摆在这。你要的是省钱还是省事，得自己掂量。便宜一半、覆盖率少两成，这笔账没有标准答案，得看你手头缺什么。

覆盖率这事不能单看。覆盖七成七，意思是还有两成多的活要人补；覆盖五成二，超过一半得人接手。你算总账的时候，要把人工复核的成本也算进去。省下的那点调用费，可能还不够补人工的时间。反过来，任务量本来就小、容错又高，便宜的那款完全够用，硬上贵的纯属花冤枉钱。别只比单次报价。把三个月的量拿出来，按覆盖率乘一遍，再看人工补的那部分值不值。账得这么算。

还有个容易被忽视的维度，稳定性。有的模型今天跑得挺好，明天同一段输入给你换个说法，你根本不知道哪个算数。自动化最怕这种不确定。所以评估时别只跑一次，同一个任务多跑几遍，看结果稳不稳。稳比聪明更省心。同一件事，今天做对明天做错，比一直做错还折腾。

上下文给得对不对，比参数重要

上下文给得对不对，比参数更要紧。这句话是我看过最多案例之后最想说的。同样一个模型，你把整个文件一股脑塞给它，它容易抓不住重点；你把相关的几十行挑出来、把背景说清楚，它答得又好又快。信息不是越多越好。把无关的东西塞进去，它还要花力气去分辨哪些是噪音，反而拖慢判断。喂什么，比喂多少更讲究。

反过来，给少了也不行。让它判断一个改动安不安全，你不给它这个项目的历史、不给它依赖的关系，它只能瞎猜。所以喂上下文是门手艺，该给的给全，无关的拿掉。这活儿现在很多团队还是人肉在做，短时间内也替代不了。喂得准不准，往往比换哪个模型影响更大。

很多团队迷信参数量，觉得越大越强。实际用起来你会发现，同一个模型，上下文组织得好，效果能上一个台阶；组织得乱，再大也白搭。所以与其纠结参数，不如花时间把喂进去的东西理一理，把无关的删掉，把关键的标出来。这一步看着笨。回报最实在，也最容易被跳过。把料喂对，比把模型换大，见效快。参数是买来的，上下文是人搭的，后者才见功力。

跑到一半不干了，也算故障

自动化里有个特别烦的情况，任务跑到一半，模型突然不干了。它不是说错了，是拒绝继续执行。这在测试里被记下来了，前沿模型偶尔会这样。对流程来说，这跟崩溃没区别，你等着它出结果，它却撂了挑子。这一样算故障。流程不会因为它是善意的拒绝，就停得好看。

为什么会这样，原因挺杂，有时是它觉得这一步不合适，有时就是随机。你没法完全杜绝，但能兜住。做法是给它一个明确的失败出口：卡住了要报错，不能沉默；流程要有超时，不能无限等；关键节点要能人工接管。把这三条写进流程，半路卡壳就不会变成整条任务烂尾。得给它留个出口。出口留好了，值班的人半夜也能一眼看懂停在哪、该找谁。

很多团队评估工具时，只测成功率，不测这种半路撂挑子的比例。真上线了，才发现一堆任务挂在中间。所以你的测试用例里，得有卡住这一类。失败要算进去。能把失败处理干净的方案，才是能进生产的方案。测试的时候顺一遍，上线之后少熬几个夜，这笔投入不亏。

选工具时该问的四个问题

选工具的时候，先别急着看报价。问四个问题就差不多了。第一，任务怎么拆，谁来拆。第二，上下文怎么给，给多少。第三，结果怎么验，谁签字。第四，它半路停了你怎么办。这四个问题分别对应拆分、输入、验收和容错。答不上来的方案，先别急着下单。把这四个问题做成一张清单，每次选型都过一遍，谁也别凭印象拍板。

顺序上，建议先拿一件小活试。挑一件你熟悉、结果好判断、出错了也不致命的活，让整套流程跑一遍。跑完你看看人工补了多少、花了多少钱、省了多少时间。数字比宣传页上的话可靠。先拿小活试。试完再决定要不要铺开，比一上来就签一年合同稳当。

最后说一句，别指望换个模型就能解决问题。这套活的关键，八成在外面那层编排上。把拆解、上下文、验证这三件事先想清楚，剩下的再挑模型，顺序就对。顺序别弄反。反过来先挑模型再想流程，多半要推倒重来，白费功夫。模型迭代快得很，今天的最强过两个月就落伍，可你那条流程能用很久。