175秒生成失败后，他把AI写代码改成了填表

手机上想记一笔账、提醒喝水、算个分账，往往要装三个不同的应用。每个应用只需要几个输入框和按钮，可找到合身的那个，本身就成了新任务。开发者 JackApp 的作者干脆自己动手，但他没有为每件小事写一个应用，而是做了一个能把一句大白话变成小工具的安卓应用。

JackApp 的用法很直接：描述你需要的字段、按钮或计算，它从预置组件里拼出一个迷你应用。记账、提醒、分账可以各自拥有独立的位置和保存的数据，共存在同一个应用里。模型是 Gemma 4 E2B，通过 LiteRT-LM 跑在手机上，模型下载完成后，建工具和用工具都能离线进行。

作者的实际用法是这样的：输入“提醒我喝水”，得到一个带“完成”按钮的提醒，每天提醒三次，点一次完成就累加一次打卡计数。再要一个记账工具，得到金额、备注和累计总额。后来想读小票，又提了一次带“小票”字样的请求，现在拍下小票、核对识别结果，再存进账本。这些是彼此独立的请求，不是在一段对话里反复修改同一个应用，但两次都不需要他画界面、接按钮或搭数据库。

第一次尝试：175秒换来一个失败

最初的做法是让模型描述整个迷你应用——布局、字段、存储值、动作以及它们之间的每一条连线。输出是结构化数据，从不生成可执行代码，JackApp 负责校验，出错就让模型修复，再校验。

在一台 Moto G45 上，一次有记录的尝试花了 175 秒，产出的描述没通过校验，随后的修复又错误地拒绝了请求。三分多钟过去，手上依然没有可用的工具。作者随后缩短输出、把完整 JSON 换成紧凑文本、让修复只返回需要改动的部分。手机复测产出了可用的冰箱和植物工具，但分账和记账仍然失败，物理和天气类请求被错误处理，修复反而让结果更糟。

问题在于，模型被反复要求重新发现一些本就确定的事：计数器的“添加”按钮会让数字加一，日志需要记住自己的条目。这些不该取决于小模型这一次把连线写得多好。

Gemma 填参数，配方搭结构

解法是引入“配方”：预置的应用模式，模型只负责填设置。以记账为例，Gemma 给出字段和想要的合计方式，配方负责表单、添加按钮、保存的行以及它们之间的接线。作者贴出了模型对基础记账请求的真实设置返回：名称“Expense Log”、图标、描述、名词 expense、文本字段 Expense、金额字段 Amount、合计方式为对 amount 求和、无点击动作、无排序、无分享、无提醒。

设备端的配方路径是：你的请求 → 检查已知能力边界 → 选择配方（必要时让 Gemma 分类）→ Gemma 填写设置 → 配方构建应用描述 → 校验 → 预览 → 保存。没有配方匹配或设置不可用时，可以退回同一本地模型的自由生成，那条路更慢也更不可靠。无效描述不会进入预览，也不会被保存。

目前有七类配方：列表与日志、计数器、计算器、计时器、提醒、分账，以及处理文字或照片的 AI 助手。阅读记录和手工材料清单可以共用一套结构，同时各存各的字段和数据。限制也明确：列表每条最多四个字段，计算器最多五个输入四个输出，提醒最多三条每日或每周计划。预览之所以重要，是因为一个请求听起来合理，却可能超出模式能承载的范围。

手机上跑出来的数字

在 Moto G45、Android 15、8 GB 内存的机器上，作者跑了四个受支持的请求和两个超出能力范围的请求。此前在整应用生成下失败的分账和记账这次通过了结构检查，两个不支持的请求被拒绝，四个受支持的构建全部一次通过、无需修复，模型已加载的情况下构建时间中位数为 13.9 秒。

作者自己给这组数据划了边界：这是同一台手机上四次构建的结构性结果，不能证明每次交互都符合请求，也不是与那次 175 秒失败的受控速度对比。加载和照片处理另算，早前一次手机测试中加载模型用了 21.8 秒。手动检查还覆盖了离线构建、重开后数据仍在、拍照辅助的购物与读小票、以及植物提醒的通知。

保存下来的迷你应用包含一份 JSON 描述和它的数据，加载时校验，再用预置组件和受支持的动作渲染。记账、勾选、计算走的是普通应用逻辑，只有读一张新的小票照片才会再次调用 Gemma。配方类应用还带“自定义”，可以改标签、计数步长、计时长度或提醒时间；可能隐藏已有数据的改动会先警告，并提供把当前版本连同数据保留为副本的选项。

为什么坚持放在本地

一张小票暴露消费，一条提醒暴露作息，一张冰箱照片拍在别人家里。记录小票的工具不该需要把小票发到别处。开放权重让 Gemma 能跑在手机上，初次下载之后，设备端路径可以构建受支持的工具、读取照片，不把输入送到托管推理服务，也没有云端兜底，读一张新小票不会多出一笔按次计费的推理账单。代价是约 2.6 GB 的下载，加上手机的内存、电量和时间。

本地推理也反过来影响了设计：长输出在手机上意味着漫长的等待，配方让 Gemma 少写一点，让普通按钮、计算和已存数据不再依赖又一次生成请求。源码同样开放，有人可以查看一份描述如何变成可用工具，改一个配方或加一个配方。

它仍然要求太多的地方

模型可能选错模式、漏掉字段或误解动作。校验只检查描述的规则，结果是否真的完成了你要的活，还得自己看。

• 输入要你自己给。JackApp 看不到你的银行账户，读不了别的应用，也取不到实时天气和价格，汇率计算器需要你输入汇率。
• 照片需要复核。冰箱里被挡住的物品、不清楚的小票文字都可能漏读或读错。
• 它是本地和个人的。没有账号、共享实时工作区和云同步，有 CSV 导出，但迷你应用本身的导出导入还没做完。
• 手机上的准备仍是体力活。开发构建加大体积下载是相当重的第一步，提醒需要通知权限，计时器还不是可靠的背景闹钟。

作者自己的总结是：一个需要不断纠正的工具，只是换了一种家务。

接下来他想先让修改更容易，比如一句“把这个提醒改到周五”就够，同时保住兼容的数据；然后测人们会回头用什么——构建时间能放进表格，有用性要更久才看得出来，他想在更多手机上测真实交互和陌生措辞，再看一周后哪些小工具还值得打开。喝水提醒的打卡计数还在涨，账本里存着那些本来要另找地方记的金额，两者都不需要他画界面或搭数据库，也不需要每次打开都重新写一遍提示词。植物提醒目前只走到手机弹出通知这一步，浇水仍然是他自己的活。