企业官网建设流程全解析

dz-1093是我的一个项目代号，全称是“智能台球比赛的计分与裁判系统设计”。一句话概括：让摄像头和传感器代替人眼去盯球台，自动记录比分、识别犯规、给出判罚提示。做这个项目的起因很现实，我有段时间常去球房打球，发现业余比赛里最扯皮的就是计分和犯规认定，两边各说各话，一个黑八进门到底算谁赢能吵半天。有专职裁判的正式比赛会好一些，但裁判盯完进球盯击球顺序，三局下来脑子也是高度紧张，漏判在所难免。

所以我才动了念头，想做一套系统，把“球进了哪个袋、进的是哪颗球、母球有没有跟着落袋、该轮到谁出杆、有没有犯规”这些事全部自动化。整套系统做下来，名字虽然长，本质就两个词：计分与裁判。写这篇记录，是把这个项目从需求到架构、从算法到调试的完整过程梳理一遍。如果你正在做台球、桌面冰球这类体育项目的视觉识别，或者想了解怎么把一套比赛规则写进状态机里，这里面有不少实打实踩过的坑，能帮你省掉大量试错时间。

1. 需求拆解：一套“看得懂台球规则”的系统，难点到底在哪里

1.1 台球计分不是数数那么简单

很多人一听“计分系统”就觉得简单，不就数进球吗？真上手做才发现，台球计分难在“规则状态”太复杂。以最常见的8球（黑八）比赛为例，开局后要先看有没有球进、进的是全色还是花色，然后双方各自认领一组球；接下来每次击球，必须先把己方组的球碰进袋，期间母球不能落袋、不能先碰到对方的球、不能打空杆；最后黑八要在己方组球全部清台后才能打，而且黑八落袋的时机如果不对，直接判负。

这还只是8球，9球、斯诺克的逻辑又完全不同。这就意味着系统不能只做一个“进球计数器”，它得理解当前处于哪个比赛阶段，并根据规则判断当前阶段的“合法动作”是什么。这也是我后来把规则引擎放得比识别算法更重要的原因——识别只负责“发生了什么”，规则引擎负责“合不合法”。

1.2 方案选型：视觉为主、传感器为辅，而不是二选一

刚开始规划方案时，我列了三条技术路线：纯摄像头视觉方案、袋口传感器方案、视觉加传感器融合方案。纯视觉的优势是信息量大，球在哪里、进了哪个袋、母球在哪都能看到，但缺点也明显，球面高光、台呢阴影、球与球互相遮挡都会造成误判。纯传感器也有致命伤，袋口传感器只能告诉“某个袋口有球落袋”，但它无法区分进的是全色还是花色、是目标球还是母球，连续两球同一个袋口进就更乱了。

对比下来，我选择了融合方案：摄像头负责“是什么”，传感器负责“是不是”——摄像头看到球进袋，传感器在同一时间窗内产生落袋信号，两个条件都满足才确认进球事件。这套双通道确认机制，实测下来能把袋口附近的误报率压到很低。传感器不用高级货，常见的袋口感应触发块就行，关键是做好信号去抖，避免旁边球桌大力开球震得你这桌也误报。

2. 系统架构：从采集到展示，四个层级各司其职

2.1 四层架构设计

整个系统我划分成四层：采集层、推理层、规则层、展示层。采集层负责视频流和传感器信号接入；推理层跑球体检测模型，输出每颗球的位置、类别和置信度；规则层接收推理层产生的“球进了”“母球落袋了”这类事件，结合当前状态机输出判罚；展示层则是球房里的触摸屏或者裁判用的平板，展示比分、犯规提示和回放录像。

分层的好处是各层可以独立测试、独立替换。我最早用一台性能一般的AI边缘盒子做推理，规则层跑在同一台设备上，后来发现推理占用太高会导致规则层偶发卡顿，就把规则层单独拆成一个轻量进程，通过消息队列通信。这样改动之后，再也没出现过“球都进袋了，界面上还没弹比分”的情况。

2.2 摄像头布局与采集参数

摄像头的安装位置直接决定了后续算法的难度。我测试过两种布局：一种是从球台正上方垂直俯拍，需要用龙门架把相机挂在台面上方；另一种是球台两端各装一个斜向摄像头。俯拍方案里，球的遮挡最少，轮廓最完整，袋口位置也最好判断，但施工麻烦，还要处理顶灯反光。斜向方案安装简单，但球与球的遮挡频繁，靠外侧的球经常因为透视变形而识别不稳。

最终我选了俯拍为主、斜向为辅的搭配：主摄像头做进球检测和球位跟踪，副摄像头只在主摄像头画面不清时提供备选视角。参数上，主摄像头分辨率1920×1080、帧率30fps，镜头焦距选能覆盖整张台面且畸变较小的广角镜头。这里有个容易忽视的细节：一定要关闭摄像头的自动白平衡和自动曝光，球房的灯光环境稳定，自动模式反而会因为台呢颜色抢白平衡，导致球体颜色在比赛过程中漂移，干扰花色识别。

2.3 边缘推理设备与传感信号链路

推理设备选型有两个硬指标：一是能实时跑轻量检测模型，二是至少支持两路视频输入。我用的是一款千元级的AI边缘开发板，配8GB内存，检测模型在FP16精度下单帧推理时间大约40到50毫秒，配合30fps的视频流取10fps做检测，余量充足。选它还有一个原因：接口丰富，USB口接摄像头、GPIO口接传感器扩展板，省掉额外买采集卡的麻烦。

传感器链路我做了统一的事件网关。每个袋口装一个触发式感应块，信号接入开发板的GPIO，程序里用“连续3次采样都为高”作为触发条件，时间戳统一以系统时钟为准。视觉检测到“球疑似入袋”时，会把视觉时间和坐标打包发给规则层；传感器触发的信号也会带着时间戳进来。规则层比较这两者的时间，差值在正负200毫秒以内，才判定为一次有效进球。这个时间窗是实测调出来的，太小会漏掉传感器偶发延迟，太大则容易把前后两次进球混在一起。

3. 算法核心：从“看到球”到“看懂进球”，每一步都是细节

3.1 球体检测与花色分类

模型方面，我用了轻量化的单阶段目标检测网络，输入分辨率640×640，检测类别分四类：母球、全色球、花色球、黑八。很多做台球识别的人会纠结要不要把15颗球按数字区分成15个类别，实际做下来发现，8球比赛的计分逻辑只需要区分花色，不需要区分具体数字，类别拆得太细反而会增加标注成本和误判率。当然，如果你要做9球项目，数字识别就躲不掉了，那需要单独训练。

训练数据是整个识别系统里最耗时的部分。我前后在两种光线环境、四种台呢颜色下采集了四千多张图片，手工标注球体框和类别，标注的时候刻意包括了贴库球、球堆遮挡、强光反射这类难例。训练时给难例加了更高的权重，否则模型学到的全是“干净台面上的球”，实战一上桌就露馅。最终模型在测试集上的mAP大约到了93%，但在实战场合，准确率更重要的参考指标是“漏检率”，漏一颗球可能就导致进球误判。

3.2 进球事件判定：球是“消失”的，不是“进去”的

这是我踩坑最深的一个环节，得单独拎出来讲。球进袋瞬间，视觉上不是一个“球慢慢滚进袋口”的过程——台球进袋非常快，往往一两帧之间球就没了。所以把“进球”当“目标进入袋口区域”来检测，效果极差。

我的做法是双条件判定。第一，以每个袋口中心画一个半径22厘米的圆形ROI，当某颗球连续3帧出现在这个ROI内，标记为“疑似入袋球”；第二，如果下一帧开始这颗球从检测结果中消失，且这段时间窗内传感器有触发信号，就确认进球。如果球只是滚过袋口区域后又滚出来，它会在ROI内存续超过3帧，而且不会消失，系统会把它标记为“擦袋”，不触发进球事件。这里一个小细节：ROI半径不能拍脑袋定，要按实际袋口宽度来。我量了球房几张球台，袋口胶条内沿到外沿大约19厘米，ROI设22厘米留一点余量，太大会把袋口旁边的贴库球误收进来。

3.3 母球落袋与击球顺序判定

母球落袋是判罚里最频繁的事件，误判代价也大。母球是纯白色，球房强光下特别容易过曝，有时球面上会丢纹理，让检测器认不出“这是母球”。我的处理方式是给母球建一条轻量跟踪链：每帧检测到母球后，用卡尔曼滤波预测下一帧位置，即使某帧检测丢失，也能用预测位置补上；只有预测位置和下一帧检测位置都落在袋口ROI内，同时传感器触发，才判定母球入袋，触发“对方自由球”规则。

击球顺序判断比进球更棘手。规则要求“击球后第一个碰到的必须是己方组球”，这在纯视觉上很难高精度判断，因为击球瞬间球与球的接触发生在几毫秒内，30fps的摄像头经常拍不到碰撞那一帧。我用的是间接证据法：击球后0.5秒内，检测所有球的位移方向变化，哪个球最先发生明显变向，就认为它是第一碰撞球。这个判断只能作为提示，不能作为最终判罚，系统会弹出“疑似先碰对方球”的提示，由裁判或球员确认。做工程要承认边界，硬撑全自动反而会让系统失去可信度。

4. 规则引擎：把裁判脑子里的经验，写成看得见的状态机

4.1 用状态机给8球比赛建模

规则层我没用一堆if else硬编，而是按状态机来设计。因为台球比赛本质上是一连串“合法状态转移”的集合，用状态机描述最自然。我定义了四个主状态：开局等待（OPENING）、选组中（CHOOSING）、比赛中（PLAYING）、结束（FINISHED）。每个主状态下，事件到来时检查转移条件，合法则更新比分和球权，非法则生成犯规事件。

举一个具体例子：开局开球后如果有球落袋，系统进入选组状态，根据第一颗落袋球的花色决定当前击球方选全色还是花色；如果开球后母球落袋，则直接生成犯规事件，对方获得线后自由球。这些逻辑用状态转移表管理，比散落的if判断清晰太多，后期加“9球模式”“斯诺克模式”也只是换一张表的事。

4.2 判罚流程：系统先给结论，人来拍板

我把整个系统定位成“辅助裁判”而不是“替代裁判”。所以在流程设计上，所有关键判罚都不是系统一个人说了算。规则引擎生成事件后，系统在界面上弹出一个判罚卡片，显示事件类型、回放时间段、检测置信度，后面跟两个按钮：“确认”和“改判”。球房无人值守模式下，默认等待15秒无人操作则按判罚执行并记录日志；正式比赛模式下，则必须由裁判点击确认才生效。

这套“系统建议+人工复核”的流程，既发挥了自动化的效率，又保留了人的最终裁决权。实际落地时，球房老板对它的接受度特别高，因为没有人愿意被一台机器“当众打脸”，但屏幕上清楚的回放证据出现时，争议双方往往也就没话说了。项目做到这一步我才反应过来：智能裁判系统的核心价值不在于“取代裁判”，而在于“让裁判每一秒都能看清发生了什么”。

5. 现场部署与调参：从实验室到球房的实战记录

5.1 标定流程：把物理球台映射进图像坐标

算法跑在图像坐标里，但规则层需要的是物理坐标。第一步是标定球台四角，用专用标定板在球台四角各放一张，检测角点并映射到台面的物理坐标系；第二步是取袋口坐标，在标定图像上点出六个袋口的圆心位置和半径；第三步是把这些数据固化成本地配置文件，系统每次启动时加载。这个配置非常关键，因为它直接决定进球ROI的画法，我最初用的是光学中心近似，结果袋口坐标偏差几厘米，进球检测率掉了十几个点。

标定还有个容易被忽略的小步骤：测量球的实际直径像素值。摄像头离台面高度不同，球的像素大小也不同。我通过检测一颗已知物理直径的球，反推台面的像素比例，这样后续判断“球是否越过了袋口边缘”就能直接用像素距离换算，不用靠猜。

5.2 光照处理：反光、阴影和频闪，一个都不能留

球房的灯光环境比实验室复杂很多，灯管频闪会让画面亮度周期性跳动，自动曝光如果开着，检测框会在“偏暗”和“正常”之间来回抖。我把曝光模式切到手动，根据球房实际环境固定一个曝光值，再关掉自动白平衡，用固定色温贴近现场。反光问题靠偏振镜解决，在镜头前加装可调偏振镜，调到能压住台呢反光的角度，球体的纹理和号码清晰度明显提升。

阴影问题更隐蔽。球在台呢上会投下投影，开顶灯时投影方向朝下，容易和球体粘连，干扰检测框的边缘。我的做法是在标注训练数据时把常见投影情况都标进去，让模型学习区分“球体”和“阴影”，同时在检测后处理阶段加一个小判断：检测框底部如果出现深绿色区域，按阴影剔除处理。这个方法不能完全解决贴库球的阴影粘连，但已经能显著减少误检。

5.3 延迟优化：事件链路控制在500毫秒内

比赛场景对实时性有明确要求，进球后系统超过1秒才弹比分，体验就崩了。整条事件链路包括：视频帧采集、目标检测、进球判定、规则引擎处理、界面刷新。我实测下来的瓶颈在检测频率，30fps全部跑推理不现实，边缘盒子的算力hold不住。最后的方案是10fps检测帧率，单帧推理50毫秒以内，从进球帧出现到界面弹出比分，实测平均450毫秒，球员和裁判的感知就是“球刚进，屏幕就响了”。

另外我建议把推理线程和UI线程彻底分离。早期版本推理耗时偶尔飙到80毫秒时，UI刷新跟着掉帧，表现为比分弹窗卡顿。后来加了一个事件队列，推理层只往队列里塞事件，UI层订阅队列刷新，两边彻底解耦，问题就消失了。这种架构上的小调整，比单纯堆硬件算力更有性价比。

6. 常见问题速查：计分系统最容易翻车的几个地方

调试点位积累了一些高频问题，整理成表，方便后续维护人员快速定位：

这里再补一条独家经验：系统上线前一定要准备一套“回放归档”能力。比赛的视频流不要直接覆盖写，而是按时间切片存储，保留最近两小时。这个功能看起来不起眼，但在实际评判争议时价值极高——有一次两个球员因为“上一杆犯规之后该谁开球”吵起来，我直接调出5分钟前的录像，把击球时球杆触碰母球的画面放大放慢，争议当场解决。智能裁判系统如果只能给结论、给不出证据，说服力就少了一半。

回到开头说的那个问题，这套系统到底做到了什么程度？它可以在一场8球比赛中自动记录每一次进球、识别大部分犯规，并在关键判罚上给出带回放证据的提示。但我个人的体会是，真正让这个项目跑起来的，不是某个模型有多准，而是我学会了把模糊的规则翻译成确定性的逻辑，用状态机把裁判的经验结构化。这一整套方法，放在台球之外的其他项目上也一样适用。最后再分享一个小技巧：做任何规则型视觉系统，先花一周时间把规则表理清楚，再动摄像头和代码，绝对比边做边改省时间。这个顺序，是我的真实经验。