笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
GUI 应用应当完全支持键盘驱动：从一场 HN 争论说起
本文反驳了“TUI 优于 GUI 因为键盘驱动”的常见论点，指出 GUI 完全有能力实现全键盘操作，问题在于开发者的意愿而非技术可行性。
上周，Hacker News 上有一篇帖子鼓励应用开发者停止制作终端用户界面（TUI），转而专注于图形用户界面（GUI）。该帖登上了 HN 首页，并在评论区引发了热烈讨论。我认为争论双方都有道理：一方面，GUI 应用框架的能力在理论上是 TUI 的超集，因此理应被优先选择；另一方面，作为一个重度终端用户，我非常欣赏那些能让我“留在”终端里满足所有需求的 TUI 应用。
但我想反对一个反复出现的、在我看来缺乏坚实基础的 TUI 支持论点。转述一下各位评论者的观点：TUI 应该被优先选择，因为它们是键盘驱动的。
诚然，如果你随机挑选一个 GUI 和一个 TUI 应用，后者更有可能完全支持键盘操作。但这并不能成为开发 TUI 而非 GUI 的理由。它真正凸显的是许多 GUI 应用在键盘导航方面的不足。没有任何东西阻止 GUI 像 TUI 一样——甚至比 TUI 更好地——实现完全键盘驱动。
事实上，许多 GUI 框架的应用指南明确鼓励开发者提供覆盖整个应用功能的键盘导航支持。例如，GNOME 人机界面指南（HIG） 明确指出：正如应该可以用指点设备执行每个操作一样，也应该可以用键盘执行每个操作；用户应该能够仅用键盘在用户界面的每个部分移动和交互。
作为用户，这引起了我的共鸣。能够仅用键盘直观且可预测地在 GUI 应用中导航，会让我更有动力选择它而非其他替代品。知道了这一点，当我戴上开发者帽子时，就必须确保我的应用对键盘友好。
以我的第一个 GUI 应用 Klisi 为例，我投入了一些时间来实现覆盖所有可用操作的键盘快捷键。在大多数情况下，键盘导航并不难实现，而且能带来整体更好的用户体验。这不是可行性问题，而是应用开发者意愿的问题。
结论很简单：不要在你提供的用户体验上妥协。努力让应用尽可能直观。为此，启用完整的键盘导航不应被忽视。
深度扩展：为什么这个争论值得认真对待
1. 背景：TUI vs. GUI 的长期拉锯
这场争论并非新鲜事。从 1980 年代 GUI 普及开始，就有“终端原教旨主义者”与“图形界面拥护者”之间的持续摩擦。TUI 的优势在于：轻量、可脚本化、易于远程使用（SSH）、资源占用低、与 Unix 哲学契合。GUI 的优势在于：丰富的视觉反馈、鼠标精确操作、多媒体支持、多窗口并行。
但键盘驱动这个论点，往往被 TUI 支持者当作“杀手锏”。他们的逻辑是：在 GUI 中，你经常需要鼠标点击小按钮、拖拽滑块、在复杂菜单中查找选项；而在 TUI 中，Vim 风格的快捷键、Emacs 键位、或者简单的 j/k 滚动让操作效率极高。
2. 作者的核心反驳：键盘驱动不是 TUI 的专利
作者指出，键盘驱动是应用设计决策，而非界面范式属性。一个 GUI 应用完全可以做到：
- 所有菜单项都有快捷键（如
Ctrl+N新建、Ctrl+S保存） - 所有控件都可以通过 Tab 键顺序聚焦
- 支持全键盘的焦点移动（如方向键在控件间移动，空格激活）
- 提供全局搜索框（如 VS Code 的
Ctrl+P）来跳转到任意功能 - 支持命令面板（如 Sublime Text 的
Ctrl+Shift+P）
这些都不是 TUI 的专属能力。事实上，现代 GUI 框架（Qt、GTK、Electron、SwiftUI）都内置了完善的键盘导航支持。例如：
- Qt 提供
setShortcut()和焦点链（focus chain）机制 - GTK 有
accelerator和mnemonic支持 - Electron 应用可以轻松注册全局和局部快捷键
- 浏览器 本身就是键盘驱动的（Tab 导航、
Ctrl+L地址栏、/搜索等）
3. 为什么很多 GUI 应用键盘体验差？
作者认为这是“意愿问题”而非“能力问题”。我深表同意，并补充几个原因：
- 开发优先级：很多开发者默认用户会用鼠标，键盘支持是“锦上添花”，往往在最后阶段才补，甚至直接省略。
- 设计迭代：GUI 设计经常在原型阶段用鼠标操作验证，键盘路径被遗忘。
- 框架默认值：有些框架的默认焦点行为不理想，需要开发者额外配置，但很多人不知道或不关心。
- 测试缺失：自动化测试很少覆盖键盘操作路径，导致回归。
4. 键盘驱动的实际价值
作者从用户体验角度强调键盘导航的直观性和可预测性。这背后有更深层的理由：
- 效率：熟练用户通过快捷键可以达到比鼠标高数倍的操作速度（例如文本编辑、代码重构）。
- 无障碍：视力障碍、运动障碍用户依赖键盘或辅助设备模拟键盘操作。这不是小众需求，而是法律和道德要求（如 WCAG 标准）。
- 可脚本化：键盘驱动应用更容易被自动化工具（如 UI 自动化测试、宏工具）操作。
- 一致性：当所有操作都能键盘完成时，用户更容易建立心智模型，减少学习成本。
5. 作者的个人实践：Klisi 应用
作者提到他的第一个 GUI 应用 Klisi 实现了全功能快捷键。这很有启发：即使是初学 GUI 开发的开发者，也能做到这一点。关键在于设计阶段就考虑键盘路径，而不是事后补救。
6. 反对意见的回应
评论区可能有反对意见，例如：
- “鼠标在某些任务中更高效”（如拖拽、绘图）。作者也承认这一点——他澄清“完全键盘驱动”不等于“禁止鼠标”，而是“所有功能都可通过键盘完成”。
- “TUI 更适合服务器环境”。这是对的，但作者的建议是：在 GUI 环境中，不要因为键盘问题而放弃 GUI 转投 TUI。
- “实现键盘驱动太费时间”。作者反驳：这通常不难，而且能显著提升用户体验，是值得的投资。
7. 对开发者的具体建议
基于文章和我的经验，给 GUI 开发者的键盘驱动清单：
- 为所有操作绑定快捷键，包括不常用但存在的功能。
- 确保 Tab 键顺序符合视觉逻辑，且焦点可见（如高亮边框）。
- 支持方向键在控件组内移动（例如单选按钮组）。
- 提供快捷键帮助对话框（如
Ctrl+/或?）。 - 在文档中列出全部快捷键，并在 UI 中提示（如菜单项右侧显示）。
- 测试键盘路径：写自动化测试模拟纯键盘操作。
- 遵循平台惯例（如 macOS 的
Cmd+Q，Windows 的Alt+F4）。
8. 结语
作者最后说“不要在你提供的用户体验上妥协”。这句话值得每个开发者铭记。键盘驱动不是 TUI 的护城河，而是所有优秀应用的共同标准。无论你选择 TUI 还是 GUI，都应当让用户能够完全通过键盘操作——这不是范式之争，而是基本的人性化设计。