第三届 NVIDIA DGX Spark 黑客松 · Agent Skills 开发挑战赛参赛纪实与技术记录。仓库github.com/majiantong58-collab/dgx-spark-agent-skills数字纪律只引用仓库落盘数字。墙钟时间给区间不给单点各层调用次数tier_calls才是确定性主指标。⚠️照片口径本文照片级数字分两批。未打码原图批——含可辨认人脸、当事人未同意公开原图不随仓库分发这批数字无法从可发布素材复现打码样片批——随仓库分发、可复现数字已落盘docs/face-blur-rerun-ledger.md。打码改变了检测结果人员区域 6→5 处、有人把握 0.4632→0.7525 越过判定线这本身正是 §3 的故事。起因报名这次比赛源于一个朴素的问题AI Agent 这个在互联网世界里被反复验证的「新物种」能不能走进车间替制造业做点实实在在的事带着这个问题我们最终捧出了两个作品——「面向工业 MES 场景的车间穿戴智能视觉识别系统」与「搭载 AI Agent 的 MES 生产管理助手」。下面是它们的完整技术记录。问题是从一次调研里具体起来的。做 MES 调研时我们拿到了十份产线在用的表单样张逐列对过去——那一刻才真正看清系统不可谓不先进可数据的录入、规则的核对仍旧靠人力靠一张张手写的表格。巡检员每天要在车间里往返数十次反复核对着装规范再逐一填表——高强度、高重复的核对必然伴随疲劳与疏漏。第一个念头由此而来能不能把「看」这件事交给机器摄像头采集画面本地设备完成推理把原本沉重的巡检变成一次次「机器替人看」的调用人只需专注在判断与决策上。念头是滚烫的现实却很快给了我们几记结实的闷棍。第一重我们没申请到赛方的算力节点手里的机器只有一台 RTX 5060 Laptop、8 GB 显存——「看一眼就识别」的理想撞上了 8 GB 的墙。第二重工程细节远比想象棘手——光线、角度、遮挡识别效果迟迟稳不下来更扎心的是修复前启发式把三个实际戴着帽子的人标成了「未佩戴」。第三重也是最意外的一重我们亲手做对照实验拆穿了自己文档里的一个假设见 §3 末——那一次比任何挫折都让人脸红。但挫折把我们推向了一个更深的问题识别出来不算完成——发现必须落进系统、变成业务动作。于是第二个作品破土而出一个挂在 MES 页旁的 Agent 助手五个工具、清单化清单外的它直说做不了。我们不再满足于做一个识别工具而是想做一个真正的「助手」。还有一条底线必须守住数据。车间照片里有可辨认的人脸当事人未同意公开——所以我们坚持全流程本地推理、对外只发打码样片云端层不是没做而是本次没有授权一次都没被调用过我们不假装它能兜底。安全与诚实是我们从头到尾守着的两条底线。下面进入技术正文。1. 一个具体的取舍我们没申请到赛方发放的算力节点。剩下的选择很清楚要么放弃本地路线全走云端 API要么在手上的机器做一版。我们手上是一台RTX 5060 Laptop8 GB 显存Windows。我们选了后者但定了一条规矩不是「跑不动所以缩小」而是「同一套架构按机器能力伸缩规模」。这句话有具体的落点换成更大的显存只需要替换 Tier 1 的模型规模三层结构与层间接口不变。8 GB 显存意味着单模型上限大约 3.5 GB所以架构不能是「一个大模型包打天下」必须是分层的——便宜的先看拿不准再叫贵的。伸缩点被刻意收在一处便宜的检测层、启发式层、以及它们与贵层之间的升级协议都与模型规模无关真正随机器变的只有 Tier 1 那一个模型。这也是我们选择把「要不要叫贵层」做成独立决策、而不是揉进模型里的原因。说明这是一条架构设计主张我们没有在更大显存的机器上实测过——本机是 RTX 5060 Laptop 8 GB。它描述的是代码结构预留的伸缩方式不是已验证的性能结论。于是就有了这条三层管线全部跑在笔记本本地。2. 三层怎么分层组件稳态耗时已加载区间显存 after_load / peak / after干什么Tier 0YOLO11n 检测器14.29 – 51.42 ms42.1 / 59.8 / 42.1 MiB只做人形定位与计数Tier 0.5颜色-几何启发式16.12 – 18.58 ms不占显存纯 CPU用颜色/形状找 PPE 线索Tier 1Qwen3-VL-2B9046.6 – 10603.29 ms≈9.05 – 10.60 s4059.0 / 4546.9 /4096.3MiB逐人判读着装Tier 2StepFun 云端——本次运行未授权未触发每层独立进程 × 3 轮稳态样本 15冷启动区间Tier 03.976–4.147 s、Tier 0.51.862–1.894 s、Tier 119.362–20.638 s。数据出处docs/local_tier_benchmark.json——该文件是逐层性能数字的唯一真值来源。有些数字值得多看一眼。Tier 0 的稳态区间是 14.29 到 51.42 毫秒上端是下端的 3.6 倍。我们起初以为是随机噪声查下来是系统性现象每个进程内稳态第 1 次调用恒为 43–51 ms第 2 次起落到 14–17 ms三个独立进程各自复现。成因是进程内首次调用仍受 CUDA 分配器与计算图预热影响——不是抖动是结构。这比「偶发离群」更值得写本地推理的延迟有系统性的预热特性只报一个平均数是把结构掩盖成噪声。对「能不能长跑」同样有意义——Tier 1 推理后显存4096.3 MiB比加载后的 4059.0 高 37.3 MiB 且未完全回落PyTorch 分配器缓存非必然泄漏而 Tier 0完全回落到 42.1 MiB。这也正是我们全篇墙钟只给区间、并以确定性指标为主证据的原因。关键在于第一层和第二层有多便宜。十几毫秒和十几秒之间差了三个数量级所以「少叫一次贵层」的收益极大。实测三张真实车间照片无人那张0.11–0.16 秒、零次 Tier 1 调用有人那张14.35–25.20 秒、一次 Tier 1 调用。差别不在优化而在于——没人的那张照片检测器一看就短路直接不进 Tier 0.5也不调用那个 10 到 11 秒的模型。⚠️ 这里要补一句我们自己踩出来的坑这条短路路径也承载检测器故障。检测函数在ultralytics未安装或权重文件缺失时返回空表而不抛异常走的是同一条分支——对外同样显示「跳过 · 上游无信号」。也就是说「画面里确实没人」和「检测器根本没跑起来」从输出上看不出区别。一个把故障显示成「一切正常」的链路比一个会报错的链路危险得多。这条我们后来修掉了检测层现在会抛异常而不是返回空表管线据此写一个不同的原因码界面显示「未能运行」并明说「这不代表画面里没有人」。我们用什么当主证据主指标是各层的调用次数不是墙钟时间。三张照片跑三轮调用次数三轮完全一致tier0: 3 tier0_5: 2 tier1: 2 tier2: 0因为它是输入决定的不是计时决定的。而墙钟会波动——同一张照片三轮下来最慢 25.20 秒、最快 14.35 秒极差 1.76 倍波动主要来自 Tier 1 单次推理约 10 到 11 秒本身。所以本文的墙钟一律给区间不给单点单点数字报出来等于随机挑一个数。这个取舍本身也是本轮的一条方法论把确定性指标各层调用次数作为主证据把墙钟作为参考区间报告。管线里把它记成short_circuit: no_person。这是整条链路里性价比最高的一行代码——同时也是最需要加一道「故障 vs 真无人」判别的一行见上一节末尾的说明。3. 核心洞见便宜的那层不该说「没问题」这一节是全文最想讲的部分。三层跑通之后我们差点犯一个错误。启发式拿到一张图输出「未佩戴·警告」。看起来很正常。但把它的原始输出翻出来看问题是它看不见白色。白墙、白柜、白色反光——白色掩膜里混着二十多个噪声连通块。它对白色人员的召回是 0。我们最初以为这是「环境里白色太多、白衣服没区分度」。查下来不是——是代码里的一句注释和自己的实现打架。启发式里有一句注释写得很清楚「白色区间本身饱和度为 0不能被饱和度下限误杀」。而紧接在它下面的实现把饱和度下限一刀切地施加在了所有颜色区间合并后的掩膜上。白色区间的定义是饱和度0–45下限是60——它被全数清零与画面里有什么无关。三个数把这件事钉死事实值白色像素的饱和度分布中位21、90 分位38口径按S∈[0,55]取白代码里施加的下限60白色区间像素的存活率0.0000把白色区间加回去之后输出与当前逐位完全相同最后一行是死代码的直接证据一个对结果毫无影响的区间等于不存在。所以正确的说法是这个 0 是缺陷不是能力上限。我们把它按缺陷记账——因为它可以修而「设计约束」是不可修的用后者描述前者会让人以为不用修。不过要同时说清下半句修了也不够。把缺失的颜色区间补回去之后照片1的把握范围是0.08–0.46把照片2 也算进来上限到 0.56。两者都仍然全部低于 0.75 的判定线——「本层不下结论」这个结论不变。于是有了两条我们必须写死的规则第一条没看到 ≠ 没有。它「没找到防尘帽」不能报「未佩戴」。那会冤枉一个穿戴合规的人。在安全场景里假指控比漏检更糟——漏检只损失一次检查机会假指控会摧毁对系统的信任。第二条看到了但拿不准 ≠ 没问题。置信度 0.15 的阳性结果不能报「合规」——那会放走一个真违规的人。所以只有置信度 ≥ 0.75 才能下结论。这里得补一句关于这条线能不能过的实测。把握值取「头盔覆盖率」与「防护服覆盖率」中较小的那个而头盔区只占人形框高度的 33%。在未打码的那批照片上头盔区最大覆盖 0.4632防护服区最大能到0.8116——绑住那一批的是头盔项7 条 findings 因此全部uncertain。但我们一度据此写成「这条线结构上过不去」——那句话是错的我们自己后来推翻了自己。在给同一张照片做了人脸打码之后把握实测到了0.7525越过了 0.75系统确实输出了一条info。打码版的逐人 confidence 与 3 次稳定性复跑已落盘docs/face-blur-rerun-ledger.md打码样片随仓库分发可复现。越线的不是「穿戴更规范」是一次人脸马赛克。这件事比它听起来严重它说明这个把握值是没标定过的色块覆盖率代理量不是合规概率——一个与 PPE 状态无关的图像处理动作就能把它推过判定线。所以「达到判定线」不能读作「这一层认为此人合规」。这个 0.75 不是新拍的它就是升级阈值本身——和「什么时候该叫 Tier 1」用的是同一个常量。这是我们刻意做的如果升级用一个阈值、危险等级用另一个两套规则迟早会漂移。一刀切只有一个数字要维护。一句话便宜层的职责是决定「要不要叫贵的层」不是宣布结果。实测佐证改之前启发式在那张图上把3 个实际戴着帽子的人标成了「未佩戴 · 警告」。改之后同一张图的6 个人全部是uncertain整轮 7 条 findings 里warning/critical出现0 次。uncertain不是「我们偷懒不判」而是正确的输出——它意味着「这件事我这个层没有能力下结论」。这是分层架构里便宜层唯一诚实的表态。但这句话得配着上面那组实测读。在这批未打码照片上这一层是 7 条全uncertain——它没有出过错但那是因为它几乎没有机会出错输出集中在同一个值上就不携带区分度。而打码那张越过线之后它输出的是info——一个「没问题」的结论原因却是一次马赛克。两种情况都不构成「有判断」。「不出错」和「有判断」是两件事不能混为一谈。贵层的对照同一张图把三个层的能力摆在一起YOLOTier 0颜色启发式Tier 0.5本地视觉模型Tier 1命中6 个框3/6模型自述 5 人逐人作答接地未验证穿白的✗全漏模型自述认出 2 名启发式漏掉的包括所有穿白衣服的人。贵层零调参在它的自述里蓝的白的都认出来了。⚠️上表右列只能读作「模型自述」不能读作「识别正确」。三个理由都写在这里而不是脚注里逐人输出未验证接地。我们做了扰动对照只把编号图 1 号人形框顶部 20% 抹掉其余像素不动。结果1 号自己没变仍答「是」而 3 号、4 号从「是」翻成了「否」。改动只发生在一个框内结论漂到了别的框上。诚实边界n1 帧、n1 次扰动、扰动方式粗糙——只够说「不能假定它接地」不够说「它不可能接地」。无 ground truth。这批照片是我们自拍的没有标注所以「2 命中」里的「命中」二字指的是「模型说 2 个人穿白」不是「我们核实过 2 个人穿白」。这一层的输出当前不参与任何判定。它的答案是描述不是结论——见下一节。这个对照说明分层的价值不在于「便宜层更准」——它明显更不准。价值在于它用十分之一的代价过滤掉了大部分不需要贵层的请求。一个必须自己拆穿的假设贵层是判定者吗不是。这是我们做完对照实验之后最难堪的一条发现。判定在 Tier 0.5 那一层就定稿了。Tier 1 是在 findings定稿之后才被调用的它的回答只被挂到结果的顶层字段不回写到任何一条结论里。全仓库读这个字段的地方只有界面的引文块。决定性对照把「模型说全部合规」和「模型说 3 号没戴帽」分别喂进去机器判定逐字段完全相同。所以我们文档里原先写的「Tier 1 确认或推翻 Tier 0.5」准确的说法是那是设计意图。当前实现里Tier 1 是描述者不是判定者——它被调用、产生成本但不改变任何一条结论。这个坑值得单独讲因为它不是「实现漏了一步」是文档与代码对不上而我们没先发现架构图里画了一条从贵层回到判定的箭头代码里那根箭头不存在。画架构图的时候最好顺手 grep 一下那条箭头有没有消费者。4. 意外发现不给技能模型会编造工具名这是我们做对照实验时撞上的跟分层本身无关但可能是整轮里最有意思的观察。实验里有一组是完全不给任何技能包——只给任务提示词让模型自己决定调什么。结果它开始编造工具名。在 40 条用例、每例跑 3 次的口径下数据skills/evals/results/A.json臂带skills字段的调用引用了不存在的技能名不同假名数A不给技能11769 次37 个B给完整技能1200 次0C删掉负向条件1190 次0D只给描述1200 次0它编出来的名字比如rtsp_stream_analysis、helmet_detection、oil_leak_detection、reflective_clothing_detection——听起来完全像真的。如果不看技能清单一个人类评审很难当场发现这些工具并不存在。这引出一个值得警惕的点在只看最终输出的评测里一个「编造合理工具名并调用」的模型和一个「正确调用真实工具」的模型输出格式上几乎无法区分。统计口径便于复算上表的判定方式是从raw_response里解析出skills数组一次调用中只要出现至少一个不在 4 个真实技能名inspection-orchestrator/safety-hazard-detection/gauge-reading/inspection-report之内的名字就计为一次「引用了不存在的技能名」不同假名按字符串去重计数。原始数据在skills/evals/results/{A,B,C,D}.json。两套用例集下的假名数不同原因只有一个主用例集40 条与加强负例集9 条上A 臂编出的假名并不相同用例集A 臂引用假名的调用不同假名数主用例集69 / 11737加强负例集16 / 279这个差异只来自用例集本身不同——两套用例问的问题不一样模型自然编出不一样的名字。它与技能描述版本无关而且机制上不可能有关A 臂的 payload 是空 system message它根本不加载任何技能描述。无论description怎么改A 臂看到的东西一个字都不会变。所以拿 A 臂去比较「描述改动的影响」在设计上就是无效的——要测描述的影响只能看加载了描述的 B / C / D 臂。5. 一个没做成的实验这一节讲我们没做成的事。而且比「没做成」更难看一点我们一度以为自己做出了一个「诚实的否定结果」后来发现那个结果根本不可解释。先说结论免得读者读完才知道本节不提供任何关于负向条件有效性的结论。原四臂实验的 C 臂操作没有真正施加成功所以Δ2 0.000不是「没测出效应」而是「变量没删掉」。重做版已预注册、执行器就绪但因 API 账户配额耗尽没能运行。现在的状态是「不可判读」不是「零结果」。我们想测什么Agent Skills 官方规范明确建议skill 的description里要写清楚「不适用于什么」。此前官方从未公开量化过这段负向条件的运行时收益。我们决定去测设计四臂对照A 不给技能、B 给完整技能、C 给技能但删掉负向条件段、D 只给描述不给正文指标是Δ2 FTR© − FTR(B)FTR 是负向误触发率越低越好所以 Δ2 为正是负向条件的净收益。我们测到了什么结果Δ2 0.000。主用例集40 条含 16 条负例三个臂的 FTR 全为 0.000。我们又做了一套加强负例集——9 条全部构造为「同族干扰」即一个不读负向条件的模型有明确理由误触发的场景并在看到任何结果之前预注册了假设若负向条件有净收益加强集上的 Δ2 应显著大于主集若加强集 Δ2 同样为 0则负向条件的运行时收益在我们的场景下不成立。加强集 Δ2 同样是 0.000。上面这些数字本身是真的。问题出在我们对它们的解读。为什么这个 0 不可解释复核时发现C 臂的操作根本没施加成功。四个SKILL.md的正文里各自都有一节逐条复述description里那句不适用于的内容。而原 C 臂只从description里删掉了那一句——正文照常加载进上下文。也就是说C 臂的「负向条件」并没有被删掉只是从 description 挪了个位置正文里还完整地写着。一个自变量根本没被改变因变量当然不会动。这一条足以让整个结果作废。除此之外还有两个次要问题#问题说明2主指标漏报A 臂裸模型实测广义触发率 0.562、编造36 个不存在的技能名、幽灵技能调用76 次而「本技能口径」的 FTR记成了 0.000。观察到了过度触发指标没记。3负例偏易原 16 条负例里只有6 条是真 near-miss。裸模型都不误触发的负例测不出任何操作的效果。我们打算怎么补重做版做了三件事C′ 臂运行时读原件 → 内存删段 → 喂给模型删掉所有「本技能不适用 X」陈述--selftest已核验无残留主指标保留原口径另并排加报广义触发率与幽灵技能计数负例 16 → 22 条。规模5 臂 × 46 用例 × 3 次 690 次调用。预注册已冻结、执行器--selftestPASS。然后配额断了。StepFun 账户 HTTP 402quota_exceeded——models.list正常、换其他模型同样 402、探针 5 次全部失败账户级问题与实验无关。690 次调用一次都没发出去。所以本节的最终状态是不可判读基础设施阻塞。既不是零结果也不是有效应。顺带说清两件我们不打算掩盖的事C′ 有个消不掉的耦合C′ 删掉的那段正文里同时含兄弟技能名所以 C′ 相对 B同时少了两样东西——(a) 域排除条件要测的与 (b) 路由提示搭便车的。两个变量绑在一起无法分离。若重做后 Δ2′ 仍为 0我们不会说「已证明 Not-for 无用」。四个正文首段仍有「只做一件事…不读数、不成文、不做趋势分析」这类正向范围陈述隐含边界信息本轮不删删了就等于删掉技能的定义本身。这将是「零结果仍不可解释」的首要候选解释必须写在报告里。一个必须一起说的口径问题如果不加说明Δ2 0 很容易被读成「都挺好」。但报告里有一条提醒值得原样引用若只报 FTR一个「见任务就触发、乱点名」的臂会与「安静拒绝」的臂得到同样的 0.000。对照第 4 节A 臂引用了69 次不存在的技能名而它的 FTR 同样是0.000。因为 FTR 只统计「该用例指向的那个技能是否被误触发」而 A 臂乱点的名字根本不在技能清单里自然一条都不算。指标测不到的地方才是这次实验最该记住的地方。口径提示复算时对不上是正常的但我们不替你对齐本节与第 4 节的数字出自 v1 用例集40 条的原始响应文件重做版复核在同一批数据上得到的是广义触发率 0.562、幽灵技能调用 76 次、假名 36 个。这两组数我们尚未逐一核对到同一口径上——「广义触发率」与「引用了假名的调用次数」是不是同一个分母我们没有验证过。因此两组数必须并排给出并注明各自出处在核对清楚之前不得只报其中一组也不得假定它们可以互相换算。6. 顺带测出的官方静态评分可以用字符串改在做交付前合规自检时我们用 NVIDIA 的SkillEvaluatorv0.3.0做了两轮受控实验各自只改一个变量语义一字未动变量改法Discoverability 变化Overall 变化英文触发词在description末尾加一句Use when …102.4 2.5章节标题正文补一个## Purpose段51.25两轮都有往返比对证据把新增内容按正则精确移除后文件行数逐一回落到改动前的记录值每文件恰好 4 行不适用于段字节级比对未变。说明一点我们写的负向条件段是中文而评分器的触发词检查匹配的是[use,when,for,helps,allows]这组英文子串——所以它既没给我们加分也没扣分只是看不见。补上Use when之后分数动了而那句话不承载任何原描述里没有的信息。这不是指控。NVIDIA 自己的论文写得更清楚结构性分数与 LLM-judge 分数在 145 个真实技能上的一致性只有Spearman ρ 0.14 / Pearson r 0.08论文里有一节的标题就叫“Static Scores Are Not Runtime Evidence”。这是静态方法的固有边界它测的是文本的结构特征不是运行时行为。用作形式一致性门禁是有效的——我们确实靠它发现了缺失的字段但它回答不了「这个技能是不是更容易被正确触发」。7. 局限这一节单独存在不缩写进任何段落。1. Tier 2 未授权本次运行未触发也未验证。cloud_authorized False安全边界会把路由压回本地。三张照片的tier2_calls都是0。这不能被表述为云端路径已工作、或云端兜底已验证——我们只是没有测过它。2. 不可检测项实测得出不是推测检测不了原因通道堵塞COCO 无料箱类别照片里蓝色周转箱确实未检出设备渗漏分不清积水和湿地面明火烟雾无模型无数据未戴手套 / 口罩目标过小且无类别精确人数YOLO 说 6 人、本地视觉模型说 5 人我们无法判定谁对仪表读数三张照片无可用表盘没测过3. 精确人数不可宣称。两者不一致未逐像素人工复核无法裁决谁对YOLO 第 6 个框置信度仅 0.301本就偏低。系统内不存在裁决环节——模型的回答是自由文本从未被解析为计数与检测器比对。也不得「以视觉模型为准」实测模型自述的计数随提示词措辞变化原提示词 5 人 / 编号提示词 6 人两次都do_sampleFalse是确定性复现不是抖动。4. 样本量小。测试素材是我们自己拍的车间照片3 张不是公开数据集没有标注 ground truth因此不能据此给出召回率或准确率。文中的召回数字如 3/6是单张图的观测不是统计指标。5. Tier 0 不认识任何 PPE 类别。COCO 版 YOLO11n 没有「防尘帽 / 防静电服」类别——它的职责仅为人形定位与计数不作为 PPE 判定依据。6. 没有任何外部合作与部署。没有跟任何企业建立过合作关系没有在产线上部署过没有在任何现场做过验证也没有以任何客户为对象的案例。所有测试都在本机完成素材为我们自拍。7. 管线与 policy 存在已知偏差。record_failure目前是累计计数而 policy 写的是「连续失败」若干 policy 定义的触发条件接口未承载。这些已在仓库docs/local-tier-limitations.md逐条列明未做粉饰。8. 贵层的判定权是「设计意图」不是「当前实现」。Tier 1 的输出不参与判定链路——判定在便宜层就定稿Tier 1 在之后才被调用答案只挂到结果顶层字段。详见 §3 末。这是本文里最需要读者注意的一条架构图上有一根从贵层回到判定的箭头代码里那根箭头不存在。9. 便宜层的把握值「能过线」而这件事本身是问题。把握值取「头盔覆盖率」与「防护服覆盖率」的较小者头盔区只占人形框高度的33%。未打码照片上头盔区最大覆盖0.4632、防护服区可达0.8116故 7 条全为uncertain。但给同一张照片打上人脸马赛克后把握到了 0.7525越过 0.75系统输出了info。即这条线可以被越过而且能被一次与 PPE 无关的图像处理越过 ⇒该把握值是未标定的覆盖率代理量。我们最初把这写成「结构上过不了线」那句话是错的已在文中更正。10. 「无人」与「检测器故障」曾不可区分——✅ 已修复2026-09-28。原文检测函数在依赖缺失或权重缺失时返回空表而不抛异常与「画面确实无人」走同一条短路分支对外显示同一句话。修复新增DetectorUnavailable管线以strictTrue调用并捕获写另一条原因码且tier_calls.tier0记0界面显示「未能运行 / 这不代表画面里没有人」。已验证CPU 阻断ultralytics导入strictTrue确实抛异常。残留探针 CLI 的默认仍是宽松行为。11. 贵层的逐人输出未验证接地。扰动对照只抹掉 1 号框顶部 20%1 号自己没变3 号、4 号翻了。诚实边界n1 帧、n1 次扰动、扰动方式粗糙——只够说「不能假定它接地」不够说「它不可能接地」。12. 演示用照片已打码而打码改变了检测结果。原图含可辨认人脸当事人未同意公开。打码后人员区域6 处 → 5 处有人把握0.4632 → 0.7525越过 0.75 判定线另一张1 处 → 2 处。未打码原图不随仓库分发那批数字无法从可发布素材复现打码批数字已落盘docs/face-blur-rerun-ledger.md且打码样片随仓库分发、可复现。13. 对照实验被基础设施阻塞且原结果不可解释。见 §5。本文不提供任何关于负向条件有效性的结论。14. 环境曾有自动装包风险。一张坏图曾触发 ultralytics 的自动装包、把清单外的包装进环境。我们已在运行配置里关掉自动装包服务启动时会打印一行YOLO_AUTOINSTALL确认它关着。结尾这篇记录里我们最想留下的不是某个数字而是两条规矩便宜的那层职责是决定「要不要叫贵的层」不是宣布结果。只报测过的测不了的一个都不报。三层流水线跑在一台 8 GB 笔记本上MES 桥把它和业务接上旁边还挂了一个只做清单里事的助手——两端都是自己做的所以接得上。所有数字、台账、脚本都在仓库里欢迎逐条核对。回望整段历程我们真正完成的是一次从「宏大叙事」到「具体场景」的收敛——AI 不需要被神话它需要的只是被安放在对的地方一个需要几十次巡检里反复核对的车间一个需要从千百张表单里翻找数据的 MES 后台。这场比赛教会我们的比任何一堂课都更深刻最动人的创新往往诞生于最朴素的观察最坚固的技术往往扎根于最真实的场景。当 AI 真正走进车间的那一天它带去的将不止是效率更是让一线工作者从重复劳动里被解放出来的日常。