让模型只描述、让表格做决策：一家宠物健康应用的 LLM 边界设计

把「判断该不该连夜送宠物去急诊」这类生死问题交给大模型，是一种让产品经理睡不踏实的架构。TailStory 是一款由两人团队搭建的宠物健康记录应用，其核心功能允许主人拍摄九类身体部位——粪便、食物、水、耳、眼、皮肤、口腔、伤口、爪子——并返回一个四级紧急度：正常、关注、尽快就医、立即就医。整套系统的设计原则只有一条：模型负责描述，表格负责决定。

为什么不让模型直接决策

团队列出了四条不可妥协的理由。

• 确定性：同一张照片周一和周五应当给出相同结论，模型升级后也应如此。查找表天然具备这一属性，prompt 做不到。
• 可审查：11 行粪便规则，兽医十分钟就能读完并纠正；而一条「通常会升级黑色粪便」的 prompt，其行为藏在权重里，无人能审。
• 可测试：表格与升级器可以写单元测试，模型的判断只能测试「我们拿它的输出做了什么」。
• 失败兜底：模型拒绝、超时或越界时，紧急度仍由表格兜出，最坏情况是缺一段描述，绝不会是缺一条警告。

模型被允许说什么

每个身体部位有独立的结构化输出 schema，且所有 schema 只要求「观察」，不要「判断」。以粪便为例：颜色（封闭枚举）、形态、是否有血、黏液、寄生虫、体积，加一个图像质量标记、一个相关性标记、一句总结。模型永远不会被问紧急度、诊断、病因或建议。系统提示里写了这条规则，但团队不信任提示本身——总结文本会被后置扫描，扫到任何医疗声明就丢弃。扫描器同时检查德语和英语，因为奥地利是他们的首要市场。

主人在拍照前先选部位，模型的角色是「确认」而非「猜测」。若照片与所选部位不符，模型返回 is_relevant: false，应用用自己的话告诉用户「这看起来不像耳朵」，而不是去分析一张地板的照片。

表格决定什么

观察项映射为一个信号码与一条紧急度。以粪便表为例：

• 黑色 / 柏油样 → vet now
• 任何鲜红血迹 → vet soon
• 灰色 / 陶土色 / 白色 → vet soon
• 任何液体粪便 → vet soon
• 绿色且软或稀 → monitor
• 棕色成形 → normal

之所以用四级而不是三级，是因为「本周预约」和「现在打电话」是两种不同行动，合并后那条紧急的就不再被相信。

升级器在表格之后运行，绝不嵌入表格内部：六个月以下或超过物种老年阈值的宠物升一级，因为幼年与老年动物脱水更快、代偿更差；24 小时内出现第三次令人担忧的粪便再升一级；水样便合并鲜血直接升到 vet now（这是唯一一对「合并比任一单条件更糟」的情形）；正常结果永不升级，「我们看了，没事」不该因为是幼犬就变成警告。

让警报保持可信的字段：min_days

系统后半段追踪主人长期记录。每六小时一个 cron 任务为每只宠物构建一份上下文（90 天日志 + 24 个月事件与化验值），再评估一组趋势规则。每条规则包含代码、严重度、一个针对该上下文的纯函数、一个去重窗口，以及一个 min_days 字段。

• weight_drop_fast：≥5% 体重下降且持续 ≥14 天（猫 ≥3%）→ vet soon
• water_up：7 天均值 ≥ 前 21 天均值的 1.8 倍且高于目标 → vet soon
• appetite_none：猫 24 小时 0 千卡记录 → vet now
• symptom_persists：开放症状 ≥5 天 → vet soon
• check_urgent_unactioned：「vet now」照片检查 48 小时内未记录就诊 → vet now

min_days 是规则文件中最重要的字段——它表示一条规则需要多少天历史数据才能触发。昨天才添加的宠物没有基线，仅凭两个数据点就发出「饮水量上升 80%」的警报，正是那种「教会主人忽略下一条警报」的警报。

物种差异也体现在一些看似不一致的地方：appetite_none 对猫是 vet now，对狗则不存在，因为猫一旦停食可能在数天内发展出肝脂沉积症，而狗少一顿通常无碍。

规范里写错了的三件事

• 旧病历的陷阱：「疫苗逾期」「化验值异常」类规则读取的是打印日期，规范最初没给它们设置最低历史天数。结果一个用户在首晚输入两年旧病历后，所有警报一次性涌出。现在每条规则都设有 7 天的地板线，自行提交的照片检查后续跟进除外。
• 沉默不是症状：「食欲下降」「48 小时无粪便记录」曾对每个停止使用应用的主人触发。宠物的日志空白不代表它停食了。两类规则如今都要求先有记录习惯——前 14 天中有 3 天记录过喂食、12 天记录过如厕——才会触发。

这些细节共同指向一个工程上的共识：让 LLM 做它擅长的感知与描述，把决策交给可读、可测、可审的确定性逻辑，是当前生产环境里更稳妥的边界划分。