Marico's space

最近折腾了本地 Gemma 4，踩了几个坑，这篇把问题说清楚。

用能力不错的本地模型时，最容易犯的错误是把模型调用当成整个应用。

我在用 Gemma 4 E2B 开发项目时差点就犯了这种错误。

我的项目是一个本地老年痴呆症护理助手，叫 RememberMe CareGrid。产品目标不是做一个听起来很聪明的聊天机器人，而是帮助一位困惑的患者获得平静的上下文信息，帮助护理人员理解发生了什么，帮助可信赖的社区成员安全地做出响应。

这个目标改变了我看待 Gemma 4 的方式。

Gemma 4 不是产品。Gemma 4 是产品内部的一个推理层。

产品是它周围的一切：转录、上下文边界、同意机制、结构化输出、备选方案、延迟、UI 状态，以及在长回答可能有害时保持回答简短的决定。

这是我学到的核心经验：

本地 AI 不仅仅是本地运行一个模型，而是决定模型应该负责什么、应用应该负责什么、以及什么永远不应该委托给模型。

为什么我选择了 Gemma 4 E2B

Gemma 4 给开发者提供了多种模型选择，最明显的诱惑是直接选最大的那个。

对于我的使用场景，那会是一个错误的冲动。

我选择 Gemma 4 E2B 是因为应用需要本地、快速、注重隐私的推理能力。它不需要尽可能大的模型。它需要可靠的简短回复和结构化的护理动作。

在老年痴呆症护理工作流中，模型可能需要回答：

• "我是谁？"
• "我在哪里？"
• "张阿姨是谁？"
• "我安全吗？"
• "站在我面前的人是谁？"

这些问题不是说越长回答就越好。困惑的人不需要一篇论文。他们需要一两句话的平静回答加上一个安全的后续步骤。

这让 E2B 成为一个好选择。它足够小，可以进行实际的本地实验，但又足够强大，能够在护理上下文中进行推理并产生有用的结构化响应。

更大的模型可能对更重的摘要或复杂的多步骤分析有用，但对于面向患者的循环，模型大小不是主要瓶颈。产品设计才是。

这次选择教会了我：模型选择不是排行榜上的决定，而是产品约束的决定。

对于这次构建，最好的模型不是最大的模型，而是让本地辅助变得实用的模型。

架构教训：分离职责

突破性时刻是意识到 Gemma 4 不应该做所有的工作。

在我最初的心理模型中，流程感觉很简单：

用户说话 -> AI 回复

在真实系统中，这太模糊了，没法用。

更好的架构是：

音频或文本输入 -> 转录（如需要） -> 护理上下文检索 -> Gemma 4 推理 -> 结构化响应验证 -> UI、手表、手机或护理人员动作

每个组件有不同的职责。

• 语音转文本把音频变成文字。
• Gemma 4 对文字和护理上下文进行推理。
• 应用验证允许哪些动作。
• UI 决定患者应该看到多少信息。
• 护理人员/社区流程决定谁被允许知道什么。

这种分离让系统调试变得容易得多。如果患者说了什么但响应失败了，我可以问：

• 转录返回了文字吗？
• Gemma 4 收到了正确的上下文吗？
• 模型返回了有效的 JSON 吗？
• 清理器拒绝了一个不安全的动作吗？
• 传递路线到达了手机或手表吗？

没有这些边界，"AI 失败了"是一个毫无帮助的解释。有了这些边界，失败就变得可观测了。

JSON 模式有用，但不够

最重要的决定之一是要求 Gemma 4 返回结构化的 JSON 响应。

对于普通的聊天机器人，文本响应可能就足够了。对于护理助手，文本只是输出的一部分。系统还需要知道意图、风险级别，以及是否应该执行某个动作。

一个简化的响应格式是这样的：

{ "reply": "你是王阿姨。你很安全，小李是你的护理联系人。", "intent": "patient_identity", "risk_level": "medium", "action": "notify_caregiver", "should_end_session": false
}

这改变了模型的角色。Gemma 4 不只是在写一句话，而是在帮助选择一条安全的护理路径。

但 JSON 模式并不能消除验证的需要。

应用仍然需要检查：

• 意图是允许的意图之一吗？
• 动作是允许的动作之一吗？
• 风险级别有效吗？
• 回复对患者来说够简短吗？
• 模型是否幻觉出了一个不应该存在的字段？

这就是为什么包装器很重要。模型可以建议。应用必须决定什么是被允许的。

这是构建过程中最重要的安全教训：

结构化输出不等于安全输出。

你仍然需要在模型周围建立一份契约。

UX 教训：不要优化"令人印象深刻"的回答

AI 演示通常奖励戏剧性的回答。老年痴呆症护理 UX 不是这样。

如果患者感到困惑，一段精彩的文字可能比一句平淡的话更糟糕。太多信息可能会增加压力。

所以我为面向患者的响应制定了三条规则：

• 用一两句话平静地回答
• 永远不要因为患者遗忘而羞辱他们
• 总是给出一个安全的后续步骤

例如，如果患者问"我是谁？"，回答不应该是人物传记论文。应该是这样的：

你是王阿姨。你的护理记录说你有时会感到不确定，这很正常。我在这里陪着你，我会通知小李。

这不是 Gemma 4 能产生的最技术 impressive 的输出。但这是正确的产品输出。

这就是本地模型变得有趣的地方。一旦模型在应用附近运行，开发者可以非常仔细地设计周围的行为。你不只是提示一个模型，而是在塑造一种体验。

隐私是执行路径，不是声明

本地推理有帮助，但它不会自动让应用变得私密。

这是用 Gemma 4 构建时最清晰的教训之一。隐私必须在产品的实际流程中出现。

在我的护理助手中，隐私边界是这样的：

• 模型在护理上下文上推理，但应用控制发送什么上下文
• 可信人员识别只检查已注册的人员
• 未知面孔不会变成身份
• 保存姓名、照片或转录前请求同意
• 社区帮助者收到角色特定的指令，而不是完整的患者病史
• 紧急求助只在安全逻辑需要时共享位置

这让隐私工作变得具体。Gemma 4 本地运行减少了向远程模型发送敏感推理的需要，但应用仍然必须围绕身份、同意、保留和升级执行规则。

对我来说，教训是：

本地模型是一个隐私机会。架构决定这个机会是否成为现实。

本地 AI 需要可观测性

另一个教训：本地不等于简单。

当云 API 失败时，错误通常是外部的。当本地模型失败时，问题可能出在任何地方：

• 模型没有加载
• 模型加载了但是冷的
• 请求超时
• 提示词太大
• 模型返回了格式错误的 JSON
• 本地语音识别器没有返回文字
• 应用把音频路由到了错误的组件

所以我在本地流程周围添加了提供程序元数据和诊断。应用应该知道响应是否来自 Ollama，哪个模型回答了，花了多长时间，如果出了问题是什么失败了。

这听起来可能很无聊，与模型本身相比也不起眼，但这是让演示感觉真实的东西。

玩具和工具之间的区别往往不是快乐路径。而是当快乐路径出现问题时，系统能否解释发生了什么。

Gemma 4 感觉最强的地方

当我给 Gemma 4 一个狭窄的任务和清晰的输出契约时，它感觉最强。

效果最好的模式是：

特定上下文 + 狭窄角色 + 约束输出

这比要求模型表现得像通用助手要好。

它对患者提示、护理人员摘要、培训卡片和医生简报有帮助，因为每个任务都有一个有界限的角色。Gemma 4 不需要发明产品流程。它需要在其中一个流程中进行推理。

这是我在未来项目中会重用的部分：不要让模型拥有整个体验。在一个知道下一步做什么的系统中，给它一个精确的职责。

我会告诉其他开发者什么

如果你要用 Gemma 4 构建，我不会从"如何使用最大的模型？"开始。

我会从这些问题开始：

1. 模型应该负责什么？
2. 应用应该验证什么？
3. 什么永远不应该委托给模型？
4. 失败是什么样子的？
5. 模型真正需要什么上下文？
6. 应用其他部分期望什么输出格式？
7. 更小的本地模型是否能创造更好的产品体验？

这些问题比听起来更重要。

Gemma 4 让本地 AI 变得平易近人，但好的本地 AI 仍然需要产品边界。

结语

用 Gemma 4 构建改变了我对本地模型的思考方式。

模型调用是开始，不是终点。

真正的工作是决定模型在系统中的位置：它获得什么上下文，它能输出什么，应用如何检查那个输出，以及用户如何体验结果。

对我来说，Gemma 4 E2B 很强大，因为它让本地推理变得足够实用，可以放进一个真实的护理时刻。

如果王阿姨在家外面感到困惑，目标不是让 AI 听起来 impressive。目标是让系统给出一个平静的提示，通知正确的人，并避免暴露不必要的信息。

这是我希望更多开发者去构建的本地 AI 版本：不是更大的演示，而是更小、更安全的智能片段，放在人们真正需要帮助的地方。

原文链接：https://dev.to...