乱 乱花
项目复盘

LabelHub AI：为什么先做 Mock AI，而不是急着接大模型

复盘 LabelHub AI MVP 的真实产品取舍：先用动态表单、三角色工作流和规则驱动 Mock AI 验证标注审核闭环，再决定何时接入真实模型。

5 个标签
LabelHubReactExpressMock AIData Labeling

LabelHub 想验证什么

LabelHub AI MVP 没有试图复刻一个完整的数据标注平台。它抽取的是一条更小、也更容易观察的工作流：

管理员创建任务和表单 Schema
  -> 标注员填写动态表单
  -> 规则驱动 Mock AI 预审
  -> 审核员查看原文、标注结果和风险提示
  -> 人工通过或驳回
  -> Dashboard 更新任务状态

项目真正想验证的是：在人工审核之前增加一个结构化预审层，是否能让任务状态、角色视角和审核信息在同一个原型里连起来。

因此，重点不在“模型有多聪明”，而在这些问题：

  • 任务如何描述不同的标注要求？
  • 标注结果如何进入统一审核流程？
  • AI 建议应该在什么位置出现？
  • 最终判断为什么仍然由审核员完成？
  • 任务状态变化如何反映到工作台和统计中？

这仍然是一个全栈 MVP 原型，不是完整数据标注平台，也没有真实在线 AI 服务。

标注任务、动态表单和审核流程如何衔接

管理员创建任务时提交标题、待标注文本和一个 JSON Schema 数组。每个字段描述名称、标签、类型、选项和是否必填。前端根据字段类型渲染输入控件，当前支持：

  • text
  • textarea
  • select
  • number
  • checkbox

同一套 React 组件可以处理情绪分类、标题质量和内容安全等不同演示任务，不需要为每个任务类型重新写一套固定表单。

任务创建后进入 pending_annotation。标注员提交结果时，后端完成三件事：

  1. 把 annotation 写入任务。
  2. 调用 mockAIReview(annotation) 生成结构化预审结果。
  3. 把任务状态改为 pending_review。

审核员随后在同一界面看到原文、动态表单结果和 Mock AI Review 卡片，再选择 approved 或 rejected。审核结果写回任务后，Dashboard 会重新计算待标注、待审核、已通过、已驳回和风险提示等状态。

这条链路验证的是工作流衔接，而不是模型能力。

为什么第一版选择规则驱动 Mock AI

当前 AI Review 是一个同步 JavaScript 函数。它会把标注值拼接成文本，再执行两类规则：

  • 命中“不确定”“不知道”“违规”等风险关键词时标记为高风险。
  • 存在长度小于 2 个字符的回答时标记为中风险。
  • 其他情况标记为低风险。

函数返回统一结构：

{
  riskLevel,
  confidence,
  possibleIssue,
  suggestion
}

这里的 confidence 是按风险等级写死的演示数值，不是模型概率，也不是经过数据集评测得到的指标。

第一版使用 Mock 的主要价值是控制变量。没有 API Key、网络、余额、模型响应格式和外部服务可用性之后，可以先观察：

  • 预审发生在标注之后、人工审核之前是否合理。
  • 审核员是否能同时理解原文、标注结果和风险建议。
  • 通过与驳回能否正确推动任务状态变化。
  • 前端是否能稳定展示统一的 Review 结构。
  • Dashboard 是否能根据任务状态重新计算。

Mock 让“AI 层的位置和接口”先变得可运行，而不是让模型能力成为整个原型的前置条件。

Mock AI 能验证什么，不能证明什么

Mock 可以验证Mock 不能证明
AI 预审在工作流中的插入位置真实模型能准确判断标注质量
Review 输出结构是否方便前端展示confidence 具有统计意义
风险提示如何交给人工审核规则能覆盖真实业务风险
模型失败时未来需要怎样的回退接口Prompt、模型和数据集已经完成评测
状态流转和 Dashboard 是否连通AI 能替代人工审核

规则输出是确定性的演示结果。它没有训练过程、验证集、准确率、召回率或人工一致性评测，因此不能被描述为真实 AI 效果。

LabelHub AI MVP 的管理员任务工作台
公开截图展示动态任务与工作台界面；AI Review 仍是规则驱动 Mock，不包含真实模型调用或真实业务数据。

为什么不急着接真实模型

把同步 Mock 函数替换成真实大模型，不只是换一个函数名。至少会新增这些不确定性：

  1. Provider 地址、API Key 和模型名称的本地配置。
  2. 异步网络请求、超时、限流和服务不可用。
  3. Prompt 设计与结构化输出解析。
  4. 非法 JSON、字段缺失和模型输出漂移。
  5. 调用成本、延迟和可重复性。
  6. 敏感标注文本是否允许发送到外部服务。
  7. 错误重试、失败回退和日志脱敏。
  8. 不同模型之间如何建立可比较的评测方法。

如果工作流本身还没有验证清楚，真实模型会把“流程不好用”和“模型输出不好”混在一起。此时即使模型返回了看似合理的结果，也无法确认产品是否真的需要这层信息。

更稳妥的顺序是先固定输入、输出和人工决策位置，再用小规模、脱敏、可复现的样本评估真实 Provider。

Demo 角色登录为什么不是真实认证

登录接口只检查角色是否属于 admin、annotator 或 reviewer，然后返回一个 Demo Token 和用户角色。它没有：

  • 密码校验
  • Token 签名或服务端会话
  • API 鉴权中间件
  • 权限校验
  • Token 过期与撤销
  • 注册、找回密码或账号管理

前端根据当前角色显示不同工作台，但后端接口没有以真实身份阻止越权调用。任何能直接访问 API 的调用方都不受前端角色界面限制。

所以 Demo 登录只能用于演示三种视角，不具备真实安全性，也不能作为认证或授权方案。

JSON 文件存储的适用边界

数据访问集中在 dataStore.js。后端首次读取时会确保 backend/data/tasks.json 存在；如果不存在，就从源码中的三条虚构 seed 任务生成。后续创建、标注和审核操作会读取整个数组、修改任务，再把完整 JSON 写回文件。

这种方案适合单机演示：

  • 不需要额外数据库服务。
  • 数据结构可以直接观察。
  • 项目启动成本较低。
  • 数据读写集中在一个模块，后续更换存储层有明确入口。

但 JSON 存储不适合生产环境：

  • 没有事务。
  • 没有并发写入控制和任务锁。
  • 没有索引、查询优化和数据约束。
  • 没有迁移、备份和恢复策略。
  • 整文件重写可能在异常中断时损坏数据。
  • 无法可靠支撑多人同时标注和审核。

“以后可以换数据库”只说明代码有一个集中入口，不代表迁移已经完成或不需要重新设计数据模型。

本轮整理如何处理本地任务数据

整理前，backend/data/tasks.json 是被 Git 跟踪的运行时文件。检查确认它包含三条虚构演示记录，与 dataStore.js 内置 seed 一致，没有发现真实身份信息或密钥。

问题在于：正常创建任务、提交标注或完成审核都会重写这个文件。如果继续跟踪，任何演示操作都可能让仓库产生未提交修改，也容易把后续本地任务内容带进提交。

本轮整理采取了这些处理：

  • 将 backend/data/tasks.json 从当前 Git 跟踪中移除。
  • 保留本地文件，不删除已有演示状态。
  • 在根 .gitignore 中忽略运行时任务文件。
  • 在后端 .dockerignore 中排除任务数据。
  • 后端 Dockerfile 不再把运行时 data 目录复制进镜像。
  • Docker Compose 继续挂载本地 data 目录，用于容器重启后的本地持久化。

该路径仍然存在于早期 Git 历史中，但已检查的历史和当前内容都是虚构 seed 数据，没有形成敏感信息阻断。后续本地任务数据仍应只保留在本机。

构建与 Docker 验证情况

仓库整理阶段实际完成了：

  • 后端和前端锁文件一致性检查。
  • 后端 server.js、dataStore.js 和 mockAIReview.js 的语法检查。
  • 前端生产构建，Vite 转换了 31 个模块并生成静态资源。
  • docker compose config 配置解析。
  • README、截图、文档路径和 Git diff 检查。

Docker Compose 配置能够解析，但本机 Docker Desktop Linux daemon 当时没有运行，因此 docker compose build 未完成，前后端 Docker 镜像没有被实际构建验证。

这意味着项目有 Dockerfile 和 Compose 配置，也通过了静态配置检查，但不能把它写成“容器镜像已经验证可用”。

没有自动化测试意味着什么

后端和前端的 package.json 都没有 test 脚本。本轮没有为了整理仓库临时引入测试框架，也没有编造测试结果。

语法检查和前端构建可以发现语法、类型转换和打包问题，但不能证明这些行为始终正确：

  • 任务状态是否只能按合法顺序变化。
  • Schema 是否正确处理所有字段类型和必填规则。
  • Mock AI 规则是否覆盖边界输入。
  • 驳回后的任务是否能安全重新标注。
  • JSON 写入失败时是否会保留原数据。
  • Dashboard 统计是否在所有状态组合下正确。
  • 不同角色是否真的受到后端权限限制。

当前项目适合展示流程原型，但缺少回归保护。下一轮工程改进应先为核心状态流转、Mock 规则和数据读写增加基础测试。

从 Demo 走向真实产品还缺什么

除了接入模型，还需要补齐更基础的产品和工程能力：

  1. 真实用户、认证和后端授权。
  2. 数据库事务、约束、迁移和备份。
  3. 任务分配、领取、锁定和并发冲突处理。
  4. 标注、预审、人工审核的完整历史和审计日志。
  5. Schema 版本、数据校验和任务模板管理。
  6. 批量导入导出、错误恢复和失败任务处理。
  7. 标注质量规则、抽检策略和多人一致性机制。
  8. AI Provider 配置、超时、回退、成本控制和日志脱敏。
  9. 真实模型评测集、人工基线和可解释的指标。
  10. 自动化测试、CI、监控和部署验证。

这些能力决定了系统能否安全地支持多人和真实数据。真实模型只是其中一层，不能替代认证、数据治理和流程控制。

下一步：先验证用户流程，还是先接真实模型

当前更合理的顺序是先验证工作流，再接真实模型。

可以先用 Mock 和虚构数据完成这些检查：

  1. 明确管理员创建任务时真正需要哪些 Schema 字段。
  2. 验证标注员填写、修改和重新提交是否顺畅。
  3. 确认审核员需要哪些上下文，哪些风险提示真正有帮助。
  4. 固定任务状态机和驳回后的返回路径。
  5. 为核心流程补自动化测试。
  6. 将 JSON 存储迁移到具备事务能力的数据层。
  7. 补真实认证和后端权限控制。

当输入结构、审核界面和人工决策标准稳定后，再选择一组脱敏样本接入单个 Provider，对比 Mock、人工判断和模型输出。这样才能判断真实模型增加了什么价值，而不是只证明 API 可以返回文本。

项目详情和源码可以从项目作品页继续查看。

Related Project

LabelHub AI MVP

用动态表单、角色工作流和规则驱动 Mock AI Review 演示标注审核闭环

返回项目页 全部笔记