前几天，Karpathy 发了一篇很有意思的帖子。
他说，自己最近想认真做一次有氧训练管理，目标是在 8 周内，把静息心率进一步降下来。为了更清晰地追踪训练效果，他没有去应用商店里找一个现成的“有氧训练管理 App”，而是直接用 Claude 快速做了一个定制 Dashboard，专门用来分析自己的 Woodway 跑步机数据。
这个案例很小，但很有代表性。
因为它揭示了一个越来越清晰的趋势： 未来很多软件，可能不再是“先有产品，再有用户去适应产品”； 而是“先有用户场景，再由 AI 临时把软件拼出来”。
Karpathy 在这个过程中有两个很典型的发现。
第一，很多长尾需求，其实根本不需要一个专门的 App。 像“8 周有氧实验追踪”这种需求，本身就非常个人化、非常具体，传统软件模式很难为这种细颗粒度场景单独做一个产品，也没必要专门上架一个 App。 但对 AI agent 来说，这种东西可能就是几百行代码、几个接口、一个前端页面的组合，几分钟甚至更短时间就可以生成出来。
第二，真正拖慢效率的，已经不再是“写页面”“写逻辑”，而是“怎么接上真实世界”。 在他的案例里，1 个小时里大量时间并不是花在做 Dashboard 本身，而是花在对接 Woodway 跑步机的数据接口、拉取原始数据、处理和调试这些环节上。也就是说，AI 生成应用已经越来越快，但设备、系统、服务是否以 AI 友好的方式开放能力，反而成了新的瓶颈。
这件事很容易让我联想到我们所在的手机业务。
手机和手机管理行业，其实是一个很有意思的领域。 一方面，它高度标准化。设备有统一的硬件基础、系统能力、策略接口和管控框架。 另一方面，它的应用场景又极其繁多。 不同企业、不同岗位、不同流程、不同终端状态，会组合出大量碎片化但真实存在的需求。
再仔细想想，顺着 Karpathy 这个方向继续往下推，真正值得关注的，其实不是 AI 能不能生成一个页面，而是当 AI agent 开始大规模解决长尾需求时，它会越来越频繁地遇到一个现实问题： 它需要快速调用现实世界里的能力，但这些能力并不是天然为 Agent 设计的。
而手机，恰好是其中最典型的一类对象。
从 AI agent 的视角看，手机并不只是一个消费电子终端， 它更像是一个高度标准化、广泛普及、能力丰富的复合型传感器。 它持续提供位置、时间、网络状态、摄像头、麦克风、蓝牙、通知、应用活动、设备状态等多维信号。 如果这些能力能够被 Agent 直接理解和调用，那么很多长尾需求就不再需要等待标准产品化，而是可以在生成应用的同时，直接把手机纳入能力闭环。
问题在于，今天手机虽然能力丰富，但这些能力大多仍然停留在“人可配置”“App 可接入”“工程师可开发”的层面，还没有真正被组织成一套Agent 可读、可调、可组合的标准能力体系。
这正是中间层存在的意义。
我更愿意把这层定义为：Mobile Skill Abstraction Layer（移动能力技能抽象层）。
它不是简单的 API 包装， 也不是把底层接口做成文档再交给 Agent 去读。 它的核心价值，是把原本分散、底层、偏工程语义的手机能力，抽象成一组更适合 AI agent 调用的标准 skill。
从能力模型上看，这层 Skill 至少需要完成三种抽象。
第一种是 Capability Discovery。 也就是让 Agent 能快速知道：当前这台手机具备哪些能力、哪些能力可调用、哪些能力受限、哪些能力可组合。 这样 Agent 在生成应用时，不需要自己探测系统边界，也不需要逐项猜测权限和接口状态。
第二种是 Semantic Normalization。 也就是把底层系统能力统一转换成稳定、清晰、可解释的调用语义。 Agent 不应该面对杂乱的系统字段、权限状态和厂商差异，而应该面对类似“读取当前位置上下文”“启动相机采集流程”“获取当前前台应用状态”“设置低干扰提醒通道”“注册设备事件监听”这样的高层能力语义。
第三种是 Composable Execution。 也就是让这些能力不仅能单独调用，还能被快速编排进一个临时生成的应用流程中。 因为长尾需求最重要的不是调用单个能力，而是让 Agent 在生成 Web 应用时，可以顺手把手机能力一起编进去，形成一个完整的小型场景闭环。
如果说 Karpathy 那个案例里，Claude 花大量时间在“如何接入 Woodway 跑步机数据”，那么在手机领域，我们做的事情，本质上就是把“如何接入手机能力”这一步大幅前置、标准化、结构化。
换句话说，我们不是在替 Agent 做一个固定应用，而是在给 Agent 提供一套随时可拿来拼装长尾应用的移动能力底座。
举一个更接近未来形态的 C 端例子。
假设一个用户对 AI 说： “帮我做一个旅行中的临时 Web 助手。我要去东京 5 天，我希望它能根据我每天所在的位置、时间和行程安排，提醒我接下来要去哪里、记录我去过的地方，并在我到达景点时自动弹出我提前收藏的内容。”
这个需求很典型。 它不值得做成一个长期存在的 App， 因为它只服务于“这一个人、这 5 天、这一次东京行程”。 但它又足够真实、足够具体，而且非常适合由 Agent 临时生成一个 Web 应用来承载。
对 Agent 来说，生成前端页面并不难。 难的是：它怎么快速把“这台手机”的位置能力、通知能力、前台状态、拍照入口、本地事件触发机制接进来？
如果没有中间层，Agent 需要自己理解：
• 当前位置如何获取
• 后台位置如何处理
• 到达某个地点后如何触发
• 通知如何发送
• 拍照入口如何调用
• 不同手机上这些能力有什么差异
• 当前权限状态是否允许这样做
这套事情，即使能做，也会消耗大量时间在能力理解和接口适配上。 而这恰恰是 Karpathy 提到的那类“不是页面难，而是接现实世界难”的问题。
如果有我们提供的 Mobile Skill Abstraction Layer，这个过程就会完全不同。
Agent 在创建这个 Web 应用时，可以直接调用类似这样的 skill：
• Device Capability Discovery Skill：识别当前手机支持的位置感知、通知触发、相机调用、本地存储和事件订阅能力
• Location Context Skill：以统一语义获取当前位置、地理围栏状态和移动轨迹上下文
• Mobile Trigger Skill：注册“到达某地点”“离开某地点”“进入某时间窗口”等事件触发条件
• Notification Delivery Skill：在合适时机推送轻提醒或卡片式提示
• Capture Entry Skill：为 Web 应用快速接入拍照、记录、上传等手机原生能力
• Runtime Permission Mediation Skill：统一处理运行时权限检查、引导和状态回传
这样，Agent 就不需要从底层系统接口开始拼装。 它在生成这个旅行 Web 助手时，可以直接知道： 这台手机当前可以提供哪些能力； 这些能力应该用什么统一方式调用； 这些能力如何和当前 Web 应用流程组合起来。
最终结果就是，Agent 不只是生成了一个网页，而是顺手把这台普通手机快速转化成一个对 Agent 友好的能力宿主。
也就是说，这个 Web 应用之所以真正可用，不是因为页面写出来了，而是因为 Agent 借助 Skill Layer，快速把手机的感知和交互能力接进来了。
从这个角度看，未来手机行业一个非常重要的方向，不是单纯继续增加更多底层能力，而是把已有能力进一步重构为一套适合 AI agent 直接消费的技能体系。
因为在长尾需求时代，真正稀缺的不是“能力本身”，而是能力能否被快速发现、快速理解、快速接入、快速编排。
而我们做的，正是这件事： 通过一套专业的 mobile skill，把手机底层复杂、碎片化、偏工程实现的接口，转换成 AI agent 可以直接调用的标准能力。
这样，当 Agent 在创建一个长尾 Web 应用时，它不需要再花大量时间理解手机接口，而是可以直接把手机当作一个标准化传感器能力平台接入进去。
这件事的意义，不只是“提高开发效率”。 更重要的是，它让“即时生成应用”这件事真正跨过了从数字世界走向现实世界的那道门槛。
因为只有当 Agent 能稳定调动真实设备能力时，“1 分钟搭建一个私人场景应用”才不只是生成一个界面，而是生成一个真正能工作的场景系统。