即刻App年轻人的同好社区
下载
App内打开
佳心
299关注1k被关注0夸夸
💻 创业中|前 MiniMax 大模型后训练工程师(M2.x/M1)&开发者社区负责人|前语雀开发
☕️ 喜欢旅行|五只猫仔
佳心
23天前
最近被 Claude Opus 4.7 惊喜到的一个例子:
我在读一篇做图表语义分析叫 ChartQAPro的论文,对作者说的web chart 的数据源来自 157 个源站很感兴趣,但论文和hf、github仓库里都没有放出来原始数据,于是让模型去查。

遇到这种网上都搜不到的情况,以往的模型到这就停住,要么直接说做不了,要么建议联系作者,最多再给一个邮件模板。一些笨模型甚至像鬼打墙一样,再怎么压迫,都只是在一些低价值路径里反复打转😅

今天我和opus(Claude桌面端)说“你去做,我只想要看到结果”(图1),它去一番深度调研了然后发现确实找不到(图2)。这时候精彩的来了,它想到了个思路是图片图脚可能会带有来源标记,并开始思考对 1252张图片 下载+本地OCR的可行性,并且根据测试耗时选择了多线程做OCR(图3)。最后通过这种朴实无华甚至看起来有点笨的方式,帮我拿到了98个域名(图5),甚至还回头去pdf里读了附录做内容二次校验(图4)。

最后的结果完全在我意料之外,原本我都预想准备要写邮件给作者了,结果竟然拿到了一份还原了60%以上的域名清单!

真正让我惊艳的,不是它用了OCR、多线程这些具体手段,而是它在检索路径明确失败,常规路径走不通之后,没有给“无解”,也没退回到写邮件这类保守策略,而是主动重写了问题本身!

它把“找不到数据源列表”转化为“是否存在可利用的弱信号去反推来源”,并进一步落到图像中的来源标记这一具体路径。随后小规模测试OCR验证可行性、调整优化并发策略,最后再回头对结果做校验。

这背后体现的,是模型具备一种更稳定的策略:默认路径失效时,不会中途停在“无解”,模型会继续改写问题,直到把它推进到一个还能执行的空间里。
其实之前的版本也会出现类似行为,但更像偶发的“灵光一现”;但在 Opus 4.7 上,这种策略看起来变得稳定且可预期,这是 Opus 4.7 今天让我非常惊讶的点!
53
佳心
2月前
想问下大家的个人openclaw/agent有给自己挣到钱的吗?怎么挣钱的?我最近很好奇,一直有这个疑问,很多人都在聊🦞可以当数字员工做价值产出,想和大家交流交流,能赚到钱的人是怎么在用agent赚钱的/有收益的?😄
72
佳心
4月前
最新版Codex的Automations好评!这版感觉是AI agent chat(thread)+ worktree(git manager)+ cron(automation) + skills,有点意外的喜欢,这个UI和交互用的很顺手
刚才直接玩了三四个小时vibe coding了个AI资讯雷达播报系统,帮我找了几十个top rss源,一一做了标记、评级,现在已经可以给我推送每日AI简报了。
下一步就是把openclaw的推送im的能力搬过来,刚玩了几天的openclaw就可以丢了😆
(另外,我连续用了四小时 Codex 竟然没像CC一样遇到限流,难道是刚发布让大家先爽爽用起来🤔
39
佳心
4月前
in distribution or out of distribution!这个观点太精辟了!非常赞同!我越在做代码能力后训练,越是感觉到每个模型都有自己的数据分布,很多大家现在能用AI做好的任务都是因为模型的训练数据分布在这些任务场景里训的好,甚至每个领域都align to这个领域专家的taste和对领域的深度+广度理解。而我,想要和能够有能力做out of distribution的任务的人工作😄 //@熊猫ai甘蔗: 我认为还有一点是搞明白自己公司业务需要的代码是in distribution还是out of distribution,越偏离越需要手写代码的能力。

佳心: 最近连续面试很多候选人,有一个普遍现象,大家的代码能力退化速度之快,让我感触非常深。 vibe coding普及一年以来,25年上半年的侯选人大部分还能通过两道代码题,到了26年初,大家在代码题上卡壳的比例令人震惊,很多侯选人更是直接说用AI几个月了不怎么写代码了,很多code基础语法、概念都忘记了,这种情况我都会让用AI去查语法等等,但是能写出来的人非常少,最近甚至比例掉到我面试了10场只有1场过了代码的。 这让我不得不把面试流程调整成,先考代码题,再问经历。避免前面聊了很多但后面代码题没过浪费时间,毕竟我也要把时间放在其他工作的事情上,不能大把时间都全花在面试上。 很多侯选人都问我,为什么AI 模型公司,竟然还会考察代码题?甚至我们自家M模型能力就是coding agentic,甚至我就在做模型的代码能力训练。是的,我也大量vibe coding。 这个问题,其实我也想过很多遍。在回答这个问题之前,我想问另一个问题: AI coding能力进化速度这么快,大家都可以用AI写代码,那么还需要工程师什么? 我觉得需要的是,工程师的发现问题、定义问题、解决问题、做好为AI/其他兜底的能力,以及对生产环境/线上用户的敬畏精神,不管你用AI或不用AI,用什么工具、什么编程语言、什么框架。包括AI,始终只是工程师解决问题的工具。在没有AI之前,工程师不也是持续学习、持续迭代各种技术栈,让自己始终保持能用前沿+现有技术解决问题吗? 所以,我觉得尤其是在AI时代,拥抱AI但又同时保有自己工程师精神和能力的人,真的非常可贵,我想和这种人一起工作。 且,虽然AI coding能力飞速发展,但在前沿冲浪的vibe coder们想必都知道,还有非常多能力不足,部分编程语言/场景比如前端、数据分析、bash等等,AI能做到80-90分,另一些还只能做到60-70分,那么剩下的部分,不都是需要工程师兜底的吗? 回到一开始的问题,那么为什么我还要考代码题? 这是我认为在AI时代,考察工程师能力的仍然有效方法。所以我对侯选人说,我们越是AI公司,越知道,我们需要具备工程师能力和精神的人。 当然,道理不变,方式变了: 1. 面试前我都会把侯选人的简历给 agent,让agent基于侯选人的过往经历,出针对性的代码题,甚至是特殊情景的代码题。基本不再使用以往大家熟知的 leetcode算法题,这种题目基本靠背,现在再考察没啥意义。 2. 面试前我也会看一遍agent出的题目+另一个ai审题,确保题目本身逻辑没什么问题,且难度适中。 3. 面试时,我其实是和侯选人一起想题/做题的,会让侯选人先跟我说思路,再继续。如果侯选人没思路换道题再试。一些小概念、用法遗忘,允许用AI查(投屏给我看),把AI当查询工具,不允许直接AI代写。同时关注侯选人状态,及时调整细节和难度。不一定要完全写出来, 4. 代码不行就及时结束,减少浪费彼此的时间。毕竟现在代码题能过的比例太低了,面试场次增加了,只能每轮及时结束,减少浪费时间。 不过我相信,以上方法只是暂时的,因为AI能力还在进步,工程师技能的组合还在不断变化,所以之后还有更好的考察方式,也欢迎大家评论区讨论~ (btw,用AI久了,好久没手机打这么长字了,打完手酸,忽然惊觉自己的腱鞘炎这一年基本不犯了,这何尝不是一种AI带来的影响,可能会给传统输入硬件比如人体工学鼠标键盘等等带来冲击?🤔) 补充一个点: 据我最近个人面试情况,现在敢开始写题而不是放弃的人已经赢了另外三分之一的人了,不用AI作弊的就更少了,AI作弊其实蛮明显的,很多pattern非常明显,真的😏

45
佳心
4月前
「不同人用AI写出来的东西质量区别还是很大的,和当事人的代码功底有很深关系」,这个观察蛮有意思的,确实可以设置一些更难的更涉及复杂架构的场景题,让候选人解决问题,看候选人的实际运用AI的能力,以及,候选人是否有考虑AI产出项目的架构可扩展性、项目鲁棒性、后续可维护性、和如何消除团队协作带来的AI产出效果不一致等问题 //@WarmBear: AI时代再考拧螺丝意义不大了。就像有了高级语言的时候总不能去盯着编译后的汇编码觉得这不纯手工不古法吧。

感觉允许候选人用各种方法做,但要:
1. 说得出整体逻辑
2. 得到的代码质量(尤其是架构和范式)足够好。(亲测不同人用AI写出来的东西质量区别还是很大的,和当事人的代码功底有很深关系)

AI时代,最后干活还是会用AI的。考察候选人用AI的结果,比古法测试感觉更有价值。

佳心: 最近连续面试很多候选人,有一个普遍现象,大家的代码能力退化速度之快,让我感触非常深。 vibe coding普及一年以来,25年上半年的侯选人大部分还能通过两道代码题,到了26年初,大家在代码题上卡壳的比例令人震惊,很多侯选人更是直接说用AI几个月了不怎么写代码了,很多code基础语法、概念都忘记了,这种情况我都会让用AI去查语法等等,但是能写出来的人非常少,最近甚至比例掉到我面试了10场只有1场过了代码的。 这让我不得不把面试流程调整成,先考代码题,再问经历。避免前面聊了很多但后面代码题没过浪费时间,毕竟我也要把时间放在其他工作的事情上,不能大把时间都全花在面试上。 很多侯选人都问我,为什么AI 模型公司,竟然还会考察代码题?甚至我们自家M模型能力就是coding agentic,甚至我就在做模型的代码能力训练。是的,我也大量vibe coding。 这个问题,其实我也想过很多遍。在回答这个问题之前,我想问另一个问题: AI coding能力进化速度这么快,大家都可以用AI写代码,那么还需要工程师什么? 我觉得需要的是,工程师的发现问题、定义问题、解决问题、做好为AI/其他兜底的能力,以及对生产环境/线上用户的敬畏精神,不管你用AI或不用AI,用什么工具、什么编程语言、什么框架。包括AI,始终只是工程师解决问题的工具。在没有AI之前,工程师不也是持续学习、持续迭代各种技术栈,让自己始终保持能用前沿+现有技术解决问题吗? 所以,我觉得尤其是在AI时代,拥抱AI但又同时保有自己工程师精神和能力的人,真的非常可贵,我想和这种人一起工作。 且,虽然AI coding能力飞速发展,但在前沿冲浪的vibe coder们想必都知道,还有非常多能力不足,部分编程语言/场景比如前端、数据分析、bash等等,AI能做到80-90分,另一些还只能做到60-70分,那么剩下的部分,不都是需要工程师兜底的吗? 回到一开始的问题,那么为什么我还要考代码题? 这是我认为在AI时代,考察工程师能力的仍然有效方法。所以我对侯选人说,我们越是AI公司,越知道,我们需要具备工程师能力和精神的人。 当然,道理不变,方式变了: 1. 面试前我都会把侯选人的简历给 agent,让agent基于侯选人的过往经历,出针对性的代码题,甚至是特殊情景的代码题。基本不再使用以往大家熟知的 leetcode算法题,这种题目基本靠背,现在再考察没啥意义。 2. 面试前我也会看一遍agent出的题目+另一个ai审题,确保题目本身逻辑没什么问题,且难度适中。 3. 面试时,我其实是和侯选人一起想题/做题的,会让侯选人先跟我说思路,再继续。如果侯选人没思路换道题再试。一些小概念、用法遗忘,允许用AI查(投屏给我看),把AI当查询工具,不允许直接AI代写。同时关注侯选人状态,及时调整细节和难度。不一定要完全写出来, 4. 代码不行就及时结束,减少浪费彼此的时间。毕竟现在代码题能过的比例太低了,面试场次增加了,只能每轮及时结束,减少浪费时间。 不过我相信,以上方法只是暂时的,因为AI能力还在进步,工程师技能的组合还在不断变化,所以之后还有更好的考察方式,也欢迎大家评论区讨论~ (btw,用AI久了,好久没手机打这么长字了,打完手酸,忽然惊觉自己的腱鞘炎这一年基本不犯了,这何尝不是一种AI带来的影响,可能会给传统输入硬件比如人体工学鼠标键盘等等带来冲击?🤔) 补充一个点: 据我最近个人面试情况,现在敢开始写题而不是放弃的人已经赢了另外三分之一的人了,不用AI作弊的就更少了,AI作弊其实蛮明显的,很多pattern非常明显,真的😏

10
佳心
4月前
哈哈是的,但其实有个前提是,面试时间太短,上进心和靠谱程度,在一个小时之内,非常难以考察和衡量出来,当然这能在非代码环节即过往经历里有所体现,但现在AI时代,候选人让AI帮忙把经历美化的比例非常高,所以考代码也算是种兜底 //@咕咚同学: 可以让写代码,但这件事对最终录取的权重可以降低,对于招聘而言,代码能力已经不那么重要了,关注这个人的上进心,靠谱程度比关注代码有意义。

佳心: 最近连续面试很多候选人,有一个普遍现象,大家的代码能力退化速度之快,让我感触非常深。 vibe coding普及一年以来,25年上半年的侯选人大部分还能通过两道代码题,到了26年初,大家在代码题上卡壳的比例令人震惊,很多侯选人更是直接说用AI几个月了不怎么写代码了,很多code基础语法、概念都忘记了,这种情况我都会让用AI去查语法等等,但是能写出来的人非常少,最近甚至比例掉到我面试了10场只有1场过了代码的。 这让我不得不把面试流程调整成,先考代码题,再问经历。避免前面聊了很多但后面代码题没过浪费时间,毕竟我也要把时间放在其他工作的事情上,不能大把时间都全花在面试上。 很多侯选人都问我,为什么AI 模型公司,竟然还会考察代码题?甚至我们自家M模型能力就是coding agentic,甚至我就在做模型的代码能力训练。是的,我也大量vibe coding。 这个问题,其实我也想过很多遍。在回答这个问题之前,我想问另一个问题: AI coding能力进化速度这么快,大家都可以用AI写代码,那么还需要工程师什么? 我觉得需要的是,工程师的发现问题、定义问题、解决问题、做好为AI/其他兜底的能力,以及对生产环境/线上用户的敬畏精神,不管你用AI或不用AI,用什么工具、什么编程语言、什么框架。包括AI,始终只是工程师解决问题的工具。在没有AI之前,工程师不也是持续学习、持续迭代各种技术栈,让自己始终保持能用前沿+现有技术解决问题吗? 所以,我觉得尤其是在AI时代,拥抱AI但又同时保有自己工程师精神和能力的人,真的非常可贵,我想和这种人一起工作。 且,虽然AI coding能力飞速发展,但在前沿冲浪的vibe coder们想必都知道,还有非常多能力不足,部分编程语言/场景比如前端、数据分析、bash等等,AI能做到80-90分,另一些还只能做到60-70分,那么剩下的部分,不都是需要工程师兜底的吗? 回到一开始的问题,那么为什么我还要考代码题? 这是我认为在AI时代,考察工程师能力的仍然有效方法。所以我对侯选人说,我们越是AI公司,越知道,我们需要具备工程师能力和精神的人。 当然,道理不变,方式变了: 1. 面试前我都会把侯选人的简历给 agent,让agent基于侯选人的过往经历,出针对性的代码题,甚至是特殊情景的代码题。基本不再使用以往大家熟知的 leetcode算法题,这种题目基本靠背,现在再考察没啥意义。 2. 面试前我也会看一遍agent出的题目+另一个ai审题,确保题目本身逻辑没什么问题,且难度适中。 3. 面试时,我其实是和侯选人一起想题/做题的,会让侯选人先跟我说思路,再继续。如果侯选人没思路换道题再试。一些小概念、用法遗忘,允许用AI查(投屏给我看),把AI当查询工具,不允许直接AI代写。同时关注侯选人状态,及时调整细节和难度。不一定要完全写出来, 4. 代码不行就及时结束,减少浪费彼此的时间。毕竟现在代码题能过的比例太低了,面试场次增加了,只能每轮及时结束,减少浪费时间。 不过我相信,以上方法只是暂时的,因为AI能力还在进步,工程师技能的组合还在不断变化,所以之后还有更好的考察方式,也欢迎大家评论区讨论~ (btw,用AI久了,好久没手机打这么长字了,打完手酸,忽然惊觉自己的腱鞘炎这一年基本不犯了,这何尝不是一种AI带来的影响,可能会给传统输入硬件比如人体工学鼠标键盘等等带来冲击?🤔) 补充一个点: 据我最近个人面试情况,现在敢开始写题而不是放弃的人已经赢了另外三分之一的人了,不用AI作弊的就更少了,AI作弊其实蛮明显的,很多pattern非常明显,真的😏

01
佳心
4月前
哈哈,恰恰是因为我们太ai native了,以及深刻的知道,有足够学习能力、学习意愿和技术工程师素养的人,从不ai native到ai native可以有多快,那么工程师精神才尤其可贵 //@施耐泽: 不够ai native

佳心: 最近连续面试很多候选人,有一个普遍现象,大家的代码能力退化速度之快,让我感触非常深。 vibe coding普及一年以来,25年上半年的侯选人大部分还能通过两道代码题,到了26年初,大家在代码题上卡壳的比例令人震惊,很多侯选人更是直接说用AI几个月了不怎么写代码了,很多code基础语法、概念都忘记了,这种情况我都会让用AI去查语法等等,但是能写出来的人非常少,最近甚至比例掉到我面试了10场只有1场过了代码的。 这让我不得不把面试流程调整成,先考代码题,再问经历。避免前面聊了很多但后面代码题没过浪费时间,毕竟我也要把时间放在其他工作的事情上,不能大把时间都全花在面试上。 很多侯选人都问我,为什么AI 模型公司,竟然还会考察代码题?甚至我们自家M模型能力就是coding agentic,甚至我就在做模型的代码能力训练。是的,我也大量vibe coding。 这个问题,其实我也想过很多遍。在回答这个问题之前,我想问另一个问题: AI coding能力进化速度这么快,大家都可以用AI写代码,那么还需要工程师什么? 我觉得需要的是,工程师的发现问题、定义问题、解决问题、做好为AI/其他兜底的能力,以及对生产环境/线上用户的敬畏精神,不管你用AI或不用AI,用什么工具、什么编程语言、什么框架。包括AI,始终只是工程师解决问题的工具。在没有AI之前,工程师不也是持续学习、持续迭代各种技术栈,让自己始终保持能用前沿+现有技术解决问题吗? 所以,我觉得尤其是在AI时代,拥抱AI但又同时保有自己工程师精神和能力的人,真的非常可贵,我想和这种人一起工作。 且,虽然AI coding能力飞速发展,但在前沿冲浪的vibe coder们想必都知道,还有非常多能力不足,部分编程语言/场景比如前端、数据分析、bash等等,AI能做到80-90分,另一些还只能做到60-70分,那么剩下的部分,不都是需要工程师兜底的吗? 回到一开始的问题,那么为什么我还要考代码题? 这是我认为在AI时代,考察工程师能力的仍然有效方法。所以我对侯选人说,我们越是AI公司,越知道,我们需要具备工程师能力和精神的人。 当然,道理不变,方式变了: 1. 面试前我都会把侯选人的简历给 agent,让agent基于侯选人的过往经历,出针对性的代码题,甚至是特殊情景的代码题。基本不再使用以往大家熟知的 leetcode算法题,这种题目基本靠背,现在再考察没啥意义。 2. 面试前我也会看一遍agent出的题目+另一个ai审题,确保题目本身逻辑没什么问题,且难度适中。 3. 面试时,我其实是和侯选人一起想题/做题的,会让侯选人先跟我说思路,再继续。如果侯选人没思路换道题再试。一些小概念、用法遗忘,允许用AI查(投屏给我看),把AI当查询工具,不允许直接AI代写。同时关注侯选人状态,及时调整细节和难度。不一定要完全写出来, 4. 代码不行就及时结束,减少浪费彼此的时间。毕竟现在代码题能过的比例太低了,面试场次增加了,只能每轮及时结束,减少浪费时间。 不过我相信,以上方法只是暂时的,因为AI能力还在进步,工程师技能的组合还在不断变化,所以之后还有更好的考察方式,也欢迎大家评论区讨论~ (btw,用AI久了,好久没手机打这么长字了,打完手酸,忽然惊觉自己的腱鞘炎这一年基本不犯了,这何尝不是一种AI带来的影响,可能会给传统输入硬件比如人体工学鼠标键盘等等带来冲击?🤔) 补充一个点: 据我最近个人面试情况,现在敢开始写题而不是放弃的人已经赢了另外三分之一的人了,不用AI作弊的就更少了,AI作弊其实蛮明显的,很多pattern非常明显,真的😏

00
佳心
4月前
最近连续面试很多候选人,有一个普遍现象,大家的代码能力退化速度之快,让我感触非常深。

vibe coding普及一年以来,25年上半年的侯选人大部分还能通过两道代码题,到了26年初,大家在代码题上卡壳的比例令人震惊,很多侯选人更是直接说用AI几个月了不怎么写代码了,很多code基础语法、概念都忘记了,这种情况我都会让用AI去查语法等等,但是能写出来的人非常少,最近甚至比例掉到我面试了10场只有1场过了代码的。

这让我不得不把面试流程调整成,先考代码题,再问经历。避免前面聊了很多但后面代码题没过浪费时间,毕竟我也要把时间放在其他工作的事情上,不能大把时间都全花在面试上。

很多侯选人都问我,为什么AI 模型公司,竟然还会考察代码题?甚至我们自家M模型能力就是coding agentic,甚至我就在做模型的代码能力训练。是的,我也大量vibe coding。

这个问题,其实我也想过很多遍。在回答这个问题之前,我想问另一个问题:
AI coding能力进化速度这么快,大家都可以用AI写代码,那么还需要工程师什么?

我觉得需要的是,工程师的发现问题、定义问题、解决问题、做好为AI/其他兜底的能力,以及对生产环境/线上用户的敬畏精神,不管你用AI或不用AI,用什么工具、什么编程语言、什么框架。包括AI,始终只是工程师解决问题的工具。在没有AI之前,工程师不也是持续学习、持续迭代各种技术栈,让自己始终保持能用前沿+现有技术解决问题吗?

所以,我觉得尤其是在AI时代,拥抱AI但又同时保有自己工程师精神和能力的人,真的非常可贵,我想和这种人一起工作。

且,虽然AI coding能力飞速发展,但在前沿冲浪的vibe coder们想必都知道,还有非常多能力不足,部分编程语言/场景比如前端、数据分析、bash等等,AI能做到80-90分,另一些还只能做到60-70分,那么剩下的部分,不都是需要工程师兜底的吗?

回到一开始的问题,那么为什么我还要考代码题?
这是我认为在AI时代,考察工程师能力的仍然有效方法。所以我对侯选人说,我们越是AI公司,越知道,我们需要具备工程师能力和精神的人。

当然,道理不变,方式变了:
1. 面试前我都会把侯选人的简历给 agent,让agent基于侯选人的过往经历,出针对性的代码题,甚至是特殊情景的代码题。基本不再使用以往大家熟知的 leetcode算法题,这种题目基本靠背,现在再考察没啥意义。
2. 面试前我也会看一遍agent出的题目+另一个ai审题,确保题目本身逻辑没什么问题,且难度适中。
3. 面试时,我其实是和侯选人一起想题/做题的,会让侯选人先跟我说思路,再继续。如果侯选人没思路换道题再试。一些小概念、用法遗忘,允许用AI查(投屏给我看),把AI当查询工具,不允许直接AI代写。同时关注侯选人状态,及时调整细节和难度。不一定要完全写出来,
4. 代码不行就及时结束,减少浪费彼此的时间。毕竟现在代码题能过的比例太低了,面试场次增加了,只能每轮及时结束,减少浪费时间。

不过我相信,以上方法只是暂时的,因为AI能力还在进步,工程师技能的组合还在不断变化,所以之后还有更好的考察方式,也欢迎大家评论区讨论~

(btw,用AI久了,好久没手机打这么长字了,打完手酸,忽然惊觉自己的腱鞘炎这一年基本不犯了,这何尝不是一种AI带来的影响,可能会给传统输入硬件比如人体工学鼠标键盘等等带来冲击?🤔)

补充一个点:
据我最近个人面试情况,现在敢开始写题而不是放弃的人已经赢了另外三分之一的人了,不用AI作弊的就更少了,AI作弊其实蛮明显的,很多pattern非常明显,真的😏
4450
佳心
5月前
欢迎报名参赛~期待能见到一些有趣优秀的东西🚀
22
佳心
10月前
感谢 @艾逗笔 赠书。书一打开就是这句“做难而正确的事”,很触动,互勉🤝

想起三四月的时候,市面上MCP文章和教程几乎没有,MCP官网文档很多细节没说清楚,有些问题还是看了idoubi的公众号文章解惑。四月初的时候开发MCP和idoubi交流过很多,帮助非常大,当时也在mcp.so上合作了。

转眼间三四个月就出了这本MCP,果然是我认识的自律、高产、高质的idoubi。我想了一圈,确实在国内MCP这本书就只有 idoubi最适合写,因为他就是行业最贴近MCP前沿、最了解这段发展的人,读了书的核心第二章内容,果然没让我失望。

推荐想了解MCP的由来、原理、开发、应用的朋友可以去看看
33