科技
transformer架构
Q K V
假如一个男生B，面对许多个潜在交往对象B1，B2，B3...，他想知道自己谁跟自己最匹配，应该把最多的注意力放在哪一个上。那么他需要这么做： 1、他要把自己的实际条件用某种方法表示出来，这就是Value； 2、他要定一个自己期望对象的标准，就是Query； 3、别人也有期望对象标准的，他要给出一个供别人参考的数据，当然不能直接用自己真实的条件，总要包装一下，这就是Key； 4、他用自己的标准去跟每一个人的Key比对一下（Q*K），当然也可以跟自己比对，然后用softmax求出权重，就知道自己的注意力应该放在谁身上了，有可能是自己哦 因为 A' = Softmax(Q · K) 得到的只是注意力权重矩阵，类似 0.5, 0.2, 0.1 ... ，对于整个任务来说，只有权重不够呀，还需要 input 本身的信息，所以要乘以 V，也就是经过一层变化后的 input。
——2025年11月5日20:43:03
ViT
基于transformer架构
传统方法CNN为归纳偏置所困
在设计时内置的一些先验假设或偏好，这些假设帮助模型更高效地学习图像等空间结构数据，CNN“天生认为”数据应该具备某些特性，如局部性和空间不变性
（1）局部性（Locality）
- 含义：空间上相邻的像素或区域是相关的，而距离较远的区域相关性弱。
- 实现方式：卷积核只在局部区域滑动，只处理一个小窗口内的信息，而不是整张图。
- 作用：大幅减少参数数量，提升计算效率，同时符合图像中物体由局部结构组成的现实。
（2）平移等变性/空间不变性（Translation Equivariance / Spatial Invariance）
- 含义：无论目标在图像中的位置如何移动，卷积核的响应都相同，即对输入的平移不敏感。
- 实现方式：权重共享（同一个卷积核在整张图上滑动，参数相同）。
- 作用：让模型能够识别物体，而不管它出现在图像的哪个位置。
ViT把图像切成一个个的补丁patch，16*16较好
patch展平后得到的向量---[embedding matrix (可学习的)]-->维度 D---[人为在首部添加一个特殊的可学习向量cls token]--->加入位置编码向量（也是可学习的）--->transformer--->输出（取决于具体的任务）
MCP
❓ "MCP 不就是普通的 function call 换了个名字吗？"
核心质疑在于MCP是否仅是函数调用的语义包装，本质上缺乏创新。这一观点触及了协议设计与传统编程范式的深层差异，但其批判忽略了交互模式与抽象层级的关键分野。
函数调用本质是语言内同步、原子化的操作，其核心在于参数传递与栈帧管理，受限于语法结构与求值策略（如严格或惰性求值）。而协议（如MCP）定义的是跨实体的交互规则，强调异步性、状态维护与多步协商。例如，一个协议可能要求LLM先验证用户权限，再动态选择工具执行，最后整合结果，这一流程需通过多次消息交换实现，远超单次函数调用的范畴。这种差异类似于HTTP协议与单个API端点间的区别：前者规范通信框架，后者仅实现具体功能。
数学抽象（如范畴论中的态射组合）确实为协议设计提供理论支撑，但工程实践往往将其简化为状态机或事件驱动模型。MCP可能隐式应用这些概念，例如通过上下文管理实现副作用隔离，或通过消息路由模拟非严格求值中的延迟决策。然而，LLM当前的技术局限（如符号推理能力薄弱）导致此类设计常退化为硬编码流程，牺牲了理论上的灵活性以换取可靠性，这正是用户所指出的“过渡形态”特征。
在语言无关性层面，宏虽能突破语法限制，但其能力仍受宿主语言元编程机制的约束。MCP若定位于跨系统交互协议，则需通过接口标准化（如自然语言指令模板）而非语法操作来实现复用，这本质是另一种抽象路径——用语义协议替代语法宏。此外，LLM的交互天然依赖自然语言这一“超语法层”，使得协议可通过文本指令动态定义，但代价是依赖模型对模糊语义的解析能力。
当前MCP的妥协性显而易见：它既未完全拥抱数学形式化（如进程演算建模），又未充分利用LLM的上下文学习潜力，而是通过预定义协议约束交互空间，本质是降低决策复杂度的一种工程折衷。然而，这恰恰体现了其作为中间形态的必要性——在LLM尚未实现精确复用的阶段，协议通过规则化交互流程，为复杂任务提供可预测的协作框架。未来若LLM能直接生成并解释形式化协议，当前MCP或许会进化为更动态的“元协议”，但在此之前，它仍是连接自然语言指令与结构化操作的有效桥梁。
——2025年4月3日01:45:30
低代码
less is more
在已实现的功能范围内，做东西的难度低于正常编程，而想加东西的难度高于正常编程
- “低”，还不是“零”，使用产品的运营、市场、营销甚至业外人士完全不懂技术，虽然是拖拉拽，但是无法理解拖拉拽背后的逻辑，导致上手难度很高，有这套工具且成功走向市场的公司，往往都需要储备一堆售前人工教甲方怎么用。
- “受固于UI”，更全面的理解应该是“受固于需求”，我们都知道甲方想要五彩斑斓的黑，大部分甲方是不懂准确描述需求的，这行内绝大多数的产品经理、需求分析师对需求的理解也时常有变差。这就导致一套低代码工具上线了，交付给业务方时（中间可能经历了1个Q,业务的KPI早就变了），业务方浅尝辄止，没有见效。
maybe 在一个特定的场景下，流程相对固定的场合，研发提供给公司内部的产品/运营/销售使用，研发要担当培训和更新维护的责任。
低代码目的应当是不生成优秀（技术层面的优秀）的软件
而是让更多的人能够参与到开发，实现及格线之上的功能。
wix/weebly/squarespace这样的拖拽建网站的网络服务早就赚的盆满钵满的了。但成功的核心是，它们是给没有能力的用户赋予有限的能力，从0上做加法。
但最近这波低代码，它们是想替代最低端的前端劳动力，从100上做减法，但只能减10这么一点点，而且省掉的时间，会因为代码质量等原因，在后期产品需求复杂一点点后，变本加厉的加回去。
——2025年3月20日12:18:56