zakirullin/files.md

GitHub: zakirullin/files.md

一个私密的本地优先Web应用,用于管理Markdown格式的个人笔记、日记和任务。

Stars: 3323 | Forks: 145

Files.md icon # 文件.md 私密、安静的思考空间。一个用于管理您 `.md` 文件的简单应用。 Files.md screenshot 您可以存储整个生活: - 📌 笔记 - 📝 文档、项目 - 💚 日记、习惯 - ✅ 清单、任务 全部使用纯文本 `.md` 文件,本地优先。对 LLM 友好。**私密 - 不向服务器发送任何数据**。 试一试:[app.files.md](https://app.files.md)(测试版)。主站:[files.md](https://files.md)。 您可以将此应用用于卡片笔记法、第二大脑、笔记、日记、待办清单、检查清单等。 [倾倒你的想法](#dump-your-thoughts) · [如何深度思考](#how-to-think-deeply) · [第二大脑?](#second-brain) · [日记、任务和检查清单](#journal) · [文件结构](#files-structure) ## 又一个笔记应用? 也许吧。但这次不同: - 只保留必要功能,**限制催生创造力** - 免费且开源 - 无需安装任何东西,只需一个浏览器 - 支持离线使用 - **本地优先,文件不会离开您的设备** - 代码极其简单。**一个人或一个 LLM 能完全理解整个项目** - 代码库已准备好供您的 LLM 扩展以满足需求 - 便携,无构建系统,无 Electron,直接打开 `web/index.html` 即可 - 可选的开箱即用同步功能 - 服务器仅需一个二进制文件(或使用 iCloud/Dropbox/Google Drive 进行同步) - Telegram 聊天机器人,随时随地访问您的文件 - **聊天式流程,轻松捕捉想法** ## 如何使用 - 打开 [app.files.md](https://app.files.md) - 点击地址栏右侧的“Install files.md”:
Install
- 打开一个本地文件夹以持久保存更改 - 偶尔按一下强制刷新(`Cmd+Shift+R`)以获取新更新。 ## 倾倒你的想法 您可以使用聊天功能快速倾倒您的想法。
Files.md screenshot
打开聊天并发送消息:
选择保存位置(可以稍后操作):
**通过此流程,您可以快速保存笔记、任务、日记记录和检查清单**。 ## 在聊天机器人中保存内容 打开聊天,写点东西并按 `Enter`:
Saving things in bot
就这样。 ## 如何深度思考 **连接想法。让它们复合。深入思考。** 1. 我使用 [app.files.md](https://app.files.md) 来增长关于大脑和软件开发的知识 2. 我将新笔记添加到 `brain` 或 `dev` 文件夹。一个笔记一个想法 3. 我在 Web 应用中将相关笔记连接起来(输入 `[`) 4. 一切都相互关联,就像我们的大脑一样 5. **我花时间在笔记中穿梭并深入思考** 6. 某个时刻,一些 `brain` 和 `dev` 的笔记看起来非常相关 7. 这两个不同领域之间的联系产生了洞见 8. 我基于该洞见写了一篇文章:[软件开发中的认知负荷](https://github.com/zakirullin/cognitive-load) 所有这些活动帮助我: - **深度思考**(这在人工智能时代非常重要) - **系统性思考并看到全局** - **写出有见地的文章** 要实现所有这些,**你必须使用你的大脑**,而不是高级模板或 AI 工作流。 - 从完全无结构开始,0 个文件夹 - 一个笔记一个想法 - 每个笔记都应在无需上下文的情况下被理解 - 立即应用新知识,不要为未来的自己保存 - 链接相关笔记 - **重温你的笔记并深入思考** 我和我的朋友们使用这个简单的设置已经五年了,效果很好。 ## 第二大脑? 我引用[《我删除了我的第二大脑》](https://www.joanwestenberg.com/i-deleted-my-second-brain-692aa40d59d5f06dd5131e43/): 第二大脑令人兴奋。 高级导师模板、插件和 AI 工作流... 人们想要抓取整个互联网的智慧。 在这个整齐的系统中有某种美感。每个新笔记都带来多巴胺。 *第二大脑正在变得更好。* **但第一大脑没有进步。** 而这正是问题所在。 在人工智能时代,你的第一大脑和以往一样有价值。 用**你的大脑**深入思考笔记。 工具不重要,你的思考才重要。 在添加新笔记之前,尝试回答这些问题: - 这个新知识如何能锐化我的判断力或扩展我的分类? - 给定这个新知识,我怎样才能以不同的方式看待世界? - 我可以怎样采取不同的行动? ## 笔记可能会阻碍体验 - 阅读和做笔记很容易让我们误以为自己理解了一个文本 - 我们认为我们理解了,但实际上**我们只是知道** - **在某种程度上,我们的“知道”是如此之好,以至于我们开始感觉自己真的在做(或至少尝试过)** - 最糟糕的是,**我们不会让新的体验出现,因为我们已经拥有知识**。这是知识壁垒。生活给我们机会去经历新的体验,但我们拒绝了,因为“我们已经知道了”。 ## 通过阅读和做笔记来自助? **情感层面造成的伤害必须在情感层面治愈。** 不是通过智力工作和做笔记。 阅读而不行动是娱乐。一种拖延的形式。 **再多的自助书籍也无法治愈情感创伤。** 能帮助的是心理治疗、重写脚本和椅子疗法、冥想。 **治愈是通过感受发生的。** ## 何时做笔记 如果您的目标是: - 对某事物发展更深入、更有结构的理解 - 进行研究 - 写文章或书籍 那么做笔记是完全可以的。 ## 日记 您对某事感觉良好吗?发送消息。
然后点击“转到日记”。 或者在消息末尾添加 ` jj` 或 ` жж`。 您的记录将被妥善保存在 `journal/YYYY.MM 月.md` 文件中。 ## 任务 ✅ 您正处于心流状态。 同事让您发送报告。 将这件事记在脑子里会消耗精力。 发条消息然后保持心流状态。
只添加小的、可操作的项目。不要像“计划假期”这样的事情。 您的任务应该是无论如何都应该做的第一步,一个小小的步骤。 **不是你希望完成但还没有动力去做的事情。** 您的任务列表不应该制造负罪感。 对于稍后应完成的任务,按“稍后”。 ## 检查清单 🛒 朋友向您推荐一本书。 您的黄油和面包卷用完了。 在脑子里记着这些东西很费力。 将所有内容丢到聊天中,然后移动到相应的检查清单。 ## 如何同步 | 设置 | 文件存储位置 | 跨设备同步 | 需要服务器 | 最适用于 | |---|---|---|---|---| | **本地优先**,`app.files.md` 不发送任何数据 | 您设备上的文件夹 | 否 | 无 | 最大限度隐私,数据不离开您的设备 | | **云文件夹同步** (iCloud/Dropbox/Google Drive) | 您现有的云文件夹 | 是 | 无(云提供商) | 无需运行服务器即可跨设备同步 | | **[自托管同步服务器](docs/your-own-server.md)** | 您自己的(或本地)服务器 | 是 | 一个 Go 二进制文件 | 在您的网络内跨设备同步 | | **托管同步服务器** | 我们的托管服务器 | 是 | `api.files.md` | 即时试用,无需设置 | ## 文件结构 您不必考虑结构,它是预定义的。 不过,您可以自由使用任何您想要的结构。 - 聊天:`Chat.md` - 笔记:`brain/Note.md`、`<类别>/*.md` - 项目:`Project.md`、`*.md` - 检查清单:`Read.md`、`Watch.md`、`Shop.md` - 日记:`journal/2024.08 八月.md` - 任务:`Later.md` - 习惯:`habits/Ate consciously.md`、`habits/*.md` - 图片:`media/*` (png, jpg, webp, gif) - 归档:`archive/*.md` - 配置:`config.json` 方案也可在 [files.md/llms.txt](https://files.md/llms.txt) 获取。 您可以将其复制粘贴到 `CLAUDE.md` 或 `AGENTS.md` 中,以便您的 AI 智能体理解该结构。 ## 快捷键 | 快捷键 | 操作 | |---|---| | `[` | 插入文件链接 | | `Cmd+K` / `Ctrl+K` | 打开文件搜索模态框 | | `Cmd+N` / `Ctrl+N` | 新建文件 | | `Cmd+M` / `Ctrl+M` | 移动文件 | | `Cmd+D` / `Ctrl+D` | 删除文件 | | `Cmd+Enter` / `Ctrl+Enter` | 打开聊天 | | `Cmd+Shift+Enter` / `Ctrl+Shift+Enter` | 切换聊天对话框 | | `Cmd+[` / `Ctrl+[` | 转到上一个文件 | | `Cmd+]` / `Ctrl+]` | 转到下一个文件 | | `Cmd+~` / `Ctrl+~` | 切换侧边栏 | | `Cmd+B` / `Ctrl+B` | 切换**粗体** | | `Cmd+I` / `Ctrl+I` | 切换*斜体* | | `Cmd+Y` / `Ctrl+Y` | 插入复选框 | | `Cmd/Ctrl` + `点击` | 复制内联文本 / 打开链接 | | `Ctrl+Cmd+Space` | 插入表情符号 (macOS) | ## 用于文件的实用脚本 所有脚本都在 `cmd` 中,可以在**您的文件目录内**运行。首先安装 [Go](https://go.dev/doc/install)。 ### 将 Whoop 指标添加到日记 ``` go run /abs/path/to/files.md/cmd/whoop/whoop.go ``` ### 将 Wiki 链接转换为 Markdown 链接 将 `[[wikilinks]]` 转换为标准的 `[Name](/path.md)` (提供 `--dry-run` 选项): ``` go run /abs/path/to/files.md/cmd/tomdlinks/tomdlinks.go . ``` ### 插入反向链接 添加指向引用文件的链接(提供 `--dry-run` 选项): ``` go run /abs/path/to/files.md/cmd/backlink/backlink.go ``` ### 调整日记时间戳 将日记文件中的时间戳移动 N 小时(时区变更后有用): ``` go run /abs/path/to/files.md/cmd/shifttime/shifttime.go ``` ## 文档 [部署在您自己的服务器上](docs/your-own-server.md) [聊天机器人](docs/bot.md) [同步流程](docs/sync-flow.md) [端到端测试](docs/e2e-tests.md) ## 仓库结构 - `web` - Web 应用 (PWA),`index.html` 是入口点 - `web/lib` - 前端库 - `cmd/server` - 服务器入口点 - `cmd/*/` - 用于 `.md` 文件的实用脚本 - `server/bot.go` - 机器人 - `server/sync/` - 同步 API 服务器代码 - `vendor` - 后端库 - `tests` - 端到端测试,同时测试 Web 应用和服务器 ## 后端指南 - 我们编写**测试** - 方法不使用 get* 前缀 - 无 panic,错误是业务逻辑的一部分 - 如果我们忽略错误 - 我们会留下 WHY 注释 - 我们一直包装错误,应该添加方法的上下文 - 客户端代码不使用迭代器 - 我们更喜欢真实实现或至少是 fakes,而不是 mocks 和 stubs - 导入仅重命名以避免与其他导入的名称冲突 - **出于可移植性考虑,所有内容都存储在纯文本 `.md` 文件中** ## 前端指南 - 如果您就地修改库,请使用 `PATCHED` 关键字 - **如果有一天我们能用自己微小的实现替换 `CodeMirror`,那就太好了** - 无构建系统,**10 年后我们打开 `/web/index.html` 它应该能正常工作** - 不要忘记,锁检查和锁获取之间的 `await` 可能导致竞态条件 - 避免不稳定的端到端测试。首先我们会有负面情绪,然后我们就停止运行所有测试 - 大多数错误是由竞态条件引起的,当异步流程在中间被中断时 ## 术语表 - `filename` - 带扩展名的文件名,如 "note.md"(用作 ID) - `header` - 去掉扩展名并大写的文件名,如 "Note" - `body` - 文件内容 - `dir` - 一个旨在存储某个类别下笔记的目录,如 "happiness" - `userID` - 聊天 ID。大多数情况下我们只使用聊天 ID 作为用户 ID(与机器人的私聊) - 文件的 `ctime` - 数据块或元数据更改时间:文件的所有权、位置、文件类型和权限设置更改时间。重命名父文件夹不影响,移动文件会影响,重命名文件会影响。我们需要这个来跟踪文件位置的更改,比如理解它何时被移动到归档,跟踪任务的紧迫程度等 - 文件的 `mtime` - 文件的 mtime(修改时间)指的是文件内容最后一次被修改的时间。与 ctime 不同,它不受文件元数据更改的影响,例如所有权、权限或重命名。我们依靠这个进行同步。 - 目录的 `ctime` - 添加或删除文件或子目录(类似于 `mtime` 加上 inode 更改,如重命名文件) ## 性能 这个项目非常快 :) 如果您出于性能原因担心不必要地使用文件或互斥锁,请看这个: ``` Mutex lock/unlock = 25 ns Read 4K randomly from SSD = 150,000 ns 1 ms = 1,000,000 ns ``` ## ADR(架构决策记录) - `24.05.2026` 立即展开视口中的所有内容(图片、数学公式、Mermaid)。这可以防止闪烁并且不会带来性能损失。附注:我们还应该在视口变化时安排完整文档展开,否则视口外的 LaTeX/Mermaid 块将不会被折叠。 - `22.05.2026` 添加了 Mermaid 支持。决定延迟加载脚本,因为 mermaid.min.js 大小为 3MB。对于这样一个小应用来说,同步加载是相当大的负担。 - `20.05.2026` 添加了 LaTeX 支持,尽管我对增加 20 个字体文件并不满意。LaTeX 是基于文本的且对 LLM 友好。文本 + 数学几乎可以覆盖所有内容。 - `06.05.2026` 从 Today.md 迁移到 Chat.md。客户开发显示用户难以理解“今天”的概念。此外,“打开聊天”这个短语在机器人和 Web 应用中都有意义。 - `02.05.2026` 现在 hide-token 在每次更改时同步运行,之前有 100 毫秒的防抖,这导致在按词删除链接和格式化文本时出现抖动。 - `02.05.2026` 将 Inbox.md 和 Today.md 合并到 Today.md。收件箱名称太抽象、太注重生产力、太 GTD 了。我想要平静和简单。今天就像“我在聊天中生活的页面”。 - `23.04.2026` 从 API_HOST、APP_HOST 迁移到 API_URL、APP_URL。对于不同环境,最好在配置中提供更多信息,如期望的方案。 - `22.04.2026` 机器人中的收件箱条目现在通过稳定的内容哈希(剥离 `- [ ] `/`- [x] ` 标记的块的 `fs.Hash`)而不是位置索引来标识,因此即使其他条目被添加/删除/完成,按钮仍指向正确的行。 - `22.04.2026` 看到两个按钮/消息“转到收件箱”和“转到聊天”在精神上很费力,它不如直接丢弃任务到聊天那样在精神上轻松。因为它去了收件箱,还需要多点击一次。那一次点击就是添加新任务变得令人沮丧的原因。我放弃了两种不同的流程,现在所有内容都转到收件箱,收件箱中的每个项目都是一个 Markdown 检查列表项目。另外,PWA 应用现在非常方便,因为它默认显示聊天的任务。另外,也许“收件箱”是一个精神上过载的术语,“聊天”听起来更好。走着瞧。 - `11.04.2026` 尽管我想将链接存储为纯 Markdown 链接,但在视觉上我想将它们当作最小的 [links] 来处理。为此,我决定在光标位于该行时隐藏 (...) 部分。(...) 部分仅对 Markdown 文件链接隐藏。 - `11.04.2026` 恢复了标准的 Markdown 链接。我希望知识库是跨平台的。它应该在 GitHub 上工作。 - `05.04.2026` 为了简单起见,尝试将 web/* 内容移到根目录。糟糕的决定——应该有一个明确的目录,我们可以将其用作服务器上的公共文档根目录。 - `21.09.2025` 切换到 [link] 表示链接。`[link](full%20path)` 语法过于繁重和笨拙,而且我们不想处理路径更改。 - `21.09.2025` 移除了 WASM。当一条消息从 Inbox.txt 中移除但未添加到文件(我按了“移动到文件”按钮)时,我遇到了一个错误。我无法重现该问题,但我发现了很多复杂性。JS -> Go (writeFile) -> Go 等待 JS 的承诺 -> 某处的 JS Golang 运行时 -> JS (writeFile) -> Go (从承诺返回) -> 将结果发送回 JS。这必须在一个单独的 goroutine 中完成,因为 WASM 和 JS 都在同一个线程中运行。此外,Golang 的 WASM 仍然是实验性的。我们有太多组件和大量的不确定性。当时我不想用 JS 重新实现相同的功能,该解决方案运行了一段时间。现在是时候用 JS 重新实现功能并放弃所有这些复杂性了。此外,inbox.wasm 约 8MB,我希望应用程序非常小。 - `11.07.2025` 决定使用 OPFS 作为文件系统的初始驱动程序。更好的浏览器支持,为用户减少麻烦。应用默认从 OPFS 驱动程序启动,如果需要,用户可以通过打开本地目录将其替换为本地文件系统 API。在这种情况下,DirHandle 将被保存到 IndexedDB 并在每次使用时重复使用。 - `08.07.2025` 根文件夹现在是 '/',而不是 ''。Web 应用中的所有文件都通过路径标识,而不是通过 'dir' + 'filename',限制为 1 级嵌套。 - `08.07.2025` Dropbox 会更改新创建文件的某些元数据,因此 ctime 会改变。我考虑过迁移到 mtime 进行同步,但这将不允许我们检测重命名(不过,我们通过单独的机制检测它们),所以 mtime 可能更可靠。此外,同步不会由权限/所有权更改等触发。迁移到 mtime。Mtime 用于基于内容的同步,ctime 用于仅追加同步日志(重命名/删除)。另外,我们可以从 .git/archive 恢复 mtime,而 ctime 不行。 - `30.06.2025` 决定将每个流程迁移到 Chat.md,甚至是待办事项列表。补充 - 使用这种流程我们无法处理多行任务,我们可能希望同时支持文件和索引。我们有两种方法 - 以统一方式编码参数,并使用带有 IF 的相同命令处理程序。或者我们可以使用不同的命令处理程序来处理聊天/文件移动。我决定采用不同的命令处理程序。补充,如果我们采用不同的命令 - 移动到按钮的配置会很复杂。补充,也许我们可以在“文件移动”时将文件移回 Chat.md,并重用现有流程?补充,到目前为止看起来不错。我们的 Chat.md 日志充当仅追加日志。作为奖励,如果我们没有完成某些流程(如安排/移动),内容将保存在日志中,我们可以从应用中继续安排/移动。 - `29.06.2025` 现在所有传入消息默认都转到 Chat.md。在此之前,它们被移动到 `/today`(并变成任务),这对于简单的待办事项列表很好,但对于其他用例不太方便。我意识到在会议期间,我所需要的只是一个简单的输入字段,可以在那里丢弃脑子里的任何东西,而不需要立即采取进一步的行动。并可以稍后审查和组织它。它可以是任务,可以是日记记录,也可以是文件。此外,最好有一个真正简单、易于理解的默认流程 - 我们将所有消息转储到一个文件中,就这样。 - `27.06.2025` 聊天的默认模式现在是“一个大文件”,即它唯一做的就是将所有消息转储到一个文件中。再次强调,让我们从最简单的流程开始,不要让用户不知所措。补充,稍后。如果我们选择完整模式,我们将必须预先创建目录,以便“转到习惯”、“转到阅读/购物”等可以工作。如果用户不需要它,他删除了目录,我们就不会重新创建它们(就像我们在“按需模式”中所做的那样)。所以,我们不能在任何地方使用按需策略。 - `26.06.2025` 之前我们预先创建了所有必要的目录,现在我们按需创建目录。这样我们从一开始就不会弄乱用户的知识库。 - `24.06.2025` 切换到微秒来跟踪同步期间的文件更改。连续文件创建之间的间隔绰绰有余——从 5000μs 到 1000μs 不等。我们没有选择纳秒,因为 js 在 int64 精度上有问题。补充,稍后。Linux 使用缓存的内核时间,该时间在 `CONFIG_HZ` 间隔更新(`grep CONFIG_HZ /boot/config-$(uname -r)`),在我的情况下该值是 1000(1ms)。大多数现实世界的操作间隔远大于 1ms,原因包括:用户交互、网络延迟、磁盘 i/o。只有在有效/本地循环内更新文件时,我们才可能遇到问题。 - `16.06.2025` 我认为是时候让我们的知识库跨平台了,通过禁止文件名中使用 ":?<>*" 等字符。这些字符在某些环境中(如 Windows、PWA)是不允许的。 - `14.06.2025` 我想要在浏览器中实现类似机器人的功能。我不想用 TypeScript 重写经过充分测试的代码,所以我使用了 wasm~~。它工作得非常好。 - `12.06.2025` 我们使用 Telegram 机器人作为免打扰的只写入口进入我们的知识库。唯一的问题是,它在欧盟/美国并不那么流行。我想到一个主意,一旦我们缩小窗口大小,我们就可以将 app.files.md 转换为聊天界面!在移动设备上这将是默认行为。 - `04.06.2025` 引入了仅追加日志用于同步。无状态同步很难实现——我们必须在每个请求中发送所有文件。由于我们只在服务器上重命名——我们将只跟踪重命名。 - `04.06.2025` 对于仅内容同步(无重命名/删除),我们在服务器上不存储任何状态,我们比较哈希和最后的 ctimes。 - `11.11.2024` 移除了 Wiki 链接支持。只支持纯 Markdown 链接,我们的知识库必须是可互操作的。 - `26.10.2024` 更新现在按用户顺序处理。因为并发文件写入时存在一些竞态条件。我们还遇到了乱序转发消息的处理,无法将它们折叠为一条消息。 - `06.10.2024` **移除了 fyne.io**。起初,我想要一个轻量级的 Electron 替代品,fyne.io 似乎是一个理想的候选者。使用几天后实现了 80% 的机器人功能,我对此相当满意。问题是,要实现剩余的功能,我们必须付出巨大的努力。我说的是诸如滚动、表情符号渲染、文本选择行为、链接支持等细微差别。将来我们还必须实现图像上传和 Markdown/HTML 渲染器,在这种非基于 Web 视图的工具包中这也会很痛苦。尽管我讨厌将 Web 技术栈用于桌面应用程序,但我们似乎别无选择。试试 wails.io。 - `09.09.2024` 我们使用 vendoring 处理依赖项。我们希望将所有少量的依赖项都放在仓库中,这样我们就不关心被阻止/移除的依赖项。我们的仓库是自给自足的事实来源。 - `01.09.2025` 我们使用细粒度锁(在数据库、日记、用户配置中),而不是每个用户一个全局锁,以避免瓶颈。工作人员可能使用像 ChatGPT 这样的第三方 API,我们不想在那段时间一直持有用户的锁。**已修补**,我们添加了顺序的每用户更新处理,`bot` 本身不会引起竞态条件,但 `bot` 和 `worker` 会,因此我们应该继续使用细粒度锁。 - `20.08.2024` 我们在每次访问时都从配置文件中读取每个用户配置值。我们不需要在 `bot.Answer()` 方法之前/之后加载/保存整个配置。我们每次需要更改时都必须重新读取它,这样我们就不会写回任何陈旧的数据。想象一下,我们只在 `bot.Answer()` 之前加载一次配置,接下来,在 `bot.Answer()` 中可能会有显著的网络延迟(比如在发出外部请求时 2 秒),很有可能在这 2 秒内 `worker.MoveDueTasks()` 会修改 `userconfig.Schedule`,导致数据竞态(在 bot 回答后我们写回陈旧数据)。而我们不希望我们的日程安排丢失。 - `08.08.2024` 尽早净化,我们放弃了在 Path 方法中净化。这是意想不到的行为——它会破坏路径。我们应该在收到后立即净化所有内容。大多数命令都使用 md5 哈希,对于这种情况不需要净化。 - `13.07.2024` 使用 `gofumpt` 进行更严格的格式化。`gofumpt` 对 gofmt 满意的格式子集感到满意。我们越少在不同格式选项之间选择越好。 - `13.07.2024` 文件系统结构应该有 userFS 名称,以反映它是用户命名空间的。 - `09.07.2024` “笔记”这个术语太模糊了。让我们尝试使用“文件”这个术语,没有任何高级抽象(如笔记)。 - `08.07.2024` 放弃了 AST 解析/渲染。我们通过 AST 遇到了很多边缘情况,代码非常复杂。Markdown 解析并不那么难,我们可以通过简单直接的代码来完成。我们现在代码量减少了三倍,理解起来在精神上也轻松得多。MD->HTML 转换我们也做了同样的事。Telegram 不支持全部 HTML 标签,所以编写我们自己的 md-to-html 转换器更容易。 - `08.07.2024` 遵守宽容读者原则。如果在解析过程中遇到乱码——我们跳过它,但如果我们遇到有效数据的标志(比如 `###`)但数据本身无效——我们会 panic。TODO 在读写周期中保留乱码。 - `07.07.2024` 使用 https://github.com/rivo/uniseg。在 Go 中,字符串是字节的只读切片。它们可以使用 for 循环或强制转换:`[]rune(str)` 转换为 Unicode 码点。然而,多个码点可能组合成一个用户感知的字符或 Unicode 规范所谓的“字形簇”。例如,白色圆圈“⚪”有两个 rune,但一个字形簇。 - `6.2024` Markdown 到 HTML 的转换。用户的笔记中可能有无效的 Markdown,TG API 无法直接发送无效的 Markdown。因此,首先我们转义 HTML,然后将用户的 Markdown 转换为 HTML,最后通过 Telegram API 作为 HTML 发送。 - `13.06.2023` 文件哈希。在有用户输入的地方——我们都应该使用 fs.hash,否则我们会得到长文件名,tg 会返回 `INVALID_DATA` 错误(callbackData 最大 64 字节)。 - `13.06.2023` 引入了 `db.go`。无论如何我们都必须抽象掉 Redis(否则很难编写测试)。 - `13.03.2023` 包 db.go 不存储 userID(我们经常单独使用它...)我们是吗?也许我们会在没有 userID 的情况下使用它(比如全局机器人统计数据?)。补充:将 userID 移到类中。也许稍后我们需要在用户范围之外使用这个类,但让我们将来再说。:) - `13.06.2023` 我们无法在 fs.Put 中 ucfist 文件名——如果那是用户创建的文件(在机器人之外),即它是小写的怎么办。
标签:EVTX分析, LLM友好, Markdown文件管理, Web技术, Zettelkasten, 个人知识管理, 习惯跟踪, 任务管理, 可扩展性, 多模态安全, 效率工具, 数据可视化, 日志审计, 日记应用, 本地优先, 极简设计, 浏览器应用, 清单工具, 离线工作, 笔记应用, 第二大脑, 简单应用, 网络安全, 防御加固, 隐私保护