浏览器开了几十个标签页，想找刚才的文档，先得在一排小图标里猜。
飞书多维表格收了不少反馈，故障、需求和使用咨询混在一起，真正开始处理之前，还要先分一遍类。
GitHub 上看到好项目顺手点 Star，过了两周，只记得"当时收藏过一个能做这个的工具"，名字却忘了。
这三件事单独看都不大，但会反复打断工作。我想做的，就是把这类小判断接进现有平台，让整理结果能被检查、修改和继续使用。
于是有了 Jev Everyday Kit：一个本地工作台，三个面向常用平台的小工具。
这篇文章把界面、使用流程和实现原理放在一起介绍。配图来自实际程序，工作台使用内置离线样例，浏览器扩展使用测试样例；它们展示已经实现的交互，不代表真实账号的推理效果评测。
01｜先把三个产品讲清楚
| 产品 | 面向的日常问题 | 做完后得到什么 |
|---|---|---|
| Tab Sort | 浏览器标签页太多 | 可以审阅和手动调整的原生标签组 |
| Feedback Triage | 反馈混杂、优先级难统一 | 审阅后的分类计划、回填回执与撤销入口 |
| Star Atlas | 收藏的仓库难以再次找到 | 可搜索、可修正、可离线打开的工具目录 |
我把它们放在一个仓库里：三个产品各有独立入口，但共用 Jev 决策适配器、类型定义和一部分工程基础。以后修改模型请求结构时，只需要集中维护一处。
图 1：本地工作台。三个工具的入口和连接设置集中在同一处。
界面采用偏浅的底色和绿色的操作强调，目的是让表格、卡片和状态提示更容易阅读。真正有价值的内容应该是"整理出了什么、哪些需要确认、接下来能做什么"，所以我把这些信息放在结果附近。
02｜为什么这次会用 Jev
我选择的场景都有一个特点：需要从有限候选项里作判断，然后让程序接着执行。
例如，一个页面更接近开发资料还是阅读内容；一条反馈属于故障还是功能建议；一个 GitHub 项目主要是 CLI、应用，还是库和框架。这些问题都可以先定义类别，再把待判断的内容交给模型。
TypeSafe 官方文档把 Jev 定位为结构化决策模型，提供 Choice、Score、Noul 等原语。本项目主要使用 Choice，获取选项、概率分布及 confidence。官方介绍
在代码里，一次分类请求大致可以理解成下面的形式。以下是简化示意，完整请求和错误处理以仓库源码为准：
ts
const request = {
state: { title: '某开发文档', domain: 'docs.example.test' },
questions: {
category: {
type: 'choice',
instructions: '根据固定类别判断页面用途',
criteria: {
development: '软件开发相关资料',
reading: '阅读与学习内容',
other: '信息不足或不属于以上类别'
}
}
}
};这个结构给了我一个明确的工程边界：模型只能建议有限类别，后续代码检查建议是否有效，用户再决定是否应用。
图 2：三个工具的共同处理链。模型输出和平台操作之间保留校验与审阅。
我没有把模型输出直接当成平台指令。即便服务返回的是结构化结果，应用仍然会检查类别是否存在、概率是否在合理范围、字段是否齐全。结构有效之后，还要判断是否值得自动采用。
目前默认门槛是：confidence 和选中项 probability 都至少达到 0.75。这个数是可调整的产品阈值，不意味着项目已经测得 75% 的准确率。真实数据里类别是否均衡、文本是否完整，都需要进一步评估。
03｜Tab Sort：让浏览器标签页各归其位
我想保留浏览器原本的使用习惯
整理标签页时，我不想额外维护一套"保存到某个网页里"的收藏系统。因此 Tab Sort 最后创建的是 Chrome / Edge 的原生标签组，整理后仍然在原来的窗口继续工作。
实际流程是：分析当前窗口，查看分类预览，用搜索找到某些页面，取消不想处理的项目，必要时手动调整类别，最后应用分组。
图 3：真实 Chromium 中的扩展界面，模型响应使用固定测试样例；图中的页面与数值用于验证流程。
我专门保留了人工调整入口。同一个文档页面，在不同人的工作里可能属于"开发"或"学习"。让使用者改一个下拉选项，通常比要求他不断改提示词更直接。
分组之前，先确认页面还是那个页面
标签页会变化。分析完成后，用户可能跳转到另一篇文章，也可能把页面拖到了另一个窗口。如果还沿用旧结果，插件就可能整理错对象。
因此，扩展会保留用于变更检查的页面信息，在应用前再次核对页面和窗口。模型判断与最终执行之间存在时间差，程序必须处理这段时间里发生的变化。
插件默认过滤固定页、已有分组、无痕页和内部页面，也支持排除域名。发送给 TypeSafe 的是候选页面的标题与域名，不包含 URL 路径、查询参数和页面正文；标题本身仍可能包含敏感内容，需要由使用者判断是否适合处理。
做错了，应当能收回来
我加入了撤销、分批进度、停止后继续分析，以及分组前缀、折叠等偏好。标签页多的时候，这些功能比一口气弹出一个"成功"提示更实用。
它不会关闭页面。低把握结果会保留供确认，演示样例也不能直接拿去应用到真实标签页。
04｜Feedback Triage：把反馈分诊做成可审阅的流程
类别和优先级，最好分开判断
"希望支持深色模式"和"所有用户都无法付款"，都可以写在反馈表里，但处理方式显然不同。
这里我把问题拆成两部分：这是什么类型的反馈，以及它有多紧急。类别包含故障反馈、功能需求、账号权限、订单账单、使用咨询等；优先级则有独立判断。
这种拆法能减少类别对优先级的误导。故障不一定都紧急，功能建议也可能有明确的时间约束。实际团队仍应根据自己的业务定义调整标准。
图 4：内置演示反馈。信息不足的"有问题"被留在待确认状态；演示模式禁止真实回填。
工作台支持填写表格地址或标识、配置输入列与四个输出列、检查字段，以及在确认后创建缺少的输出列。生成计划时，只读取和分类，不修改反馈内容。
用户可以筛选待确认项、搜索反馈、修改类别和优先级，也可以取消选择某条记录。确认后才进入回填阶段。
我更在意回填过程有没有依据
真正需要花心思的，是从"有一个建议"走到"已经改了表格"。
计划生成后，反馈文本可能被同事补充，输出列也可能被人工填写。如果回填时只看旧计划，就会把新的信息覆盖掉。
所以每条计划记录都保留输入哈希。执行前重新读取当前记录，检查原始输入和目标字段是否变化。发现冲突时，交给用户处理，而不是为了完成批次强行写入。
图 5：反馈回填的处理顺序。撤销也需要检查当前内容，不能盲目恢复旧值。
成功写入会留下回执，记录原值和本次操作结果。出现部分失败时，用户可以看到哪些成功、哪些冲突、哪些还没有处理，并从已有进度继续。
这里有一个容易被忽视的细节：撤销并不意味着把所有字段一律改回去。如果同事在回填之后已经修改了某条结果，直接恢复旧值又会覆盖他的工作。因此撤销同样需要检查当前值是否仍属于本次操作。
这个实现是逐条校验和保存回执，不是跨整张表的数据库事务。我不会把它宣传成"任何情况都能一键无损回滚"。
05｜Star Atlas：把 Star 变成真正能用的工具箱
收藏只是入口，找得到才算完成
我想解决的并不是"如何多收藏几个项目"，而是在需要一个工具时，能快速找到之前存下来的候选。
Star Atlas 支持读取用户的公开 Star，也可以输入仓库清单。它按用途和产品形态两条线分类：例如一个项目可以属于"部署与运维"，同时是一个"CLI"。
结果可以按名称、简介、topics 和个人备注搜索，也可以按用途、形态、语言及归档状态筛选。模型建议不合适时，直接人工修正并添加备注。
图 6：实际工作台的离线样例。example 下的仓库为虚构演示项目，不代表真实开源仓库。
目前分类依据是公开仓库名称、简介、topics 和语言，不读取源码或 README。因此它适合整理索引，不能替代技术选型时的代码审查。简介写得少的仓库，宁可留在待确认里，也不为它编一份功能清单。
没变的内容，不必每次重新判断
如果一个仓库只是 Star 数从 800 变成 820，它的用途一般没有因此改变。每次都重新调用模型，没有必要。
缓存键会参考模型、分类方案、仓库名称、简介、topics 和语言。分类依据变化时重新判断；只有 Star 数变化时，可以更新展示信息并复用分类。
图 7：缓存的是分类判断，人工修正单独保留。
批次完成后先保存缓存，后续批次失败或取消，也能复用前面的工作。人工修正优先保留，演示模式的数据与真实模型缓存隔离，避免样例影响实际目录。
导出以后，工具箱仍然能用
我提供了 Markdown、JSON 和自包含 HTML 三种导出。Markdown 适合放在文档里，JSON 便于其他程序继续处理，HTML 则可以离线打开并搜索筛选。
HTML 不需要额外服务器，也不依赖外部脚本资源；点击仓库链接时才会前往 GitHub。这一点适合把个人目录留在本机长期使用。
项目还附带 GitHub Action，方便在 Runner 上生成目录和构建产物。但它不会自动修改 Star，不会自动提交、推送目录，也不会把结果写进 GitHub 原生 Star Lists。
06｜本地工作台补上了命令行之外的体验
三个工具里，飞书和 GitHub 都可以通过 CLI 使用。不过如果每次都要记参数、找 JSON、手动检查回执，试用门槛还是有点高。
因此我补了本地工作台，把配置、任务进度、历史、人工调整和下载整合起来。服务只监听 127.0.0.1，启动后打印地址，由使用者自己打开。
工作台中的凭据只保存在当前服务进程内存，不返回原值到前端，也不写入任务历史。服务重启后需要重新配置，或者由本地 .env 提供。.env 文件本身仍需要用户妥善保管。
这里的"本地优先"需要说明白：界面、任务历史和导出保存在本机，真实分类仍然会请求 TypeSafe，平台数据的读取与回填也会访问对应官方服务。它不是本地运行 Jev 模型。
页面刷新不会终止后台任务。服务意外退出后，未完成任务显示为中断，不会悄悄重新开始付费推理。这些状态处理，让工具更接近日常可以反复使用的产品。
07｜工程上，我怎样判断它做到哪一步了
这次我把测试分成两层。
第一层是单元和集成测试：检查 Jev 响应结构、错误处理、概率阈值、分页、缓存失效、幂等、冲突、撤销和工作台会话边界。
第二层是端到端测试：使用独立无头 Chromium 操作真实工作台，加载构建后的 Chrome 扩展，验证原生分组、手动调整、撤销、取消继续，以及导出与历史恢复。
2026 年 9 月 23 日重新运行完整验证，34 项单元/集成测试和 9 项端到端测试全部通过，共 43 项。分发包也做了逐文件校验并生成 SHA-256 校验值。
这能证明已覆盖的程序行为正常，但不能代替真实模型效果评估。当前尚未使用真实 TypeSafe Key 测量准确率和延迟；飞书链路使用契约样例验证，仍需真实租户授权验收；GitHub 真实读取也需要在可用账号和网络下完成联调。
我会把这两种进展分开记录：软件流程是否正常，以及模型在真实样本里是否有帮助。后者应该继续观察自动分类覆盖率、人工纠正比例、任务总耗时和实际费用，而不是只看页面上有没有一个绿色成功提示。
08｜怎么开始体验
三个工具与工作台已集中放在 GitHub：
需要 Node.js 22 或更新版本。从源码启动：
bash
git clone https://github.com/xiaom8413-afk/jev-everyday-kit.git
cd jev-everyday-kit
npm ci
npm run build
node dist/jev.mjs serve访问终端打印的本机地址，先使用离线样例。确认流程符合需要后，再按各平台说明配置凭据。
仓库包含源码、安装指南、示例配置、验证记录、问题模板和 MIT 许可证。目前是可本地安装、自行部署的工具套件，还没有上架 Chrome 商店、飞书应用市场或 GitHub Marketplace。
写在最后
做完这三个工具，我更确定了一点：一个小的分类能力，也值得认真设计完整的使用过程。
从候选项如何定义，到结果能否修改，再到数据变化后怎么办、任务中断后能不能继续，这些决定了工具能不能融入日常工作。
我接下来更想做的是拿真实、经过授权的样本验证分类标准，记录人工修正，逐步调整阈值。让工具在几个明确场景里稳定地帮上忙，比不断增加入口更有意义。
如果你也经常被标签页、反馈表和收藏夹打断，可以先试试离线样例，再决定要不要把它接进自己的工作流程。
个人原创，转载请注明作者及原文出处。