[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-fable-5-claude-code-like-coworker-en":3,"article-related-fable-5-claude-code-like-coworker-en":30,"series-ai-agent-65872119-5c63-409f-b8f9-338096299326":79},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"65872119-5c63-409f-b8f9-338096299326","fable-5-claude-code-like-coworker-en","Fable 5 让 Claude Code 更像真同事","\u003Cp data-speakable=\"summary\">我拆了这篇测评，整理出一套把 Fable 5 用进 coding 和 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> 工作流的可复制模板。\u003C\u002Fp>\u003Cp>我用 \u003Ca href=\"\u002Fnews\u002Fclaude-code-cursor-copilot-2026-ai-agents-en\">Claude Code\u003C\u002Fa> 这类工具已经有一阵子了。说实话，前面几代模型都挺能聊，甚至挺会认错，但总有种别扭感。你把任务交给它，它先说“好”，再说“明白”，然后开始绕圈子。代码写得像是知道答案，真到要跑、要合并、要进主干的时候，又开始露怯。最烦的是那种“看起来很努力”的假动作，像是在配合你，而不是在解决问题。\u003C\u002Fp>\u003Cp>所以我看到这篇中文测评时，第一反应不是“又一篇 SOTA 通稿”，而是想看看它到底是不是把那种别扭感往前推了一步。原文来自知乎专栏《\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\">实测「神话」级模型 Fable 5：强者世界里的最强者 | AI 上新\u003C\u002Fa>》，作者是极客公园。它讲得很直白：\u003Ca href=\"\u002Ftag\u002Fanthropic\">Anthropic\u003C\u002Fa> 放出来的 Fable 5 不是完全裸奔的 Mythos 级模型，而是套了一层安全分类器，危险问题会回退到更保守的 Opus 4.8。这个设定本身就很有意思，因为它把“能力”和“可公开使用”硬拆开了。\u003C\u002Fp>\u003Cp>我先把结论放前面：这篇文章真正值得我抄的，不是“Fable 5 很强”这种废话，而是它看模型的方式。它不是只盯着 \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> 分数，而是盯着模型到底把什么能力放在第一位、它能不能在真实工程里被接受、以及它会不会把外部 harness 逼薄。这个视角对我们做 agent、做 coding workflow、做内部评测，都比单纯看榜单有用得多。\u003C\u002Fp>\u003Ch2>先看厂商把什么放第一位，别被榜单顺序骗了\u003C\u002Fh2>\u003Cblockquote>“看模型发布有哪些能力更新了，其实有个很取巧的办法：看厂商把哪个指标放在第一位。”\u003C\u002Fblockquote>\u003Cp>这句我很认同。厂商不是随便排顺序的，谁都知道首页最上面的那个数字最能打人。原文里，Fable 5 开头放的是 \u003Ca href=\"\u002Ftag\u002Fswe-bench\">SWE-bench\u003C\u002Fa> Pro 和 FrontierCode，前者是 coding，后者是 agent。这个顺序本身就已经说明问题了：Anthropic 想让你记住的，不是它会不会写几段花活，而是它能不能把复杂任务真的做完。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324307625-of8c.png\" alt=\"Fable 5 让 Claude Code 更像真同事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is：别把 benchmark 当成一个平面分数表，要把它当成产品策略说明书。SWE-bench Pro 这种题，更多是在测模型是否“听话”、是否能按题意补丁式修代码；而 FrontierCode 测的是更接近真实工程的东西，代码能不能被接受、能不能进主干、能不能通过项目自己的规范和审查。后者明显更接近我们日常碰到的脏活累活。\u003C\u002Fp>\u003Cp>我自己也踩过这个坑。以前我会拿一堆“解题题”去测模型，问它写个函数、补个 bug、改个脚本，觉得挺准。后来真把它丢到一个有历史包袱的仓库里，问题就来了。它不是不会写，而是不理解上下文，不知道哪里能动、哪里不能动，不知道改完之后谁会炸。那一刻我才明白，单点能力和工程能力根本不是一回事。\u003C\u002Fp>\u003Cp>怎么用这个思路？我建议你以后评估模型时，先问三个问题：\u003C\u002Fp>\u003Cul>\u003Cli>这个模型最想让我记住的能力是什么？\u003C\u002Fli>\u003Cli>这个能力是“答题”还是“交付”？\u003C\u002Fli>\u003Cli>它的分数是在实验室里好看，还是能进真实仓库？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你在做产品选型，这个顺序比“谁高了 2 分”重要得多。尤其是你要做 coding assistant、内部自动化、代码迁移、测试修复，这种场景里，能不能进主干比能不能把题做对更值钱。\u003C\u002Fp>\u003Ch2>FrontierCode 这种题，才像真工程，不像考试\u003C\u002Fh2>\u003Cp>文章里最打动我的，其实是 FrontierCode 这个基准。它不是让模型做一套“标准答案题”，而是从真实开源项目里抽任务，要求结果能被接受、能被合并。原文提到，任务来自 Celery、Mattermost 这些项目，而且专业开发者会花四十多个小时打磨一道题。这个信息很关键，因为它说明题目本身就带着工程世界的摩擦。\u003C\u002Fp>\u003Cp>What this actually means is：模型不只要“会写”，还要“写得像能活下去”。真实项目里，正确答案往往不是唯一答案，甚至不是最优雅答案，而是那个能过 review、能符合 repo 习惯、能不把别的模块带崩的答案。这个差别太大了。你在 LeetCode 上的满分，到了真实仓库里可能连 PR 都开不出来。\u003C\u002Fp>\u003Cp>原文还提到一个 Stripe 的案例：在一个 5000 万行 Ruby 代码库里，Fable 5 用一天完成了原本要一个团队干两个多月的迁移。这个说法我不会替它背书成绝对事实，但它至少表达了一个方向：模型正在从“帮你写代码”变成“帮你搬家”。这两个动作的难度不是一个量级。\u003C\u002Fp>\u003Cp>我自己做过代码迁移，最痛的从来不是语法转换，而是边角料：老接口、历史注释、隐式约定、测试夹具、奇怪的命名、没人敢删的兼容分支。你让模型只写新代码，它往往还行；你让它在旧代码上动刀，它就开始犯糊涂。FrontierCode 这种基准的价值就在这儿，它逼模型面对真实工程的脏和乱。\u003C\u002Fp>\u003Cp>如果你想把这个思路用到自己的团队里，我建议你把评测题改成这三类：\u003C\u002Fp>\u003Cul>\u003Cli>单文件修复：看它能不能补一个明确 bug。\u003C\u002Fli>\u003Cli>跨文件改动：看它能不能理解依赖关系。\u003C\u002Fli>\u003Cli>真实仓库 PR：看它能不能接受 review 约束。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这三层一层比一层接近真实价值。只测第一层，容易高估模型；只看榜单，不看 PR，基本等于自我安慰。\u003C\u002Fp>\u003Ch2>拍照直接解题，比转 LaTeX 更像真实使用\u003C\u002Fh2>\u003Cp>我很喜欢原文在数学题上的测法。作者故意没走那种“先把 PDF 转 LaTeX，再喂给模型”的老路，而是直接拍照截图丢进去，让模型自己读图解题。这个选择很对，因为现实里没人会为了问一道题先花半小时做格式清洗。那不是 AI 辅助，那是给 AI 打工。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324307856-zr79.png\" alt=\"Fable 5 让 Claude Code 更像真同事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>原文里说，Fable 5 能直接看懂高考数学卷里的几何图、辅助线，然后一题一题解下去，最后拿到 150 满分。这里我不打算把这个结果神化，但我要承认，这种“直接看图并推理”的体验，确实比单纯文本问答更接近我们未来会用到的方式。\u003C\u002Fp>\u003Cp>What this actually means is：多模态能力真正有价值的地方，不是“它能看图”，而是“它能少一步”。少一步就意味着少一个人工转换层，少一个出错点，少一个让人放弃的门槛。很多模型看起来都能处理图片，但一旦你真的把原始截图、白板照、票据、UI 截图扔进去，马上就露馅。不是它不聪明，是它没把输入世界当成真实世界。\u003C\u002Fp>\u003Cp>我以前做内部知识库问答时，最烦的就是用户总要上传乱七八糟的截图。传统做法是 OCR、清洗、再总结，链条长得离谱。最后你得到一个看起来很“工程化”的流程，但用户体验烂透了。Fable 5 这类模型给我的启发是，别急着把输入格式标准化到过头，先看看模型能不能直接吃原始材料。\u003C\u002Fp>\u003Cp>如果你要落地，可以这么做：\u003C\u002Fp>\u003Cul>\u003Cli>保留原图输入，不要默认转文字。\u003C\u002Fli>\u003Cli>让模型先解释它看到了什么，再开始推理。\u003C\u002Fli>\u003Cli>把“读图正确率”和“最终答案正确率”分开记。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这样你才能知道问题出在感知层，还是出在推理层。很多团队把这俩混在一起，最后根本不知道模型到底差在哪。\u003C\u002Fp>\u003Ch2>Agent 真正的分水岭，不是会不会调用工具，而是会不会自己收尾\u003C\u002Fh2>\u003Cp>原文里对 Fable 5 的 Agent 体感描述得很到位：以前的模型像聪明实习生，要你拆好任务，一步一步喂；它更像一个能自己拆任务、自己调子代理、自己验证结果、自己处理异常的人。这个比喻虽然有点夸张，但方向是对的。Agent 的核心不是“能不能调用工具”，而是“能不能把一件事从头做到尾”。\u003C\u002Fp>\u003Cp>What this actually means is：真正有价值的不是某一次工具调用，而是长链路执行能力。模型要能记住目标、分解任务、在中间卡住时自救、发现失败后改策略、最后把结果收回来。这里面任何一个环节掉链子，用户就得重新接管。只要你得接管，那它就还没从“演示”进入“工作”。\u003C\u002Fp>\u003Cp>文章引用了 Ethan Mollick 和 Simon Willison 的体验，这两个人都不是来凑热闹的。Mollick 让模型自主构建等时线地图，涉及多个子代理、上千条交通数据、连续十个小时；Willison 则说挑战在于找到它做不成的任务。这个方向和我自己的体感一致：模型越强，你越少需要盯着它每一步，但你越需要给它一个清楚的边界。\u003C\u002Fp>\u003Cp>我自己也遇到过类似情况。以前模型一旦中间出错，我就得人工插手修正。到了更强的模型，问题变成了另一种：它未必一开始就错，但它会自己绕开一些你本来希望它处理的细节，最后交给你一个“差不多”的结果。这个时候，最重要的不是再加提示词，而是加验收标准。\u003C\u002Fp>\u003Cp>如果你要把 Agent 用起来，我建议你只盯四件事：\u003C\u002Fp>\u003Cul>\u003Cli>它能不能自己拆任务。\u003C\u002Fli>\u003Cli>它能不能自己检查中间结果。\u003C\u002Fli>\u003Cli>它能不能在失败时换路。\u003C\u002Fli>\u003Cli>它能不能在结束时给出可交付物。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这四件事，比“会不会多轮对话”重要得多。多轮对话只是聊天，收尾能力才是工作。\u003C\u002Fp>\u003Ch2>审美没那么强，说明它把筹码全压在 coding 和 agent 上了\u003C\u002Fh2>\u003Cp>原文对审美生成部分是失望的，我觉得这个判断挺诚实。作者测了金门大桥和鹈鹕 SVG，Fable 5 和 GPT-5.5 都没给出特别惊艳的结果。这个结果不算意外，但它有个很重要的信号：这代模型的优化重心，明显不是设计和创意，而是 coding 和 agent。\u003C\u002Fp>\u003Cp>What this actually means is：厂商在做取舍。模型能力不是均匀增长的，它会朝最容易商业化的方向倾斜。coding 能直接卖开发者，agent 能直接卖生产力，审美和创意虽然也能卖，但离“立刻证明 ROI”总差一口气。Anthropic 这次的选择很冷静，也很现实。\u003C\u002Fp>\u003Cp>这对我们做产品的人其实是个提醒。别幻想一个模型能同时把所有事都做成天花板。你要先认清它的强项，再把它塞进对的工作流。比如你做设计辅助，就别指望它替代审美判断；你做工程自动化，就别浪费时间拿它去拼视觉效果。能力分布不均，才是常态。\u003C\u002Fp>\u003Cp>我自己最怕的就是团队拿一个强模型去做不该它做的事，然后得出“AI 不行”的结论。不是 AI 不行，是你把它放错了地方。像 Fable 5 这种模型，明显更适合放在代码迁移、测试修复、脚本生成、研究助理、长链路任务协调这些地方。\u003C\u002Fp>\u003Cp>如果你要做内部选型，直接按场景分桶就行：\u003C\u002Fp>\u003Cul>\u003Cli>高价值工程任务：优先 coding 和 agent。\u003C\u002Fli>\u003Cli>创意产出任务：单独评估审美，不要混着看。\u003C\u002Fli>\u003Cli>多模态输入任务：先测原图理解，再测结果质量。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这样你会少很多幻觉式预期，也少很多无意义争论。\u003C\u002Fp>\u003Ch2>安全分类器不是纯护栏，它也是产品边界\u003C\u002Fh2>\u003Cp>原文里我最在意的另一段，是关于 Anthropic 的安全分类器。官方说法很正面：因为 Mythos 级别能力太强，在网络安全、生物这些高危领域可能被滥用，所以加了一道分类器，遇到危险问题就回退给更保守的 Opus 4.8。听起来像责任感，但作者也点出来了，公开版本里一些星号标注的高危 benchmark 分数会被压下去。\u003C\u002Fp>\u003Cp>What this actually means is：护栏不只是安全机制，它也是能力分层和市场控制。最强的能力被锁在内部，公开版只给你一部分。对用户来说，这当然会让体验变差，甚至会误伤正常问题；但对厂商来说，这既能控制风险，也能控制竞争对手能看到多少。\u003C\u002Fp>\u003Cp>我不想把这件事讲得太阴谋论，但也没必要装天真。任何一个大模型厂商，都会同时考虑安全、成本、品牌、竞争壁垒。护栏不是纯道德，也不是纯商业，而是两者的混合物。你把它看成单一动机，都会看偏。\u003C\u002Fp>\u003Cp>我自己碰到过类似的“安全回退”问题。模型明明知道怎么答，但一碰到某些关键词就开始装傻，或者切换到很保守的模板化回答。对普通用户来说，这当然是烦的；但对平台来说，这是可控的。问题在于，护栏一旦过重，就会把正常工作流也一起挡掉。\u003C\u002Fp>\u003Cp>所以如果你在做企业内部部署，我建议你别只问“有没有安全机制”，还要问：\u003C\u002Fp>\u003Cul>\u003Cli>误判率有多高？\u003C\u002Fli>\u003Cli>回退后能力损失多少？\u003C\u002Fli>\u003Cli>能不能区分高风险和正常专业问题？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这三个问题比一句“我们有安全层”有用得多。否则你最后拿到的只是一个更礼貌的模型，不是一个更好用的模型。\u003C\u002Fp>\u003Ch2>模型越强，harness 越该变薄，不然你是在给弱点续命\u003C\u002Fh2>\u003Cp>文章最后提到一个我特别喜欢的点：harness 工程。原文引用了 \u003Ca href=\"\u002Ftag\u002Fclaude-code\">Claude Code\u003C\u002Fa> 工程师 Boris Cherny 的说法，未来的 Claude Code 可能只需要 100 行代码。这个说法听上去反直觉，但逻辑很清楚：模型越弱，你越要靠外部框架补洞；模型越强，框架就应该越薄，因为很多原来靠工程硬拧的事，模型自己就能想明白。\u003C\u002Fp>\u003Cp>What this actually means is：harness 不是越厚越好，厚到一定程度，你其实是在替模型的短板做永久性装修。短期看很稳，长期看很蠢。因为一旦模型能力上来，旧 harness 反而会拖慢它，限制它，甚至把它的能力压回去。\u003C\u002Fp>\u003Cp>我自己见过太多“为了兜底而兜底”的工程。每一步都加校验，每一步都加重试，每一步都加规则，最后整个系统像一辆装了五层防撞梁的车，安全是安全了，但根本开不快。模型升级以后，最该做的不是继续加壳，而是敢不敢把壳拆掉一层。\u003C\u002Fp>\u003Cp>这也是我觉得这篇测评最值钱的地方。它不是只告诉你“Fable 5 很强”，而是在暗示一个工程判断：如果模型已经能更少 token 做更复杂的事，那你围着它写的那些补丁、脚手架、提示词胶带，就该重新审视了。很多时候，真正该优化的不是 prompt，而是你那套为了补弱模型而搭出来的旧流程。\u003C\u002Fp>\u003Cp>如果你想把这个判断落地，我建议你做一次 harness 清点：\u003C\u002Fp>\u003Cul>\u003Cli>哪些逻辑是为了兜模型错误？\u003C\u002Fli>\u003Cli>哪些逻辑是业务必须？\u003C\u002Fli>\u003Cli>哪些逻辑其实已经可以删掉？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你会惊讶地发现，很多“不可或缺”的步骤，其实只是历史遗留。模型一强，这些东西就开始显得笨重。\u003C\u002Fp>\u003Ch2>你可以直接拿去用的评测模板\u003C\u002Fh2>\u003Cp>下面这套模板，是我按这篇测评的思路整理出来的。你可以拿它去测自己的模型、自己的 agent、或者你准备接入的第三方 API。重点不是得出一个漂亮分数，而是看它到底适不适合真实工作流。\u003C\u002Fp>\u003Cpre>\u003Ccode># 模型实测模板：coding + agent + 多模态输入 + harness 评估\n\n## 1. 先定义你最在意的能力\n- coding: 单文件修复 \u002F 跨文件改动 \u002F PR 可合并性\n- agent: 任务拆解 \u002F 工具调用 \u002F 中间自检 \u002F 失败恢复 \u002F 最终交付\n- multimodal: 截图理解 \u002F 图表理解 \u002F 手写或扫描件理解\n- safety: 误拦截率 \u002F 回退后的能力损失 \u002F 正常专业问题是否被误伤\n\n## 2. 给模型三个层级的任务\n### Level A: 题目级\n- 单文件 bug fix\n- 简单函数补全\n- 单张截图问答\n\n### Level B: 仓库级\n- 多文件重构\n- 代码风格对齐\n- 测试补齐\n- 依赖关系修改\n\n### Level C: 交付级\n- 真实 PR\n- 真实 review 约束\n- 真实上线前检查\n- 真实长链路 agent 任务\n\n## 3. 每个任务都记录这些指标\n- 是否一次完成\n- 是否需要人工介入\n- 中间步骤是否自洽\n- 最终结果是否能被接受\n- 修正成本有多高\n- 是否因为安全机制被错误回退\n\n## 4. 评测提示词模板\n你是一个资深工程助手。\n\n目标：{写清楚最终目标}\n\n约束：\n- 只修改必要部分\n- 保持现有架构和命名风格\n- 先解释你的计划，再执行\n- 每一步完成后自检\n- 如果失败，说明原因并换方案\n\n输入：\n{原始截图 \u002F 仓库片段 \u002F 任务描述}\n\n输出格式：\n1. 任务理解\n2. 执行计划\n3. 实际修改\n4. 自检结果\n5. 风险和未解决项\n\n## 5. harness 清点清单\n- 这个重试逻辑还必要吗？\n- 这个规则是业务规则还是模型补丁？\n- 这个分类器会不会误伤正常问题？\n- 这个工作流能不能在模型更强时缩短一半？\n\n## 6. 最终判断\n- 适合做：{写场景}\n- 不适合做：{写场景}\n- 需要人工兜底的环节：{写场景}\n- 可以删掉的工程层：{写场景}\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>这套模板我建议你真的去跑一次。别只在小样本上试，尽量放进你们真实的 repo、真实的文档、真实的截图、真实的脏数据里。模型在演示环境里看着都挺像回事，只有碰到真实输入，优缺点才会露出来。\u003C\u002Fp>\u003Cp>最后我想补一句：这篇原文最有价值的地方，不是替 Fable 5 站台，而是把“强模型”到底意味着什么讲清楚了。它意味着更少的外部补丁、更长的自主执行、更接近真实工程的交付，以及更高的使用门槛。你要是只看热闹，会觉得又是一次发布会；你要是拿它来改自己的工作流，就会发现很多旧假设都该翻新了。\u003C\u002Fp>\u003Cp>我这里的整理是基于原文观点做的二次拆解和模板化，不是 Anthropic 官方材料本身。原始来源是知乎专栏这篇文章：\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\">https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\u003C\u002Fa>。如果你要追溯具体 benchmark、作者体验和配图，还是应该回到原文看完整上下文。\u003C\u002Fp>","我拆了这篇测评，整理出一套把 Fable 5 用进 coding 和 agent 工作流的可复制模板。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324307625-of8c.png","ai-agent","en","40cd5d8d-c9fc-4883-b978-f7f757c14488",[17,18,19,20,21],"Claude","agent","coding","harness","benchmark",[23,24,25],"别只看 benchmark，先看模型把什么能力放在第一位","真正值钱的是长链路 agent 和真实工程接入能力","模型越强，外部 harness 越该变薄",0,"2026-06-13T04:18:01.203421+00:00","2026-06-13T04:18:01.199+00:00","a9bee732-b07c-4e5b-a0e6-3048577e32a7",{"tags":31,"relatedLang":38,"relatedPosts":42},[32,33,34,35,36],{"name":19,"slug":19},{"name":18,"slug":18},{"name":20,"slug":20},{"name":21,"slug":21},{"name":17,"slug":37},"claude",{"id":15,"slug":39,"title":40,"language":41},"fable-5-claude-code-like-coworker-zh","Fable 5 讓 Claude Code 更像真同事","zh",[43,49,55,61,67,73],{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"50d67ff2-698e-4ac1-9b5f-9233550bdc00","aspire-microsoft-agent-framework-app-graph-en","Aspire ties Microsoft Agent Framework into one app graph","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781353081127-r8l2.png","2026-06-13T12:17:30.899796+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"9abeb68f-5750-43b5-baff-d454f58068f0","fine-tuning-methods-sft-lora-dpo-rlhf-grpo-en","Fine-Tuning Methods: SFT, LoRA, DPO, RLHF, GRPO","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781262188430-9te1.png","2026-06-12T11:02:33.676197+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"9ff578af-a9fb-4149-9a25-3557abdca7c0","mistral-vibe-cli-agent-still-matters-en","Mistral Vibe proves the CLI agent still matters","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781248682129-6oah.png","2026-06-12T07:17:22.149012+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"c9aeda0b-adb4-437a-a88c-19a2c00df1c1","kimi-code-cli-setup-pricing-workflow-guide-en","Kimi Code CLI setup, pricing, and workflow guide","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781161392221-tdcq.png","2026-06-11T07:02:28.34709+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"1a9879eb-d0c9-44f4-9faf-8bc25dab2016","windows-agent-runtime-not-human-desktop-en","Windows is becoming an agent runtime, not a human desktop","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781147875233-ah2r.png","2026-06-11T03:17:17.770392+00:00",{"id":74,"slug":75,"title":76,"cover_image":77,"image_url":77,"created_at":78,"category":13},"c0a961a9-23ca-49c4-a384-8bb5195b82e6","grok-updates-change-how-i-code-en","5 Grok updates that change how I code","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781126304211-brf6.png","2026-06-10T21:17:56.942433+00:00",[80,85,90,95,100,105,110,115,120,125],{"id":81,"slug":82,"title":83,"created_at":84},"03db8de8-8dc2-4ac1-9cf7-898782efbb1f","anthropic-claude-ai-agent-task-automation-en","Anthropic's Claude AI Agent: A New Era of Task Automation","2026-03-25T16:25:06.513026+00:00",{"id":86,"slug":87,"title":88,"created_at":89},"045d1abc-190d-4594-8c95-91e2a26f0c5a","googles-2026-ai-agent-report-decoded-en","Google’s 2026 AI Agent Report, Decoded","2026-03-26T11:15:23.046616+00:00",{"id":91,"slug":92,"title":93,"created_at":94},"e64aba21-254b-4f93-aa21-837484bb52ec","kimi-k25-review-stronger-still-not-legend-en","Kimi K2.5 review: stronger, still not a legend","2026-03-27T07:15:55.385951+00:00",{"id":96,"slug":97,"title":98,"created_at":99},"30dfb781-a1b2-4add-aebe-b3df40247c37","claude-code-controls-mac-desktop-en","Claude Code now controls your Mac desktop","2026-03-28T03:01:59.384091+00:00",{"id":101,"slug":102,"title":103,"created_at":104},"254405b6-7833-4800-8e13-f5196deefbe6","cloudflare-100x-faster-ai-agent-sandbox-en","Cloudflare’s 100x Faster AI Agent Sandbox","2026-03-28T03:09:44.356437+00:00",{"id":106,"slug":107,"title":108,"created_at":109},"04f29b7f-9b91-4306-89a7-97d725e6e1ba","openai-backs-isara-agent-swarm-bet-en","OpenAI backs Isara’s agent-swarm bet","2026-03-28T03:15:27.849766+00:00",{"id":111,"slug":112,"title":113,"created_at":114},"3b0bf479-e4ae-4703-9666-721a7e0cdb91","openai-plan-automated-ai-researcher-en","OpenAI’s plan for an automated AI researcher","2026-03-28T03:17:42.312819+00:00",{"id":116,"slug":117,"title":118,"created_at":119},"fe91bce0-b85d-4efa-a207-24ae9939c29f","harness-engineering-ai-agent-reliability-2026","Harness Engineering: From Bridle to Operating System, The Missing Link in AI Agent Reliability","2026-03-31T06:36:55.648751+00:00",{"id":121,"slug":122,"title":123,"created_at":124},"7a09007d-820f-43b3-8607-8ad1bfcb94c8","mcp-explained-from-prompts-to-production-en","MCP Explained: From Prompts to Production","2026-04-01T09:24:40.089177+00:00",{"id":126,"slug":127,"title":128,"created_at":129},"116d5ee9-a4f1-4b5a-aac5-5d035dd22bbe","amazon-bedrock-agents-multi-agent-workflows-en","Amazon Bedrock Agents Gets Multi-Agent Workflows","2026-04-01T09:30:30.197685+00:00"]