如果你也经常在开会、写代码、回消息之间来回切换多少会遇到过这种瞬间脑子里闪过一个“回去要查一下某个接口的用法”手上却在处理线上告警等忙完再想已经想不起来了。我过去最常做的补救动作是打开微信把这句话发给文件传输助手。结果是这句话混在各种链接、图片、语音里过几天想找它得先完成一次考古式搜索。后来我换过几个方案在 IDE 里放一个临时文件、在电脑桌面新建一枚便签、往看板工具里丢卡片。它们各有各的用处但都缺一种东西——一个专门承接“还没想清楚怎么归类但需要马上记下来”的信息的地方。看到 Jotchi 这个出现在 Hacker News 上的 Show HN 项目时我多看了几眼因为它的标题就很直白a smart scratchpad for the busy brain一个给忙碌大脑用的智能草稿本。这类项目的价值通常不是功能数量而是它能不能把“从念头出现到完成记录”之间的那几秒钟压缩到极致。这篇博客我想围绕 Jotchi 这种“智能 scratchpad”的定位聊一聊这类工具到底解决了什么问题、怎么把它放进自己的工作流以及长期使用会遇到哪些边界和坑。1. 为什么“忙碌大脑”需要一块真正的草稿区域1.1 不是笔记不够好而是“开始记录”的阻力太大很多人一上来就会问我都有 Notion、飞书、Obsidian 了为什么还需要一个 scratchpad这个疑问忽略了一个关键差异那种结构完整的笔记工具是为“组织信息”服务的不是为“捕捉信息”服务的。当你想把一条想法记到笔记软件里通常要经过这些步骤打开应用、选择一个页面或新建一个页面、起标题、选文件夹或标签、把内容贴进去、保存。这套流程每一步都很轻但加起来就重了。更重要的是它要求你在记录的那一刻就回答“这条信息属于哪里、该叫什么”而忙碌的时候大脑恰恰最没有余力回答这种问题。Jotchi 想做的事从标题来看就是把这里的“先组织再记录”改成“先记录再组织”。它不要求你决定这条内容最终去哪也不需要你为一条草稿先搭一个知识库结构。你要做的只是把它倒出来剩下的交给后面的整理。这个顺序看似简单但决定了记录这个动作能不能成为一种本能。从认知负荷的角度也可以理解这件事。人的工作记忆容量是很有限的当一个临时念头冒出来时如果不把它放到一个外部载体里它就会持续占用一部分注意力干扰正在做的事情。scratchpad 的价值不是帮你写得更漂亮而是把你的工作记忆“卸载”到纸面上让大脑腾出空间处理眼前的问题。1.2 scratchpad 和笔记软件、任务管理工具的本质区别要理解 Jotchi 这类工具最好先把它放进一个连续谱系里看。下表是我在工作流里常用的分类方式工具类型记录代价组织时机典型用途传统便签很低几乎不组织临时提醒、简单想法scratchpad很低延迟组织、智能辅助灵感、待办、参考信息的临时中转笔记软件中等记录时或记录后手动组织知识沉淀、长期文档任务管理工具较高需要明确项目、时间、优先级可执行的任务管理我并不是说 Jotchi 一定已经把这套分类做到了什么程度因为从 Show HN 的标题里看不到具体交互。但“smart scratchpad”这个定位本身就是要填补中间那条很少有人做好的位置既能快速捕获又不放弃后续整理的智能感。传统便签的问题在于“记录是可以很快但取出来时很慢”。一张贴在桌面上的黄色便签如果不手动处理过几天就会变成一张写了几句话、但再也不看的纸片。笔记软件和任务管理工具则把组织成本前移导致很多人因为“还没想好怎么归类”而干脆不记。scratchpad 站在中间它让信息先流入再想办法帮你减少积压。1.3 Jotchi 这个命名里的产品取向Jotchi 不是一个正式的中文产品名但从英文构词能看出一点取向。“Jot” 在英文里的意思是“匆匆记下”这是记录动作最原始、最轻盈的版本而后缀 “chi” 可能是项目名的一部分也可能暗合中文“气/能量”的概念。当然这更多是猜测不必过度解读。更值得揣摩的是 “smart” 这个词。如果它只是一个快速便签完全可以说 “a scratchpad for the busy brain”。加上 smart意味着产品希望在记录之外提供额外的整理能力也许是自动识别日期和找人名也许是自动生成标签也许是按相似度把相关记录串起来。我觉得真正需要的智能不是展示设计上的花哨而是能回答“这条记录可能属于哪一类、应该送去哪里”。这种辅助如果能做到位会让整个 scratchpad 的出口变得很自然如果做不到位就会变成一个让人改来改去的负担。这也是我后来评估这类工具时最看重的维度之一。2. 从“捕获”到“整理”智能草稿本应该跑通的闭环2.1 捕获把输入动作压缩到最小一个 scratchpad 的成败大半取决于它把“输入一条信息”这件事压缩到什么程度。理想的情况下从念头出现到内容进到草稿箱应该像使用全局搜索框那样顺滑呼出一个输入窗口打字回车关闭窗口。Jotchi 是否已经做到这种程度我不能代替用户下结论。但如果你平时在多个编辑器、终端、浏览器页面之间切换对“记录动作”的感知会非常明显。我自己的经验是快捷键唤起 默认焦点在输入框 回车保存是一套最低限度的顺滑流程。如果再加入语音输入和桌面小组件覆盖场景会更多但核心仍然是“减少停留时间”。这里有一个容易被忽略的小问题记录界面一旦追求美观就会出现大量磁贴、画板、日程展示反而让输入框藏在角落里。对 scratchpad 来说最好每次打开都只看到一个输入框或最大程度突出输入框。记录不是一个需要沉浸式体验的场景它需要的是“一发即收”。2.2 延迟整理让智能发生在合适的时间“延迟整理”听起来像是不整理其实不是。它指的是把“捕获”和“处理”这两个动作从时间上分开。捕获时你只需要保证内容没丢处理时你再判断它是一条待办、一段灵感还是一条永远不需要再看的碎片。Jotchi 这样的智能草稿本最有价值的地方就是在这个“处理”阶段提供帮助。它可以在你记录时不打扰你等条目静置之后再通过规则或模型给内容补上时间、类别、关键词等结构。例如一条 “周六下午两点和张三聊 API 设计”可以被自动识别出日期、人物和主题方便你在清空列表时快速决定要不要把它转成日历事件。但要注意自动整理只适合做“半成品”不适合做“全自动决定”。原因很现实语言里有太多歧义。同样一句话在开会场景里是待办在私人场景里可能只是随手记下的灵感。算法可以给出分类建议但最终归类权应该保留在人手里。一个可以手动修正建议的智能工具比一个替你删掉的智能工具更可信。2.3 输出草稿本必须能“把消息送到该去的地方”如果一条草稿只在 scratchpad 里存在时间长了它就会变成信息垃圾。scratchpad 应当是一个中转站而不是终点站。所以它真正的价值除了接收之外还在于能否高效输出。最常见的输出是这么几种待办事项输出到任务管理工具比如 Trello、Things、Todoist参考资料输出到笔记软件比如 Obsidian、Notion、Evernote灵感类内容输出到专门的项目草稿有明确时间的内容输出到日历或提醒应用。如果 Jotchi 想走得长远最好的状态是支持一键分享到其他应用或者至少支持 Markdown 导入导出让数据不被锁在一个单一的工具里。因为很少有人愿意把毕生笔记全部迁移到另一个新工具上更多人需要的是一个能跟现有工具和平共处的“临时车站”。我见过不少效率工具死掉不是因为功能少而是因为数据出口太少。使用者一旦意识到整理成本太高就会停止使用。对 scratchpad 来说出口通畅比入口好看更重要。3. 怎么判断一个智能 scratchpad 值不值得长期用3.1 记录速度从想法出现到你真正写下来中间隔几层判断一个 scratchpad 是否合格可以先用一个最原始的标准从想法出现到最后落下需要几秒、几个动作。如果一条记录需要经历打开软件、点击新建、输入标题、选择笔记本、设置标签、保存那么它就不适合当 scratchpad。它更像是正式笔记工具。对比之下理想路径是按一个全局快捷键、直接打字、按回车关闭。你可以根据自己的习惯设计一个隐形测试。比如今天下午你收到一条“下周记得给客户发合同”如果工具能在五秒内让你完成输入并且之后能通过搜索找出来那么它在“捕获速度”这一项上就算合格。如果中途会卡在“该放哪个文件夹”这一步它就还没完全理解 scratchpad 的使命。3.2 检索和呈现三天后你还能不能找到它记录只是一半。回到使用现场往往是过了几天才需要翻看某条记录。这时候考验的是检索能力我能不能通过一个关键词、一个日期范围甚至一个模糊印象找到它。一个好的 scratchpad应该默认按时间倒序排列保证最新内容在最前面。在此基础上可以支持全文搜索和标签筛选。如果连全文搜索都做不到就会被淹没在碎片里最终失去价值。搜索不一定要很复杂但必须能容忍错误拼写和长短不一的记忆比如你只记得“周六聊 API”翻出来的结果要能包含那条完整内容。另外呈现方式也需要关注。如果每条记录都显示得非常冗长没有突出关键词和时间你扫一眼列表的成本就会升高。理想的列表应该是一眼能看到“这是什么、大概什么时候记录的、有没有被处理过。”处理状态也是一种重要信息能帮你判断草稿箱里还有多少没消化。3.3 整理机制是自动替你做决定还是在旁边提醒你很多号称“智能”的工具最容易犯的错是替用户做决定。比如把一条内容自动归入工作项目自动加上优先级甚至自动移动到一个用户找不到的地方。短期看省事长期看会让用户失去掌控感。我更欣赏的整理机制是“建议 确认”。系统可以判断出“这条内容可能是一个待办”然后以卡片形式问你要不要转到日历你说不要它就继续躺在草稿里。这种交互看起来很轻微但对于一个以“快速捕获”为核心的工具来说信任感比自动化更重要。Jotchi 作为新项目如果它能做到“画龙点睛”而非“全盘代劳”就更容易赢得用户。因为 scratchpad 的使用者本来就对“组织信息”有自己的习惯他们缺少的不是一个机器管家而是一个足够聪明又不越界的助手。3.4 数据边界能不能导入导出、数据到底储存在哪里长期使用任何工具都要提前想清楚数据边界。这个听起来不性感但很要命。假设你已经往一个 scratchpad 里存了几百条灵感某一天工具停止维护、服务器下线或者同步逻辑出了问题你怎么办所以在决定是否长期使用之前至少要确认几件事是否支持 Markdown 或纯文本导出是否有本地存储或离线访问能力同步逻辑是否透明会不会出现覆盖账号体系和登录机制是否简单隐私政策是否清晰会不会拿记录内容去做训练和广告。这四个问题不一定要产品强到全部满足但至少不能给不出答案。对一个“接住灵感”的工具来说数据安全性就是它最后的底线。如果记下来的东西随时可能丢所谓的“智能”就会变成空中楼阁。4. 把 Jotchi 放进个人工作流一套最小可验证流程4.1 先定义什么该进 scratchpad什么不该进很多人在刚开始使用一个新工具时会把所有东西都往里倒最后草稿箱变成一个比垃圾邮件还混乱的收件箱。为了避免这种情况可以提前划一条边界。我一般会把这几类内容放进 scratchpad临时冒出来的灵感还没想清楚去哪聊天过程中看到的链接、书名、产品名未来某个时刻才需要用到的参考信息需要稍后决策的选项一些只有一句话的待办暂时不想打断当前思路。而不适合放进 scratchpad 的是那些已经非常明确的紧急任务和需要立即执行的动作。它们应该直接进入任务管理工具或日历不需要在草稿箱里绕一圈。如果在草稿箱里看到 “下午三点线上评审” 这样的内容最合理的动作是立刻把它移到日历然后再清空这条草稿。4.2 每天固定两次清空而不是收藏后永不处理scratchpad 只有在“清空”这件事上养成习惯才能避免变成数字垃圾场。我这里说的清空不是指删除而是指对每条内容做一个动作移动、归类、标记或确认丢弃。我建议每天安排两次固定的清空时间每次十分钟以内。第一次可以放在午休前把上午积累的、还没处理的信息快速过一遍第二次放在下班前把下午新增的草稿归档。之所以分两次是为了防止内容在草稿箱里堆积到下午后疲惫状态下更不想处理。清空时判断顺序可以参考这个它现在还有用吗没用就删除或归档。它有明确的时间吗有就移到日历并设置提醒。它能变成待办事项吗能就移到任务管理工具。它值得日后重读吗值得就移到笔记软件并加标签。它还不确定但不想丢保留在草稿箱标记一个“maybe”标签。这套判断顺序能让每次清空都有结果而不是把所有内容从屏幕上方滚到下方。4.3 标签不要一开始就建数量控制在五个以内很多人拿到一个新的效率工具第一件事就是设计一套复杂的标签体系。这个冲动可以理解但对 scratchpad 来说过早建立标签体系弊大于利。因为记录时你还在快速流动的状态里如果每增加一条都要思考该打什么标签又会回归到旧问题。比较好的做法是前期不建标签先用一个 flat 列表记录。等使用两周之后再根据实际内容反推标签。如果非要提前准备我推荐五个以内例如action、idea、read、waiting、maybe。action代表要做事idea代表灵感read代表待阅读内容waiting代表需要等待别人反馈maybe代表可能有用但现在不想处理。这个结构非常简单整理时不会卡住。如果 Jotchi 的智能能辅助自动打标签也应该从这种粗粒度标签开始而不是一上来就给每条内容定义几十个类别。粗粒度好处是容错率高就算打错也能通过搜索找回来。4.4 用周复盘清掉“可能有用”的积压即使每天清空还是会有些内容被贴上maybe标签后一直留在草稿箱里。这时候需要一周一次更彻底的复盘。我一般在周五下午做这件事把过去七天里没有被处理、也没有被移动的条目全部看一遍。周复盘的标准很简单如果一件东西放了一个星期你依然没有想对它采取任何行动那它大概率已经失效了。这时候可以归档到历史记录或者直接删除。不要因为“舍不得”而无限期保留。真正重要的事情会在许多天里反复出现如果它没有第二次出现说明它在你的生活里并没有那么重要。通过这套“日清空 周复盘”流程草稿箱才能一直保持低水位记录也才能继续保持低阻力。这个流程不依赖于具体工具Jotchi 只是作为一个良好的承接者存在于前端。5. 从尝鲜到长期使用最容易忽略的坑和排查路径5.1 “智能”会错所有自动动作都要给人留确认入口智能识别一定会错。不需要怀疑概率只是早晚问题。比如你把 “周六下午见老张” 记录进去算法可能把“见老张”识别成“件老张”或者把“周六”识别成过去日期。如果你让算法自动创建一个日历事件很可能日历上会出现一条错的时间、错的地点。因此使用任何智能草稿本都要先确认它的自动动作是可逆的、可编辑的。一旦出现“建议创建任务”这个能力最好在创建之前让你预览。如果产品设计里没有预览环节我的建议是把它当成参考而不是当成可信的日历同步源。5.2 草稿本不是收纳箱它必须有一个出口很多工具死就死在用户用成了“收藏夹”。看到一篇好文章先丢进去刷到一个好点子先丢进去想到一句话又丢进去。三个月后里面装了几百条内容看起来很有安全感实际上一条都没有被真正消化。scratchpad 的正确用法是“短暂停留 定期出口”。它可以接收很多东西但必须有意识地流向别处。如果你开始觉得它是一个个人仓库那就已经偏离了它的设计意图。真正的仓库是笔记软件、资料库、任务看板而不是一个输入框。如果 Jotchi 能帮助用户建立这种“出口意识”比如每周生成一个未处理列表或者提醒“你已经有 20 条内容超过七天没有处理”我会觉得这是一个很有价值的设计。因为它不是在替你把内容整理得更漂亮而是在帮你在信息洪流里保持清醒。5.3 当工具开始变复杂它就背叛了“草稿”的本质这是几乎所有效率工具都会经历的演变成问题。一开始是一个简单的输入框后来加了看板、日历、团队共享、自动化流程、项目模板最后变成另一个 Notion 或 Jira。对做产品的人来说这种演进可能自然而自然但对“草稿本”这个赛道来说复杂化就是自杀。scratchpad 的核心是快。快意味着界面轻、逻辑简单、没有太多二次确认。每增加一个功能都会消耗用户的注意力即使它不常用。一个使用者真正希望看到的画面是输入框、时间线、搜索框、设置入口。这样就够了。所以我评估 Jotchi 这类产品时不太关心它未来会不会加入 AI 对话或者项目管理只关心它是否守住了“小”。“小”不是功能少而是没有让次要功能喧宾夺主。5.4 一条可套用的排查链路使用 scratchpad 期间你可能会遇到几种问题。这里给一条通用的排查链路适合用在 Jotchi 或者其他类似工具上。现象确认是记录丢失、保存卡顿、搜索不到还是智能标签不准输入检查确认输入法、键盘布局、文字格式、链接是否正确如果是语音输入是不是周围环境噪音导致的识别误差。环境检查查看是否有网络同步问题、登录状态是否过期、本地缓存是否已满、系统是否阻止了后台刷新。参数检查如果支持标签和过滤器检查关键词拼写、标签是否关联、搜索范围是不是只包含当前目录。工具边界确认确认这个产品的同步能力是否支持跨设备自动整理规则是否只针对英文或某种日期格式有些功能是否还在测试阶段。这套链路看起来常识但大多数人遇到“丢失”时会直接归咎于工具而忽略了输入法或网络延迟也可能造成误导。先记录证据、再分层排查比反复卸载重装更能找到症结。6. 如果我来设计一个智能草稿本我会把这三件事放在优先位置6.1 入口做成全局流程而不是打开一个应用如果有一天我要做一个类似 Jotchi 的工具第一件事不是做花哨的桌面端界面而是把入口做到“无处不在”。在浏览器里可以呼出在编辑器里可以呼出甚至在手机的通知栏里可以一键发起语音记录。全局入口的意义不是方便而是“你根本不需要意识到自己在用一个应用”。你只是在世界上快速记录一下。窗口不抢焦点不打扰当前任务记录完成后自动隐藏连多余手势都不用。很多工具失败不是因为记录能力不够强而是因为入口太深打开应用本身变成了一道坎。6.2 智能整理只给出建议不自动执行第二件优先事项是让 AI 整理永远停留在建议层。例如当我记录 “周六下午两点和张三聊 API 设计” 时系统可以弹出一条提示“检测到时间、人物、主题是否创建日历事件” 我点头它才去创建我忽略它保留原样。让用户保留最终决定权能带来两个好处。一是减少意外后果比如垃圾字符串被识别成日期然后日历被塞满奇怪事件二是建立信任用户知道系统不会替他乱动东西。对效率产品而言信任比自动化更稀缺。自动化只有建立在信任上才会被长期使用。6.3 提供 Markdown 导入导出和开放接口第三件事是把数据出口做好。支持 Markdown 导入导出已经不是增值功能而是底线要求。因为所有信息工具都逃不开用户从一个平台切换到另一个平台的可能。我今天用 Jotchi明年可能迁到别的工具。开发者用户还会额外期望 API 或者命令行支持。一个能通过 API 追加记录、查询记录、导出记录的 scratchpad可以被轻松嵌入到个人脚本、Claude 工作流、自动提醒系统里。这种开放性会让工具从“单一应用”变成一个底层基础设施实现更长久的生命力。这三点不一定能立刻做成但它们决定了产品能走多远。Jotchi 是否已经做到我不得而知但如果它未来更新都朝这个方向发展我会认为它走在了正确的路上。7. 重新看待 Jotchi 这类 Show HN 项目7.1 早期产品看什么不是功能列表是它有没有降低某个动作的成本Hacker News 上每天都有很多 Show HN 项目出现大多数会在一阵讨论后消失。原因多种多样但一个非常普遍的问题是产品做了很多功能却没有把任何一条用户路径打磨到“足够自然”。Jotchi 的切入点很小只有“给忙碌大脑一个智能草稿本”。看一个早期产品有没有潜力不是看它支持多少个连接器、有没有暗黑模式、有没有团队协作而是看它有没有真正降低“记录一条随机信息”的成本。如果成本足够低低到使用者形成肌肉记忆那么它就已经完成了最关键的验证。7.2 真正值得长期关注的能力随取随用随意丢弃我最近越来越觉得像 scratchpad 这样的信息工具核心不是知识的积累而是“临时性”的管理。它不是要让你的知识库越来越厚而是让你在信息洪流中有一块可以随手放下重物、下个路口再捡起该捡部分的空地。所以真正值得长期关注的能力一是随取随用呼出要快、输入要快、搜索要快二是随意丢弃一条内容用完就从主界面消失不产生愧疚感也不占用心理余额。如果 Jotchi 能实现这种体验它会比收藏上千篇笔记更让人舒服。7.3 适合谁不适合谁不是所有人都需要 scratchpad。它更像是一把顺应特定工作节奏的钥匙。适合的人群包括经常在多个项目间切换的开发者、产品经理脑子里经常同时跑两三个没整理完的想法的人用笔记软件和任务管理工具但始终觉得“入口太重”的人愿意每天花五分钟清空一次临时记录的人。不适合的人群包括期望一个工具管理所有信息、不想自己维护笔记结构的人没有定期整理习惯只想“记完就永远放着”的人需要强项目管理、依赖关系、甘特图的团队负责人对数据隐私非常敏感但又不接受本地存储和自主导出的人。看清楚这些边界你才能判断 Jotchi 是锦上添花还是又一个吃灰应用。回到开头那个场景。当你手头有任务、脑中又冒出新的念头时最理想的做法不是强迫自己停下来归类也不是让念头就这么溜走而是把它放进一个专门为“忙碌大脑”准备的草稿区域。Jotchi 这类项目能不能成为最终答案还需要实际体验和社区反馈来验证。但至少它提醒了我一件事真正有效的效率工具不是帮你管理更多信息而是帮你减少信息对你的打扰。