同一句提示词，几个模型并排答：Foundry Toolkit 的比较视图值得用

为一个功能选模型时，最容易发生的偏差是：这个模型问一句，那个模型又换了个说法，最后凭印象比较。Foundry Toolkit的聊天比较视图可以把同一条输入发给多个已配置模型，让回答并排出现，再看差异具体落在哪里。

熟悉旧名称的读者需要留意：AI Toolkit for VS Code已经更名为Foundry Toolkit。它仍是一款VS Code扩展，但不能因为反馈仓库公开，就把扩展实现称为开源。

比较视图怎样减少来回复制

官方Playground说明给出操作关系：打开Compare，为每个面板选择一个已配置模型；在任意面板输入提示词，文字会同步到其他面板，发送后再查看不同回答。

有一个细节很重要：输入提示可以镜像，system prompt和推理参数仍分别属于各自模型。某个模型没有相同参数，或参数含义不同，就不能把表面上填了相近数值当作完全一致的实验条件。切换所选模型，还会重置比较视图中的对话。

因此，这个视图适合快速观察同一个任务：哪条回答漏掉了要求，哪条输出更便于交给后续程序，哪些说法需要补来源。它减少的是重复操作和记忆负担，不会自动替你决定谁是总体最好的模型。

Playground会按模型与服务展示输入和参数能力。官方说明区分了模型原生能力与Toolkit辅助选项，“使用全部AI功能”也不会给一个不支持图片的模型凭空添加视觉理解。

这会影响比较方式。如果任务需要看图，就要先确认每个面板的模型和服务都接受相应输入；如果任务只是处理文字，最好保持材料范围相同。否则，一边实际收到图片，另一边只得到提取文字，差异可能来自输入路径，而不只是模型本身。

本地模型与远程端点也应分清。扩展在电脑上运行，不代表请求一定留在电脑里。远程模型会接收输入，并按服务条件消耗额度或产生费用；比较多个远程模型时，每个请求都可能分别计费。

概览文档将交互测试、数据集评估和追踪区分开来。比较视图适合看具体行为；若需要重复比较一批任务，则应进入Evaluation，而不是用一条提示得出正式排名。

确定一个候选后，可以通过View Code打开模型客户端样例。它提供接入起点，不会把当前完整聊天记录自动导出成应用，也不会替你部署服务。代码里的输入、认证、错误处理仍需要放回实际项目里整理。

对于已经在VS Code里开发的人，最实用的起步方式是挑一条真实任务，保留相同材料与要求，再并排查看回答。结果若能帮你指出一个具体遗漏或输出差异，这一轮比较就已经比“印象里哪个更聪明”更有参考价值。