“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Fable 可能不是所有工程师的最佳选择
说实话，我最近一直在琢磨一个问题：像 Fable、Opus 这种高度自主的 AI 编码代理，到底适合谁用？
起因是看到了 Simon Willison 的一篇笔记，他提了一个很犀利的观点：当你面对一个足够强的编码代理（比如 Fable）时，与其事无巨细地写一堆条件规则，不如放手让模型自己判断。换句话说，与其写“大功能跑测试，小文案改动不跑，设计改动另算……”这种繁琐的指令，你只需要说一句：“在合适的地方写测试并运行。” 同样的，成本控制也一样——与其手动决定哪个任务该用哪个模型，不如直接告诉代理：“选一个成本合适的模型，把任务分给子代理去做。”
这听起来很美好，对吧？但问题在于，这对所有工程师都适用吗？
手动挡与自动挡的类比
我想到一个有点粗糙但很贴切的类比：开车。
喜欢驾驶乐趣的人，通常偏爱手动挡。他们想自己选择档位，感受发动机转速，让车子直接响应自己的意图。对他们来说，驾驶本身就是一种技能和乐趣的体现。而对于那些只想从 A 点到达 B 点的人来说，自动挡显然更省心。
软件工程师其实也一样。
如果你有多年专业写代码的经验，你多半已经形成了自己的一套工作方式：
- 你可能习惯先把类型定义写好，再写实现。
- 你可能偏爱小粒度的 diff，一次只改一个逻辑。
- 你可能对测试的粒度有自己的一套标准——什么该测，什么不该测，心里门儿清。
- 你甚至可能有一套自己阅读陌生代码库的顺序（我希望你有，因为这是专业性的体现）。
对于这类工程师来说，Fable 或 Opus 这种高度自主的模型，就像一辆过于“自动”的车。它替你做了太多决定——而这些决定，你原本想自己做。
模型越强，细节指令越碍事
这一点其实和人类组织中的管理结构一模一样。
- 初级成员：需要具体的指令。“读这份文档，从这几个角度分析，用这个格式写总结。”
- 高级成员：可以接受更模糊的任务。“我想解决这个问题，你去调研一下，出个实现方案，然后推进。”
当然，这并不意味着“甩手掌柜”。你仍然需要给出目标、约束条件和成功标准。只是你不需要事无巨细地指挥每一步。
我认为，给 Fable 和 Opus 写指令的方式，正在向第二种情况靠拢。你告诉它：“我要做一个电商网站，支持用户注册、商品浏览、购物车和支付。数据库用 PostgreSQL，前端用 React，后端用 Go。安全性和性能是关键。” 然后它自己会去分解任务：先建表结构，再写 API，然后搭前端，最后写测试。每一步它都会自己判断怎么做最合理。
但问题来了：如果你已经知道怎么做最好呢？比如你明确知道这个场景下应该用 Redis 缓存而不是直接查数据库，或者你习惯先写集成测试再写单元测试。这时候，模型替你做的决定，反而可能和你的习惯冲突。
按“授权级别”选模型，而不是按“能力”
这里有个关键点：最强的模型不一定是最好的选择。你应该根据你想授权多少来选择模型，而不是根据模型的“智商”。
让我把这个逻辑拆开来说清楚：
如果你想自己掌控开发流程——比如你已经有了一套成熟的开发方法论，知道每一步该怎么做——那就用中档模型（比如 Sonnet）作为工具，你牢牢掌控方向盘。Sonnet 的代码能力足够强，但它不会自作主张替你规划任务。你让它写一个函数，它就老老实实写一个函数。
如果你想授权整个实现方式——包括任务分解、技术选型、测试策略、子代理调度——那就用高度自主的模型（比如 Opus 或 Fable）。你只需要给出目标和约束，剩下的它来搞定。这适用于你对技术方案没有强烈偏好、或者想探索新思路的场景。
如果你的开发风格还没定型——比如你刚入行不久，或者正在学习新的技术栈——那广泛授权给旗舰模型可能更合适。它能帮你建立一套工作流程，你可以在观察它的决策过程中学习。
对于维护工作或小修小补——在现有代码库里改个小 bug、加个简单功能——用中档模型快速交互通常更高效。杀鸡不用牛刀。
Fable 和 Opus 的真正价值
Fable 和 Opus 的价值不仅仅在于它们写代码更快。它们的真正价值在于：你可以把“开发如何推进”这件事本身授权出去。
这也是为什么它们和所谓的“vibe coding”很搭。注意，我说的 vibe coding 不是指对着模型瞎喊“给我做个牛逼的东西”然后期待奇迹发生。我指的是：给模型一个大致的目标，比如“我大概想要这么个东西”，然后让它处理更大的决策：
- 如何分解任务
- 调研到什么深度
- 是否应该写测试
- 是否应该把子任务分给子代理
- 最终结果是否自洽
如果你想自己做这些决策，那模型不需要那么自主。一个听话的工具比一个自作主张的搭档更好用。
但说实话，有时候自动挡就是香
别误会，即便你是个热爱手动挡的人，有时候也不得不承认自动挡更好。
举个例子：
- 大规模重构：在一个你不熟悉的代码库里做大规模重构。你连模块之间的依赖关系都不清楚，更别提怎么改了。这时候让 Fable 自己去探索、分析、执行，效率远高于你自己一步步摸索。
- 探索性工作：你还不确定该用什么方案。比如你想给一个老系统加个新功能，但不知道是改原有架构还是重写一部分。这时候让 Opus 出几个方案，每个方案分析利弊，比你自己纠结半天强。
- 原型开发：明天可能就扔掉的代码。比如你要做个 demo 给客户看，或者验证一个想法是否可行。这时候速度比质量重要，让模型全权处理是最快的。
所以我的论点不是“手动挡更好”。而是：授权级别是一个选择——如果你每次都默认用最自主的模型，你就跳过了这个选择，根本没思考过。
总结：手动挡还是自动挡？
对于从手写代码时代成长起来的工程师来说，Fable 和 Opus 不一定是最好的搭档。
- 如果你有自己的风格，想亲手把控方向盘，用中档模型（如 Sonnet）作为你双手的延伸，可能会更舒服。你写 prompt 就像在写代码，每个细节都在掌控之中。
- 如果你想授权整个开发过程，Fable 和 Opus 才真正展现出它们的价值。你从“写代码的人”变成了“定义目标和约束的人”。
简而言之：按授权级别选模型，而不是按智能水平。
对于喜欢手动挡的人来说，再好的自动挡也不一定最有趣。但如果目标只是“到达”，那自动挡完胜。Fable 和 Opus 大概就是这种工具。
最后问大家一个问题：你选择编码代理时，是按“它有多聪明”，还是按“我想授权多少”来选的？如果你也是手写代码出身，你真的愿意把整个过程全权交给它吗？
注：本文最初以日文撰写，后使用 GPT 翻译为中文。