即刻App年轻人的同好社区
下载
终于算是切身体会到 AI 视频制作有多花钱了。就这么一条 30 秒不到，输出预期还特别明确的视频，前后应该花了 ¥200 了。（不过这对 AI 视频制作团队还是赚的，毕竟这点💰要找人，一个人应该都下不来）
不过还是挺有意思的，也差不多摸到 AI 制作视频的门道了。好玩好玩。
不过还是挺有意思的，也差不多摸到 AI 制作视频的门道了。好玩好玩。
00:28
6 20
虽然现在还不能用 AI 做产品挣钱，但是起码，可以省钱。
让 Codex 复刻一个 Flomo 并支持 MCP，导入我所有 Flomo 的记录，好了，flomo max 一年 ¥200 的💰省下来了。 做完正好赶上 Codex reset。
让 Codex 复刻一个 Flomo 并支持 MCP，导入我所有 Flomo 的记录，好了，flomo max 一年 ¥200 的💰省下来了。 做完正好赶上 Codex reset。
2 11
好奇的问一件事，大家用远程操作 Codex 或者其他应用的时候，如果它启动了一些本地的服务，比如说本地启动的开发服务，手机远程看不到的话，怎么去验证它的结果呢？让它去截图吗？
1 00
使用 github.com给我的 CodeX 换一个 GT7 和 F1 风格的背景：
2 00
grok build 开源，感觉这一手操作有点神之一笔呀。前两天看它自动上传代码仓库，我就果断的把它删掉了，而且当时想的是完全不可能再装回来。他这一开源，先是收割一波流量不说，还把大家之前对它丧失掉的信心，用成本最低的方式、相对最有效的方式补回来了。堪称危机公关典范了。而且还能让全球的程序员给他修 bug。
GitHub - xai-org/grok-build: SpaceXAI's coding agent harness and TUI. Fullscreen, mouse interactive, extensible.
2 32
00:14
4 20
我一直有个很烦的小问题。
Obsidian 是我真正想长期沉淀东西的地方。本地文件、双链、结构、长期知识库，都很舒服。
但工作里的很多文档又天然在飞书里：需求、方案、协作、评论、权限、多人编辑。
于是每天就在两个软件之间来回切：在 Obsidian 里想起“这个方案其实在飞书”；打开飞书搜一遍；回到 Obsidian，又忘了哪个本地笔记对应哪个飞书文档。
有一阵子我甚至在纠结：到底该完全用飞书，还是完全用 Obsidian？
后来想明白了：成年人当然是全都要。
所以做了 Lark Doc。
它会在 Obsidian 里创建很轻的 `.lark.md` 文件。这个文件留在本地 vault 里，保存飞书文档的元信息；但你点击它的时候，会直接在 Obsidian 里用 WebView 打开对应的飞书文档。
更重要的是，`.lark.md` 本质上仍然是一个普通文本文件。它的原始内容不是飞书文档的副本，而是一段给 AI 的说明：告诉 AI 如何通过 Lark CLI 读取这个飞书文档的最新内容。所以这里不需要做复杂的双向同步；AI 看到这个本地文件时，也能知道该去哪里拿到远端文档的最新版本。就像这样：
> **Shadow File** - This note is a local proxy for a Lark or Feishu wiki document.
>
> **Wiki URL:** www.feishu.cn
>
> **Node info (via lark-cli):**
> ```bash
> lark-cli wiki spaces get_node --params '{"token":"xxxx"}' --format json
> ```
>
> This file contains only front matter metadata. The full content resides in Lark and can be viewed at the wiki URL above.
这样飞书文档还是飞书文档，保留协作、评论、权限；Obsidian 也还是 Obsidian，保留本地文件、链接、索引和长期沉淀。
现在支持：
- 点击 `.lark.md` 直接打开对应飞书 / Lark 文档
- 重复点击复用已有标签页，行为像普通 Markdown
- 从已有飞书链接创建本地关联文件
- 从 Obsidian 创建新的飞书文档
- 同步远端标题和本地文件名
- 自动生成 `Lark Documents.base` 管理所有关联文档
GitHub：github.com
下面两张图会更直观：一张是文档直接在 Obsidian 里打开，另一张是 Bases 里的关联文档索引。
Obsidian 是我真正想长期沉淀东西的地方。本地文件、双链、结构、长期知识库，都很舒服。
但工作里的很多文档又天然在飞书里：需求、方案、协作、评论、权限、多人编辑。
于是每天就在两个软件之间来回切：在 Obsidian 里想起“这个方案其实在飞书”；打开飞书搜一遍；回到 Obsidian，又忘了哪个本地笔记对应哪个飞书文档。
有一阵子我甚至在纠结：到底该完全用飞书，还是完全用 Obsidian？
后来想明白了：成年人当然是全都要。
所以做了 Lark Doc。
它会在 Obsidian 里创建很轻的 `.lark.md` 文件。这个文件留在本地 vault 里，保存飞书文档的元信息；但你点击它的时候，会直接在 Obsidian 里用 WebView 打开对应的飞书文档。
更重要的是，`.lark.md` 本质上仍然是一个普通文本文件。它的原始内容不是飞书文档的副本，而是一段给 AI 的说明：告诉 AI 如何通过 Lark CLI 读取这个飞书文档的最新内容。所以这里不需要做复杂的双向同步；AI 看到这个本地文件时，也能知道该去哪里拿到远端文档的最新版本。就像这样：
> **Shadow File** - This note is a local proxy for a Lark or Feishu wiki document.
>
> **Wiki URL:** www.feishu.cn
>
> **Node info (via lark-cli):**
> ```bash
> lark-cli wiki spaces get_node --params '{"token":"xxxx"}' --format json
> ```
>
> This file contains only front matter metadata. The full content resides in Lark and can be viewed at the wiki URL above.
这样飞书文档还是飞书文档，保留协作、评论、权限；Obsidian 也还是 Obsidian，保留本地文件、链接、索引和长期沉淀。
现在支持：
- 点击 `.lark.md` 直接打开对应飞书 / Lark 文档
- 重复点击复用已有标签页，行为像普通 Markdown
- 从已有飞书链接创建本地关联文件
- 从 Obsidian 创建新的飞书文档
- 同步远端标题和本地文件名
- 自动生成 `Lark Documents.base` 管理所有关联文档
GitHub：github.com
下面两张图会更直观：一张是文档直接在 Obsidian 里打开，另一张是 Bases 里的关联文档索引。
3 03
