📌 项目地址zakirullin/files.md | ⭐ 2,196 颗星 | 🔧 Go | 📜 未标注

一个项目,两个阶段

作者在README里写:“I have been building this project for 5 years”。前三年加功能,后两年砍。最后剩下什么?一个输入框,按Cmd+Enter弹出来,打字,回车,内容直接存成.md文件。没有笔记本列表、标签栏、标题字段、模板选择。存完之后才让你决定放哪个文件夹,或者永远留在收件箱。

2196个star。后端用Go,大约2000行。前端是一个HTML文件(web/index.html),HTML、CSS、JavaScript全部写在一起。没有Webpack、Vite、npm install、React。不需要安装任何东西,浏览器打开就能用。可以装成PWA离线使用。同步用iCloud/Dropbox/Google Drive解决,不自己写同步服务器。没有Electron,没有桌面客户端。

这种设计的目标是低认知负荷。作者在另一个项目cognitive-load里详细解释过。代码极简到“一个人或一个LLM能装进脑子里”,读代码不用学框架,改前端只需要懂一点HTML和JavaScript。

最小化记录摩擦:从想到写到只要两步

我试了下核心流程。打开app.files.md(推荐Chrome或Edge),点击地址栏右侧安装PWA。安装时会要求授权一个本地文件夹,这是关键一步——不授权的话数据只在内存里,刷新就丢。

授权完成后,在任何界面按Cmd+Enter,弹出聊天框。输入文字,按Enter。文件保存到本地.md文件,可以选择存放位置,也可以跳过存到默认收件箱。

【实际体验】从头脑里蹦出念头到文件落地,只需要Cmd+Enter – 打字 – Enter,中间没有任何对话框打断。我试了下,比Obsidian、Notion、Logseq都快,因为那些工具至少需要你先想一个文件名和位置。

files.md的做法是“先捕获,后整理”。你不需要在输入时决定这篇笔记属于哪个项目、打什么标签。它先帮你存下来,之后你想移动就移动。这种模式对“临时想法”尤其有效——你正在干别的事,一条想法冒出来,三秒内就能存下来,然后继续手头的工作。

架构选择:一个HTML文件加一个Go二进制

前端就一个web/index.html,所有HTML、CSS、JavaScript写在一起。没有构建步骤,没有包管理器,没有框架。

后端是一份Go代码,大约是2000行,编译成一个二进制文件。它提供同步功能,但这是可选的。你完全可以不用官方同步,直接用iCloud、Dropbox或Google Drive同步文件夹,效果一样。

这种架构的结果是:

  • 端口不变。没有Webpack、Vite、npm install、React。你改一句CSS,刷新浏览器就行。
  • 可移植。到任何电脑,装个Chrome,打开文件就行。
  • 可修改。懂一点HTML和JavaScript就能改前端,懂Go就能改后端。作者说“一个LLM能装进脑子里”,我试了下,把前端代码扔给Claude,它确实能理解并帮你改。

【技术限制】有两点需要知道。一是浏览器兼容问题。README明确说“Chrome-based browsers are best at File System API support”。实测Safari和Firefox不能正常安装PWA或读写本地文件夹。如果你长期用Safari,这个项目基本不可用。

二是没有自动刷新。你用VS Code改了一个.md文件,应用里不会自动更新。README说“Occasionally hit force-refresh (Cmd+Shift+R) to get new updates”。从其他编辑切回来必须手动强制刷新。这对习惯自动保存和同步的人来说可能是个小麻烦。

LLM可扩展性:一个被低估的特性

files.md的极简代码结构决定了它有独特的LLM可扩展性。市面上大多数笔记应用的数据格式和API是封闭的,LLM无法直接修改。而files.md的文件是纯.md,代码是一个HTML文件加一个Go二进制——你让Claude或GPT看一遍,它就能理解整个应用的结构,帮你修改功能。

作者在README里强调:“Grow the software around it with an LLM”。这种设计不是巧合,是刻意为之。低认知负荷的一个体现就是“LLM友好”——你不需要花时间解释框架、构建工具、数据格式,直接把代码扔进去,AI就能干活。

【实际案例】如果你想增加一个功能,比如“双击笔记标题改名”,传统的做法是找到代码库、定位文件、修改、构建、部署。在files.md里,你只需要打开web/index.html,找到对应的HTML和JavaScript,直接改。甚至可以复制给Claude,让它改完再贴回来。整个过程不需要理解任何构建工具。

数据所有权:本地文件,不依赖平台

README首页写着:

Own your data as plain local files.
Own the software that opens those files.
Grow your personal workspace with files.
Grow the software around it with an LLM.
Local files and owned software last ages.

翻译过来:数据是本地.md文件,软件是你能看懂并修改的HTML+Go。不依赖任何封闭平台。你甚至可以只用一个文本编辑器来处理笔记,files.md只是提供一个更快的输入入口。

这种设计有个实际的好处:你不用担心平台关停或收费。因为你的数据是标准Markdown文件,放在你自己的文件夹里。软件是纯HTML+Go,编译成二进制就能跑,不存在“开发者停止维护你就拿不到数据”的问题。

移动端:只有Telegram机器人

手机端没有原生App,只有Telegram机器人@FilesMDBot。发消息给机器人,内容直接同步到你的文件夹。

机器人能搜索文件、列目录、创建日程。READEME自己说“It’s much simpler than that by default”,意思是基础功能就够用,不需要搞复杂。

【实际场景】你在外面,突然想到要买牛奶和鸡蛋。打开Telegram,发给机器人“买牛奶 鸡蛋”,电脑上立刻生成一个checklist文件。回家打开电脑,在文件夹里就能看到。中途不需要打开任何App,不需要想文件名叫什么,不需要决定放哪个笔记本。

不过,移动端功能有限。你无法查看、编辑文件内容,只能发送文本和接收机器人返回的文件列表。别指望读取PDF、富文本、图片。如果需要一个完整的移动笔记体验,这个点可能是硬伤。

适合谁?不适合谁?

【适合】

  • 你受够了复杂笔记工具的配置和同步问题,想要一个本地存储、离线可用的极简方案
  • 你习惯自己管理文件夹结构,不需要智能标签和自动目录
  • 你想让笔记流程的摩擦最小化,从“想到”到“写下”越快越好
  • 你懂一点HTML/JS,想根据自己的需求修改前端
  • 你需要一个LLM友好的代码库,方便快速定制

【不适合】

  • 你需要日历、看板、富文本、团队协作
  • 你需要自动标签、智能搜索、知识图谱
  • 你需要一个完整的移动端体验
  • 你不想动手操作文件系统和文件夹

files.md不是一个通用笔记应用。它是一个个人工具,开发者自己用了五年,打磨到只剩最必要的部分。2196个star说明这种极简主义有受众。如果你追求“打开就能写、写了就存、改了就同步”,这是一个干净的起点。如果你需要更多组织功能,它可能反而让你难受。

这篇文章对你有帮助吗?

发表回复