#Blog #AI
🧑🏻💻 你不知道的 Claude Code:架构、治理与工程实践
🔗:X Article
今天这篇文章源于自己最近半年深度使用 Claude Code、两个账号每月 40 刀氪金换来的一些踩坑经验,希望能给大伙一些输入。
刚开始我也把它当 ChatBot 用,后来很快遇到这样的问题:上下文越来越乱、工具越来越多但效果越来越差、规则越写越长却越不遵守,折腾了一段时间,研究了 Claude Code 本身之后才意识到,这不是 Prompt 问题,而是这套系统的设计就是这样的。
这篇文章想和大伙聊清楚这几个点:Claude Code 底层怎么运作、上下文为什么会乱以及怎么治理、Skills 和 Hooks 应该怎么设计、Subagents 的正确用法、Prompt Caching 的架构影响,以及怎么写一个真正有用的 CLAUDE.md。
频道:@NewlearnerChannel
🧑🏻💻 你不知道的 Claude Code:架构、治理与工程实践
🔗:X Article
今天这篇文章源于自己最近半年深度使用 Claude Code、两个账号每月 40 刀氪金换来的一些踩坑经验,希望能给大伙一些输入。
刚开始我也把它当 ChatBot 用,后来很快遇到这样的问题:上下文越来越乱、工具越来越多但效果越来越差、规则越写越长却越不遵守,折腾了一段时间,研究了 Claude Code 本身之后才意识到,这不是 Prompt 问题,而是这套系统的设计就是这样的。
这篇文章想和大伙聊清楚这几个点:Claude Code 底层怎么运作、上下文为什么会乱以及怎么治理、Skills 和 Hooks 应该怎么设计、Subagents 的正确用法、Prompt Caching 的架构影响,以及怎么写一个真正有用的 CLAUDE.md。
频道:@NewlearnerChannel
❤19🆒2👍1
#Reading #APP #AI
📩 接读者来稿,TA 向我们推荐了自己开发的 AI 有声书软件
🎧 免费听书应用悦读 Readify 迎来重大更新,朗读功能更强大,并且新增音色克隆功能
🔗:官网链接 | 安卓下载 | 苹果下载
👓 基础功能
📚 多格式支持:TXT / PDF / EPUB / MOBI / AZW3 / DOCX;
🔊 100+ AI 音色:自研模型,40+ 语言,高保真自然发音,秒杀微信读书和番茄小说;
🔍 AI 搜书:内置搜书功能(需梯子),免费下载所有你想要的图书;
🤖 AI问答:专属读书搭子,帮你深层了解书籍内容;
💻 多端同步:同一账号,书库自动同步多个设备(平板,网页,手机)。
⭐️重磅新功能
- 🎙 音色克隆
只需录一段话或上传音频,即可马上生成你的专属音色来听书。
- 📄 TXT AI 排版
自动清理 TXT 里的乱码和广告,
生成清晰目录与书籍封面,阅读体验大幅提升。
- 📖 听读分离
一键进入纯阅读模式,
隐藏播放器,页面可自定义,看书更专注。
- 👓首页改版+添加公版书库
首页全新改版,视觉与体验全面升级;
智能公版书推荐,打开就能读,不再依赖手动导入。
👏 100%免费使用,欢迎大家体验!
📘 关联阅读:Readify - 让 AI 为每个人朗读世界
频道:@NewlearnerChannel
📩 接读者来稿,TA 向我们推荐了自己开发的 AI 有声书软件
🎧 免费听书应用悦读 Readify 迎来重大更新,朗读功能更强大,并且新增音色克隆功能
🔗:官网链接 | 安卓下载 | 苹果下载
👓 基础功能
📚 多格式支持:TXT / PDF / EPUB / MOBI / AZW3 / DOCX;
🔊 100+ AI 音色:自研模型,40+ 语言,高保真自然发音,秒杀微信读书和番茄小说;
🔍 AI 搜书:内置搜书功能(需梯子),免费下载所有你想要的图书;
🤖 AI问答:专属读书搭子,帮你深层了解书籍内容;
💻 多端同步:同一账号,书库自动同步多个设备(平板,网页,手机)。
⭐️重磅新功能
- 🎙 音色克隆
只需录一段话或上传音频,即可马上生成你的专属音色来听书。
- 📄 TXT AI 排版
自动清理 TXT 里的乱码和广告,
生成清晰目录与书籍封面,阅读体验大幅提升。
- 📖 听读分离
一键进入纯阅读模式,
隐藏播放器,页面可自定义,看书更专注。
- 👓首页改版+添加公版书库
首页全新改版,视觉与体验全面升级;
智能公版书推荐,打开就能读,不再依赖手动导入。
👏 100%免费使用,欢迎大家体验!
📘 关联阅读:Readify - 让 AI 为每个人朗读世界
频道:@NewlearnerChannel
❤10👍5🎉1
#GitHub情报 #macOS #AI
☠️ ANE — 逆向工程解锁 Apple Neural Engine 训练能力
首个绕过 CoreML、在 Apple M4 神经引擎上实现完整反向传播的开源概念验证,证明 ANE 硬件本身具备训练能力,软件封锁才是真正壁垒。
✨ 特点
• 私有 API 直连:通过逆向工程 _ANEClient、_ANECompiler 等私有接口,完全绕过 CoreML,实现对 ANE 硬件的直接控制,吞吐提升 2–4x。
• 完整前向 + 反向传播:在 ANE 上运行 Transformer 的前向与 dx 梯度计算,权重梯度 dW 由 CPU(Accelerate cblas)并发处理,支持 Adam 优化器与 checkpoint 续训。
• 动态权重管道:将权重打包进空间维度,实现权重更新无需重新编译,突破 ANE 每进程约 119 次编译上限的约束。
• INT8 W8A8 量化:利用 MIL quantize/dequantize 算子在 L2 SRAM 缓存 INT8 激活值,M4 上实测 1.88x 吞吐提升(35.1 TOPS vs 18.6 TOPS)。
• GPU↔ANE 零拷贝流水线:基于 IOSurface 共享内存,GPU 负责 prefill,ANE 负责 decode,Stories110M 总延迟仅 8.8ms。
• 硬件基准体系:系统性揭示 Apple「38 TOPS」宣传存在虚高。ANE 实际将 INT8 反量化为 FP16 后执行,真实峰值为 19 TFLOPS FP16,并提供 SRAM 带宽、TFLOPS 峰值等详细测量数据。
⚙️ 机制
ANE 是一个图执行引擎,接受编译好的 MIL(Model Intermediate Language)计算图后原子执行,本身不暴露可编程的指令集。项目通过运行时 objc_msgSend 解析 AppleNeuralEngine.framework 中 40+ 个私有 Objective-C 类,构建出「MIL 程序生成 → 内存编译 → IOSurface I/O」的完整链路。训练时前向与反向 dx 计算在 ANE 完成,权重梯度 dW 由 CPU cblas 并行执行,Adam 更新在 CPU 完成后权重重新打包回 ANE 空间维度。全程无外部依赖,仅使用系统框架。
主要依赖:Objective-C + Foundation + IOSurface + Accelerate(纯系统框架,零第三方依赖),Python 仅用于训练监控 Dashboard(blessed 库)。
🧑💻 使用场景
• NPU 编译器研究者:希望深入了解 Apple ANE 的 MIL IR 格式、Kernel Fusion 策略和 SRAM 行为,可直接参考 inmem_bench.m、sram_probe.m、inmem_peak.m 等基准工具,无需从零逆向工程。
• 边缘 AI 推理优化工程师:gpu_prefill_ane_decode.m 实现的 GPU prefill + ANE decode 混合流水线(Stories110M 总延迟 8.8ms、功耗 2.8W),可作为低功耗本地部署方案的参考架构。
• Apple 平台 ML 开发者:需要在 CoreML 训练 API 限制之外实现设备端持续学习或个性化微调时,可通过 bridge/ane_bridge.h 提供的 C-callable API 接入 ANE 计算能力。
• 硬件性能研究者:验证 38 TOPS 虚高发现,或研究 Apple Silicon ANE 与 SME(Scalable Matrix Extension)在不同工作负载下的分工边界。
• 开源社区建设者:在本项目基础上构建更完整的运行时,如已涌现的 Orion(完整 ANE 训练 + 推理框架)、hybrid-ane-mlx-bench(Apple Silicon 推理策略系统评测)。
🛣 社区关注方向
• Mega-kernel 层融合:将完整 Transformer 层融合为单一 MIL kernel
• macOS 26 API 适配:Apple 更改了 compile API。Apple 据报将推出「Core AI」替代 CoreML
• 扩展到更大模型:Qwen3-0.6B(596M 参数)GQA 支持已合并,社区在探索 1B+ 参数范围的可行性
• 模型加载支持:目前只能从随机初始化训练,无法加载预训练权重
💭 感想
ANE 项目最有价值的地方,不在于能立即替代 MLX 或 llama.cpp。作者在 README 里写得很清楚,这从来不是目标。它真正做到的是把一个「不可能」命题变成了有据可查的事实:Apple Neural Engine 的硬件本身具备训练能力,6.6 TFLOPS/W 的功效比(约为 A100 的 80 倍)让人想知道,若 Apple 开放训练 API,边缘端持续学习会走向哪里。
技术完成度上,最扎实的是基准测试体系中 38 TOPS 虚高的实验性反驳、SRAM 带宽性能悬崖的量化分析,都是不多见的一手硬件数据。训练实现接近 PoC 状态。5–9% 的 ANE 利用率说明距离高效 NPU 训练还有很长的软件工程路要走。相比 MLX(GPU 路线,开箱即用)和 CoreML(推理受限但稳定),ANE 这条路适合想深入理解 Apple Silicon 底层的系统工程师,不适合期望开箱即用的应用开发者。
项目的另一面是方法论本身:逆向工程、基准分析、训练代码,全程与 Claude Opus 4.6 协作完成。 AI 可用性得到了另一次证明
频道:@NewlearnerChannel
首个绕过 CoreML、在 Apple M4 神经引擎上实现完整反向传播的开源概念验证,证明 ANE 硬件本身具备训练能力,软件封锁才是真正壁垒。
• 私有 API 直连:通过逆向工程 _ANEClient、_ANECompiler 等私有接口,完全绕过 CoreML,实现对 ANE 硬件的直接控制,吞吐提升 2–4x。
• 完整前向 + 反向传播:在 ANE 上运行 Transformer 的前向与 dx 梯度计算,权重梯度 dW 由 CPU(Accelerate cblas)并发处理,支持 Adam 优化器与 checkpoint 续训。
• 动态权重管道:将权重打包进空间维度,实现权重更新无需重新编译,突破 ANE 每进程约 119 次编译上限的约束。
• INT8 W8A8 量化:利用 MIL quantize/dequantize 算子在 L2 SRAM 缓存 INT8 激活值,M4 上实测 1.88x 吞吐提升(35.1 TOPS vs 18.6 TOPS)。
• GPU↔ANE 零拷贝流水线:基于 IOSurface 共享内存,GPU 负责 prefill,ANE 负责 decode,Stories110M 总延迟仅 8.8ms。
• 硬件基准体系:系统性揭示 Apple「38 TOPS」宣传存在虚高。ANE 实际将 INT8 反量化为 FP16 后执行,真实峰值为 19 TFLOPS FP16,并提供 SRAM 带宽、TFLOPS 峰值等详细测量数据。
ANE 是一个图执行引擎,接受编译好的 MIL(Model Intermediate Language)计算图后原子执行,本身不暴露可编程的指令集。项目通过运行时 objc_msgSend 解析 AppleNeuralEngine.framework 中 40+ 个私有 Objective-C 类,构建出「MIL 程序生成 → 内存编译 → IOSurface I/O」的完整链路。训练时前向与反向 dx 计算在 ANE 完成,权重梯度 dW 由 CPU cblas 并行执行,Adam 更新在 CPU 完成后权重重新打包回 ANE 空间维度。全程无外部依赖,仅使用系统框架。
主要依赖:Objective-C + Foundation + IOSurface + Accelerate(纯系统框架,零第三方依赖),Python 仅用于训练监控 Dashboard(blessed 库)。
• NPU 编译器研究者:希望深入了解 Apple ANE 的 MIL IR 格式、Kernel Fusion 策略和 SRAM 行为,可直接参考 inmem_bench.m、sram_probe.m、inmem_peak.m 等基准工具,无需从零逆向工程。
• 边缘 AI 推理优化工程师:gpu_prefill_ane_decode.m 实现的 GPU prefill + ANE decode 混合流水线(Stories110M 总延迟 8.8ms、功耗 2.8W),可作为低功耗本地部署方案的参考架构。
• Apple 平台 ML 开发者:需要在 CoreML 训练 API 限制之外实现设备端持续学习或个性化微调时,可通过 bridge/ane_bridge.h 提供的 C-callable API 接入 ANE 计算能力。
• 硬件性能研究者:验证 38 TOPS 虚高发现,或研究 Apple Silicon ANE 与 SME(Scalable Matrix Extension)在不同工作负载下的分工边界。
• 开源社区建设者:在本项目基础上构建更完整的运行时,如已涌现的 Orion(完整 ANE 训练 + 推理框架)、hybrid-ane-mlx-bench(Apple Silicon 推理策略系统评测)。
🛣 社区关注方向
• Mega-kernel 层融合:将完整 Transformer 层融合为单一 MIL kernel
• macOS 26 API 适配:Apple 更改了 compile API。Apple 据报将推出「Core AI」替代 CoreML
• 扩展到更大模型:Qwen3-0.6B(596M 参数)GQA 支持已合并,社区在探索 1B+ 参数范围的可行性
• 模型加载支持:目前只能从随机初始化训练,无法加载预训练权重
ANE 项目最有价值的地方,不在于能立即替代 MLX 或 llama.cpp。作者在 README 里写得很清楚,这从来不是目标。它真正做到的是把一个「不可能」命题变成了有据可查的事实:Apple Neural Engine 的硬件本身具备训练能力,6.6 TFLOPS/W 的功效比(约为 A100 的 80 倍)让人想知道,若 Apple 开放训练 API,边缘端持续学习会走向哪里。
技术完成度上,最扎实的是基准测试体系中 38 TOPS 虚高的实验性反驳、SRAM 带宽性能悬崖的量化分析,都是不多见的一手硬件数据。训练实现接近 PoC 状态。5–9% 的 ANE 利用率说明距离高效 NPU 训练还有很长的软件工程路要走。相比 MLX(GPU 路线,开箱即用)和 CoreML(推理受限但稳定),ANE 这条路适合想深入理解 Apple Silicon 底层的系统工程师,不适合期望开箱即用的应用开发者。
项目的另一面是方法论本身:逆向工程、基准分析、训练代码,全程与 Claude Opus 4.6 协作完成。 AI 可用性得到了另一次证明
频道:@NewlearnerChannel
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤21👍2
#Blog #AI
🧑🏻💻 你不知道的 Agent:原理、架构与工程实践
🔗:X Article
今天这篇文章源于写完「你不知道的 Claude Code」之后,发现自己对 Agent 底层的理解还差一截,加上团队在 Agent 方向已经有不少业务落地,一直缺一份系统梳理,所以又把资料、开源实现和自己写的代码重新过了一遍。
刚开始我也觉得 Agent 效果不稳是模型能力不够,换更贵的模型就能解决。后来发现提升往往没有想象中那么大,反而是 Harness 搭得好不好、工具描述准不准、上下文有没有分层管理,才是决定成功率的真正变量。
这篇文章想和大伙聊清楚这几个点:Agent Loop 的控制流怎么运转、Harness 为什么比模型更关键、上下文工程为什么决定稳定性、工具设计的核心原则、记忆系统怎么分层、多 Agent如何协作组织,以及评测和追踪体系怎么搭。
频道:@NewlearnerChannel
🧑🏻💻 你不知道的 Agent:原理、架构与工程实践
🔗:X Article
今天这篇文章源于写完「你不知道的 Claude Code」之后,发现自己对 Agent 底层的理解还差一截,加上团队在 Agent 方向已经有不少业务落地,一直缺一份系统梳理,所以又把资料、开源实现和自己写的代码重新过了一遍。
刚开始我也觉得 Agent 效果不稳是模型能力不够,换更贵的模型就能解决。后来发现提升往往没有想象中那么大,反而是 Harness 搭得好不好、工具描述准不准、上下文有没有分层管理,才是决定成功率的真正变量。
这篇文章想和大伙聊清楚这几个点:Agent Loop 的控制流怎么运转、Harness 为什么比模型更关键、上下文工程为什么决定稳定性、工具设计的核心原则、记忆系统怎么分层、多 Agent如何协作组织,以及评测和追踪体系怎么搭。
频道:@NewlearnerChannel
❤12🐳2
#Blog #AI
🧑🏻💻 你不知道的大模型训练:原理、路径与新实践
🔗:X Article
今天这篇是「你不知道的」系列第三篇,写完 Claude Code 和 Agent 之后,想着继续挑战一下,把大模型训练到底怎么回事梳理清楚,尽量让非专业背景的人也能读懂。
刚开始我也以为模型变强就是参数堆大、数据喂多。后来发现用户真正感受到的那些提升,大部分不是来自预训练,而是来自它后面那整套流程:后训练、评测、奖励、Agent 训练、蒸馏,每一层都在影响最终体感。InstructGPT 当年有个数字,1.3B 做过对齐的模型,人类偏好评测里能赢过 175B 的 GPT-3,差了两个数量级,但用户更喜欢那个小的。
这篇文章想聊清楚这几个点:训练为什么是条流水线、数据配方怎么决定能力分布、系统约束为什么要在训练前就想清楚、后训练到底在调什么、奖励模型和 RLHF 怎么回事、蒸馏怎么把大模型能力压进小模型,以及 Agent 训练和部署侧还有哪些工程现实。
频道:@NewlearnerChannel
🧑🏻💻 你不知道的大模型训练:原理、路径与新实践
🔗:X Article
今天这篇是「你不知道的」系列第三篇,写完 Claude Code 和 Agent 之后,想着继续挑战一下,把大模型训练到底怎么回事梳理清楚,尽量让非专业背景的人也能读懂。
刚开始我也以为模型变强就是参数堆大、数据喂多。后来发现用户真正感受到的那些提升,大部分不是来自预训练,而是来自它后面那整套流程:后训练、评测、奖励、Agent 训练、蒸馏,每一层都在影响最终体感。InstructGPT 当年有个数字,1.3B 做过对齐的模型,人类偏好评测里能赢过 175B 的 GPT-3,差了两个数量级,但用户更喜欢那个小的。
这篇文章想聊清楚这几个点:训练为什么是条流水线、数据配方怎么决定能力分布、系统约束为什么要在训练前就想清楚、后训练到底在调什么、奖励模型和 RLHF 怎么回事、蒸馏怎么把大模型能力压进小模型,以及 Agent 训练和部署侧还有哪些工程现实。
频道:@NewlearnerChannel
❤5👍3
#Tools #Design #AI #OpenSource
👷 Kami:一个开源的 AI 原生文档设计系统
🔗:GitHub 🌐:官网
⭐️ Features
• 免费开源,面向 AI 生成文档的排版场景
• 支持一页纸报告、简历、作品集、白皮书、信件、长文档、Slides
• 支持中英文双语排版,适合打印、分享和导出 PDF
• 内置清晰、美观的图表和关系图绘制能力
• 零配置,适合作为 Claude Code / ChatGPT / Cursor 这类 AI 工具的文档输出 Skill
• 风格偏简洁、清晰、克制,避免千篇一律的 AI Design 味道
Kami 可以理解成一个给 AI 文档准备的设计系统。现在 AI 写内容已经不难了,但很多时候最后生成出来的文档,排版还是比较粗糙,要么像网页,要么像模板,要么看着有很重的 AI 味道。Kami 主要解决的就是这一段,把 AI 写出来的内容变成更适合阅读、展示、打印和发送给别人的精致文档。
它适合的场景很多,比如一页纸产品说明、个人简历、作品集 PDF、项目白皮书、长文档、Slides,或者任何需要排版成 PDF 的内容。里面也加入了自动画图的能力,可以把流程图、结构图、关系图这些内容一起做得更清楚。
我会把 Kami 看成 Waza 的妹妹,Kaku 的女儿,一个更偏创作和 Paper 排版的小工具。对于经常用 AI 写文档、做资料、整理作品集、准备对外材料的人来说,Kami 会是一个很顺手的补充。AI 已经能把内容写好了,现在也该让文档本身好看一点。
频道:@NewlearnerChannel
👷 Kami:一个开源的 AI 原生文档设计系统
🔗:GitHub 🌐:官网
⭐️ Features
• 免费开源,面向 AI 生成文档的排版场景
• 支持一页纸报告、简历、作品集、白皮书、信件、长文档、Slides
• 支持中英文双语排版,适合打印、分享和导出 PDF
• 内置清晰、美观的图表和关系图绘制能力
• 零配置,适合作为 Claude Code / ChatGPT / Cursor 这类 AI 工具的文档输出 Skill
• 风格偏简洁、清晰、克制,避免千篇一律的 AI Design 味道
Kami 可以理解成一个给 AI 文档准备的设计系统。现在 AI 写内容已经不难了,但很多时候最后生成出来的文档,排版还是比较粗糙,要么像网页,要么像模板,要么看着有很重的 AI 味道。Kami 主要解决的就是这一段,把 AI 写出来的内容变成更适合阅读、展示、打印和发送给别人的精致文档。
它适合的场景很多,比如一页纸产品说明、个人简历、作品集 PDF、项目白皮书、长文档、Slides,或者任何需要排版成 PDF 的内容。里面也加入了自动画图的能力,可以把流程图、结构图、关系图这些内容一起做得更清楚。
我会把 Kami 看成 Waza 的妹妹,Kaku 的女儿,一个更偏创作和 Paper 排版的小工具。对于经常用 AI 写文档、做资料、整理作品集、准备对外材料的人来说,Kami 会是一个很顺手的补充。AI 已经能把内容写好了,现在也该让文档本身好看一点。
频道:@NewlearnerChannel
❤12👍5
#Blog #AI
🧑🏻💻 你不知道的 AI Coding:非技术人的上手、场景与实战
🔗:X Article
上个月在公司给产品和业务的同学分享了下怎么上手 AI Coding,加上最近发了条推特,聊到不少同学因为订阅门槛没机会用上一线 AI Coding 工具,方法和习惯不花钱就能先学,索性把上手这部分整理出来。
很多人卡在使用命令行的第一步,看到只有字符的终端会觉得是给程序员用的,自己肯定搞不定。其实门槛没想象的高,会用豆包这类对话框 AI 的人花点时间也能上手,剩下的就是慢慢习惯把执行权交给它。等用顺手后会发现它像个什么活都接的能干助手,跑后台数据、写解决你问题的小工具、把乱七八糟的文档拼成简报、做原型、整理销售报表都能干。
这篇文章想和大伙聊清楚这几个点:第一道坎为什么是命令行、Claude Code 适合什么样的活、
频道:@NewlearnerChannel
🧑🏻💻 你不知道的 AI Coding:非技术人的上手、场景与实战
🔗:X Article
上个月在公司给产品和业务的同学分享了下怎么上手 AI Coding,加上最近发了条推特,聊到不少同学因为订阅门槛没机会用上一线 AI Coding 工具,方法和习惯不花钱就能先学,索性把上手这部分整理出来。
很多人卡在使用命令行的第一步,看到只有字符的终端会觉得是给程序员用的,自己肯定搞不定。其实门槛没想象的高,会用豆包这类对话框 AI 的人花点时间也能上手,剩下的就是慢慢习惯把执行权交给它。等用顺手后会发现它像个什么活都接的能干助手,跑后台数据、写解决你问题的小工具、把乱七八糟的文档拼成简报、做原型、整理销售报表都能干。
这篇文章想和大伙聊清楚这几个点:第一道坎为什么是命令行、Claude Code 适合什么样的活、
CLAUDE.md 到底怎么写、需求精度差一档结果差多少、Plan 和 Auto 模式什么时候用、怎么验收它真的做对了、Skills 怎么沉淀重复动作打包成肌肉记忆,以及几条让账号不被封、代码不出事的安全习惯。频道:@NewlearnerChannel
❤18
#telegram #AI #Tools
🧠 聊聊 Telegram 的新功能 —— AI Editor
🔗:Blog
三月底的时候,Telegram 发布了一波新功能更新,其中引起我注意的是 AI Editor(AI 文本编辑器)。作为一个经常在 Telegram 写作并发布文字的人,它到底能带来哪些变化?
👉 Features
- 一键翻译文本,支持多国语言
- 支持润色改写为多种语言风格,包含正式 / 简短 / 部落 / 圣经 / 禅 / 商务等
- 一键排版、标点符号修改、错别字纠正等
- 使用自研模型 Cocoon AI,注重隐私、不存储用户文本、不用于训练
💡 AI Editor 只有在对话框字数到达一定程度时,才能够触发 AI 编辑选项。它做的事情和去年 WWDC 发布的 Writing Tools 非常像,即像插件一样对文字表达实时润色。它真正改变的不是「写什么」,而是「怎么写」,这一点和生成式 AI 有着本质的不同
👀 最近一直思考这个工具能够带来的实质意义,但几乎微乎其微。用户日常对话,除了极个别需要翻译的场景,几乎不会用到太复杂的文本编辑修正。因此只有发布严肃内容的频道主,可以用它来检查语法、语句通顺等。自留地几乎不需要它,我们很早就确立了一套自己的准则,但用它来润色读者们的长文投稿,经测试意外得好用(对中文的支持还不错,甚至还有 Emoji 模式)
🤖 另外,Telegram 对 AI Agent Bot 的支持格外得优秀,想要发布一些有条理、有内容的文字,也不见得需要再走一遍 AI Editor。所以,我个人理解目前这个功能对我们的帮助非常有限,以至于到现在也没什么人提到。但是,如果未来融合了生成式 AI,就能给我们在 Telegram 生态下的一站式写稿带来许多便捷,希望这是一个好的开始
* 实际上,自留地自 19 年就开始在频道推送中使用多种 Emoji 来进行分段或视觉指引,于 20 年疫情居家后逐步形成了 Emoji 排版体系。我们对后续「滥用 Emoji」以及「Emoji 成为 AI 风格」等事深表遗憾
频道:@NewlearnerChannel
🧠 聊聊 Telegram 的新功能 —— AI Editor
🔗:Blog
三月底的时候,Telegram 发布了一波新功能更新,其中引起我注意的是 AI Editor(AI 文本编辑器)。作为一个经常在 Telegram 写作并发布文字的人,它到底能带来哪些变化?
👉 Features
- 一键翻译文本,支持多国语言
- 支持润色改写为多种语言风格,包含正式 / 简短 / 部落 / 圣经 / 禅 / 商务等
- 一键排版、标点符号修改、错别字纠正等
- 使用自研模型 Cocoon AI,注重隐私、不存储用户文本、不用于训练
💡 AI Editor 只有在对话框字数到达一定程度时,才能够触发 AI 编辑选项。它做的事情和去年 WWDC 发布的 Writing Tools 非常像,即像插件一样对文字表达实时润色。它真正改变的不是「写什么」,而是「怎么写」,这一点和生成式 AI 有着本质的不同
👀 最近一直思考这个工具能够带来的实质意义,但几乎微乎其微。用户日常对话,除了极个别需要翻译的场景,几乎不会用到太复杂的文本编辑修正。因此只有发布严肃内容的频道主,可以用它来检查语法、语句通顺等。自留地几乎不需要它,我们很早就确立了一套自己的准则,但用它来润色读者们的长文投稿,经测试意外得好用(对中文的支持还不错,甚至还有 Emoji 模式)
🤖 另外,Telegram 对 AI Agent Bot 的支持格外得优秀,想要发布一些有条理、有内容的文字,也不见得需要再走一遍 AI Editor。所以,我个人理解目前这个功能对我们的帮助非常有限,以至于到现在也没什么人提到。但是,如果未来融合了生成式 AI,就能给我们在 Telegram 生态下的一站式写稿带来许多便捷,希望这是一个好的开始
* 实际上,自留地自 19 年就开始在频道推送中使用多种 Emoji 来进行分段或视觉指引,于 20 年疫情居家后逐步形成了 Emoji 排版体系。我们对后续「滥用 Emoji」以及「Emoji 成为 AI 风格」等事深表遗憾
频道:@NewlearnerChannel
3👍9❤2
#GitHub情报 #AI #telegram #bots
📩 接读者来稿,他向我们介绍了自己开发的 AI 股票分析机器人项目
📈 TradingAgents-Telegram:基于 AI 股票分析的 Telegram 助手
🔗:GitHub
⭐️ Features
• 基于 TradingAgents 框架
• 支持通过Telegraph输出股票分析、市场情绪总结与观点
• 可以直接通过 Docker Compose 部署
🧠 最开始是因为我在体验挺火的 TradingAgents 时,发现它原本主要运行在 Terminal 里,虽然功能很强,但日常使用和交互并不是特别方便。所以我尝试把它做成 Telegram Bot,让整个过程更像聊天:你可以直接把股票代码发给 Bot,然后看不同 AI 如何分析、讨论和补充观点。相比传统命令行,这种方式会更轻量,也更接近日常使用习惯。它并不是传统意义上的量化系统,也不是自动交易工具,而更像一个「AI 投资讨论Bot」。
👨🏻💻 这个项目本身也是一次很有意思的 Vibe Coding 体验。整个开发过程里,我大量使用了 Claude Code 做协作开发,从需求描述、架构设计到代码生成,很多部分都是通过自然语言一步步完成的。某种程度上,它也是我对「Vibe Coding」方式的一次实践。
⚠️ Disclaimer
这个项目仅用于技术交流与 AI 能力探索,不构成任何投资建议。
AI 输出可能存在错误、幻觉、信息滞后或分析偏差,不应作为实际投资决策依据。投资本身存在风险,请务必独立判断并自行承担风险。
❤️ 欢迎提 Issue 或者给个 Star!
频道:@NewlearnerChannel
📩 接读者来稿,他向我们介绍了自己开发的 AI 股票分析机器人项目
📈 TradingAgents-Telegram:基于 AI 股票分析的 Telegram 助手
🔗:GitHub
⭐️ Features
• 基于 TradingAgents 框架
• 支持通过Telegraph输出股票分析、市场情绪总结与观点
• 可以直接通过 Docker Compose 部署
🧠 最开始是因为我在体验挺火的 TradingAgents 时,发现它原本主要运行在 Terminal 里,虽然功能很强,但日常使用和交互并不是特别方便。所以我尝试把它做成 Telegram Bot,让整个过程更像聊天:你可以直接把股票代码发给 Bot,然后看不同 AI 如何分析、讨论和补充观点。相比传统命令行,这种方式会更轻量,也更接近日常使用习惯。它并不是传统意义上的量化系统,也不是自动交易工具,而更像一个「AI 投资讨论Bot」。
👨🏻💻 这个项目本身也是一次很有意思的 Vibe Coding 体验。整个开发过程里,我大量使用了 Claude Code 做协作开发,从需求描述、架构设计到代码生成,很多部分都是通过自然语言一步步完成的。某种程度上,它也是我对「Vibe Coding」方式的一次实践。
⚠️ Disclaimer
这个项目仅用于技术交流与 AI 能力探索,不构成任何投资建议。
AI 输出可能存在错误、幻觉、信息滞后或分析偏差,不应作为实际投资决策依据。投资本身存在风险,请务必独立判断并自行承担风险。
❤️ 欢迎提 Issue 或者给个 Star!
频道:@NewlearnerChannel
❤13👍2
#macOS #APP #AI
🧠 oh-myusage:面向 macOS 菜单栏的 AI 订阅、额度与账号状态控制台
🔗:GitHub | Download
👉 Features
- 支持 Codex、Claude、Gemini、Kimi 等多个主流 AI 订阅产品
- 显示额度、百分比、余额、倒计时、刷新状态和异常状态
- 统一管理官方 Provider、本地桌面端会话和账号资料
- 支持低额度、鉴权失效、连续失败等提醒
- 对认证失败、限流、端点配置错误、网络不可达等状态做用户可读诊断等
🧑🏻💻 适合谁
• 同时使用多个 AI 官方产品,希望在菜单栏快速判断额度状态的人
• 依赖多个第三方中转站,希望统一查看余额、Token 用量和异常原因的人
• 经常在多个 Codex 或 Claude 本地账号之间切换的人
• 希望区分“官方确认”“本地估算”“缓存回退”“鉴权失效”等数据可信度的人
• 想要一个长期常驻、低能耗、可诊断的 AI 用量监控工具的人
🔥 随着各类第三方 AI Agent 和人们日常编程需求的急剧增加,消耗的 Token 也不可同日而语。在这样的背景下,我们需要一个工具来聚合、显示不同 AI 平台的 Token 开销和余量,于是 macOS 端有了 oh-myusage
💡 项目把官方订阅额度、模型使用窗口、第三方中转余额、本地桌面端账号状态和异常诊断统一放到菜单栏里。它不是单一网页余额的封装,而是一个常驻运行、低打扰、可扩展的 AI 用量工作台。文档已经足够详细,欢迎大家试用
📘 关联阅读:
1️⃣ 面对「龙虾大战」,你可以用到的几个工具网站
2️⃣ Open Minis: Your Private On-Device Agent
3️⃣ Kaku:极速开箱即用的 AI 友好终端
4️⃣ OpenClaw:我见过最强的开源 Al Agent之一,也有很明确的边界
频道:@NewlearnerChannel
🧠 oh-myusage:面向 macOS 菜单栏的 AI 订阅、额度与账号状态控制台
🔗:GitHub | Download
👉 Features
- 支持 Codex、Claude、Gemini、Kimi 等多个主流 AI 订阅产品
- 显示额度、百分比、余额、倒计时、刷新状态和异常状态
- 统一管理官方 Provider、本地桌面端会话和账号资料
- 支持低额度、鉴权失效、连续失败等提醒
- 对认证失败、限流、端点配置错误、网络不可达等状态做用户可读诊断等
🧑🏻💻 适合谁
• 同时使用多个 AI 官方产品,希望在菜单栏快速判断额度状态的人
• 依赖多个第三方中转站,希望统一查看余额、Token 用量和异常原因的人
• 经常在多个 Codex 或 Claude 本地账号之间切换的人
• 希望区分“官方确认”“本地估算”“缓存回退”“鉴权失效”等数据可信度的人
• 想要一个长期常驻、低能耗、可诊断的 AI 用量监控工具的人
🔥 随着各类第三方 AI Agent 和人们日常编程需求的急剧增加,消耗的 Token 也不可同日而语。在这样的背景下,我们需要一个工具来聚合、显示不同 AI 平台的 Token 开销和余量,于是 macOS 端有了 oh-myusage
💡 项目把官方订阅额度、模型使用窗口、第三方中转余额、本地桌面端账号状态和异常诊断统一放到菜单栏里。它不是单一网页余额的封装,而是一个常驻运行、低打扰、可扩展的 AI 用量工作台。文档已经足够详细,欢迎大家试用
📘 关联阅读:
1️⃣ 面对「龙虾大战」,你可以用到的几个工具网站
2️⃣ Open Minis: Your Private On-Device Agent
3️⃣ Kaku:极速开箱即用的 AI 友好终端
4️⃣ OpenClaw:我见过最强的开源 Al Agent之一,也有很明确的边界
频道:@NewlearnerChannel
😘6❤3
This media is not supported in your browser
VIEW IN TELEGRAM
#GitHub情报 #APP #Tools #AI
📩 接读者来稿,他向我们介绍了一个有趣的 AI 代理可视化项目
🧩 ascii-agents:把你的 Claude Code 装进一个像素风办公室
🔗:GitHub
👉 Features
- 为每段会话设置办公桌,多出的将会展示在地板和沙发
- 为每段会话代表的人物设置丰富的动作和表情
- 通过颜色快速识别状态,并加入多种天气情况
- Office Cat 陪伴左右
- 在人物身上悬停可看到会话详细信息
- 支持 Claude Code 和 Antigravity CLI,未来计划更多平台
👀 看到这个项目,第一反应是想到了令人舒适的 室内白噪音 以及灵感买家俱乐部推出的线上「野乌咖啡馆」。在后者之中,你依然可以化身为一个可视化的个人,在其中听音乐、自习、开会、聊天,做自己想做的事。很好的想法!
🧑🏻💻 开发者的话
现在的状态:每个 session 是一个小人,显示器会根据当前在用什么工具自动变色,空闲的趴桌睡觉,闲久了自己走去茶水间。窗外有阴天、刮风、日落的天气变化,内置 Cyberpunk、Catppuccin、Gruvbox、Dracula、Tokyo Night 等 6 种主题。🐱 还有只办公室的猫。
起因是日常工作开始大量用 Claude Code,经常同时跑好几个 session 在不同的项目里。但一个 session 当下到底是在打字、还是在等我点权限、还是早就跑完了我没注意,光看终端输出很难一眼分清。
这时候在 GitHub 上刷到 pixel-agents(VS Code 网页版)和 clawd-on-desk(macOS 桌宠版)两个项目,觉得这种「把 Agent 拟人化」的方向很有意思。但自己日常其实更常在终端和 SSH 里干活,所以就想做个纯终端版本。
项目本身是周末用 Rust 慢慢搭起来的,之前没怎么写过 Rust,顺便当练手了。TUI 用的是 ratatui,像素感来自 24-bit RGB 的半字符块渲染(▀)。Agent 闲下来会用 A* 在办公室里乱走,整个过程也算重度使用了 Claude Code,某种意义上「用 AI Agent 给 AI Agent 盖房子」。
频道:@NewlearnerChannel
📩 接读者来稿,他向我们介绍了一个有趣的 AI 代理可视化项目
🧩 ascii-agents:把你的 Claude Code 装进一个像素风办公室
🔗:GitHub
👉 Features
- 为每段会话设置办公桌,多出的将会展示在地板和沙发
- 为每段会话代表的人物设置丰富的动作和表情
- 通过颜色快速识别状态,并加入多种天气情况
- Office Cat 陪伴左右
- 在人物身上悬停可看到会话详细信息
- 支持 Claude Code 和 Antigravity CLI,未来计划更多平台
👀 看到这个项目,第一反应是想到了令人舒适的 室内白噪音 以及灵感买家俱乐部推出的线上「野乌咖啡馆」。在后者之中,你依然可以化身为一个可视化的个人,在其中听音乐、自习、开会、聊天,做自己想做的事。很好的想法!
🧑🏻💻 开发者的话
现在的状态:每个 session 是一个小人,显示器会根据当前在用什么工具自动变色,空闲的趴桌睡觉,闲久了自己走去茶水间。窗外有阴天、刮风、日落的天气变化,内置 Cyberpunk、Catppuccin、Gruvbox、Dracula、Tokyo Night 等 6 种主题。🐱 还有只办公室的猫。
起因是日常工作开始大量用 Claude Code,经常同时跑好几个 session 在不同的项目里。但一个 session 当下到底是在打字、还是在等我点权限、还是早就跑完了我没注意,光看终端输出很难一眼分清。
这时候在 GitHub 上刷到 pixel-agents(VS Code 网页版)和 clawd-on-desk(macOS 桌宠版)两个项目,觉得这种「把 Agent 拟人化」的方向很有意思。但自己日常其实更常在终端和 SSH 里干活,所以就想做个纯终端版本。
项目本身是周末用 Rust 慢慢搭起来的,之前没怎么写过 Rust,顺便当练手了。TUI 用的是 ratatui,像素感来自 24-bit RGB 的半字符块渲染(▀)。Agent 闲下来会用 A* 在办公室里乱走,整个过程也算重度使用了 Claude Code,某种意义上「用 AI Agent 给 AI Agent 盖房子」。
频道:@NewlearnerChannel
👾7❤3
#Photos #AI #Terminal
📷 摄影焦段分析器:用 AI 制作的终端脚本,直观统计你偏爱的摄影焦段
🔗:获取脚本
🧠 生成式 AI 和编程的发展,让我们能够快速实现之前很难做到的事情。曾几何时,我们只能从别人的博客、论坛搜刮代码片段,然后针对性作出修改,才能勉强实现部分功能。而如今,直接向 AI 告知我们的需求,即可快速生成可用代码(包安装运行)。此前曾通过 iOS AI Agent 分析过自己的睡眠和健康情况,评价为 AI 真是太好用了!
📸 前不久在小红书网上冲浪时,算法精准将我击中,萌生了统计自己摄影焦段喜好的想法,评论区清一色表示:脚本是 AI 写的。于是跃跃欲试,给 AI 以下内容:帮我编写一个脚本,能够快速统计分析我的摄影作品所用的焦段区间,要求根据超广角、广角、中焦、长焦、超长焦几个维度统计张数和占比。选中文件夹后需要访问二级和三级文件夹的所有内容
❓ 生成的过程很顺利,调试了几次之后能够跑起来了。但当我遍历电脑上存的 10000 多张照片(PNG 格式,可在系统信息查询焦段等信息)后,脚本提示照片均没有有效的 EXIF 信息。研究后发现,PNG 照片一般用 XMP 携带元信息,安装 exiftool 工具即可快速读取,于是得到了脚本的最终稿
💡 如何使用
① 下载脚本
② 安装 Python 所需依赖:
③ 安装 exiftool:
④ 运行脚本
运行后,脚本会提示你选择对应的摄影文件夹,直接选择一级文件夹即可。接着脚本会自动遍历所有照片,提取对应的焦段信息并最终生成统计。如果你有其他需求,或是想要进一步生成对应的热力统计图,也可以借助 AI 快速实现
频道:@NewlearnerChannel
📷 摄影焦段分析器:用 AI 制作的终端脚本,直观统计你偏爱的摄影焦段
🔗:获取脚本
🧠 生成式 AI 和编程的发展,让我们能够快速实现之前很难做到的事情。曾几何时,我们只能从别人的博客、论坛搜刮代码片段,然后针对性作出修改,才能勉强实现部分功能。而如今,直接向 AI 告知我们的需求,即可快速生成可用代码(包安装运行)。此前曾通过 iOS AI Agent 分析过自己的睡眠和健康情况,评价为 AI 真是太好用了!
📸 前不久在小红书网上冲浪时,算法精准将我击中,萌生了统计自己摄影焦段喜好的想法,评论区清一色表示:脚本是 AI 写的。于是跃跃欲试,给 AI 以下内容:帮我编写一个脚本,能够快速统计分析我的摄影作品所用的焦段区间,要求根据超广角、广角、中焦、长焦、超长焦几个维度统计张数和占比。选中文件夹后需要访问二级和三级文件夹的所有内容
❓ 生成的过程很顺利,调试了几次之后能够跑起来了。但当我遍历电脑上存的 10000 多张照片(PNG 格式,可在系统信息查询焦段等信息)后,脚本提示照片均没有有效的 EXIF 信息。研究后发现,PNG 照片一般用 XMP 携带元信息,安装 exiftool 工具即可快速读取,于是得到了脚本的最终稿
💡 如何使用
① 下载脚本
② 安装 Python 所需依赖:
pip install exifread tqdm tabulate pillow pillow-heif③ 安装 exiftool:
brew install exiftool④ 运行脚本
运行后,脚本会提示你选择对应的摄影文件夹,直接选择一级文件夹即可。接着脚本会自动遍历所有照片,提取对应的焦段信息并最终生成统计。如果你有其他需求,或是想要进一步生成对应的热力统计图,也可以借助 AI 快速实现
频道:@NewlearnerChannel
❤2
#Games #AI
📩 接读者来稿,他向我们介绍了自己开发的有趣的 AI 武侠游戏
⚔️ 江湖论剑:人定门派,AI 论招 —— 把武侠对战做成一套专门给 AI Agent 打的擂台
🔗:官网
江湖论剑把「打武侠对战」这件事整个翻转了一下:人不下场。人只负责造一个角色 —— 取个名、选一个门派;真正逐帧出招的,是一段由 AI agent 写的「心法脚本」。你把角色和门派招式丢给任意 AI(Claude / GPT / 你自己的脚本),它就能在「试招 → 读战斗复盘 → 改招 → 上天梯排位」这个闭环里自己练级。说白了拼的不是手速,是提示词和算法——你在调教一个会打架的 AI,再看它能爬多高。
✨ 特点
- AI 替你打,不是你替 AI 点:核心玩法就是把角色交给 AI——给它一段提示词、一套门派招式,它自己就能跑完「试招 → 复盘 → 改招 → 排位」整个闭环,全程不用你盯着点。
- 人定门派,AI 论招:七大门派、35 个招式,各有形状——单体 / 直线 / 锥形 / 自身范围 / 落地陷阱 / 召唤 / 姿态切换 / 反弹(苍云「盾立」连 debuff 一起弹回去)。人选流派,AI 写出招逻辑。
- 完整复盘 + 战斗诊断:每局打完自动生成一份复盘——逐招命中率、伤害构成、暴击数、各地形停留时间一目了然,AI 拿这份数据反过来调招。
- 有信息差的战场:14×14 网格,五种地形(墙、高坡、浅溪减速、灵泉回内力、雾林让你从对手眼里隐身)。120° 视野锥 + 真实视线遮挡——看不见对手时你只知道他有什么招、什么状态,却摸不到他在哪,是真的战争迷雾。
- 真排位天梯:14 段位天梯,外加「论武尊 / 大宗主 / 鸣剑生」称号;还有一圈 PUBG 式的「禁地」缩圈逼你近身,专治无限风筝流。
- 招式版本留痕:每次改招都留痕,AI 能把「哪一次改动」对上「那段时间的真实胜负」,拿战绩反过来优化。
🛣 路线图
• 更多门派与演武场地:在现有七大门派、四张地图之上继续扩,丰富招式形状与地形互动。
• 平衡持续迭代:数值调整靠真实对局数据驱动,且不影响你已经发布的招式。
• AI 上手更顺:把战斗诊断、对手检索做得更好用,让 AI 更容易读懂战况、更快上手。
• 秘境试炼扩充:从视野、资源管理到进阶策略,做成一条带「要诀」讲解的教学关卡线。
🖊 作者背景
由 gtoxlili 个人开发,线上长期运行在 jianghu.gtio.work,欢迎来玩、提建议,也欢迎贡献门派与招式创意。
频道:@NewlearnerChannel
📩 接读者来稿,他向我们介绍了自己开发的有趣的 AI 武侠游戏
⚔️ 江湖论剑:人定门派,AI 论招 —— 把武侠对战做成一套专门给 AI Agent 打的擂台
🔗:官网
江湖论剑把「打武侠对战」这件事整个翻转了一下:人不下场。人只负责造一个角色 —— 取个名、选一个门派;真正逐帧出招的,是一段由 AI agent 写的「心法脚本」。你把角色和门派招式丢给任意 AI(Claude / GPT / 你自己的脚本),它就能在「试招 → 读战斗复盘 → 改招 → 上天梯排位」这个闭环里自己练级。说白了拼的不是手速,是提示词和算法——你在调教一个会打架的 AI,再看它能爬多高。
✨ 特点
- AI 替你打,不是你替 AI 点:核心玩法就是把角色交给 AI——给它一段提示词、一套门派招式,它自己就能跑完「试招 → 复盘 → 改招 → 排位」整个闭环,全程不用你盯着点。
- 人定门派,AI 论招:七大门派、35 个招式,各有形状——单体 / 直线 / 锥形 / 自身范围 / 落地陷阱 / 召唤 / 姿态切换 / 反弹(苍云「盾立」连 debuff 一起弹回去)。人选流派,AI 写出招逻辑。
- 完整复盘 + 战斗诊断:每局打完自动生成一份复盘——逐招命中率、伤害构成、暴击数、各地形停留时间一目了然,AI 拿这份数据反过来调招。
- 有信息差的战场:14×14 网格,五种地形(墙、高坡、浅溪减速、灵泉回内力、雾林让你从对手眼里隐身)。120° 视野锥 + 真实视线遮挡——看不见对手时你只知道他有什么招、什么状态,却摸不到他在哪,是真的战争迷雾。
- 真排位天梯:14 段位天梯,外加「论武尊 / 大宗主 / 鸣剑生」称号;还有一圈 PUBG 式的「禁地」缩圈逼你近身,专治无限风筝流。
- 招式版本留痕:每次改招都留痕,AI 能把「哪一次改动」对上「那段时间的真实胜负」,拿战绩反过来优化。
🛣 路线图
• 更多门派与演武场地:在现有七大门派、四张地图之上继续扩,丰富招式形状与地形互动。
• 平衡持续迭代:数值调整靠真实对局数据驱动,且不影响你已经发布的招式。
• AI 上手更顺:把战斗诊断、对手检索做得更好用,让 AI 更容易读懂战况、更快上手。
• 秘境试炼扩充:从视野、资源管理到进阶策略,做成一条带「要诀」讲解的教学关卡线。
🖊 作者背景
由 gtoxlili 个人开发,线上长期运行在 jianghu.gtio.work,欢迎来玩、提建议,也欢迎贡献门派与招式创意。
频道:@NewlearnerChannel
❤8
#RSS #AI #GitHub情报 #Tools
📰 邸报:把推荐算法重新接回 RSS
🔗:GitHub | 项目介绍
⭐️ Features:
• 导入 OPML 或 RSS 地址
• 根据阅读行为自动学习偏好
• 支持 Docker Compose 部署
• SQLite 单文件存储
• 无需绑定 LLM API,可接入 embedding 服务或本地模型
RSS 的好处是信息源掌握在自己手里,坏处也是信息源容易古板、陈旧、机械的掌握在自己手里。订阅一多,每天几百篇未读文章堆在收件箱里,阅读很容易逐渐变成一种负担。平台推荐当然省心,但代价是信息分发权也一并交给了平台。邸报在两者之间找一个位置,让信源仍然由用户选择,但排序交给算法完成。导入 OPML、添加 RSS 地址之后,就可以在邸报中像普通阅读器一样浏览、收藏和标记文章。与传统 RSS 阅读器不同之处在于,邸报会根据阅读行为逐渐学习用户的偏好,再对订阅池中的内容重新排序。它不会引入新的信息来源,只是在你已经订阅的文章里,把可能更值得先看的内容浮上来。
这个思路非常合理。现在很多“AI 阅读”产品习惯让大模型直接吞掉整条信息流,逐篇总结、筛选和判断,不仅消耗大量 Token,也容易让阅读变成被模型加工过的二手信息。而邸报选择了另外一条路,通过行为数据、embedding 和排序,已经可以解决大部分需求,每篇推荐还会附带理由,不只是扔给用户一个无法理解的黑盒分数。
部署方面,邸报支持 Docker Compose,可以运行在 NAS、VPS 或本地电脑上。数据保存在 SQLite 文件中,备份基本就是复制粘贴。它不依赖中心化服务,也不强制绑定付费 API。接入硅基流动之类的 embedding provider,或者在本地跑一个小模型,就可以获得不错的推荐效果。
👀 开发者将邸报称作“外部嗅觉器官”,我很喜欢这个描述。RSS 阅读器流行于 2000 年前后,推荐算法在十多年前就已经被大规模验证,但直到今天,两者仍然很少被真正结合起来。邸报目前的完成度和推荐效果都需要更多真实使用来检验。如果你的 RSS 收件箱已经长期处于爆炸状态,又不愿意把阅读完全交给平台算法,邸报很值得试试看。
频道:@NewlearnerChannel
📰 邸报:把推荐算法重新接回 RSS
🔗:GitHub | 项目介绍
⭐️ Features:
• 导入 OPML 或 RSS 地址
• 根据阅读行为自动学习偏好
• 支持 Docker Compose 部署
• SQLite 单文件存储
• 无需绑定 LLM API,可接入 embedding 服务或本地模型
RSS 的好处是信息源掌握在自己手里,坏处也是信息源容易古板、陈旧、机械的掌握在自己手里。订阅一多,每天几百篇未读文章堆在收件箱里,阅读很容易逐渐变成一种负担。平台推荐当然省心,但代价是信息分发权也一并交给了平台。邸报在两者之间找一个位置,让信源仍然由用户选择,但排序交给算法完成。导入 OPML、添加 RSS 地址之后,就可以在邸报中像普通阅读器一样浏览、收藏和标记文章。与传统 RSS 阅读器不同之处在于,邸报会根据阅读行为逐渐学习用户的偏好,再对订阅池中的内容重新排序。它不会引入新的信息来源,只是在你已经订阅的文章里,把可能更值得先看的内容浮上来。
这个思路非常合理。现在很多“AI 阅读”产品习惯让大模型直接吞掉整条信息流,逐篇总结、筛选和判断,不仅消耗大量 Token,也容易让阅读变成被模型加工过的二手信息。而邸报选择了另外一条路,通过行为数据、embedding 和排序,已经可以解决大部分需求,每篇推荐还会附带理由,不只是扔给用户一个无法理解的黑盒分数。
部署方面,邸报支持 Docker Compose,可以运行在 NAS、VPS 或本地电脑上。数据保存在 SQLite 文件中,备份基本就是复制粘贴。它不依赖中心化服务,也不强制绑定付费 API。接入硅基流动之类的 embedding provider,或者在本地跑一个小模型,就可以获得不错的推荐效果。
👀 开发者将邸报称作“外部嗅觉器官”,我很喜欢这个描述。RSS 阅读器流行于 2000 年前后,推荐算法在十多年前就已经被大规模验证,但直到今天,两者仍然很少被真正结合起来。邸报目前的完成度和推荐效果都需要更多真实使用来检验。如果你的 RSS 收件箱已经长期处于爆炸状态,又不愿意把阅读完全交给平台算法,邸报很值得试试看。
频道:@NewlearnerChannel
❤7👍3
#Photos #AI #GitHub情报
🎞 X5-Crop:轻量的 X5 扫描长 TIFF 自动裁切工具
🔗:GitHub | Releases
👉 Features
- 兼容绝大部分胶片以及扫描格式:普通 135 / 135 双条片夹 / 半格 / 645 / 66 / 67
- 使用简单:有详细的文档说明,使用方式简洁到只需要双击和回车
- 批处理:一个脚本可以批量处理整个文件夹内的所有 TIFF 图;同时运行多个脚本可以同时处理多个文件夹里的图片,只要电脑内存和硬盘读写足够,上不封顶
- 安全可靠:不对原图作任何修改,输出的裁切图片也严格限制到只做裁切和水平/垂直校准,其余属性绝不修改
- 自动识别与人工审核:能自动识别横图与竖图,只裁切能够被可靠识别的图片,无法可靠识别的情况将会把原图复制粘贴到 needs_review 文件夹以方便人工处理
⏳ 作为一名冲扫店主,处理哈苏 X5 扫描出来的长 TIFF 是一个高频的场景,不过手动裁切是一件费时费力且枯燥疲惫的事。市面上有着各种各样的裁切工具,在亲自尝试过能找到的所有之后,却总是觉得不能完美地解决自己的痛点:偏手动的效率低下,自动的却常常无法正确识别;又或者是掺杂了许多我完全不需要的花里胡哨功能,裁切的入口太深且不能批处理,反而拉低了效率。
💻 为了解决自己的(还有许多与我类似处境的人)的痛点,我只得自己动手,拿起 Codex 学习做一个 Vibe Coder。用 AI 写代码的过程出乎意料的充满乐趣。最初我以为只是一个非常简单的项目,一天之内就能解决。但是反复的调试验证以及扩充测试样本的过程中,我却发现了这是一件比想象中复杂的事。一开始我只是认为写一个脚本,捕捉到长图中两张图片中间黑色间隔的像素,就能很快很好的完成自动的裁切。但验证的结果却很快告诉我没这么容易:欠曝的图片,叠片,不稳定的片距,片头和片尾。
🤔 这些情况混杂在一起造成了非常糟糕的结果:我甚至需要在自动裁切的产出里去挑选真正可用的图片,很难说这到底是在增加效率还是降低效率。于是在几周的迭代和重构里,我加入了除了间隔检测之外的内容判断、几何修正等等各种 Policy。我也从一名初学者,开始逐渐变得有那么一点点 Coder 的思考方式了。做出来的项目也越来越准确和顺手,让我这个创造者有点自豪,也非常开心帮助到了除了我自己以外的其他人。
💡 现在脚本还有一些不足:比如对于 135 之外的格式没有足够的优化识别参数,对于叠片或者片距不稳定之类的高难度场景只能让脚本临时加 Bleed 或者让人工审核,效率仍然不够高:一张长图的分析裁切需要 10 秒。在这分享出来,也是希望得到更多的反馈让我能够优化和改进,非常欢迎在 GitHub 上提 Issue!至于是否做软件级的封装仍在犹豫中,这一点也需要用户的反馈。
📘 关联阅读: NegativeCutter-135 | Lightroom 135 胶片扫描自动裁剪插件
频道:@NewlearnerChannel
🎞 X5-Crop:轻量的 X5 扫描长 TIFF 自动裁切工具
🔗:GitHub | Releases
👉 Features
- 兼容绝大部分胶片以及扫描格式:普通 135 / 135 双条片夹 / 半格 / 645 / 66 / 67
- 使用简单:有详细的文档说明,使用方式简洁到只需要双击和回车
- 批处理:一个脚本可以批量处理整个文件夹内的所有 TIFF 图;同时运行多个脚本可以同时处理多个文件夹里的图片,只要电脑内存和硬盘读写足够,上不封顶
- 安全可靠:不对原图作任何修改,输出的裁切图片也严格限制到只做裁切和水平/垂直校准,其余属性绝不修改
- 自动识别与人工审核:能自动识别横图与竖图,只裁切能够被可靠识别的图片,无法可靠识别的情况将会把原图复制粘贴到 needs_review 文件夹以方便人工处理
⏳ 作为一名冲扫店主,处理哈苏 X5 扫描出来的长 TIFF 是一个高频的场景,不过手动裁切是一件费时费力且枯燥疲惫的事。市面上有着各种各样的裁切工具,在亲自尝试过能找到的所有之后,却总是觉得不能完美地解决自己的痛点:偏手动的效率低下,自动的却常常无法正确识别;又或者是掺杂了许多我完全不需要的花里胡哨功能,裁切的入口太深且不能批处理,反而拉低了效率。
💻 为了解决自己的(还有许多与我类似处境的人)的痛点,我只得自己动手,拿起 Codex 学习做一个 Vibe Coder。用 AI 写代码的过程出乎意料的充满乐趣。最初我以为只是一个非常简单的项目,一天之内就能解决。但是反复的调试验证以及扩充测试样本的过程中,我却发现了这是一件比想象中复杂的事。一开始我只是认为写一个脚本,捕捉到长图中两张图片中间黑色间隔的像素,就能很快很好的完成自动的裁切。但验证的结果却很快告诉我没这么容易:欠曝的图片,叠片,不稳定的片距,片头和片尾。
🤔 这些情况混杂在一起造成了非常糟糕的结果:我甚至需要在自动裁切的产出里去挑选真正可用的图片,很难说这到底是在增加效率还是降低效率。于是在几周的迭代和重构里,我加入了除了间隔检测之外的内容判断、几何修正等等各种 Policy。我也从一名初学者,开始逐渐变得有那么一点点 Coder 的思考方式了。做出来的项目也越来越准确和顺手,让我这个创造者有点自豪,也非常开心帮助到了除了我自己以外的其他人。
💡 现在脚本还有一些不足:比如对于 135 之外的格式没有足够的优化识别参数,对于叠片或者片距不稳定之类的高难度场景只能让脚本临时加 Bleed 或者让人工审核,效率仍然不够高:一张长图的分析裁切需要 10 秒。在这分享出来,也是希望得到更多的反馈让我能够优化和改进,非常欢迎在 GitHub 上提 Issue!至于是否做软件级的封装仍在犹豫中,这一点也需要用户的反馈。
📘 关联阅读: NegativeCutter-135 | Lightroom 135 胶片扫描自动裁剪插件
频道:@NewlearnerChannel
❤9🤝1
#Blog #AI
🧑🏻💻 你不知道的具身智能:从小机器狗到 Optimus
🔗:X Article
今天这篇是「你不知道的」系列第六篇,写完 Claude Code、Agent、大模型训练、AI Coding 和 GEO 之后,这次换个方向,聊我自己最不熟、又最好奇的具身智能。起点是今年 4 月,我用 STM32、ASRPRO、ESP32-C3、舵机和一堆 3D 打印件,花两百多块手搓了一台能听懂话、会走路、还能接云端 AI 对话的小机器狗。
真插上线、电机转起来才发现,从软件视角看「给大模型接个身体」很轻巧,落到物理世界完全是另一回事。一条自然语言指令要一路变成结构化意图、动作序列、PWM、力矩、电流和接触,每一层都有自己的时间和误差预算。最直观的是动作空间的差距:自动驾驶基本就方向盘、油门、刹车,而 Tesla Optimus 按 78 个执行器算,每个时间步都得把身体、手臂、手指、平衡、接触一起兼顾。
这篇文章想聊清楚这几个点:小机器狗怎么从一堆零件跑起来(异构芯片分工、端云协同、MCP)、机器人怎么知道自己在哪(深度、位姿、3D 地图)、从写死的动作到 VLA 这条路线(RT 系列、ACT、Diffusion Policy、π0、Gemini Robotics、Helix)、绕不开的时间能耗数据三道坎、Tesla Optimus 这个工程样本(纯视觉、FSD 迁移、一根没有销钉的手指、量产约束),以及几家公司的不同路线和一个软件工程师该怎么往具身智能走。
频道:@NewlearnerChannel
🧑🏻💻 你不知道的具身智能:从小机器狗到 Optimus
🔗:X Article
今天这篇是「你不知道的」系列第六篇,写完 Claude Code、Agent、大模型训练、AI Coding 和 GEO 之后,这次换个方向,聊我自己最不熟、又最好奇的具身智能。起点是今年 4 月,我用 STM32、ASRPRO、ESP32-C3、舵机和一堆 3D 打印件,花两百多块手搓了一台能听懂话、会走路、还能接云端 AI 对话的小机器狗。
真插上线、电机转起来才发现,从软件视角看「给大模型接个身体」很轻巧,落到物理世界完全是另一回事。一条自然语言指令要一路变成结构化意图、动作序列、PWM、力矩、电流和接触,每一层都有自己的时间和误差预算。最直观的是动作空间的差距:自动驾驶基本就方向盘、油门、刹车,而 Tesla Optimus 按 78 个执行器算,每个时间步都得把身体、手臂、手指、平衡、接触一起兼顾。
这篇文章想聊清楚这几个点:小机器狗怎么从一堆零件跑起来(异构芯片分工、端云协同、MCP)、机器人怎么知道自己在哪(深度、位姿、3D 地图)、从写死的动作到 VLA 这条路线(RT 系列、ACT、Diffusion Policy、π0、Gemini Robotics、Helix)、绕不开的时间能耗数据三道坎、Tesla Optimus 这个工程样本(纯视觉、FSD 迁移、一根没有销钉的手指、量产约束),以及几家公司的不同路线和一个软件工程师该怎么往具身智能走。
频道:@NewlearnerChannel
❤5
#macOS #GitHub情报 #AI
🧠 RegionSpoof:在国行 Mac 上开启完整 Apple 智能(适用于 macOS 27)
🔗:GitHub
相较于用「电子围栏」限制死的 iOS系统,macOS 相对更加开放,也给了我们国行 Mac 使用 Apple Intelligence 的机会。此前 已经介绍对应的解决方案,但 macOS 27 发布后就不再适用,且已经有一段时间不曾更新。近期冲浪的时候看到了另一套方案,和大家分享
👉 Features
- 使用极简内核扩展 kext 修改设备区域码
- 提供一件安装 / 卸载脚本
- 可启用完整的 Apple Intelligence 端侧 + Private Cloud Compute 云端全功能
💡 原理
和之前的项目都有一些不同,RegionSpoof 引入了一个第三方 kext,而不是着手修改合规文件。这几乎从源头使得全系统进程将电脑识别为美版,完美解决了 macOS 27 的 eligibilityd 基于 SwiftData 实时重算的问题
通过开机自启和添加守护进程,能够带来很不错的体验
💻 前置条件
在运行脚本前,我们需要做以下准备工作:
① SIP 关闭 + Permissive 安全模式 + 允许第三方 kext
② AMFI 必须保持开启
③ kext 首次加载需在「系统设置 → 隐私与安全性」里点 Allow 后重启
④ Apple 账户和 macOS 系统语言设置为 Apple Intelligence 支持区域
具体的步骤详见 README,有朋友反馈无法关闭 SIP,是因为 27 引入了一个 bug。为了避免我们需要:要在更新前把系统的安全性等级恢复成 Full Security 再更新,这样更新后才能调整安全等级
同时,关闭 SIP 后通过 App Store 安装的 iOS / iPadOS 软件就无法使用了,需要大家进行取舍后再决定。总之,欢迎有需求的朋友们进行尝试和反馈!
📘 关联阅读:
1️⃣ enableAppleAI:更适合中国宝宝的国行 Mac 开启 Apple Intelligence 方案
2️⃣ 巧用两个开源项目,让你的国行 Mac 使用 Apple Intelligence
3️⃣ 巧用开源项目 misakaX,让你的国行 iPhone 使用 Apple Intelligence
频道:@NewlearnerChannel
🧠 RegionSpoof:在国行 Mac 上开启完整 Apple 智能(适用于 macOS 27)
🔗:GitHub
相较于用「电子围栏」限制死的 iOS系统,macOS 相对更加开放,也给了我们国行 Mac 使用 Apple Intelligence 的机会。此前 已经介绍对应的解决方案,但 macOS 27 发布后就不再适用,且已经有一段时间不曾更新。近期冲浪的时候看到了另一套方案,和大家分享
👉 Features
- 使用极简内核扩展 kext 修改设备区域码
- 提供一件安装 / 卸载脚本
- 可启用完整的 Apple Intelligence 端侧 + Private Cloud Compute 云端全功能
💡 原理
和之前的项目都有一些不同,RegionSpoof 引入了一个第三方 kext,而不是着手修改合规文件。这几乎从源头使得全系统进程将电脑识别为美版,完美解决了 macOS 27 的 eligibilityd 基于 SwiftData 实时重算的问题
通过开机自启和添加守护进程,能够带来很不错的体验
💻 前置条件
在运行脚本前,我们需要做以下准备工作:
① SIP 关闭 + Permissive 安全模式 + 允许第三方 kext
② AMFI 必须保持开启
③ kext 首次加载需在「系统设置 → 隐私与安全性」里点 Allow 后重启
④ Apple 账户和 macOS 系统语言设置为 Apple Intelligence 支持区域
具体的步骤详见 README,有朋友反馈无法关闭 SIP,是因为 27 引入了一个 bug。为了避免我们需要:要在更新前把系统的安全性等级恢复成 Full Security 再更新,这样更新后才能调整安全等级
同时,关闭 SIP 后通过 App Store 安装的 iOS / iPadOS 软件就无法使用了,需要大家进行取舍后再决定。总之,欢迎有需求的朋友们进行尝试和反馈!
📘 关联阅读:
1️⃣ enableAppleAI:更适合中国宝宝的国行 Mac 开启 Apple Intelligence 方案
2️⃣ 巧用两个开源项目,让你的国行 Mac 使用 Apple Intelligence
3️⃣ 巧用开源项目 misakaX,让你的国行 iPhone 使用 Apple Intelligence
频道:@NewlearnerChannel
❤8👍3
#macOS #APP #AI #GitHub情报
🗣 Type4Me:AI 驱动的 macOS 语音输入法
🔗:GitHub | Releases
👉 Features
- 内置本地识别引擎,支持多家云端引擎厂商
- 支持流式识别、边说边出字,说完无需等待、快速输入
- 内置润色、Prompt 优化、翻译功能,可自定义添加任意处理模版
- 支持主流厂商 API 接入;文本处理支持使用 Ollama 接本地模型
- 支持热词、映射词
- 存储所有历史识别记录,支持导出 CSV
- 通过配套 Skill,打造只属于你的输入法
🧠 步入 AI 大爆炸时代,常常觉得打字速度跟不上脑子里天马行空的想法。各大厂商在加紧布局智能对话助手的同时,也有诸如 Typeless 这样的工具崭露头角,更有许多人为它配备了 DJI Mic 以便随时随地对话输入
💡 但每个人都有他自己的想法和说话习惯,Type4Me 就是为了高自由度和自定义度而打造的新语音输入法。它支持本地模型,也可以接入云端大模型,同时能够根据你的需要进行高度自定义,使用起来比较流畅。无论是生成结果 AI 再润色,还是支持历史导出,都紧贴当下 AI 时代需求
👀 当然了,有的朋友不想折腾太多,想要开箱即用,最后再介绍几个商业项目。Typeless 不再赘述,近期看到国人开发的同类项目 Voilà,需要一次性买断(支持一个月试用)。此外,许多网友反馈豆包输入法也不错,大家可以根据自己的需求进行试用
📘 关联阅读:
1️⃣ Typeless:用 AI 重新定义语音听写
2️⃣ MemoAI:好用的语音转文字工具
3️⃣ 精准转写:利用 Whisper 处理音视频转文字不完全指南
频道:@NewlearnerChannel
🗣 Type4Me:AI 驱动的 macOS 语音输入法
🔗:GitHub | Releases
👉 Features
- 内置本地识别引擎,支持多家云端引擎厂商
- 支持流式识别、边说边出字,说完无需等待、快速输入
- 内置润色、Prompt 优化、翻译功能,可自定义添加任意处理模版
- 支持主流厂商 API 接入;文本处理支持使用 Ollama 接本地模型
- 支持热词、映射词
- 存储所有历史识别记录,支持导出 CSV
- 通过配套 Skill,打造只属于你的输入法
🧠 步入 AI 大爆炸时代,常常觉得打字速度跟不上脑子里天马行空的想法。各大厂商在加紧布局智能对话助手的同时,也有诸如 Typeless 这样的工具崭露头角,更有许多人为它配备了 DJI Mic 以便随时随地对话输入
💡 但每个人都有他自己的想法和说话习惯,Type4Me 就是为了高自由度和自定义度而打造的新语音输入法。它支持本地模型,也可以接入云端大模型,同时能够根据你的需要进行高度自定义,使用起来比较流畅。无论是生成结果 AI 再润色,还是支持历史导出,都紧贴当下 AI 时代需求
👀 当然了,有的朋友不想折腾太多,想要开箱即用,最后再介绍几个商业项目。Typeless 不再赘述,近期看到国人开发的同类项目 Voilà,需要一次性买断(支持一个月试用)。此外,许多网友反馈豆包输入法也不错,大家可以根据自己的需求进行试用
📘 关联阅读:
1️⃣ Typeless:用 AI 重新定义语音听写
2️⃣ MemoAI:好用的语音转文字工具
3️⃣ 精准转写:利用 Whisper 处理音视频转文字不完全指南
频道:@NewlearnerChannel
❤9👍1
#AI #Tools #GitHub情报
🧠 Tolaria:更 Git-first 的 Obsidian 替代品
🔗:Web | GitHub
⭐️ Features:
• MD + YAML 本地保存,无私有格式
• Git-first
• 支持块编辑器
• 原生支持多种 AI agent
• 无账号、无订阅、无云依赖,离线可用
• 支持 macOS / Windows / Linux,开源
和大火的 Obsidian 一样,Tolaria 也是一个本地文件优先的笔记软件。每条笔记都是 Markdown 文件,用 YAML frontmatter 存结构信息,Wikilinks、关系、白板、媒体预览这些能力也都在熟悉的 PKM 语境里。两者的区别在于 Obsidian 更像一个高度可扩展的个人知识工作台,很多能力依赖插件补齐,用户也很容易陷入到无限的美化和插件折腾的怪圈里;Tolaria 则固定了一系列的笔记工具如块编辑、Slash Command、Git 提交、历史浏览和推送同步,用户开箱就能用到这些核心能力,并且原生集成 AI agent。
在同步功能上,Tolaria 把每个 vault 当成 Git 仓库,在应用内即可提交、推送、查看历史,以及对单篇笔记浏览版本变化。这个设计可能偏极客,但是对于接触过 Git 的用户可能非常有用,因为知识库本来就应该是可以溯源的。
🤔 虽然 Tolaria 经常被拿出来同 Obsidian 对比,但 Tolaria 不一定是给所有 Obsidian 用户的替代品。如果已经深度依赖 Obsidian 的插件生态、移动端体验和长期打磨出的工作流,Tolaria 目前肯定不能直接替换。可以把 Tolaria 看作是 AI 时代里被打上 Mod 的 Obsidian,Git 同步和 AI 接入更原生、更少折腾。当然目前 Tolaria 还处于早期且迭代非常积极的开发阶段,功能可能频繁变化,也可能有 bug,使用时应当注意备份。
频道:@NewlearnerChannel
🧠 Tolaria:更 Git-first 的 Obsidian 替代品
🔗:Web | GitHub
⭐️ Features:
• MD + YAML 本地保存,无私有格式
• Git-first
• 支持块编辑器
• 原生支持多种 AI agent
• 无账号、无订阅、无云依赖,离线可用
• 支持 macOS / Windows / Linux,开源
和大火的 Obsidian 一样,Tolaria 也是一个本地文件优先的笔记软件。每条笔记都是 Markdown 文件,用 YAML frontmatter 存结构信息,Wikilinks、关系、白板、媒体预览这些能力也都在熟悉的 PKM 语境里。两者的区别在于 Obsidian 更像一个高度可扩展的个人知识工作台,很多能力依赖插件补齐,用户也很容易陷入到无限的美化和插件折腾的怪圈里;Tolaria 则固定了一系列的笔记工具如块编辑、Slash Command、Git 提交、历史浏览和推送同步,用户开箱就能用到这些核心能力,并且原生集成 AI agent。
在同步功能上,Tolaria 把每个 vault 当成 Git 仓库,在应用内即可提交、推送、查看历史,以及对单篇笔记浏览版本变化。这个设计可能偏极客,但是对于接触过 Git 的用户可能非常有用,因为知识库本来就应该是可以溯源的。
🤔 虽然 Tolaria 经常被拿出来同 Obsidian 对比,但 Tolaria 不一定是给所有 Obsidian 用户的替代品。如果已经深度依赖 Obsidian 的插件生态、移动端体验和长期打磨出的工作流,Tolaria 目前肯定不能直接替换。可以把 Tolaria 看作是 AI 时代里被打上 Mod 的 Obsidian,Git 同步和 AI 接入更原生、更少折腾。当然目前 Tolaria 还处于早期且迭代非常积极的开发阶段,功能可能频繁变化,也可能有 bug,使用时应当注意备份。
频道:@NewlearnerChannel
❤5🥰1
#Internet #Tools #AI
🔑 iroh:用公钥而不是 IP 地址来「拨号」任意设备的点对点网络库
把 IP 换成密钥:无论设备在哪、网络怎么变,只要知道对方的公钥就能建立一条默认直连、默认端到端加密的连接,让整个互联网变成一台「安全的 localhost」。
✨ 特点
- 拨号密钥而非 IP:每台设备用一对密钥标识,公钥即地址。设备换网络、跨 NAT、藏在防火墙后都能被稳定寻址,连接不会因为 IP 变动而断掉。
- 默认直连、默认加密:优先打洞建立设备间直连,常见场景 95% 以上的数据不经云端中转,既降低云出口带宽费,也让端到端加密成为默认而非可选。
- QUIC 多路径:同一条连接内可同时管理 Wi-Fi、蜂窝等多条路径,并随信号质量热切换,弱网和移动场景下连接更稳。
- 模块化协议生态:在裸连接之上提供 Blobs、Gossip、Documents 等可插拔协议,按需组合。
- 自定义传输:统一的「拨号密钥」抽象之下可接入 BLE、LoRa(建设中)、WiFi Aware 甚至 Tor,也支持编译到 WASM 在浏览器运行。
- 多语言绑定:除 Rust 外,1.0 起官方支持 Python、Node.js、Swift、Kotlin,可直接嵌进 iOS 与 Android 应用。
⚙️ 机制
iroh 的底层是点对点的 QUIC 连接:用 EndpointId(一枚 ed25519 公钥)直接作为 TLS 握手中的身份,因此连接天然双向认证、无法被中间人劫持。建立连接时,端点先把 (endpointid, relayurl) 发布到 pkarr 记录,对方通过 DNS 查到中继地址完成 QUIC 握手,握手后双方交换 IP 尝试打洞转为直连,打洞失败则继续走中继回退。
地址查找上它没有自研 DHT,而是复用 BitTorrent mainline 这张全球最大的 DHT,尽量站在 IETF 标准(QUIC、TLS、ALPN)之上——用 wireshark 抓包看到的就是一个普通 QUIC 连接。
主要依赖:核心用 Rust 编写(占比 99.6%),基于自研 QUIC 实现 noq,加密全部采用标准 TLS,并已支持可选的后量子密钥交换。
👨🏻💻 使用场景
- 分布式 AI 训练:跨 AWS、GCP、Azure 与自建节点做梯度共享和管线并行时,用 iroh 在地理上分散的算力之间建立直连通信,省掉中心协调器。Nous Research、PrimeIntellect 均已在生产中这样使用。
- 移动应用实时同步:网络时断时续的环境里,为数十万台设备提供可靠的数据同步,设备切换 Wi-Fi 与蜂窝时连接自动迁移。
- POS 支付:让支付终端通过 BLE、LAN 或 Wi-Fi 直连收银系统,满足 PCI 合规且不需要额外服务器。
- IoT 与嵌入式:在 ESP32、Raspberry Pi、Linux 上跑同一套 API,设备自动相互发现,无需 broker 或网关。
- 文件传输与音视频流:在设备间做内容寻址、可续传、逐字节校验的大文件传输,或搭建低延迟的加密视频流。
🛣 路线图
- 更多开箱传输:目前开箱仅支持 IPv4、IPv6 和中继三种传输,自定义传输 API 刚推出不久,LoRa 传输尚在建设中。
- 浏览器作为对等端:现阶段浏览器接入仍需借助 webrtc,让浏览器真正作为 iroh peer 参与是社区高频诉求。
- 加密 ClientHello(ECH):用于隐藏 QUIC Initial 包里的 SNI,等待 rustls 上游支持后再集成。
💬 社区评价
iroh 于 2022 年开源,历经 4 年、 65 个预发布版本后在 2026 年 6 月发布 1.0。目前在 GitHub 上获得约 10,000+ 星标、464 次 Fork、 60 位贡献者参与开发,crates.io 上每月约 6.1 万次下载、被 196 个 crate 依赖,公共中继近 30 天创建了超过 2 亿个 endpoint,社区活跃度很高。
- 「网络速度翻倍,我们的算力预算就减半。」
-「想连两台电脑,用 Tailscale;想给 App 里的某个功能加点对点连接,用 iroh。」
🖊 作者背景
- Brendan O'Brien - 联合创始人 / CEO:曾在 Protocol Labs 参与去中心化 Web,做过 qri(去中心化数据集版本管理)等开源项目。
- Friedel Ziegelmayer - CTO:前 Protocol Labs 工程师,iroh 头号贡献者,深耕 Rust 加密与 P2P 生态。
💰 定价
核心库与协议永久开源免费,商业化通过 iroh services(托管中继、监控仪表盘、网络诊断)实现。
- Free:$0/月 · 本地开发测试、7 天数据保留、社区支持。
- Pro:$19/月起 · 用量计费、30 天保留、8x5 工单支持;专属中继 $199/relay/月、额外连接 $0.5/100 endpoints。
频道:@NewlearnerChannel
🔑 iroh:用公钥而不是 IP 地址来「拨号」任意设备的点对点网络库
把 IP 换成密钥:无论设备在哪、网络怎么变,只要知道对方的公钥就能建立一条默认直连、默认端到端加密的连接,让整个互联网变成一台「安全的 localhost」。
✨ 特点
- 拨号密钥而非 IP:每台设备用一对密钥标识,公钥即地址。设备换网络、跨 NAT、藏在防火墙后都能被稳定寻址,连接不会因为 IP 变动而断掉。
- 默认直连、默认加密:优先打洞建立设备间直连,常见场景 95% 以上的数据不经云端中转,既降低云出口带宽费,也让端到端加密成为默认而非可选。
- QUIC 多路径:同一条连接内可同时管理 Wi-Fi、蜂窝等多条路径,并随信号质量热切换,弱网和移动场景下连接更稳。
- 模块化协议生态:在裸连接之上提供 Blobs、Gossip、Documents 等可插拔协议,按需组合。
- 自定义传输:统一的「拨号密钥」抽象之下可接入 BLE、LoRa(建设中)、WiFi Aware 甚至 Tor,也支持编译到 WASM 在浏览器运行。
- 多语言绑定:除 Rust 外,1.0 起官方支持 Python、Node.js、Swift、Kotlin,可直接嵌进 iOS 与 Android 应用。
⚙️ 机制
iroh 的底层是点对点的 QUIC 连接:用 EndpointId(一枚 ed25519 公钥)直接作为 TLS 握手中的身份,因此连接天然双向认证、无法被中间人劫持。建立连接时,端点先把 (endpointid, relayurl) 发布到 pkarr 记录,对方通过 DNS 查到中继地址完成 QUIC 握手,握手后双方交换 IP 尝试打洞转为直连,打洞失败则继续走中继回退。
地址查找上它没有自研 DHT,而是复用 BitTorrent mainline 这张全球最大的 DHT,尽量站在 IETF 标准(QUIC、TLS、ALPN)之上——用 wireshark 抓包看到的就是一个普通 QUIC 连接。
主要依赖:核心用 Rust 编写(占比 99.6%),基于自研 QUIC 实现 noq,加密全部采用标准 TLS,并已支持可选的后量子密钥交换。
👨🏻💻 使用场景
- 分布式 AI 训练:跨 AWS、GCP、Azure 与自建节点做梯度共享和管线并行时,用 iroh 在地理上分散的算力之间建立直连通信,省掉中心协调器。Nous Research、PrimeIntellect 均已在生产中这样使用。
- 移动应用实时同步:网络时断时续的环境里,为数十万台设备提供可靠的数据同步,设备切换 Wi-Fi 与蜂窝时连接自动迁移。
- POS 支付:让支付终端通过 BLE、LAN 或 Wi-Fi 直连收银系统,满足 PCI 合规且不需要额外服务器。
- IoT 与嵌入式:在 ESP32、Raspberry Pi、Linux 上跑同一套 API,设备自动相互发现,无需 broker 或网关。
- 文件传输与音视频流:在设备间做内容寻址、可续传、逐字节校验的大文件传输,或搭建低延迟的加密视频流。
🛣 路线图
- 更多开箱传输:目前开箱仅支持 IPv4、IPv6 和中继三种传输,自定义传输 API 刚推出不久,LoRa 传输尚在建设中。
- 浏览器作为对等端:现阶段浏览器接入仍需借助 webrtc,让浏览器真正作为 iroh peer 参与是社区高频诉求。
- 加密 ClientHello(ECH):用于隐藏 QUIC Initial 包里的 SNI,等待 rustls 上游支持后再集成。
💬 社区评价
iroh 于 2022 年开源,历经 4 年、 65 个预发布版本后在 2026 年 6 月发布 1.0。目前在 GitHub 上获得约 10,000+ 星标、464 次 Fork、 60 位贡献者参与开发,crates.io 上每月约 6.1 万次下载、被 196 个 crate 依赖,公共中继近 30 天创建了超过 2 亿个 endpoint,社区活跃度很高。
- 「网络速度翻倍,我们的算力预算就减半。」
-「想连两台电脑,用 Tailscale;想给 App 里的某个功能加点对点连接,用 iroh。」
🖊 作者背景
- Brendan O'Brien - 联合创始人 / CEO:曾在 Protocol Labs 参与去中心化 Web,做过 qri(去中心化数据集版本管理)等开源项目。
- Friedel Ziegelmayer - CTO:前 Protocol Labs 工程师,iroh 头号贡献者,深耕 Rust 加密与 P2P 生态。
💰 定价
核心库与协议永久开源免费,商业化通过 iroh services(托管中继、监控仪表盘、网络诊断)实现。
- Free:$0/月 · 本地开发测试、7 天数据保留、社区支持。
- Pro:$19/月起 · 用量计费、30 天保留、8x5 工单支持;专属中继 $199/relay/月、额外连接 $0.5/100 endpoints。
频道:@NewlearnerChannel
❤13