這是一份提交給Gemma 4挑戰的參賽作品：用Gemma 4
所構建的 我所構建的內容
Companion是一個安靜的每日檢查工具，用於幫助管理第二型糖尿病和高血压的人們——他們幾乎都是這樣的（約有70%的糖尿病患者同時患有高血壓）。
問題：全球有 5.37 億人患有糖尿病。大多數人每三到六個月看一次醫生。在兩次看診之間，他們會在筆記本或應用程式中記錄數字——而他們沒有辦法知道這些數字代表什麼意思一起星期二 215 mg/dL 壞嗎？血壓趨勢正在上升嗎？錯過一次氨氯地平的劑量真的有關係嗎？
夥伴像溫柔的護士般，讀取他們一週的讀取記錄。它：
- 先標記危險區域 — 任何今天需要撥電話給醫生的讀取記錄
- 識別模式 — "星期二和星期六的米飯都讓血糖超過215。值得注意。"
- 建議嘗試一個小小的改變。 — 不是泛泛的建議，而是基於他們的數據
- 撰寫的臨床摘要，他們可以在下次就醫時交給醫生——乾淨、事實，30秒內可閱讀
每個讀數都保留在用戶的瀏覽器中。沒有後端，沒有數據庫，沒有賬戶.
演示
🎥影片導覽：
🌐 實時示範： https://companion-sooty.vercel.app
流程很簡單：
- 貼上你的閱讀週期（或載入範例)
- 點擊"分析我的週期"
- 查看危險旗標、趨勢、一個建議的實驗，以及醫生總結
- 下載 PDF 以供下次就診使用
代码
📦 GitHub:
伴手禮
為管理糖尿病和高血压的人士提供一個安靜的日常檢查。貼上你這週的讀數，獲得關於正常範圍、需要關注的事項以及一個小建議的簡潔語言摘要——還有一份乾淨的 PDF 總結，可帶到你的下一次就醫約診.
為了DEV.to Gemma 4 挑戰，2026年5月.
為何存在
全世界有5.37億人患有糖尿病。他們中的大多數每三到六個月看一次醫生。之間，他們在筆記本或應用程式中記錄數字，卻不知道這些數字合起來代表什麼。
伴侶就是那個中間角色。它讀取一週的血糖和血壓數據，就像一位和藹的護士那樣——尋找危險區域，發現模式，建議嘗試一個特定的方法，並寫一份醫生能在30秒內掃描的臨床總結.
它的運作方式
它是一個…
整個應用程式是一個HTML檔案。沒有框架，沒有建構步驟，沒有npm install。唯一的相依性是jsPDF（透過CDN載入），用於醫生摘要下載。應用程式的「智慧」幾乎完全存在於系統提示中——我調整的次數比我想承認的還多.
// The model call is dead simple:
const response = await fetch('https://openrouter.ai/api/v1/chat/completions', {
method: 'POST',
headers: { 'Authorization': `Bearer ${key}`, 'Content-Type': 'application/json' },
body: JSON.stringify({
model: 'google/gemma-4-26b-a4b-it:free',
messages: [
{ role: 'system', content: SYSTEM_PROMPT },
{ role: 'user', content: `Here are my readings for the past 7 days:\n\n${readings}` }
],
temperature: 0.3,
max_tokens: 1500
})
});
系統提示是產品的棧位。它定義了參考範圍、輸出模式、語氣規則（「像一個友善的護士而不是教科書般交談」），以及明確的安全限制（永不替換醫療建議，始終包含醫生總結）。
我如何使用Gemma 4
我選擇了Gemma 4 26B MoE (4B主動) — 專家混合變體 — 而模型選擇對此產品來說至關重要.
為何選擇 MoE 而不是 31B Dense: 伴侶需要感覺快速反應。人們不會使用一個需要12秒才回應的每日登記工具。MoE給我接近密集模型的推理品質，每個token僅有4B參數被激活，這意味著在OpenRouter的免費套餐上具有低延遲。對於每日使用的工具來說，延遲預算比最後幾點的基準準確性更重要.
為何選擇MoE而非E4B： 這個推理任務確實很難。模型必須將星期二的血糖波動與星期二記錄的米雞餐連接起來，然後注意到星期六咖哩中出現的相同模式。它必須理解星期二遺漏的氨氯地平劑量與血壓漸漸升高之間的關聯。它必須同時衡量五個不同的參考範圍，並決定什麼值得標記、提及或忽略。E4B (4B 參數) 在這裡開始傳遞信號。MoE 的專家路由處理跨領域推理——飲食、藥物依從性、一天中的時間模式——而沒有增加活動參數計數。
為何選擇Gemma 4（而非Gemini Flash或GPT-4o-mini）： Apache 2.0 授權條款對健康應用程式的重要性遠超人們的認知。這個架構是刻意設計為透過 LiteRT-LM 或 Ollama，在本地推論路徑穩定後可完全替換為本地 Gemma 4 E4B 部署。對於嚴格要求隱私的市場——德國醫療保健、歐盟 GDPR 規範環境、任何無法將病患數據傳送至美國雲端的情況——這條遷移路徑是區分「有趣示範」與「實際產品」的關鍵。今天的托管呼叫是為部署便利性。模型選擇則是為了未來的隱私保證。
Gemma 4 帶來了我兩年前無法達成的突破： 推論。早期的開放式模型會給我摘要（「你這週的血糖從 128 到 268，平均 144」），而 Gemma 4 則給我一個深刻的洞見。 ("你的兩次最高讀數都跟著吃了很多米飯。值得注意。") 這個轉變 — 從總結到洞見 — 才是區分一個記錄應用程式和一個伴侶的地方.
我刪除的內容
我大約花了七小時來建立這個，我刪除了很多非必要的功能：
- ❌ 多模式照片上傳 (會讓用戶拍攝他們的血糖計螢幕) — 保留給 v2
- ❌ 多週的趨勢圖 — 醫生 PDF 就夠了
- ❌ 手機應用程式 — 網頁在手機瀏覽器上運作良好
- ❌ 用戶帳戶 — 所有內容都存放在瀏覽器中，這就是隱私故事
我保留的是在醫生拜訪之間實際能幫助人的最小東西。這就是整個主張.
責任的註記
我並非醫生。這個應用程式對此有明確說明 — 每個螢幕、每份 PDF，都包含「這不是醫療建議」的字樣。提示中的參考範圍來自標準的 ADA 和 AHA 指南，但模型仍然可能出錯。這個產品的基礎是建立在人類醫生參與的假設上。Companion 的任務是協助這個對話發生 — 而不是取代它.
請親自試試看
如果你有朋友或家人正在管理糖尿病或高血壓，請他們將一週的讀數記錄到 Companion 中，看看簡報是否有告訴他們任何他們不知道的事。那是我最關心的測試。
感謝 DEV 組織和 Google 組織了這個挑戰——特別感謝揭發了開放重量故事。這個模型這麼強大使用 Apache 2.0，對醫療保健來說確實是大事。
獨自為Gemma 4挑戰賽建造，2026年5月。