- 现场人员本来就随身带着手机，但大多数系统逼着他们事后回到办公桌前补录数据。
- 好的助手要单手就能用：拍张照片它就看得懂，说句话它就记下来，没有信号时也照样能用。
- 看得见的效益是：工作在现场就能完成，事后不用重做文书，数据也比以前准确。
传统网站和应用做不到的地方
在现场干活的技师只空得出一只手，戴着手套，站在大太阳底下，信号时有时无。我们给他用的系统，却是一份为坐办公室的人设计的十栏长表单。结果他只好先记在纸上，晚上再回来补录。
传统的现场应用是一套死板的检查清单。员工得知道该打开哪个菜单，还要在不方便的环境里打一长串字，数据于是录得晚、录不全。
现场软件往往是把办公室表单缩小到手机上，可用户此时正站在烈日下、戴着手套、身处嘈杂的环境，或者根本没有信号。所以他们先记在纸上、拍照留存，晚上再回来录入。数据迟到，细节记漏，大家觉得系统是个负担，谈不上帮手。
AI 现场作业助手（AI Mobile Field Assistant）必须按真实的工作情境来设计：能打开正确的手册，读取标牌或文件，接收语音指令，建议下一步，并在作业过程中记录证据。但它不能让技师的注意力离开安全，也不能让他们轻信尚未经企业内部专家确认的建议。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 显示手册，接收表单，事后上传照片 | 理解图像和语音，从当前工作中调取上下文，以交互方式建议检查步骤，并生成经员工确认的结构化记录 |
现场应用的系统集成，要能应对在线和离线两种状态。应用把工作包（Work Pack）和证据安全地保存在设备上，部分 AI 任务在靠近用户的一端完成，条件允许时再通过 API 同步，遇到数据冲突则交给人来决定。
企业可以用上的新能力
所以，真正好用的现场助手要从作业的实际条件出发：拍张照片，系统就明白拍的是什么；简单说几句，它就记到正确的栏位里；没有信号也能继续工作，回到有信号的地方再上传到系统。
项目形态
这款应用把手册和智能工作日志装进同一部手机。用户选择设备资产（Asset）或扫描编码，系统就预先加载它的历史记录、检查清单和相关文件。作业时可以用大按钮、语音、图片和简短的步骤操作，即使网络不通，也会记下谁在什么时间做了什么。
具体功能
功能可以包括离线工作包、语音笔记、文字识别（OCR）、图片标注、引导式巡检、零件查询、远程专家、安全确认、自动报告和同步状态。如果 AI 没有把握，应该请用户补拍照片或呼叫专家，不能给出超出现有数据的笃定答案。
适合现场的技术
部分任务在设备端完成，比如语音识别、OCR 或检索已缓存的数据，这样响应快，也能保护隐私；需要最新数据的任务，则在有网络时发送到云端。应用必须具备冲突处理（Conflict Resolution）、加密存储、后台同步和设备权限管理，也可以接入移动设备管理（MDM），管理公司的设备。
对现场人员的好处
技师花在写报告上的时间少了，不必每次都打电话问人就能查到需要的知识，第一次就能把完整证据交给专家。主管能更早看到积压的工作和异常情况。企业还能从优秀员工的讲解和照片中积累隐性知识（Tacit Knowledge），用来改进手册，但不会声称 AI 能取代现场技能。
- 相机助手，读取标牌、条形码、文件或现场状况
- 语音优先，腾不出手时也能用，还能实时追问
- 设备端 AI（On-device AI）处理部分任务，不必把所有数据都传到服务器
- 离线优先（Offline-first），先保存工作，信号恢复后再同步
模拟案例
实际使用场景
建筑巡检人员拍下一台设备，应用读取编码，调出历史记录，用语音询问设备状况，并起草巡检记录（Inspection Record）。有风险的地方转给工程师处理，不允许由 AI 出具安全认定。
在这个模拟案例中，一位技师到一栋信号很弱的大楼检查空调。他扫描设备资产编码，应用打开事先下载好的历史记录和检查清单。他用语音记录读数，并拍下看起来异常的部位。系统提示其中一个读数超出了客户工程部门设定的范围，于是加上一步，请专家复核。
恢复联网后，应用同步证据、更新工单（Work Order），并生成报告草稿，技师检查修改后再提交。如果部分数据与办公室那边的修改冲突，系统会把差异列出来让他选择，不会悄悄覆盖。这样的体验减少了重复劳动，决定权仍然留在现场人员手里。
范围、风险与效果评估
写给开发团队 · 技术指标
必须用实际使用的设备、光线、噪声、手套、语言和网络来测试，并规定哪些数据可以存在设备上、存多久。指标应关注 First-time Completion、Report Delay、Missing Evidence、Expert Call 和 Safety Stop，速度的权重不能高于安全或证据质量。
必须设计好用户同意（Consent）、数据保存期限、电量和延迟、各种设备型号的适配，以及模型无法使用时的手动模式（Manual Mode）。
写给开发团队 · 技术指标
应跟踪的指标：Time-to-Record、Data Completeness、Offline Success、Expert Escalation 和 Unsafe Advice
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果应用让用户的视线离开手上的工作、证据在同步过程中丢失，或者在有风险的环节给出含糊的建议，就应该暂停试点。安全和记录的完整性，必须排在报告速度前面。
BUSINESS & PRODUCT READINESS
现场 AI 必须按真实条件来设计，把网页缩小塞进手机是行不通的
先调查作业环境，再定功能：用户有没有空出来的手？光线和噪声怎么样？是否戴手套或个人防护装备（PPE）？信号会断多久？工作要求几秒内得到响应？这些问题决定了该用语音、相机、大按钮、设备端处理还是离线队列，比界面好不好看重要得多。
写给开发团队 · 技术细节
准备好 Device Matrix、Permission、Data Retention、Sync Conflict 和 Manual Checklist。AI 应帮助生成记录或查找操作步骤，但影响安全的建议必须依靠规则和专家。设定 Battery/Latency Budget，并在最难的班次和地点测试。
建立设备与环境矩阵（Device and Environment Matrix），区分不同情况，比如手是否空得出来、光线够不够、能保持在线多久、需要哪种身份验证。然后为每种情况选择合适的交互方式：有的环节适合语音，有的适合单个按钮，有的根本不该让人看屏幕。
手册和阈值必须有负责人，来自客户企业的工程、安全或专家团队。系统应显示版本号和更新日期，并始终提供手动模式。试点可以从手册清楚、风险可控的工作开始，找一小群愿意在真实现场提供反馈的用户。
哪些任务让人腾不出手？
哪些数据绝不能离开设备？
能离线工作多久？
哪些建议必须由专家确认？
开发一款顾及真实情境和设备限制的现场助手
DNA Maker 会到现场实地观察，或与员工和专家做情境访谈，了解他们的动作、工具、信号条件和禁止事项，然后绘制三重情境图（Three-context Map）：人员、地点、任务。与具体工作相关的专业知识仍由客户确认，我们负责把这些知识整理成适合手机的交互方式和数据流。
我们制作可点击原型、相机原型和语音原型，从一开始就在真实设备上测试，不等后端完工。这样在架构定型之前，就能发现按钮、语音、光线、网络和确认步骤方面的问题。
在选择功能之前，DNA Maker 会按不同地点和设备，把用户旅程（User Journey）梳理到细节。我们制作原型，针对亮度、噪声、按钮尺寸、单手操作和离线流程做测试，然后设计设备端与云端相结合的架构，在速度、隐私和数据新鲜度之间取得平衡。
解决方案可以包括原生移动应用、离线同步、OCR 和语音功能、AI 现场助手、工单系统集成和专家控制台，并配有不打扰用户的遥测数据收集。如果有某项工作，技师每次都得打开手册、拍照、再填一遍报告，就可以拿这条流程做试点，先证明它在实际中可用，再增加其他功能。
DNA Maker 可以开发原生或跨平台移动应用、设备端与云端 AI、离线存储与同步、条形码与 OCR、语音、后端和系统集成，并提供崩溃、延迟和模型监控。
如果员工在同一项任务里要拿着手机在手册、相机和纸之间来回切换，可以带着这项任务来找我们。我们会帮忙设计一个现场试点，在不增加负担的前提下衡量时间和数据完整度。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这组术语解释了现场软件的不同之处，从设备端、离线、多种媒体，一直到响应时间。可以借这些术语问清楚：当现场条件和会议室完全不同时，系统如何继续工作、如何恢复数据。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| On-device AI | 在设备上运行 AI，适合需要速度、隐私或离线工作的任务，但要考虑模型大小、电池，以及每种设备型号的处理能力。 | 不把录音上传到云端，就能总结笔记 | 哪些设备型号支持？ |
| Offline-first | 设计成没有网络也能工作。应用从一开始就要支持离线创建和修改数据，同时显示同步状态，并说明两端数据冲突时如何处理。 | 先记录巡检结果，之后再同步 | 同步时数据冲突，怎么解决？ |
| Multimodal Prompt | 把多种媒体一起交给模型判断。指令应说明每张图片、每段音频和每段文字分别起什么作用，以及证据看不清时该怎么办，不要让模型去猜。 | 设备照片加一段语音提问 | 哪些媒体是必需的？是否取得了用户的同意？ |
| App Intent | 系统可以用自然语言调用的应用功能。它为应用或外部系统提供了触发既定任务的入口，所以必须写清楚输入、权限和预期结果。 | 下指令打开下一项巡检任务 | 哪些操作应该开放调用？ |
| Latency | 从发出指令到得到响应的等待时间。要衡量的是整个流程的耗时，模型的响应时间只是其中一部分，因为查数据、调用 API 和同步都会增加用户的等待时间。 | 语音指导的响应速度要跟得上现场作业 | 慢到几秒就没法用了？ |
延伸阅读（原始文档）：https://developer.apple.com/documentation/foundationmodels/