“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
近5500万美元融资的Otonomo，如何一步步“克隆”我们的产品
一家融资5500万美元的竞争对手，被指系统性抄袭开源API文档，甚至包括随机生成的占位符和拼写错误。
背景：我们为何愤怒
我执笔写下这篇文章，不是为了博取同情，而是为了记录一次我们亲眼所见、甚至无法用“巧合”解释的抄袭行为。Smartcar是一家致力于让开发者能够轻松为汽车构建应用的初创公司。我们花数年时间构建了一个标准化的汽车API——开发者仅需几行代码，就能通过我们的文档和API定位车辆，甚至远程解锁车门。
作为开发者出身的团队，我们深知优秀的API体验离不开优秀的文档：清晰的端点定义、准确的参数说明、可复现的代码示例，这些都是产品的一部分。从构思到工程实现，从客户访谈到底层迭代，我们花了数月时间才让Smartcar平台上线。每一段文档、每一个示例标识符、甚至表格中的顺序和注释，都是团队心血的结晶。
但几天前，我们偶然发现了Otonomo的公开API文档。 Otonomo是一家获得约5500万美元风险投资（其中包括知名VC如Bessemer）、估值近4亿美元、并且与汽车行业巨头德尔福（现Aptiv）关系密切的公司。LinkedIn显示其员工超过100人。他们绝非无名小卒。但当我们翻开那本文档时，一股寒意从脊背升起——那看起来太熟悉了。奇异地熟悉。
不是模糊的相似，不是结构上的撞车。这是系统性的、逐字逐句的照搬——从整体组织架构，到代码注释、代码示例，甚至连我们当初随手生成的临时标识符和错别字都一字不漏地复制了过去。
证据？文档截图，一清二楚
（以下内容以2019年4月16日Smartcar与Otonomo公开文档的对比进行说明。）
1. 注册与重定向URI
我们文档在描述“注册与重定向URI”的表格中，包含一项“自定义scheme”示例。这个示例中，我们为了演示而随机生成了一个自定义URI字符串（如com.example.smartcar://这样的占位符）。而Otonomo的文档中，同样位置、同样结构、同样表格标签下，出现了完全相同的随机字符串。
这不是API设计标准强制的字段，而是开发者随意写的示例标识符。数百种可能的写法中，他们偏偏选中了我们的那一个。巧合？概率几乎为零。
2. 授权URL与state参数
在OAuth 2.0授权流程中，我们需要在文档中展示如何拼接授权的URL。当时，为了演示&state=参数，我们在URL中嵌入了一个人为添加的随机字符串作为参数值的占位符，比如state=random_token_abc123。这个字符串没有任何业务含义，纯粹是写文档时随手敲进去的。
而Otonomo的文档中，同样位置、同样格式、同样一模一样的随机字符串也出现了。我们不可能在毫无交流的情况下，在几百万个可能的随机字符串中撞同一个。
3. Auth Code 响应示例
在展示授权码响应（Auth Code Response）的章节中，我们给出了一个JSON响应示例，包括字段顺序、嵌套层级、字段标签、描述性文本、以及一个演示用的授权码和示例值。Otonomo的文档将此段落原封不动地搬了过来——连字段的排列顺序、表格的列数、甚至对字段的解释说明文字都一致。我们没有使用自动化工具对比，但肉眼可见，这已经超出了“借鉴”的范畴。
4. 获取Access Token的代码示例
这是最令人反感的。我们在文档中提供了一段代码片段，用于展示如何通过HTTP请求获取Access Token。这段代码包含了定义的HTTP方法、URL路径、请求头Headers（如Content-Type: application/x-www-form-urlencoded）、请求体Body的键值对，以及一个演示性的返回JSON。Otonomo将这段代码几乎原样复制，只替换了域名和特定凭证的值。代码风格、缩进、注释位置，甚至连我们写错后保留的一个小疏忽（一个拼写错误）也一并拷贝了。
截图胜于雄辩。我们不需要逐行指出差异，因为几乎不存在差异。这不再叫‘灵感’，而是‘影印’。
令人困惑的不仅是抄袭本身
真正让我感到难以置信的，不是抄袭行为本身，而是其背后代表的文化和缺失的问责制。Otonomo不是一家车库里的黑作坊，他们的背后有Bessemer这样名门正派的风投支持，有来自汽车行业资深玩家的认可，团队规模超过100人。那么在这一次又一次的PR评审、代码审核、文档修订中，难道没有一个人意识到他们在照搬另一个初创公司的所有文本？难道没有任何一位工程师或产品经理在合并文档时，觉得这些字符串和示例不应该来自别人的努力？
我也曾试图为他们寻找理由，比如可能是某位外包文档写手“抄了不该抄的资料”，但从文档的系统性来看——从目录结构到各个端点描述、从基础概念到进阶用法——这不是局部泄露，而是一场大手笔地全盘挪用。如果一个超过100人的团队中，没有任何人对这种抄袭提出质疑，那么问题就不再是“某个人犯错”，而是这个组织的流程和价值观出了漏洞。
为什么我们选择曝光和采取法律行动
我们花费数年时间与用户沟通，判断他们真正需要什么样的API；我们打磨数据模型，争取兼容更多的车型；我们一遍遍检查错误边界，确保开发者调用接口时不会因为模糊的文档而卡壳。这些投入，转化为我们文档中的每一个字，每一个示例，每一个随机生成的令牌。现在这些投入被白拿走了。
Smartcar团队日夜奋斗，背后有坚定的信念：我们相信自己的工作能为开发者的未来出行创新赋能。如果我们对这种抄袭视而不见，那我们等于默许了“当你做大之后，可以随意拿走别人心血”的潜规则。这不仅是对我们团队的伤害，更是对整个开发者生态的毒化——初创公司仅有的技术资产变得可以被轻易掠夺，如果没人保护，那谁还敢做前沿创新？
我们将付诸法律。我们已经向Otonomo发送了停止函（Cease & Desist），要求他们立即停止对Smartcar辛勤成果的侵犯。我们要求他们删除所有涉嫌侵权的文档内容，保存相关修改记录，并停止使用任何与之相关的材料。
我们深知这将会是一场漫长的拉锯战，但为了行业的公平竞争，为了我们自己团队的心血，也为了所有相信靠真才实学来竞争的开发者，我们必须一战。后续进展，我们会随时公布。
本文翻译自Smartcar CEO Sahas Katta发布于2019年4月22日的博客文章，内容经过技术表达上的编辑性微调，但完整保留了原作者的陈述、数据及观点。
原文链接：https://smartcar.com/blog/how-otonomo-is-cloning-our-product/