Automate AI Car Copilot
视觉代号 · 星舱协议
把座舱问答、意图理解、场景 Agent、反馈与安全规则放进一个 Mock 原型。
项目定位、用户问题与产品目标
基于 Python 与 Streamlit 的智能座舱 AI Copilot 原型；所有车辆控制均为 Mock，不连接真实车辆。
目标用户与使用场景
需要验证智能座舱 Copilot 产品流程、评测方法和安全边界的产品团队。
用户问题
座舱请求同时涉及知识、车辆状态、控制意图和安全风险，单轮聊天难以表达完整产品闭环。
为什么需要 AI
自然语言请求需要被解析成结构化意图，并结合知识、状态和安全规则决定回答、确认或拒绝。
产品目标
在不连接真实车辆的前提下，验证知识问答、意图解析、场景编排和安全确认。
我的职责
- 01
拆解座舱问答、意图理解和场景执行流程
- 02
定义车辆状态、指令参数与反馈结构
- 03
设计测试集、Judge 维度和安全分级
- 04
通过 Mock 控制验证人机确认与拒绝路径
产品方案与技术工作流
在 Streamlit Mock 原型中依次读取车辆状态、解析八字段意图、调用 RAG 或场景 Agent，再由三级安全规则决定直接响应、二次确认或拒绝。
- 01接收用户请求
- 02读取 Mock 车辆状态
- 03解析结构化意图
- 04检索座舱知识
- 05执行安全分级
- 06确认或模拟执行
- 07记录反馈与评测
Prompt、RAG 与 Agent 技术方案
- 八字段结构化意图用于承接动作、对象、参数与上下文
- 四类场景 Agent 组织不同座舱任务
- RAG 回答返回本地知识证据
- 五维 LLM-as-Judge 用于辅助评测，不替代人工安全判断
人工确认节点
测试方法与 Evaluation focus
以下内容是项目中记录或计划观察的评测维度，用于指导验证与迭代，不代表已经取得对应结果。
意图解析正确性
回答相关性
场景完成度
安全规则符合度
回复清晰度
失败案例、边界与风险
所有车辆控制仅为 Mock；三级规则决定直接响应、二次确认或拒绝；不得用于真实驾驶控制
失败类型
- 把自然语言直接映射为控制
- 忽略当前车辆状态
- 模型回答越过安全规则
异常与边缘场景
- 车辆状态不允许操作
- 意图字段缺失
- 知识库没有依据
- 用户连续修改指令
迭代记录
知识问答、座舱控制和评测容易被拆成互不连通的 Demo。
- 分析
- 需要一个共同状态和清晰的安全决策顺序。
- 改动
- 仓库将 RAG、意图解析、四类 Agent、反馈池和 Judge 评测整合到 Streamlit。
- 结果
- 当前公开仓库提供完整 Mock 流程；车辆状态与控制均为模拟。
- 下一步
- 继续扩展异常状态和人工安全复核样本。
产品思考与下一步
智能座舱 AI 的产品价值不仅是听懂指令，更在于知道什么时候必须确认或拒绝。
- 扩展异常车辆状态
- 复核安全规则覆盖
- 区分模型错误与规则错误
仓库事实
公开仓库包含 RAG 座舱问答、八字段意图解析、四类场景 Agent、由反馈整理的需求池、十八题测试集、五维 LLM-as-Judge 和三级安全规则。
这些内容用于验证产品流程和评测结构。页面不宣称项目已经接入真实车辆，也不把测试集规模当作业务指标。
基于 Python 与 Streamlit 的智能座舱 AI Copilot 原型；所有车辆控制均为 Mock，不连接真实车辆。
↗界面与过程证据
真实项目截图尚未写入本地。页面先使用原创概念封面保持完整体验，待补充文件已记录在资源清单。