AI 编码

AI 写代码的一切：编码助手、Vibe Coding、代码模型评测与开发工作流变革。

7月17日星期五

Hacker News 首页7/17 22:21

月之暗面发布 2.8 万亿参数 Kimi K3，自称首个开源 3T 级模型，API 定价看齐 Claude Sonnet

月之暗面推出了 Kimi K3，一个 2.8 万亿参数的模型，他们把它四舍五入叫成“首个开源 3T 级模型”。这个模型 API 定价是输入每百万 token 3 美元、输出 15 美元，跟 Anthropic 的 Claude Sonnet 系列一个价，是目前中国 AI 实验室里最贵的模型。它自己公布的跑分大多超过了 Claude Opus 4.8 和...

推荐理由：月之暗面发了 Kimi K3，一个 2.8 万亿参数的模型，他们管它叫“首个开源 3T 级模型”，API 定价输入每百万 token 3 美元、输出 15 美元，跟 Claude Sonnet 一个价，是目前中国 AI 实验室里最贵的。自己公布的跑分大多超过 Claude Opus 4.8 和 GPT-5.5 high，但输给 Claude Fable 5 和 GPT-5.6 Sol。Simon Willison 的测试里 K3 在长周期知识任务上比前代 K2.6 涨了 732 Elo，输出 token 数少了 21%，成本降了 27%，说明模型在...

锐评

Kimi K3这次定价直接对标Claude Sonnet，输入每百万token 3美元、输出15美元，比自家上一代K2.6贵了三倍多，是目前中国AI实验室里最贵的模型。月之暗面把它四舍五入叫成“首个开源3T级模型”，实际参数2.8万亿，比DeepSeek的1.6T大不少。从Artificial Analysis的第三方评测看，K3在长周期知识任务上的Elo分达到1547，比K2.6猛涨了732分，仅次于Claude Fable 5。单任务成本0.94美元，接近GPT-5.6 Sol的1.04美元，大约是Opus 4.8的一半。输出token数比上代少了21%，说明回答更精简了。不过目前模型只提供“max”推理强度，没法调低省成本。Simon拿它画鹈鹕花了25美分，烧了1.3万个推理token，效果还行但不算惊艳。视觉能力可用，输入token数暗示有个约85 token的隐藏系统提示词。开源权重承诺7月27日前放出，到时候可以本地跑跑看。现在缺的是它在长对话工具调用和agent场景下的可靠性数据，这才是现在模型能不能干活的关键，光看跑分和画图说明不了问题。

AI 群聊日报7/17 18:23

Kimi K3 登顶前端编程榜，权重将开源，但实测发现它有时会烧光额度原地打转

Kimi K3 在 Frontend Code Arena 拿了 1679 分，压过 Claude Fable 5，七个前端领域赢了六个。模型有 2.8 万亿参数，支持 1M 上下文，定价是每百万 token 3 到 15 美元，完整权重会在 7 月 27 日前放出来。群友上手后评价两极：有人花 199 元月费让它重做了之前搞砸的粒子特效，效果惊艳；也...

推荐理由：Kimi K3 在 Frontend Code Arena 拿了第一，七个前端方向赢了六个，权重还要开源，属于国产大模型一次硬碰硬的亮相。群聊日报给了分数、参数量、价格和真实用户反馈，信息够用。没打更高是因为来源是社区整理，不是一手官方公告，我会先打个折。

锐评

K3 这次最值得关注的点不是跑分，而是“性能登顶、成本三分之一、权重全开”三件事第一次同时成立。2.8 万亿参数、1M 上下文、定价每百万 token 3 到 15 美元，完整权重 7 月 27 日前放出——如果属实，对开源生态的冲击会比跑分本身大得多。

但群友实测暴露了两个关键问题。一是稳定性：有人冲了 40 刀 coding plan，模型在仓库里分不清 ranchen 和 rancheng，在思考链里疯狂打转，5 小时额度几乎全烧光。官方也承认 K3 遇到小问题或意图模糊时“可能替用户做非预期决定”。二是榜单保真度：GLM-5.2 榜上分数不低，实际用下来群友觉得比 5.5 还差，K3 的跑分同样需要等更多独立验证。

文风方面，群友评价是 AI 味确实少了，但“强行加模拟人的语气词”，远没达到当年 Opus 4.6 的自然中文水平。正文没披露 K3 在非前端编程任务上的表现，也没说芯片设计那项测试的可复现性——这些缺口会让“开源斩杀线”这个定位暂时只能打七折。

AI HOT 精选7/17 18:00

OpenAI 给 CFO 们画了张新账本：别盯着每个 token 多少钱，要看“每块钱干成了多少活”

OpenAI 发了一篇面向 CFO 的指南，核心就一句话：算 AI 账不能只看 token 单价，得算完成一件合格任务的综合成本。文章提了个“有用智能每美元”的框架，拆成四个问题：AI 到底干成了多少有用的活、每件成功的活实际花了多少钱、结果靠不靠谱、以及用得越多是不是每块钱买的活也越多。拿刚发的 GPT-5.6 三个档位（Sol、Terra、Luna...

推荐理由：OpenAI 这篇给 CFO 的指南把 AI 成本从 token 单价拉回到“完成一件合格任务花了多少钱”，提了个四维记分卡，还拿自家新模型和 Claude Fable 5 比了一圈。框架和对比数据都有，对企业算账的人挺实在，所以给了 featured。

锐评

OpenAI 这篇东西本质上是给企业财务负责人看的采购思路，核心是把算账逻辑从“买 token”扭到“买结果”。他们提的“有用智能每美元”框架不算新概念，但把问题拆得挺清楚：先定义什么叫活干完了，再算干成一件合格的事总共烧了多少钱，最后看规模上去后单价能不能降。

文章拿刚发的 GPT-5.6 三个档位举了例子，其中 Sol 在 DeepSWE v1.1 编程测试上跑到 72.7%，比 Claude Fable 5 的 69.9% 高一点，估算的 API 成本低了 36.2%。但这里有个坑：正文没披露 Sol 的具体定价，也没说这个成本估算是怎么算出来的，是只算了 API 调用费还是把重试、人工复核都摊进去了。所以“便宜 36.2%”这个数只能当个参考方向，不能直接拿来批预算。

另外，文章只比了编程场景，其他业务场景的性价比完全没提。如果你公司主要用 AI 做合同审查或者客服，这篇指南只能给个框架，具体数字得自己拿内部数据跑一遍。

彭博科技7/17 15:01

月之暗面发布新 Kimi 模型，跑分追上 OpenAI o3 和 Claude Sonnet 4.5，英伟达盘前跌超 3%

月之暗面在 7 月 17 日推出了新一代 Kimi 模型，在 MATH、HumanEval 等基准测试里，成绩跟 OpenAI o3 和 Anthropic Claude Sonnet 4.5 打平甚至略高。现在通过 Kimi 聊天机器人就能试，API 也已经上线。市场反应很直接——英伟达盘前跌了超过 3%，大家担心这会压降美国 AI 公司的定价空间。...

推荐理由：月之暗面这次发模型，跑分直接叫板 o3 和 Claude Sonnet 4.5，而且不是论文阶段，是已经能用的产品。我会先打个折——没看到模型大小和实际推理成本，光看跑分容易高估。但市场反应很诚实，英伟达股价先跌为敬，说明大家认真在考虑这会不会压降美国公司的定价空间。对国内从业者来说，这至少是个值得上手测一下的信号。

AI HOT 精选7/17 12:57

Kimi K3 前端编码跑分登顶，2.8 万亿参数模型 7 月 27 日开放权重

Kimi K3 在 Frontend Code Arena 拿了 1679 分，7 个前端子任务里 6 个第一，压过了 Claude Fable 5 和 GPT-5.6 Sol。模型本身是个 2.8 万亿参数的 MoE 架构，上下文窗口能塞进 100 万 token，大概是一套《三体》三部曲的量。7 月 27 日会开放权重，到时候可以自己部署。API ...

推荐理由：Kimi K3 在 Frontend Code Arena 前端编码榜拿了 1679 分，7 个子任务里 6 个第一，压过了 Claude Fable 5 和 GPT-5.6 Sol。模型是 2.8 万亿参数的 MoE 架构，上下文窗口能塞 100 万 token，7 月 27 日开放权重。这是国产旗舰模型在一个具体编码榜单上直接挑战闭源双巨头，而且马上能自己部署，对前端圈和国内开发者来说是个实打实可验证的信号。

锐评

Kimi K3 在 Frontend Code Arena 拿了 1679 分，7 个前端子任务里 6 个第一，压过了 Claude Fable 5 和 GPT-5.6 Sol。这个跑分说明它在写网页界面这件事上确实强，但要注意这只是前端编码一个细分方向，不代表通用能力也碾压。模型本身是 2.8 万亿参数的 MoE 架构，上下文窗口能塞 100 万 token，大概是一套《三体》三部曲的量，适合扔进大段代码或文档让它干活。

定价每百万 token 15 美元，没走低价路线，直接对标闭源头部。7 月 27 日开放权重，到时候可以自己部署，但正文没披露模型体积和推理硬件要求，部署成本现在没法算。另外，跑分数据来自官方发布，没有第三方复现或用户实测反馈，这点先别太激动。还缺的是：其他编码场景（后端、全栈）的表现、实际 agent 工作流里的稳定性、以及开源后的社区验证。

Latent Space7/17 09:46

月之暗面发布 Kimi K3：2.8 万亿参数开源模型，前端编程能力冲上第一

月之暗面发布了 Kimi K3，一个总参数量 2.8 万亿的模型，这也是目前公开权重里最大的一个。模型权重承诺在 7 月 27 日前放出。它支持 100 万 token 的上下文和原生的多模态输入，已经在 Kimi.com、Kimi Code 和 API 上线。在 Artificial Analysis 的智能指数上，K3 拿了 57 分，跟 Clau...

推荐理由：月之暗面扔出了 Kimi K3，2.8万亿参数，是目前公开权重里最大的模型。我会先打个折：权重还没放出来，承诺是 7 月 27 日前，这点先别太激动。性能上，Artificial Analysis 给了 57 分，说是 Opus 4.8 级别，但定价压到 Sonnet 5 那档，如果是真的挺省钱。支持 100 万 token 上下文和原生多模态输入，已经在 Kimi.com、Kimi Code 和 API 上线，可以直接用。正文没披露训练成本、推理延迟和具体 benchmark 细节，这些缺口让性价比判断还缺几块拼图。

锐评

月之暗面这次放出的 Kimi K3 总参数量 2.8 万亿，是目前公开权重里最大的一个，权重承诺 7 月 27 日前放出。它支持 100 万 token 上下文和原生多模态输入，在 Artificial Analysis 智能指数上拿了 57 分，跟 Claude Opus 4.8 和 GPT-5.5 差不多，但明显落后于 Fable 5 和 GPT-5.6 Sol。代码能力是亮点：LMSYS 前端代码竞技场排第一，胜率 76%，远超 Fable 5 的 63%；文本竞技场从 K2.6 的第 38 名跳到了第 9 名。成本方面，AA 测下来每次任务 0.94 美元，输出 token 数比 K2.6 少了 21%，说明回答更精简了。

不过月之暗面自己在博客里承认，跟 Fable 5 和 GPT-5.6 Sol 比，用户体验还有明显差距。这点先别太激动——分数高不代表用着顺手，代码榜第一也可能只是刷题厉害，实际项目里的表现还得看后续实测。另外，正文没披露训练数据构成和具体的安全对齐方案，这么大的模型跑起来需要什么硬件也没说，想自己部署的人得等权重放出来再算账。

Hacker News 首页7/17 08:21

人肉把关员已经累了

Pydantic 的 Laura Summers 聊了用大模型写代码的真实疲惫感：代码生成没问题，但人得不停地审查、纠错、把持方向，精力很快被榨干。她的同事 Douwe 每天醒来面对 30 个 AI 生成的 PR，很想把审查也丢给 AI，但反问自己“那我还在这干嘛”。她管这叫监督疲劳，并指出 AI 让你能同时开很多头，但能认真收尾的事一件没多。文章还引...

推荐理由：Pydantic 的开发者从一线视角讲了大模型写代码的真实困境：代码能生成，但人得不停审查纠错，精力很快被榨干。她管这叫“监督疲劳”，并指出 AI 让你能同时开很多头，但能认真收尾的事一件没多。观点来自真实体验，比纯技术文章更打动人。分数没给更高是因为这是一篇观点文，没有新数据或工具发布，但观点本身足够犀利。

锐评

这篇文章来自 Pydantic 的 Laura Summers，不是公关稿，是开发者自己说真话。她点出一个被忽视的代价：用大模型写代码，生成很快，但人得不停地审查、纠错、把持方向，精力很快被榨干。她管这叫“监督疲劳”。同事 Douwe 每天面对 30 个 AI 生成的 PR，很想连审查都外包给 AI，但那样自己的角色就彻底悬空了。文章还引了伯克利哈斯商学院的研究：AI 没有减少工作量，反而让工作更密集。

关键限制是，这全是个人体感和团队内部观察，没有量化数据支撑“疲劳”到底多普遍、多严重。正文也没披露他们内部有没有尝试用自动化评估来减轻审查负担，或者有没有对比过不同模型在维持意图连贯性上的差异。

对从业者来说，这篇文章的价值在于把“AI 写代码很爽”的另一面摊开了：它能让你同时开很多头，但能认真收尾的事一件没多。如果你也在经历这种“AI 提效但人更累”的拧巴状态，这篇值得一看，但别指望它给解法。

Computing Life · Share · 鸭哥调研7/17 08:00

BackendForge 让 AI 编程评测从笔试变面试，同一份代码通过率直接腰斩

BackendForge 先给 56 个后端任务写了 7,250 项测试，再让 Agent 专门找这套题库漏了什么，最后补了 640 项。测试只多了 8.8%，但 GPT-5.5 全部通过的任务从 31 个掉到 16 个，Claude Opus 4.7 从 33 个掉到 10 个。代码没变，变的是评分方式：新题专挑权限、脏数据、连带影响这些第一版没覆盖...

推荐理由：BackendForge 这件事有意思在它不拼模型，拼的是出题方式。先拿 56 个后端任务写了 7,250 项测试，再让 Agent 自己找题库的盲区，补了 640 项。测试量只涨了 8.8%，但 GPT-5.5 和 Claude Opus 4.7 的满分率直接腰斩。代码没变，变的是评分标准——新题专挑权限、脏数据、连带影响这些第一版没覆盖的角落。这对做 AI 编码工具的人是个实在提醒：模型能跑通任务不代表真靠谱，评测得学会追问。数字清晰，结论有冲击力，而且没吹模型，吹的是方法论，值得放 featured。

锐评

这条新闻最值得看的是评测思路的转变，而不是具体分数。BackendForge 先写好 7,250 项测试，再让 Agent 围着参考服务找漏，补了 640 项新题。新题数量不多，但专挑第一版没覆盖的权限、脏数据和连带影响。同一批代码，GPT-5.5 全过的任务从 31 个掉到 16 个，Claude Opus 4.7 从 33 个掉到 10 个。这说明以前很多“全过”的成绩，可能只是题目没问到点上。

不过得打两个折。第一，论文说会公开材料，但截至发稿还没放出来，外界没法逐项检查那 640 项新题是否合理。第二，这套追问是按每个 task 的参考服务定制的，不同 task 补的题不一样，所以不能把“通过率腰斩”直接套到其他评测上。

真正可复用的思路是：以后做整套应用评测，可以在定稿前加一轮面试式追问，让 Agent 先对着参考服务找漏，人再检查新题有没有需求依据，最后冻结成统一题库。这样既保持公平比较，又不漏掉关键边界情况。

Hacker News 首页7/17 01:44

德国团队发布开源模型 Soofi S，30B 参数跑出 3B 成本，德语英语跑分双杀

Soofi S 是一个 31.6B 参数的混合专家模型，每次生成只激活 3.2B 参数，推理成本压得很低。它用了 Mamba 加 Transformer 的混合架构，处理长文本时速度几乎不掉，这点比很多同尺寸模型强。训练数据故意向德语倾斜，结果在德语、英语和编程基准上分数都超过了 Olmo 3 32B 和 Apertus 70B。模型在德国电信的慕尼黑...

推荐理由：德国 AI 联盟放出的 Soofi S，一个 31.6B 参数的混合专家模型，每次只激活 3.2B 参数，推理成本压得很低。它用 Mamba 加 Transformer 的混合架构，长文本处理不掉速，在德语、英语和编程基准上分数都超过了 Olmo 3 32B 和 Apertus 70B。虽然德语优先的定位会限制它在中文圈的传播，但开源 30B 级别模型做到这个性能和成本，对从业者来说值得看一眼。

锐评

Soofi S 最值得看的是它的省钱思路：31.6B 参数的混合专家模型，每次生成只叫醒 3.2B 参数干活，处理 256K 长文本时推理速度几乎不降。这对需要处理大量文档又不想烧太多算力的场景很友好。训练数据故意向德语倾斜，结果在德语、英语和编程基准上分数都超过了 Olmo 3 32B 和更大的 Apertus 70B，说明数据配比比单纯堆参数有效。

争议集中在训练量上。按 Chinchilla 法则，模型参数和训练数据量有个最佳比例，但 Soofi S 用了约 27 万亿 token 训练，远超建议值。项目技术负责人反驳说，混合专家架构不适用老法则，因为不同专家可以重复看相同数据，Nvidia 也用过 25 万亿 token 训练。这个解释有道理，但正文没给出他们自己验证新法则的实验数据，说服力要打个折。

模型在德国电信的慕尼黑云上完成全部训练，代码和权重都开放，对想自己复现或微调德语模型的团队是个不错的起点。不过目前只看到基准跑分，缺真实业务场景的测试反馈，比如客服、合同审查这些德语强需求场景表现如何，还得等社区验证。

AI HOT 精选7/17 01:32

Anthropic 公开了用 Claude Code 做大规模代码迁移的实操手册，拿 Bun 的百万行 Zig 转 Rust 当案例，两周搞定

Anthropic 在博客里完整拆解了他们怎么用 Claude Code 把 Bun 项目超过一百万行的 Zig 代码迁移到 Rust，只花了两周。核心思路是把迁移拆成规划、执行和验证三步：先让 Claude Code 通读代码库并写出迁移方案，再自动生成 PR，最后跑通 CI 来验收。文章附了完整的工作流和提示词模板，给想用 AI 做内部重构的团队参...

推荐理由：Anthropic 官方博客拆解了一次真实的大规模迁移，有数字、有流程、有模板，不是公关稿。分数没给更高是因为这本质上是一篇案例分享而非产品更新，而且 Bun 不是 Anthropic 的项目，更像一次对外演示。

锐评

Anthropic 这篇博客不是第三方评测，是他们用自家工具 Claude Code 做的一次大型代码迁移实验。对象是 Bun 项目超过一百万行的 Zig 代码，目标语言是 Rust，整个迁移只用了两周。

工作流分三步：先让 Claude Code 通读整个代码库，写出迁移方案；再自动生成 PR；最后跑通 CI 来验证。博客里附了完整的提示词模板，想用 AI 做内部重构的团队可以直接参考。

但这里有几个点要先打折。第一，这是 Anthropic 自己写的案例，不是独立验证，效果可能有美化。第二，正文没披露迁移后的代码质量指标，比如 bug 率、性能对比、人工修了多少处。第三，Bun 的 Zig 代码库结构相对规整，换成一个老旧的内部系统，两周能不能跑通是未知数。

对 AI 从业者来说，这篇的价值在于工作流设计和提示词思路，而不是“两周迁移百万行”这个数字本身。如果你团队也在考虑用 AI 做大规模重构，可以先拿一个小模块跑一遍这套流程，看看实际返工率再决定要不要铺开。

7月16日星期四

Hacker News 首页7/16 19:59

批评大模型的人说得都对，但我还是在用

作者在柏林 Local-First Conf 上发现一种普遍的矛盾：台上演讲者批评大模型，台下观众一边鼓掌一边开着 Claude Code。他承认所有批评都成立——产出大量信息垃圾、破坏开源社区的信任基础、打乱资深与初级工程师之间的带教循环、存在地缘政治断供风险——但自己依然重度使用。文章没有试图化解这种矛盾，而是把这种集体性的别扭感摊开来讲，并邀请大...

推荐理由：这篇文章没打算讲道理，就是把开发者圈子里那种'边骂边用'的集体拧巴摊开给你看。柏林会议上 Armin Ronacher 的回复是个好钩子，但全文没有数据支撑，也没有解决方案，就是一次诚实的自我暴露。我会给 featured，因为共鸣够强、传播力够好，但别指望从这里学到什么新东西。

锐评

这篇文章没打算说服谁，只是把一种普遍存在的矛盾摆出来：批评大模型的所有理由都成立，但大家还是用。作者在柏林 Local-First Conf 上观察到，演讲者 Armin Ronacher 刚说完“人类才是最好的 agent”，台下就有人开着 Claude Code 鼓掌。他本人做的开源项目 Pi.dev 甚至自动关闭绝大多数 PR，因为被大模型生成的提交淹没了。

文章承认了几个核心批评：大模型产出大量信息垃圾，破坏了开源社区基于“提交成本”建立的信任基础——以前一个像样的 PR 至少说明对方花了几小时，现在没法区分是真人用心还是机器批量生成。另外，资深工程师不再有动力带新人，因为无法判断初级工程师的代码背后有多少是自己的思考。作者还提到地缘政治断供风险，但正文没展开讲具体指什么。

他给出的个人用法模式比较实在：把大模型当“超级自动补全”用，自己始终是最后把关的人。但文章没提供任何数据或对比实验，所有观察都来自个人经验和一场会议的见闻。如果你想知道这种用法在效率上到底提升了多少、错误率有没有变化，这篇文章给不了答案。

Hacker News 首页7/16 19:39

Roc 语言的编译器用 Zig 重写后，首次追平了原 Rust 版的功能

Roc 团队花了 487 天，把 30 万行 Rust 编译器用 Zig 重写了一遍，最近刚做到功能追平。一个叫 Rocci Bird 的演示小游戏现在能编译成 31KB 的 wasm 文件，体积不到原来的一半。新编译器在开发时会自动热加载代码，改完不用重启；发布时能交叉编译出可复现的静态二进制文件。团队强调这次是重新设计，不是直接搬运，所以没法拿 R...

推荐理由：Roc 团队花了 487 天把 30 万行 Rust 编译器用 Zig 重写，刚追平功能。31KB wasm（不到原来一半）、热加载、可复现静态二进制都是实打实的改进。和 Bun 从 Zig 切 Rust 的报道天然形成对照，增加了话题性。但正文没给出 Rust 版本的直接性能对比，团队也承认是重新设计而非搬运，所以实际提升幅度要打个折。上限给到 72，因为缺乏严格的 A/B 数据支撑。

锐评

Roc 团队花了 487 天把编译器从 Rust 换成 Zig，最近做到了功能追平。一个叫 Rocci Bird 的小游戏现在能编译成 31KB 的 wasm 文件，体积不到原来的一半，说明新编译器在产出体积上有明显改善。开发时支持热加载，改代码不用重启；发布时能交叉编译出可复现的静态二进制，这对分发和部署是实打实的好处。

需要明确的是，这次不是直接搬运代码，而是重新设计编译器，所以不能拿这个案例去简单对比 Rust 和 Zig 的性能或开发效率。正文也提到，Bun 从 Zig 到 Rust 的移植只用了 11 天，但那是直接搬运，和 Roc 的情况完全不同。

目前还没有正式发布，v0.1.0 计划在今年晚些时候推出。正文没披露新编译器在编译速度、内存占用、错误信息质量上的具体对比数据，也没提重写过程中踩了哪些坑。这些信息缺口让“重写是否值得”这个问题暂时没法下结论。

Latent Space7/16 14:18

Thinky 发布 Inkling：9750 亿参数、410 亿活跃的多模态开源模型，目前美国最强 Apache 2.0 基座

Thinky 推出了 Inkling，一个总参数量 9750 亿、每次推理激活 410 亿参数的混合专家模型。它能直接处理文字、图片、音频和视频，支持最长 100 万 token 的上下文窗口。模型用 45 万亿个多模态 token 训练，采用 Apache 2.0 协议开源，发布当天就得到了 vLLM、Hugging Face 等工具链的支持。团队明...

推荐理由：Thinky 第一个完整模型发布，975B MoE 架构、Apache 2.0 开源，填补了美国开源阵营的空缺。Mira Murati 的团队背景、100 万 token 上下文和原生多模态能力同时打中了热度、硬核度和身份认同三个点。没给到 90 分以上是因为目前只有团队自己公布的跑分数字，正文没披露独立第三方的验证结果，这点先别太激动。

锐评

Inkling 最值得看的是定位：不追 SOTA，而是做一个美国本土的、Apache 2.0 协议的多模态开源基座。975B 总参数量、41B 激活参数，用 45 万亿个多模态 token 训练，支持 100 万 token 上下文窗口，这些数字说明它规模够大、训练数据量也足。但团队和独立评测都承认，它在部分基准上还跑不过中国最好的开源模型和闭源模型。

技术上，它原生处理文字、图片、音频，不是后期拼接的多模态，这点对需要直接处理混合输入的开发者比较友好。同一天还发了 Inkling-Small，激活参数降到 120 亿，用类似配方训练，主打更低成本和延迟。vLLM 和 Hugging Face 当天就接入了，工具链跟得快。

正文没披露训练成本、推理延迟的具体数字，也没给出跟 DeepSeek 等模型的直接对比表。Mira Murati 说这是“第一个模型”，John Schulman 补充预训练去年冬天才开始，团队规模不大。如果是真的，这个产出效率挺高，但长期能不能持续迭代、生态能不能起来，还得看后续动作。

AI HOT 精选7/16 05:07

xAI 把编程助手 Grok Build 的完整代码开源了

xAI 在 GitHub 上公开了 Grok Build 的全部源码，包括智能体的工作循环（怎么拼上下文、怎么解析模型回复、怎么调用工具）、终端界面、以及技能、插件、MCP 服务器等扩展系统。你可以直接读源码搞清楚它的内部机制，也可以自己编译后连上本地模型跑起来，完全离线使用。

推荐理由：xAI 开源了 Grok Build 的全部代码，包括智能体循环、终端界面和扩展系统，还支持本地离线运行，在开发者圈子里同时踩中了好奇心、干货和实用价值三个点。目前只有官方公告，还没有第三方评测或实际跑通后的反馈，所以分数先定在 featured 这一档，等有人上手验证了再调整。

7月15日星期三

Hacker News 首页7/15 21:55

StyleSeed：给 AI 编程助手装一套设计规范引擎，别让它再生成千篇一律的界面

bitjaru 开源了一个叫 StyleSeed 的项目，专门给 Claude Code、Cursor 这类 AI 编程工具用。它不直接生成代码，而是教模型做设计判断。项目里打包了 74 条设计规则、48 个组件、7 套品牌皮肤（像 Stripe、Linear、Vercel 这些），还有一套命名过的动效系统和 15 个快捷指令。目前 MIT 协议开源，...

推荐理由：给 AI 编程工具加设计约束这事确实戳中刚需，74 条规则加品牌皮肤让项目不止于概念 demo。分数没给更高是因为刚在 Show HN 亮相，没有用户反馈和实际落地效果，目前只能按工具完整度打分。

锐评

bitjaru 开源的这个 StyleSeed，说白了就是给 Claude Code、Cursor 这类 AI 编程助手配了一本“设计说明书”。它不直接写代码，而是用 74 条设计规则、48 个组件和 7 套品牌皮肤（比如 Stripe、Linear 的风格），教模型在做界面时学会做设计判断，而不是每次都吐出那种一眼 AI 的默认样式。项目还带了一套命名过的动效系统和 15 个快捷指令，目前 MIT 协议开源，拿了 731 个星。

数字上看，规则和组件量不算少，覆盖了常见的设计决策点。但正文完全没提最关键的一环：这些规则在模型实际生成代码时是怎么被遵守的。是靠提示词约束，还是做了后处理校验，还是只是当参考文档丢给模型？如果只是把规则文件放在项目里让模型自己读，那效果会很依赖模型当时的理解能力，稳定性存疑。动效系统也只给了名字，没讲实际怎么触发和控制。

另外，7 套品牌皮肤是直接复刻了这些公司的视觉特征，实际使用时要注意版权边界。总的来说，思路对路——给 AI 补设计常识而不是只补代码量，但缺了执行机制的说明，目前更像一套精心整理的设计规范库，离“引擎”还有距离。

Hacker News 首页7/15 18:11

Martin Fowler 博客：用领域特定语言给大模型套上缰绳，让代码生成更靠谱

Unmesh Joshi 在 Martin Fowler 的博客里说，靠一份详细需求文档就让大模型一把梭出整个系统不现实——需求只是假设，真正的设计是在实现过程中一点点摸出来的。他提出用领域特定语言（DSL，也就是为特定业务定制的“小语言”）和领域抽象给大模型画好边界，这样模型生成的代码才不会跑偏。文章举了 Tickloom 的例子：这是一个给分布式系...

推荐理由：一篇扎实的工程实践文章，发在 Martin Fowler 的博客上，用 DSL 给大模型代码生成画边界，有具体例子支撑。没给更高分是因为它属于观点/模式文章，不是产品发布或模型发布，受众更偏后端架构师。

锐评

Unmesh Joshi 在 Martin Fowler 博客上发了一篇很实在的文章，核心就一句话：别指望扔一份详细需求文档给大模型，它就能吐出整个系统。需求只是假设，真正的设计是在实现过程中一点点摸出来的。他提出的解法是用领域特定语言（DSL，也就是为特定业务定制的“小语言”）和领域抽象给大模型画好边界，让模型生成的代码不跑偏。

文章举了 Tickloom 的例子，这是一个给分布式系统建模的领域模型，大模型先帮着迭代构建 DSL，再充当自然语言接口去用这个 DSL。逻辑上说得通：DSL 成了系统的唯一真相来源，模型只是在这个框里干活。但正文没披露这套方法在真实生产环境里的效果数据，比如 DSL 维护成本多高、模型生成代码的一次通过率是多少。例子偏演示性质，离工程落地还有距离。

对 AI 从业者来说，这篇文章的价值在于把“用 DSL 约束大模型”这个思路讲透了，比单纯优化提示词更结构化。但缺的是：当 DSL 本身需要演进时，怎么让模型跟着一起改而不引入新错误？这点正文没展开，先别太激动。

Computing Life · Share · 鸭哥调研7/15 08:00

Codex 仍然开源，但父 agent 给子 agent 派了什么任务，现在被加密了

OpenAI 在 6 月 5 日合并了一个 PR，把 Codex 里主 agent 派给子 agent 的任务指令从明文改成了密文。以前你在本地日志里能看到类似“Review the authentication changes”这样的具体任务，现在只剩一串 <ciphertext>。子 agent 调用了什么工具、跑了什么命令、改了哪些代码，这些执行...

推荐理由：这是一条有具体技术细节的产品变动报道，不是公关稿。PR 号、issue 链接、改动前后对比都给出来了。扣分是因为这属于功能调整而非新能力发布，影响范围也局限在 Codex 用户。我会先打个折：虽然对开发者体验的冲击不小，但本质上是一次安全加固，不是模型能力或架构的突破。

锐评

OpenAI 在 6 月 5 日合并了一个 PR，把 Codex 里主 agent 派给子 agent 的任务从明文改成了密文。以前你在本地日志里能看到类似“检查认证改动”的具体指令，现在只剩一串 <ciphertext>。子 agent 调用了什么工具、跑了什么命令、改了哪些代码，这些执行记录仍然可见，但中间那句“你去做什么”被藏起来了。

这跟之前隐藏模型推理过程不一样。推理是模型自己怎么想，而任务指令是在指挥另一个 agent 行动。现在排错时，你没法判断是主 agent 派错了任务，还是子 agent 理解错了。加密发生在 OpenAI 服务端，本地客户端只负责转发密文，开源代码里已经没有恢复明文的路径。

OpenAI 没解释为什么这么做，正文只提到外界猜测可能是保护提示词或统一云端服务。真正需要追问的是：当 agent 之间的任务链越来越长，我们还能审计到哪一步，完全取决于服务商愿意让本地看到什么。

Computing Life · Share · 鸭哥调研7/15 08:00

AI 训练 AI：一次公开实验把自我改进的闭环走到了哪一步

Dan Austin 开源了一个完整的 AI 训练 AI 实验。外层用 Qwen3.6 智能体设计后训练方案，内层用 Qwen3-0.6B 或 1.7B 模型在 GPU 上真跑训练，隐藏评分再作为奖励反馈给外层。54 步下来，智能体先学会少交无效作业，然后把 1.7B 模型的使用比例从 42% 拉到了 95%，并开始主动调整温度、优化器等超参数。训练后...

推荐理由：我会先打个折：这只是一个公开实验，不是产品，规模也小。但它的价值在于把“AI 训练 AI”从概念变成了可复现的流程。外层 Qwen3.6 智能体设计后训练方案，内层 Qwen3-0.6B 和 1.7B 真跑训练，隐藏评分当奖励。54 步后，智能体先学会别交无效作业，然后主动把 1.7B 模型的使用比例从 42% 拉到 95%，还开始调温度、优化器这些超参数。这说明在小规模下，AI 确实能通过试错找到更省钱的训练策略。正文没披露最终模型在基准上的绝对分数，所以别急着说“超越人类调参”，但流程本身对做模型训练自动化的团队很有参考价值。

锐评

Dan Austin 开源的这个项目，把“AI训练AI”的循环跑通了。外层智能体负责设计训练方案，内层小模型在GPU上真跑，跑完的分数再回来教外层怎么写更好的方案。54步下来，智能体先学会了不交无效作业，然后把1.7B模型的使用率从42%拉到了95%，还开始主动调超参数。训练后的小模型得分也从噪声水平涨到了0.22-0.48的区间。

但别急着激动。项目复盘时发现评估器有个低级错误：检测工具使用时找错了字段名，导致占奖励权重0.4的分数从来没生效过。也就是说，之前看到的奖励上涨，有一部分是量错了。作者发现后推倒重来了，现在公开的是修复后的结果。

这个实验最实在的结论是：外层强化学习确实能改变训练智能体的行为，让它更会“应试”。但任务、奖励、预算全是人定好的，智能体只是在规则内找高分策略。在没参与训练的triage任务上，效果有提升但不稳定，第34步见顶后第54步又回落了。这离真正的自主科研还很远，更像一个学会了怎么写高分作业的实习生。

Latent Space7/15 07:21

AIE 世界博览会 2026：AI 工程的重心从造智能体转向造智能体周围的系统

今年的 AIE 世界博览会透露出一个明显转向：工程师们不再只盯着怎么造一个更聪明的智能体，而是开始认真搭建智能体周围的那套系统。Lilian Weng 的新文章把这套东西叫做“缰绳”——管工作流、管上下文、管权限、管评估，还要管持续改进。三年前大家还在热议 AutoGPT，今年现场几乎没人提了，取而代之的是 Claude Code、Codex 和 Cu...

推荐理由：Latent Space 从 AIE 世界博览会抓到的趋势总结有真东西。Lilian Weng 的“缰绳”框架把散落的观察拧成了一根系统级的绳子，对正在落地 agent 工作流的工程师来说，能直接拿来对照自己的架构。扣分是因为这毕竟是一篇会议综述，没有一手实验数据，但作为方向判断，值得一看。

锐评

今年 AIE 世界博览会最明显的变化是，工程师的注意力从造更聪明的模型，转向了搭建模型周围那套可靠的系统。Lilian Weng 的新文章把这套东西叫做“缰绳”，管工作流、管上下文、管权限、管评估，还要管持续改进。三年前她还在拆解单个智能体的结构，现在则认为外围系统至少和模型本身一样重要。现场讨论的热点也变成了 Claude Code、Codex 和 Cursor 这类工具，以及让编程助手在生产环境稳定运行的基础设施。

一个关键判断是，完全的智能体自主不仅不可靠，在规模化场景下甚至不受欢迎。OpenAI 的 Romain Huet 在演讲里也强调，工具是用来增强工程师，而不是取代他们。不过，文章正文只详细展开了前两个趋势，剩下三个被截断了，我们没法知道大会还讨论了哪些具体方向。另外，这些判断主要来自现场观察和一篇个人博客，缺少更量化的数据支撑，比如实际落地项目的成功率或故障率。

AI HOT 精选7/15 07:01

OpenAI Codex 周活破 700 万，两个月塞了 150 多项更新

OpenAI 的编程助手 Codex 现在每周有超过 700 万人在用，过去两个月更新了 150 多项功能。比较能打的有：GPT-5.6 和 Ultra 模型可以并行跑任务；新加的 /goal 指令能把一个目标自动拆成执行步骤；电脑操作速度更快了；AppShots 和内联编辑也上了；还能直接用 Sites 搭网页，支持移动端和 SSH 工作流，以及从代...

推荐理由：Codex 周活冲到700万，两个月塞了150多项更新，产品节奏很猛。GPT-5.6 并行执行、/goal 自动拆任务、AppShots、内联编辑这些功能都有明确的技术指向，不是空泛的“升级”。分数定在78而不是更高，因为这是官方口径，没有第三方验证，实际体验和稳定性还得看用户反馈。

锐评

OpenAI 自己发推说 Codex 现在每周有超过 700 万人在用，过去两个月更新了 150 多项功能。这个更新频率很高，平均一天超过两项，说明团队在快速迭代。比较值得关注的是 GPT-5.6 和 Ultra 模型可以并行跑任务，相当于让两个模型同时干活，理论上能缩短等待时间。新加的 /goal 指令能自动把一个目标拆成执行步骤，这有点像让模型自己规划工作流，对复杂任务可能有用。

但这条推文是官方宣传口径，没披露任何性能数据。并行跑任务到底快了多少、/goal 拆步骤的准确率怎么样、移动端和 SSH 工作流的稳定性如何，这些全都没提。700 万周活这个数字也没说明是付费用户还是包括免费试用，参考价值要打个折。

对想上手试的人来说，现在缺的是第三方实测对比，尤其是并行模式和 /goal 在实际项目里的表现。如果这些功能真像说的那么好用，开发流程确实能省不少事，但在看到独立评测之前，先别太激动。

最新精选

7月17日星期五

7月16日星期四

7月15日星期三