这次我们来看一个 Hacker News 上的 Show HN 项目名字叫One Thing at a Time。光看标题很容易觉得这又是个普通的 todo 应用但它真正的差异点藏在那半句里hides your list。它不会像传统待办软件那样把所有任务一次性铺在你面前而是默认把整个列表隐藏起来只把“当前要做的一件事”放到最显眼的位置。你做完了这一件它才会从队列里露出下一件。这类“单任务聚焦”型待办应用解决的不是“记不住事”的问题而是“看到一堆事就焦虑、不知道先做哪个”的问题。对那些每天要面对十几个任务、切换成本高、容易分心的开发者和内容创作者来说这个设计切入点比加更多花哨功能更值得研究。这篇文章会从产品逻辑、交互设计、前端实现、数据存储、测试验收和后续扩展几个角度拆解这个项目。如果你也在做自己的任务管理工具或者想复刻一个类似的“单任务模式”应用到自己的工作流里下面的内容可以直接参考。1. 核心能力速览项目维度说明项目类型单任务聚焦型待办事项应用Web/本地小应用核心设计默认隐藏完整任务列表一次只展示当前任务主要功能添加任务、选择当前任务、完成任务、切换下一任务、按需展开完整列表产品目标降低决策负担减少任务切换提升单任务专注度适合场景个人日常任务管理、开发者工作流、内容创作任务、学习计划运行环境如果是静态前端方案常规浏览器即可运行数据存储本地存储或轻量数据库具体取决于项目实现接口 API原始项目未明确说明可按需自行扩展批量任务产品强调“一次一个”不适合批量并行展示但任务列表的批量导入/排序仍可支持这个表里大部分是“从产品形态推断”的信息。原始 Show HN 页面没有给出完整技术栈和部署要求所以如果你要复刻最稳妥的做法是先按一个小型 Web 应用来设计再按自己的运行环境调整。2. 适用场景与使用边界2.1 适合谁用这个应用最适合的是以下几类人任务过多、每天被列表淹没的人。传统 todo 应用把所有任务平铺在界面上视觉压力大反而让人不愿意打开。One Thing at a Time 的做法是把 99% 的内容收起来只留一条任务心理负担明显更低。需要连续执行简单任务的人。比如内容创作者有“写大纲、拍照、排版、发布”这类固定流程每完成一步应用自动露出下一步不需要手动去列表里挑。容易被多任务干扰的开发者和设计师。在做技术方案、写代码、做界面时如果任务列表突然弹出一条“明天要交周报”的提醒注意线就会断。这种应用把提醒推迟到当前任务结束后降低了切换成本。2.2 解决什么问题这个设计解决的主要问题有三个决策疲劳。人每天做选择是有消耗的。与其在十几条任务里反复纠结“先做哪个”不如让应用帮你指定唯一选项。任务切换开销。频繁看一眼列表、换一个任务、再切回来上下文丢失很严重。单任务模式让界面上的信息量始终维持在最低。未完成焦虑。任务列表越长没完成的事情看起来越多焦虑感越强。隐藏列表之后你眼前只有一条任务心理状态会平稳很多。2.3 不适合什么场景这个设计也有明显边界紧急任务处理。如果某条任务有硬性截止时间比如“今天下午 3 点前提交代码”单任务模式可能隐藏掉这个信息导致错过 deadline。这类应用需要额外支持“置顶紧急任务”或“截止时间提醒”。团队协作场景。团队任务往往需要看全局、看负责人、看依赖关系把列表全部隐藏会让协作效率下降。大量重复性任务。如果你每天要处理 50 条相似任务一条一条点完成反而慢传统列表模式更高效。2.4 合规与隐私边界待办事项数据虽然不像人脸、声音那样敏感但同样涉及用户个人生活和工作的私密内容。如果你要把这个项目发布给更多人使用或者做多设备同步必须注意本地存储方案下数据只存在用户自己浏览器里服务端不收集数据隐私风险最低。如果要加账号体系或云端同步必须明确数据存储位置、加密方式和隐私政策。不要采集用户的任务内容用于训练模型或广告推荐这个底线不能碰。3. 环境准备与前置条件如果你想在本地复刻这个项目按一个轻量前端应用来准备环境即可。3.1 系统与工具操作系统Windows、macOS、Linux 都可以这类应用不挑系统。Node.js 环境如果项目基于 Vite、React、Vue 等前端工程需要安装 Node.js 18 或更高版本。浏览器Chrome、Edge、Firefox 或 Safari建议用最新版本保证 localStorage 和原生 Web API 完整支持。代码编辑器VS Code 或任意你习惯的编辑器。如果原始项目不是 Node 工程而是一个单 HTML 文件或静态资源目录那么只需要一个静态文件服务器即可。这里给一个通用方案# 在项目目录下启动一个本地静态服务 python3 -m http.server 8080启动后访问http://localhost:8080就能打开页面。3.2 开发依赖如果采用现代前端工程通用依赖如下# 以 Vite React 为示例实际依赖需按项目情况调整 npm install npm run dev注意不要照抄命令就完事。如果项目用的是 Vue、Svelte 或者纯原生 JS安装和启动命令都有差异要以项目 README 或 package.json 为准。3.3 数据存储方案选择“隐藏列表”这个功能对存储方案没有特殊要求但会直接影响后续扩展localStorage最简单适合纯前端个人工具。容量约 5MB足够存几千条任务文本。缺点是容易被浏览器清理工具清空。IndexedDB容量更大适合存大量任务和附件信息。API 较复杂但可以封装。SQLite 或 JSON 文件如果应用是 Electron 桌面版或本地 Node 服务可以用文件存储备份更可控。云端数据库如果要做多设备同步需要后端服务和账号体系复杂度明显上升。4. 安装部署与启动方式原始项目没有给出一键启动包或明确的部署命令所以这里给出一条通用的本地启动路线。4.1 获取源码如果项目已经开源通常是以下命令之一git clone 项目地址 cd one-thing-at-a-time npm install npm run dev如果项目没有开源你完全可以根据产品思路自己实现一个。下面给出一份最小可行版本的概念原型。4.2 最小 HTML/CSS 结构核心交互可以拆成三个部分当前任务展示区、完成/跳过按钮、可折叠的完整列表。!-- 概念原型一次只显示一个任务 -- div idapp h1当前任务/h1 div idcurrentTask/div button idbtnDone完成/button button idbtnSkip跳过/button details idlistPanel summary查看完整列表/summary ul idtodoList/ul input idnewTaskInput typetext placeholder输入新任务 / button idbtnAdd添加/button /details /div4.3 核心 JavaScript 逻辑这里用 localStorage 做持久化实现“新增任务、选取当前任务、完成后自动露出下一项”的核心循环。这只是一个参考实现方向不是原始项目源码。// 概念原型focus-first 待办应用核心逻辑 const STORAGE_KEY one-thing-at-a-time; function loadTasks() { const raw localStorage.getItem(STORAGE_KEY); return raw ? JSON.parse(raw) : []; } function saveTasks(tasks) { localStorage.setItem(STORAGE_KEY, JSON.stringify(tasks)); } function render() { const tasks loadTasks(); const current tasks.find((t) !t.done !t.skipped); // 当前任务区 const currentTask document.getElementById(currentTask); if (current) { currentTask.textContent current.text; } else { currentTask.textContent 所有任务已完成添加一个新任务吧; } // 完整列表区 const list document.getElementById(todoList); list.innerHTML ; tasks.forEach((task, index) { const li document.createElement(li); li.textContent ${index 1}. ${task.text}【${task.done ? 已完成 : 待办}】; list.appendChild(li); }); } function addTask(text) { const tasks loadTasks(); tasks.push({ text, done: false, skipped: false, createdAt: Date.now() }); saveTasks(tasks); render(); } function completeCurrent() { const tasks loadTasks(); const current tasks.find((t) !t.done !t.skipped); if (current) { current.done true; saveTasks(tasks); render(); } } function skipCurrent() { const tasks loadTasks(); const current tasks.find((t) !t.done !t.skipped); if (current) { current.skipped true; saveTasks(tasks); render(); } } // 绑定事件 document.getElementById(btnDone).addEventListener(click, completeCurrent); document.getElementById(btnSkip).addEventListener(click, skipCurrent); document.getElementById(btnAdd).addEventListener(click, () { const input document.getElementById(newTaskInput); if (input.value.trim()) { addTask(input.value.trim()); input.value ; } }); // 初始渲染 render();这段代码的核心就是四步循环从存储中读取任务数组。找到第一条未完成、未跳过的任务显示到当前任务区。用户点击“完成”或“跳过”。重新渲染自动露出下一条待办。这里的skipped字段很关键。如果用户暂时不想做某条任务点“跳过”就不需要把它标成完成也不会在界面上制造压迫感。原始项目是否实现了“跳过”功能不确定但从产品逻辑看这是“单任务模式”必备的逃生通道。4.4 部署到生产环境如果要在本地长期使用或部署到服务器可以用任意静态托管# 构建生产包以 Vite 工程为例 npm run build# 将 dist 目录部署到任意 Web 服务器 npx serve dist这种“一个静态目录 localStorage”的方案部署成本很低个人用完全够。5. 功能测试与效果验证无论你是在试用原始项目还是在测试自己复刻的版本都要建立一套验收标准。下面是针对 One Thing at a Time 这类应用的功能测试清单。5.1 基础功能测试测试项操作步骤预期结果添加任务在列表区输入任务文字点击“添加”任务出现在完整列表中当前任务区显示第一条任务完成任务点击“完成”按钮当前任务被标记为完成下一任务自动出现在当前任务区跳过任务点击“跳过”按钮当前任务被移动到列表末尾下一条未完成任务显示出来隐藏列表默认不展开“查看完整列表”主界面只显示一个当前任务展开列表点击“查看完整列表”能看到全部任务和状态刷新持久化刷新页面当前任务和列表状态仍然保留5.2 边界场景测试空列表状态。没有任务时界面不能报错应该显示“没有任务”的提示。全部已完成状态。所有任务都完成后当前任务区要显示完成提示而不是空白。任务内容过长。如果任务文本有 200 个字符当前任务区应该正常换行不能撑破布局。快速连续点击“完成”。连续点击时要避免重复完成同一条任务。需要注意按钮的防抖处理或状态同步。localStorage 不可用。在隐私模式或禁用存储的浏览器中要提示用户开启本地存储或改用内存存储。5.3 判断成功的标准一个可用的“隐藏列表”待办应用至少需要满足打开应用后第一眼看到的是“一个当前任务”不是完整列表。完成任务后下一个任务自动出现不需要手动刷新。想查看全量任务时可以主动展开列表。刷新页面后数据不丢失。所有交互响应时间在毫秒级没有明显卡顿。5.4 常见失败原因问题现象可能原因处理方式添加任务后列表没变化事件绑定失败或存储写入异常打开控制台看报错检查 localStorage 是否被禁用完成按钮点了没反应当前任务获取逻辑有问题检查find条件是否正确是否存在 done 为 false 的任务刷新后任务丢失localStorage 没写入或浏览器清理数据检查saveTasks是否在addTask后被调用列表展开时布局混乱CSS 未适配完整列表高度给列表容器设置最大高度和滚动条6. 接口 API 与批量任务原始项目的种子介绍里没有提到后端接口所以这一节主要讲“如果要扩展应该怎么做”。6.1 为什么需要 API纯 localStorage 的方案有一个硬伤数据只在当前浏览器里。换电脑、换浏览器、清除浏览器数据后任务就会丢失。如果要做得更完整需要后端同步或至少支持导入导出。6.2 通用 API 设计模板如果后续给项目加一个简单后端可以设计三个接口{ GET /api/tasks: 获取所有任务, POST /api/tasks: 新建任务, PATCH /api/tasks/:id: 更新任务状态完成/跳过 }Python 调用示例import requests BASE_URL http://127.0.0.1:8000/api # 获取任务列表 response requests.get(f{BASE_URL}/tasks, timeout10) print(response.json()) # 创建新任务 payload {text: 写一篇技术博客, done: False} response requests.post(f{BASE_URL}/tasks, jsonpayload, timeout10) print(response.status_code, response.json()) # 标记完成 task_id response.json().get(id) response requests.patch( f{BASE_URL}/tasks/{task_id}, json{done: True}, timeout10 ) print(response.json())这个示例只是通用模板。实际接口路径和字段名要根据你的后端实现调整。6.3 批量任务的正确理解One Thing at a Time 这个名字已经说明产品主流程是单任务模式。但这不意味着完全排斥批量操作。批量需求主要体现在“导入”和“整理”两个环节批量导入。用户一次性复制 20 条任务过来应用自动拆分成 20 条记录。这不破坏“一次一个”的展示逻辑。批量清理。已完成的任务可以一键清空避免列表区垃圾数据堆积。批量排序。拖拽排序或按优先级排序确保“当前任务”是经过用户决策的而不是随机冒出来的。7. 资源占用与性能观察这一类小工具应用性能压力通常不在算法而在渲染和存储。7.1 前端渲染如果任务数量在几千条以内用原生的 DOM 操作完全没问题。只有当任务数超过 1 万条才需要考虑虚拟列表或分页展示。这里重点观察“展开完整列表”时的渲染性能。推荐用性能面板做一次快速检查打开浏览器开发者工具的 Performance 面板。手动制造一个包含 2000 条任务的测试数据。点击“展开完整列表”。观察 FPS 和渲染耗时。如果渲染耗时超过 500ms就需要考虑以下优化使用DocumentFragment批量插入 DOM。只渲染任务的前 50 条用“加载更多”代替全量渲染。对任务文本做截断处理。7.2 本地存储容量localStorage 的容量通常在 5MB 左右一个汉字按 UTF-8 编码约 3 字节假设平均每条任务 50 个汉字也就是 150 字节。加上 JSON 键名和结构开销一条任务大约 200 到 250 字节。5MB 大概能存 2 万条以上任务对个人使用来说足够了。但要注意一个性能陷阱每次都把整个任务数组读出来、解析成对象再整体写回 localStorage。任务少时没问题任务达到几千条后这种“全量读写”模式会有明显延迟。更好的做法任务列表拆成“未完成”和“已完成”两部分存储。已完成的旧任务定期归档或删除。写操作加防抖避免短时间内大量写入。7.3 CPU 和内存这类应用几乎没有 CPU 压力。即使每秒渲染一次当前任务内存占用也就在几十 MB 量级。真正需要担心的是浏览器插件和第三方脚本带来的额外开销与应用本身无关。8. 常见问题与排查方法以下问题是这类“单任务待办应用”最容易遇到的按常见程度排序。问题现象可能原因排查方式解决方案本地运行时报错 Cannot read properties of undefined初始化数据格式不对读取不到任务数组在loadTasks里打印 JSON 数据增加一份默认空数组兜底添加任务后刷新就不见了浏览器清理了 localStorage查看 DevTools Application 面板改用 IndexedDB 或加导入导出备份“跳过”后任务仍然显示跳过状态没有正确保存检查skipped字段是否写入存储在skipCurrent里调用saveTasks完成按钮连续点击导致跳过多条任务按钮没有防抖重复触发在按钮事件里打印日志给按钮加disabled状态或节流列表展开后网页滚动卡顿任务数量太多全量渲染用 Performance 面板看长任务耗时改用分页渲染或虚拟滚动迁移到新电脑数据丢失没有导出功能检查是否有导出按钮增加 JSON 文件导出/导入浏览器兼容问题用了较新的 Web API检查目标用户浏览器版本用 Babel 转译或选择兼容写法8.1 深入排查任务不显示这是待办应用最核心的故障。排查顺序建议是先看控制台有没有 JS 报错。如果没有报错在浏览器控制台执行localStorage.getItem(one-thing-at-a-time)看数据是否写入。如果数据存在但界面不显示检查渲染函数里的find条件。比如把!t.done写成了t.done就会导致空列表。如果数据不存在检查saveTasks是否在addTask之后被调用。// 控制台检查代码 const raw localStorage.getItem(one-thing-at-a-time); console.log(raw);8.2 深入排查完成操作无效完成操作无效大概率是当前任务没有被正确识别。建议在completeCurrent函数里加一行日志function completeCurrent() { const tasks loadTasks(); const current tasks.find((t) !t.done !t.skipped); console.log(当前任务:, current); // 后续逻辑... }如果current是undefined说明任务已经全部完成或者所有任务都带上了skip标记。9. 最佳实践与使用建议9.1 产品交互层面“完成”和“跳过”必须分开。跳过不是删除也不等于完成用户需要一条“这件事我今天不想干”的退路。列表默认收起但入口要明显。不能为了隐藏而隐藏用户需要时应该一秒找到列表入口。当前任务区要支持多行展示。任务文本一长就截断是非常差的设计应该留足呼吸空间。完成动画要轻盈。不要用夸张的弹窗和特效单任务模式的核心是减少干扰不是制造戏谑感。9.2 工程实现层面第一次先小参数测试。加 5 条任务测一遍全流程再考虑做批量导入。保留一套最小可运行版本。可以把概念原型代码单独存一份后续实验新功能时拿它做基线。模型文件、输入素材、输出结果分目录管理。这里的“输入素材”指的是原始任务列表“输出结果”是归档的已完成任务建议分开存放。one-thing-app/ ├── src/ │ ├── components/ │ ├── store/ │ └── utils/ ├── data/ │ ├── tasks.backup.json │ └── archive/ ├── dist/ └── README.md批量操作要加日志和失败重试。如果做了 API 同步用户导入 100 条任务时服务端可能只成功写入 80 条此时必须返回明确错误列表而不是静默丢数据。接口服务要限制访问范围。如果应用监听在0.0.0.0并暴露到公网其他人可以直接读写你的任务。本地开发建议只监听127.0.0.1。# 本地服务只监听本机 python3 -m http.server 8080 --bind 127.0.0.1涉及他人日程或团队任务时必须确认授权。如果这个应用要同步团队成员的日历、任务和日程不要把别人的数据拉到本地明文存储。9.3 使用习惯层面每天的当前任务由前一天晚上确认。在晚上打开完整列表挑出明天最重要的一件其余不看。紧急任务单独处理。如果任务有硬性截止时间不要只依赖单任务视图建议配一个“截止提醒”或日历事件。定期清理完成记录。一周或一个月导出一份完成记录然后清空旧数据。这既降低存储压力也能看到自己真正完成了多少事。10. 总结与下一步One Thing at a Time 这个项目的价值不在技术复杂度而在产品视角。它把“待办事项应用必须展示所有任务”这个默认假设推翻换成一个更贴合大脑工作方式的问题如果我只做一件事应该做哪一件这个思路适合很多想做个人效率工具的开发者参考。你可以先做一个最小版本把“添加任务 - 显示当前任务 - 完成自动切换 - 列表默认隐藏”这条主流程跑通再逐步加排序、截止日期、多设备同步和 API 扩展。最容易踩的坑有三个第一把“跳过”和“完成”混到一起导致用户无法灵活选择第二列表虽然默认隐藏但没有做一个稳定、醒目的展开入口用户找不到自己的历史任务第三只用 localStorage 却不提供导出备份用户一清浏览器数据就会丢全部任务。下一步可以做的扩展方向包括给任务加优先级和截止时间但不把这些信息默认展示出来。增加桌面通知只在当前任务完成时触发下一条提醒。做成浏览器插件或 PWA方便跨设备安装。增加命令行接口让开发者可以用todo next、todo done这类命令操作任务。如果你最近也在找一款“真正能让你专注于眼前这一件事”的待办应用这个项目值得试。也建议直接动手写一个最小版本因为这类工具的复杂度刚好适合拿来做一次完整的前端项目练习从产品定义到数据持久化再到性能优化一个周末就能跑通。