感谢作者，几年前的项目就开始在用 Quill ，记得那时候是少数对 operational transformation 支持非常好的库
感动，有生之年系列啊！我还以为 package.json 里 "quill": "^2.0.0-dev.4" 这一行永远没机会改了 https://i.v2ex.co/504J5BO2.png

诶，今天才在推特上看见 https://music-theory.aizcutei.com/ 这个项目，也是楼主翻译的。可以讲讲两个项目背后的故事吗？

我的某个创业朋友表示已经把主要业务逻辑从 GPT-4-Turbo 切换到 Claude 3 Opus 了，说是 Opus 在逻辑推理和遵循指令上有明显优势。这让我对 Claude 仅擅长行文修辞的老印象有所改变了。
经过了之前的低迷期，Anthropic 似乎又支棱起来了啊

写得很清晰的科普！
（假设 Fediverse 成为主流，） Fediverse 最终会走向由寡头实际控制的未来吗？

今日份欢乐，ALOHA 失败集锦
https://twitter.com/dotey/status/1743396313704649064
不过这机器人的 few-shot learning 确实了得。

@mwVYYA6 可恶，被发现了>///<

@Genii @siriussilen
模型： https://huggingface.co/Undi95/Mixtral-8x7B-MoE-RP-Story
对应的 quantization： https://huggingface.co/Undi95/Mixtral-8x7B-MoE-RP-Story-GGUF

@siriussilen 谢谢纠正！严谨地说，这个模型是拿 8 个原本独立的 7b 模型用 Mixtral-8x7b 架构组装在一起而成的。那 8 个独立的 7b 模型是用各自的数据集分别精调的。

@showgood163 确实，我自己实际使用体验是显存占用维持在 25.9G 左右

@neteroster 赞同啊，不过 NovelAI 被迫开源这一段往事哈哈哈。另外，本地 LLM 的成本还不够平民化，不过应该是本年之内能解决的问题了

@neteroster @hellojay Stable Diffusion 的新动向我有几个月没关注了，现在就偶尔拿之前的 prompt 生成几张。等我哪天见到新突破或许会开坑（不过浓度太高的话可能去 Bangumi 发？

@showgood163 嘿嘿谢谢关注。对的，25GB 对应 4bits quantization ，100GB 对应官方全量的模型 (float16 ，用 Flash Attention 2) 。

@cwyalpha 嗯嗯，慢慢坐等开源界达到 Claude 2.1 的水平，按照这个进度应该不会太久

@paopjian 用的都是官方原模型 + prompt 。微调嘛，一定程度上会限制模型的能力。

@molezznet 如果有可以自己配置的 NAT 确实是最好的情况。acp 的打洞也有 UPnP 等端口映射方法的支持，让路由器的 NAT 能配合打开端口。不过现实的情况是有时会有两层或以上的 NAT ，而且多是像电信运营商那种用户无法配置的 NAT ，就比较麻烦了

当然是用来实现邪道三元运算符：

func tern[T any](cond bool, a T, b T) T {
   if cond {
      return a
   }
   return b
}

var x, y int
x = tern(true, 42, 1)
*tern(false, &x, &y) = 42

越过现象看本质：无论什么领域的代码、无论多大规模的项目，维护靠的都是模块化，即把一个项目拆分成尽量相互独立的部分，以便管理维护。

对于一个 .ipynb 文件，单元格就是一种模块化。而一个组织良好的 Python 项目并不会是单个 .py 文件，而是会包含许多相互依赖的 .py 文件和文件夹，它们构成了 Python 模块化中的包（ package ）和模组（ module ）。

以 debug 举例，一个 Python 项目中，一个 .py 文件实现一个具体的功能，与之对应的一个单元测试文件针对性验证这个 .py 文件的功能。所以很多时候 debug 并不用运行整个项目，而是单独运行查验一个单元测试文件。

最后多讲两句，.ipynb 是快速验证想法或者做小 demo 的利器。但如果一个项目持续增长到一定规模，最终还是整理成一个 Python 的包更有利于长期维护，因为线性组织的 .ipynb 很难维护多层的依赖关系，而且版本控制也比较困难。再说你写成一个包也是可以在 .ipynb 里导入使用的。

你这 sd 怎么纯热水也能拉花？

@Lighthughjiajin 免大佬。基本没问题，就是注意一下依赖关系，Syncer 单方面依赖 Actor ，22 行是没必要的。

不过这个玩具例子有点过于复杂了😅，但愿你在实际应用中不会经常遇到这种情况。

@Lighthughjiajin 嗯对，为了清晰对应你的例子我尽量沿用了你的命名。Go 里的 Interface 一般都是“动词 + er”来命名。假设我把 fn 重命名为 act ，那接口就叫 Actor 或者 DeviceActor ，对应的实现叫 PCActor 和 RouterActor 。

关于你提到的无法重写 sync 方法的问题，这意味着在你的业务逻辑里 sync 并不是只有一个实现，那就应该也把它列进接口里。根据不同情况，可以开一个新的 interface ，也可以加进 IDevice 。
- 开一个新的 interface 那就可以实现一个 type DefaultSyncer struct{}，只是初始化 Device 时得传两个值
- 加进 IDevice 就是强制要求每一个具体实现都要实现 sync

Go 的 interface 和 struct 那一套鼓励的是组合 (composition) 而不是继承，所以像 PC 和 Router 这种实现具体功能的类是会被作为 Device 这种实现公共方法的类的**一部分**，就是 Device 包裹住 PC 或 Router 。下面是我个人认为的对应 Go 的地道解决办法： https://go.dev/play/p/wio55S6HtdK