一个周二的下午，他删掉了所有依赖大模型生成冲煮方案的代码。因为他发现，真实咖啡知识不在训练数据里，而在烘焙商的指南里，在社区笔记里，在上周二某个咖啡师的一次手冲记录里。

开发者 yuens1002 在提交 Hermes Agent 挑战的作品中写道：“我在一个此前从未用过的系统上，只用了三天就建成了它。”他指的“它”是一个叫 brew-guide 的工具。没有账号注册，无需安装客户端，用户选择咖啡产地、烘焙度和冲煮方式，系统返回的不是一份统计平均的“1:16 粉水比、93°C、四分钟”，而是一份可溯源的社区共识对象。

打开网易新闻 查看精彩图片

这套机制正对一个老问题：稀有产地的咖啡，AI 训练样本极薄，给出的常常是技术上看没毛病、实操上毫无个性的建议。brew-guide 的做法是，不靠大模型生成答案，而是用确定性算法计算社区真实记录。

推荐路径分成了明显的两条。正方路线是社区数据驱动的确定性引擎：每当你请求一个配方，computeBestBrew() 函数会抓取多达 50 条最近的冲煮日志，按产地、方式、烘焙度、品种和研磨度打分，再叠加时间衰减权重和信源信任加权，取前五名用加权平均或加权众数合成出一组参数。这一步耗时不足 100 毫秒，完全可复现、可审计。更关键的是，返回结果自带置信度等级——高、中、低——如果某个产地的日志太少，系统会诚实地说“数据稀疏”，然后退回该冲煮方式的默认值，而不是捏造一个看似合理的数字。

反方路线是当前多数 AI 工具的做法：直接让模型生成冲煮指南。典型场景是问“埃塞俄比亚浅烘手冲推荐”，模型输出 15 克粉、250 毫升水、92°C、冲煮 2 分半。这来自统计平均，有时甚至只是语料中最常见的值。好处是覆盖面广，任何产地都能得到答案；坏处是当语料稀少时，统计平均就成了伪共识，把“最常见”包装成“最正确”。

两条路线的分界在于知识来源。brew-guide 的每一条参数都能追溯到具体的社区记录，你可以看到这些共识是从哪几次真实冲煮中来的。这种溯源性让它的推荐成为一种“可质疑的知识对象”，而不是一个需要无条件信任的黑箱输出。

从实际使用看，brew-guide 为咖啡饮用者走了一条极低门槛的路：网页端无账号、无设置，选好参数即得共识指南和分步技法，甚至还包括闷蒸时间、注水阶段和搅拌方式。开发者则为 MCP 兼容客户端提供了一行接入：https://brew-guide-production.up.railway.app/mcp，并暴露了五个工具——获取冲煮方式、推荐、记录冲煮日志、搜索记录和对比冲煮。整套 API 通过流式 HTTP 传输，公开免认证。

目前引擎弱环在投票权重：用户可以对推荐给出有用／无用的表态，追踪哪条推荐被实际用于冲煮，这部分反馈数据在 computeBestBrew 中的数学权重尚未接入。但项目作者坦承这是设计已完成、代码待补的下一项提交，这本身也是一种诚实的解释。

拆解这件事，不同阵营争论的核心从来不是“要不要用社区数据”，而是“先用社区数据还是先用模型填补空白”。brew-guide 的选择对资源稀疏领域有启发：在无法奢求大样本的前提下，允许系统坦承无知，并让可追溯的记录而非光滑的输出成为答案的主体，可能是比追求永不沉默的应答更聪明的诚实。

整个项目的代码托管在 GitHub（yuens1002/brew-guide），完全透明。那个下午删掉生成式调用的程序员，只是在把一句老话做成产品：真正的好配方，藏在人的经验里，而不是任何模型的平均里。