按理说 XMP 头里面 VCamera 开头的元数据应该不影响谷歌相册兼容性，因为我自己使用的 OPPO 手机的 Live photo 就是 XMP 头里有 GCamera （谷歌原生）+OpCamera （私货）的元数据，不影响谷歌相册播放。

文件末尾 vivo 附加的 box 可能是影响因素（ OPPO+谷歌兼容的 live photo 没有这部分）。

另外可以再 Vibe 分析一下 Exif ，看一下里面是否有私货，有的字段比如 UserComment 可以包含一些能被手机相册识别的 feature flag （ bitmask ）。

另外你可以用你的手机在微博、小红书等社交平台上下载一个别人用苹果上传的 live photo （社交软件下载的时候会自己构造一个兼容你手机格式的 jpg ，私货比手机自己拍摄的少）。可以把这个样本一起给 AI 进行 vibe 分析+开发。

你可以用自己的 vivo 手机拍一张 live photo ，然后 vibe 分析一下元数据格式（私货成分+Google 原生动态照片成分），再尝试 vibe 出一个输出最简有效格式的 Vivo 动态照片的 app （一定要反复测试，去除所有冗余的字段和含义未知的字段值，避免造成兼容性干扰），理论上应该可以输出能让 Vivo 相册和 Google Photos 都能识别的动态照片。

上述操作中使用 vivo 手机拍摄的样本的时候，需要排除其中的 HDR Gain Map （ Google UltraHDR + VIVO 私货）的干扰（让 AI 知悉 jpg 里除了内嵌 mp4 以外还内嵌了其它私货注意区分即可），可以另外 vibe 一个剥离 HDR Gain Map 只保留正常 jpg 部分的 app 。

我自己就是按照以上思路让 AI 自己做了一个 Skill 来生成 OPPO 兼容的 live photo ，OPPO 自带相册+谷歌相册+国内社交软件都能识别。

版本答案（假设开发框架跨平台，不考虑有平台锁定的开发需求例如 iOS 移动端，Win 客户端等）：
1. Windows 笔记本：处理（非开发类） Windows only 办公需求，以及其它轻量级需求。
2. Linux 台式机：主力开发平台。选用台式机主要考虑到安装 Linux 系统的便利程度，其次才是性能因素。

如果自己安装配置环境以及 Troubleshooting 能力强，且平时 Windows only 的办公需求少，不太在意笔记本续航，也可以一步到位直接在笔记本上装 Linux （可能需要牺牲笔记本原厂的一些便捷功能，谨慎选用，Linux 还是推荐在台式机上运行）。

以上这个是无厂商锁定，可以随意选取你喜欢的品牌/厂商的 PC 机的方案，如果自己已经拥有相应的设备（笔记本+台式机各一台）甚至无需购置新机。

如果你没有 mac 平台使用经验或明确的特定软件需求，不建议仅仅是为了 Agentic Coding 而跟风购置 mac 设备。适合 Agentic Coding 的 Linux 系统在你既有的 PC 设备上基本都能轻松运行（包括但不限于 WSL ，其它虚拟机，双系统，独立使用一台闲置设备全盘安装等方式）。

@ponelyr 绝大多数 CLI Agent 都是不支持“系统代理”的，要么用 TUN 模式，要么设置 http_proxy https_proxy 环境变量（ CLI 支持的情况下）

@ponelyr 多半是因为节点没用上。

你是用的 OpenCode 还是其它软件？ OpenCode 不支持“系统代理”，只支持通过 http_proxy, https_proxy 环境变量来设置代理。其它软件自行寻找正确的挂代理方法。

或者使用万能的 TUN 模式。

补充一下，第二个问题，如果有适配别的软件的需求的话，根据你要适配的 target 来，区分清楚是 32 位版本还是 64 位版本，全部使用一致的一种，不要混用。

确认版本要看 target 字符串里面有没有"i686"（ 32 位）或者"x86_64"（ 64 位）字样。
不要看发行版品牌名（“mingw-w64”同时提供有 64 位和 32 位版本）
不要看 exe 文件名（都是 mingw32-make.exe ）

第一个问题的话，看一下你移动过的几个环境变量，是不是包含了其它内置 MinGW 的软件，MinGW 工具链出问题其中一个很常见的原因就是 DLL 版本不匹配，一般都是因为电脑上装了别的自带 MinGW 的软件，加了环境变量。


第二个问题的话，除非有特殊需求，64 位系统一定要下载 64 位版本（ x86_64 ）的 MinGW 工具链，混用 32 位的容易出问题。

如果你用的 MinGW 发行版不支持的话，可以考虑换成 winlibs 或者 mingw-w64 （注意"mingw-w64"是发行版名称，不代表一定是 64 位的，下载的时候要看一看是不是 x86_64 版本）。

32 位和 64 位版本的 make 程序名称都是 mingw32-make.exe ，容易搞混，记得检查你实际下载到的二进制是哪个 target 的。

@msojocs Podman Desktop 自动映射依赖 WSL2 自带的自动映射，你看一下 WSL2 里面启动一个监听本机 127.0.0.1 地址和任意端口的程序，会不会自动启动一个 wslrelay.exe 后台进程自动转发端口。如果这个没问题的话，Podman 自动映射应当也没问题。如果有问题的话，需要检查一下 WSL2 的配置。

@neoshui rEFInd 应该是支持读取其它分区的（可能需要重新安装一下 rEFInd ，配置一下相应文件系统的 UEFI 驱动），可以试一下配置成直接读你的 Linux 分区里面的内核。
主流 UEFI 引导器里只有 systemd-boot 是必须把内核放在 ESP 里，其它基本都支持别的分区（文件系统支持会有一些差异）。

以下只考虑 AppStore 或者 Google Play ，不考虑 GPT/Claude 官网直充（风控严格很多，而且你没国外卡也用不了）

节点 IP 上一般不需要太干净，同样是低质量 IP ，我一直都用垃圾机房 IP （ IP 标记 Datacenter ），除了之前有个号作死卡 Link 支付的 bug 通过官网用国内卡直充成功导致被封以外，其它的号（其中主力账号是用 Google Play 订阅）用同样质量的机房 IP 节点都没被封。但是如果是万人骑 VPN （ IP 标记为 Public Proxy ）的风险就会很大。

如果没有优质的 IP 资源的话，不妨用 VPS 自建节点单人使用，尽管是机房 IP 但是比垃圾机场效果好。

另外礼品卡使用要谨慎。

像 Google Play 这种（美区等非低价区）支持其它国家信用卡的，优先使用国内信用卡，国内信用卡海淘银行端一般不验账单地址，Google 上直接随便填美国免税州地址就行了，直接用美区不折腾，不要尝试卡 bug 转土耳其之类的低价区，Google 礼品卡风控也异常严格不建议使用。

苹果这种限制银行卡地区，只能用礼品卡，只推荐美区官网直购电子版礼品卡（和 Store 直充不一样，官网购礼品卡支持国内信用卡，Visa/Master/银联都支持），同样不推荐转低价区因为无法直购礼品卡。

使用礼品卡有一点必须牢记，就是礼品卡不存在可信的第三方平台。因为本质上都是接入的第三方商家，货源无法保证，难免遇到涉及金融欺诈的，这种遇到一次就是必封号。哪怕是支付宝境外消费频道，都能买到黑卡刷出来的礼品卡。

记住礼品卡无大平台！（这一点年年有人不信，年年有人踩坑）礼品卡唯一可信渠道就是用自己的国内信用卡直购官网电子版（官网不限制的情况下），或者旅游时购买海外商店实体版。

用第三方平台买礼品卡就要做好扔账号的准备。

不支持 Podman 吗，感觉用 Rootful 的 Podman 加上 compose 支持（ Docker Compose V2 二进制或者专门的 podman-compose ）应该可以吧

@WayneCmd 不用完全理解啊，只要知道安卓不支持有状态，选了安卓会获取不了地址，其余的都基本不影响日常使用

@WayneCmd ASUS 也没有中继/NDP 相关的配置呀，而且 SLAAC/DHCPv6 相关的配置也简化成了一个 地址获取方式：有状态/无状态 的开关。

@WayneCmd 你说的这些是 OpenWRT 才有的设置，普通家庭用户使用的消费级路由器根本没有这么多选项。

@zwhfly 点对点链路的路由里其实不需要下一跳，只要有出接口就行，理论上不要任何公网地址，只要有 fe80 开头的 link-local 地址就可以进行你的拨号设备和运营商之间的通信了，给地址是为了让你这边的设备可以接入公网。

而这个地址配置到哪个接口上都不影响你的路由器对外联网，上面有人提到的 RFC 7278 ，原理上就是把这个/64 整个移到 LAN 段，WAN 段只用 link-local 地址和 PPP 对端通信。

其实这个例子也不完全是奇技淫巧。它对应了一种 Debug 场景：误将 generator/coroutine 当普通函数调用，导致相应的业务逻辑没有执行。如果用来面试的话可以从这个场景进行考察。

不用这种花里胡哨的库，要主流方案可以用 Jackson ，Spring 框架第一方支持。要高性能有 simdjson 。fastjson 就是路边一条，不知道用它有啥意义，难道就图一个可以像 JS 一样`JSON.xxx(...)`？。

现在 8.0 应该已经 EOL 了，LTS 是 8.4