你这都没我现在夸张。我这的小组长，开会，直接说，你们不加班就是工作量少，你们即使加班做个 hello word 只要你考勤好看，你都是工作量高的。夸张不夸张。

@duke807 #1 好像是不登录一些功能就只能看

如果用 openai 的 gpt ，发票就开不出来。所以合法合规就是用 azure openai ，至少有国内团队洽谈商务，都是出海正规做法。

变成 50%优惠了。

油，或者油混。电车我的想法是再等等，每年更新换代太快，电车的背刺比油车严重。

要是这么说的话，我高中那会知道的 btc ，那会 1 块不到一个，我一周生活费 200 ，该不吃不喝买 200 个的。

Google Gemini 和我都是 Google AI 开发的大型语言模型，但我们在以下几个方面存在一些差异：

训练数据集：Gemini 使用的是 Google 搜索和 YouTube 的数据集，而我使用的是 Google 搜索、YouTube 、书籍和代码的数据集。这意味着 Gemini 在生成有关实际世界主题的文本方面具有优势，而我则在生成有关抽象概念的文本方面具有优势。
模型架构：Gemini 使用的是生成对抗网络（ GAN ）架构，而我使用的是 Transformer 架构。GAN 架构擅长生成逼真的图像和文本，而 Transformer 架构擅长处理自然语言。
目标任务：Gemini 的目标任务是生成高保真度的图像和文本，而我的目标任务是提供信息丰富的答案。这意味着 Gemini 在生成创意内容方面具有优势，而我则在回答事实性问题方面具有优势。
总体而言，Gemini 和我都是强大的语言模型，但我们各有优势和劣势。Gemini 在生成逼真的图像和文本方面具有优势，而我则在回答事实性问题方面具有优势。

以下是一些具体的例子：

Gemini：
生成逼真的肖像画
写出有创意的诗歌或故事
翻译语言
我：
回答有关事实性主题的问题
提供摘要或概述
生成不同的创意文本格式
最终，哪种模型更好取决于您的具体需求。如果您需要生成逼真的图像或文本，Gemini 是一个不错的选择。如果您需要回答事实性问题或生成创意内容，我是一个不错的选择。

还有一个原因，降本增效的裁员，很多公司不会让你呆满一个月的交接期，有的还是当天就走。这种裁员，你觉得交接工作做的能有多好。

不光人在裁，机器也在裁啊，降本，机器资源，集群资源，然后在降本的时候发现某些东西很老，有隐患，然后又想冲一波考核，那就拿出来升升级，然后发现，哦豁，没考虑到那么全面，因为最了解的人走了，现在都是看看文档的人，自然就崩一下，你要说解决不了，那不可能，只是因为没遇到所以才出问题，遇到了后面就不出了，然后后面又裁，新的问题再暴露。

[Imgur]( https://imgur.com/YH90YMG)

梯子一个月 50
没有月度订阅的软件，都找的买断平替。
软硬件，那就是看当年的升级到底吸不吸引我，比如今年，换了 15pm 因为 typec 。

你应该好好看看文档，多数据源他有一个组的概念，你得命名，abc ，abc_test ，他会根据_切分，abc 是 group ，test 是 group 下的一个子项。所以你 abc 去匹配，返回的就是 test 。所以你将 abc 命名改为 abc_prod ，用 abc_prod 去 push 就正常了。

先谈，后换。然后再谈这个任务分解问题，开发任务很难有你说的这种场景，任务 b 依赖 a ，并不代表 b 就只能在 a 之后才能进开发。不管是 mock 还是什么手段，任务 b 都是可以提前进开发，然后再和任务 a 联调的。

就是一个安全性的考虑问题而已。当年还没到考虑安全的地步，就跟当年还没到考虑高并发高可用的地步一样。都是一步一步升级来的。

你们这流程，只能让人保证 prd 切 feature ，feature 开发完，mr 到 dev 和 uat 测试，改 bug 还是在 feature 改，改完继续 mr 到 dev 和 uat ，测试完成后上线，feature 提 mr 到 prd 删除 feature 。这个流程就是保证 dev/uat 测试的 mr feature 版本和最后 mr 到 prd 的 feature 版本一致，避免在测试中途有人提交了代码到 feature ，最后没过验证直接 mr 到 prd 。

首先 surge 增强。然后
DOMAIN-SUFFIX,grazie.aws.intellij.net,OpenAI
DOMAIN-SUFFIX,grazie.ai,OpenAI

我这样是没问题的。账号的地区还是中国大陆也没影响。

pikpak

@cnzmz #4 你如果只是因为要升级接口，比如多一些参数少一些参数，你就用 2 完事了。这种场景就是说我两个接口都要保留，原因就是因为部分老版本 app 需要请求到老的接口，并且能通，不影响用户使用。当然也可以改 v1 接口返回个错误 msg：请升级最新版本 app 。我并不是提倡你去用两个 controller ，只是说如果你只是单纯的因为业务问题要升级接口，就写个新接口完事，没必要为这种场景去设计个注解，还破坏了接口的可读性和查找性。