@cenbiq 这个其实是另外一个问题，既统计学解是不是真理。我的答案是：不是真理，但有很大价值。

@craftsmanship 国产 AI 也是一样，deepseek 的发言要远比任何国内媒体都要更透彻且直接。相比而言，抖音上面的内容一度我认为不是中文。

百度会把骗子放在置顶，但 deepseek 不会让你去莆田系割包皮。

大语言模型是一种真正意义上的信息平权。
它提供的是信息的绝对统计学解。而且因为其数据的数量级过大，导致人类很难出于利益、政治等考量对输出进行有效干预。

在此之前，任何的文字信息，都是通过人类制定的规则与组织筛选呈现的。
报纸有报社，书有出版社，广播、电视有广电总局，教育有教育局，搜索引擎有搜索引擎公司和排序算法。

只有大语言模型，能够给出人类语料真正的统计学结果。

所以在我看来，这一波机器学习为底层的统计学 AI 的兴盛，除了算力的爆发、算法的突破造成的共振以外，其因为其高成本、大数据量导致的无法低成本干预，从而绕过了绝大多数的既得利益者的防御措施，也是其真正能够打破社会体系，真正释放给普通民众使用的根本原因之一。

@Kirkcong 一样有这个问题，如果 cherry Studio 决断用 opus 给你分析文档，一个文档分析用掉你几十美金，你会同意吗？

这还不是最恶心的。你花几十美金分析了一个文档，最后出图的时候文生图模型跑飞了。这个损失怎么算？算文生图模型的问题，还是文档分析模型的问题？还是模型调度机制的问题？

再加上你跑一半，你的某个 API token 余额透支了呢？等等这种完全不可控因素非常大。Cherry Studio 这种产品只是一个可视化 API 调度器，他不提供收费服务，自然也没有权利和义务决断你的消费选择，更不会对结果负责。


所以只有以 Request 作为收费单位（而不是 token ），才有可能合理的智能分配模型能力（比如各家的 AI Coding ，都有 Agent 模式）。

但话说回来，这种以 Request 作为收费单位的产品，其“模型选择”其实就是一个黑盒了。即便你选的是“某某模型”，其实也只是选择的收费标准。实际上跑的是不是那个模型，你的提示词被如何加工，对你都是未知的。

这是因为模型的选用，和用户的利益成直接正相关关系。而且和结果不成线性正比。

举个简单粗暴的例子，免费模型和 opus 都可以告诉你 1+1=2 。但是 9.1 和 9.9 哪个大呢？

任何其他人、组织，都不可能客观评判你的问题哪个模型性价比最优。更别提这其中还有利益问题。

很多问题是这样的，你不着手，其实你是不知道这个产品/技术/设定的真正的用途或者说逻辑在哪里。所以我的经验是，但凡想上手一个东西，先低成本的尝试一下，哪怕不像投入沉没成本，也要是至少要去了解一下全流程。不要去思考值不值得，以及应不应该的问题。

只有真正上手了之后，才能 get 到“它”的实际用途，和给你的观感，然后再聊能否创造价值或者是否有用的问题。

而且即便你了解上手之后，没有发现真正的用途，或者发现用途和自己的预期不一致。也并不意味着你整个体验的过程是浪费的。因为知识是网状结构的。所有信息不光服务于垂直领域，也会增进你对其他领域的认知和逻辑思路。

要珍惜自己的好奇心。

从演进的流程上来讲，确实是这样。一开始的 AI Coding 主要体现在 Tab 提示，然后逐渐演进到 Chat ，然后再演进到 Agent 。
总体上来讲，一定是人的干预越来越远离实现本身。

但讨论这个没什么意义。

首先，因为提出需求的是人，这就导致人必须参与输入。你不输入你的需求无从表达。
其次，相同的需求，表达方式多种多样，总会有人掌握更优秀表达需求的能力。
最后，你要明白为何目前的统计学 AI 的解决方式是 Agent 。因为是基于目前的上下文能力，以及模型向量转换次数所限。最终的终局，AI 产出一定不是 Agent 的。

你看现在还有人讨论“提示词工程”么？还有人因为写提示词更好引以为傲么？

在我看来，Agent 就像是提示词工程一样，只是基于有限能力下的临时性解决方案。仅此而已。

微服务是一种理念。不是一个技术选型或技术选型组合。

nacos 只是阿里给微服务做的一个平台工具而已。你可以用，也可以不用。楼上举出了很多替代方案和其他的实现方式。

这个变量很多。除非控制变量，否则很难横向对比。

所以哪个用的最顺手，用哪个就好。

不了解微信，但是每个不同的渠道，是有可能不是同一个软件的（也就是包名不同）。
这个和国内的应用市场的强势程度有关。

游戏行业比较常见，部分游戏在某品牌手机就是单独的服务器（所谓渠道服）。

@swulling 同楼上，UI 处理和事件处理其实是完全不相干的两个事儿。要分别对待。

@AV1 "绝大部分在 onclick 事件上用防抖，是错误的。
防抖是给 oninput 、onmousemove 、onresize 这类高频事件用的。"

没懂，onclick 事件和以上的几个事件有什么区别？
只要是事件就有可能有防抖的业务需求，是否防抖跟是什么事件无关。防抖也不光指处理程序内部的逻辑噪声。

对应的，还有个处理方式叫“节流”。

另外，UI 上的反馈处理和事件上的防抖也并不冲突。UI 变化是人机工效逻辑（用于提示使用者的），事件防抖是业务逻辑（用来防止逻辑错误的）。

一个视频，100 个切片。你请求到哪个切片了，你的进度就是%多少。

这个问题有多个维度。

视频解码位置：
如果是 7.2.1 之前的系统版本，群晖可以直接通过 web 播放，群晖也有 video station 。也支持压缩和画质选项。
如果是 7.2.2 及以后的版本，就只能使用客户端硬解了。所以就需要全码率传输。

网络环境：
决定“速度”的，很大程度上也要看你的群晖是否能和客户端设备 p2p 直连。以及你家的上传带宽。如果不能直连，群晖中转（也就是那个 QuickConnect ）效率很差。

所以你得先弄明白你体验不好的瓶颈是在哪。

这就是 chat 机器人的最大弊病。最终输出的统计学取向，是由监督者，既有语料共同决定的，也就带有人类本身的主观好恶。

所以那些打破行业常规，颠覆行业规则的 AI 模型，都是强化学习比例高,量化充分，客观度强，且半监督，甚至无监督占主导的领域。

AI 时代垂直协作肯定会变弱，更多的岗位从横向转换为纵向（从 UI 到数据持久化统一一个人负责）。
所以过去的分层理念必然不会是最有效率的。
btw：其实很多架构与分工，都是基于组织结构与人力的能力限制，做的效率妥协。也就是所谓的“康威定律”。

但反之，你的程序逻辑越下潜，代码的通用性也会越弱。

所以要根据需求来讨论架构。

btw:由此就引申出一个问题。目前多数新的 web 应用都上框架，是因为管理职能的需要。
使用框架并不是 web 开发的必要条件。

所以不要啥事儿都往 React 、Vue 、Angular 身上遮。

很多人只嘲讽，不讲逻辑。我尝试讲讲看。

首先，从原教旨主义上讲，事件的触发默认逻辑就是多线程的。既触发几次事件，响应的方法就应该执行几次。所以至少不能默认“防抖”。

其次，“防抖按钮组件”是存在的。只是不是 React 提供的而已。

然后，“防抖按钮”在目前的互联网逻辑下用的多么？多。因为当今远程访问多了，延时大了，不防抖很容易和用户意愿相悖。

最后，React 应该给机制来解决么？不应该。因为 React 解决的，是也仅是“前端的职能管理与分工”问题。不解决业务与 UI 问题。

所以，不是 React 应该包含，而是你应该使用一个带 loading 按钮的 UI 组件库。

回答完毕。

不是不支持，是设计思路不同。
Cursor 和 Copilot 这种代码补全用的都是超低成本的小模型，走的也是让你“方便录入”这个产品设计思路。
生成的代码逻辑可靠性低，本文件的耦合程度高。

这和目前的代码生成乃至 Agent 是完全不同的技术路线与功能出发点。