如果你和大多数开发者一样电脑上至少躺着三个笔记软件、两个待办清单和一堆临时文件那么你一定经历过这种场景正在写代码时突然想到一个需求点切到笔记软件准备记录结果被启动速度、新建文档、起标题、选文件夹这一连串操作打断索性放弃或者是在会议上快速记下的几个关键词三天后打开却完全不认识只能凭上下文猜测。这就是忙碌大脑最真实的困境——想法来得很快消失得更快而传统笔记工具的结构化要求恰恰成了捕获灵感的最大阻力。Jotchi 是近期在 Hacker News 上展示的一个轻量级项目定位是 a smart scratchpad for the busy brain翻译过来就是为忙碌大脑准备的智能随手记。从项目定位来看它瞄准的不是又一个大而全的知识管理平台而是捕获想法这个最前端、最容易被忽略的环节。本文不打算只停留在介绍层面我想结合这个产品思路和读者一起拆解一个真正好用的智能暂存工具应该具备哪些核心能力底层数据模型怎么设计分类与检索可以怎么做以及如果你也想开发一个类似 Jotchi 的小工具从零到一的技术路径是什么。文章会从产品理念、核心概念、架构设计、代码实现、数据同步、常见问题到最佳实践逐层展开。无论你是单纯对 Jotchi 这个项目感兴趣还是想自己实现一个类似的想法捕获工具这篇文章都能提供可以参考的落地方案。1. 智能暂存工具到底要解决什么问题先明确一个判断智能暂存工具的核心价值不是记录而是零阻力捕获和事后自动整理。传统笔记工具的问题在于它们把记录动作设计得太重了。新建笔记要选择笔记本、填写标题、选择标签、甚至调整排版这套流程对于写长文是合理的但对于捕获一个稍纵即逝的想法来说完全是负担。认知科学里有个概念叫认知负荷每一次额外的点击和选择都在消耗我们宝贵的注意力资源而灵感恰恰是对注意力极其敏感的东西。Jotchi 这类工具想要解决的就是这个矛盾。它用一个极轻量的输入入口替代传统的完整笔记流程让用户可以像发一条即时消息一样记录想法然后再通过算法和规则自动完成分类、打标签、提取关键词这些原本需要手工完成的工作。换句话说把整理的压力从捕获时刻转移到空闲时段。从材料看Jotchi 的定位有三个关键特征值得关注第一它是 smart 的。说明它一定包含了某种自动化的智能化处理比如自动分类、自动标签、语义检索甚至可能是基于大模型的文本理解。第二它强调 scratchpad 而不是 notes。scratchpad 在英文语境里指随手写画用的便签本暗示内容的初始状态是草稿级的、非结构化的、低成本的。这与传统笔记追求结构化、长期沉淀的理念完全不同。第三它面向 busy brain。目标用户是思维活跃、信息密集的开发者、设计师、产品经理这类人群最大的痛点是想法量太大但整理时间太少。所以我们评价一个智能暂存工具是否优秀不应该看它的功能列表有多长而应该看两个指标从产生想法到完成记录的耗时有多短以及事后重新找到这条记录的成本有多低。这两个指标也是我们后续做技术设计时需要时刻对照的准则。2. 核心概念从零开始理解 Jotchi 的运作逻辑在深入代码之前有必要先把几个核心概念讲清楚。如果你之前没有接触过智能暂存工具这个品类下面的概念对比会产生更直观的理解。2.1 先导捕获与事后整理传统笔记的工作流程是捕获 - 整理 - 归档而且整理发生在捕获之前因为你必须先决定记在哪里、用什么标签然后才能把内容写进去。智能暂存工具把流程颠倒了过来捕获 - 暂存 - 自动整理 - 按需检索。整理这个动作被延后甚至被自动化这是它与传统笔记最本质的区别。2.2 非结构化输入与结构化存储用户的原始输入可能是半句话、几个关键词、一段代码片段甚至是语音和图片。但在存储层我们需要把这些内容逐步结构化为可检索的数据。这里面的关键设计决策是既要保留原始文本的原貌也要在其上生成结构化的元数据。元数据包括时间、来源、标签、分类、关联性等这些字段是后续智能检索和自动整理的基础。2.3 自动标签与自动分类自动标签是对文本内容的主题识别。传统的实现方式可以基于规则和关键词匹配比如出现bug、报错这样的词就自动标记为开发问题。现代实现方式则用文本分类模型或者大模型进行语义分析效果更贴近人工判断。自动分类则是更高一层的抽象它把标签聚合成几个大类比如工作事项、学习笔记、灵感点子、待办任务。2.4 快速检索与语义搜索草稿纸上的内容因为缺乏结构检索是最大的难题。传统的字符串匹配对拼写错误和语义相近的内容无能为力。现代暂存工具通常支持两个层次的检索基础的全文本关键词搜索以及基于向量的语义搜索。语义搜索可以处理怎么解决数据库连接超时找到MySQL 数据库连接失败排查这样语义相关但字面不匹配的记录。维度传统笔记工具智能暂存工具捕获成本高新建、起标题、选目录低一次输入即可完成整理时机捕获前手工整理捕获后自动整理数据形态结构化文档为主非结构化文本 自动元数据检索方式目录浏览 关键词搜索全文搜索 语义搜索使用心理有记录压力担心记不好无压力先记下来再说理解了这些核心概念再去设计 Jotchi 这样的应用思路就清晰多了。接下来的章节我会从架构和技术选型的角度说明一个智能暂存工具的工程实现路径。3. 架构设计与技术选型从架构层面看一个智能暂存工具可以拆成四个核心模块捕获入口、存储引擎、智能处理管线、检索与展示。下面我逐个说明。3.1 捕获入口层捕获入口是整个应用的灵魂。设计目标是让任何形式的输入能在三秒内完成。常见的捕获方式包括桌面端全局快捷键唤起输入框。浏览器扩展选中文字一键捕获。命令行工具在终端里直接输入适用于开发者场景。Markdown 文件所在目录的自动监听类似于文件系统的暂存目录。对于 Jotchi 这种定位的工具捕获入口的设计优先级远高于其他模块。如果你在做自己的版本第一步不是写分类算法而是把输入入口做到尽可能顺手。3.2 存储引擎层存储层需要同时保存原始内容和结构化元数据推荐使用 SQLite 加 JSON 字段的组合。SQLite 零配置、单文件、易于备份适合个人工具的场景。文本内容可以用一个 Text 字段存储元数据和标签可以用 JSON 字段这样兼顾了查询灵活性和写入简单性。如果未来数据量很大可以考虑迁移到 PostgreSQL但起步阶段 SQLite 完全够用。为什么不用 MongoDB 或者 Elasticsearch从材料看Jotchi 是一个轻量级项目大概率是个人开发者或者小团队的作品追求的是快速迭代。SQLite 的另一个好处是你可以把数据库文件放在用户的笔记目录下天然支持通过网盘同步降低数据同步的复杂度。3.3 智能处理管线这是smart的关键所在。处理管线在捕获完成之后异步执行大致分为四个步骤文本清洗去除多余空格、格式化编码、提取时间信息。标签提取基于规则或模型提取关键词和主题标签。自动分类将笔记归入预定义的类别。语义向量化为后续语义搜索生成 embedding 向量。在工程实现上这四步应该设计为可插拔的管线每一步都可以独立替换。比如一开始用规则实现标签提取后面想换成大模型只需要替换管线中的一个处理器不影响其他模块。3.4 检索与展示层检索层需要实现三种查询方式全文搜索、标签筛选、语义搜索。展示层可以采用时间线流的形式类似即时通讯软件的聊天记录按时间倒序排列同时对标签和分类进行颜色标识。这种展示方式比传统的笔记本列表更符合暂存的心理模型。3.5 技术选型建议模块推荐方案备选方案说明桌面端框架Electron、Tauri命令行工具Tauri 体积更小适合轻量工具存储SQLitePostgreSQL起步阶段 SQLite 足够捕获入口全局快捷键 系统托盘浏览器扩展、CLI可以多端并存智能处理规则引擎 大模型 API本地 ONNX 模型兼顾成本与效果搜索SQLite FTS5Elasticsearch、MeilisearchFTS5 零额外依赖从趋势来看桌面端用 Tauri 或 Electron 都是常见选择如果你偏向 Rust 技术栈就选 Tauri如果前端团队以 Node.js 为主就选 Electron。这部分没有绝对标准按团队实力来定即可。4. 环境准备与项目初始化考虑到实际情况我以 TypeScript Node.js 作为示例语言数据存储使用 SQLite读者可以在自己的机器上跑通整套流程。版本方面以实际安装为准不要强行固定版本号以下示例在 Node.js 18 以上的环境中均可运行。4.1 初始化项目mkdir jotchi-demo cd jotchi-demo npm init -y npm install better-sqlite3 typescript ts-node types/node npx tsc --init这里使用better-sqlite3的原因很简单它的 API 是同步的写起来非常直接对于个人工具项目来说同步接口带来的性能损耗可以忽略不计还能避免 Promise 回调把代码弄得很乱。如果你的环境安装better-sqlite3时报错通常是缺少编译工具链导致的。Node.js 原生模块需要本机编译Windows 用户需要安装 Visual Studio Build ToolsmacOS 用户需要安装 Xcode Command Line Tools。4.2 创建数据表结构-- schema.sql CREATE TABLE IF NOT EXISTS notes ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, created_at TEXT NOT NULL DEFAULT (datetime(now)), updated_at TEXT NOT NULL DEFAULT (datetime(now)), meta TEXT NOT NULL DEFAULT {} ); CREATE VIRTUAL TABLE IF NOT EXISTS notes_fts USING fts5( content, contentnotes, content_rowidid );这个表结构里content存原始文本meta存 JSON 元数据notes_fts是 SQLite 内置的全文搜索虚表用于快速关键词检索。FTS5 是 SQLite 自带的全文索引模块不需要额外安装性能对个人笔记量级完全足够。4.3 初始化数据库连接// src/db.ts import Database from better-sqlite3; import fs from fs; const DB_PATH process.env.JOTCHI_DB_PATH || ./jotchi.db; const schema fs.readFileSync(./schema.sql, utf-8); const db new Database(DB_PATH); db.exec(schema); export default db;这里做了一件重要的事把数据库路径暴露为环境变量方便不同场景下切换数据存储位置。比如测试环境可以用:memory:或者临时文件生产环境指向实际的数据目录。5. 核心功能拆分与代码实现本节会逐步实现一个最小可用的 Jotchi 核心模块包括捕获输入、保存笔记、智能标签生成、全文检索。这里只展示核心代码保证可以直接跑通实际产品还需要补充 UI 层和错误处理。5.1 核心笔记模型// src/models/note.ts export interface NoteMeta { tags: string[]; category: string; source: string; importance: number; } export interface Note { id: number; content: string; created_at: string; updated_at: string; meta: NoteMeta; } export function createEmptyMeta(): NoteMeta { return { tags: [], category: uncategorized, source: manual, importance: 0, }; }把元数据分离成独立接口有几个好处第一数据结构清晰前端渲染时可以按字段直接绑定第二后续如果要接大模型生成标签只需要更新tags字段不需要改表结构第三将原始内容与元数据分开存储万一智能处理出错内容本身不会受影响。5.2 捕获与保存逻辑// src/services/noteService.ts import db from ../db; import { Note, NoteMeta, createEmptyMeta } from ../models/note; export function capture(content: string, source manual): Note { const meta: NoteMeta createEmptyMeta(); meta.source source; const result db .prepare( INSERT INTO notes (content, meta) VALUES (?, ?) RETURNING * ) .get(content, JSON.stringify(meta)) as any; // 同步全文索引 db.prepare( INSERT INTO notes_fts (rowid, content) VALUES (?, ?) ).run(result.id, content); // 异步触发智能处理可以替换为消息队列 process.nextTick(() { autoTag(result.id, content); }); return { id: result.id, content: result.content, created_at: result.created_at, updated_at: result.updated_at, meta: JSON.parse(result.meta), }; }这里的RETURNING *语法是 SQLite 3.35 以上版本才支持的如果你用的版本较老需要改成先插入再查询。插入笔记后同步写入 FTS 索引可以保证全文搜索不会遗漏新记录。process.nextTick仅用于演示真实场景建议用异步任务队列来执行智能处理管线。5.3 基于规则的自动标签生成在没有大模型 API 的场景下基于规则的关键词匹配是性价比最高的方案。下面实现一个支持中英文关键词的简单标签提取器同时演示如何自动判断笔记的分类。// src/services/autoTag.ts import db from ../db; const RULES: Array{ tag: string; category: string; keywords: string[] } [ { tag: 开发问题, category: development, keywords: [bug, debug, 报错, 异常, 重构, 代码], }, { tag: 灵感创意, category: idea, keywords: [灵感, 创意, idea, 设想, maybe, 或许], }, { tag: 待办事项, category: todo, keywords: [待办, todo, 记得, 别忘了, schedule, 计划], }, { tag: 会议记录, category: meeting, keywords: [会议, meeting, 同步, 对齐, 结论], }, ]; export function autoTag(noteId: number, content: string): void { const lower content.toLowerCase(); const tags: string[] []; let category uncategorized; let maxScore 0; for (const rule of RULES) { let score 0; for (const keyword of rule.keywords) { if (lower.includes(keyword.toLowerCase())) { score; } } if (score maxScore) { maxScore score; category rule.category; } if (score 0) { tags.push(rule.tag); } } // 更新元数据 const row db.prepare(SELECT meta FROM notes WHERE id ?).get(noteId) as any; const meta JSON.parse(row.meta); meta.tags Array.from(new Set([...meta.tags, ...tags])); meta.category category; db.prepare(UPDATE notes SET meta ?, updated_at datetime(now) WHERE id ?).run( JSON.stringify(meta), noteId ); }这个实现的优点是代码清晰、可扩展。如果你想把标签提取换成 OpenAI 或者本地模型只需要修改autoTag函数的内部逻辑不需要改动上层调用。实际项目里可以把这些规则配置到 YAML 或 JSON 文件中让用户自己维护关键词库。5.4 全文检索实现// src/services/search.ts import db from ../db; import { Note } from ../models/note; export function searchNotes(query: string): Note[] { // 第一步在全文索引中查 const rows db .prepare( SELECT n.id, n.content, n.created_at, n.updated_at, n.meta FROM notes_fts f JOIN notes n ON n.id f.rowid WHERE notes_fts MATCH ? ) .all(query) as any[]; // 第二步额外做一次 LIKE 匹配兼容部分匹配场景 const likeRows db .prepare( SELECT id, content, created_at, updated_at, meta FROM notes WHERE content LIKE ? AND id NOT IN (SELECT rowid FROM notes_fts WHERE notes_fts MATCH ?) ) .all(%${query}%, query) as any[]; return [...rows, ...likeRows].map((row) ({ ...row, meta: JSON.parse(row.meta), })); }这里做了一个重要的设计决策FTS5 使用 MATCH 语法进行分词匹配对英文效果很好但对中文的分词效果取决于分词器。SQLite 内置的 FTS5 默认分词器处理中文时是按单字切分的所以搜索精确性有限。为解决这个问题我在第二步增加了一个 LIKE 查询兜底把 FTS 没匹配到的内容再过滤一遍。如果你对中文搜索要求较高有两个优化方向一是使用simple分词器加上自定义的 jieba 分词插件二是在应用层先对内容做分词再把分词结果写入一个自定义的分词表。从小工具的定位来看LIKE 兜底已经可以满足大部分场景。5.5 测试主流程写一个简单的入口文件来验证整个流程。// src/index.ts import { capture } from ./services/noteService; import { searchNotes } from ./services/search; // 模拟捕获 const note1 capture(今天遇到了一个 MySQL 连接超时的 bug需要排查。); console.log(第一次捕获完成:, note1.id); const note2 capture(灵感做一个自动整理浏览器书签的工具); console.log(第二次捕获完成:, note2.id); const note3 capture(明天记得给团队的代码评审准备材料); console.log(第三次捕获完成:, note3.id); // 等待异步标签处理完成 setTimeout(() { // 搜索测试 const results searchNotes(bug); console.log(搜索 bug 结果:); for (const r of results) { console.log( [${r.id}] ${r.content} 标签: ${r.meta.tags.join(,)}); } // 查看所有笔记 const all searchNotes(); console.log(所有笔记:); for (const r of all) { console.log( [${r.id}] ${r.content} 分类: ${r.meta.category}); } }, 100);运行方式npx ts-node src/index.ts预期输出大致如下第一次捕获完成: 1 第二次捕获完成: 2 第三次捕获完成: 3 搜索 bug 结果: [1] 今天遇到了一个 MySQL 连接超时的 bug需要排查。 标签: 开发问题 所有笔记: [1] ... 分类: development [2] ... 分类: idea [3] ... 分类: todo如果搜索不到结果或者标签没有生成优先检查两个地方一是数据库文件是否存在并且表结构正确二是process.nextTick里的异步逻辑是否执行可以在autoTag函数开头加一行日志确认。6. 智能分类与检索的进阶设计上面的代码实现了一个基础版本但如果 Jotchi 宣称自己是smart只靠基于规则的标签匹配显然不够。这里我分享一下智能化程度更高的进阶思路。6.1 从规则匹配到语义模型规则匹配能解决词面重复的问题但解决不了同义替换的问题。比如用户记录这个接口响应太慢了需要优化如果关键词库中没有优化两个字这条记录就不会被打上性能优化的标签。要想解决这个问题有两条路线第一条路线是使用预训练文本分类模型。像 BERT 系列这种模型可以直接把文本编码成向量然后通过一个线性分类头输出类别。对于个人项目可以直接用现成的多语言模型服务比如调用云厂商的自然语言处理 API。这条路线的优势是效果好缺点是可能产生 API 费用而且有隐私顾虑。第二条路线是使用大语言模型进行结构化抽取。把笔记文本发送给大模型让它返回 JSON 格式的标签、分类和摘要。这种方式效果最好但延迟和成本都更高适合在用户空闲时异步处理不适合在捕获瞬间同步调用。6.2 结合 embedding 做语义搜索如果引入了向量化语义搜索就水到渠成了。基本思路是在智能处理管线里给每条笔记生成一个向量存入向量数据库检索时先把查询句子也向量化然后计算余弦相似度。SQLite 可以通过扩展支持向量检索也可以引入单独的向量数据库比如 sqlite-vss 或者 Qdrant。// 伪代码语义搜索的流程 async function semanticSearch(query: string, topK 10) { const queryVector await embedText(query); return await vectorStore.search(queryVector, topK); }这个能力在真实场景中非常实用。比如你搜索数据库连接失败语义搜索应该能找到今天 MySQL 报 cant connect 错误这条笔记即使两条记录没有任何共同字面词。6.3 基于时间衰减的提醒智能暂存工具还应该具备一个能力让过期的内容自动沉底让近期内容浮上来。给每条笔记算一个新鲜度权重按时间衰减和最近访问频率加权这样可以避免老笔记永远排在搜索结果最前面。6.4 设计取舍功能规则实现模型实现产品建议标签提取关键词匹配文本分类先用规则后续平滑迁移到模型分类得分最高类别多分类模型规则兜底 模型增强搜索FTS LIKE向量语义检索默认全文搜索高级里放语义搜索摘要截取片段大模型生成可选功能避免增加延迟这部分想表达的核心观点是智能不是一上来就上大模型而是在产品迭代中逐步升级。先跑通基础版本等数据积累起来了再引入模型比一开始就设计得特别复杂要稳妥得多。7. 数据同步与多端方案智能暂存工具的另一个重要场景是多端使用。开发者的忙碌大脑既可能在电脑前冒出想法也可能在手机上、会议中随时产生灵感。如果数据不能同步工具的价值会大幅缩水。7.1 基于文件同步的轻量方案个人工具最省事的方案是利用云盘同步数据库文件。SQLite 单文件的特性让它非常适合直接放在 Dropbox、坚果云、OneDrive 这类目录下。优点是零开发成本缺点是同步引擎在文件被占用时可能产生冲突所以应用要设计成只在启动时打开数据库避免长期占用文件句柄。7.2 自建后端同步如果产品需要面向多人使用自建后端就不可避免。这里给出一个最小可用的同步设计思路客户端每次写操作都生成一个单调递增的sync_id。服务端保存每个设备的last_sync_id客户端拉取增量数据。冲突处理采用后写覆盖策略元数据和内容字段单独比较避免整行覆盖丢失标签。7.3 本地优先架构我实际更推荐的是本地优先架构即本地数据库是唯一真相源云端只是备份和中转。这种架构与笔记类工具非常契合离线可用、隐私好、同步冲突少。Jotchi 从定位上看很可能就是这种设计因为对于私人的、碎片化的想法用户对隐私的敏感度远高于对协作的需求。// 同步模块伪代码 export async function syncWithServer() { const localChanges db.prepare( SELECT * FROM notes WHERE sync_status pending ).all(); await api.pushNotes(localChanges); const serverChanges await api.pullNotes(); for (const note of serverChanges) { upsertNote(note); } }8. 常见问题与排查方法开发过程中有一些高频问题我整理成表格方便读者对照排查。问题现象可能原因排查方式解决方案better-sqlite3安装失败缺少原生编译工具链查看安装日志中的 error 信息安装对应平台的 Build Tools输入中文搜索不到结果FTS5 默认分词器对中文支持有限测试SELECT * FROM notes_fts WHERE notes_fts MATCH 中文使用 LIKE 兜底或集成中文分词器标签没有自动生成异步任务未执行或规则未匹配在autoTag开头加日志确认调用检查关键词库是否覆盖了输入内容多端同步后数据冲突没有维护同步 ID 和冲突策略查看本地与云端updated_at差异实现基于字段的合并策略数据库文件越用越大历史版本未清理检查数据库中 text 字段大小和索引数量定期 VACUUM清理不再使用的索引启动时数据库被锁定多个进程同时打开 SQLite查看SQLITE_BUSY错误信息使用 WAL 模式并设置busy_timeout排查问题的通用思路是先确认数据有没有写进去再确认逻辑有没有执行最后确认查询条件是否命中。用二分法缩小范围通常很快就能定位问题。9. 最佳实践与工程建议结合自己在相关工具开发中的经验和 Jotchi 这类产品的常见做法最后分享几条工程层面的建议。9.1 把捕获路径做到极致简单在设计交互时坚持一个原则任何操作链路的步骤数超过三就要重新设计。全局快捷键唤起输入框、自动聚焦、回车保存、关闭窗口这四步已经是极限。不要在这个流程里插入选择分类填写标题之类的步骤捕获的第一原则是快后续的整理交给自动化。9.2 数据结构预留弹性上面的代码里meta字段使用 JSON 格式存储元数据这是一个非常重要的设计决策。相比为 tags、category、source 各建一列JSON 字段最大的优势是扩展性。今天加一个importance字段不需要迁移表结构明天加一个recurring字段也不需要动数据库。SQLite 对 JSON 字段的查询支持也比较完善还可以为其中的字段建立表达式索引。9.3 智能处理与主流程解耦智能处理通常是整个系统中最不稳定、最容易超时的部分。无论是调用大模型 API 还是本地运行模型都可能出现延迟甚至不可用。所以必须在架构上把智能处理与主流程解耦。捕获动作应该立即成功智能处理异步执行失败也不影响保存。实际项目中可以用工作队列、定时任务或者事件流来实现不要在前端请求里同步等待模型结果。9.4 隐私与数据安全暂存工具记录的是最原始、最真实的想法有些内容可能非常私密。设计产品时必须考虑加密方案本地数据库可以加密云端备份必须加密传输如果有云端服务应该支持端到端加密。这部分不是可选项而是信任基础。9.5 充分考虑搜索体验搜索是暂存工具的核心交互之一。建议在设计时把搜索框放在最显眼的位置并支持快捷键唤起。搜索结果应该突出展示命中片段、标签和时间让用户快速判断是否是自己需要的内容。语义搜索可以作为独立的增强入口不要把它和普通搜索混合展示避免造成困惑。9.6 定期回顾机制自动整理只能解决标签和分类但真正让暂存工具有长期价值的是用户的定期回顾。建议在应用中内置一个回顾模式随机或者按时间展示一周内的重点笔记帮助用户把碎片想法转变成行动计划。这个功能不复杂但对产品的长期粘性非常重要。10. 总结与后续学习方向回到最初的问题Jotchi 这类智能暂存工具为什么值得关注因为它重新定义了笔记工具的交互模型把整理从用户的负担中剥离出来交给了算法和自动化。当你不再需要为记哪里怎么记操心记录本身会变得轻松且自然这恰恰是忙碌大脑最需要的产品体验。从动手实践的角度本文的示例代码已经构成了一个最小可用的暂存工具骨架支持捕获、保存、自动标签、全文搜索。你可以在此基础上继续扩展可以选择的方向包括接入大模型 API 优化标签和摘要生成、引入向量数据库增强语义检索、开发基于 Tauri 的桌面客户端、增加浏览器扩展捕获入口。每个方向都有足够的深度可以深挖而且组合起来就是一款完整的产品。最后提醒一句小工具的开发过程中最大的风险不是技术实现而是过度设计。抓住零阻力捕获和低成本检索这两个核心体验其余功能都可以放到后续迭代中慢慢补。先把基础版本跑通用起来再去迭代智能能力这才是做一个成功工具的最短路径。希望这篇文章对你有帮助。如果你正在考虑开发类似的工具或者已经在使用 Jotchi欢迎在评论区分享你的体验和想法。