5.5 没有 codex 变种吧
烧的快正常，毕竟模型参数量接近 10T ，比 5.4 大了不少，成本高

建议下次不要用 imgur 图床，这玩意问题很大

copilot 的 nes 确实好用，有些非常小的修改开 agent 改还是太慢了（输入提示词的时间超过了自己打字的时间）。。。不知道有没有啥替代品

试试 warp
虽然看着像是 electron 但是是 rust 做的（）

@est 我说的是 https://isomorphic-git.org/ 这个

用 https://github.com/mksglu/context-mode 这种工具试试呢？

git 那个协议也没复杂到需要 wasm 来做啊。。。感觉就是有锤子找钉子的问题

@saranz 信用卡的监管就完全不一样了

@AV1 不就是因为集成到支付宝里才有竞争优势吗，这个新规一出支付宝就没这个机会了

@p4d9k “余利宝在支付宝使用网商银行支付时有时候能看到余额，有时候看不到”这不就是在明面违规吗，只是以前管得松，（和某些 iOS app 有时候能绕 iap 直接支付的行为如出一辙）
这个办法怎么看都是针对非银行支付机构搞的这些骚操作吧

@p4d9k 中国银联是银行卡清算组织，直接算银行了，这个《办法》管不到云闪付啊，云闪付甚至可以合规将贷款、资产管理产品列入选项（至少不是这个《办法》管的事）

@p4d9k 对啊，那网商银行有什么优势和其他银行竞争呢（）完全不能在支付宝里营销的话

@p4d9k 就算宽松解释，那支付宝的天也塌了（）新客户怎么办，直接用其他大银行的呗，还可以在多个支付产品里共享使用

@jacketma 有牌照不顶用啊，除非支付宝直接换壳改名为网商银行 lite 版（），因为《办法》里也禁了品牌混同，不能顶着支付宝的牌子干银行的事

对于余利宝，我觉得最有可能的结局是：支付宝完全切断任何主动提及余利宝的通道，也不能一键开通支付·还款功能，用户必须得去网商银行 app 里启用。
更严格一点的话，后台自动赎回这个机制可能也是涉嫌违规，估计会改成“仅扣银行账户余额，不足时支付失败”，但显然正常情况应该是 100%支付失败，然后让用户手动赎回后再支付（估计会提供一个跳转网商银行 app 的入口）

@p4d9k 但有一点是明确的：
非银行支付机构不得为资产管理产品提供营销服务，余利宝不能被支付宝主动提及了。

而且即使支付宝通过网商银行绕一圈，还是可以被严格解释打击到，比如可以这么解释：
用户付款时，虽然界面显示的是“网商银行储蓄卡”，但是实际扣款资金来源于余利宝。
只是系统通过后台自动赎回机制，而这已将理财产品完全融入到支付环节。
这种做法在实质上已接近“以支付工具为载体提供资管服务”。
如果监管按“实质重于形式”的原则进行穿透核查，这个模式还是存在被认定为违规的可能。
主要是结合此次新规来看，征求意见稿中的“在支付页面中”的限定词已被删除，监管重心明显转向业务实质，并明确禁止为资管产品提供营销支持。
因此，我觉得这个模式还是会受到重点关照的。
当然，与余额宝直接在收银台展示入口的做法相比，余利宝当前的交互设计“在形式上”仍保留了一定的合规弹性，就是不知道最后监管会怎么看了。

@mooyo 之前初稿还是在支付页面中禁止提供资管产品的营销服务（也就是不能显示任何第三方产品信息）
正式稿删除了“在支付页面中”的限定词，意味着限制从“页面展示”扩大到“任何形式的营销服务”
你打算怎么绕，不管怎么说新用户的获客成本肯定被提高了，那基本上也就相当于这个产品的增长空间变小很多了，老用户可能还能继续用。。。

@mooyo 现在就是这个流程啊，之前就禁止了“基金份额直接支付”和“T+0 垫资” ，支付宝通过网商银行中转完成了第一次合规改造
这次这个《办法》明显是针对这个方案做的补丁

@p4d9k 但支付宝本身还是非银行支付机构，除非 app 改成网商银行 app ，因为有品牌混同禁令，估计支付宝要集成到支付页面的话还是会存在合规风险，不知道这玩意怎么绕

@wu67 https://docs.github.com/en/copilot/concepts/usage-limits