CVAT Task 命名規則 v2 · ISMS 鏡頭主軸（乾淨版）

<廠商>_[<ISMS鏡頭名稱>]_<YYYYMMDD>_<NNN>

解析 regex

^(?P<vendor>[A-Z]+(?:-AI)?)_\[(?P<cam>.*?)\]_(?P<date>\d{8}|UNKNOWN)_(?P<seq>\d{3})$

適用範圍：所有新建 CVAT task 一律套用本 4 段格式。下游 cvat-reports / reports_maker fetch 階段以上方右錨點 + 括號分隔 regex 解欄位。過渡期須同時相容舊 5 段格式（task 名含 '[' → 新 regex，否則 → 舊 <VENDOR>_<SITE>_<CHxx>_<DATE>_<NNN> regex）。

Train / Val / Test 拆分

• 不進 task 名 → 走 CVAT 既有 subset 欄位（合法取值見第 5 節，v2.4 起封閉列舉）
• 若刻意拆成 3 個獨立 task 作為三套資料集 → 用編號 001 / 002 / 003 區分
• 不要把 _Train / _Val / _Test 當後綴加在名後（舊格式）
• 同支影片不可重複抽幀，避免資料汙染
• 廢批 / 不可用批次同樣不進 task 名 → subset 設 Rejected（第 5 節）；不要加 _REJECT 之類的名稱後綴

新格式的核心。鏡頭名稱直接取 ISMS cameraCode 原樣、用方括號框住，因此不需要任何每廠商的場域/鏡頭對照表。

• 一律用方括號 [] 框住，例 [jujia_A1]。
• 內容 = ISMS cameraCode 原樣，不做正規化、不轉拼音、不補零。底線 / 連字號 / 中文都允許。
• 唯一禁止字元：右括號 ]（會破壞解析）。若 ISMS 名稱含 ]（目前未見），需個案處理。
• 取 cameraCode（穩定機器 ID），不取可變的中文顯示名。
• 無 ISMS 鏡頭實體的來源 → 改填來源 tag（見下表），不要硬湊或造鏡頭名。

無 ISMS 來源 → 來源 tag

舊格式把『場域 + 鏡頭 CH』寫進 task 名，因此要維護每廠商的對照表。新格式只在 task 名保留『廠商 + ISMS 鏡頭 ID』當外鍵，其餘 metadata 在 ISMS。

• task 名 = 指向 ISMS 鏡頭的外鍵（廠商 + cameraCode）。
• 場域 / 樓層 / 位置 / production model 等 metadata 全在 ISMS，報表階段以 cameraCode join 取回。
• cams_v1 報表的 isms_to_cvat_key() 已是此模式（ISMS↔CVAT join）。
• 好處：單一真相來源（ISMS），不必在 task 名 + 對照表各存一份，也不必維護每廠商場域/CH 對照表。

權威來源：C:\Users\User\.claude\data\projects.db table projects（欄位 id, name, code, type, stage） 2026-08-25 · 19 筆

特例（不進 DB）

別名

使用規則

• 權威來源：projects.db 的 code 欄，且**只取 stage != 'alias' 的列**（別名列保留是為了查歷史詞的去向，不是合法代號）。
• 合法特例：PUBLIC、UNKNOWN。
• 未登錄代號禁止直接使用：付費客戶先寫入 projects.db；不確定真實廠商一律 UNKNOWN，不要造詞。
• -AI 後綴（v2.2 起）：<廠商代號>-AI = 該廠商場域的 AI 生成資料（如 FOX-AI、IRODA-AI、GREENIDEAS-AI）。後綴只能接在已登錄代號之後，不是新廠商、不入 projects.db；括號內仍放真實 ISMS cameraCode。

資料集切分與廢批狀態都不進 task 名，走 CVAT 既有的 subset 欄位。v2.4 起本節明文列舉 subset 的合法取值，且為封閉集合 —— 不在表內的值一律視為未指定，不得當成可訓練資料。取值大小寫敏感，一律照表中字面。

使用規則

• 合法取值只有 Train / Validation / Test / Rejected 四種，大小寫敏感。
• 廢批一律 subset=Rejected，並在 bug_tracker 寫明廢因（人看的理由）。名稱不加 _REJECT 之類後綴 —— 命名規範沒有狀態欄，也不會有。
• 訓練切分程式一律用白名單過濾：subset in ('Train','Validation','Test')。禁止用黑名單（如 subset != 'Test'）—— 黑名單會把 Rejected 與未指定的 task 一起撈進訓練集。
• 判定廢批但還沒改 subset 的期間是實害風險：只寫 bug_tracker 沒有用，程式不讀 free text。判定當下就要改 subset。
• Rejected 的 task 不刪除、不改名、不搬 project —— 留作證據就是它的用途。
• 要新增第五種取值須改本檔並重 build，不要在各自的程式或本地規則檔另立取值。

現況的非合法取值（不在封閉集合內）

以下是 raicvat5090 p12 現況存在、但不屬於合法取值的 subset 值（清點日 2026-08-19：Test 1563 / Train 1540 / Validation 909 / 空 222 / 小寫變體各 8 / Rejected 2 / Unlabeled 1）。本節只定義它們該怎麼解讀與收斂，既存 task 的實際清理由 data 排程，本規範不追溯強制。

本節由使用者 2026-08-19 裁決加入。前面幾節講「名稱怎麼寫」，本節講「規範本身怎麼改」—— 這兩件過去只有前者寫下來，導致有部門在缺乏權威依據時自行反推規則、自造欄位。

一、格式是封閉的

• 名稱只有 4 段：<廠商>_[<ISMS cameraCode>]_<YYYYMMDD>_<NNN>。不多不少。
• 解析 regex 以 $ 錨定在 3 位序號之後 —— 這是刻意的封閉，不是還沒寫完的開放結尾。
• 序號之後不得有任何欄位：沒有選用尾欄、沒有批次代號欄、沒有狀態後綴、沒有第 5 段。
• 放不進這 4 段的 metadata 就是放不進去。改放 CVAT bug_tracker（人看的自由文字）或該部門自己的台帳。
• 這是規範的核心設計：名稱只放指向 ISMS 的外鍵（廠商 + cameraCode），其餘 metadata 在報表階段 join 取回。為單一欄位破例就是在拆這個設計。

二、規範本身的變更需經使用者同意

• 規範要改，一律先問使用者。不是先改再說、不是「順手處理」。
• 任何部門不得自行新增欄位、改解析 regex、加後綴，或另開一份本地規則副本。
• 唯一真相來源是 C:\reports_maker\_naming_spec_v2_data.json（歸 ops）。同意後改本檔 → 重跑 _naming_spec_v2_build_html.py → deploy，人看的 index.html 與機器版 spec.json 都由本檔產生。
• 不要從下游程式的 regex 反推規則（如 cvat-ops/naming_audit/analyze.py）—— 下游是規範的消費者，不是來源，反推會把實作漏洞當成規則。
• 不要憑記憶回答命名規則。本機直接讀本檔，或讀線上 spec.json。
• 需求提出方式：寫進 _org/inbox/ops/ 的 memo，由 ops 帶到使用者裁決。不確定歸屬就標 TODO，不要猜。

個案裁決

JUJIA_[jujia_A1]_20260601_001      # 寶佳 · ISMS 鏡頭 jujia_A1 · 2026-06-01 · 第1筆
SINON_[151-11]_20260601_001        # 興農 · ISMS 鏡頭 151-11
GREENIDEAS_[吳濁流]_20260601_001      # 思維 · ISMS 中文鏡頭名直接入括號
FOX_[TC-1-102]_20260601_001        # 弗克司 · ISMS cameraCode TC-1-102
FOX-AI_[TC-1-102]_20260529_001     # 弗克司場域 AI 生成資料 · -AI 後綴 · 括號仍放真實 cameraCode（raicvat5090 PPE task 實例）
SKYSHARP_[民雄後門禁]_20260521_001      # 天銳國際 · ISMS 中文鏡頭名 民雄後門禁
CPC_[HEIGHT]_20260601_001          # 中油 · 無 ISMS 鏡頭 · 工安類別 tag 高處
PUBLIC_[FASDD]_UNKNOWN_001         # 開源資料集 FASDD · 日期不明
RAIVISION_[AIGEN]_20260601_001     # 自家合成資料