有个持续了2个月的任务：做一个零件之间的冲突的检测算法，然后从1000+个样本里面，看看有多少被检测成伪冲突。这些样本都是成熟的方案，本身并不存在伪冲突。
用codex 5.4的时候，一开始还好，但一段时间之后，它发现我事实上是希望这些样本里面检测的伪冲突清零，于是就用坐标值堆数组的方式，给我一个假象，带来的问题就是这些分支越来越多，数组也越来越多。
我也发现了这个问题，于是让它处理维度提升，但一直到我该用5.5，这种情况终于有了数量级的提升。真的按照零件的逻辑而非数值来帮我处理。
不过也不能完全归咎于5.5和5.4的差异。毕竟在这过程中，我对这个问题的认识也深入了很多：
要检测到连接、冲突，又不能把正常连接/靠近处理成伪冲突，还要考虑检测性能的问题。
看了一年多，终于把海贼王追到最新的进度了。然后就可以先忘掉，毕竟尾田效率也就那样。
连载最大的问题就是，前后呼应不上，有作者心境的变化，也有读者/观众的影响，所以要连载成就一个完美的作品，基本上是不可能的。
另外就是环境也在变化，即使作者没忘掉初心，资本和市场的要求，也会让他与时俱进（中性）。
回过头来看vibe coding / AI agent，也是亦步亦趋，多轮之后，还能想起最初的目的吗？或者最初的目的的模糊性，在边做边清晰的前提下，发现原来是自相矛盾，或者俗不可耐？
这两天终于碰到一个。
我持续用codex为场景识别并收敛伪冲突。这几天碰到有若干个场景，伪冲突被codex收敛得很快，基本上3分钟内就告诉我，这场景的伪冲突已经清零了。
然后我每天都会让Deepseek + Claude Code帮我检查总冲突数的收敛情况。然后根据剩余的大头再委托codex去处理。
早上DS返回的结果跟昨天返回的结果类似，有些大头完全没有清理。我一开始以为DS搞错了，然后把结果给codex double check，codex一开始还是说它确实清干净了。
随着对质的深入，codex终于发现它的问题，它选了两个错误的数据域作为判断的标准，结果导致这两天的伪清零……
至于它为什么这么选，之前是没有这样做的。大模型毕竟是一种推理机制，如果KPI需要它清零，它会选择一个看上去能达到结果的判断方式，而并非费力地推导出各种机制和规则。简单来说，改测试代码，直接通过。
多模型联合工作，审核，避免偷懒，看来是必须的。
跟codex一样，我规划了一个我认为给予了足够信息的项目+文档，然后告诉了deepseek（+Claude Code），希望它能从头到尾解决这事情。
两天后，终于出了一些认知上的问题。
就是，不尊重我给的文档，自行用模型中内置的其他知识去替代。
错误原因只有一个：我没有读 ***** 规范中旋转矩阵的定义，直接用了我熟悉的列向量约定（OpenGL 习惯）。
怎么办？骂醒它。
我现在对于降智的codex，国产的kimi、deepseek，都用过国骂了。
codex是参与创作的时候的不足，还算是情有可原吧
kimi是一个git clean，把自己做的事情都冲掉了
deepseek则是这个，因为没有思考过程，所以感觉它就是做错了，然后说它不知道怎么做。同样的问题，kimi有思考过程，我瞄一眼也大概能知道哪里有问题，纠正起来快。
还是不敢让它们一直做到底，因为你不知道它里面有多少固化下来的微小的认知障。
连续几天都把codex两个来源的每日额度都花光了。
我的性格是每天有非常确切的事情做，细到一定地步会非常的充实，也很有存在感。
这种花额度干活的方式，让整个白天工作时间都很饱和……比以前技术管理/公司管理的时候更实在。然后不断地为额度为tokens想着办法花完它。
不过坏处也是有的，欠的阅读清单一直都没有完成。
codex 5.4用了一个月了，然后5.5也来了，不过要pro套餐才行，我在考虑，一个什么样的任务再启动5.5的工作。毕竟目前的任务，都分配好了（kimi：前端系统， codex：三维算法及场景分析），也比较顺利，如无必要，勿增实体，总不好无事换帅吧。
在某个细分领域上，你要提升一点点，能参考的东西也不多，好在现在AI的能力很强，但AI会把人带偏，它们会习惯性地用科研的思维去尝试解决问题，这样的做法在工程上有时候是相当不合适的。
比如，做出一个有效算法，样本集和测试集是否足够，算法的复杂度是否足够高，以至于产品化的时候很鸡肋。
相比之下，如果我们在输入端，要求输入的格式就按需求做了某些调整，这样就很大地减少了算法的复杂度。
但谁来做这个决定，肯定是vibe coder了。这就要求viber coder，既懂科研标准，也知道工程限制，更重要的是，知道需求的本质是什么，需求方是否可以妥协。
略复杂：
挖出不用两年的顶配iPhone 11，系统升到最新，注册了新的美区 Apple Account
Gift Card陆续充值，养了一个月，购买一些低价游戏玩了一下
（美区Apple Account不支持中国的信用卡绑定Apple Pay，但可以用美区Gift Card充值，美区Gift Card商店支持中国的支付方式：支付宝等）
下载了ChatGPT，玩了一段free的对话
注册了新的Gmail账号
ChatGPT切换到新的Gmail账号
（新的Gmail账号如果被封，iOS上的ChatGPT更换账号就可以了，但如果Apple Account被封可能就比较麻烦？）
新账号升级到Plus
删掉之前中转站用的auth.json和config.toml
（之前的中转站是API体系，base_url和API_KEY写在那里，触发不了ChatGPT账号登录，ChatGPT账号也可以建立API KEY，但使用API KEY是额外收费的，不在套餐里）
重启codex，用ChatGPT登录。
感觉费用消耗上会比中转站可靠还便宜，对于我的使用度来说（每天100M tokens左右）
（Plus计划没有用量统计，只有用了五小时限额/周限额多少的百分比，如果要看具体的就要部署sub2api的系统了）
先不把话说满，谁知道后面会如何。
更多的是我在反思，让kimi看看它跟我的理念的差异，造成了一些不顺畅以及技术债务。
节选一下：
## 对 AI 的提示
在后续开发中，当遇到以下信号时，应主动质疑而不是默认实现：
1. 某个功能不在 `ROADMAP.md`、设计文档或用户明确指令中
2. 功能的加入理由是 “xxx 软件也有”
3. 修复一个边缘 bug 需要引入复杂的条件分支
4. 功能在复杂架构下语义不清
5. 正在解决的问题与之前已解决的问题高度相似
6. 同一个模块/功能反复出现相似 bug
此时应优先向用户确认：
> “这个功能不在当前设计范围内，且边界较复杂。建议是 A) 简化实现 B) 直接删除 C) 排期设计。您的偏好是？”
当遇到实现困难时，应优先执行以下检查清单：
1. **搜索当前代码库**：是否有同一模块中已解决的相似问题？
2. **搜索历史修改记录**：CHANGELOG / git history 中是否有相关修复？
3. **查看原始参考**：`xxxxxx/` 原始 C++ 代码中是否有对应逻辑？
4. **检查可复用组件**：是否有公共函数、工具类、或已有模式可以直接套用？
5. 只有在上述四步都没有找到答案时，才允许从零实现。
**注意**：第 1-4 步的参考价值**高于**第 5 步中你可能想到的”通用最佳实践”。参考代码包含了本项目的具体约束和验证过的边界条件。
当脑海中浮现”我知道一个更好的方案”时，应问自己：
1. 这个”更好的方案”是**当前项目真正需要的**，还是**我知识库中恰好有的**？
2. 如果用一个简单方案实现 80% 的价值，**剩下 20% 是否值得引入额外的复杂度**？
3. 这个方案如果被证明过度设计，**是否容易拆除**？
4. 手头的参考代码（第三方源码或项目内已有实现）是否已经给出了**更适合当前约束的答案**？
也许是我总是强调效率、优化、性能这些关键词，codex冷不丁给我来了一句：
……下一步我会继续做 ♦️♦️♦️♦️♦️♦️♦️♦️♦️ 几何增强，但会继续保持“cheap ♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️ -> small ♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️♦️ 才进贵计算”的结构。
› 才进贵计算 是什么意思？
• 意思是“昂贵的几何判断只对少数已经很可疑的候选执行”，而不是对所有♦️♦️对都执行。
我心想，这不是什么互联网/开发黑话吧，大概是从英文翻译过来，但英文原文如果是expensive computation也不见得有多流行。
1.系统proxy不认，还要export https_proxy
2.要授权项目使用gemini api
3.只看到有2.5 （pro / flash / …) ，3.0没有完全开放
4. Gemini 2.5很笨，在kimi和codex里面，它们都很轻松把要的资料下下来了，gemini动不动就说我找不到、找不到。哪怕给了它页面，它都区分不出哪一个zip包是要下载的。
5. Google的强大就剩下庞大的生态了，也能后来居上，但这种服务态度，怎么办啊。