拓冰网站定制 
我们的故事俗话说得好一个成功的项目离不开一个优秀的团队(bushi)。我们彼此相识于Datawhale开源社区其中每个人的领域还都不一样有做前后端开发的有做视觉的有做大模型算法的还有做多模态的可谓是好像什么都会一点。在比赛开始的第一天队长就拉着我们热火朝天的开了一场选题大会。最初的4个主题分别是博客生成skill先说一嘴队长的博客非常之震撼欢迎大家来瞅瞅Echo Lin · 全栈开发 · AI 应用、法律材料整理skill、流量监控skill以及今年一直都非常火爆的短剧生成skill还有“抢风口”的RSI skill。后来我们把目光投向最近全民热议的理念——FDE前端部署工程师主要旨在现场解决问题这就由此延伸出了一个新的目标我们能不能通过一个skill解决工业场景中出现的零件安装流程不规范的情况FlowGuard AI由此诞生。我们怎样把一段装配视频变成一条可追溯的质量记录FlowGuard 的起点落在一段四十秒的装配视频上工人扫了零件码装上端盖拿扳手锁紧最后贴好标签。画面看起来很完整要紧的那一步却可能没有发生。泵体槽位里少了一只密封圈产品到了使用现场才开始渗漏。整个产品的构想就是从这个很窄的问题开始的。我们没有把目标写成理解工厂视频也没有试图覆盖整条生产线。项目只处理固定装配工位、明确产品、已发布 SOP 和预录视频。系统先判断规定动作是否出现、执行顺序是否正确。画面不足以支持判断时它还要明确说明证据不够。如果发现问题工单怎样进入人工确认、返工、复核和归档也属于开发范围。先把一条质量问题走到底早期设计里我们选了泵体端盖装配作为主演示场景。操作员先扫描泵体二维码再安装绿色密封圈随后放置端盖并锁紧最后贴上质检标签。这套流程里有三种结果。正常视频应该完整走完步骤系统放行工单。漏装视频缺少密封圈步骤系统生成异常等待班组长确认。遮挡视频里手或工具箱挡住了槽位模型无法看清密封圈有没有放进去这时系统只提出复核请求。第三种结果很关键。证据不够时仍然给出肯定结论会给工业质量系统带来更大的风险。FlowGuard 把“流程违规”和“证据不足”分成两个状态。低置信度、画面遮挡、缺少关键帧或时间区间时工单进入人工复核。系统不会根据一段模糊画面认定操作员漏装更不会自动处罚任何人。有了这三段视频后面的产品和代码都能围绕一条完整路径展开。上传并发布 SOP创建工单上传视频生成步骤时间线处理异常派发返工再用返工视频复核最后生成报告。我们没有先堆十种识别能力因为一次识别还不能完成后续的质量处理。SOP 必须先变成系统能执行的规则操作手册通常是 PDF 或 DOCX里面有人能看懂的步骤、工具要求和异常处理程序却不能直接拿这些自然语言控制工单状态。FlowGuard 先把手册解析成候选步骤。每一步都有顺序、是否必需、前置条件、证据要求、缺失后的处理方式还保留原文页码和引用。工艺工程师可以修改这些内容再依次提交审核、批准和发布。系统只允许已发布的 SOP 参与正式检测。工单一旦开始检测就固定绑定当时的 SOP 版本。以后发布新版本也不会改变历史工单的判断依据。保留人工审核模型可以帮助提取但是后续步骤必须要有工程师确认。某个步骤能不能跳过缺失后要不要阻断视频中应该看见什么这些决定不能交给模型自行补全。模型负责观察规则负责作决定真实推理通过相同接口接入。目前有 Step 5 和 DeepStream 两条路径。Step 5 路径用 FFmpeg 抽取 JPEG 帧把图片写入 RustFS再将带有效期的访问地址发给视觉模型。DeepStream 路径调用官方推理服务并保留分块信息。两条路径最后都返回统一的步骤观察结果。统一接口解决了一个容易被忽略的问题。模型输出会变业务规则不能跟着某家模型的响应格式一起晃动。FlowGuard 的核心层只关心步骤编号、是否观察到、置信度、起止时间、关键帧、遮挡状态和证据说明。具体模型放在基础设施层切换供应方时工单流程不需要重写。模型给出观察以后执行图才开始判断。它把观察到的事件与 SOP 步骤对应起来检查缺失、错序、重复和证据完整性最后给出通过、违规或证据不足三种决定。模型回答“看见了什么”系统规则回答“这对当前工单意味着什么”。这条边界也让错误更容易追查。异常出现以后系统还要继续工作很多视频分析演示停在一张结果页。模型画出时间线标一个红色警告演示就结束了。现场的质量工作还要继续。FlowGuard 会把异常交给人处理。班组长可以确认异常也可以根据证据驳回。异常确认后系统创建返工任务记录负责人和操作要求。操作员提交返工视频系统仍按原来的 SOP 检查。复核通过以后工单才能放行。复核失败任务回到返工状态。每次状态变化都进入审计记录。报告从数据库里的事实生成包含 SOP 版本、原始视频与返工视频的哈希、模型和提示词版本、逐步发现、人工决定及返工结果。PDF 生成后还会保存 SHA256。报告内容不交给语言模型自由发挥关键字段来自结构化记录。这种做法显得有些笨却很适合质量场景。几个月后有人问起某张工单系统能够说明当时使用哪版 SOP模型看见了哪些动作谁确认了异常返工视频是哪一份最终报告有没有被改过。工程结构围绕替换和追溯展开后端使用 FastAPI、SQLAlchemy 和 Alembic。PostgreSQL 保存业务数据RustFS 提供兼容 S3 的对象存储。前端使用 React 和 TypeScript。Docker Compose 把 API、Web、数据库和对象存储放进同一套本地环境。后端代码按依赖方向拆开。core 定义推理和存储契约infrastructure 放数据库、RustFS 和模型适配器services 编排业务规则routes 处理 HTTP 请求。这个分层没有追求形式上的漂亮它主要解决两件事。第一Mock、Step 5 和 DeepStream 可以替换。第二业务判断能够独立测试不必每次都启动外部模型。我们为数据库建立了多轮迁移逐步加入视频审计、异常返工、归档报告和证据追踪。自动化测试覆盖 SOP、工单状态、执行图、视频审计、异常流程、报告和统一错误处理。本地验收会检查后端测试、代码规范、前端构建和集成冒烟流程。目前做到哪里FlowGuard 已经具备一条完整的业务路径。SOP 可以提取、审核和发布工作单可以上传视频并执行审计异常可以确认、返工和复核报告可以生成 JSON 和 PDF。项目也准备了 Mock、Step 5 和 DeepStream 三种推理适配方式。它仍是一套面向受控场景的早期系统。默认 Mock 模式靠文件名生成确定结果只适合开发和演示。真实推理需要 FFmpeg、RustFS、模型服务和对应密钥。摄像头可以帮助确认有没有使用扭矩扳手却不能从普通画面可靠读出真实扭矩。系统也不控制 PLC不识别人脸不替代最终安全认证。这些边界写进 README也进入了产品和代码设计。我们希望系统在证据不足时停下来把决定交回给人。对质量审计来说知道什么时候不能下结论本身就是一项能力。SOP 版本、证据记录、人工决定和返工状态把线索接入生产流程最后那份可以追溯的报告则把整个处理过程固定下来。 FlowGuard AI与我们的故事
我们的故事俗话说得好一个成功的项目离不开一个优秀的团队(bushi)。我们彼此相识于Datawhale开源社区其中每个人的领域还都不一样有做前后端开发的有做视觉的有做大模型算法的还有做多模态的可谓是好像什么都会一点。在比赛开始的第一天队长就拉着我们热火朝天的开了一场选题大会。最初的4个主题分别是博客生成skill先说一嘴队长的博客非常之震撼欢迎大家来瞅瞅Echo Lin · 全栈开发 · AI 应用、法律材料整理skill、流量监控skill以及今年一直都非常火爆的短剧生成skill还有“抢风口”的RSI skill。后来我们把目光投向最近全民热议的理念——FDE前端部署工程师主要旨在现场解决问题这就由此延伸出了一个新的目标我们能不能通过一个skill解决工业场景中出现的零件安装流程不规范的情况FlowGuard AI由此诞生。我们怎样把一段装配视频变成一条可追溯的质量记录FlowGuard 的起点落在一段四十秒的装配视频上工人扫了零件码装上端盖拿扳手锁紧最后贴好标签。画面看起来很完整要紧的那一步却可能没有发生。泵体槽位里少了一只密封圈产品到了使用现场才开始渗漏。整个产品的构想就是从这个很窄的问题开始的。我们没有把目标写成理解工厂视频也没有试图覆盖整条生产线。项目只处理固定装配工位、明确产品、已发布 SOP 和预录视频。系统先判断规定动作是否出现、执行顺序是否正确。画面不足以支持判断时它还要明确说明证据不够。如果发现问题工单怎样进入人工确认、返工、复核和归档也属于开发范围。先把一条质量问题走到底早期设计里我们选了泵体端盖装配作为主演示场景。操作员先扫描泵体二维码再安装绿色密封圈随后放置端盖并锁紧最后贴上质检标签。这套流程里有三种结果。正常视频应该完整走完步骤系统放行工单。漏装视频缺少密封圈步骤系统生成异常等待班组长确认。遮挡视频里手或工具箱挡住了槽位模型无法看清密封圈有没有放进去这时系统只提出复核请求。第三种结果很关键。证据不够时仍然给出肯定结论会给工业质量系统带来更大的风险。FlowGuard 把“流程违规”和“证据不足”分成两个状态。低置信度、画面遮挡、缺少关键帧或时间区间时工单进入人工复核。系统不会根据一段模糊画面认定操作员漏装更不会自动处罚任何人。有了这三段视频后面的产品和代码都能围绕一条完整路径展开。上传并发布 SOP创建工单上传视频生成步骤时间线处理异常派发返工再用返工视频复核最后生成报告。我们没有先堆十种识别能力因为一次识别还不能完成后续的质量处理。SOP 必须先变成系统能执行的规则操作手册通常是 PDF 或 DOCX里面有人能看懂的步骤、工具要求和异常处理程序却不能直接拿这些自然语言控制工单状态。FlowGuard 先把手册解析成候选步骤。每一步都有顺序、是否必需、前置条件、证据要求、缺失后的处理方式还保留原文页码和引用。工艺工程师可以修改这些内容再依次提交审核、批准和发布。系统只允许已发布的 SOP 参与正式检测。工单一旦开始检测就固定绑定当时的 SOP 版本。以后发布新版本也不会改变历史工单的判断依据。保留人工审核模型可以帮助提取但是后续步骤必须要有工程师确认。某个步骤能不能跳过缺失后要不要阻断视频中应该看见什么这些决定不能交给模型自行补全。模型负责观察规则负责作决定真实推理通过相同接口接入。目前有 Step 5 和 DeepStream 两条路径。Step 5 路径用 FFmpeg 抽取 JPEG 帧把图片写入 RustFS再将带有效期的访问地址发给视觉模型。DeepStream 路径调用官方推理服务并保留分块信息。两条路径最后都返回统一的步骤观察结果。统一接口解决了一个容易被忽略的问题。模型输出会变业务规则不能跟着某家模型的响应格式一起晃动。FlowGuard 的核心层只关心步骤编号、是否观察到、置信度、起止时间、关键帧、遮挡状态和证据说明。具体模型放在基础设施层切换供应方时工单流程不需要重写。模型给出观察以后执行图才开始判断。它把观察到的事件与 SOP 步骤对应起来检查缺失、错序、重复和证据完整性最后给出通过、违规或证据不足三种决定。模型回答“看见了什么”系统规则回答“这对当前工单意味着什么”。这条边界也让错误更容易追查。异常出现以后系统还要继续工作很多视频分析演示停在一张结果页。模型画出时间线标一个红色警告演示就结束了。现场的质量工作还要继续。FlowGuard 会把异常交给人处理。班组长可以确认异常也可以根据证据驳回。异常确认后系统创建返工任务记录负责人和操作要求。操作员提交返工视频系统仍按原来的 SOP 检查。复核通过以后工单才能放行。复核失败任务回到返工状态。每次状态变化都进入审计记录。报告从数据库里的事实生成包含 SOP 版本、原始视频与返工视频的哈希、模型和提示词版本、逐步发现、人工决定及返工结果。PDF 生成后还会保存 SHA256。报告内容不交给语言模型自由发挥关键字段来自结构化记录。这种做法显得有些笨却很适合质量场景。几个月后有人问起某张工单系统能够说明当时使用哪版 SOP模型看见了哪些动作谁确认了异常返工视频是哪一份最终报告有没有被改过。工程结构围绕替换和追溯展开后端使用 FastAPI、SQLAlchemy 和 Alembic。PostgreSQL 保存业务数据RustFS 提供兼容 S3 的对象存储。前端使用 React 和 TypeScript。Docker Compose 把 API、Web、数据库和对象存储放进同一套本地环境。后端代码按依赖方向拆开。core 定义推理和存储契约infrastructure 放数据库、RustFS 和模型适配器services 编排业务规则routes 处理 HTTP 请求。这个分层没有追求形式上的漂亮它主要解决两件事。第一Mock、Step 5 和 DeepStream 可以替换。第二业务判断能够独立测试不必每次都启动外部模型。我们为数据库建立了多轮迁移逐步加入视频审计、异常返工、归档报告和证据追踪。自动化测试覆盖 SOP、工单状态、执行图、视频审计、异常流程、报告和统一错误处理。本地验收会检查后端测试、代码规范、前端构建和集成冒烟流程。目前做到哪里FlowGuard 已经具备一条完整的业务路径。SOP 可以提取、审核和发布工作单可以上传视频并执行审计异常可以确认、返工和复核报告可以生成 JSON 和 PDF。项目也准备了 Mock、Step 5 和 DeepStream 三种推理适配方式。它仍是一套面向受控场景的早期系统。默认 Mock 模式靠文件名生成确定结果只适合开发和演示。真实推理需要 FFmpeg、RustFS、模型服务和对应密钥。摄像头可以帮助确认有没有使用扭矩扳手却不能从普通画面可靠读出真实扭矩。系统也不控制 PLC不识别人脸不替代最终安全认证。这些边界写进 README也进入了产品和代码设计。我们希望系统在证据不足时停下来把决定交回给人。对质量审计来说知道什么时候不能下结论本身就是一项能力。SOP 版本、证据记录、人工决定和返工状态把线索接入生产流程最后那份可以追溯的报告则把整个处理过程固定下来。