@julyclyde rsc 大部分用户的交互结果都要在服务端渲染，再发回客户端渲染出 dom ，性能成本提高也就十几倍吧。另外因为交互要发回服务端渲染，更高的延迟也都是非常合理了

我一直不能理解为什么要用 rsc ，为了解决服务器性能过剩，以及服务器成本过低的问题吗

你也没指定不思考啊，gemeni3 默认思考级别是高，这不是得先思考再给你回答吗

@theOneMe 量化的总产出不变的情况下，个体产出提升 50%，只要裁掉三分之一的人力即可，没有 50%那么夸张的

cursor 的计费规则有几次变更的。
最早的是固定次数；然后今年 6 月改为自选模型按量计费，但是有无限 auto ；现在又改成没有无限 audo ，全面按量计费，auto 也按用量算钱
在计费策略变更前就开始订阅的，一般是保持原策略不变，但是据说 cursor 会定期抽取一些幸运用户改掉计费策略

接力接力 g.co/g1referral/V8B6S8G4

这种问题对知道的人来说根本就不是问题，你来问说明你搞不定，是个小白。小白自然就会得到给小白定制的正确答案，加个路由器问题自然就解决了

1. TPS 低于 100 的模型不配上桌，总不能跑个任务还要出去散个步吧？
2. 3.2 降本但没有增效，绝对能力没有提升反而有下降。

v3 都一年了，当时和一线模型基本没有代差，但是现在一线模型都更新了一到两个版本了，deepseek 一直都在在 v3 的底子上优化，进步实在有限

可以看一下 MCP 的具体介绍和实现规范，除了 tools 以外，还有 resources 和 prompts 的，这也是为什么叫做 MCP 而不是 Tool 什么的原因。只是 mcp server 实现这些东西的比较少见而已

https://modelcontextprotocol.io/docs/learn/server-concepts

这个 80%应该是来自于 w3techs 的数据吧，最新的值已经是 73%。
而且它的这个统计其实不是很合理，所有的子域名都视为同一站点。另外所有域名站点的权重一致（我有两个域名站点，比 google.com 强多了），导致 CMS 成为了统计数据中的绝对大头。
另外，现在现代的技术框架下，绝大部分服务端对外都没有明显的语言特征，不像 PHP 那么容易识别。
PHP 事实上已经死掉了，只是还没埋而已

能做到监听并且不被发现，一定得是手机厂商吧？你是说伟大的苹果监听你们的对话，然后把数据卖给了字节？

你这个几乎是零分回答了。整体的处理流程其实都差不多了，只是根据你的角色不同，在不同的阶段措施有差异而已，基本就是自己执行或者上报推动其他人执行的区别。
首先肯定是确定问题现象，恶性程度，影响范围。然后初步分析大致原因，解决难度，能否回滚，并结合之前的问题信息，来选择修复/回滚/不修复。如果问题较为严重，但是选择修复的话，视情况让另一拨人同时评估回滚影响，随时准备回滚。

我的服务器日均 2.1 度电，一年大概在 500 块电费。但是性能高啊，同配置的在阿里云要 3000 多每月

既然我们公司的打印机可以直接打印双面的文件，为什么不直接打印钞票呢？

llm 不是计算器，这个是正常现象

这就是传说中的恶魔低语吗

稳定的只有营收，盈利短期内就别想了。
现在大家还处于跑马圈地的环节，而第一梯队模型的推理成本不小，这块的成本就非常高昂。并且模型能力还没有达到预期，相互之间也没有足够大的代差，大家还得咬着牙继续投资去训练新的模型

绝大部分自以为是的扩展，最后根本用不上。其中大概一半多增加了不必要的复杂度，对相关开发造成困扰。一小部分会对后续的基于真实需求的扩展造成非常大的阻碍

设计时预留实现扩展的可能性，不要堵死扩展的路就好。
千万不要真的实现扩展，除非你真的知道这里短时间内需要扩展以及扩展的明确方向。