興農 PPE — 各鏡頭需求
ISMS 快照 2026-08-24 10:37 · 頁面產生於 2026-08-24 11:59 ·
這是快照不是即時，要更新請重跑下方的兩支腳本。
📌
看這頁之前先知道三件事：
① 資料日期＝2026-08-24 10:37（ISMS 快照時間）。這頁不會自己更新，
ISMS 那邊改了需求，這頁不會跟著動——看到的永遠是這個時間點的狀態。
② 需求是從 ISMS 的 notes 自由文字解析出來的，不是結構化欄位，
格式不是強制的。解析規則與「用了哪一行」逐列都有標，原文可展開。
③ 42 支有定案需求，但另外 3 支「待確認」、21 支「不列入」、
1 支「需求取消」——合計 67 列。
待確認那幾支沒有定案（頁面列的是原訂需求，不能拿去標）；
不列入那 21 支的理由寫在 ISMS 的 updates 欄，
本站抓不到，只能標「不列入」。詳見第三段。
📄
資料來源與日期
來源＝ISMS https://isms.intemotech.com/api/cameras 的 camera notes 欄，
快照檔 C:\reports_maker\_isms_cameras_raw.json，拉取時間 2026-08-24 10:37。
範圍＝vendor 興農 且 model 安全裝備 的 67 列。
另有 46 列 model 是 factory_ppe_v20260426_pool_v1、
全部 ARCHIVED——那是 2026-08-09 遷移前的備份，不是現況，已排除。
與 2026-08-18 的基準檔逐列對帳：0 處差異（stage / 定案需求 / 負責人 三欄全同）。本次是重拉 ISMS 的現況，不是沿用舊檔——對帳結果剛好一致，代表這段期間 ISMS 的興農 PPE 需求沒有變動。
⚠
需求物件是從自由文字解析的，不是結構化欄位。
ISMS 的 notes 慣例格式是三行「原訂：… ／ 修改後辨識項目：… ／ YYMMDD確認：…」，
但格式不是強制的。
定案取值順序：最新的 YYMMDD確認 > 修改後辨識項目；
兩者都沒有＝這列 notes 沒有需求記載（多半是「這顆不用工安」那批，備註寫在 ISMS 的
updates 而不是 notes，本站抓不到），標成 (不列入)。
每一列都附「用了哪一行」，原文可展開對照。
拆不出來的殘字一律標出來、不猜——本次 0 支有殘字。
🧪
Test 現況對照來自 C:\rai\data\_dept\test-site-v2\_classified.json（門檻 20，排除軟刪幀，計數以評估單位為準），
84 / 84 個組合對得上。那是另一份快照，
不是本頁隨查隨算的；口徑（門檻 20、評估單位、排除軟刪幀）以那邊為準。
「達標」講的是測試集樣本夠不夠，不是模型準不準。兩件事不要混。
一、有需求的鏡頭
| 鏡頭 |
pipelineStage |
物件數 |
需求物件（點標籤可篩選） |
負責人 |
Test 達標 |
二、條件式需求（A 或 B）
🔀
8 支鏡頭的需求寫成「A 或 B」，意思是符合任一組就算合規。
CVAT 的屬性是逐項獨立的 yes/no，沒有地方表達「這兩組是二選一」。
使用者已裁決：兩邊的物件模型都要判斷，合規邏輯放模型輸出後的規則層。
所以標註端照現況逐項標，兩組的物件都要有足夠樣本——
下面把兩組分開列，就是為了看清楚「兩組各自缺什麼」。
三、需求未定
四、反查：物件 → 有哪些鏡頭要
🔎
一個物件底下列出所有要判它的鏡頭。鏡頭代號的顏色＝該格 Test 達標與否
（綠＝達標、紅＝未達標、灰＝Test 對照查無此格）。點鏡頭代號會跳回第一段並篩出那支。
棉紗手套與橡膠手套在 p12 是同一個屬性
gloves（2026-07-29 合併），ISMS 品名不同但看到的是同一份數字。