# Open WebUI 多模型对话：并排生成参观FAQ，合并时核对分歧与未知信息 本次实际运行：Python标准库参考程序、业务边界检查与HTML渲染。未安装或运行Open WebUI，未调用模型、创建真实自动化、发送消息、建第三方PR或部署。人工基准和错误样稿均明确标注。 ## 文件 input.json：原创输入；node-fields.json：字段教材，不能直接当平台导出文件导入；prompt.md：任务约束；schema.json：规范化观察结构；reference.py：本站手写参考；reference-output.json：实际本地输出；reference.html：参考产物；review-template.json：读者填写目标工具结果。 ## 本地运行 ```bash python3 reference.py python3 verify.py ``` 用浏览器打开reference.html。不依赖模型或第三方账户。 ## 真实平台步骤 1. 固定六条参观事实与未知格 brief.json只有开放时间、闭馆日、20人上限和迟到规则；票价与无障碍入口未提供。facts-manual.json是人工金标，不能把其中人工错误样稿当模型实测。 2. 在Compare Mode选择两个模型 Open WebUI模型选择器点击Compare，选两个实际可访问的model ID；先各自测试短请求。若没有Compare，检查Allow Multiple Models in Chat用户权限。 3. 同一提问生成两列原稿 提交prompt.md，两个模型收到同一brief和六个问题。等待各自完成，展开确认错误/失败状态；任一失败就记录失败，不用人工补稿假装两列都成功。 4. 先记录差异再做原生合并 把两列答复按F01–F06填comparison-template.csv，特别查票价与入口。原始答复保留；一致也不保证正确，不先把错误删掉再声称模型没有分歧。 5. 点击当前答复的Merge Responses 最后一轮且所有模型结束后，点击右侧分支形合并图标。合并使用当前查看答复对应的模型，不读取Task Model；模板内置，没有正文可虚构的管理员自定义合并字段。 6. 逐条审校合并FAQ 用人工事实清单核对合并稿。reference.html渲染的是人工构造的错误样稿/合并基准与事实差异表，并非Open WebUI UI、真实模型答复或原生Merged Response。实际稿若把未知补成免费必须纠正并留证。 7. 重开聊天并归档原稿与费用 回到聊天确认两份原稿和合并稿仍在，保存实际模型ID、三类主要请求及重试费用。导出审校版和差异表；一次固定brief不用于发布模型排行榜。 ## 版本与许可 Open WebUI0.12.2；需Allow Multiple Models in Chat权限，两个模型都可访问并各自单独跑通。两份生成和一次合并至少有三次主要推理请求，实际额外请求/重试以日志与账单为准，不声称只收费一次或必然更准确。原提问可要求保留未知，但内置合并不保证事实正确；最终逐条人审。无需GPU、本地权重或外部搜索服务，远端模型API费用独立；保留Open WebUI品牌许可。 ## 来源 - https://docs.openwebui.com/features/chat-conversations/chat-features/multi-model-chats/ - https://docs.openwebui.com/features/workspace/models/ - https://github.com/open-webui/open-webui/releases/tag/v0.12.2 ## 验收边界 提供原创“青屿科普馆”说明，明确开放日、预约人数上限和迟到处理，门票价格与无障碍入口位置故意未给；同一原始提问通过Compare Mode发给两个模型，各生成6条访客FAQ。保留两列原答复，全部结束后使用Merge Responses生成合并稿，再对照人工事实清单形成6行差异表（原文依据、模型A、模型B、合并稿、人工结论）。最终交两份原答复、合并FAQ和差异表；验收日期/人数规则一致、未知不变已知、不同意见可定位，任一模型失败不伪称双模型完成，重新打开聊天后仍能找到原稿与合并稿。不做真实景点推荐。 目标产品实跑时保存原生输出，不得把本包人工/手写参考改名冒充模型返回。所有人物、订单与规则均为虚构练习数据。 渲染说明：input.html、operation.html、reference.html和figures是随当前原创输入冻结的实际浏览器预览；修改输入后重新运行会更新reference-output.json，静态HTML不会自动重绘。目标软件原生结果请另存。