普通人如何用AI给手机造一个“智能体”：从需求到端侧落地的实践拆解

一、手机智能体为什么值得重新讨论

过去我们使用手机，本质上是围绕一个个独立应用进行操作：打开购物软件、截图、复制信息、切换笔记工具、整理表格。这个过程中，人承担了大量“粘合”工作。随着端侧模型能力提升，一种新的可能性出现：手机不再只是被动响应点击，而是可以根据用户意图，跨应用理解信息、整理数据并给出结果。

这种能力常被称为“智能体”。对于没有传统客户端开发背景的普通用户或后端开发者来说，真正关键的不是“能不能做一个完整产品”，而是能不能利用现有智能编程工具、通用模型能力与自动化流程，快速构建一个可运行、可验证的端侧原型。

本文将结合一次真实实践，讨论如何把“电商订单截图识别与结构化问答”这一需求，拆解为可在手机端落地的智能体流程。整个过程不依赖专业客户端开发经验，而是采用自然语言描述需求、智能编程工具生成代码、反复运行验证的方式进行。

二、先想清楚：不是“做一个App”，而是定义一条智能链路

很多第一次尝试端侧开发的人容易陷入一个误区：一开始就纠结界面、按钮、页面跳转等客户端细节。实际上，智能体的核心并不是界面，而是信息流转链路。

本项目的目标可以描述为：

用户在电商平台订单页面截图，手机自动识别其中的商品、金额、时间、订单状态等信息，完成结构化整理，并支持自然语言查询。

从这个目标出发，可以抽象出以下核心流程：

1. 获取订单页面长截图；
2. 在手机端对截图进行文字识别；
3. 使用端侧语言模型清洗和分类识别结果；
4. 生成结构化数据；
5. 通过可视化界面展示；
6. 支持自然语言问答。

这条链路中，真正的技术难点并不是“写页面”，而是如何把不同环节串联起来，并确保每个环节在手机端稳定运行。只要把链路定义清楚，后续开发就有明确方向。

三、需求描述越具体，AI生成方案越可用

在项目启动阶段，不必先写代码，而是可以先与智能编程工具进行多轮需求澄清。这个阶段可以尽量使用最充分的模型能力，让工具从多个角度审视方案边界。

例如，可以明确说明：

• 目标设备是手机；
• 需要调用端侧OCR能力；
• 输入是长截图；
• 输出是结构化后的订单信息；
• 用户可以用自然语言提问；
• 不希望依赖云端接口；
• 开发者没有客户端经验。

把这些条件描述清楚后，智能编程工具通常可以给出更贴近实际落地的项目结构、模块划分与风险提示。比如它可能会提醒：端侧模型体积不能过大、推理耗时需要控制、截图文字质量会影响识别结果、不同订单页面版式差异需要做归一化处理等。

需求澄清并不是一次性的。通常需要经过多轮交互：先让工具给出整体架构，再针对细节追问，最后再让它生成开发计划。这样得到的方案，往往比一开始直接说“帮我做一个订单识别应用”更可靠。

四、开发循环：检查、生成、运行、再修正

整个开发过程可以概括为一个重复循环：

1. 检查当前开发计划；
2. 让智能编程工具生成或修改代码；
3. 运行并观察结果；
4. 记录问题，回到第一步。

这个循环看起来简单，但实际执行中需要一定的工程判断力。智能工具生成的第一版代码通常能跑起来，但很多时候跑起来并不意味着符合预期。例如：

• OCR识别结果包含大量无关文字；
• 模型输出的JSON结构不稳定；
• 截图较长导致推理失败；
• 某些订单字段缺失或错位；
• 自然语言问答时无法正确关联上下文。

这些问题不能只靠“再生成一遍”解决，而是需要把现象准确描述出来，甚至手动定位到具体环节。例如，是识别端没识别出来，还是清洗端把正确信息过滤掉了？是模型输出格式不稳定，还是展示层解析出错？

这种定位能力，并不需要传统客户端背景，但需要开发者具备基本的系统思维：知道数据是如何一步一步流经整个链路的，哪个环节出现异常，就优先检查哪个环节。

五、真正的卡点：让端侧模型跑在手机上

许多第一次接触端侧AI的人会有一个误解：以为把训练好的模型文件直接放进项目里，就能在手机里调用。实践下来会发现，这是整条链路中最容易卡住的环节之一。

以OCR识别为例。目前常见的做法是使用一个通用的OCR模型完成文字检测与识别。这类模型通常以训练框架的原生格式保存，例如.pdmodel等。但手机端推理引擎并不直接识别这些格式。

要把模型跑在手机NPU或CPU上，通常需要经过转换：

• 先将原生模型转换为通用中间表示，例如ONNX；
• 再使用面向移动端的推理运行时加载ONNX模型；
• 如果目标是在NPU上运行，还需要确认推理运行时是否支持对应硬件后端；
• 同时需要处理输入预处理、输出后处理，保证与原始训练流程一致。

这一步的难点并不在于代码量，而在于工具链适配。例如：

1. 模型是否能成功从原生格式转换为ONNX；
2. 转换后算子是否被移动端运行时全部支持；
3. 输入张量的形状、通道顺序、归一化方式是否匹配；
4. 输出层名称与后处理脚本是否对齐；
5. 推理精度是否满足业务需要。

任何一个环节不匹配，都可能导致模型无法加载、推理崩溃或结果完全错误。

在这个项目中，OCR模型的原生格式无法直接被手机使用，最终需要先转换为ONNX格式，再由移动端推理运行时加载执行。经过转换与调试后，识别链路才在手机端跑通。

六、从OCR到结构化：端侧语言模型的作用

OCR只是把图片变成一行行文字，并不等于直接得到订单字段。截图中的文字可能包括：

• 商品标题，可能跨行、含符号；
• 价格，可能包含货币符号、优惠说明；
• 时间，格式不统一；
• 订单状态，可能使用图标或颜色辅助表达；
• 物流信息，可能夹杂在备注中。

因此，需要第二个模型来理解这些文本，完成字段提取与分类。这里采用端侧语言模型，而不是调用云端大模型，一方面是为了减少网络依赖，另一方面也便于整条链路在离线环境运行。

语言模型的工作可以分为两步：

1. 数据清洗：去掉与订单无关的界面文字、重复内容、推广信息；
2. 结构抽取：将清洗后的文本转换为键值对，例如商品名称、数量、实付金额、下单时间、订单编号等。

为了保证输出稳定，通常需要在提示词中明确输出格式。例如可以要求模型输出JSON，并给出字段定义与示例。部分轻量端侧模型对长文本和复杂指令的遵循能力有限，因此提示词设计需要更简单直接。

如果发现模型输出格式不稳定，可以考虑：

• 缩短单次输入长度；
• 将任务拆分为多个步骤；
• 对输出做正则校验和兜底处理；
• 在界面层对缺失字段进行提示，而不是直接崩溃。

七、可视化与自然语言问答：让数据真正可用

结构化数据生成后，还需要通过直观方式呈现给用户。这部分比想象中更灵活。可以用列表、卡片、分组等方式展示订单信息，也可以按时间、金额排序。

自然语言问答则是在结构化数据之上增加一个轻量交互入口。例如用户可以问：

• “这个月买得最多的是什么？”
• “待收货的订单有哪些？”
• “总共花了多少钱？”

这类问答不依赖于复杂的语义理解，因为数据已经结构化了。只要先把自然语言转换为对结构化数据的查询意图，再执行匹配、过滤、聚合即可。

实现上，可以先用规则处理常见问题，例如关键词匹配“花了”“金额”“总数”等；再对更复杂的问题调用端侧语言模型理解意图。关键是要保证答案可解释、可追溯，避免模型给出没有数据支撑的回答。

八、对普通开发者的启示

这个项目说明了一件事：即使没有客户端开发背景，只要能把问题定义清楚，把链路拆开，再借助智能编程工具与端侧模型，也可以做出可运行的手机智能体原型。

同时也要看到，真正阻碍落地的往往不是“不会写客户端代码”，而是几个关键认知：

• 端侧模型不是简单复制文件就能调用；
• 不同环节之间的数据格式需要严格对齐；
• 工具生成代码只能解决“能跑”，不能保证“跑对”；
• 调试循环必须建立在理解系统链路的基础上。

对于企业或团队而言，如果要进一步产品化，还需要考虑模型更新机制、隐私合规、性能监控、异常兜底等工程问题。但作为个人实践来说，先跑通一条最小链路，验证核心价值，已经是从“看别人做智能体”到“自己做一个能用的智能体”的重要一步。

未来，随着端侧推理框架、小模型能力和智能编程工具的进一步成熟，手机端智能体的开发门槛还会继续下降。到时候，真正稀缺的将不再是某种编程语言或平台经验，而是对场景的理解、对流程的抽象，以及把复杂问题拆成可执行步骤的能力。