肇鑫 / Owen Zhao

我经常用 Mac 的“屏幕共享”连接另一台 Mac mini。以前点一下就能进去，最近却不行了。每次连接都会先弹出一个窗口，说远端的 zhaoxin 正在使用显示器，让我选择“请求许可查看显示器”，或者“以 aiUser 身份登录”。默认选中的是请求许可。点连接以后，就一直转圈。

这就很奇怪。两台电脑上我用的都是 zhaoxin，为什么连接自己的电脑，还要等对面有人批准？Mac mini 又不一定有人坐在前面，等下去也不会有人点“允许”。我只能点 Back，重新输入 zhaoxin 的密码，才能进去。进去之后，还需要再次输入一遍密码才能进入桌面。

我一开始怀疑，是 Finder 把文件共享的登录身份搞混了。Finder 那边显示的是我的 Apple Account 邮箱，可是“屏幕共享”的连接详情里，用户名明明写着 zhaoxin。后来我又去看两台电脑的用户列表：本机没有 aiUser，远端 Mac mini 上却有。更有意思的是，选“以 aiUser 身份登录”居然也能进去。也就是说，aiUser 不是一个凭空冒出来的用户名，真正进不去的只有默认那个“请求许可”。

我又检查了远端的屏幕共享设置。允许访问的用户里有 zhaoxin，所以权限本身没问题。试过在输入密码时勾选“记住密码”，下一次仍然要输入。之前我还以为这只是密码没有保存好，现在看起来，事情没那么简单。

最后，我在 Mac mini 上删除了不再需要的 aiUser。删除之前发现，这个账户还开着“查找我的 Mac”。我先把相关功能关掉，再删除账户。结果重新连接时，那个让我选择“请求许可”或 aiUser 的窗口消失了，系统直接让我输入 zhaoxin 的密码。这次勾选“记住密码”后，再连接就直接进入，连密码也不用输了。故障排除。

总结

我怀疑 aiUser 开启“查找我的 Mac”后，在系统里有了某种更高的关联地位，影响了屏幕共享默认选择的连接方式。不过我同时关闭了“查找”并删除了账户，没有单独测试哪一步起了作用，所以不能把这个推测当成确定的原因。能够确定的是：远端多出这个账户时，屏幕共享总把我带到一个无法完成的请求许可流程；清理掉它之后，zhaoxin 的直接登录和记住密码都恢复了正常。

经常有人说ChatGPT很慢，即便是提速了之后还是慢。我看到有人发的测试图，然后自己也测试一下，发现我这次测出来的速度并不慢。刚刚，我遇到了Reconnection 5/5的问题

stream disconnected before completion: IO error: Broken pipe (os error 32)

以往我就是等它继续了。但是今天我突发奇想，新建一个对话，然后让Codex分析，这次故障的原因。Codex分析说，这个对话原本使用的是WebSockets，然后再5次重试之后，换成了http的访问方式。但是在我这里，http的访问是很慢的。因此，我担心一旦回退到http的方式，之后的对话都会继续使用http。

我使用了多种方式进行测试。首先是新建一个对话，然后让Codex分析，Codex说这个新对话还是使用的WebSockets，然后我继续刚刚出错的对话，Codex说这个继续使用了http。于是我退出Codex，重新开，然后继续刚刚出错的那个对话。结果那个对话虽然一开始恢复使用WebSockets了，但是它立刻连续失败了5次，然后又回退到http。我问Codex这种情况怎么办。Codex让我新建一个session，然后重新说明任务。这次终于好了。

总结

当长任务遇到WebSokets失败之后，最好的办法就是新开一个对话，然后重新描述任务。否则就会回退到http，这会导致对话变得很慢，根源是

WebSocket 在长任务中可以复用连接和近期响应状态，减少每次继续请求的开销；HTTP 回退会失去这项优势。

今天，Tibo在X上给出了Codex设置1M上下文的方法。我尝试了，也的确成功了。但是我又改回去默认的258K。关于上下文这个事，以下的事情是你需要了解的。

在gpt-5.6系列发布之前，Codex的上下文一直是258K。这是用户可用的部分，隐藏了系统占用的。但是gpt-5.6发布之后，这个上下文一度增加到了384K。不过很快，有人发现5.6的额度消耗过快。这是因为原本调整为384K之后，应该是384K上下文之内都应该按照默认收费，如果额外设置，超出了，才应该按照2x收费。可是实际上，OpenAI的服务器却是按照超过258K就开始2x收费，OpenAI发现了这个bug，于是回滚到258K的上下文，并且承诺，说一旦修复了。就会恢复。

可最终OpenAI并没有兑现这个承诺。258K就是目前的最终的默认上下文。唯一改变的，是以前只有使用API的用户可以设置为1M上下文，现在任何订阅的用户也可以设置了。但是一旦超过默认的258K，全部的输入都会按照2x收费，全部的输出都会按照1.5x收费。注意：是超过默认的258K，全部都会按照2x和1.5x收费，而不是超出的部分。而订阅用户，如果手动设置为更大的上下文，则会感到额度消耗得更快了。

这也是为什么我最终还是选择回退到默认的设置，毕竟省钱才是王道。

如果你想测试

可以将tibo的原文贴给AI，然后AI遵照设置，设置完成之后，需要退出重开一下Codex。取消也是同样的，需要重启Codex才能执行。

我有两台Mac mini，1台m1，一台m4都是16GB的。之前我为了节省资源，ollama都是跑在m1那台，而我日常使用的是m4的这台。这就导致了一个问题。就是我开发的Chrome扩展X Recommender Plus在调用局域网里的Ollama的时候，会被拒绝服务。这是因为，Ollama默认情况下，只针对本机的所有请求开发了服务，如果是局域网的请求，就会验证头。

因此，要解决这个问题，我就得自己修改代码，然后本地编译。方法不难，仅需要修改一行代码。但是修改之后的只有我自己能用。今天，我突发奇想，问问AI，问它可不可以在GitHub上fork一下ollama，然后完成我本地操作的步骤，最后发布。AI说可以，然后就开始跑。

前几次都收到run failed的邮件。之后AI停了，告诉我成功了。但是我发现release里并没有成果。我问AI，AI说因为我选择的全平台，所以编译要很久，这个可把我给吓到了。因为我知道GitHub的action是有免费额度限制的。于是我赶忙问AI，那这样的话，咱们的免费额度够跑几次的啊？结果AI告诉我，我们fork的public的，而我们自己的也是public，所以action用多少都是免费的。这样我就安心了。

这个是GitHub的地址：https://github.com/owenzhao/ollama

使用X Recommener Plus的诸位可以根据需要选择。其他人有需要也可以选择。这个好处主要是两点：

1. macOS的版本默认支持苹果的mlx。
2. 局域网安装的ollama，任何应用或者插件都可以调用，不会被拒绝。

最近大家因为微信的存储有问题，从而上升到微信是否应该使用SQLite还是应该制造轮子。但其实焦点一直就错了。微信使用了SQLite，不代表它就没有制造轮子。还好我的年纪大，记忆也还不错，搜索了一下，找了证据。wcdb，这个就是微信开源的SQLite工具，至今还在维护。所以，说它没造轮子是不正确的。

这件事，其实让我想到的是其他的事情。随着AI辅助编程的出现，编程技能越来越被普通人所忽视，甚至上升到了不是程序员，编程反而更有优势这种奇谈怪论，逻辑是说非程序员不会收到懂编程的束缚，可以天马行空，所以更容易成功。这叫好比说不懂物理的人，可以不受到物理定律的束缚，所以可以天马行空，轻松超越光速。这可能吗？

不过AI的确把编程的门槛降低了。但是如果你的应用不是为了自用，而是为了卖掉。那就不是只自己满意就可以了。而是要知道用户想的是什么。用户的想法，在我看来，则是信誉的问题，同样的应用，如果是来至更值得信赖的来源，比如知名的开发，知名的大公司，那肯定比不知名的开发者或者不知名的小公司的产品更加容易成功。而开发者，则需要用时间和产品来证明，自己是值得信赖的。

Xcode Cloud如果归档设置了无，然后后续设置为TestFlight。这样打包的应用是不能发布到商店的。但是现在App Store Connect的分发页却允许选择这个的打包的应用，不过问题来了，选完之后，点保存，会直接出现感叹号，没有办法保存，也就没法审核。

正确的方式，是归档时设置为App Store Connect，然后后续选择TestFlight。然后保存，重新打包就可以了。

最近遇到了一个问题，我的Mac mini m4在睡眠之后，很快就会再次唤醒。有时刚刚睡眠就唤醒，有时睡眠不到1分钟就会唤醒。

现在已经是AI的时代了。我于是就询问AI怎么处理。AI给我了几个命令，让我看输出，我说没输出，它有给我另外一组命令，我将输出复制给它。AI说是我的蓝牙键盘造成的，睡眠之后它还在发出信号。我按照它的提示，将键盘从蓝牙改成有线，结果忽好忽坏，效果不如意。

AI还提了一个很可笑的建议，它让我把系统的蓝牙关了，然后再睡眠。这还真是一个头疼医头的建议，因为我的键盘鼠标都是蓝牙的，禁用了，就开不了了。

不过我也的确同意大概率是蓝牙的问题，可问题是我有三个蓝牙设备。苹果触控板、蓝牙键盘、蓝牙鼠标。我还是很相信苹果的，所以先把触控板排除了。然后我关了键盘，发现还是会唤醒。看来大概率就是蓝牙鼠标了。我关了鼠标，只留键盘和触控板。这下没问题了。试了几次，始终都没问题。

我在回想，是不是鼠标的固件升级造成的，因为鼠标的固件更新还挺频繁的。我打开了蓝牙鼠标的web驱动页，不过我还是犹豫了。

我又想了想，可能鼠标移动导致的。因为这两天我看在线视频的时候，选择全屏模式时，经常会遇到进度条忽隐忽现的问题。这个问题就是鼠标放在那里没人碰，也还在抖动。高灵敏的鼠标很容易遇到这个问题。而这个问题大概率是因为鼠标垫脏了的缘故。

我用湿纸巾清洁了鼠标垫。故障排除。

总结

AI提供的不一定对。只能作为参考。所以手动古法处理还是必要的。

如果是Windows，其实直接禁用鼠标移动唤醒就可以了，只保留案件唤醒。但是macOS没有类似的功能，所以只能采用其它的方式。

很少有人知道，我最初其实学习的是安卓开发。大概10几年前，我就已经有了第一个上架的安卓应用了。原因也很简单，当时编程还只是我的一个爱好，而我当时手里有一部安卓手机。不过我只上架了一个类似番茄钟的应用，而在那时，Google Play中国开发者只能上架免费应用，而那时好巧不巧，我居然在微博抽奖抽中了一台电信版的iPhone 5（京东的活动），于是我变成了现在的iOS/macOS开发者。

说回到Google Play。自打我成为了苹果的开发者，安卓那边我就彻底放下了。直到到了2024年，Goolge Play改了政策，给我发了邮件，说我如果一直不更新应用，也不开发新的应用，那账户就会被取消。当时，AI还没有流行，我也没有转回安卓的计划，于是我就没搭理。于是时间到了，这个开发者账户就被Google Play取消了。

当时我的想法很简单。因为我当初注册Google Play开发者的时候没花钱，我以为以后也就是重新激活一下就可以了。

今年，随着AI的流行，我发现重新回到安卓也没有那么困难。不过我应用开发得差不多，打算上架，才发现一切和我想的不一样。

首先，根据Google的政策，这个开发者账户的取消是永久的，不是暂时的。因此，并不能像邮件帐户那样重新激活。只能使用一个新的账户，重新注册。此外，当年注册账户不要钱，现在注册Google Play，需要交25美元的一次性费用。

钱交了，新注册的账户也能用了。我以为这就完了。其实还没完。

这两天我提交了应用到Google Play内测，然后添加了我的常用Google账户，也就是之前的那个被取消的Google Play的开发者账户作为测试账户。结果在运行应用的时候，这个应用无法获得应用内购买的信息。Google Play直接返回该“设备或者账户不允许进行支付”。

getOfferings error: code=PurchaseNotAllowedError, message=The device or user is not allowed to make the purchase.

我一开始以为是之前提交的信用卡过期了缘故。于是添加了新卡。还是不行。而且我注意到。我的账户在登录时，在Google Play上，连付费的排行榜都看不了。而另一个账户就可以。所以，不是账户所属的原因，而就是这个账户不行。

可奇怪的是，我在Google Play里选择切换账户，切换到可以的账户，结果也还是获取不了正确的IAP信息。

我问豆包，因为我觉得这个问题大概中国的用户遇到的更多一些。豆包和我说，需要在Google的应用里完全注销掉有问题的账户才可以。于是我尝试在设置里，将Google账户里的这个有问题的账户删掉，只保留后注册的那个。这次终于可以了。

可这样一来，我常用的Gmail就无法使用这个邮箱了。于是用小米系统自带的邮件应用登录这个Gmail。

总结

一旦你被Google Play取消了某个账户的开发者资格。你会得到以下损失：

1. 此账户永久地被Google Play拉黑，不能再次注册成为开发者。
2. 重新注册Google Play开发者需要一个新的账户，以及支持25美元的一次性费用。
3. 被拉黑的账户，不只是不能作为Google Play的开发者，而且他在Google Play上也会有限制，不能够支付，只能使用免费应用，甚至也不能作为测试账户，因为他无法获得收费的任何信息。

以上就是我遇到的教训。大家遇到了最好还是随便开发个应用，上传一下。