sentinelK

@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 变化是人机工效逻辑（用于提示使用者的），事件防抖是业务逻辑（用来防止逻辑错误的）。