科技
低代码
less is more
在已实现的功能范围内，做东西的难度低于正常编程，而想加东西的难度高于正常编程
- “低”，还不是“零”，使用产品的运营、市场、营销甚至业外人士完全不懂技术，虽然是拖拉拽，但是无法理解拖拉拽背后的逻辑，导致上手难度很高，有这套工具且成功走向市场的公司，往往都需要储备一堆售前人工教甲方怎么用。
- “受固于UI”，更全面的理解应该是“受固于需求”，我们都知道甲方想要五彩斑斓的黑，大部分甲方是不懂准确描述需求的，这行内绝大多数的产品经理、需求分析师对需求的理解也时常有变差。这就导致一套低代码工具上线了，交付给业务方时（中间可能经历了1个Q,业务的KPI早就变了），业务方浅尝辄止，没有见效。
maybe 在一个特定的场景下，流程相对固定的场合，研发提供给公司内部的产品/运营/销售使用，研发要担当培训和更新维护的责任。
低代码目的应当是不生成优秀（技术层面的优秀）的软件 而是让更多的人能够参与到开发，实现及格线之上的功能。
wix/weebly/squarespace这样的拖拽建网站的网络服务早就赚的盆满钵满的了。但成功的核心是，它们是给没有能力的用户赋予有限的能力，从0上做加法。 但最近这波低代码，它们是想替代最低端的前端劳动力，从100上做减法，但只能减10这么一点点，而且省掉的时间，会因为代码质量等原因，在后期产品需求复杂一点点后，变本加厉的加回去。
——2025年3月20日12:18:56
MCP
❓ "MCP 不就是普通的 function call 换了个名字吗？"
核心质疑在于MCP是否仅是函数调用的语义包装，本质上缺乏创新。这一观点触及了协议设计与传统编程范式的深层差异，但其批判忽略了交互模式与抽象层级的关键分野。
函数调用本质是语言内同步、原子化的操作，其核心在于参数传递与栈帧管理，受限于语法结构与求值策略（如严格或惰性求值）。而协议（如MCP）定义的是跨实体的交互规则，强调异步性、状态维护与多步协商。例如，一个协议可能要求LLM先验证用户权限，再动态选择工具执行，最后整合结果，这一流程需通过多次消息交换实现，远超单次函数调用的范畴。这种差异类似于HTTP协议与单个API端点间的区别：前者规范通信框架，后者仅实现具体功能。
数学抽象（如范畴论中的态射组合）确实为协议设计提供理论支撑，但工程实践往往将其简化为状态机或事件驱动模型。MCP可能隐式应用这些概念，例如通过上下文管理实现副作用隔离，或通过消息路由模拟非严格求值中的延迟决策。然而，LLM当前的技术局限（如符号推理能力薄弱）导致此类设计常退化为硬编码流程，牺牲了理论上的灵活性以换取可靠性，这正是用户所指出的“过渡形态”特征。
在语言无关性层面，宏虽能突破语法限制，但其能力仍受宿主语言元编程机制的约束。MCP若定位于跨系统交互协议，则需通过接口标准化（如自然语言指令模板）而非语法操作来实现复用，这本质是另一种抽象路径——用语义协议替代语法宏。此外，LLM的交互天然依赖自然语言这一“超语法层”，使得协议可通过文本指令动态定义，但代价是依赖模型对模糊语义的解析能力。
当前MCP的妥协性显而易见：它既未完全拥抱数学形式化（如进程演算建模），又未充分利用LLM的上下文学习潜力，而是通过预定义协议约束交互空间，本质是降低决策复杂度的一种工程折衷。然而，这恰恰体现了其作为中间形态的必要性——在LLM尚未实现精确复用的阶段，协议通过规则化交互流程，为复杂任务提供可预测的协作框架。未来若LLM能直接生成并解释形式化协议，当前MCP或许会进化为更动态的“元协议”，但在此之前，它仍是连接自然语言指令与结构化操作的有效桥梁。
——2025年4月3日01:45:30