“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
一位24岁全栈工程师正在失明：我该如何为未来做准备？
一位24岁全栈工程师因患尤塞氏综合征即将失明，向HN社区求助如何调整职业方向与工具链，引发了关于盲人工程师生态的深度讨论。
原文背景与核心诉求
提问者是一位24岁的全栈工程师，拥有约7年专业经验，主要使用JavaScript和PHP构建项目，涉及前端应用与后端架构。两年前被诊断为尤塞氏综合征（Usher's Syndrome）——一种以听力损失、平衡障碍和进行性视力丧失为特征的遗传性疾病。他的视力正在快速退化，而他没有计算机相关正式学历，完全依赖自学的编程技能谋生。
他的核心问题包括：
- 是否存在盲人前端工程师？
- 哪类软件工程工作更适合视力受限者？是否只能做后端？
- 除屏幕阅读器外，有哪些最佳工具可以帮助视力受限者开发软件？
- 公司是否雇佣盲人工程师？实际效果如何？
他在编辑中补充道，确诊后他逐渐产生了严重的焦虑，总觉得必须在“太晚之前”规划好余生。他非常独立，感受到必须“证明自己”的压力。
HN社区的关键回应与深度洞察
1. 盲人前端工程师确实存在，且能力超乎想象
多位盲人或低视力开发者现身说法。一位评论者提到，自己认识一位完全失明的资深前端工程师，在大型科技公司工作，负责复杂的React应用开发。他使用屏幕阅读器（如NVDA或JAWS）配合键盘导航，通过DOM树的有序遍历来理解页面结构，而不是依赖视觉布局。
关键背景： 屏幕阅读器并不是“朗读屏幕”那么简单。对于前端开发，盲人工程师通常需要开启浏览器的“虚拟光标”模式，逐行、逐元素地感知页面。CSS布局（尤其是Flexbox和Grid）对盲人开发者是巨大的挑战，因为这些布局的视觉顺序可能与DOM顺序不一致。因此，语义化HTML和合理的DOM顺序不仅是无障碍最佳实践，更是盲人工程师能否高效工作的生死线。
2. 后端开发是主流选择，但不是唯一选择
绝大多数回应的盲人工程师集中在后端服务、基础设施、DevOps和数据库领域。原因很现实：
- 后端代码是纯文本，依赖逻辑而非视觉理解；
- 命令行工具（如Vim、Emacs、tmux）对屏幕阅读器友好度远高于图形化IDE；
- 调试过程可以通过日志和测试驱动，无需视觉追踪UI状态。
但一位评论者指出，后端也并非安全的避风港。现代微服务架构涉及大量分布式追踪、可视化监控面板（如Grafana、Datadog），这些工具的无障碍支持极差。盲人工程师往往需要自己写CLI包装器或定期用curl查询API来替代仪表盘。
3. 工具链的真相：屏幕阅读器只是冰山一角
社区详细列举了实际可用的工具组合，远超普通人的想象：
- 终端优先：几乎所有盲人工程师都强调，**Textual User Interface（TUI）**是核心生产力工具。用
tmux管理多会话，用vim或emacs+speechd（语音合成守护进程）写代码，用git命令行版本控制。 - 语音听写：有些人用Dragon NaturallySpeaking或Windows内置语音识别写代码，但准确率对符号密集的语言（如Perl、C++）不高。JavaScript和Python的相对宽松语法反而更友好。
- 盲文显示器：少数人使用40或80单元的盲文点显器，尤其在需要精确理解括号嵌套和正则表达式时，盲文比语音更高效。但价格昂贵（约5000-10000美元），且需要额外学习盲文编码（如六点盲文和八点电脑盲文）。
- 代码朗读器：除了NVDA/JAWS，开发者专门推荐了Emacspeak（一款将Emacs变成音频桌面的开源工具）以及VS Code的屏幕阅读器优化模式（但多数人反馈体验不佳）。
- AI辅助扩展：一位评论者提到自己开始使用GitHub Copilot，将其作为“语法补全+结构提示”的工具，因为AI能根据上下文生成完整括号和函数块，减少逐字符导航的负担。这被很多人认为是一个有潜力的新方向。
4. 企业雇佣盲人工程师的现实
回答者中，有人在微软、亚马逊、IBM等大公司工作，有人在小创业公司。普遍反馈是：
- **合理便利（Reasonable Accommodation）**是法律要求（美国ADA法案），但实际落地中，同事的协作习惯比技术设施更重要。例如，如果团队习惯用截图讨论UI问题，盲人工程师就会被边缘化；但如果团队养成用文字描述问题（如“左侧第三个按钮的边距”vs“设置面板里保存按钮上方10px处”）的习惯，就不存在障碍。
- 面试过程是最难的一环。白板编程对盲人几乎不可行，但现在一些公司允许用自带电脑加屏幕阅读器完成算法题。一位面试官回忆，自己曾面试一位盲人候选人，对方用语音输入+键盘快捷键在40分钟内解决了疑难问题，表现优于多数视力正常的候选人。
- 晋升通道：一位IBM的盲人技术主管坦言，日常执行不是问题，但“阅读其他人的视觉化设计文档”、“参与架构图讨论”是隐形障碍。他常常需要请同事花5分钟把架构图用文字描述一遍。这导致他转向更重逻辑、轻视觉的领域（如API设计、安全策略）。
5. 心理与职业策略的深刻建议
评论中最动人的部分不是技术，而是生活哲思：
- 不要试图一次规划完余生。一位在30岁失明、现在45岁的工程师写道：“我25岁时以为失明就是世界末日，但事实上，这个世界每5年都会诞生新的辅助技术。现在的语音交互和AI代码生成是20年前无法想象的。与其焦虑未来，不如专注于当前能学到的东西——你的学习速度远比失明速度快。”
- 尽快开始“无障碍化你的工作流”。一位同时患有视网膜色素变性的开发者建议：即使还有部分视力，现在就开始逐步切换为纯键盘操作+屏幕阅读器为主、视觉为辅的模式。“当最后一点视力消失的那天，你不会经历学习曲线平台期，因为你早已在黑暗中工作了。”
- 建立盲人工程师社区人脉。他推荐了BlindDevs论坛和NFB（National Federation of the Blind）的技术部门，说那里的成员乐于进行远端结对编程，互相指导工具配置。
- 考虑将无障碍作为职业专长。一位视力正常但专职做无障碍服务的咨询师建议：既然你亲身体验了障碍，可以成为“盲人无障碍测试工程师”或“无障碍框架开发专家”，这类人才比普通后端更稀缺，且价值不随视力变化而消失。
6. 被忽略的硬事实：视觉之外的其他损失
尤塞氏综合征还包括听力损失。多位评论者提醒他：如果未来听力也下降，那么依赖语音输出的屏幕阅读器也将失效。因此，应该提前学习盲文，或使用动态盲文显示器作为输入输出的备用通道。更长远看，触觉反馈（如振动编码）正在研究中，但尚未商用。
总结与核心教训
这篇文章在HN上获得3270分和473条评论（2020年4月），远高于普通帖子，因为它触及了软件工程中一个被忽视的底层命题：代码本质上是文本，但我们的工作流却深深依赖于视觉隐喻。
社区共识可以归纳为：
- 盲人绝对可以从事前端，但需要更严格的代码规范（语义化HTML）和更耐心的团队沟通；
- 后端、基础设施、DevOps、安全审计是对视力最友好的领域；
- 工具列表：屏幕阅读器（NVDA/JAWS）、盲文显示器、Emacspeak、tmux、语音听写、以及善用AI代码补全；
- 公司层面的成功关键在于文档化一切（把图表用文字描述）、键盘友好型开发流程、以及将无障碍纳入日常代码评审；
- 心理上：不要试图一次性解决所有问题。技术发展是加速的，残障不是静态的敌人，而是一个需要持续适应的变量。
一位ID为lost_in_space的评论者说得最透彻：“你问‘我该怎么办’，其实你的职业路径不会变——你依然在解决问题、构建系统、写代码。变的只是你的输入输出设备。工程师的本质是逻辑和创造力，不是视觉皮层。”