即刻App年轻人的同好社区
下载
置顶最近一直在找 Agent Dynamic Workflow 的替代方案。
一开始是沿着 Temporal 这条线找的。Temporal 很强，但如果只是想把 agent、脚本、数据处理、运维任务动态串起来，有时候会觉得整套体系有点重。
然后翻到了 Dagu，感觉方向很对。
单个 binary 就能跑，流程用 YAML 写，本地文件管理，带 Web UI，也不用额外起 DB 或 broker。
内置动作也挺多：shell、Docker、K8s Job、SSH 这些都有。比较惊喜的是还有 harness.run，可以直接把外部 coding agent CLI 接进流程里。
我喜欢它的点是：流程本身就是文件，状态、日志、重试、依赖和界面都帮你兜住了。
对小团队、私有环境、个人自动化，还有 agent workflow 来说，Dagu 这种本地优先的路线反而很舒服。
github.com/dagucloud/dagu
一开始是沿着 Temporal 这条线找的。Temporal 很强，但如果只是想把 agent、脚本、数据处理、运维任务动态串起来，有时候会觉得整套体系有点重。
然后翻到了 Dagu，感觉方向很对。
单个 binary 就能跑，流程用 YAML 写，本地文件管理，带 Web UI，也不用额外起 DB 或 broker。
内置动作也挺多：shell、Docker、K8s Job、SSH 这些都有。比较惊喜的是还有 harness.run，可以直接把外部 coding agent CLI 接进流程里。
我喜欢它的点是：流程本身就是文件，状态、日志、重试、依赖和界面都帮你兜住了。
对小团队、私有环境、个人自动化，还有 agent workflow 来说，Dagu 这种本地优先的路线反而很舒服。
github.com/dagucloud/dagu
1 00
AI 写代码太快了，怎么查看变化内容变得更困难，在线 PR 查看效率太低了。
我一直在使用 IntelliJ IDEA 作为我的主力 IDE（现在是主力代码查看器）。
官方 Git 插件看本地 Changes 还行，但我真正需要的是：持续看“当前分支 vs 目标分支”的 diff。👀
Commit 面板只能看本地差异，GitHub / GitLab 插件又不适合我们这种特殊 Git 源码服务器。
今天发现一个 IntelliJ 插件：Git Scope，解决了我进入 AI Coding 时代后一个很大的痛点。🚀
Git Scope 刚好补上这个洞：可以和任意 branch / tag / commit 做对比。🔍
装完之后感觉 IDE 终于适配 AI Coding 工作流了。✨
我一直在使用 IntelliJ IDEA 作为我的主力 IDE（现在是主力代码查看器）。
官方 Git 插件看本地 Changes 还行，但我真正需要的是：持续看“当前分支 vs 目标分支”的 diff。👀
Commit 面板只能看本地差异，GitHub / GitLab 插件又不适合我们这种特殊 Git 源码服务器。
今天发现一个 IntelliJ 插件：Git Scope，解决了我进入 AI Coding 时代后一个很大的痛点。🚀
Git Scope 刚好补上这个洞：可以和任意 branch / tag / commit 做对比。🔍
装完之后感觉 IDE 终于适配 AI Coding 工作流了。✨
1 00
推荐一个老牌小工具：asciinema 🎬
它专门录终端操作，但不是录成视频，而是保存成很轻的文本记录。播放的时候像视频，实际内容还能复制、暂停、快进，放 README、文档、演示材料里都很舒服。
我最近做汇报演示，现场跑命令最怕两件事：网络抽风、手抖打错。后来干脆提前用 asciinema 录好一遍，汇报时直接播放，既像 live demo，又不会翻车。领导看的是效果，我保住的是血压。
这个项目也挺有意思，早期 CLI 是 Python 写的，3.0 直接用 Rust 重写，还加了 terminal live streaming。老工具继续长新牙。
适合这些场景：
录 CLI demo / 写 README 示例 / 做排障复现 / 给新人留操作说明 / 汇报时假装自己很稳 😄
终端世界里的“行车记录仪”，建议常备。
它专门录终端操作，但不是录成视频，而是保存成很轻的文本记录。播放的时候像视频，实际内容还能复制、暂停、快进，放 README、文档、演示材料里都很舒服。
我最近做汇报演示，现场跑命令最怕两件事：网络抽风、手抖打错。后来干脆提前用 asciinema 录好一遍，汇报时直接播放，既像 live demo，又不会翻车。领导看的是效果，我保住的是血压。
这个项目也挺有意思，早期 CLI 是 Python 写的，3.0 直接用 Rust 重写，还加了 terminal live streaming。老工具继续长新牙。
适合这些场景：
录 CLI demo / 写 README 示例 / 做排障复现 / 给新人留操作说明 / 汇报时假装自己很稳 😄
终端世界里的“行车记录仪”，建议常备。
3 00
置身钉内我读了三遍，在这个时代 AI 写的 3000 字我都不愿意多读，而这篇 7w 多字文章我逐字看。
作者确实才女，阅读量很大，讲故事论道理，旁征博引，有料有据，图文并茂，草蛇灰线，包袱遍地。即便我看了这么多离职奇帖，这篇也是排到最前列。视角、内容、文笔均在最前。我要是文中人，也得暗暗称一下奇文。
作者确实做到茨威格上身，汉娜·阿伦特也有点这个意思。文化人真是骂人不带脏字，多处戳肺管子却还没法强势回应。
作者确实才女，阅读量很大，讲故事论道理，旁征博引，有料有据，图文并茂，草蛇灰线，包袱遍地。即便我看了这么多离职奇帖，这篇也是排到最前列。视角、内容、文笔均在最前。我要是文中人，也得暗暗称一下奇文。
作者确实做到茨威格上身，汉娜·阿伦特也有点这个意思。文化人真是骂人不带脏字，多处戳肺管子却还没法强势回应。
2 00
你知道 Linux 内核有一个 1997 年就引入的特性，让 Apple Silicon Mac 能高效运行 x86 容器吗？
它叫 binfmt_misc，Linux 2.1.43 引入，距今快 30 年了。
原理极其简单： Linux 内核在执行一个二进制文件时，会先读取文件头的 magic number。如果你提前在 /proc/sys/fs/binfmt_misc/ 注册了一条规则 —— "遇到这种 magic 的文件，交给某个解释器处理" ——
内核就会自动把执行权转交给那个解释器。和 #!/bin/bash 的 shebang 机制本质一样，只是匹配的是二进制文件头。
最早它是用来让 Linux 直接 "运行" Java class 文件和 Windows PE 可执行文件的。后来 QEMU 利用这个机制实现了用户态跨架构模拟 —— 在 ARM 的 Linux 上直接执行 x86 ELF，内核自动调用 qemu-x86_64
翻译。
然后 Apple 来了。在 Apple Silicon Mac 上用 Colima / Lima 启动一个 Linux VM（使用 macOS 的 Virtualization.framework），打开 rosetta: true 后，会发生这些事：
1. macOS 通过 virtio-fs 把 Rosetta 翻译器二进制挂载进 Linux VM 的 /mnt/lima-rosetta/rosetta
2. VM 内部用标准的 binfmt_misc 注册一条规则：遇到 x86_64 ELF magic (7f454c46...02003e00)，交给 /mnt/lima-rosetta/rosetta 处理
3. 从此，VM 里任何 x86_64 二进制的执行都会被内核自动转交给 Rosetta 翻译
对容器来说完全透明 —— docker run --platform linux/amd64 nginx，Docker 拉下来的是 x86 镜像，容器里的进程是 x86 ELF，Linux 内核通过 binfmt_misc 自动调用 Rosetta
翻译执行。容器自己完全不知道发生了什么。
性能对比：
- Rosetta 方案：接近原生 70-90% 的性能（JIT 翻译，指令级优化）
- QEMU 全虚拟化方案：仅约 10-30%（完整模拟 x86 CPU）
一个 1997 年为了跑 Java class 文件设计的内核特性，在 2024 年成了 Apple Silicon 跑 x86 容器的关键基础设施。有时候最持久的架构决策，就是那些足够简单、足够通用的抽象。
$ colima ssh
$ cat /proc/sys/fs/binfmt_misc/rosetta
enabled
interpreter /mnt/lima-rosetta/rosetta
flags: OCF
magic 7f454c4602010100000000000000000002003e00
它叫 binfmt_misc，Linux 2.1.43 引入，距今快 30 年了。
原理极其简单： Linux 内核在执行一个二进制文件时，会先读取文件头的 magic number。如果你提前在 /proc/sys/fs/binfmt_misc/ 注册了一条规则 —— "遇到这种 magic 的文件，交给某个解释器处理" ——
内核就会自动把执行权转交给那个解释器。和 #!/bin/bash 的 shebang 机制本质一样，只是匹配的是二进制文件头。
最早它是用来让 Linux 直接 "运行" Java class 文件和 Windows PE 可执行文件的。后来 QEMU 利用这个机制实现了用户态跨架构模拟 —— 在 ARM 的 Linux 上直接执行 x86 ELF，内核自动调用 qemu-x86_64
翻译。
然后 Apple 来了。在 Apple Silicon Mac 上用 Colima / Lima 启动一个 Linux VM（使用 macOS 的 Virtualization.framework），打开 rosetta: true 后，会发生这些事：
1. macOS 通过 virtio-fs 把 Rosetta 翻译器二进制挂载进 Linux VM 的 /mnt/lima-rosetta/rosetta
2. VM 内部用标准的 binfmt_misc 注册一条规则：遇到 x86_64 ELF magic (7f454c46...02003e00)，交给 /mnt/lima-rosetta/rosetta 处理
3. 从此，VM 里任何 x86_64 二进制的执行都会被内核自动转交给 Rosetta 翻译
对容器来说完全透明 —— docker run --platform linux/amd64 nginx，Docker 拉下来的是 x86 镜像，容器里的进程是 x86 ELF，Linux 内核通过 binfmt_misc 自动调用 Rosetta
翻译执行。容器自己完全不知道发生了什么。
性能对比：
- Rosetta 方案：接近原生 70-90% 的性能（JIT 翻译，指令级优化）
- QEMU 全虚拟化方案：仅约 10-30%（完整模拟 x86 CPU）
一个 1997 年为了跑 Java class 文件设计的内核特性，在 2024 年成了 Apple Silicon 跑 x86 容器的关键基础设施。有时候最持久的架构决策，就是那些足够简单、足够通用的抽象。
$ colima ssh
$ cat /proc/sys/fs/binfmt_misc/rosetta
enabled
interpreter /mnt/lima-rosetta/rosetta
flags: OCF
magic 7f454c4602010100000000000000000002003e00
1 00
最近用 Firecrawl 挺多 🔥
它做的事很简单：把网页抓下来，清洗干净，转成 Markdown / 结构化数据。
这一步其实挺省事。很多网页直接丢给模型，里面一堆导航、广告、页脚、相关推荐，token 花了，重点没剩多少。
Firecrawl 处理完之后，可读性高很多，也更适合拿去做资料整理、知识库、agent workflow。
免费版 1000 credits，大概可以理解成：普通网页约 1000 页；如果开 JSON extraction / 增强模式，会少一些，大概几百页。
我还写了一个非官方 CLI，方便在终端里直接用：
github.com
小工具，但很实用 🧰
它做的事很简单：把网页抓下来，清洗干净，转成 Markdown / 结构化数据。
这一步其实挺省事。很多网页直接丢给模型，里面一堆导航、广告、页脚、相关推荐，token 花了，重点没剩多少。
Firecrawl 处理完之后，可读性高很多，也更适合拿去做资料整理、知识库、agent workflow。
免费版 1000 credits，大概可以理解成：普通网页约 1000 页；如果开 JSON extraction / 增强模式，会少一些，大概几百页。
我还写了一个非官方 CLI，方便在终端里直接用：
github.com
小工具，但很实用 🧰
3 00
亲戚聚会有个万能公式，叫「感介祝」：
感谢 XX，介绍自己，祝福大家。
工作里其实也有一个类似公式，叫「难努险」：
遇到了什么困难，做了什么努力，还有什么风险。
很多人做周报、汇报、同步进展，只写“我做了什么”，听起来就很平。
换成「难努险」会立刻不一样：
难：这件事为什么这么难
努：我具体做了什么努力和推进
险：接下来有什么风险，可能卡在哪里
这套东西的价值在于，它把“干活”翻译成“可被理解的工作量”。
价值 5000 的职场培训小技巧，今天免费送了。
感谢 XX，介绍自己，祝福大家。
工作里其实也有一个类似公式，叫「难努险」：
遇到了什么困难，做了什么努力，还有什么风险。
很多人做周报、汇报、同步进展，只写“我做了什么”，听起来就很平。
换成「难努险」会立刻不一样：
难：这件事为什么这么难
努：我具体做了什么努力和推进
险：接下来有什么风险，可能卡在哪里
这套东西的价值在于，它把“干活”翻译成“可被理解的工作量”。
价值 5000 的职场培训小技巧，今天免费送了。
82 313
今天被 golangci-lint 的版本问题卡了一下，顺手看了一圈通用版本管理工具 🧰。中间甚至冒出过一个念头：这东西是不是可以让 AI 直接写一个？看完一圈还是算了，asdf 已经够用了。
它的逻辑很简单：命令先经过 ~/.asdf/shims/*，运行时再读当前目录的 .tool-versions，然后决定该用哪个版本。
所以真正容易踩的坑就一个：⚠️ ~/.asdf/shims 没进 PATH，一切都白搭。
日常记三件事就够了： 项目版本写在 .tool-versions；📦 第一次进项目跑 asdf install；🔍 which golangci-lint 要看到 ~/.asdf/shims/...。
工具不大，效率大提升。
github.com
它的逻辑很简单：命令先经过 ~/.asdf/shims/*，运行时再读当前目录的 .tool-versions，然后决定该用哪个版本。
所以真正容易踩的坑就一个：⚠️ ~/.asdf/shims 没进 PATH，一切都白搭。
日常记三件事就够了： 项目版本写在 .tool-versions；📦 第一次进项目跑 asdf install；🔍 which golangci-lint 要看到 ~/.asdf/shims/...。
工具不大，效率大提升。
github.com
0 00
最近在读《人人都是产品经理 2.0》。
核心就是一条流程：产品定义 → 需求 → 设计 → 执行 → 迭代 → 运营。
流程是否顺畅，直接影响结果。
AI 把“做出 70 分作品”的成本压低了，结果是到处都是看起来还不错的产品、内容和工具。
差距不在产出，而在结果：
是不是真实需求，有没有人持续用，能不能在真实环境里跑起来。 产品有没有持续运营
#Product #AI
核心就是一条流程：产品定义 → 需求 → 设计 → 执行 → 迭代 → 运营。
流程是否顺畅，直接影响结果。
AI 把“做出 70 分作品”的成本压低了，结果是到处都是看起来还不错的产品、内容和工具。
差距不在产出，而在结果：
是不是真实需求，有没有人持续用，能不能在真实环境里跑起来。 产品有没有持续运营
#Product #AI
1 00
