关于AIGC人工智能、思维方式、知识拓展,能力提升等。投稿/合作: @inside1024_bot
AIGC 领域的最新工具、开源项目以及行业大事件
前两天在 X 上看到有人发了在 cursor 里利用代码补全来窥探 LLM 对不同族群的隐藏偏见,很有意思,就立即复现了并扩展了一下。下面是实验结果:
音频模型最好的 Eleven Labs 终于做了这个功能。

你现在可以在 Elevenreader app 里面将收藏的文档、链接、电子书转换为智能播客。

声音相当自然,支持 32 种语言。
纳米搜索这个 AI 搜索简直是创作者神器!

任何热点都能一键生成播客和视频快速分发。

搜索生成结果从文本拓展到了更多模态。

尤其是真人语音模型很自然。

下面是我用Lex的视频文稿生成的

这里尝试纳米搜索:http://n.cn/

播客生成:

App 中获取搜索结果后点击下方播放 UI 的分享按钮就可以下载生成的播客。

除了可以在声音市场(点击左上角头像→声音)选择既有的声音之外,还可自定义上传自己或家人的声音。

视频生成:

生成视频的时候只需要提供文档的链接就行,也可以从搜索结果提取。

然后 AI 会根据已有内容自动生成不同风格的口播稿和标题,当然你也可以自己再修改。

最后根据润色完的文本生成视频或者播客或者文档,他们甚至专门为不同的视频渠道做了适配,比如抖音和小红书的行文风格和标题就会不一样。

以 NotebookLM 为代表的 AI 交互新范式说了好久了,国内的跟进的是真的慢,反倒不管行不行都开始搞生成了。

但是今天发布的纳米搜索是我最近发现把这套融合的非常好的,甚至比 Perplexity 做的都很好。

他们把 AI 搜索完全做成了多模态的创作工具。

AI 时代以前的搜索引擎只能对文本进行处理,AI 时代的搜素引擎不再是内容检索工具而是内容生成工具和消费工具。

未来一个内容的消费场景会覆盖视频、图片、播客、数据图、PPT 甚至是不同的软件和交互布局。
对不起,要重新来炫耀下了。

这款100%由Cursor AI写代码的app,现在已经不是分类榜,而是总付费榜的第一了。
树穿衣服
机器人不怕冷
我吃臭豆腐🤒
大家都在用什么可以根据需求和素材生成图片和海报的ai应用 最好轻量 免费 求大神带带🥹
和生财有术航海家沟通下来,发现目前 AI 领域有四大流派:

主流叙事 To VC派+ 传统工具出海派+ 新型套壳个体户派+商学院私董会派

亦仁说,存在着两种“看不见”:
传统做 App 的团队看不见ai网站的机会,因为网站没有 data.ai 和 sensortower 这种榜单;但凭借 AI 概念加持,很多半死不活的 App 工具厂商迎来第二春。

站长派,做 AI 网站的人,大多数是草根,看不见 App 的机会(开发成本也偏高) ,擅长 SEO 和蹭热点,或者去找达人/私域推广,甚至玩坏了 product hunt。

两种领域,都有人在赚钱,但互相融合的不多。

但,中国 90% 以上流量在 App 里(比如微信搜索 小红书搜索 和抖音搜索的体量,已经不亚于百度)

但在国外,web/PC 端的流量,还是和移动 App 端等量齐观的。尤其在北美等 Tier1 区域。
AI探索指南
聊几点我对 Anthropic MCP 的看法: 1. 并没有像自媒体鼓吹的那样夸张,还不至于让 AI 行业变天,依然有很长的路要走; 2. 可以简单理解跟大模型已经支持的 Function Calling 是同一个东西,本质是为了让大模型可以调用外挂的服务,对接更多的数据和能力,再作为补充上下文回答用户的问题; 3. 区别点在于:Function Calling 由大模型通过 HTTP 请求第三方的外挂 API,而 MCP 是由大模型通过 RPC 请求第三方的外挂服务; 4. 从接入方式上看,Function…
7. OpenAI 最初开放的 API 协议已经成了一个约定俗成的标准,后来的大模型在开放自家 API 时都会选择兼容 OpenAI 的 API,主要原因有两个:一是 OpenAI 的 API 开放的早,很多应用接入了,兼容它对第三方接入友好;二是 OpenAI 的 API 实现的确实很规范,照着模范生抄作业何乐不为。MCP 会不会也跟 OpenAI 的 API 协议一样,成为行业内的新标准,这个问题取决于先有鸡还是先有蛋:如果有足够多的第三方服务基于这套协议开放了自己的服务,其他大模型/应用客户端应该会跟进;如果主流的大模型/应用客户端都支持了这套协议,那么作为一个第三方,也肯定愿意按这套协议开放自己的服务(比起为 GPTs / Coze / Dify 分别写一个 API 给智能体调用,MCP 服务只需要写一次,可以在任意支持 MCP 的客户端调用)。

8. MCP 目前不支持 Remote Server,不能在网页版调用,只能在 Claude 桌面版使用。我写了一个用 Claude 客户端分析群聊记录的程序,结合实例来看 MCP 的应用,很好理解。MCP 的想象空间还是很大的,未来可期。

个人经验之谈,有表达不当之处,欢迎补充讨论。🌚
聊几点我对 Anthropic MCP 的看法:

1. 并没有像自媒体鼓吹的那样夸张,还不至于让 AI 行业变天,依然有很长的路要走;

2. 可以简单理解跟大模型已经支持的 Function Calling 是同一个东西,本质是为了让大模型可以调用外挂的服务,对接更多的数据和能力,再作为补充上下文回答用户的问题;

3. 区别点在于:Function Calling 由大模型通过 HTTP 请求第三方的外挂 API,而 MCP 是由大模型通过 RPC 请求第三方的外挂服务;

4. 从接入方式上看,Function Calling 更简单,第三方只需要写一个 API,再在大模型配置对 API 的请求参数即可。MCP 接入起来要复杂一些,第三方需要写个服务,实现协议里定义的 RPC 方法,再在大模型里面配置服务地址和参数,大模型客户端在启动的时候需要做一次服务发现,再连接到配置的 RPC 服务,才能在后续对话过程调用;

5. Function Calling 和 MCP 的核心和难点都在于大模型侧的意图识别,用户随机提问,如何找到匹配的外挂服务,实现 RAG,这是所有大模型面临的通用难题(比如 ChatGPT 有几百万的 GPTs 应用,如何根据用户提问路由到最匹配的那个 GPTs 来回答问题),MCP 协议并不能解决这个问题。Claude 客户端目前的实现方式,是让用户自己写个配置文件,告诉大模型有哪些可以调用的服务,再由 Claude 在对话时自动识别,跟 ChatGPT 之前让用户选择使用哪些 Plugins 的逻辑一致;

6. MCP 的亮点是定义了一套标准且相对完善的协议,对于大模型和应用的生态协同有很大的指导意义。类似由微软提出并在 VS Code 实现的 LSP 协议一样(定义了编辑器如何与第三方语言服务交互,实现代码补全/类型约束/错误提示等功能)。MCP 协议的适用对象主要是大模型/应用客户端和第三方服务,跟 LSP 不同的是,编程语言的数量相对有限,最多几百个语言服务,社区协同下很快就能全部支持,编辑器可以根据文件的后缀快速定位到要调用的语言服务。MCP 适用的第三方服务是海量的,MCP 的发展取决于有多少第三方服务愿意基于这套协议去实现 RPC 服务,最关键的还是大模型/应用客户端对海量 MCP 服务的路由寻址问题(没有固定的后缀,只能靠意图识别或者人工配置)。
Back to Top