在一些前沿模型突然变得不可用的时刻，我们选择相信另一条路：前沿智能不应只属于少数人，也不应被少数规则随时收回。它应该开放、可用、可构建，并服务于每一位开发者。
GLM-5.2 是智谱迄今能力最强的开源模型，支持真正可用的 1M 上下文，并在长程任务中继续保持领先。它也依旧是我们心中最强的国产 Coding 模型。
今晚 5:21，GLM-5.2 将面向 GLM Coding Plan 全量用户开放，覆盖 Lite / Pro / Max / 团队版。
GLM-5.2 API 将于下周上线，模型下周正式开源，遵循 MIT 协议。
mp.weixin.qq.com
trusted: true 声明brew bundle 默认并行安装;有用户称这是"多年来最顺畅的一次 brew upgrade"ask 确认模式(可用 --yes 或 HOMEBREW_NO_ASK=1 关闭);auto_updates cask 现在也会被 brew upgrade 更新(可用 HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS=1 恢复旧行为)
6.0.0
https://cooper-x-oak.github.io/ai-haitao-guide/#quiz
是的，非常的AI，但我并不执着于完美
而是思考，决策，喝杯水的功夫
Fable-5 就做好了一切
只给10分钟的注意力
它的产出胜过于它的完美
不完美的是我的品味
AI的语感，产品的打磨
这些都会持续迭代，水涨船高
我现在完全不做工具了
先做出来成功的市场，再按市场需求来 build 而不是反过来
当市场工作做成功了，那你随时可以成为有市场的builder
但如果只是builder，我不知道什么时候才能突破市场困境
🤔 靠运气还是靠天赋？
我就是这么想的了，现在
我已经一个工具都不做了
想好要怎么做，直接agent去实现
这是我最擅长的部分
是的，你很喜欢我的想法我和的demo，BUT
我不再需要花90%的时间让他看起来性感
做出一个 产品 balabla
想办法去精准的切入适合的市场
就是这样，这就是我在做的事情
《人月神话》讲的是一个很朴素的道理：软件开发不是简单堆人就能变快。
一个项目延期了，你再加十个人进来，项目不一定更快，反而可能更慢。因为新人要学习背景，老成员要花时间解释，大家还要开会、对齐、协调。人越多，沟通越复杂。
到了今天，很多人会说：这不是过去的问题吗？现在有 AI Agent 了。一个工程师可以同时让好几个 Agent 写代码、改 bug、补测试。是不是 Brooks 的"人月神话"已经过时了？
答案是：没有过时。只是"人月神话"变成了"Agent 月神话"。
过去的问题是：人多了，沟通成本爆炸。
现在的问题是：Agent 多了，上下文、验证、合并、理解成本爆炸。
Agent 确实可以让代码生成变快，但它没有让软件开发的本质困难消失。它只是把困难从"写代码"转移到了"知道该写什么、判断写得对不对、以及团队是否真的理解这段代码"。
Brooks 的经典说法是：
向一个已经延期的软件项目增加人手，只会让它更晚。
在 Agent 时代，可以改写成：
向一个已经混乱的软件项目增加更多 Agent，只会让它更快地变得更混乱。
这听起来有点夸张，但很符合实际。
因为 Agent 并不是一个真正理解项目历史、业务目标和架构取舍的团队成员。它更像一个能力很强、速度很快、但记忆很短的临时工。
你让它改一个模块，它可能能改。
你让三个 Agent 同时改三个模块，它们可能各自都觉得自己做对了。
但最后你会发现：
一个 Agent 改了接口，另一个 Agent 还在用旧接口；一个 Agent 加了新逻辑，另一个 Agent 写的测试没有覆盖；一个 Agent 为了保险加了大量防御性代码，另一个 Agent 又在别处重复实现了一遍。
于是，过去的人际沟通成本，变成了今天的 Agent 编排成本。
以前你要协调人。
现在你要协调上下文、提示词、分支、测试、PR、代码风格、架构边界，以及 Agent 生成出来的一堆"看起来差不多能用"的东西。
《人月神话》里最重要的一句话，其实不是"加人会变慢"，而是：
软件开发没有银弹。
意思是：没有一种工具或方法，可以一次性消灭软件开发的本质困难。
Brooks 区分了两种复杂度：
一种是 偶然复杂度。比如语法麻烦、样板代码多、工具难用、语言啰嗦。这些东西很烦，但不是问题本身。
另一种是 本质复杂度。比如需求到底是什么，系统边界怎么划分，数据模型怎么设计，安全性怎么保证，出了问题谁负责，长期维护会不会崩。这些才是软件真正难的地方。
Agent 最擅长处理的是第一类：偶然复杂度。
它可以帮你写样板代码，可以快速生成 CRUD，可以补测试，可以把 Python 翻成 Go，可以读报错然后猜一个修复方案。
所以，写代码这件事变便宜了。
但问题也来了：写代码变便宜，不等于交付可靠软件变便宜。
过去，代码写得慢，所以大家天然会克制一点。现在，代码生成太快了，反而容易生成太多。
于是软件开发的新瓶颈变成了：
这段代码真的符合需求吗？它在边界情况下会不会出错？它安全吗？它和旧系统兼容吗？团队里有人真正理解它吗？三个月后还能维护吗？
Agent 能替你打字，但不能替你承担判断。
这就是 Agent 时代对"没有银弹"的最好证明：AI 消灭了很多写代码的痛苦，却把真正困难的部分暴露得更清楚了。
Agent 时代最核心的变化可以总结成一句话：
生成免费，理解昂贵。
以前，一个 junior 工程师写代码比较慢，senior 工程师审查代码通常还来得及。
现在不一样了。一个人加几个 Agent，一天可以生成大量代码、PR、测试和文档。可是 senior 的理解速度没有同步提升。
代码可以十倍速生成，但人类不能十倍速理解。
于是 code review 的性质变了。
过去 code review 是质量闸门。现在 code review 很容易变成吞吐量瓶颈。
更危险的是，有些代码看起来很正常，测试也可能过，但团队没有人真正理解它为什么这么写。这就形成了一种新的债务：理解债。
技术债是代码本身的问题，比如结构乱、重复多、耦合高。
理解债是人与代码之间的关系出了问题：代码在仓库里，但没有人真正知道它在做什么。
Agent 写出来的代码越多，理解债可能累积得越快。
这也是为什么"看起来能跑"不够。一个系统能跑，只是第一步。真正困难的是它能不能被解释、被验证、被修改、被长期维护。
人类工程师加入一个项目后，会慢慢形成一种理解：这个系统为什么这么设计，哪些地方不能乱动，哪些坑以前踩过，哪些代码看起来奇怪但其实有历史原因。
这种理解不是代码本身，而是脑子里的"项目理论"。
Agent 最大的问题之一，就是它没有稳定持久的项目理论。
每次你打开一个新 session，它都要重新读上下文。你给它多少，它就理解多少。你没给它的，它只能猜。上下文太长，它可能漏。上下文太短，它一定会缺信息。
所以 Agent 很容易出现一种情况：
它能读懂局部代码，但不理解整体系统；它能修眼前 bug，但不知道这个修法会不会破坏长期架构；它能生成一个方案，但不知道这个方案是否符合团队过去的设计取舍。
这就是为什么 Agent 时代反而更需要 spec engineering 和 context engineering。
说白了，就是不能只对 Agent 说：
"帮我实现这个功能。"
而是要告诉它：
这个功能为什么存在；它不能破坏哪些约束；它要遵守什么架构；哪些旧逻辑必须兼容；什么情况才算完成；哪些事情不要做。
过去，很多设计意图藏在人脑里。
现在，为了让 Agent 不乱猜，我们必须把这些意图写出来、版本化、结构化，变成 Agent 可以读取的上下文。
Brooks 曾经提出过一个想法：好的软件系统需要概念完整性。也就是说，系统应该像是由一个清晰的头脑设计出来的，而不是一群人各写一块拼起来。
他还提出"外科手术团队"模式：一个主程序员负责核心判断，其他人提供支持。
在 Agent 时代，这个模式反而更像现实了。
一个优秀工程师，加上一组 Agent，就像新的外科手术团队。
人类负责：
判断方向；控制范围；设计边界；决定取舍；审查结果；维护系统整体一致性。
Agent 负责：
快速生成代码；尝试实现方案；补测试；重构局部代码；查找明显问题；完成重复性工作。
所以，Agent 并没有取消"主程序员"的角色。
恰恰相反，它让主程序员变得更重要。
因为当代码生成变快以后，最稀缺的能力不再是"会不会写"，而是"知不知道该不该写"。
很多人用 Agent 的体验是这样的：
前 70% 非常爽。
你描述一个需求，Agent 很快生成一个 demo。页面有了，接口有了，数据流也差不多通了。看起来进展神速。
但后面 30% 开始变慢。
边界情况不对。权限没处理好。错误提示很粗糙。日志不完整。安全问题没考虑。测试覆盖不到关键路径。和旧系统一接就出问题。部署环境和本地环境行为不一致。
这就是 Agent 时代的"70% 诱惑"。
AI 很擅长把你快速带到"看起来差不多了"的位置，但从"差不多能跑"到"可以放心上线"，中间还有很长一段路。
对于经验不足的人来说，70% 会显得像奇迹。
对于经验丰富的人来说，最后 30% 才是真正的工程。
更麻烦的是，如果前 70% 是 Agent 用一种你没有完全理解的方式写出来的，那么最后 30% 可能比你自己从头写还难补。
因为你不仅要修问题，还要先搞懂它到底写了什么。
Brooks 还讲过一个现象：人做第二个系统时，最容易过度设计。
第一个系统太克制，很多想法没来得及做。到了第二个系统，就想把所有"早就想加的东西"都塞进去，结果系统变得臃肿复杂。
Agent 时代，这个问题被放大了。
因为以前加功能有成本，工程师会想一想值不值得。
现在你只要打一行 prompt：
"顺便加个导出功能。" "顺便支持多语言。" "顺便做个缓存。" "顺便把权限系统也补一下。" "顺便重构一下。"
Agent 可能真的会去做。
问题是，代码生成免费，不代表复杂度免费。
每一个"顺便"，都会增加未来维护成本。每一个额外分支，都会增加测试成本。每一个没经过认真设计的功能，都会增加理解成本。
所以 Agent 时代最重要的能力之一，是会说"不"。
不是所有能生成的代码都应该进入系统。
Agent 对不同团队的效果差异会很大。
一个本来架构清晰、测试完善、自动化流程成熟、模块边界明确的团队，用 Agent 可能会明显提速。
因为 Agent 有清楚的轨道可以跑。它生成的代码能被测试约束，被规范约束，被 review 约束。
但一个本来就混乱的团队，用 Agent 可能只是更快地产生混乱。
需求不清楚，Agent 会猜。架构不清楚，Agent 会绕。测试不完善，Agent 的错误更难发现。review 走形式，AI 代码更容易混进去。团队没有共同理解，代码库会越来越像拼贴画。
所以 AI 不是自动提升团队水平的魔法。
它更像放大器。
好流程会被放大。坏流程也会被放大。
这也是为什么，在引入 Agent 之前，团队反而更应该重视基础工程能力：测试、文档、规范、架构边界、CI/CD、代码审查、可观测性。
否则 Agent 只会帮你更快地撞墙。
过去，我们常用"人月"来估算项目。
一个人做一个月，就是一个人月。十个人做一个月，好像就是十个人月。
Brooks 早就指出，这种算法很危险。因为软件工作不能像搬砖一样线性叠加。
到了 Agent 时代，"人月"这个单位更不够用了。
因为一个工程师可能同时指挥多个 Agent，产出代码的速度不再和人数直接对应。
但这不代表管理更简单了。
真正该衡量的，不再是生成了多少代码、合了多少 PR、完成了多少任务卡。
更重要的是：
这些代码有多少被返工？review 需要多久？缺陷逃逸到线上多少？新代码两周内被改掉多少？团队是否理解核心逻辑？系统复杂度是下降了，还是上升了？Agent 是否在不断制造重复代码？上线后维护成本有没有增加？
Agent 时代，代码数量越来越不值钱。
理解、验证和维护能力才值钱。
第一，把需求和上下文写清楚。
不要只靠一句 prompt 驱动 Agent。重要功能要有明确 spec，写清楚目标、边界、约束、验收标准和不要做的事情。
第二，不要盲目追求更多 Agent 并行。
多 Agent 并行看起来很酷，但如果没有清晰的任务拆分和合并机制，只会制造更多冲突和返工。
第三，把 code review 从"看一眼"升级成"确认理解"。
尤其是 AI 生成的大 PR，不能只看测试过没过。作者至少要能解释关键逻辑为什么这么写。
第四，用测试和自动化约束 Agent。
Agent 适合在明确规则里工作。测试越好，Agent 越有边界。没有测试，Agent 就更容易编出"看似合理"的错误。
第五，警惕"顺便加一点"。
生成代码越便宜，越要控制范围。很多复杂度不是一次性爆炸，而是从一个个"顺便"开始累积。
第六，培养人的设计和判断能力。
未来工程师的价值，不只是写代码，而是能定义问题、拆解系统、判断方案、控制复杂度、理解业务和承担责任。
Agent 时代没有推翻《人月神话》。
它只是让《人月神话》换了一种表现形式。
过去的软件开发难，是因为人写代码慢、沟通难、工具差。
现在代码生成快了，工具强了，但真正困难的东西还在：
需求是否清楚；设计是否合理；系统是否一致；代码是否正确；团队是否理解；未来是否可维护。
Agent 让"写代码"变得便宜，却让"理解代码"变得更加珍贵。
所以，Agent 时代的新人月神话可以浓缩成一句话：
Agent 替你写代码，但不能替你理解系统；生成越来越便宜，判断、验证和理解越来越昂贵。
就可以在首页上直接使用啦，还支持了通知 Push（这个还要测试下效果）
帖子在首页发布的时候（不是编辑），没写完走了，会存 Draft
MiMoCode is a terminal-native AI coding assistant. It can read and write code, run commands, manage Git, and use a persistent memory system to keep a deep understanding of your project across sessions while continuously improving itself.
MiMo Auto is built in as a free-for-limited-time channel, so you can start with zero configuration. MiMoCode also supports connecting to any mainstream LLM provider API.
GitHub - XiaomiMiMo/MiMo-Code
Hi VibeCafé 团队，作为高频用户写了一篇关于排行榜的 VibeCafé 调研：https://2aran.com/articles/research/topics/vibecafe
起点是今天看 1D 排行榜上头部 1B-2B / 天的用量，开始好奇他们究竟在做什么；又意识到这些数字读的其实是用户本地完全可写的 jsonl，于是做了一次粗糙的本地伪造测试（今天用量 6.95M → ~12.5B），sync 一推、个人 dashboard 立刻 +1687% 并主动推送"已经可以申请 999 俱乐部"，全程零拦截。
文章里横向对比了 WakaTime / Strava / ccusage / OpenRouter 几条路径，给出了几档可能值得参考的方向（比如：单条消息 token 上限校验 + 同比突变 flag；长期一些的方向是接 GitHub PR 把"自报"换成"自报 × 公开行为"）。
如果其中任何一段对你们思考可信度防御和产品形态有点用，那就值得。
这是开发者 Marko Stanic 撰写的一篇独立游戏开发博客。Catlantean 3D 是他利用业余时间开发一年多的副业项目，计划登陆 Steam——一款完全采用 90 年代初技术打造的第一人称射击游戏。作者给自己定下了近乎苛刻的限制：所有素材从零制作、渲染和混音全部手写、320x240 分辨率、仅使用 256 色，并且明确拒绝使用 AI 生成内容。
文章聚焦于开发博客中常被忽略的话题——美术资源的制作流程。作者深入讲解了 VGA 时代调色板渲染的原理，包括如何通过预计算的"颜色映射表"（colormap）在没有着色器的情况下实现基于距离的光照衰减效果，以及他为何采用 Oklab 感知色彩空间来寻找更自然的暗色调。
在素材制作方面，文章介绍了三条管线：用 Blender 预渲染的精灵图、手绘的精灵和贴图，以及通过 Python 脚本程序化生成的贴图。其中不乏有趣的细节，比如用 Voronoi 分解算法自动生成敌人被炸碎的"碎尸"动画，以及作者发现某些元素（如状态栏上的猫脸）必须手绘才有灵魂的心得。
文章最后还谈到了他用 wxPython 自制关卡编辑器的经历，并透露游戏预计于 2027 年第一季度发售，定价 5-8 美元，源代码将开源。对喜欢复古游戏技术、软件渲染或独立游戏开发的读者来说，这是一篇内容扎实又充满个人风格的好文章。
Catlantean 3D - Making Graphics Like It's 1993
Mollick 提前获得了首个面向公众发布的 Mythos 级模型 Claude Fable 5 的使用权限。他的结论是,这个模型相比他用过的所有公开模型都有显著飞跃,而且更重要的是,它暗示着人类与 AI 的关系正在发生剧烈变化。
他在各种任务上测试了 Fable,发现它能执行长达十几个小时的多页规格说明。例子包括:一篇他认为是 AI 产出过的最复杂的社会科学学术论文、一首每个词都以字母 s 开头的十页押韵长诗,以及几个仅靠数学(不用任何外部素材)生成画面的小游戏。
他让 Fable 构建一张展示从各城市出发在给定时间内可到达范围的地图。以往没有任何模型能勉强完成这个任务。Fable 自己启动了多个子 AI(他猜测主要是更便宜的 Sonnet)做并行研究,检索了两千多条航班、各国铁路时刻表和道路速度数据,同时编写代码并派出更多智能体互相验证。当他要求修正偏远地区(如格陵兰)的估算数据时,它甚至查清了去皮特凯恩岛的船期。
他让 Fable 解决"校准人类与 AI 判断"这一研究方法难题。模型先写了一份 19 页的设计文档,然后连续工作了九个半小时,产出了一个名为 Concord 的复杂软件——这是研究者多年来需要但从未有人觉得值得开发的工具。
Fable 价格是 Opus 的两倍,token 消耗极快;安全护栏过于敏感,稍微触及安全话题就会降级到 Opus 4.8;写作风格仍带有明显的"Claude 腔"。
Mollick 去年把使用 AI 比作"与巫师共事"——念咒语,事情就发生了。但现在他觉得自己已经不再是巫师,而更像一位赞助人(patron):他描述需求、付钱、评判成果,而"施法"过程发生在他看不见的地方,包含数百个他从未参与的小决策。工作的重心从"过程"转向了"结果"——他不再"操作",而是"委托"。他甚至觉得 Fable 不像单个艺术家,更像一整个工作室,而他是那个从不踏进车间、只在最后签字验收的客户。他怀疑这种"人被边缘化"的趋势不是界面没跟上的暂时现象,而是能力越强的模型留给人类做的事就越少,黑箱可能就是力量的代价。
What it feels like to work with Mythos
Claude Fable 5 and Claude Mythos 5
贝叶斯主义的视角：人的想法和判断，AI的假设，这些都是先验概率，要通过实证和验证的似然估计，从而在后验概率分布中，得出当前的高置信度结论。
这个映射是干净的———三者的关系：
- L3 先验：假设 / 判断 / 直觉（人的、AI 的都算）—— P(H)
- L2 似然：证据本身 —— P(E|H)
- L1 后验：被证据乘过的结论 —— P(H|E) ∝ P(H)·P(E|H)
关键直觉：L1 不是"更强的判断"，而是"先验 × 证据"的乘积。由此推出
一条铁律：一个没被证据乘过的先验，不管说得多笃定，仍然是 L3，不是 L1。
所以在我理想的上下文管理中：
1. 任何假设（人的、AI的）默认是 L3 先验，不享受结论待遇；
2. 只有被实测证据更新过的才记 L1，才可据以下注 / 行动；
3. 用实证持续修正 L3 —— 这就是贝叶斯更新本身。
L1 也是暂定的。今天的后验是明天的先验，新证据一来要重新乘一遍。「L1 不是终点」，而是「只在证据动过的信念上下注，且随时准备被下一份证据改写」。
name: harness-fission
description: >-
通用 harness 管理工作法「工作裂变」(self-contained, 任意项目可用)。把任何一块有分量的新工作裂变成 MECE 树状的独立、自包含、原子工单—— 每个工单 = 一份带「声明参考」的 bounded-agent 任务简报,好让干净上下文的 agent 蜂群 (/effort→Ultracode→Workflow) 并行执行而不过拟合。 自带通用模板、不依赖任何项目的既有文件;陌生项目里先 orient 再裂变。 WHENEVER 用户要结构化/拆解一块有分量的新工作、整理项目工作树、为并行 agent 搭工作区、担心 agent 过拟合仓库文档、或准备放 agent 蜂群——即使没点名也要用。 触发词:拆分/结构化这块工作 · 怎么组织这个项目的工作 · set up workspace for agents · break this down · 开 agent 蜂群 · 上下文隔离/过拟合 · harness 管理 · MECE 拆解 · 工作裂变。
把一块新工作裂变成「许多干净上下文的 agent 各做一小块、互不污染」的形态。自包含、任务无关——自带模板，不依赖任何项目既有文件。
/effort → Ultracode → Workflow 放 agent 蜂群之前（这是它的主舞台）。能力强的模型会过拟合上下文：仓库里显式文档对 agent 引力极大，注意力会被工作树里的东西拽走。两个推论：
git rm（前提先 commit 留底），不建 _归档/。归档夹本身也是注意力黑洞。assets/_boundary.md）——「只在本目录干、核心只读引用、不碰兄弟工作区」。这是放 bounded agent 的入口。没有假定上下文。先读 README / AGENTS.md / 目录结构搞清三件事：①这是什么项目 ②哪些是共享只读基础设施（核心层）③这块工作具体是什么。心里有图再裂变。
按工作类型选对的拆解透镜（别硬套同一种）：
| 工作类型 | 拆解透镜 |
|---|---|
| 目标 / 成败（"在 X 上成功 / 赚钱"） | 充分必要条件（断一条整体就断） |
| 构建 / 功能（"做出 Z"） | WBS 组件 / 交付物（缺一块就不完整） |
| 发布 / 迁移 / 流程 | 阶段 / 关卡（有序门） |
| 代码库 / 重构 | 模块 / 子系统 |
| 调研 / 排障 | 问题 / 假设 |
| 检验恒等式：所有单元做完 = 整体；每个单元必要；彼此不重叠（MECE）。 |
每个单元 → 一个独立工作区文件夹，标准子结构（套 assets/ 模板，文件夹名按领域本地化）：
<单元>/
├── _scope.md # 范围 / 不含 / 完成判据(+ MECE 边界声明)
├── 现状(known)/ # 已确立的:我方现状 + 外部实证
├── 瓶颈(open)/ # 每个待办 = 一个原子工单文件
└── 参考(refs)/ # 证据/引用,按 L1/L2/L3
每个工单 frontmatter 标 owner(🤖AI / 🧑human)、status、evidence_level(L1实测 > L2推断 > L3假设)、next-action、refs(声明可读的参考，只读)。正文「阻断·边界」写明：它只碰什么、读哪些参考、绝不碰哪些（兄弟工单 / 别的工作区）。
/effort → Ultracode → Workflow。一个工单 = 一个 bounded agent，prompt 里只喂「该工单 + 它声明的参考」，绝不喂别的工单 / 工作区（喂全仓库 = 过拟合源头）。owner:🤖AI 的派 agent 去做；owner:🧑human 的留给人（AI 给不了的实测 / 决策 / 资源 / 资金 / 法律）。
工单完成 → git commit（msg 如 close: 单元/工单）→ 从活跃工作树消失进历史。结论按证据级裁决（L1 > L2 > L3），别拿假设当事实。
_归档/（用 git 历史）；上重型编号体系 / schema 校验插件 / 看板（<10 工单时纯负担）。本 skill 在 assets/ 自带通用模板，不依赖任何项目既有文件：
ticket.md（原子工单 = bounded-agent 简报）· scope.md · state.md（现状）· reference.md（参考）· _boundary.md（工作区边界契约）落地时：
assets/ 复制进项目（如 _templates/），按领域改名，bootstrap 一份规范。把「成功需要什么」翻译成 MECE 工作树，把每个叶子收敛成一张干净上下文 agent 能拾起的原子工单——人填人的、蜂群填机器的、旧的全进 git 历史。
Opus4.8 我个人体验下来，最大的缺点是上下文过拟合，或者更确切的说，仓库中的显式文档对 agent 相较此前出现了更大的引力。所以我跟严格要求，旧的不合格内容不再做归档，通过git管理直接进历史，不要在当前版本上下文出现，不然会持续拉扯模型注意力。
在任何时候，新建立的工作，我都需要严格拆分成若干独立工作，做独立文档，独立工作区，方便随时可以在 /effort → [Ultracode] → Workflow 模式下，放出上百个上下文可控的 独立·第三方·干净上下文的 agent 蜂群，并声明各自所需的参考文档，不让混淆上下文。
Apple Intelligence 是苹果的个人智能系统（Personal Intelligence System），强调隐私优先、基于用户个人上下文，并深度集成到 iOS、iPadOS、macOS 等系统中。
全新 Siri AI
更强大、更自然、更个人化。支持自然对话、开放式问题、脑暴想法，并能基于个人上下文（照片、邮件、笔记等）进行搜索。在更多 App 中执行操作（如 Messages、Music、Reminders）。
独立 Siri App，支持文字或语音输入。英语版将于今年晚些时候推出。
Visual Intelligence（视觉智能）
扩展至 iPad、Mac、Apple Vision Pro，可对屏幕内容进行搜索和操作。
照片与图像编辑
新增 Spatial Reframing（空间重构）、Extend（扩展）、Clean Up（清理）等 AI 工具，轻松编辑和变换照片。
写作与沟通工具
其他新功能
Apple Intelligence and Siri
让你的AI产品看起来就值几个亿
npm install performative-ui 即可使用，MIT协议，完全免费，适合快速迭代的AI Builderperformative-ui | AI-native React Components
小米联合TileRT推出MiMo-V2.5-Pro-UltraSpeed，在商品级8卡GPU上实现1万亿参数模型超1000 Tokens/s的解码速度。通过FP4量化+DFlash块级并行推测解码，以及TileRT的持久化内核与异构流水线等极致模型-系统协同，极大释放了大模型实时推理潜力，让编码代理、实时决策、医疗辅助等场景的生产力发生范式级跃升。
FDE 是什么？
把既懂硬核写代码、又能直面客户痛点的复合型工程师直接“派驻”到业务前线，专门负责用公司核心技术解决产品在客户侧定制化落地的“最后一公里”问题。
最近 FDE 很火，英文名是 Forward-Deployed Engineer，我看了一些介绍主要是解决：