“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
AppGet之死：一个开源项目与微软的12个月博弈
微软以疑似借鉴的方式推出WinGet，导致独立开发者放弃AppGet项目，折射出小项目与大公司互动的现实困境。
背景：AppGet是什么？
AppGet 是一个由独立开发者 Keivan Beigi 创建的 Windows 包管理器，旨在让 Windows 用户能够像 Linux 用户使用 apt 或 yum 一样，通过命令行轻松安装、更新和卸载软件。在它出现之前，Windows 上的软件分发主要依赖手动下载安装包，或使用体验不佳的 Windows Store。AppGet 的出现填补了这一空白，受到了许多 Windows 开发者和高级用户的欢迎。它的核心特性包括：
- 基于 YAML 的清单文件（manifest）描述软件包元数据
- 集中式包仓库（GitHub 上维护）
- 命令行工具支持安装、升级、卸载等操作
- 权限模型和安装逻辑的简化
2019年时，AppGet 已经在 GitHub 上获得了数千星标，成为 Windows 生态中一个不可忽视的社区项目。
时间线：从惊喜到沉默
2019年7月3日：微软的橄榄枝
Keivan 收到了来自微软高级经理 Andrew 的邮件，邮件中 Andrew 称赞 AppGet 是“Windows 生态的绝佳补充”，并希望在温哥华与 Keivan 会面，听取他对如何改进 AppGet 的建议。对于一个业余项目开发者来说，这无疑是一个令人兴奋的信号——被巨头认可，甚至可能获得资源支持。
2019年8月20日：初次会面
在微软温哥华办公室，Keivan 与 Andrew 及另一位产品工程经理见面。会面轻松而富有建设性：他们讨论了 AppGet 的设计理念、Windows 包管理器现状的不足、未来规划。Keivan 提出了几个具体的支持请求：Azure 云额度、MSIX 包格式的文档、以及修复几个下载链接问题。会面后，Keivan 感觉到微软确实想提供帮助。
2019年8月28日：收购职位的暗示
Andrew 发来邮件，明确表达了微软想在包管理器领域“做大事”的决心，并暗示希望 Keivan 加入微软——不是做 Windows Store 或 MSI 引擎这类传统工作，而是专注于 AppGet。Keivan 起初犹豫，但在得到“你将全职投入 AppGet”的保证后，开始认真考虑。
2019年9月至11月：缓慢的谈判
邮件来回速度极慢，每个问题都要等上数周才得到回复。Keivan 多次询问自己的职位、汇报线、团队规模等关键信息，但从未得到明确答案。微软内部流程的复杂性开始显现：负责收并购的 BizDev 部门效率极低。为了加快速度，微软建议以“雇佣+奖金”的方式绕开收购流程，之后再转移代码所有权。Keivan 同意了。
2019年12月5日：雷德蒙德面试
Keivan 飞往西雅图，在微软总部微软总部进行了一整天的面试和技术会议。前三次是典型的面试，与 Andrew 的会议则更像方案讨论：如何将 AppGet 扩展至微软规模？如何迁移基础设施？会议在下午6点结束，Keivan 当晚飞回温哥华。之后，杳无音信。
2020年1月至5月：石沉大海
整整六个月，微软没有任何回复。没有邮件，没有电话，没有解释。Keivan 只能暗自推断“微软的事”已经告吹。
2020年5月（Build 2020）：WinGet 发布
就在 Build 2020 大会前夕，Andrew 终于发来邮件，告知微软已开发了名为 WinGet 的包管理器，首版预览将于次日发布，并轻描淡写地表示“PM 职位没有成功”，同时称赞 Keivan 的“输入和见解”。邮件中甚至提到“给 appget 一个呼叫”，但实际上在博客中只是将 AppGet 列为现有包管理器之一，未提灵感来源。
核心内容：技术相似性与“灵感”
当 Keivan 看到 WinGet 的 GitHub 仓库时，震惊之余发现，WinGet 的许多核心设计几乎与他为 AppGet 规划的方向一致：
- 清单文件格式：都是 YAML，结构高度相似（包名、版本、安装器类型、校验和等字段）
- 仓库结构：包仓库采用类似的按包名分目录的组织方式
- 术语与机制：例如“manifest”的用法、安装模式选项（silent, interactive, etc.）
- 设计哲学：支持多来源（community vs. official），基于 GitHub 的社区驱动模式
Keivan 在博客中特意澄清：代码本身没有直接复制，因为 AppGet 是开源的，但“项目的根基”——设计理念、工作方式、对 Windows 软件分发痛点的理解——被无声无息地吸收，且未给予公开的致谢。
情感侧面：失望而非愤怒
Keivan 在博客中坦诚：
- 对未被聘用，他并不太在意：雷德蒙德之行后，他对为巨头工作并不心动；而且从加拿大移民美国并非他所愿。他也从未将此事视为板上钉钉。
- 对微软推出自己的包管理器，他举双手赞成：1.4万亿美元的公司终于为旗舰产品做了件正事，这本是多年前就该完成的。
- 真正的痛苦在于处理方式：沟通极其拖沓，最终沉默数月，发布公告时却将 AppGet 归类为“恰巧存在的另一个包管理器”，而 WinGet 其实深受其启发。
对创业与开源的启示
- 大企业的流程风险：与顶级公司合作可能意味着漫长的内部协商，即使个人诚意满满，组织机器也会让速度放慢到令人绝望。
- 开源不等于无风险模仿：开源的代码可被人合法使用，但设计思想被挪用却不署名，对项目创始人的精神冲击是巨大的。
- “走为上计”的谈判：在早期没有确定书面协议的情况下，即便口头承诺“全职做AppGet”，也无法保证后续执行。
- 心理准备：小项目与大平台互动，结果往往不受自身控制，保持独立发展的能力是唯一的保险。
尾声
Keivan 决定让 AppGet 进入维护模式，直至2020年8月1日永久关闭。他祝愿 WinGet 能成功，并希望 Windows 用户最终能享受到良好的包管理体验。但他也留下了一句话：
“Live and learn.”
在这场不对等的博弈中，他失去了项目，获得了教训；而微软赢得了一个新的引擎，代价是另一个开发者的信任。
原文链接：The Day AppGet Died