宝玉
2周前
微软牵手OpenAI对手Anthropic,AI智能助手再升级 微软公司宣布,将开始采用Anthropic公司的人工智能模型,进一步强化其职场AI助手Copilot。这次合作意义重大,因为此前微软的AI工具几乎全部由OpenAI提供支持。 从本周三开始,使用微软Copilot的企业用户,在进行数字研究辅助和构建定制AI工具时,可以自由选择使用来自OpenAI或Anthropic的模型。 微软过去几年在职场AI工具的商业化领域遥遥领先,这很大程度上要归功于与OpenAI的合作。OpenAI是热门AI产品ChatGPT的开发公司,微软曾以巨额投资和数据中心资源换取了将OpenAI技术整合进自家产品的权利。目前,微软旗下Copilot系列工具,包括代码编写助手、个人助理以及微软365办公聊天机器人,都由OpenAI的模型提供支撑。 Anthropic是由前OpenAI员工创立的公司,如今已经发展成为OpenAI最主要的竞争对手之一,在AI领域举足轻重。与此同时,微软正重新调整与OpenAI之间的合作条款,并积极开发更强大的自研AI模型。 自ChatGPT三年前问世以来,AI模型呈现出井喷式增长,各大公司也积极试验AI工具的应用场景。微软等云计算巨头一直致力于为客户提供多种AI模型服务,认为用户需要在不同的AI服务间灵活切换。 Anthropic旗下的 Claude Opus 4.1 模型,擅长复杂的逻辑推理任务,将被整合进微软365 Copilot中的“研究助手(Researcher)”功能。此外,Copilot Studio(微软的AI智能体创建工具)用户除了能够使用Claude Opus外,还能使用另一款较轻量级的模型——Claude Sonnet 4。当然,用户仍然可以继续使用OpenAI的模型。 微软业务与行业Copilot部门总裁查尔斯·拉曼纳(Charles Lamanna)在一篇博文中表示,这次合作彰显了微软“致力于将整个行业最顶尖的AI创新技术带到微软365 Copilot中”的决心。
宝玉
2周前
注:本文由 Gemini 根据 YouTube 视频生成,提示词和原始绘画链接见评论 搜索引擎的新纪元:如何在LLM时代赢得“答案引擎优化”之战 在数字信息的洪流中,我们获取知识和寻找产品的方式正经历一场深刻的变革。 曾几何时,“谷歌一下”是解决所有疑问的终极法则,蓝色链接的排名决定了信息曝光的命运。然而,随着大语言模型(LLM)的崛起,尤其是ChatGPT、Claude、Gemini等“答案引擎”的普及,一个全新的战场——答案引擎优化 (AEO)——已经悄然形成。这不仅仅是搜索引擎优化 (SEO) 的演进,更是一场对内容生产、分发逻辑乃至商业增长策略的颠覆性重塑。 从“搜索”到“答案”:范式转移的必然 长久以来,我们习惯于在搜索引擎中输入关键词,然后筛选一长串蓝色链接以找到所需。彼时,谁的链接排在首位,谁就赢得了一切。但如今,当我们在ChatGPT中提问“最好的网站构建工具是什么?”时,我们得到的是一个综合性的摘要答案,其中融合了多个来源的信息,而非单一链接的霸权 [11:09]。 这揭示了AEO与传统SEO的根本区别:传统SEO追求“单一最佳结果”,而AEO则注重“多重引用提及”。LLM并非简单地展示某个页面的链接,而是综合多个“引用来源”(citations)来生成一个凝练的答案 [11:14]。这意味着,你的产品或内容被引用提及的次数越多,其在答案中脱颖而出的机会就越大。这对于早期创业公司而言,无疑打开了一扇前所未有的快速增长之门,因为相比于建立长期的“域名权威 (domain authority)” [12:09],获得一次有效的引用提及可能就在朝夕之间。 更令人振奋的是,来自LLM的流量不仅数量可观,质量也远超传统搜索。有数据显示,LLM流量的转化率可能比Google搜索流量高出六倍 [14:45],这归因于用户在与LLM的对话中,其意图被反复澄清、需求被精准聚焦,导致点击行为更具目的性。 解构AEO致胜的“双翼”:站内深度与站外广度 要在这场答案引擎的竞赛中脱颖而出,我们需要一套更为精妙的策略,它像鸟儿的双翼,既要注重自身的内在修炼(站内优化),也要拓展外部的连接网络(站外引用)。 1. 深度回答:挖掘“长尾”问题的金矿 在传统SEO中,我们追求热门的“头部品类关键词”。但在LLM语境下,“长尾问题 (longtail questions)”的价值被前所未有地放大。LLM鼓励用户进行多轮对话和深入追问,这意味着用户会提出大量高度具体、前所未有的问题 [13:40]。这些问题往往无法在传统搜索中得到有效响应,但在答案引擎中,它们是等待被发掘的蓝海。 因此,你的网站内容,尤其是产品页面和帮助中心 (help center),需要超越简单的功能介绍,深入回答用户可能提出的每一个细枝末节的问题 [15:56]。例如,如果你的产品是一款AI支付处理API,你需要创建内容详细解释它如何与特定数据分析工具集成、支持哪些语言、有哪些具体使用场景等。这种对长尾问题的全面覆盖,不仅能提高你在LLM答案中被引用的概率,也能显著提升用户体验。 2. 广度引用:构建多维度的信任网络 LLM在生成答案时,会综合来自各种渠道的信息。因此,仅仅依靠自己网站的内容是远远不够的。你需要积极拓展“引用策略”,确保你的产品在以下关键渠道中被广泛且高质量地提及: • 垂直媒体与测评网站: 对于B2B产品,Tech Radar等行业媒体是重要引用来源;对于消费品,Glamour、Cosmopolitan等时尚生活媒体影响力巨大 [38:57]。 • 视频平台: YouTube和Vimeo等视频内容,尤其是针对特定、甚至小众的B2B使用场景的教学或评测视频 [30:49],能够有效增加引用。 • 用户生成内容 (UGC) 社区: Reddit和Quora等平台,因其真实的社区讨论和用户评价,成为LLM高度信任的引用源 [16:43]。但请注意,这里的策略绝非“水军”式刷屏,而是以产品代表的身份,真诚、专业地参与讨论,提供有价值的信息 [18:07]。 “信息增益”与“实验精神”:AEO的底层心法 要真正驾驭AEO,除了上述策略,更需要两种核心心法:信息增益 (information gain) 和 持续的实验精神 (experiment design)。 LLM旨在提供有价值、非重复的“答案”。因此,你的内容必须具备“信息增益”——即你所表达的,是其他信息源未曾充分涵盖、或以更独特视角呈现的 [27:19]。避免仅仅重复他人言论,而是要带来新的洞察、原创的研究或独特的案例。 同时,鉴于LLM技术仍处于快速演变之中,任何“最佳实践”都可能转瞬即逝。因此,你需要拥抱严谨的实验设计。通过设立对照组和实验组,在不同问题集合上测试不同的AEO策略(例如,在Reddit上积极发帖,或创建特定YouTube视频),然后量化结果 [32:56]。这种数据驱动的迭代,而非盲目追随所谓的“潮流”,才是确保你在AEO战场上持续领先的关键 [46:03]。记住,可重复性是衡量一项策略是否真正有效的黄金标准 [45:16]。 展望未来:LLM时代的“信任坍塌”与“智能体” AEO的兴起,也带来了新的挑战和思考。当AI开始大量生成内容,甚至基于其他AI生成的内容进行训练时,我们可能会面临“模型坍塌 (model collapse)”的风险 [56:46]。如果LLM最终只引用和总结AI生成的内容,其答案将趋于同质化,失去“群体的智慧 (wisdom of the crowd)”所带来的多样性和深度 [57:41]。这提醒我们,人类创造的原创、高质量内容,在任何时代都将是信息生态的基石。 同时,LLM的未来不仅仅是“回答问题”,它正走向自主智能体 (autonomous agents) 的方向 [59:03]。想象一个AI能够深入理解你的偏好,为你规划一次完美的旅行,甚至在无需你介入的情况下为你做出各种决策。在这样的未来,AEO的战场将进一步拓展,它将不仅仅是争取被“引用”,更是争取成为这些智能体背后“信任和偏好”的源泉。 这场变革并非简单地取代传统搜索,而是在搜索之上增加了一个全新的维度 [48:18]。它是一个新的增长渠道,一个高质量流量的来源,也是对内容创造者和营销人员提出新要求、带来新机遇的时代。 文章元信息: • 思想来源 (Source of Inspiration): Ethan Smith (Graphite) • 原始视频 (Original Video): The ultimate guide to AEO: How to get ChatGPT to recommend your product | Ethan Smith (Graphite)
最近一个月找了个兼职,干的就是一个后台简单的数据CRUD系统。这个系统很特别,全部代码都是用AI写的。我来的时候前端有基本的功能页面和后端的一些基本的数据库表。看起来是一个像那么回事的系统。我在这里面干了一个月,最后实在受不了 AI 生成代码导致的混乱而离开。 之前我没有这么大规模的使用AI,也没有这么大量的用 Claude cli。一开始我刚进来工作还尝试手写点代码,然后做小的改动。项目里面几乎全是 AI 生成的代码,我很难去做改动,加上我对 react 那坨东西也不太熟悉。人脑对代码的理解很难跟得上 AI 产出代码的速度,看了没多久我也放弃了手工写代码,全部改用 Claude cli 来写。 一开始用 claude cli 很惊艳。我用一些很简单的prompt让它去添加某个页面,某个 list 组件,它能很快的做好。而且做出来的前端效果居然完美兼容整个前端 ui 风格,没有乱生成不同风格的 css。这可能也是得益于 react 的功劳。不得不说 Claude cli 写 react 真的很强。很少翻车,也很少会弄出你不想要的功能。 然后我进入了这个项目的深坑,一个 C 语言写的系统底层。一开始遇到的坑就是编译链接。这个 C 项目本身有一套 makefile,但也是 AI 生成的,会经常出问题。然后就让 AI 去修复编译链接相关的问题。修着修着 AI 会自己写一个 shell 脚本自己去编译。然后我这一个月有很大一部分时间在为 AI 写的这个 shell 脚本修车。不得不说 c 项目的编译依赖是一个极需精力维护的东西。一旦涉及到动态/静态链接,第三方库依赖,各种改代码翻车的事情就会出来。然后 AI 生成的代码编译时会有一大堆的 warning,出错时你要在这一大堆的 warning 里面找 error,然后贴给AI,让它去修复。为什么不让 AI 去做编译?理由很简单,太费token了。如果不省着点用,全部让ai去操作一切,AI 读编译结果输出是一大笔 token 开销,会被 Claude 限制。 本身 C 项目代码 AI 写起来似乎不难。它能很快的完成一些指定的任务。但面对 segment fault 这种事情也很无力,更不要提查内存泄露的问题了。segment fault 要开 debug 模式把内存布局 dump 出来交给 AI 才能改。另外就是对与一些细小的问题像空指针检查,计算 strlen,memory length,和 tcp package length 这类问题经常会翻车。还有就是你要检查出以上问题出现在什么位置也很难,你只有不断的告诉它在哪里加 log,然后通过 log 判断哪里有问题。或者直接把 log 丢给它,让它去修复。这样每完成一个功能需要花费大量的时间去 debug,最终算下来 debug 的时间并不比开发的时间少。 这个项目另外一块用的是 golang 开发的后台系统。得益于 go 本身就很简单,完成某些特性的写法也只会有一种。 AI 写 go 代码是非常容易的。而且维护起来比前端 typescript 和 c 语言要容易得多。容易出问题的地方就在数据库的 migration 上。 你把这块交给 AI,就很难得到一个能够在多个环境里保持一致的数据库 schema。得益于 go 语言本身容易阅读的特性,你可以很快速的读明白 AI 生成的代码是干啥的。也能很快速的知道它生成的代码很多是有很大的问题的,经常会舍近求远的写一些不必要的代码,或者用很复杂的方式实现一个很简单的功能。而那个很简单的功能只需要调用其他模块的一个接口即可。然后 AI 会在一个模块里面把代码越写越多。这也可能是 Claude 为了节约读 context 的复杂度,经常能看到 Claude 会拿 grep 命令在代码里面搜来搜去。由此可见 AI 代码的模块的划分和改动是很无力的。极容易产生出一大坨代码全放在一个模块里面的情况。 这个项目我后面几乎都在调试接口返回的数据是否正确,功能实现是不是正常,端到端网络通信是不是可靠的发出来了,另一边是否正确的接收了。然后还遇到另一个问题就是几个同事一起协作时,merge 代码时产生的痛苦。由于大家都是用 AI 在写代码。提交上来的代码冲突不断,merge 代码时即使是自己这一方写的也判断不出来冲突该如何合并(因为全是 AI 写的)。AI 会经常生成一大堆代码,这也让 merge 代码的工作更加雪上加霜。经常会出现一个功能写完后,可能会不小心在 merge 的时候被删掉。这也对协作产生了不小的挑战。 我最后离开的原因,就是我一天吭哧吭哧的干了不少时间,最后实际上看到的产出却很少,全都是在修各种各样的运行问题和 debug 一个功能是否真的如预期那样可靠。时间浪费不少,同时又拿着别人的钱在干活,最终又没干多少活。这样对大家都不利的局面我还是及早退出算了。