之前主要用 Obsidian
最近在云服务器上部署了 Outline 也蛮好用的，有浏览器就可以访问，可以和家人协作编辑文档、搜索功能不错，历史版本功能可以防止误删很实用。只要定期备份 Postgres 数据库和附件就可以了。计划长期用这个了。

Caffeine

根据网上分享的资料来看，美签面试官主要考量的是“滞留风险”，DS160 和面试过程必须能充分证明“必须回来”。

WordPress 建站效率可能比用 Django 来的更好

如果一定想用 Django 栈，可以试试 Wagtail 。

GraphRAG 的关系图应该可以满足楼主的需要，只是这个东西对 embedding 的消耗会比较大，每次新增内容都会重新计算它与现有资源的关系。增长不是线性的，但 token 消耗量会有相对固定的模式。比如最近一次的消耗量是 50k token ，要新增一个 2000 字的文本文件，它也可能会有 50k 左右的消耗（主要取决于内容的关联度，不是一定的）。

简言之，对计算资源的消耗要有心理准备，但值得一试。

大概小学二三年级的样子，自己在院子里踢球玩。突然感觉天黑下来了，心里有个声音很急促告诉我“往前踢，追上去”，我照做了，追出去没多远，身后轰隆隆像地震一样，回头一看，邻居家的砖墙整整齐齐的砸到我刚刚站的那个位置。

如果当时没照做，就没有此刻打字的这个人了。

obsidian + anytype

immich

- 这个配置恐怕满足不了 25 人同时使用的需求
- 多种需求尽量解耦，所有应用捆在一个设备上，容易出大问题；
- 公共环境各种系统和软件尽量用正版，除非确定自己可以承担相应后果；

可以考虑的方案：

- 单独一个设备专门做软路由
- NAS 开 Samba 共享做公盘，控制好权限和历史版本（防误删）；
- 照片墙也可以部署在 NAS 上，用 photoprism 、immich 等开源项目就可以；
- 单独一台高配设备部署开源网盘
- 注意数据和设备的备份冗余，应对随时可能出现的故障；
- 网络（网卡、线路、交换机）不能拖后腿

要不要问问外卖员？说不定有截然不同的方案。

有没有可能它们用的是上游 API

省钱的话可以在 14 号线两个终点站找房，只要房子离地铁站足够近。

折腾一下吧，我记得自己上大学时候也是这样天马行空的设想很多可能性。

用迷你主机当服务器有几个潜在问题：
1. 对外访问。如果拿不到公网 IP ，仍然需要云服务器做反向代理。
2. 硬件运维。主机放在什么位置，网络是否稳定，电源供应，以及潜在的火灾隐患也要考虑。

习惯性用 docker ，一方面是应用隔离，另一方面是“干净又卫生”。

tailscale

如果情况允许，可以在香港开一个银行卡，汇丰、众安都可以给 Wise 入金。

Llama3 70B：

这是一个有趣的问题！😊

让我们分析一下小智每天可以添加的宝可梦数量：

* 3 只、4 只或 5 只

我们可以尝试找到一个模式，使小智恰好收集到 100 只宝可梦。

首先，我们可以找到一个循环模式，使小智每天添加的宝可梦数量不同：

Day 1: +3
Day 2: +4
Day 3: +5
Day 4: +3
Day 5: +4
...

这个循环模式可以重复，直到小智收集到 100 只宝可梦。

现在，让我们计算小智需要多少天来收集 100 只宝可梦：

3 + 4 + 5 = 12
12 × 8 = 96
还差 4 只，所以下一天小智需要添加 4 只宝可梦。

因此，小智至少需要 25 天来收集 100 只宝可梦。

Deepseek-v2 Q4:

首先，我们需要考虑小智每天捕捉宝可梦的可能性。由于他不能在连续的两天内捕捉相同数量的宝可梦，我们可以将这个问题分为几个部分来解决：

- **如果小智每天都捕捉 3 只宝可梦**，那么他需要的天数是 100/3=33.33 天（向上取整到最接近的整数）。这意味着他至少需要 34 天才能捕捉到 100 只宝可梦。

- **如果小智每天都捕捉 4 只宝可梦**，那么他需要的天数是 100/4=25 天。在这种情况下，他不需要 34 天。

- **如果小智每天都捕捉 5 只宝可梦**，由于这个数量超过了每天可能的捕捉上限（最多 4 只），因此这种情况不可行。

现在，我们需要计算哪种情况最少需要的天数。显然，每天捕捉 4 只宝可梦的情况所需的天数最少，因为它少于 34 天。所以：

- 小智至少需要 25 天才能捕捉到 100 只宝可梦。

app 便于功能复用，实现功能之间的高内聚和低耦合。比如你提到的，用户中心（登录、注册等）这个就可以通过创建 users 应用来实现。