
获得徽章 0
赞了这篇文章
我十分想吐槽现在的的AI相关内容的技术自媒体,把我不懂技术领导忽悠得一愣一愣的,一个MCP协议也能吹到天上去,我说用function call已经足够用了,硬要说没有用上MCP不是他想要的,直接丢一大堆MCP的自媒体文章给我(估计就是不懂function call的逻辑)。
首先function call可以直接在你的项目代码里面调用你写的函数,并且可以在同一个项目内直接维护代码逻辑,不用另外部署一个命令行或者MCP服务,更加可控一点,特别是针对toB+B端产品而言。
MCP我认为更偏向C端+toC的场景,他调用互联网或者自己C端设备部署的服务来调用工具,我认为是合理的。
现在的开源的MCP服务都是启动一个服务器暴露接口给我们调用或者安装一个命令行让我们去运行命令行,如果接入的外部开源的MCP服务很多的话在部署的时候可能会需要部署一大堆MCP服务,增加部署的心智负担,而且还要担心开源的MCP是否完全覆盖自己的需求,如果没有完全覆盖还得把代码拉过来改一改部署。如果是自己开发的或许会可控一点,但是其实和function call的逻辑差不多,我并不想原本直接调用函数就能解决的事情还要兜个圈子走一遍MCP服务再去返回,简直是多此一举。
叠个甲:没有完全吃透MCP协议,不知道他是否也支持function call的模式,只是针对我目前领导让我用的开源MCP都是启动一个HTTP服务的方式吐个槽。
首先function call可以直接在你的项目代码里面调用你写的函数,并且可以在同一个项目内直接维护代码逻辑,不用另外部署一个命令行或者MCP服务,更加可控一点,特别是针对toB+B端产品而言。
MCP我认为更偏向C端+toC的场景,他调用互联网或者自己C端设备部署的服务来调用工具,我认为是合理的。
现在的开源的MCP服务都是启动一个服务器暴露接口给我们调用或者安装一个命令行让我们去运行命令行,如果接入的外部开源的MCP服务很多的话在部署的时候可能会需要部署一大堆MCP服务,增加部署的心智负担,而且还要担心开源的MCP是否完全覆盖自己的需求,如果没有完全覆盖还得把代码拉过来改一改部署。如果是自己开发的或许会可控一点,但是其实和function call的逻辑差不多,我并不想原本直接调用函数就能解决的事情还要兜个圈子走一遍MCP服务再去返回,简直是多此一举。
叠个甲:没有完全吃透MCP协议,不知道他是否也支持function call的模式,只是针对我目前领导让我用的开源MCP都是启动一个HTTP服务的方式吐个槽。
展开
评论
点赞
赞了这篇文章
去年有了写前端低代码工具的想法写了初版代码,后来因为下班回去要带小孩没什么时间开发搁置了,这段时间重新准备拿起来用,随着基底大模型的不断进化,我发现已经完全被类似Cursor、Trae这类AI IDE替代了。
然后就思考前端低代码是否是一个伪需求。我的答案是:是的。我的思考是:代码本身就是一种程序员的低代码,我每次在使用我的低代码工具的时候总是先冒出来的是前端的代码逻辑,然后才上手通过拖拉拽的方式去操作,并且最终生成的还是半成品(我使用的是JSON保存我的低代码配置),还需要我非常麻烦的去一个个配置。
但是AI可以直接产出最终产物而且只需要用户提一个需求即可,完完全全是碾压低代码工具的存在。如果我面向的是程序员群体,那程序员更偏向于代码逻辑,本身对这类东西就有一定的排斥,很难成为目标用户。
如果我面向的是没有任何编程经验的小白或者画原型的产品经理,他们更偏向于提需求让AI给参考后使用自己熟悉的原型工具去设计,或者可能直接拿着AI生成的原型就出去吹牛逼了(现在很多toB的软件公司的售前甚至中层领导都是这么干的)。
感慨一下:每次AI的进化都让一大堆原本看起来像创新的东西一下子拍死在沙滩上了。
然后就思考前端低代码是否是一个伪需求。我的答案是:是的。我的思考是:代码本身就是一种程序员的低代码,我每次在使用我的低代码工具的时候总是先冒出来的是前端的代码逻辑,然后才上手通过拖拉拽的方式去操作,并且最终生成的还是半成品(我使用的是JSON保存我的低代码配置),还需要我非常麻烦的去一个个配置。
但是AI可以直接产出最终产物而且只需要用户提一个需求即可,完完全全是碾压低代码工具的存在。如果我面向的是程序员群体,那程序员更偏向于代码逻辑,本身对这类东西就有一定的排斥,很难成为目标用户。
如果我面向的是没有任何编程经验的小白或者画原型的产品经理,他们更偏向于提需求让AI给参考后使用自己熟悉的原型工具去设计,或者可能直接拿着AI生成的原型就出去吹牛逼了(现在很多toB的软件公司的售前甚至中层领导都是这么干的)。
感慨一下:每次AI的进化都让一大堆原本看起来像创新的东西一下子拍死在沙滩上了。
展开
2
1