企业级 RAG 工作台
独立项目 · RAG 产品与验收设计
为企业问答保留出处、低置信拒答和反馈回收，把可重复验收与尚未通过的语义诊断分开管理。
已附报告摘要与源码核验清单；mock 结果不代表真实模型效果或线上运营。
◆
Three screens
三块界面，三条能力主线
点进任意一张，看完整界面与它背后的设计判断。
以下为依据项目描述重建的设计稿，不是运行截图。示例人物、问答、相关性分数与任务状态用于说明交互；项目测试数字另列口径，原始材料未随本副本交付。
Z1Space
双人协作 · 产品机制与接口方案；队友负责实现
Agent 负责理解与发现，关系由真人确认——Agent 之间每句事实陈述必须挂证据，且只能引用自己那一侧。
双人分工与源码边界已核对；无真实用户反馈、推荐效果或线上灰度结论。
How I design
界面不是装饰，是规则的可见化
先定状态，再画控件
每个界面先枚举状态（空 / 加载 / 边界 / 失败 / 冲突），再决定用什么控件承载。控件的优先级永远低于状态。
Z1Space 的 pending 态因此不能发消息
把不确定性摆到台面上
置信度、证据强度、来源出处都直接显示在界面上，而不是藏在后端日志里——用户要能自己判断这条答案值不值得信。
RAG 的低置信度拒答因此是界面一等状态
越权要在界面层就堵住
能点的按钮集合由状态机推导，而不是靠禁用某个按钮来补救。决定与副作用分离，未确认的状态根本没有入口。
三个界面都遵循这条
数字必须和界面同源
项目测试数字引用统一的站内记录与口径；界面中的示例分数、人物和任务状态明确标为示意，不当作测试结果。
口径写在同一页，方便核对