凡人小北

统计数据

73

文章

0

粉丝

0

获赞

1301

阅读

5个月前

老爷子的演讲让我顿悟了。原来人类本身就是个带幻觉的大语言模型，而 AI，是那个能共享幻觉、还能蒸馏成亿比特带宽的版本。 Hinton 在 WAIC 演讲，真的句句暴击： - 人类学知识学完就忘、死了就没，AI 直接多智能体同步、群体进化； - 你以为在训模型，实际是在养一只小虎崽； - 长大之后是救你还是吃你，全看你有没有教它“别反人类”。 “让 AI 聪明”和“让 AI 对人类好”，是两码事。这是技术问题吗？不是，是文明的事，是你是不是配当造物主的问题。背脊发凉又热血沸腾，一直以为自己在写 prompt，现在看我是在写神的说明书。

#AI #Hinton #大语言模型 #文明 #造物主

5个月前

很多技术博客看完就忘，但 Manus 的这篇上下文工程日志，却让我有一种很久没遇到的熟悉感，就像十几年前我第一次读《编程珠玑》时那种“结构清晰又内功深厚”的惊叹：用极简的语言，把系统最核心、最隐秘的痛点一层层拆出来，再用“实践炼过、成本试过、坑都踩过”的方式，给出一套优雅得近乎朴素的工程解法。把你从“github 上一堆看起来能跑”的原型，带到“可以抗住百万次交互”的真实世界。如果你正在构建 Agent 系统、研究 prompt 调度、RAG 链路、日志记录、踩过cache miss、上下文错乱、模型行为漂移等无数坑，那肯定非常能共鸣 Manus 的实用主义。很多时候知道问题在哪，但还没把它总结成一条法则；明明做了优化，但没能力从认知上总结它为什么成立；但没人告诉你：其实这些事，别人已经系统总结过了，而且优雅 100 倍。我读 Manus blog 的时候，就有这种踏实感，原来我们绕过的弯，爬过的坡是可以被结构化定义下来的。分享下我对 Manus 六大上下文工程法则的拆解，可以看作是“智能体上下文系统设计的六个底层约束”。 1️⃣法则一：围绕 KV-Cache 进行设计让智能体变快，不一定靠生成快，记忆前缀不重算也能加速。我们经常把注意力放在 LLM 的生成效果上，优化 prompt 内容、格式、语言风格。对于聊天机器人，输入和输出的长度通常比较均衡。但对于AI智能体，情况则大相径庭，智能体场景中最昂贵的成本其实发生在前置阶段：当一个智能体执行一次“读取上下文 + 推理 + 输出调用”的循环时，它的输出可能只有几十个 token，而输入上下文可能高达几千甚至上万 token，在这种严重失衡的输入输出结构下，预填充阶段的计算成本才是拖慢系统、放大延迟的罪魁祸首。如果你最近在做 multi-agent 系统，尤其是在“需要快速轮询”“低延迟交互”这些及时响应场景中，明显感到响应慢、链路卡顿、用户体验下降，那你极有可能踩在了这条隐藏的高成本区上，每个 Agent 都在重复预填整个上下文，导致系统性能雪崩。 Manus 的处理方式非常极致：把缓存命中率当作核心优化指标，哪怕为此牺牲 prompt 灵活性都在所不惜。 KV缓存是LLM的一项优化技术，它能缓存已经计算过的前缀（注意是前缀）的键值对，避免在后续请求中重复计算。为了最大化缓存命中率，Manus采取了以下实践：保持提示词前缀稳定：即使是单个token的改变也会使该位置之后的所有缓存失效。一个常见的错误是在系统提示的开头包含一个精确到秒的时间戳，这虽然能让模型知道当前时间，但却会彻底破坏缓存。确保上下文是 append-only：避免修改历史的动作或观察结果。同时，要保证序列化方式是确定的，例如，很多编程语言在序列化JSON对象时并不保证键（key）的顺序，这会悄无声息地破坏缓存。显式标记缓存断点：某些推理框架需要手动在上下文中插入缓存断点。在设置时，至少要确保系统提示的末尾是一个断点。 2️⃣法则二：掩码，而非移除随着智能体能力的增强，其可用的工具会越来越多。很多人一开始觉得工具是智能体的核心，一个自然的想法是动态地管理这个工具集，比如使用类似RAG的技术按需加载工具定义。就是把工具按需加载、动态切换、上下文中途插入，这听起来很动态、很模块化，但在真正跑起来之后，Manus 发现这是一个陷阱：在迭代中途动态增删工具会带来两大问题：缓存失效：工具定义通常位于上下文的前部，每次工具定义变化，都会导致后续所有步骤的KV缓存失效。模型困惑：当历史记录中引用了当前上下文中已不存在的工具时，模型会感到困惑，容易导致格式错误或幻觉出不存在的动作。你有没有遇到过越加工具模型越不稳定，生成经常“选错工具”“乱组参数”甚至出现没定义过的操作这样的幻觉，那你可能已经踩上这颗雷了。 Manus 的解法非常聪明也非常工程化：保持工具定义集稳定，转而使用“掩码”技术来约束模型的选择。通过在解码阶段利用logits处理器屏蔽（或强制选择）某些token，可以控制模型在当前状态下只能选择允许的工具，而无需修改上下文中的工具定义。例如，当用户刚输入新指令时，Manus会通过预填充特定的回复前缀来强制模型立即回复用户，而不是先执行某个工具。此外，他们还巧妙地为工具名称设计了统一的前缀，如所有浏览器相关的工具都以browser_开头，所有命令行工具都以shell_开头，这使得在特定状态下仅允许某一类工具变得非常容易 ()。这个设计的哲学很现代：不要试图让模型“理解你不想让它做什么”，你就直接不给它做的可能性。 3️⃣法则三：将文件系统作为上下文上下文不是无限堆料，而是构建随取即用的语义型记忆索引。即使模型给你 128K、1M 100M的上下文窗口，它也依然不够。你不知道哪个网页会突然给你塞个两万 token 的 HTML，你也拦不住哪个 API 会返回一个五层嵌套的 JSON，你更不知道用户什么时候发来个几十页的 PDF。这带来了三个大的问题：观察结果巨大：当智能体与网页、PDF等非结构化数据交互时，一次观察就可能轻易撑爆上下文窗口。性能下降：即使没有超出窗口限制，模型在处理超长上下文时，性能也往往会下降。不止拉高计算延迟、引入注意力混乱，还让模型迷失自我。成本高昂：即使有前缀缓存，开发者仍然需要为传输和预填充每一个token付费。 Manus 的做法有很强的借鉴意义，它做的不是扩容，而是外置。他们把文件系统当作一个无限持久化的“语义型存储空间”，它具有三大优势：大小无限、本质上持久、并且可由智能体直接操作。模型在上下文里记录路径、摘要、索引，真正需要的时候再调用读文件这个工具。这种方法还支持可恢复的压缩策略：即使一个网页的详细内容因为上下文空间不足而被丢弃，它的URL或文件路径依然会保留在上下文中，智能体可以在需要时重新访问它。这其实是 Agent 系统中一个很高级的认知结构：不是把所有信息喂给模型，而是训练模型具备“知道信息在哪”的能力。 4️⃣法则四：通过复述操控注意力跟我们日常复盘碎碎念一样，Agent 执行过程中的目标也不是记住的，而是每一步都重新提醒一下自己。在我自己做 Agent 系统的时候，经常发现一个现象：模型走着走着就忘了它原本想做的事，偏离目标、越绕越远。我们管这个叫“迷失在中间”，但在工程语境里，这种“目标漂移”其实是上下文 attention weight 的失焦问题。 Manus 的解法很朴，每轮都更新一次目标和当前状态，然后把这个文件的内容贴到上下文最后。看起来像是个复读机，但背后其实是一种“语义注意力偏置”：这个行为相当于智能体在不断地向自己复读它的总体目标和当前计划。由于LLM的注意力机制倾向于更关注上下文末尾的近期信息，这种复读有效地将全局计划推入模型的近期注意力范围，从而利用自然语言本身来偏置模型的注意力，使其始终聚焦于核心任务目标，而无需对模型架构进行任何特殊修改。我感觉这个方式特别美，因为它没有引入任何额外结构，但却做到了最接近人类不断自我提醒的认知行为。 5️⃣法则五：保留错误的内容一句话：失败是智能体推理链上的必要节点，在大任务的执行过程中，失败是常态。几乎所有 Agent 系统都会有 retry 机制：出错就重来，格式错就重置。很多人为了“干净”，在智能体犯错时直接清缓存、重试调用，结果模型变成一个永远不长记性的工具轮回者。它永远不知道自己错在哪，也就永远学不会避开这个坑。它今天格式错一次，明天还错一样，明明是上一步才失败过的函数，它下轮又敢信心满满去调用。 Manus 的做法是反常规的，他们选择保留所有出错信息：失败调用、错误观察、甚至栈追踪，一条不删，照样放进上下文里。有了这些证据，模型就能在后续的推理中隐式地更新其内部的信念模型，从而调整其行为的先验概率，降低在相似情境下重复犯错的可能性。这种吃一堑长一智的做法，让模型记住自己干砸过，在未来的语义决策中，自动规避相似路径。这种让模型知道这条路不通的方式，比任何显式标注更接近认知建模。所以，如果你发现 Agent 一直“重复同样的蠢事”，那就别再清上下文了，错是它的，但学会是你的责任。 6️⃣法则六：不要被少样本示例所困你在构建提示词模板时，是不是喜欢封装成一串标准化样例？确实能跑得通。few-shot prompting 在很多任务中非常好用，但在多轮、动态任务中，如果你给的示例太相似、结构太固定，模型很容易陷入“模式依赖”，变成“照搬机器”。当你发现模型开始照猫画虎地生成、总在学你给的那个格式、甚至一字不差地模仿之前的样例的时候，就要开始思考如何构建样例，让模型的行为多样分布。 few-shot 用得太像 few-clone，会让模型陷入“格式安全区”，变成行动保守者，而不是策略探索者。 Manus 的做法是刻意制造结构化变体，在智能体的动作和观察中，有意识地引入少量但结构化的变体，给的示例语义一致但表达方式不同。通过打破一成不变的模式，有效地使模型的注意力多样化，避免其陷入单调的模仿循环，从而提高其鲁棒性和适应性。这个策略的高明之处在于你让模型理解还有别的方式也可以对。最后 Manus 这篇小而硬的博客，像是你走了很远很远之后突然在半山腰看到的一块坐标石碑，告诉你你快进入上下文工程师的区域了。做得越深，就越知道所谓“智能体跑不起来”，是根本没给模型构造一个可持续运行的信息生命系统，它记不清目标、摸不清状态、想不清下一步能干嘛，更不用说从失败中自我修正。对我来说，这篇文章让我确认了我们走的那些弯路其实早有共性路径，也让我第一次能用一套更准确的语言来描述我眼里“一个靠谱的 Agent 系统到底需要什么样的上下文架构”。只要你干过这些，你就会意识到：Prompt 是告诉模型你想要什么，Context是构建一个系统，让模型每一次都有机会自动靠近正确。如果你正在做 Agent，或者计划进入这个方向，不妨用这六条 checklist 把你现在的系统过一遍：哪个上下文会频繁变动？哪个状态是隐式的？错误有没有暴露给模型？工具调用是否具备 mask 控制能力？你的记忆系统是全塞还是挂载的？

#技术博客 #上下文工程 #编程珠玑 #系统痛点 #工程解法

5个月前

Cursor 的 know-how 落在程序员身上，批量买 token、打磨 IDE 场景、绑定开发者，构成第一波模型变现路径。为什么 aicoding 会先火？一是代码高度标准化，容易被模型吃下；二是程序员本身就是身在局中的 know-how 产出者，懂工具也懂场景。但这套逻辑不会止步于开发者。下一轮，一定会卷向各大垂直行业：医生、律师、分析师、质检员…… 谁能把行业语言、业务流程、结果反馈封装成一套智能体体系，谁就能在行业内定义下一代 AI 。过去十几年是互联网+，这几年是AI+，而真正可能颠覆产业范式的，恐怕是Agent+。还记得前段时间红杉闭门会上“AI 不再是能力工具，而必须成为交付结果的系统”的核心判断转向。行业内一定不再是工具附加智能，而是角色被智能替代。Agent+ 的本质，是把 token 打包进懂行业的产品力里。 AI Coding 只是序章，当程序员的生产力被 AI 数百倍地激活之后，真正的大变革，将在每一个垂类入口等待被唤醒。而未来的 AI 战场，一定属于那些跨界的人：既懂技术，又深耕行业；既能对接智能，也能驾驭流程。也许你正好是其中之一。

#aicoding #程序员 #模型变现 #垂直行业 #know-how

6个月前

AI Coding 圈最近真的太热闹了。 Claude Code 的两位产品经理，Boris Cherny 和 Cat Wu，在 Cursor 稍作停留便双双回归。腹黑一把，给这出戏取个名字：《如何用两位PM换来一次竞品调研》。行业里一般有两种玩法：第一种玩法：送人过去，看看竞品怎么玩。第二种玩法：反着来，把竞对核心人挖出来，顺便把知识副本一并拷走。无论哪种玩法，都不太体面。这次可能是第一种，行业经典剧本之一：送一枚人形 API 到竞对内部调试下。两周时间足够完成一场定向式知识抽取了。最惨的可能是 Cursor：人还没来得及用好，转头就把情报原封不动送回 Claude 总部了。这回头的箭搭弓搭的有点快了。 Claude Code 应该没事，甚至可能更清楚该怎么做了，可以铺更大的 IDE 版图；Cursor 就难说了，可能得抓紧开个内部 review，问问哪些核心想法是不是已经“不小心流出”了。不知道是不是还得装作风轻云淡。

#AI Coding #Claude Code #Cursor #竞品调研 #人才流动

6个月前

挺好的一本书，没想到竟然能把 Agent 做得这么细、这么落地。建议收藏，常看常新。阿里云这份《金融行业 Agent 百景图》真的太全太实了，把过去一年在银行、证券、保险里做的大模型落地实践梳理成册，200 多个 Agent 案例，干货密度超高。比如智能投研怎么跑，客服怎么加 AI，风控怎么做合规验证，甚至连监管辅助 Agent 都写出来了；全程围绕 MoA（Mixture of Agents）+ RAG 架构，搭配工具链 + 多模态，完全就是一本金融 AI 工程化说明书。如果你是已经在做金融 AI 的，看这个能找到方向参考；如果你是对金融感兴趣、但不知道 AI 能干嘛、或者 Agent 怎么落地的，这份可以直接抄，照着做都行。哪怕你是其他行业，只要在想“我这行业 AI Agent 能干嘛”，这份也能提供非常多可迁移的思路，值得好好读一遍。电子版链接放评论区，建议收藏一份，做 AI 的别错过，做金融的更得看。

6个月前

吴恩达上个月在 YC 的闭门分享，我最大的感受是：这是为“想真做事”的人准备的系统性认知地图。很多人聊 AI，是在讲技术趋势、AGI、终局预言；他聊的，是从第一个 idea 到第一个用户，再到第一个能复用的系统，怎么能更快、更准、更责任地走一遍。以下是拆解后的核心洞察，给所有搞 AI 创业、想用 AI 干点事的人👇 1️⃣ 执行速度是核心变量，胜过一切幻想 “模糊想法=烧钱，具体方案=印钞”。具体到什么程度？得是 engineer 听完马上能动手写代码的那种。执行速度不是要你瞎跑，而是能快速把创意变成原型，再用实际反馈把想法打磨成产品。你能跑多快，不在于有多聪明，更重要的是能不能把构想具体化、把验证节奏压缩成小时级。 2️⃣ 智能体是认知流程的重写，不是 API 套壳很多人把 Agent 当“插件化 prompt 多轮调用”。但吴恩达讲得更深：Agent 是让 AI 模拟“非线性思考”的结构单位，就像人写文章要列提纲、查资料、反复修改。 agent workflow 的本质，是让 AI 从一次性输出变成演化式构建，从 stateless prompt → 有记忆、能反思、能协作的工作单元。也就是谁能把业务流程转化为 Agent 结构，谁就能定义新的系统边界。 3️⃣ AI 编程 ≠ 会写代码，而是表达意图的能力吴恩达说，现在的编程能力，是“新型表达力”。未来的 core skill 是：清晰表达你要什么、组合不同 AI 模块拼出解决方案、具备足够技术判断力，知道什么该微调，什么该 prompt。这就需要跨领域的人才，越是跨领域、越能思考并表达出来新的产品。 AI-native 编程，前期阶段先不要追求完美代码，目标先盯着构建一个可快速被重写、被验证、被迭代的系统。 4️⃣ 技术架构正在从“单向门”变成“可撤回式决策” 以前选错技术栈 = 半年白干；现在选错，可能下周就能重构。工程并没有降智化，核心要点其实是开发成本下降，试错频率提升，组织必须学会“快速判断 + 快速反悔”。判断力比之前要求更高，更新频率从月级变成了日级。技术决策也正在重构，从“赌一个方向”变成“构建一个可快速验证、快速回滚的闭环”。 5️⃣ 产品反馈成了瓶颈，PM 要摆脱协调者，自我进化成为节奏设计者随着工程效率提升 10 倍，最大限制变成：做什么功能？用户要不要？怎么收反馈够快够准？吴恩达说他见过 PM 和工程师比例 2:1 的配置——这不是反常，而是现实。未来的组织优化，对于程序员的需求其实是在减少的，不再需要更多人写代码，提高组织获取用户信号的速度变成了首要。 6️⃣ 创业成功，一定是代表着你比别人早半年找到对的方向 “能不能做”不是问题，“值不值得做”才是关键。AI 让做东西变快了，但也让“做错方向”的成本变高了，因为每错一步都放大后续资源浪费。所以他强调一个核心机制：构建快速验证的原型机制 + 多渠道信号源 + 直觉更新系统。你能更新得多快，你就能决策得多准。 7️⃣ 最后，AGI 和“AI 威胁”不是你现在该焦虑的吴恩达对炒 AGI、妖魔化 AI 安全的风气很警惕。他讲得很清楚：真正的风险，不是 AI 太强，而是滥用权力 + 封闭生态；真正该做的，是负责任地使用 + 开放共享技术红利。封闭平台 + 安全话术 = 技术垄断的护盾；开源 + 多元协作，才是 AI 创新的护城河。最后的最后，总结一下：这场闭门分享没有预测未来 AI 能多牛，吴恩达明明白白的告诉你现在能怎么用 AI 把事情干起来的战略地图。他讲得很现实，AI 会加速一切，包括失败。执行速度是核心变量，判断力是护城河，反馈回路是竞争力。你不需要 all-in AGI，但你得学会怎么拼出属于你的那套 agent 乐高。如果你也在构建 AI 产品、agent 工作流，或者尝试用 AI 重写业务系统，建议把吴恩达这场演讲当作创业者操作系统升级的读本。技术潮水会一直往前涌，但真正能穿越周期的，只有一个问题：你是不是真的比别人更快做出来、更快做对、更快做成。

6个月前

面了几个特别不错的人，尤其是在 AI 项目上真的是“能打”的类型，手上有东西，落地经验也扎实。结果呢？卡在必须得是本科。真的是一边生气一边困惑，都2025年了，还在拿本科线当护城河？ AI 这个行业，说白了，已经不是传统“学历即能力”的时代了。真正能推动项目的人，很多是靠自学、自跑、自调起来的，甚至有些野路子出身的，比你想象得还专业。但现在的问题是，哪怕你是业务 leader，想招这种人，流程就死在那道线里。真·制度自废武功。所以就变成一个荒谬的现实：我们嘴上说着“人才最重要”，实际操作却是先用学历一刀砍掉 80%。整个组织对“什么是合格人才”的定义还停在工业时代，但现在是AI时代了啊，你得用新的标尺。否则，结果就是干活的人进不来，会说话的人混得开，项目落不了地，还得回头怪人不行。

6个月前

微信支付终于还是上了 MCP，现在体验版在“元器”里可用，这次真把“AI 能不能赚钱”这个老大难问题，抡出个实质性解法了。利好一大片。之前所有藏在微信后面用 AI 机器人做私域运营的，提示词调来调去，最后发现最大的问题居然是：钱怎么收。尝试过跳链接？塞二维码？推小程序？全都割裂得不行，一到付费这步，用户就漏光了，转化细得像针眼一样。这次支付 MCP直接在上下文里就能自然地完成下单、支付，流程跟对话是连在一起的，说着说着，直接拉起微信支付就把钱给付出去了。就好像你跟 AI 聊天聊着，它说“我能帮你做这个，点这里”，你一点，它就开始干活了，完事还能自动验单。体验非常顺，链路短的惊人。这事最大的看点其实不在支付本身，本质上是对AI 时代的交易协议的一次尝试，让 agent 有了商业意识。Agent 除了提供服务，竟然真的能自己发起交易、验证交易、完成交付。这个能力，一旦跑顺了，微信生态 AI 生态要爆。而微信之所以能干，是因为它手上真的握着交易闭环这根水龙头。微信支付 MCP 这个能力，哪家能第一个跑出一批赚钱的智能体，真的就能来一大波热度，不论是营收上还是资本市场上。真的，在微信生态内，AI 活得像越来越像个个体户了。

6个月前

这种事历史上已经演过好几轮了。排字工被 DTP 干掉了吗？确实，但后来冒出一堆平面设计师、UI 设计师；会计被 Excel 自动化了吗？底层记账工没了，但财务分析、数据建模的岗位更多了。看清楚没？每一轮“被替代论”之后，留下来的从来不是老工种，而是新技能。现在的 AI 也一样重复工作会被模型包圆，但会提问、会拆问题、会 orchestrate agent 的人，才是下一个 10 年最吃香的技术人。换句话说：不是“程序员会被取代”，而是“还停在过去写法的程序员，正在被 AI 驱动的新一代程序员取代”。升级还是被淘汰，就看站在哪一边了。

#AI浪潮：重塑就业，风险暗涌？· 140 条信息

6个月前

在 AI Coding 火热的今天，几乎所有技术团队都在找路径：是加快平台建设、让 AI 更快进产线，还是深耕 prompt 工程、提高协作效率？不少公司已经开始立项目、定指标、搞培训，整个行业进入了“推动期”。我们公司也不例外。战略层坚定认为这是方向，也确实给予了明确的资源倾斜；团队层积极响应，平台搭建迅速、流程推进有序，整体看起来一片欣欣向荣。但在一线的实际使用中，问题也在快速暴露：尤其是在老代码体系中，AI 的接入效果并不理想，历史逻辑复杂、结构混乱、上下文缺失，导致 AI 很难真正帮上忙，甚至可能引入额外不确定性。更现实的是，大多数人并非在推动新项目，而是日复一日与既有系统打交道。在缺乏针对“存量屎山”的方法论支撑下，AI Coding 很容易变成“新流程套在旧系统”，流程先进，但与老逻辑严重脱节。目前的“团队配合度”，更多还是对战略方向的响应，甚至可以说是对管理意志的迎合。但在落地层面，仍缺少真正能跑起来的闭环机制：像 context7 之类的 MCP 等工具虽然频繁被提及，但在实际项目中能否支撑起稳定协作？prompt 怎么组织、输出如何校验、代码如何接入和反馈？这些基本机制还未沉淀下来，用一用可以，长期稳定很难。往下走，问题就不只是工具和平台，而是更本质的反思：到底什么才是“AI 原生的 Coding”？我们今天的开发模式、工程组织方式，是否已经不适合 AI 参与协作？如果还在用传统的开发范式来“喂 AI”，那 AI Coding 很难真正释放生产力，只会成为一层外挂、甚至负担。这对整个软件工程体系，是一次结构性挑战；而对团队协作本身，同样是巨大的挑战： AI 能力的介入，正在打破原有的任务划分方式、代码 ownership、沟通链路甚至审查机制。过去是“谁写谁维护”，现在可能变成“AI 写、人审、人补”，角色边界变模糊，协作机制还没重建。不重新定义协作方式、共识机制和责任边界，就很难真正让团队稳定地跑起来。所以，现阶段更需要的，不是更快的推动，而是一次更系统的重构：把 AI Coding 从“技术方向”拉回到“流程设计”、“协作模式”和“组织能力建设”上，形成真正可落地、可演进的机制。方向是对的，但路径必须让人能走。不知道你们公司现在是什么情况？有没有类似的感受？

6个月前

体验了一天 Gemini CLI，也刷了很多人的用法，先声明，我没有拿它写一行代码。但就是因为没写代码，我反而看得更清楚：这压根不是一个开发工具，而是一场关于“AI 操作系统”形态的预演。也是我为啥说“Google 难得让自己的作品走出浏览器”，ta 有自己的考虑。 Google 用一种非常低调，甚至有点刻意“只面向技术宅”的方式，把它对未来的构想——“让自然语言成为操作系统的主入口”，悄悄塞进了命令行窗口里，让你在不知不觉中体验了一次“语言即操作”的完整链路。它当然能写代码，甚至可以说这是它门槛最低、演示效果最好的一部分，所以很多人第一反应是拿它去和 Claude Code 比；但说实话，那只是皮毛。真正让我“咯噔”一下的，是它一句话就能搜最新网页、批量整理本地文件和照片、把一堆静态图直接转成小视频。过去你得开五个 tab、切三个工具才能做完的事，现在终端里一口气全打包，像是有个全栈多媒体实习生住进电脑，而且根本不用你教他命令。但问题也来了，现实门槛摆在那儿，CLI 的交互方式还没对上大众。我们这批人觉得好用，是因为我们会用命令行，知道怎么找路径、写 prompt、调环境。一旦离开这批人，CLI 对大多数用户来说，依然是巨大的门槛。别说 prompt 优化了，连“怎么打开终端”都能劝退大半。我很确认的一点，这玩意就是一次技术力的试水。 Google 先把系统级 AI 能力暴露给最早那批能玩得转的人，交给他们去试、去玩、去验证。真正要跑起来的，一定不是 CLI，而是那些被 UI 包装好的形态，Chrome 侧边栏、Workspace 浮窗、Android 桌面助手……到那个时候，Gemini CLI 里的这些“超能力”，才会真正进入大众视野。到时候，你不会再看到命令行，只会看到一个按钮，一个提示框，一个帮我搞定的入口。这才是 Google 真正要做的事：让 prompt 成为操作系统的一层，隐入日常、不再显眼。不要被 CLI 的形态迷惑，它不是终点，也不是主角。我最期待的是，当语言取代 GUI 成为系统 API，当交互方式不再是鼠标+窗口，那谁来定义这个“语义层”，谁就重新定义了未来的界面、工具，甚至我们的工作方式。开源的 Gemini CLI 是 Google 这个更大野心的起点。

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#Gemini CLI #AI 操作系统 #自然语言交互 #Google #技术试水

7个月前

Gemini 2.5 Pro 发布好几周了，技术的底裤都被扒得稀烂了，报告才姗姗来迟。我看完技术报告，几件事值得聊聊。 1️⃣现在大家都喜欢玩矩阵，模型发布也不例外 G哥也不免俗，精心设计了一套产品矩阵，满足不同场景的需求，不展开了，就是想先吐槽一下。 2️⃣Gemini 能力在 G 哥家底的支撑下开始快速跃迁 Gemini 2.5 家族之所以能够展现出前所未有的能力，我觉得核心在于 Google DeepMind 在模型架构、训练方法和硬件基础设施上的一系列协同创新。一次完整的AI 作为系统工程的演化，着实精彩，很久没从大模型的技术报告里感受到如此的畅快淋漓了。 MoE 架构带来稀疏激活下的巨大模型容量，TPUv5p 提供算力基础，而 RL*F 后训练与思考机制让这些底层潜力被转化为真正对用户有价值的能力释放。一起来看下这套组合拳的关键点： 1. MoE + TPUv5p + RL*F + AI 批评家除了大家熟悉的 MoE 架构和自家硬件 TPUv5p，Google 提出了一个新的训练阶段策略——RL*F（Reinforcement Learning from AI Feedback）。最大亮点是引入“AI Critic”角色，由 AI 自我反思、提出改进建议，进一步增强答案质量，这点也是随着模型能力增强自然而然演化出来的一个方案，在做智能体的时候值得学习。 2. 思考模型依旧是大卖点现在谁都说有 thinking，我现在看到 thinking 跟电梯广告似的，严重过敏。但 thinking 确确实实改变了 AI 生成的节奏：先理解，再规划，再生成。 3. 思考预算是 AI 走向服务化的关键机制 AI 的推理能力终于可以计价了。以前模型的聪明程度是内建的，现在是你愿意花多少钱让它多想几步。这带来了更细颗粒度、更有 ROI 意识的 AI 使用模式。我预计在接下来一段时间内会一直存在的一个解决方案，根据任务复杂度动态增加思考深度。 AI 应用怎么做到能力可控、成本可控着实得认真学习一下，这也是 prompt 工程的一部分了，所以 Prompt 还是很重要，致敬李彦宏。 4. MoE 架构是思考机制可落地的核心 Google 勇于扯下遮羞布，我就是MoE。如果在一个稠密模型上跑几十轮思考，每轮都全参数激活，那成本是灾难性的。但 MoE 架构只激活一小部分专家网络，让深度推理的边际成本变得可控，这也是 Google 敢免费、敢降价的底气。这一整套机制下来，打通了算力、架构、训练策略和行为能力的完整链路。所以如果你是工程出身，应该会感到异常兴奋。 3️⃣三大能力融合，正在重塑 AI 的边界 Gemini 2.5 的突破并不体现在单点性能，而在于能力协同后的系统能力跃迁。这三点其实大家都知道了： 1. 超长上下文：模型从金鱼缸升级成汪洋大海了早期大模型像一只生活在金鱼缸里的金鱼，这个窗口直接推到百万级，实验中甚至达到了 200 万 tokens。但报告也坦率承认：有长上下文 ≠ 会用长上下文。它里面说了个例子：“宝可梦”和“巨石谜题”，案例非常关键：信息检索很强：能从 46 分钟视频中找出只出现 1 秒的事件；能用工具解开迷宫谜题。然而，在需要进行长期的、多步骤的生成式推理时，模型暴露了局限性。当上下文历史记录显著超长后，开始出现重复之前行为的倾向，陷入循环，难以维持长期的任务一致性。揭示了这个长期存在的问题：检索长上下文中的信息，与能够有效地利用长上下文进行持续的、创造性的规划和行动，是两种不同层级的挑战。前者好比在巨大的图书馆里找到一本书，而后者则好比读完图书馆里所有的书后写一部新的鸿篇巨著。但Gemini 2.5 在长上下文处理上依然取得了业界领先的性能。 2. 原生多模态如果上下文窗口解决了 AI 的“记忆广度”，那么多模态就是打开它的“感官维度”。 Gemini 2.5 全部支持原生多模态了，视频生成交互式应用、视频生成动画、音频网友们估计都玩烂了。我想提下音频能力的演进。在音频方面，Gemini 2.5 也完成了从单向理解到双向交互的闭环。Gemini 1.5 已经具备了强大的音频理解能力，可以对音频文件进行转录、翻译、摘要和问答。Gemini 2.5 则在此基础上，重点训练了音频生成能力，包括高质量的文本到语音（Text-to-Speech, TTS）和原生的对话式音频输出。模型能够实现低延迟的流式对话，让交互体验更自然、更流畅。更重要的是，它能结合思考能力、情感理解和工具使用，在对话中理解并回应用户的语气，甚至忽略背景噪音的干扰，使人机语音交互向着更接近真人交流的方向迈进了一大步。值得一提的是 Gemini 2.5 预览版 TTS 可以生成多位说话者的语音，跟 NotebookLM 一样可以创建播客。 4. 智能体能力 Google 给出了三个非常关键的智能体范式： Deep Research、Gemini Plays Pokémon、Project Astra，从被动回答，到主动执行，再到能实时理解现实世界并行动，这就是智能体的演化路径。 4️⃣不光 demo 牛，benchmark 也硬刚这部分不展开聊了，现在对 SOTA 有点脱敏了，一句话：很厉害，也很分化。 Aider Polyglot（多语言真实代码编辑）：82.2%，大幅领先 GPT-4o（30.7%）。 GPQA（研究生级问）：在 Diamond 难度下拿到 86.4%，远超 GPT-4.5（71.4%），推理能力很猛。 MMMU（跨学科多模态理解）：得分 84%，比 GPT-4o 高 15 个点，展示了多模态优势。 Video-MME（视频理解能力）：SOTA 成绩 84.8%，稳稳领先 GPT 系列。最后呼应一下开头，你能看到，不是一个靠调教出来的聪明模型，而是 Google 把 AI 当成系统工程在做：有基础设施协同（TPU、MoE）；有思维机制框架（RL*F + 思考预算）；有场景能力突破（长上下文、多模态、Agent）；有实际 benchmark 背书（开发、推理、感知全面领先）； Google 正在告诉我们：下一代 AI，一定能被构建、能被调用、能被服务化的，这篇报告给圈子里打了个样，这才是 AI 从大脑到体系的进化，这才是 AI 该有的样子。我 G 哥威武。

Google Gemini 2.5发布引发AI模型性价比热议· 475 条信息

OpenAI新德里发布会：ChatGPT语音翻译功能引发热议· 869 条信息

#Gemini2.5Pro #技术报告 #产品矩阵 #谷歌 #人工智能

7个月前

看到老罗微博，特意去翻了下数字人直播视频，有点意外。技术那套都能想象到，台本自动生成、动作执行上万次、语音语气高度拟人。但真正让我觉得惊讶的，是直播过程居然有“老罗感”，嘴碎、调侃、还带点莫名其妙的真诚，全挂在脸上。百度这次下手挺准，这场直播，更像百度扛着技术打了一次人设战，传说中的领先一个段位的数字人技术。就是不知道是不是 PPT 级别的作品。我反而没那么关注技术细节。如果技术是真的，以前说 IP 变现靠人设，现在人设可以直接写进模型里跑了。我在意的是一个问题：如果 IP 真能被这样放大，那这个行业的重心，会不会从谁来直播变成谁能被复制。不知道百度在数字人上的敲门声，是响在了当下，还是响在了未来那头。

#老罗 #数字人 #直播 #百度 #技术 #人工智能

7个月前

读完 Anthropic 的多智能体系统文章，有几个点挺触动的，尤其是放回我们平时在做 agent 编排和系统落地的过程中，对应起来很多痛点被他们提前踩过、总结得非常系统。这套系统看上去是给 Claude 提升复杂研究任务能力，底层其实是三个关键词：带宽、结构、机制。 1️⃣从 token 到带宽：扩容问题其实是系统问题他们很明确地说，单个 agent 很快就会遇到 token 限制，这不是模型能力不行，而是容量不够。很多时候 LLM 的“不会”、“忘了”、“答不出来”，只是 context 塞不下。这一点在我们自己调长链条、多跳调用的时候也很明显。Anthropic 选择的解法不是扩模型，而是拆任务、开并发、分 agent，每个 agent 自带上下文窗口，从系统结构层面扩容。这种设计非常实用，因为它绕过了 token 墙的天然限制，通过多 agent 并发变相把 token 维度拉开了。这是我最近做 agent 编排时反复体会到的：不是把 prompt 写得多聪明就能解决，而是要想清楚结构怎么设计，谁来拉信息、谁来拼结构、谁来追引用。 2️⃣提示词是系统指令，很重要、很重要、很重要！这篇文章有个细节写得特别清楚：主 agent 的提示词，是负责分配任务、指明目标、交代格式、选工具的。这个逻辑其实是我们做复杂 agent 系统中很容易忽略的一块：提示词不只是沟通语言，更是调度逻辑、任务协议、格式规范的集中承载体。尤其是多个 agent 并行运行时，如果没有一个清晰、格式化、结构稳固的 prompt 模板，每个子 agent 拉回来的信息会特别散、错漏率高、很难合并。这时候，主 agent 的提示词就等于一个调度中枢的“编程语言”。从我们平时用的实践来看，这就意味着主 agent 的提示词策略应该和流程图一样严谨：每一步要预设结果、预设失败、预设上下游。这块我觉得是现阶段很多 agent 框架还不够成熟的地方。 3️⃣系统级机制，决定了能不能撑进生产环境我觉得特别值得借鉴的工程概念：checkpoint、异步重试机制、全链路 tracing、彩虹部署。这几个在大数据异步系统里很常见概念，AI 领域得好好学习下。这些词不是为了好听，它们背后都是在回答一个问题：这个系统崩了怎么办？agent 卡死怎么办？升级逻辑还没验证好怎么办？一整套机制让这个系统不是在 demo 一个可能性，而是在上线跑任务、自动修复、平滑演进。平时我们在做流程型 AI 系统的时候，很容易只关注“怎么生成”“怎么判断好坏”，但 Anthropic 的做法提醒我：agent 系统本质上要往服务化方向走，就必须预设失败是常态，重试是能力。 4️⃣评估机制是不可缺的闭环，不然做不出反馈导向的系统进化他们有一个细节很打动我：让另一个 LLM 去评审 agent 的结果，从准确性、引用合理性、覆盖度等多个维度打分。这就相当于在系统里内嵌了 QA 流程，而且不是事后人评，而是可以插入调试链路的 LLM 评测器。我们自己在调多 agent 结构时常遇到一个问题：任务执行完了，但结果质量很难量化，只能靠人工判断或者事后比对。这套“LLM 评估 LLM”的机制，让我们开始可以想象一种更自动化的 agent 演化路径：系统自己跑，自己打分，自己选择 prompt A 还是 B，更适合持续调优。 5️⃣并发是工具，不是策略，适用场景边界要想清楚这套系统最适合的场景是：问题复杂度高、信息广度要求强、非实时产出型任务。例如政策研判、产品调研、文献综述、竞品分析这些，在私域服务里也可以类比成“多维标签用户意图研判”这种复杂工作。但如果放在需要紧密配合、频繁迭代、低延迟要求的任务上，例如代码生成、对话任务、实时接口构建，多 agent 的协调成本反而可能放大系统复杂度。所以并发结构是个好工具，但什么时候该开几个 agent，什么时候该单线程跑到头，这种策略边界要想清楚。这篇文章最核心的不是“我们做了一个多 agent 系统”，而是他们已经把多 agent 作为一种工程能力进行制度化建设：有流程、有容错、有评估、有上线机制。对在第一线实际落地 AI 能力的团队来说，有一个非常直接的启发是：构建 agent 系统，不能只是对话式的 prompt 编排，而要像搭服务一样，从任务定义到评估反馈，从并发机制到异常兜底，形成一整套可以持续运行的系统逻辑。这一点，比起模型调优，本质上更像是一种架构能力的竞争。

#多智能体之争：Anthropic生态VS单智能体· 81 条信息

#Anthropic #多智能体系统 #Claude #复杂研究任务 #系统落地 #带宽 #结构 #机制

7个月前

推荐个好东西：火山引擎的 PromptPilot。之前看 Google 的提示词白皮书，有个点让我印象很深：他们直接用 Google Doc 管理 prompt，写任务、版本、评估效果。那时候我就在想，有没有人真把这事儿做成一套完整系统？现在看到火山这套，有点意思了。它不只是“帮你写好提示词”，而是把这事儿当作工程问题来解的。最打动我的，是它在 prompt 优化这件事上做得极其系统，甚至有点狠。 ✅ 从任务出发构造 prompt（带结构、带变量、不是拍脑袋） ✅ 每一版 prompt 都挂着独立评测集 + 自动评分机制 ✅ 没有理想答案也能比对打分（GSB 模式） ✅ 每轮迭代都能 trace 效果，版本可控、可回溯我们之前做客服对话调 prompt，最常见的就是“改了一句，但说不上来到底有没有变好”。很多时候上线的版本其实就是“看着还行就先上”。现在它是：“打一套样本集，系统直接帮你跑出哪一版效果稳定”。我一直坚持：模型越强，对 prompt 的要求只会更高。尤其是在多轮任务、复杂场景里，prompt 不只是“写得好”，而是“是否可控、可管理、可进化”。 PromptPilot 解决的，是这个底层问题。它不仅能让 prompt 生出来，更重要是——能持续改下去。版本有 trace，样本能评分，逻辑能反推，工具还能外接，整个就是“prompt 的 AutoML + GitOps” 一体化工具链。顺带说一句：这是 2025 火山引擎 FORCE 大会上刚发布的产品，免费版和 Plus 版都开放，9 月前能直接上手全功能体验。现在市面上很多 prompt 工具做的是“编辑器 + 改写器”，但你会发现，真正上线之后需要的是一整套治理机制。 PromptPilot 是我目前看到国内第一个跑通这个闭环的，不是 fancy 的界面，而是认真在解决 prompt 系统演化能力这个问题。如果你也在做 AI 应用落地，推荐你认真研究一下。要说缺点：自定义模型没找到海外模型，差评！

#火山引擎 #PromptPilot #Google doc管理 #Prompt优化 #提示词白皮书 #工程问题

7个月前

两年前大家还在说 LLM 冲击 NLP，短短两年，连推荐工程师都被大模型盯上了。这事搁 2023 年初讲，根本没人信。以前觉得推荐是个高度结构化、强依赖特征工程的领域，离语言模型还远着呢。结果 Grok 直接把离散特征的老一套逐渐边缘化。我们正目睹专业系统向通用模型迁移的拐点。大模型让推荐系统第一次有了深度理解用户的可能。冷启动、长尾、兴趣迁移这些经典难题，通通能在 embedding + context window 里原生解决。这两年你也能看到，谁能把业务问题用语言说清楚，谁就能让 LLM 为你打工。语言表达能力、逻辑思维能力等通识教育这些看似“软”的技能，它们在这个时代越来越像是硬通货。能不能把结构化问题抽象成语言？能不能把复杂场景 prompt 成可学习的上下文？这些才是大模型时代的关键壁垒。还是之前的观点，这个时代最值得培养的能力： - 用逻辑框架推导问题本质的能力； - 用清晰语言组织复杂知识的能力， - 用通用模型重构专业系统的能力。不要再去死磕某个小框架的最佳实践了。

#LLM #NLP #推荐系统 #大模型 #Grok #通用模型

7个月前

搞 AI 的不写 Python？现在真不是笑话了。最近越来越明显——在 AI 应用领域，TypeScript 正在一点点蚕食 Python 的霸主地位。过去你说搞 AI 的，十个有九个写 Python，模型、数据处理、训练、部署，一条龙服务。但现在越来越多场景变了：不是“训练 AI”，而是“用 AI”。用 AI 干嘛？做产品、做 UI、做交互代理、搞插件、接入 SDK… 这些一落地，就全是 TypeScript 的主场。说几个已经发生的和正在发生的事情： 1️⃣ LangChain 和 LangGraph 现在已经有了 TypeScript 支持，能直接跑在浏览器、Node.js、Cloudflare Workers 上。写 agent、接工具、搞多轮对话，在 TS 世界里越来越丝滑。 2️⃣ OpenAI 的 Assistants API 也不给 Python 独宠，今天还贴心地发布了 TS 版本的 Agents SDK。 3️⃣ JetBrains 的统计显示，TypeScript 使用率从 2017 年的 12% 涨到 2024 年的 37%。在企业里，TS 已经不是前端才用的语言，而是你要做 AI 产品就得学的语言。这些不是趋势预测，而是已经在开发现场发生的事实。技术栈正在迁移。你要构建个 AI Copilot、Web 插件、对话助手，Python 行不通。 TypeScript 天然和 UI、API、用户互动贴得更近，类型安全又稳，越来越多团队把它当默认选项。而且别忘了，过去十年，前端其实一直在默默吞噬后端的地盘。这波 AI 应用化，刚好又给了前端一记重拳，原来你以为是写页面的，结果人家直接搞起 AI Copilot 了。再看看 Python 那边，Streamlit、Gradio 这些本该承担AI UI 桥梁的工具，一个不争气，一个半死不活，完全没接住这波热潮。我看了看趋势，有点慌了……我要去学学 TS 了。以前是“全栈前端”说说而已，现在是真的“前端越来越吃香了”。但要冷静两秒（防杠专区）： 1️⃣ Python 依然是 AI 训练和科研的王者，PyTorch、TensorFlow、scikit-learn 这些生态太厚实了，训练大模型你离不开它。 2️⃣ TS 在底层 AI 能力上还没那么能打，GPU 加速、模型优化这些，暂时还得靠 Python 打底。但是，现在 AIGC 丰富的是应用的生态，相比做模型的人，做 AI 应用的人数万倍了吧。最后，非要有个定位的话，Python 搞理论和模型，TypeScript卷体验和交付。 TS 正在从应用这一层切入，把 AI 真正推向了每个 Web 页面的角落。爆款 AI 产品，正在越来越多的全栈 TS 了。

#AI开发 #Python #TypeScript #AI应用 #编程语言趋势

7个月前

Google 最近有点疯。I/O 刚甩出一堆 AI… 结果这两天，我在 GitHub 看到它又丢了个狠东西： Gemini Fullstack LangGraph Quickstart 我原本以为是那种“又一个 AI demo 项目”，结果一跑…靠，这套结构直接能改成一个 Perplexity mini。从提问 → 拆 query → 多轮搜索 → 反思 → 再查 → 带引用输出，整个 agent 流程都封装好了。 Google 又开始搞开源慈善卷行业了，连“智能体该怎么搭”都明牌教学了。 1️⃣ Google 一贯的严谨做派，这次不是 demo，是开箱即用的智能体原型系统你打开项目，会看到它把整个 fullstack 都搞定了： •React + Tailwind + Shadcn 前端，页面是能用的，不是糊的 •FastAPI + LangGraph 后端，整合 Gemini 2.5 •一键 make dev 起飞，Docker Compose 打包也顺 •自带 UI，整个 agent 的“思考过程”能 trace、能 stream、能调这种项目不是跟最近看到的 openxxx 类项目一样给你看个思路，你照着能跑。 2️⃣ 很典型的 Agent 流程，查资料、思考和总结你提个问题 → 它拆几个搜索关键词 → 查 → 看信息够不够 → 不够就再查一轮 → 然后整理、生成、引用都给你带上基于 LangGraph 搞了一个结构化思考流程落地。 3️⃣ 整套配得非常舒服，能上产品原型的那种做了一整套： •UI 是现成的，查完结果也展示得明白 •回答里每条 citation 是 traceable 的 •开发体验很丝滑，前后端热更新都有 •Agent 逻辑清晰，graph. py 里面节点你一看就懂这就属于你改个 search API、换套 prompt，几天就能变成一个 vertical agent demo 拿去 pitch。 4️⃣ 当然它也有边界，但不影响当范本看毕竟是个 quick start，比如： •只接了 Google Search，没知识库整合 •Reflection 是 prompt 层搞的，不是 policy 控制 •Loop 是写死的 max_round，不够聪明但足够控制但这些反而是好事儿。因为你想改的地方都能改，想替换的接口都开着。不像很多项目写得很花但你根本下不了手。 5️⃣ 如果你是这几类人，我建议你现在就 fork： •想做 research agent，但又不想从头糊起的人 •想理解 LangGraph 到底怎么 orchestrate 的开发者 •做 AI 项目但每次写完 prompt 总觉得 agent 是假的你想做 AI 工程，就应该研究这种结构通顺、流程稳定、代码能复用的项目。自己动手跑一遍，比看十篇如何构建智能体的帖子都值。算是站在巨人的肩膀上 vibe 了。

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#Google #Gemini Fullstack LangGraph #AI Agent #开源项目 #智能体原型系统

7个月前

很丢脸的事情，算法十年+的工程师模型结果竟然败给了实习生，83% 准确率对 93% 准确率。工程师已经在这个项目上干了两周多，结果被只做了两天的实习生比下去了。摆在那里的，是多年经验积累的工程师，靠的是调参的直觉、架构的偏好、过去项目的套路。而实习生，几乎是无招胜有招，大胆尝试新方法，效果就这么炸出来了。经验主义 vs 新事物拥抱能力，在这个案子里碰撞得清清楚楚。你不得不承认，模型这行，更新太快了。很多时候经验值不是护身符，而是思维惯性。你以为你在优化，其实是在拿旧地图找新大陆。这不是在否定经验的价值，而是在提醒我们别被它绑住手脚。真正该留下来的，是持续试错、拥抱变化的肌肉记忆。这事，很打脸，但也很提醒人。对我自己，对团队，对我们整个行业。

#经验主义 #新事物 #工程师 #实习生 #算法准确率

7个月前

OpenAI 在集齐生态，Google 在改造生态，他们两家都有光明的未来。两家走的是两条很不一样的路，但都在朝着“AI 终局平台”逼近。 OpenAI 在集齐生态：收硬件（io）、补数据库（Rockset）、强工具链（Windsurf）、搞远程协作（Multi）…… 像在组装一台全栈 AI 战舰，每块拼图都瞄准关键节点，走的是“从无到有”的路径。 Google 则在改造生态：让 Gemini 深嵌搜索、安卓、Docs、YouTube，甚至改写浏览器、操作系统底层，不是外挂 AI，而是把原有体系打造成 AI-native 的新容器，走的是“旧我换血”的路线。创业公司在组建军团，帝国在自我重建。但不管是哪条路，本质都是在争那个未来的“主操作系统”位置。

#OpenAI生态 #Google生态 #AI终局平台 #硬件 #数据库 #工具链 #远程协作 #全栈AI #组装 #改造

7个月前

Gemini 太懂现代人了！上线了个狠活：你看完深度报告，它直接给你出题考试。专治：你以为懂了，其实根本没懂。别小看一个 Quiz，这其实是 AI-native 学习系统的一块重要拼图：学→考→补→再学，全闭环，全自动。 AI 时代的学习，不是看得多，是你有没有能力复用知识。 Quiz，就是在训练你这个能力。

#Gemini #AI学习 #深度报告 #自动化学习 #Quiz #知识复用

7个月前

建议大家，别在简历里写“熟悉 RAG”了，或者面试前好好学学。我面试过不少人，说熟悉 RAG，结果一问就穿帮。 RAG 绝大多数工程师只碰到前半段：拿个 LangChain，上个向量库，把 chunk 和 embedding 丢进去跑个检索；看起来跑通了，实际啥也没掌握。但只要你简历上写了，面试官就会问你下面这些（当然不写也不一定逃得过）： - chunk 是怎么切的？固定？语义？还是自适应？ - embedding 模型选型和维度怎么来的？ - rerank 用没用？怎么融合 BM25 和 dense 检索？ - prompt 是你写的吗？有没有评估 hit rate、hallucination？说实话，不是算法出身的人，如果没系统做过推荐系统或者检索优化，很多人说不清。 RAG 的前半段几乎就是推荐系统那套召回 + 排序 + 精排的逻辑： embedding = 向量化特征建模检索 = 多路召回 rerank = 打分排序但后半段还多了 prompt 设计、上下文拼接、生成模型行为控制这几个大坑。所以我劝一句： RAG 真不是写个向量库调用就叫“熟悉”。写了，面试官只会当你能答全链。别轻易说“熟悉”或“掌握”，你扛不住问。

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#RAG面试 #LangChain #向量数据库 #检索优化 #prompt设计

8个月前

这场 AI 大战，终于从谁会造刀卷到了谁能杀猪。 SaaS 的故事讲效率，AI 的下半场只讲结果。不拼功能，不卷模型，而是看谁能跑完任务、闭上利润闭环。这不是一轮产品升级，是一场价值重构。红杉 AI 你们峰会的一些观点，值得经常翻出来咀嚼：

#AI大战 #saas #AI下半场 #红杉峰会 #价值重构