所有技术链路都 PASS，为什么产品价值仍然可能没有成立？

JiaJi 把生活通知整理成可核对的事项卡片。做它的过程中，我有过一种很容易理解的进展感：iOS 有了 OCR 和草稿，Gateway 能抽取，模型能返回结果，小程序也逐渐接上了真实请求。技术链路一个个变绿，产品似乎应该越来越接近成立。

后来我开始把两个问题分开：这条路径能不能运行，以及人是否真的需要这条路径。前者有具体技术进展，后者还缺真实使用观察。标题里的“所有技术链路都 PASS”是我想检验的推断，并不是在宣布 JiaJi 所有端、所有场景都已完整验收。

先把已经知道的技术范围放准

历史记录中，正式服务已经部署，容器健康，普通 HTTPS 客户端能通过鉴权发起真实模型抽取。后来在微信开发者工具里，也观察到真实登录、短期会话与抽取后出现可编辑卡片。这比代码存在或模拟接口成功更进一步。

但 iOS 图片到卡片的完整生产设备验收、微信双平台真机体验，仍没有同等完整的记录。OCR 实现和测试不能被写成所有真实截图都可靠；健康检查没有调用模型，也不能替代授权请求。把这些都缩成一个“端到端 PASS”，反而会丢掉进展的真实位置。

项目文档中还保留过小程序会话接口返回 404 的历史阻挡，后来的部署记录已经观察到它解除。写这篇时，我不能只挑一份文档当成当前全貌。历史失败值得保留，但它不应该覆盖更新的真实观察；新的局部成功也不能填满其它端的空白。

卡片出现以后，用户究竟得到了什么

最值得我重新思考的，是“确认”这个动作。当前实现的确认只改变页面内状态，没有把事项保存成以后能找回的对象，也没有安排实际提醒。若用户以为确认意味着已经记下，界面上的完成感就会超过系统真正提供的能力。

可是，发现这个缺口也不意味着应该马上建设持久化、提醒和家庭共享。有些人可能只想从长通知里快速提炼金额与日期，再复制到自己的工具；对这类一次性整理，保存未必是首要需要。另一些人想要的是以后不忘做事，一张离开页面就找不到的卡片则可能根本没达到目的。

两种需求会指向不同产品。只看抽取成功，无法替我选择。技术方案可以把保存实现出来，却不能证明用户原本需要的就是一个新事项系统。

准确的结果，也可能没有节省人的工作

为了使用它，用户需要打开入口、整理或粘贴信息，等待结果，再逐字段核对。金额、时间和行动状态一旦出错，影响可能比文案不够自然大。因此人可能还要回原通知重新读一遍。若最终依然要自己完整整理，AI 只是增加了一段来回。

我把这看作信任成本：为了判断结果能否使用，人额外花了多少注意力。它没有在 JiaJi 里被正式测量，所以目前只是需要验证的判断视角，不能写成“用户认为核对太麻烦”的访谈结论。

使用频率也是未知。家庭通知可能很多，也可能只是偶尔出现一个值得整理的事项。频率低时，用户能不能记得这个入口？已有的备忘录、日历、聊天收藏或直接手动记录，是不是足够好？这些替代方式不需要我在产品里重新实现一遍，但需要放进真实任务的比较。

一次输入只有一张卡，也是产品边界

当前契约每次返回一个事项。若一条通知同时要求缴费和体检，系统可能无法完整表达两个独立行动。结构合法、卡片漂亮，并不能保证用户没有漏事。是否频繁出现多事项、遗漏能否被察觉、后果多大，都会改变下一步优先级。

我现在不会只因“数组看起来更完整”就立即修改契约。可以先明确当前边界，再用真实、经同意且脱敏的通知观察问题。若高后果漏项已经出现，即使频率不高也要认真处理；若大多数使用只是一次性单事项，复杂的生命周期系统可能还不是最值得增加的部分。

我现在更想验证哪件事

下一轮有价值的观察，应该从用户原来的做法开始，到他真正完成核对或找到结果为止。是否比原做法省事，哪些字段需要改，确认以后期待发生什么，隔一段时间是否愿意再用，比“这次接口耗时多少”更接近产品问题。

这些目前是验证计划。仓库没有给出一组目标用户的完成时间、重复使用率或付费意愿，我也不会为文章补出数字。先观察用户是不是需要一次性提炼，再决定最小保存是否必要；若真实问题是抽取本身不可信，就应先修核心，而不是用更多功能掩盖。

Technical Feasibility != Product Value。 对我来说，这句话最具体的含义是：已经解决的技术困难，不能替尚未回答的用户问题投票。可运行让试用成为可能，真实使用才有机会改变产品判断。

JiaJi 目前给我的，是一条已经取得局部现实证据的实现路径，以及一组更清楚的未知。我还不能说产品价值已成立，也不能说它没有价值。这个结论仍需要更多 Dogfood；即使最后发现一个更简单的工具就够用，之前的工程进展也不需要被改写成商业成功才能有学习价值。