这个18KB的小工具，把500+药物冲突查了个底朝天

503条药物相互作用数据，12种安第斯草药，7道选择题。一个前端开发者用纯HTML文件搭了个诊断系统，没调用任何框架，Lighthouse跑分却拿了满分。

这事发生在Botánica Andina项目里。团队原本只做草药百科，用户却追着问："我到底该吃哪种？"市面上的保健品测试要么导向销售页面，要么把禁忌症埋在脚注里。开发者决定自己造个不一样的。

向量匹配：把"适合"变成可计算的问题

每株草药被编码成六维向量：能量、免疫、消化、压力、认知、激素。玛卡（maca）的能量值0.9、激素值0.8；猫爪草（uña de gato）的免疫值0.9，但压力维度只有0.1。

用户回答7道生活方式题后，系统生成"需求向量"。两个向量做点积，得分最高的三种草药进入候选池。这种推荐逻辑和音乐软件的"猜你喜欢"同源，但数据集小得多——总共12种植物，全部手写进18KB的JSON。

开发者解释选择纯原生JS的原因：「考虑过React，但7道题的静态数据不需要Redux、Context甚至useState。有时候最好的框架就是没有框架。」

安全层：比推荐算法更严格的淘汰机制

真正耗工时的是冲突检测模块。用户输入正在服用的药物后，系统遍历503条 documented interactions（已记录相互作用）。匹配到严重冲突时，该草药直接从结果页删除，而非仅标注警告。

代码里有一段硬逻辑：如果`match.severity`达到特定阈值，植物ID连进入排序的资格都没有。开发者见过太多网站把风险提示做成灰色小字，「 bury warnings in footnotes（把警告埋在脚注里）」——这是他的原话。

交互数据库的每条记录附带PubMed ID，用户能直跳文献原文。这种设计在医疗类工具里罕见，多数产品怕露怯，宁可模糊处理信源。

命名陷阱：同一称呼，两种植物

安第斯草药的跨区域命名是隐形雷区。"Uña de gato"在秘鲁指猫爪草（Uncaria tomentosa），到了墨西哥变成含羞草（Mimosa pudica）。成分、功效、禁忌完全不同，混用可能出事。

团队花了额外精力做名称标准化，给每个植物条目绑定拉丁学名和地域别名。这个细节没出现在用户界面里，但决定了推荐系统的可靠性底线。

最终交付物是个单HTML文件，零依赖、零构建步骤。总重量18KB，其中还嵌着全部植物数据。作为对比，一个空壳React项目的node_modules通常超过200MB。

Lighthouse四项评分全满：性能、可访问性、最佳实践、SEO。在4G网络下，页面加载时间以毫秒计。

工具背后的产品判断

这个案例戳中一个行业惯性：团队习惯用技术栈的复杂度证明工作量，却忽略用户实际感知。503条数据+12种植物+7道题，用Excel都能跑通的逻辑，硬要上微服务架构的比比皆是。

开发者反其道而行，把状态管理压缩到两行代码：`let currentQuestion = 0; let answers = {};`。没有 immutable update，没有派生状态，没有重新渲染优化——因为根本不需要。

这种克制来自具体场景的判断。如果是实时协作的千人问卷，原生JS会崩；但个人健康诊断，并发量天然受限，极端简洁反而降低维护成本。

药物冲突检测的严格性则来自另一面：健康类工具的信任门槛极高，一次错误推荐可能毁掉用户身体。把警告做轻是商业选择，做重是伦理选择。

目前该工具免费开放，数据持续更新。团队下一步计划扩展至更多传统医学体系，但核心逻辑不变——向量匹配算推荐，硬规则保安全，轻量技术栈保体验。

最后一个细节：结果页会追问用户"推荐是否准确"，反馈直接入库用于校准权重。没有用户画像分析，没有留存率优化，只是朴素地收集"这个建议对你有用吗"。

如果你正在服用免疫抑制剂或抗凝血药物，这个测试会直接屏蔽猫爪草——哪怕你的"需求向量"和它匹配度最高。算法在这种情况下选择沉默，你觉得这是保守还是负责？