`、``、`` 这些语义标签来判断层级和时间。全站用 `` 堆出来的页面，机器只能靠视觉猜。 建议每篇文章：一个页面只有一个 ``，小节用 ``／``，发布时间用 ``。 ## 小结 把这六件事做齐，AI 抓取基本上不会有问题。优先级排序是：**静态渲染 > llms.txt > 结构化数据 > Markdown 镜像 > robots.txt > 语义化标签**。 如果你希望官网改造成对 AI 友好、并且内容更新只需要改 Markdown 文件，可以联系我们聊聊。 ## 人脸识别考勤怎么落地？从摄像头到小程序的完整技术选型 「厂里 300 多人，打卡机代打严重，能不能改成刷脸？」这是我们最近接到最多的一类需求。技术上完全可行，但方案怎么选，直接决定成本、准确率和合规风险。 ## 先明确三个决策点 **第一，人脸数据存在哪。** 这是最关键的一条。如果把员工人脸上传到第三方云平台，涉及个人信息保护合规问题，员工也容易抵触。更稳妥的做法是把人脸库放在企业自己的服务器上，比对在本地完成，只有考勤结果（工号、时间、是否迟到）往外传。 **第二，用哪套人脸模型。** 主流选择是 InsightFace（精度高、模型体积适中）和 dlib（部署简单、资源占用低）。做 1:N 的员工识别，InsightFace 的 ArcFace 系列在国内场景下表现更稳，一般要求底库照片质量过关。 **第三，摄像头能不能用。** 大部分工厂已有海康、大华的 RTSP 摄像头，可以直接复用，不必重新布线。但要注意分辨率——低于 1080P 的枪机在 3 米外抓拍人脸，误识率会明显上升。 ## 完整链路 整条链路是这样的： 1. **取流**：后端通过 RTSP 拉取摄像头视频流（FFmpeg / OpenCV） 2. **转码**：转成 HLS 或 WebRTC，让手机端能实时预览 3. **抓拍**：小程序端预览画面，员工点击抓拍，或后端按帧自动抓拍 4. **检测与对齐**：人脸检测、关键点对齐、质量过滤（模糊/侧脸直接丢弃） 5. **特征比对**：提取 512 维特征向量，在本地底库中做 1:N 检索 6. **业务判定**：命中员工工号 → 记录时间 → 按考勤规则判断迟到/早退 7. **结果输出**：考勤报表、异常提醒、月度统计导出 微信小程序这一层有个实际限制要提前知道：**小程序不能直接播放 RTSP**，必须先由后端转码。另外小程序如果用了云开发，在 Web 端是无法使用 `wx.cloud` 的，需要改成 `app.callFunction()` 调用云函数。 ## 成本大致构成 - **硬件**：复用现有摄像头则接近零成本；新增 1080P 摄像头按需采购 - **服务器**：本地一台带独显或强 CPU 的机器即可支撑几十路比对；纯 CPU 推理需要评估并发 - **软件**：取流转码 + 人脸比对 + 考勤规则 + 小程序前端 + 管理后台 - **合规**：员工知情同意书模板、数据留存期限设定 对比传统打卡机，刷脸考勤的初期投入略高，但省掉了代打漏洞和每月核对工时的隐性成本。以 300 人规模测算，人力核对的效率提升通常在半年内就能覆盖投入。 ## 几个容易踩的坑 **底库照片不规范。** 用员工自拍的侧脸、戴帽子照片入库，识别率必然差。建议现场统一采集，每人 1–3 张正脸照片。 **光照条件。** 厂区门口的逆光会让抓拍质量骤降。要么加装补光灯，要么把摄像头装在内侧顺光位置。 **网络抖动。** RTSP 取流对网络稳定性敏感，建议摄像头与服务器走内网有线，不要跨公网。 **误识率与阈值。** 阈值调太高会「认不出」，调太低会「认错人」。上线初期建议保留人工复核入口，用真实数据调两周再把阈值固化。 --- 如果你正在评估刷脸考勤方案，可以把现场摄像头型号、点位数量和员工规模告诉我们，我们给出具体的可行性与工期判断。