这期最实在的一段是内部的 GraphRAG 实测。挑的题很刁：「为什么小王子最后选择了玫瑰而不是狐狸」——这种需要跨全书推理的问题，常规检索基本无从下手。
发货一直有问题，这周有两篇值得看的东西。
一篇是很深度的技术分析，逐层拆解可能出问题的环节——工艺上有问题，供应链上也有问题。写得极细，对底层制造环节感兴趣的人值得读一遍。
另一篇是付费媒体的报道，讲的是关于新推理模型的一些传闻。
把两件事放在一起看就有意思了：一边是关于新一代推理模型的传闻，另一边是「订阅价可能要提到两千美元一个月」的说法。
这个价位对个人用户当然是算了。但如果真有一个推理能力特别强的模型，对企业来说，两千美元一个月并不是不能接受。
换句话说：这个定价传闻本身就在暗示背后确实有新东西，而且是面向企业的。
有厂商开源了一个语义搜索的 SDK，整套后端都跑在自家服务上——数据库、对象存储、KV 缓存，全是自己的。
实测下来语义搜索效果挺不错，速度也可以（它调的是外部厂商的模型）。
关键在于它的价值不止于「能用」：里面用到的组件都是开源的，理论上可以整体换成任何一家云服务的版本。
所以它实际上是给了大家一个样板——要做语义搜索，照着它的做法搭就行。
最近编码工具火得不行，社区里全是在聊怎么用、怎么比老一代补全强。顺带也把一批更早就在做这件事的项目重新带回了视野。
但真正的差别不在功能多少，而在交互范式的一处翻转：
传统习惯是——我写个函数，先写注释说明它干什么，把步骤拆成 a、b、c，然后期待模型基于我的注释补出实现。
而它推荐的是另一种：把「你要它干什么」变成一个单独的界面，你直接下命令，它写整段。
前者是你在主导结构、模型填空；后者是你交代意图、模型出结构。这才是那个大的差别。
内部做了三组实测。
第一组是英文小说。问题是「为什么小王子最后选择了玫瑰而不是狐狸」。这种问题对常规检索来说很难理解——答案不在任何一段里。而图谱能从多个角度推理和分析：情感连接、象征意义、两个角色各自代表什么。出来的东西很像一份写得不错的读书笔记，有层次。
第二组是红楼梦前十五章。最令人意外的是问「故事中影响最大的事件是什么」——它找出的情节，事后核对确实成立。另一个问题是分析某个角色与哪些人关系密切，它也能把人物关系抽出来，覆盖得相当全面。
第三组是一份商业研究报告，和现有知识库产品的基线做对比。结论比较克制：图谱在全局模式下分析更宽泛，但缺少具体论点，观点偏泛泛，这块还需要调。
两个共同的限制：一是受限于当时的上下文长度（最高 8K），分析没法做得更深，要深入只能继续追问；二是 token 消耗比普通检索大不少——文本处理阶段就会产生大量中间产物。
有人跑了一段时间之后得出结论：把 AI 当卖点做一家游戏公司，这件事不 work——赚不到钱。
更准确地说：对小规模工作室不合适。要有体量才可能成立。
它更像是大型游戏里的一个提效或提升体验的模块，而不是一个从零开始、拿它当核心卖点的东西。
由此衍生出的另一条更有价值：有人做了一个角色扮演的评测基准。以前 role play 只是个提示词技巧，但在多 agent 框架里，它几乎就是核心——怎么定这个角色，直接决定最终效果；而哪个模型在角色扮演上更强，同样至关重要。
把这两件事连起来看：下一代游戏的制作能力，本身就该是衡量模型的一个维度。
大家跑 Python 都习惯用 notebook，但 JS/TS 一直没有对应的东西。
有人做了一个：可以理解成 JS 领域的 Jupyter——写 JS 或 TS，分块执行，写注释，重复执行调试，都行。
贴心的地方是：每一块默认放了「让 AI 生成代码」的入口，你可以写 TypeScript、写 Markdown，也可以直接让它生成。
为什么强调 TS 而不是 JS——因为 JS 本身的代码实在太脏了，TS 读起来舒服得多。