北京
周末要不要出门，这个问题听起来很小，但真到做决定的时候，大多数人靠的是感觉。看一眼窗外，刷一下天气App，然后赌一把。OpenTrips想做的事，是把这一把赌注变成一个可以查的数字。
它来自Hacktoberfest开源AI挑战赛第一周，主题叫"Touch Grass"。团队名HONEYBEE，两个人：Ashwin Temkar和Kiranraj Chintada。一个人做前端，一个人做数据、模型和后端服务。
你输入一个地点、两个日期，再加一句关于自己的描述。比如"新手，膝盖不好，预算3000卢比，想去山里"。然后你会拿到三样东西：一个出发、谨慎或等待的判定，附带模型在屏幕上标出的实测准确率；一份逐日户外计划和打包清单；一张地图，上面有附近记录过的滑坡点、降雨预报网格和住宿位置。
那个0.899是怎么来的
先说清楚这个数字的含义。0.899是地理切分下的结果，不是随便挑出来的好看数字。
训练数据用的是NASA全球滑坡目录，加上Open Meteo的历史降雨记录。原始导出有11033起事件，分布在142个国家。团队做了几层筛选：只保留定位精度在10公里以内的事件，印度境内的786起全部保留，其余国家采样了960起。每起事件都配上截至事发当天的1天、3天、7天和14天降雨量。
非事件样本是随机的地点和日期，走同一套降雨处理流程，另外补了496个印度非事件样本，目的是让留出的印度测试集里两类样本都存在。最终数据集3935行，文件直接提交在仓库里，不用评审凭信任接受结论。
评估用了两种切分方式。时间切分是每类里较早的行做训练，最后20%做测试。地理切分是把印度以外的所有国家拿来训练，只用印度的事件和非事件做测试。屏幕上那个0.899，来自地理切分。
团队自己说了一句很关键的话：精确率和召回率是空白的，因为他们没有算。这句话放在这里，比任何漂亮数字都值钱。
10次里0比8，差在哪
计划生成用的是Qwen3 8B，在Tinker上做了微调。测试方式是拿10个训练中从未见过的请求来跑。
基础模型：10次里对0次。微调后的模型：10次里对8次。
这个对比很直白，但要注意它测的是"计划生成"这件事，不是风险判定。风险判定走的是另一条路：TabPFN在API启动时拟合，请求进来时拉取实时预报降雨，加上经纬度，输出一个滑坡类事件的概率。概率高于0.6判"等待"，高于0.3判"谨慎"，其余判"出发"。
计划生成之后还有一道规则检查器，对照你的预算和能力做通过或不通过的校验。这一步是防止模型写出一个膝盖不好的人走不了的路线。
两个服务，零付费密钥
架构不复杂。Kiran做的是用户能碰到的Next.js应用，Ashwin做的是数据、TabPFN、Tinker微调和FastAPI服务。中间站着Open Meteo和OpenStreetMap，两个都不需要付费密钥。
流程是这样：地点在OpenStreetMap上解析成坐标，坐标和日期发给风险接口，风险接口从Open Meteo取降雨窗口，返回风险、判定和0.899这个准确率。然后这个判定连同你写的那句话一起发给计划模型，返回逐日安排、打包清单、警告和约束检查结果。最后生成一个可以重新打开的链接，计划被缓存下来，没信号也能看。
有一个实际体验上的坑要提前说：API跑在Render免费实例上，第一次请求可能要等大约半分钟才能唤醒。
它不是行程规划器
这一点团队强调得很清楚。OpenTrips不是酒店行程规划器。它给出的日程是步道、观景点和短途步行，按能力匹配。地图上的住宿只是背景信息，不是产品本身。
它的目标用户是任何计划散步、进山一日游或露营的人，只要那个地方有预报。产品的终点是让你合上笔记本电脑，而不是让你继续研究。
这个定位其实挺聪明。周末出门这件事，卡住人的从来不是信息不够，是信息太散——天气在
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
