Pawlife

项目起点是一次常见的遗漏：连续数天饮水量明显上升未被察觉， 直到其他症状将其暴露。

随后试用多款宠物记录类应用并连续记录两个月，得到一个明确结论—— 问题不在记录，而在记录之后。

多数宠物应用止于「记录」，但记录本身不解决问题。关键在于记录之后能否被读懂。

数据不会自动形成判断。这中间的一步，目前是空缺的。

• 宠物不会说话，所有异常都靠人观察，而人一定会漏。这不是不负责，而是人的注意力本不为连续监测设计。
• 现有 App 的记录维度是按人类医疗表单设计的。体重、体温、用药——这些是医生的语言，不是每天在家的人的语言。日常观察其实是「今天不太对劲」这种模糊的东西。
• 有用的信号在长期趋势里，但没人会自己画趋势图。单看今天的饮水量没有意义，看三个月的斜率才有意义。
• 存在一个残酷的数据量临界点。连续记录到大约 60 天，才开始出现可辨识的模式。而绝大多数人在两周内就放弃了。

最后一条是整个项目的关键约束。如果解决不了它，前面三条都没有意义。

把重心从「记录」移到「解读」。具体是三个决定：

• 记录的摩擦必须降到三秒以内，或者干脆不由人来完成。照片、语音、一句含糊的话，都应该是合法的输入。
• 系统要主动产出结论，而不是等人来查。人不会主动分析数据，人只会在疑惑的时候来找答案——而疑惑的时刻很短，抓不住就没了。
• 前两周必须产生回报。且不能采用打卡机制——方向是让 AI 在最初两天给出正面观察，使记录行为本身立即获得正反馈。

换句话说：这个产品的工作不是帮人记录，是帮人观察。 记录只是中间产物。

目前有四个部分，其中第三、四块是正在做的重点。

随手记

拍一张照片、说一句话、或者选一个事件类型，三种输入等价。系统负责把它们整理成结构化的事件。

趋势视图

不显示单日数值，默认显示滚动趋势。用户可以问「和上个月比怎么样」，而不是去看一个今天的数字。

异常提示

只在趋势发生持续性偏移时提示，不做单点告警。宁可漏报，不要制造噪音——这是被人类医生的建议直接影响的决定。

就诊摘要

就诊前生成一页摘要：近三个月的关键趋势、用药记录与异常时间点。这是目前用户反馈价值最高的一块。

前端以 uni-app 一套代码覆盖小程序端；后端为 FastAPI； Agent 编排使用 LangGraph——「从含糊输入推导结构化事件」天然是多步任务， 且每一步都需要能被单独评估。

数据层是 PostgreSQL 兼容的托管实例，另外开了向量检索——用来做「相似历史事件」的召回，比如「上次它这样是什么时候」。

三个难点

• 事件定义的粒度。太细会淹没用户，太粗会丢掉模式。最后按「人真正会观察到的最小单位」来定，而不是按医学分类。
• AI 输出的可信边界。该领域不能给建议，只能给观察。但「观察」与「建议」的语言界线非常模糊，为此定义了一整套约束，并在评估集中将越界列为一级错误。
• 趋势算法。短周期波动会淹没真实变化。现在用的是带衰减的加权基线，参数还在调。

评测方面：为「事件抽取」与「摘要生成」各建一个小型评估集，包含人工标注正例与刻意构造的反例。 该实践后来也影响了通用模型评测的方法判断，详见手记。

• 「降低摩擦」存在一个下限。摩擦降到零时，信息也随之归零。v0.2 的结论是：好的设计不是让人做更少的事，而是让做的每件事更值钱。
• AI 在这个场景里的价值不是生成，是结构化。把一个模糊的人类输入变成可计算的东西——这比写一段漂亮的文案有价值得多，也难得多。
• 越界不是靠提示词防的。「不给建议」这条约束，最终是靠评估集和一级错误的定义守住的，不是靠一句 system prompt。
• 长期数据产品的真正门槛是时间。这不是技术问题，是耐心问题，也没有捷径。

Sprouting验证中 更新于 2026 年 9 月

v0.2 已在少量真实家庭中运行一个多月，v0.3 的事件流正在开发。当前重点：

• 事件抽取的准确率还不够稳定，尤其是语音输入里的口语表达。
• 「就诊摘要」是反馈最好的一块，正在把它提到更显眼的位置。
• 趋势算法对老年宠物的数据还不友好——它们的正常波动本来就更大。
• 是否做成公开产品尚未决定。首要标准是它必须在真实饲养场景中有效。