凡人小北
1个月前
看到 OpenEvidence 又拿融资,不得提一下这家公司。 就在一周前,OpenEvidence 宣布又完成了一轮 2 亿美金的 C 轮融资,由 Google GV 领投,红杉、黑石、凯鹏华盈、Thrive 等一众顶级机构加持,投后估值飙到 60 亿美金。 注意,是三个月内连下两轮:7 月刚融完 2.1 亿,10 月又拿 2 亿。而且是产品实打实增长后的结果,跟PPT融资完全不是一回事儿。 如果你看过很多次红杉的闭门会,肯定听过这家公司的名字。这家公司没有去卷模型参数、也没搞花哨 demo,就做了一件事,老老实实盯住医生最难的那几个问题,结果反倒跑出了很扎实的落地路径。 可能很多人还没太关注这家公司,那我快速讲一下: OpenEvidence 是专门做医生用的医疗版 ChatGPT,定位非常清晰:搜索 + 分析 + 自动写研究报告,所有能力都基于真实医学文献和临床指南构建。 分享几组数据: 1. 美国已有 40% 医生在用,每月新增注册医生 7.5 万人 2. 月度咨询量从 7 月的 35.8 万暴涨到现在的 1650 万次 3. 自研模型是历史上第一个在美国医师执照考试中拿满分的 AI 4. 推出新产品 DeepConsult,能生成博士级别的医学研究文献 5. 商业模式是谷歌是赞助答案,直接给药企做精准广告,预计明年 ARR 将突破 1 亿美元 说说他的技术,数据价值占了很大的比重,跟 NEJM、JAMA 系列等 11 本顶刊合作,喂了 3500 万份同行评审过的文献,把 AI 的幻觉率降到行业最低,所以医生才敢用也才愿意用。 以下是我想说的: 如果认真观察,会发现真正有价值的 AI 应用,往往不是最热闹的那批。 比如OpenEvidence 的崛起就提醒我们一个简单却经常被忽略的事实: 在一个足够需要专业积累的行业里,数据密度+场景深度+专业严肃性,这三者就是护城河。 并且那些最早下场,懂需求,并且还不怕脏活累活的人,会悄悄赢下整盘。 这种垂类的 AI 产品 PPT 可以很酷炫,但骗不了任何一个需要每天稳定输出结果的用户。 特别是医疗行业,这个行业不是能靠 prompt 拼出来的行业,不是说今天堆几个插件,明天跑个多模态就能打穿的。 这个行业不需要演示好看,真正能用才会留下来用户,医生是会用脚投票的。 能走到这一步的公司,从一开始就选了那条最难但最有价值的路径,熬过了看不到成果的阶段,最终成功了。
凡人小北
1个月前
如果你老板是那种节奏感特别强、细节管控欲很高的事无巨细型,你该怎么适配? 尤其你本身是一个团队的负责人,希望自己的保持自驱和探索的团队,怎么在不对撞的前提下,撑住上面又托住下面? 我领导风格就挺明显的:节奏感极强、什么都想提前知道一点、细节关注度也很高。 说实话,刚开始我情绪很大,但后来也想通了,就是慢慢做事的过程中,调整自己调整节奏,不能硬碰。然后做了一些事情,让我们这几支团队还能保留一点自己动的劲儿。 比如我这边会提前把关键节奏先定下来,有哪些地方可能是风险点、预计哪个决策节点会卡,我会主动提出来,提前同步。 老板既然在意节奏感,那我先打个底,让他知道我这边没掉链子,就不用事事插手,我这边空间反而更大了。 再比如,我不把上面的节奏 1:1 拿来压团队。 我会自己先缓一层,再换个说法传下去,比如说“我们这块再快一点,方便我们下周给出一个完整 demo”,而不是“老板说这个这周必须搞定”。 这种语气差别,其实挺关键的。一个是一起推进,一个是被人推着走,长久下来,团队的状态很明显完全不一样。 还有就是,我会留点缝隙让团队的人抬头看看。 不一定非得搞创新项目,有时候就是开个小会、讨论个备选方案、尝试一个新方法。你不留这点空间,团队很快就只会执行了,想象力和判断力都会变钝。 其实就是得让这个团队有点自己的动能,不然老板节奏一紧,整个系统容易变成被管理和等指令的那种僵化状态,哪怕人再聪明,也会慢慢变钝。 我挺在意这一点的。一个管理者是不是一个好管理者,是要想办法带出一支能自我决策、自我拍板的队伍,那种“手一松,整个团队就塌了”的状态,我自己都不想进。 老板是啥风格我控制不了,但我怎么传导、我团队怎么运转,我是能决定的。 当然话说回来,也不能光想着“我扛着就行了”。有些时候你还是得管理一下老板,创造一种让他不需要事无巨细的局面。 我会刻意把核心决策点和节奏断层提前抛出来,让他知道我在掌控,他就不太会越界干预。 如果他真有越级管人的时候,也会找机会聊聊,让他知道我这边已经推进得差不多了,节奏没问题,不用插手太多。 另外不需要教他怎么当老板,只需要让他知道,有些事你比他更早看见、更快落地,他自然会往后退一步。 上面和下面之间就好像三明治的中间,既要撑住上面,又得托住下面,其实中间靠的不是忍耐力,一个好的管理者要有能力建一套自己的节奏逻辑,把两头都黏住。 然后就会慢慢看出差别了。 一个自驱、主动探索的团队,和一个只是为了迎合老板而做出探索样子的团队,状态完全不一样。 能不能真正跑起来,组织气候里的人自己最清楚。 时间久了就发现两种团队做出来的东西,最后是会分叉的: - 一个做出来的事是能继续演化、能经得起时间考验的,过了那个节点它还在持续生长; - 另一个则可能就是为了某次高光临时拼出的demo,亮相那一刻是巅峰,之后就没了后续。 组织记忆是有惯性的,时间会帮你判断什么是真能力,什么只是对得上节奏的热闹感。 就这样,没太多大道理,就是一路摸索调整,慢慢磨出来的。
凡人小北
1个月前
凡人小北
1个月前
突然 FDE(Foward Deployed Engineer 前沿部署工程师)这个词火得有点莫名其妙,很多创业者一夜之间开始膜拜 Palantir 式打法,搞得好像硅谷又发现了什么新大陆。 先说我的看法:国外现在兴奋讨论的这套东西,中国人早就在用了。不夸张地说,FDE 这个概念在国内 toB 创业环境里,根本不是什么未来范式,它是过去 10 年我们活下去的方式。 硅谷的 FDE 模式今天之所以被捧上神坛,是因为 AI agent 产品天然不能标准化、不能纯靠 SaaS 拉起规模,只能靠“深扎现场 + 产品抽象 + 高难度交付”(这几个词眼熟吗)这种非线性方式打通从 0 到 1 的路径。 这种新范式我们不叫 FDE,我们叫它: 售前 + 客户经理 + 实施 + 技术支持 + 专人陪跑 + 项目现场 + 临时产品经理 是不是听上去不那么高级,也没人总结成Echo + Delta 团队这样的理论模型可中国 to B 创业者、尤其是医疗、制造、政企、教育领域的创业者,从来没有什么 SaaS 福报。 我们走进客户现场,用工程师替客户解决一线需求,项目经理拆用例,售前写方案,然后陪标、上系统。这些人一开始就被扔进落地即交付,交付即定制的泥沼里,硬生生走出了一套非标准化探索到产品复用化的路径。 所有这些国外今天才开始鼓吹用 demo 去找 PMF,我们已经 demo 到脱发了。欧美 SaaS 怕是忘了东方还有个神奇的国度。 为什么现在大家把 FDE 当作一种新的 go-to-market 策略来膜拜。可能是因为他们原来做的是标准化 SaaS,突然卷进 AI agent 的复杂场景,一下子手脚不够用了,才发现:哦原来世界上还有一种方式,叫“没有产品也要先干起来”?
凡人小北
1个月前
《为什么 95% 的 AI Agent 做不起来?》 非常推荐,踩的坑和解决方案跟我们几乎一模一样,虽然讲得很清楚,架构师视角,值得花 10 分钟读完,应用到工程实践中。 几个点: 1. 现在大家都还在拼 prompt,只有少数人开始拼上下文结构。 特别对的一点是:prompt engineering 已经不是核心了,context engineering 才是下一阶段的主战场。给再聪明的大模型喂进去一堆乱七八糟的输入,它还是只会胡说八道。 市面上跑得稳的 Agent,都是在“什么该让模型看、怎么看、以什么形式看”上下了大功夫的,这一点现在应该是共识了。 2. 记忆系统这事,光是能存起来远远不够 很多公司的 memory,说得好听点是长期记忆,难听点就是个聊天记录仓库。 真正落地的系统要分层记忆(用户级 / 团队级 / 系统级)。文章读完我感觉更多的篇 B 端,C 端要思考的是结合业务来做分层记忆,并且要能让人知道 它记住了什么,并且用户能自己改。否则就不是记忆是监控。 3. 不迷信单模型,这年头还不做 routing 的 agent 就别说自己做 infra 了。 这篇文章提到多模型路由,说得很对。不可能所有请求都丢给 GPT5,成本和时延直接炸掉,表现也未必好。 真正合理的系统,一定是: 快速反应的轻模型做分类和前处理、重模型做主任务、补一个模型做验证或追问。 一个 agent 后面绑定的一定是一个 LLM 团队。 4. 可追溯/可控/可信,是企业愿意用 Agent 的底线 很多人只想着怎么让 agent 能回答,但企业更关心:这句话是从哪里来的?有没有越权?出了错我怎么追责? AI 要可治理。 5. 最被低估的一点:Agent ≠ Chatbot 这篇文章最后说到的一点我非常赞同但还不够狠:如果还在用聊天当所有用户交互的方式,那agent 最多是个语音助理。 真的 agent 应该是:先用语言调度任务,然后在页面上看到结构化结果,还能继续点选、调整、组合下一步。这部分很多公司现在在尝试了,交互上比之前全部自然语言高效了太多。 一个特别有意思的点,当主持人问观众“你们中有多少人构建了文本到 SQL 并投入生产?”时,没有一个人举手。
凡人小北
1个月前
最近在看一圈 ToB agent 的落地情况,有个判断越来越清晰: 至少还得 1 年,国内 ToB agent 才可能真正起来。 第一,国内的模型能力,还不够。 ToB 业务链条长、场景复杂、对结果的容错率极低。 现在的大模型,哪怕再微调十遍,稳定性不够,自洽性不够,还不够听话这些问题依然严重。 prompt 写得挺对,它干的事还是不怎么靠谱。像个刚转岗的实习生,流程懂了点,但是做起来全是 bug。 第二,做技术和懂业务的,不是一拨人。 ToB agent 最大的挑战是知识怎么迁移。比如想让 agent 搞懂保险理赔、医疗问诊、法律审查……这些不是写 prompt 能解决的,它们背后是几十年经验、人情流程和模糊判断。 越值钱的知识,掌握它的人越年长,越难被结构化表达,更别说这批人愿不愿意倾囊相授。 技术今天搞出来一个 agent,业务方只会说三句话:你这不准啊、我们流程不是这样的、你这漏了关键条件,但这个流程是之前开发跟业务一起梳理出来的。 这背后藏了抵触,技术和业务之间,隔着的不是 AI,是一整座山。 那为什么 AI coding 能先跑出来?因为这事里最懂业务的就是技术自己。 谁最懂代码结构?技术! 谁能写 agent 调 agent?技术! 谁能 debug agent?还是技术! 技术是唯一一拨能自己用,自己调 bug的群体。业务等于本体,没有认知 gap,也不需要跨专业翻译,一整个闭环自然就跑通了。 本质区别在这:AI coding 是单边迁移服务自己, ToB agent 是双边博弈,需要认知共建。一个能快,一个必须慢。 对于 AI coding,只要模型理解开发者就够了。ToB agent,不仅模型要懂业务,开发者还得懂业务,然后两边还得对得上话。 这,太难了。 真正的转折点要出现:必须满足模型能稳定 编码行业知识,Agent 能封装复杂动作并处理结果反馈(前提是老顽固们愿意掏心窝),企业能放心把核心流程交出去。 到那一天,ToB 才真正算是 ready 了。 那时候再回头看 coding agent 的进化速度,也许已经不是一个量级的对比了。 技术在革自己命这件事上,从来没有输过任何群体。