上一期我们说，工业 AR 项目失败，多半不是技术不行，而是在”技术”和”业务需求”之间迷了路。
这一期，我们讲第一个、也是最常见的坑：用例没选对。
坑长什么样
它通常以两种面目出现。
第一种：一步登天。企业此前几乎没有数字化基础，却一上来就想”全都要”——从 ERP 到 AR 的数字主线第一天就要打通，所有部门、所有流程一起上。野心很大，落地为零。
第二种：把所有场景塞进一个 App。寻路导航、设备 IoT 数据看板、维修保养（MRO）流程、甚至备件网店……功能列表很漂亮，但每个场景背后的技术逻辑、数据来源、使用人群都不一样。硬塞进一个应用里，复杂度呈指数级上升，最后哪个都做不好用。
还有一个隐蔽的变种叫”技术专家陷阱”：整个项目只有创新部门、技术极客在推动，真正每天要用它的业务一线和车间工人，从头到尾没参与。做出来的东西很”先进”，却没人愿意用。
正确的做法：从一个”小而实”的 PoC 起步
破解这一坑的核心思路只有一句话：先用一个概念验证（PoC），把一个真实需求跑通、把 ROI 证明出来，再谈下一步。
具体来说有四条原则：
1、聚焦一个真实业务痛点，而且这个痛点的回报要能被量化——省了多少时间、降了多少错误率、避免了多少返工。说不清 ROI 的需求，不值得作为起点。
2、让业务部门参与进来，而不是关起门来让技术团队自嗨。一个会被一线天天使用的方案，必须从设计阶段就听到一线的声音。
3、别过早混用场景。一次只解决一个问题。其他场景不是不做，而是排到后面、单独评估可行性。
4、避免一次堆太多不同的技术元素——技术栈越简单，跑通的概率越高。
一个真实的参照：从 4 周试用到全厂铺开
这套”先小后大”的逻辑，并不是纸上谈兵。安宝特拓影 Twyn 的多个落地项目，走的正是这条路径。
以一个质量检测的 PoC 为例：先安排一线工人做 4 周试用，上手培训只需约 1 小时；试用结束时，数据说话——错误率下降 82% 以上，检测时间减少约 50%，检测成本大幅降低。到这一步，结论很清晰：AR 确实有效地解决了”一个”具体需求。
接下来才是关键——怎么从”一个成功的点”长成”一片”？
成熟的扩展路径，是所谓的”生长与扩张（Grow & Expand）”策略：
你看，从来料检测这一个点起步，先在同一个团队里扩展到产线检测，再把同一套成熟应用复制到其他厂区，最后才是全公司范围的大规模部署、与后台系统打通。每一步都站在上一步已被验证的基础上——而不是第一天就想吃成胖子。
这一坑的本质
用例选错，根子还是上一期说的那个误区：把 AR 当成目的。
当你执着于”我要上一套 AR系统”时，就容易贪大求全；而当你回到”我要解决车间里那个具体的、每天都在烧钱的问题”时，用例自然就收敛了，起点自然就清晰了。
下一期，我们讲第二坑——看不清 AR 的边界：到底哪些场景是收益高、门槛低的”甜点区”，哪些是看着美好、实则难以落地的”技术陷阱”。这一期会用上一张很实用的”收益 vs 复杂度”地图。
📋 自测与资源
你心里那个 AR 设想，起点选对了吗？花 1 分钟做个自测，「工业 AR 制造自检表」会帮你看看用例是否过于贪大。
🔗 想看上面那个”4 周试用”案例的完整版，点击「阅读原文」进入安宝特案例列表页。
