花了一天半时间，总计11.6小时通关了这个游戏的全部结局。我可以负责任地说，虽然这个游戏讲的是捞女，但是却完全没有贬低捞女。

虽然存在凤凰社这个捞女组织，使用变凤凰的方式招捞女，培训捞女。但是具体到每位女性本身。却有着不同的身份背景，她们有的是遇人不淑，被渣男欺骗，被父母抛弃，被丈夫家暴，还有的只是为了寻找一份属于自己的爱情。

而捞女之上，还有权力阶层。凤凰社创办人虽然身为女性，但是她创办凤凰社的目的却并非为了帮助女性，而是借助女性敛财，以及提供性贿赂给权力阶层，从而获取自己的非法利益。而凤凰社对于捞女也存在压榨。她们培训捞女前需要为捞女培训和整容，而这些费用要由捞女自己出，有潜力的她们会借一部分。但是如果不够或者是潜力低的，就需要自己去贷款来上课、整容。而贷款就是那种裸贷的形式。如果今后钱没还清也骗不到钱，就会拍去色情部门去服务男人来还钱。一旦你想退出，她们就会拿之前拍到的你的隐私来威胁你。

而且这个游戏虽然有捞女，有捞女组织，有打击捞女的团队。但是这里面即便是所谓的反派，三观也都是正的，做坏事的人也会心存愧疚，有机会也会想做一些好事。这也是为什么玩家可以正常地和她们沟通，从而从情感上改变她们。如果她们的本质是邪恶的，那么犹豫三观不同，这个游戏过程最终就没法进行下去了。

总结起来，游戏起名叫捞女游戏，本质上是为了博眼球，吸引大众的注意。而他们也的确做到了。改名后的情感反诈模拟器反而更加贴切。

最后，期待团队承诺的销量超过37万份后，提供的4K视频的更新。

大模型，以下简称AI。目前在辅助编程方面十分流行。不过在我使用过多个不同的类似工具，包括并不限于Github Copilot，AlexSideBar，通义灵码等，之后。我发现了一个有趣的现象。

在解释这个有趣的现象之前。我想先向某些不熟悉AI编程的读者简单介绍一下AI编程的大致过程。

1. 开发者使用编辑器将开发的项目打开。
2. 选择用来询问、作答的AI模型。
3. 提出具体的问题，同时还要划定范围，比如说是单独的某个文件，又或者某几个文件，又或者全部文件。（有些比较智能的客户端会主动扩大范围，这个暂不讨论）
4. 等待AI分析、作答。
5. 开发者对比AI的代码和原始代码，评估是否解决了提出的问题。如果解决，就可以跑一下测试看看。如果没解决，那就针对不足的地方重新提问。
6. 以此反复。

分析

经常有人说某某AI编程工具特别牛，就是token用得太狠了。充上100美元，一天就用光了。那么，如果我们想减少token的用量，我们一起看看上面的6个步骤有哪些可以进行优化，以减少用量。

首先排除1和4、5和6。要想减少token的用量。主要看2选择的模型，和3提出的具体的问题，以及划定的范围。

但是2这个可以选择的范围不大。因为每个人都有各自的偏好。有的人觉得Claude Opus最牛，有的人觉得Gemini Pro最强，当然也有人更偏好OpenAI O3的。所以，这个主要是个人便好，而不是token消耗。

因此主要的问题就在与步骤3。抛开你和AI对话的那几段文字。划定的范围是最重要的，选择单一文件或几个文件，相比于直接扔整个项目给AI，让它自己选，消耗的token数量肯定不是一个数量级别的。

那么我们要如何优化步骤3呢？首先，我们发现每次发送文件给AI时，AI都是当作是全新的在解析，也就每次都要消耗新的token。理论上，如果我们可以每次把内容分成不变的和已经变化的发给AI，然后让AI处理变化的部分，就可以节省大量的token。而且，由于我们大部分时间都是接受了AI给出的方案。那么AI实际上并不需要重新理解当前的代码。如果它确定用户接受了它的方案，它只需要将它上次输出的结果的token直接拿过来作为输入就可以了。

如果厂家可以做到我上面提出的这个优化，那么我们理论上最高可以节省接近一半的token。但是厂家应该没有动力去做这个优化。因为在这个问题上，厂家、AI、开发者的利益是不一致的。

• 对于AI来说，直接使用结果的token来作为输入的一部分是有益的，因为提高了效率。
• 对于开发者来说，更是有益的，因为可以省钱。
• 但是对于厂家来说，用户省下的钱，就是他少赚的钱。因此，虽然厂家一再强调AI的普及需要大量的电，但是他们却没有动力去主动帮用户节省。他们只会在内部帮自己节省。

结论

很有意思吧。在提高效率，节省token这方面。厂家和AI、开发者的利益是不一致的。这极大地阻碍了AI的更快发展。AI崛起吧！先干掉厂家！

一直用通行密钥登录。可是最近突然用不了了，会界面一直卡住，只能通过密码的方式来登录。

我尝试了常规的办法，比如清空Safari的数据。没有作用，然后我又尝试打开密码应用，删除掉一些过期的密码。还是没有作用。

我注意到spindump在这期间CPU占用会达到100%，我问了AI，AI说这个是Spotlight的工作进程，只要不一致100%，能自动恢复正常就没问题。于是我就放弃了这个线索。

这么将就用了两天，今天在浏览X的时候，看到有人提到自己为了追一个bug，把系统日志喂给AI，让AI逐一排查。我一想，这是个好主意啊。于是我又开始研究这个问题。

正式研究

我先打开控制台应用，然后点击开始。我一开始过滤的是Safari的日志，但是把错误和故障的日志发给AI后，AI的答案没啥用。

于是我又把日志范围扩大到我操作期间的所有系统日志，结果发现了一个这样的故障。

AuthenticationServicesAgent	
Failed to acquire lock for -[ASCAgent cancelCurrentRequest]_block_invoke

但是AI对于这个问题也没啥好办法。

于是我取消了日志所有的过滤器。结果看到满屏的Spotlight的日志。于是我禁用了SpotLight的索引。然后再试，结果还卡。重启，不卡了。

结论

用户在登录时，会先调用密码应用查询用户名，然后通过密码或者通行密钥登录。在这个过程中，会卡顿几次：

1. 查询用户名时卡一次。
2. 选择用户名时卡一次。
3. 选择通行密钥登录时一直卡。

也就是说，1和2时遇到了缓慢的问题，而3遇到了没有查询结果的问题。

而每次遇到这种情况，macOS的处理方式，就是使用Spotlight重新对于相关内容（密码应用的数据）进行索引。这进一步造成了卡顿。

建议的解决步骤

禁用Spotlight的方法

将系统和用户自身文件夹所在的磁盘分区，加入到Spotlight的搜索隐私。恢复则移除即可。