YOHO AI

标签： AI

  • 三星把话说明白了：内存荒2027年更糟，2028年之前别指望缓解

    如果你最近打算换手机、加内存条或者买显卡，可能得做好心理准备：这轮涨价短期内不会结束，而且还要更贵。

    三星电子
    三星供应着全球约三分之一的内存芯片 | 图片来源：TechCrunch

    三星在二季度财报电话会上给出了一个相当悲观的时间表：眼下的内存芯片短缺不但会延续到明年，2027 年还会进一步加剧，供应紧张的局面至少要持续到 2028 年。说这话的分量不轻——三星自己就供应着全球大约三分之一的内存芯片。

    AI 实验室开始直接把未来几年的需求交给三星

    三星在会上透露了一个此前不太常见的细节：那些急着抢内存资源的前沿 AI 实验室，已经在直接向三星“共享它们的中长期需求预测”，目的就是提前锁定未来的供货。

    需求太旺，让三星可以优先照顾那些愿意签长期合同的客户。多年期的能见度意味着它可以放心装设备、拉产能，不必担心需求突然消失。

    这一点比涨价本身更有意思。内存一直是典型的周期性行业，涨一波、扩一波产、然后崩一波，几十年来都是这个节奏。现在下游客户主动把几年后的用量报上来换供货优先级，等于把这门生意从“赌行情”变成了“接订单”。三星显然乐意接受这种转变。

    芯片部门创纪录，手机部门被自家芯片吃掉利润

    涨价对三星来说是把双刃剑。二季度半导体业务销售额创下历史新高，但手机和电视部门的盈利能力反而缩水了——因为它们要用更贵的元器件。

    三星的应对是把成本往下游传：Galaxy 手机和平板已经提价。代价也很直接，这些设备的需求随之下滑。左手挣的钱，右手在赔。

    “RAMaggedon”正在给整条消费电子链条加价

    这轮短缺被业内戏称为 RAMaggedon（RAM 版世界末日），受影响的远不止三星自己。

    • 苹果上个月上调了 MacBook、Mac 和 iPad 的价格，iPhone 暂时没动；最新一季财报会上，苹果把下季营收同比增速的预期下调到 9% 到 11%，而此前几个季度是 16%。
    • 英伟达的消费级显卡预计要涨 20% 到 30%，这会顺着链条传导到游戏本、台式机、主机等一大批产品。
    • 存储厂商正在把产能从消费电子挪向 AI 数据中心，这才是价格上行的真正源头。

    这不是短缺，是一场重新分配

    把这些拼在一起看，“缺货”其实是个不太准确的说法。晶圆产能没有凭空蒸发，它只是被挪到了利润更高的地方。数据中心愿意为 HBM 和高端内存付出的价格，消费电子厂商跟不上，于是普通消费者手里的产品自然被排到了后面。

    换个角度说，AI 基建的账单正在以一种非常间接的方式，摊到每一个买电脑、买手机、买显卡的人头上。你并没有为哪个大模型付费，但你多花的那几百块，确实流向了同一条产业链。

    还有一个值得留意的风险：长期合同锁产能，前提是 AI 需求真的能兑现到 2028 年。三星现在按客户报上来的预测去扩产能，如果哪天这些实验室的融资节奏或者算力规划出现变化，那批设备就会在最不该的时候一起转起来。周期性行业最惨的不是缺货，是缺完之后一起过剩。眼下没人愿意讨论这一段，但它一直在时间表的另一头等着。

  • 320万粉丝的科普博主道歉：用ChatGPT查资料被抓包，他说自己对AI上瘾了

    一句听着有点别扭的话，把一个做了十几年科普的博主推到了风口浪尖。

    YouTuber Hank Green
    Hank Green 承认自己对大模型的依赖已经失控 | 图片来源：TechCrunch / Getty Images

    Hank Green 是 YouTube 上的老牌创作者，写小说、做脱口秀、拍科普，主频道有 320 万订阅。前几天他在教育向频道 Complexly 的一期视频里，突然冒出一句“我很感谢你提出的反驳”。这句话放在上下文里怎么听怎么怪，观众立刻反应过来——这更像是对着聊天机器人说的话，而不是对着摄像头。

    接下来的推测顺理成章：稿子是不是 AI 写的？他是不是不小心把跟模型对话的内容念了出来？

    先删帖，再长文道歉

    Green 最初在 X 上回应，说这期视频是“在巨大压力下”做出来的，自己确实用 ChatGPT “为这期稿子做了研究”，但那句“感谢反驳”其实是说给节目嘉宾听的，不是念提示词。这条帖子后来被他自己删了。

    真正让事情转向的是他随后在 Reddit 上那篇更长的道歉。他说自己“羞愧难当”，觉得“辜负了太多人”，并且宣布要减少视频产量。

    他为自己划了一条线：AI 只被用来“定位论文和学习某个主题所需要的资料”，视频里的文字和观点仍然是他自己的。但他同时承认，观众批评他“稀释了自己”，这个说法是公平的。

    我最害怕的，是把我自己给毁了——毁在观众心里。但我一直没能管好自己的冲动。你们需要知道，我说的话是我自己的。我不认为过去这件事不成立，只是我跑得太快，连我自己都说不清自己的创作流程了，我希望往后这能成为一种保证。

    他承认的其实不是抄袭，是上瘾

    这场风波里最狠的一句话，出现在道歉的结尾。Green 说，他必须面对一个事实：从跟大模型互动中获得的多巴胺，那种“做得更多、更多、更多”的感觉，对他自己和这个世界都不是好事，“它是轻率的，而且已经让我跟大多数人的真实感受脱节了”。

    他还特意声明自己“不是纯粹的 AI 憎恨者”，但列了一串担忧：这套技术对气候的影响，以及这些公司“试图集中经济权力的速度”。

    换句话说，他并不是被抓到造假才认错。他认错的点在于：工具让他产量变高、反馈变快、爽感变强，于是他不知不觉把自己交了出去，等回过神来，连自己是怎么写出这些东西的都讲不清了。

    接下来他打算怎么做

    • 暂停或大幅降低几个 YouTube 频道的更新频率，先把节奏慢下来。
    • 多做那种“写作本身就是全部”的内容，他提到自己最近一期偏冥想气质的视频，说那种东西他“从头到脚都感受得到”。
    • 多录不写稿、直接对着镜头说的即兴内容——用他自己的话讲，“我那些傻乎乎的、没稿子的念头”。

    这几条听起来都是在做减法，而且是往效率的反方向走。

    创作者和观众之间，卖的从来是“这是他本人”

    严格说，用 AI 找论文、整理资料，这在今天几乎算不上什么罪状。很多研究者、记者、编辑都在这么干，效率提升是实打实的。Green 被骂得这么惨，问题不在工具本身，而在他和观众之间那份心照不宣的契约——大家看他，是因为相信屏幕后面那个人在认真想问题，而不是在高效地组装信息。

    科普这门手艺尤其吃这一套。观众记住的不是某个知识点，而是“这个人是怎么理解这件事的”。一旦中间插进一个把资料嚼碎了递过来的中介，哪怕最后落笔的还是本人，那种“我陪你一起想明白”的质感就会掉一截。

    更值得琢磨的是他说的多巴胺。屏幕时间、短视频、社交推送这些成瘾机制大家已经聊烂了，但“跟模型对话本身会上瘾”还是个新话题。它给的不是娱乐快感，是一种“我正在产出、我很高效、我停不下来”的错觉。对一个靠持续产出吃饭的创作者来说，这种反馈回路可能比刷手机更难摆脱。

    Green 选择的解法是慢下来、少做点、把过程重新抓回自己手里。这在一个按更新频率算命的平台生态里，几乎是逆行。他能坚持多久不好说，但至少他把问题摆到了台面上：不是“AI 能不能用”，而是“我用完之后，还认不认得出自己写的东西”。

  • colibri：用纯 C 把 744B~2.8T MoE 大模型跑到本地

    colibri：用纯 C 把 744B~2.8T MoE 大模型跑到本地

    colibri 是近期 GitHub 上热度最高的本地推理引擎之一：只用纯 C 编写、零运行时依赖，就能把 744B 到 2.8T 参数的 MoE（混合专家）大模型跑在你现有的硬件上。它不是把模型硬塞进显存，而是把 VRAM、RAM 和 NVMe 当作同一层级来管理，按需从磁盘流式加载专家权重。项目上线一个月已收获 21.9K Stars，并支持 GLM-5.2、Inkling、Kimi K3、OLMoE 四大模型家族。

    本期我们就来拆解：colibri 是怎么让“本地运行千亿 MoE”这件事从神话变成可复现实验的。

    项目简介

    colibri 是一个面向前沿 MoE 模型的本地推理引擎。它用“存储即内存层级”的思路替代传统的“模型必须全进显存”假设：密集注意力层常驻 RAM，19456 个路由专家放在磁盘，只有在路由器真正需要时才被预取到 RAM/VRAM。这样一台只有 25 GB 内存的常规电脑也能把 744B 的 GLM-5.2 跑起来，而高端工作站则可以把全部专家驻留 GPU，达到接近数据中心的吞吐。

    配图速览

    colibri 核心速览
    colibri 核心数据一览
    三层存储层级
    colibri 把专家权重分布在 VRAM / RAM / NVMe 三个层级，速度随硬件变化，语义保持不变。

    安装要求和过程

    环境要求

    • 操作系统：Linux、macOS、Windows 11
    • 内存：最低 25 GB RAM（仅 CPU 流式）；推荐 128 GB 或更高，配合多 GPU 可获得更好体验
    • 磁盘：GLM-5.2 int4 容器约 372 GB；Kimi K3 原始检查点约 1.6 TB
    • 软件：Python 3（仅用于 launcher 和转换脚本）；编译源码需要 gcc/clang + OpenMP
    • GPU（可选）：CUDA、Metal（Apple Silicon）、Vulkan 1.2（含 AMD RADV）后端均可选

    快速安装

    1. 下载对应平台的预编译 release 并解压：
    mkdir colibri && tar xzf colibri-v1.1.0-linux-x86_64.tar.gz -C colibri && cd colibri
python3 coli info
    1. 或从源码构建：
    git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh
    1. 下载 GLM-5.2 int4 gs64 容器（推荐带 int8 MTP 头的版本）：
    # 推荐从 Hugging Face 拉取 mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp
# 约 372 GB，放 NVMe 上最佳
    1. 运行交互式聊天、API 服务或 Web 面板：
    COLI_MODEL=/nvme/glm52_i4 ./coli chat
COLI_MODEL=/nvme/glm52_i4 ./coli serve    # OpenAI-compatible API
./coli web --model /nvme/glm52_i4          # API + 可视化 dashboard

    核心功能

    1. 存储即内存层级
      把 VRAM、RAM、NVMe 统一成专家权重的放置策略。缺显存不会悄悄改模型精度或路由语义，只会影响速度。
    2. 按需流式加载专家
      MoE 每层只激活少量专家。colibri 让 19456 个专家中的绝大部分常驻磁盘，通过 per-layer LRU、学习到的热专家 pinned set 和一层提前预取（PILOT）减少磁盘等待。
    3. 纯 C 零依赖引擎
      每个模型对应一个 C 文件（如 c/glm.c），无 BLAS、无运行时 Python、无 GPU 也能跑。
    4. 多后端异构执行
      支持 CPU、CUDA、Metal、Vulkan 四种后端，可组合使用；双 SSD 镜像可把只读专家读取带宽翻倍。
    5. 学习缓存与压缩状态
      引擎记录你的工作负载路由历史（.coli_usage），越用越快；MLA KV 状态压缩到原来的 1/57，并能持久化对话上下文。

    典型使用场景

    场景一：个人开发者跑前沿模型做实验

    你只有一台 64 GB RAM + 1 TB NVMe 的台式机。传统 vLLM/llama.cpp 会把 744B 模型拒之门外；colibri 让你用 COLI_MODEL=/nvme/glm52_i4 ./coli chat 直接对话，虽然 token/s 不高，但足以做提示工程、长文本探索和小批量评估。

    场景二：工作室搭建本地私有 API

    在多卡工作站（如 6× RTX 5090）上，把专家全部驻留 GPU，colibri 可提供 5.8–6.8 tok/s 的解码速度和 1.6 s 的 TTFT。通过 coli serve 提供 OpenAI-compatible API，内部团队就能在不联网的情况下调用千亿模型。

    场景三：MoE 推理系统研究

    colibri 把放置策略、调度、I/O、CPU/GPU 重叠都做成可测量的实验参数。研究者可以替换缓存策略、测试双 SSD 镜像、评估 int4/int8/MXFP4 格式对质量的影响，并把结果以 issue 形式回馈社区。

    推荐理由

    colibri 最打动我的不是“跑 744B 模型”这个噱头，而是它把“本地推理”重新定义为系统优化问题：不盲目堆硬件，而是认真测量每一个瓶颈——磁盘带宽、专家命中率、KV 压缩、CPU/GPU 重叠、量化质量——并用可复现的 A/B 来做决策。README 里反复出现的不是营销数字，而是“这个功能在哪台机器上、用什么 commit、跑什么 prompt 测出来的”。

    对于国内用户，它还有一个隐性好处：GLM-5.2、Kimi K3、Qwen3 MoE（roadmap）等模型天然和中国模型生态更近，未来可以更低成本地跑开源中文大模型。

    当然，它现在还是研究导向的项目：没有 SLA 保证速度，配置参数很多，对磁盘和内存仍有一定要求。但如果你既想摸到前沿模型，又不想把数据送出去，colibri 是 2026 年最值得关注的本地推理引擎之一。

    下载地址

  • 全美只有约 2000 人干得了这活：AI 行业最抢手的岗位，不是训模型

    企业 AI 落地与前置部署工程师
    企业把模型装进流程，比买到最好的模型难得多｜图片来源：TechCrunch / Getty Images

    猎头公司 Christian & Timbers 做了半年调研，得出一个挺刺眼的数字：全美真正具备“行业理解 + 能镇得住客户高管 + 有实打实 AI 落地经验”这三样的工程师，大约只有 2000 人。

    不是有 2000 人可以挖，是总共就 2000 人。

    这份独家给到 TechCrunch 的研究，访谈了 180 家公司的 250 多位 C 级招聘负责人，对 80 位财富 500 强高管做了定向问卷，还聊了 300 多位一线工程师，时间跨度是今年 1 月到 6 月。

    半年时间，招人意向从 5% 冲到 70%

    他们盯的这个岗位叫前置部署工程师（forward-deployed engineer，FDE）——不待在自家办公室写代码，而是直接扎进客户公司里，把模型和软件真正接进对方的业务流程。年初还只有 5% 到 10% 的公司说要招，而且多半只是小规模试点；到第二季度末，这个比例跳到了 70%。几家最大的咨询与服务公司甚至说，FDE 人数得扩到原来的十倍，要按 20 到 100 人的规模组建整建制团队。

    “这个速度我从没见过，企业大夏天的都在抢人。”C&T 创始人 Jeff Christian 这么形容。研究预计，到今年年底 FDE 的需求量会暴涨 2100%。

    Palantir 成了人才池，有客户为了挖人先买产品

    市面上大约有 1.7 万名 FDE，其中相当一部分在 Palantir——这个岗位当年就是它发明的。Christian 说，他的一些客户干脆先买下 Palantir 的产品，图的就是能顺带用上人家的工程师。

    但这 1.7 万人里，够得上“顶级”标准的只是一小撮。所谓够格，如今的衡量口径是能带来“几千万美元量级的 ROI 影响”，可能是营收端的线索生成提速，也可能是替掉整个 FP&A 团队，或者顶替印度那边 2300 名单据处理人员。Ode with Anthropic 的 CEO Chris Taylor 把这个门槛说得更直白：很多 FDE 有能力帮你把 Claude Code 推给全公司用，但能亲手做出你旗舰 AI 产品功能的，没几个。

    今年秋天，华尔街要开始算账了

    抢人抢得这么急，根子在钱。企业过去两年砸下去的 AI 预算，到了要交答卷的时候。

    今年秋天华尔街差不多要开口了：我们给了你们两年时间去搞明白这件事，你们没搞明白，没有 ROI。那我们就要开始惩罚那些花了几亿甚至几十亿却没产出的公司，奖励那些做出来的。

    模型厂商同样在挨这一刀。训练和部署已经烧掉几百亿美元，能不能盈利，取决于技术能塞进多少家企业；而中国那边越来越能打的开源权重模型，还在从下面撬价格。这也是 OpenAI 和 Anthropic 各自成立服务公司的原因——Anthropic 那边是 Ode，OpenAI 那边叫 Deployment Company，两家都塞满了 FDE，任务就是把自家技术铺出去。

    企业开始自己养人，怕的是流程外泄

    有意思的是，从保险、金融科技到医疗、游戏，不少企业宁可自己组建 FDE 团队，也不愿意从 Ode 或 Deployment Co. 那里整包采购。理由很实在：把自家专有业务流程交出去，等于给潜在竞争对手递图纸。Christian 说，大家担心的是“这些 AI 公司拿到流程之后回头跟你抢生意”，而这种担心在很多领域是成立的。Taylor 也开始频繁听到一个新说法——“内部前置部署工程师”。

    • 顶级 FDE 全美约 2000 人，市面总量约 1.7 万，Palantir 占大头。
    • 企业招聘意向半年内从 5%–10% 升到 70%，大型服务商计划扩编十倍。
    • 衡量标准已经从“会用模型”变成“能带来几千万美元 ROI”。
    • 企业倾向自建团队，核心顾虑是专有流程被模型厂商反向吃掉。

    不过这个岗位未必是长期饭票。Christian 自己就泼了盆冷水：也许两年后一切都自动化了，是智能体在自动化智能体，而不是人在自动化智能体。中期他判断需求会从企业软件转向“物理 AI”，比如把人形机器人接进产线；再往后五到十年，FDE 这个角色可能干脆消失。

    所以现在这场抢人，更像是行业从“谁的模型最强”切换到“谁能把模型变成钱”过程中的一段短暂窗口。窗口里，懂业务又会动手的人被抬到了天价；窗口关上之后，被自动化掉的可能恰恰是他们自己。

  • Sam Altman 教人用 ChatGPT 带娃，一句“你怎么不直接跟孩子说话”把他顶上热搜

    Sam Altman
    OpenAI CEO Sam Altman｜图片来源：TechCrunch / Getty Images

    上周五，OpenAI 的 Sam Altman 在 X 上分享了一个他自己觉得“挺酷”的用法：把全家的日历接进公司新推出的 ChatGPT Work，再告诉它每个孩子分别喜欢什么，然后每天早上开车送孩子上学的路上，让它现做一档播客——聊聊老大下午的足球赛、老二快到的生日，中间再插几条新闻。

    把你们家的日历连上，解释一下孩子们的兴趣，然后每天早上送孩子上学的路上，让它做一档播客。

    他大概以为这条帖子会收获一片“真香”。结果评论区集体翻白眼。动画剧集《怪诞小镇》的主创 Alex Hirsch 只回了一句话：那你为什么不直接跟你的孩子说话呢？

    一句反问，比原帖火了十几倍

    数据比争论更能说明问题。截至周六上午，Altman 那条帖子被转发约 300 次、点赞 9600 左右；Hirsch 的那句反问，转发 9000 次、点赞 12.2 万。差了十几倍。这已经不是“功能好不好用”的技术讨论了，而是很多人对“连亲子对话都要外包给模型”这件事的本能反应。

    硅谷高管其实早就在干同一件事

    用 AI 把通勤路上那点“低效时间”填满，Altman 不是第一个。去年微软 CEO 纳德拉说，他早上开车已经不听自己喜欢的播客了，改成让聊天机器人给他讲这些播客讲了什么。Altman 本人也在《吉米·法伦今夜秀》上感慨过：“我没法想象，如果没有 ChatGPT，我要怎么搞定养一个新生儿。”不过他当时也补了半句——“显然，人类养孩子养了这么多年，也没出什么问题。”

    “家庭”是 OpenAI 明确要拿下的入口

    调侃归调侃，OpenAI 在这个方向上是认真的。公司最近挂出一个产品经理岗位，要求候选人有为父母和家庭做“高信任度消费级产品”的经验。差不多同一时间，Meta 也在测试一款专门用 AI 讲睡前故事的应用。家庭日程、育儿焦虑、辅导作业——这些是聊天机器人最容易长期驻扎下来的场景，谁都看得明白。

    但这条线上，OpenAI 还有旧账没结

    公司这两年确实给家长端加了不少东西：家长控制、敏感对话的安全分流机制都上了。可另一头，OpenAI 正面临多起来自家长和家属的诉讼，指控 ChatGPT 在亲人的妄想与自杀事件中起了作用。公司的回应一直是那句话：正在“持续改进模型在敏感互动中的回应方式”。在这种背景下发一条“让 AI 帮你了解孩子”的帖子，观感确实微妙。

    • Altman 的建议本质上是 ChatGPT Work 的场景演示，指向的是把订阅卖进家庭。
    • 反弹的焦点不是功能能不能实现，而是“该不该把亲子关系交给产品”。
    • OpenAI 一边招家庭方向的产品经理，一边在应对家长起诉，两条线同时推进。

    说到底，Altman 展示的是能力，网友抵触的是分寸。让模型把一家人的日程整理成一段十分钟的播客，技术上完全成立，甚至真的挺方便；但如果连“今天孩子有场球赛”这种事都得靠工具提醒，省下来的那点时间到底换回了什么，就不太好算了。硅谷习惯把生活里的摩擦当成待优化的 bug，而很多人恰恰认为，那些摩擦本身就是生活。

  • TRELLIS.2：微软开源 4B 参数图像到 3D 生成模型，3 秒生成高保真纹理资产

    TRELLIS.2：微软开源 4B 参数图像到 3D 生成模型，3 秒生成高保真纹理资产

    TRELLIS.2

    项目简介

    TRELLIS.2 是微软研究院开源的 4B 参数大规模 3D 生成模型，专注于图像到 3D（image-to-3D）资产生成。它抛弃了传统等值面场的限制，提出一种名为 O-Voxel 的“无场”稀疏体素结构，能够原生重建和生成具有复杂拓扑、锐利细节以及完整 PBR 材质的 3D 模型。

    安装要求和过程

    目前官方仅验证过 Linux 环境，GPU 显存至少 24GB（推荐 A100 / H100），需要 CUDA 12.4 和 Conda。

    1. 克隆仓库： 
      git clone -b main https://github.com/microsoft/TRELLIS.2.git --recursive
cd TRELLIS.2
    2. 创建 conda 环境并安装依赖： 
      . ./setup.sh --new-env --basic --flash-attn --nvdiffrast --nvdiffrec --cumesh --o-voxel --flexgemm
    3. 从 Hugging Face 下载 4B 预训练权重：
      https://huggingface.co/microsoft/TRELLIS.2-4B

    核心功能

    • 高保真生成：40 亿参数 DiT 模型 + 16× 下采样稀疏 3D VAE，可直接生成 512³ 到 1536³ 分辨率的带纹理 3D 资产。
    • O-Voxel 拓扑自由：原生支持开放曲面、非流形几何和内部封闭结构，无需像传统 NeRF/SDF 那样进行有损转换。
    • PBR 材质建模：不仅生成基础色，还输出 Roughness、Metallic、Opacity 等属性，支持透明与真实感渲染。
    • 极简后处理：纹理网格转 O-Voxel 单 CPU <10 秒，O-Voxel 转纹理网格在 CUDA 上 <100 毫秒。
    • 完整训练代码：开源 SC-VAE、形状/纹理 Flow Model 训练脚本，可用 Objaverse-XL 等数据从头训练或微调。

    TRELLIS.2 核心特性

    典型使用场景

    • 游戏/影视资产快速出稿：原画师只需提供一张概念图，即可在数秒内获得带 PBR 材质的可用 3D 模型，大幅缩短原型迭代周期。
    • 电商/虚拟展示：把产品照片自动转换为可旋转的 GLB 3D 资产，用于网页 AR、虚拟展厅和商品详情页。
    • 3D 内容创作者工具链：结合 ComfyUI、Blender 等工具，将 TRELLIS.2 作为 AI 建模节点，批量生成风格化道具和场景元素。

    推荐理由

    TRELLIS.2 给我的最大惊喜是“快”和“全”：快在 H100 上 3 秒就能跑出 512³ 的高质量模型；全在从模型权重到训练代码全部开源，还配有 Hugging Face Demo。相比之前很多只能生成封闭几何体的方案，它对开放曲面、衣物、叶片等复杂拓扑的处理明显更稳。对于想要在本地做 3D AIGC 的同学来说，这是目前最值得入手的工程基座之一。

    下载地址

  • AI 基建狂飙，最不性感的生意反而火了：帮工地填表的 Dili 融了 2170 万美元

    这两年关于 AI 的钱，大头都砸在数据中心和电力设施上。有人从另一头看到了机会：这么多工地同时开工，光是把各类合规文件填对、报齐，就够养活一家公司。

    美国数据中心与基础设施建设现场
    图片来源：Kyle Grillot/Bloomberg / Getty Images

    7 月 30 日，一家叫 Dili 的 AI 合规公司宣布完成 1500 万美元 A 轮融资。加上此前的 670 万美元种子轮，累计融资 2170 万美元。A 轮由 Khosla Ventures 领投，安联（Allianz）、Rebel Fund、Brick and Mortar Ventures 的 Darren Bechtel 以及 Y Combinator 的 Garry Tan 跟投。Dili 出自 YC 2023 年夏季批次。

    它盯上的是一堆没人愿意读的规则

    “用 AI 做合规”现在算不上什么新鲜提法，一抓一大把。Dili 的差异在于它把范围收得很窄——只做美国基建工程的合规，尤其是那些拿了联邦资金的项目。

    联合创始人兼 CEO Anand Chaturvedi 举的例子是 Davis-Bacon 法案，这套规则允许劳工部为特定项目设定现行工资标准。另一套叫 PWA 的现行工资与学徒制规则，适用于《通胀削减法案》资助的清洁能源项目。除此之外，根据施工内容不同，还会牵扯 OSHA 的职业安全条款和 EPA 的环保规定。

    这些要求层层叠叠、互相交错，而且犯一点小错代价就不小。

    “不合规可能让这些项目被罚掉数百万美元。所以能在信息进来的当下就全部核对一遍，而不是抽样检查，这件事的价值非常大。”——Dili 联合创始人兼 CEO Anand Chaturvedi

    抽样和全量的区别，就是这门生意的入口。人工审核只能抽查，成本摆在那儿；机器读得快，才有可能一条不落。

    大模型被关在数据层，不让它拍板

    罚款以百万美元计，可靠性就成了绕不过去的坎。做合规最怕的恰恰是大模型那点”差不多就行”的毛病——它给你一个听起来很像回事的答案，你还不知道错在哪。

    Chaturvedi 说 Dili 的架构从设计上就把这个风险堵住了：AI 模型只在数据层出现，负责把非结构化的文档翻译成结构化数据；再往后，由一套确定性系统按照复杂但静态的合规规则做分拣判定。

    • AI 负责”读懂”——处理 PDF、扫描件、工资表这类乱七八糟的输入；
    • 规则引擎负责”判定”——同样的输入永远得到同样的结论，可追溯、可复核；
    • 结果是过去一整天的工作量，现在几分钟就能跑完。

    这个分工看着朴素，却是当下企业级 AI 里少见的清醒做法。很多产品恨不得把判断权也交给模型，因为那样演示起来更炫；Dili 反过来，把模型能力限制在它最擅长也最不容易出事的环节。

    Chaturvedi 描述过他想要的那个状态：把一家公司所有内部文档、所有供应商文档、所有 ERP 信息、所有工资系统数据放在一起通读，然后精准抽出报表或合规所需要的那部分。

    700 个项目，一半自用一半外包

    这套东西已经跑起来了。Chaturvedi 说软件目前用在”大约 700 个项目”上，从制造工厂到数据中心都有。

    更有意思的是收入结构：大约一半客户把 Dili 当成内部软件工具用，另一半干脆把整个合规流程外包给 Dili，按承包商模式合作。两种合同 Dili 都接，但 Chaturvedi 预计行业未来几年会更多往软件模式偏。

    他的判断是，软件和 AI 会开始吃掉大量专业服务类的工作流，越来越多的公司会把这些活收回自己手里。这话说白了就是：现在的外包收入，本质上是过渡期的红利。

    这轮 AI 淘金热的另一种铲子

    AI 基建的故事讲了两年，主角一直是芯片、机柜、变电站。Dili 提醒了一件常被忽略的事：任何一轮大规模基建，配套长出来的都不只是钢筋水泥，还有一整套文书工作。工地越多，表格越多，罚单风险越大。

    Khosla 愿意领投一家做工地合规的公司，赌的也是这个——AI 泡沫会不会破是一回事，那 700 个工地上的 Davis-Bacon 表格今天就得交。这类需求不依赖模型能力再上一个台阶，也不需要客户相信 AGI，它只需要基建热潮持续开工。在满屏”下一代模型”的叙事里，这可能反倒是更耐摔的一门生意。

  • 三大唱片公司联手出手：AI 做的歌，别想上榜

    七月的最后一天，环球音乐、索尼音乐、华纳音乐这三家握着全球录制音乐大半江山的公司，拉上 Believe、BMG、Concord、Dirty Hit、Glassnote、HYBE、Mom+Pop、Partisan 等一串厂牌，抛出了一份关于 AI 歌曲能不能进官方榜单的提案。答案写得很干脆：基本上，不能。

    AI 音乐概念图
    图片来源：The Verge / Shutterstock

    提案画了六条线

    这份被国际唱片业协会（IFPI）公开背书的全球原则，核心是一段”排除条款”式的表述——不是列出什么歌可以上榜，而是规定只要有理由怀疑某首歌不满足全部条件，榜单就不该收它。

    使用生成式 AI 服务制作的录音，若有理由认为其未能同时满足以下全部标准，就不应被纳入官方榜单：所使用的生成式 AI 服务获得了适当授权且合法；作品实质上由人类创作；不存在播放量或榜单操纵方面的疑虑；符合版权、邻接权、人格权等适用法律；作品的发行不违反所用生成式 AI 服务的服务条款；在下游平台（如流媒体服务）上，已按照适用法规和行业标注标准，向消费者适当标示了生成式 AI 的使用。

    六条里，前四条勉强还能靠合同和法务去核对，第五条属于平台自查，唯独第二条——”实质上由人类创作”——像一句留白。

    “实质上由人类创作”到底怎么算

    The Verge 的周末编辑 Terrence O’Brien 在稿子里连着两次把这个词组拎出来，后面跟一句”whatever that means”（谁知道这是什么意思）。他的不耐烦挺有道理：一首歌用 AI 补了一段和声算不算？人写词写旋律、AI 编曲混音算不算？歌手用 AI 修音准这种早就普及十几年的操作，又划到哪一边？

    同样悬着的还有”榜单操纵疑虑”。刷流量本来就是老问题，跟 AI 没有必然关系，把它塞进这套原则里，等于给榜单方多开了一个可以自由裁量的口子。The Verge 就此向索尼音乐、环球音乐和 Mom+Pop 求证，三家都没有第一时间回应。

    标准模糊在行业提案里并不罕见，有时甚至是刻意的——先把大方向立住，细节留给后面谈。但音乐榜单是个要给出确定名次的东西，模糊的准入条件迟早要落到某个具体判断上：某首歌到底进不进。

    比”贴标签”那套激进得多

    做个对照。此前 RIAA、IFPI、SAG-AFTRA 等机构推过一套标注方案，思路是给 AI 生成和 AI 辅助的音乐设计标准化标签，把判断权交还给听众——你知道这是 AI 做的，听不听随你。

    厂牌这份新提案把标注要求原样保留了，然后在后面加了一道闸门：标了还不够，不达标就别想进榜。

    • 标注方案管的是知情权，属于信息披露；
    • 厂牌提案管的是资格，属于市场准入；
    • 前者让 AI 歌曲和人类作品同场竞技，后者直接把它们分到两个赛道。

    这两种思路背后是完全不同的判断。标注派默认 AI 音乐会长期共存，得想办法把它纳进现有秩序；厂牌派则更接近于说，这批东西暂时不配和人类作品放在一张榜上排名。

    榜单机构还没接招

    提案发出来了，IFPI 也把分量压了上去，但截至目前没有任何一家榜单机构表示要采纳，Billboard 那边也只是照常报道了这件事。这其实是整件事最关键的一环——原则写得再齐整，最终拍板的是 Billboard、Official Charts 这类机构，而它们要考虑的东西比厂牌复杂：一旦立规，就得有能力去核查每一首上榜歌的制作过程，这个成本谁来出。

    更微妙的是，三大厂牌自己也在跟 AI 音乐公司谈合作、谈授权。今天要求”实质上由人类创作”，明天如果自家艺人用授权模型做了一张专辑，这条线又该往哪儿挪。规则是他们提的，第一个被规则绊住的很可能也是他们。

    争的其实不是榜单

    榜单在今天早就不只是一份排行。它决定电台歌单、决定播放列表推荐权重、决定演出报价、决定唱片公司内部资源怎么分。把 AI 歌曲挡在榜单之外，等于挡住了一整条商业化通道。

    所以这份提案与其说是内容治理，不如说是分配权之争。真正的问题从来不是”AI 能不能做歌”——它已经在做了，而且有人在听。问题是这些歌能不能被算进那套沿用了几十年、分配着真金白银的计分体系里。厂牌给出的第一版答案是不能，接下来就看榜单机构愿不愿意接。

  • OpenWiki —— LangChain 出品的自我维护 Wiki CLI，让 Agent 为你写文档

    OpenWiki —— LangChain 出品的自我维护 Wiki CLI，让 Agent 为你写文档

    项目简介

    OpenWiki 是 LangChain 团队开源的「自我维护 Wiki CLI」——一个命令行工具，让 AI Agent 自动为你的代码库或个人知识库撰写并持续维护 Markdown 文档。它内置 Deep Agents 文档智能体，读取源码后合成带链接的 Wiki，每次代码变更都能自动更新；同时提供交互式可视化节点图，让你像浏览思维导图一样探索整个知识体系。

    一句话总结：「为 Agent 写的文档，给人读的 Wiki。」

    OpenWiki
    OpenWiki — 自我维护的 Wiki

    安装要求与快速上手

    环境要求

    • Node.js ≥ 18（推荐 LTS 版本）
    • npm / pnpm 包管理器
    • 任一 LLM 提供商 API Key（首次运行时引导配置）

    安装步骤

    # 全局安装 CLI
npm install -g openwiki

# 初始化代码库文档（交互式选择模型提供商）
openwiki --init

# 一键更新文档
openwiki --update

# 启动可视化浏览器
openwiki visualize

    个人知识库模式

    # 初始化个人大脑模式
openwiki personal --init

# 认证数据源连接器
openwiki auth notion      # Notion OAuth
openwiki auth gmail       # Gmail OAuth
openwiki auth x           # X/Twitter OAuth

# 执行全量数据摄取并生成 Wiki
openwiki ingest all

    核心功能

    OpenWiki 核心速览

    1. Agent 驱动的自动文档生成

    基于 LangChain Deep Agents 框架的文档专用智能体，自动分析源码结构、模块依赖、函数签名和业务逻辑，生成结构化 Markdown 文档。支持 .openwikiignore 规则排除敏感路径（类似 .gitignore），确保私有信息不泄露。

    2. 双模式：Code Wiki + Personal Brain

    • Code 模式（默认）：扫描当前仓库，输出到 openwiki/ 目录，同时维护根目录的 AGENTS.md 和 CLAUDE.md 引导文件。
    • Personal 模式：接入 Notion、Gmail、X/Twitter、Hacker News、Web Search 等数据源，将碎片化知识合成为本地 Wiki（存储在 ~/.openwiki/wiki/）。

    3. 12+ 模型提供商开箱即用

    默认 OpenAI（gpt-5.6-terra），同时支持 Anthropic Claude、Google Gemini、AWS Bedrock、GitHub Copilot、OpenRouter、Nebius/Fireworks/Baseten/NVIDIA NIM，以及任何 OpenAI 兼容端点（Ollama、LM Studio、LiteLLM 网关等）。Copilot 用户可直接复用现有订阅，无需额外购买 API Key。

    4. 交互式可视化浏览器

    运行 openwiki visualize 即可启动本地 Web 服务，将 Wiki 渲染为交互式节点图 + 实时 Markdown 阅读器。左侧树形目录导航，右侧图谱展示概念关系，点击节点即时查看内容。编辑文件后自动热重载。

    OpenWiki 可视化界面

    5. CI/CD 自动文档流水线

    通过 GitHub Actions / GitLab CI / Bitbucket Pipelines 定时触发文档更新，每次提交自动生成 Docs PR。零成本无变更运行——OpenWiki 会快照对比，只有实际变化才记录元数据，避免 CI 积分浪费。

    6. OKF 开放知识格式 & Mermaid 图表

    输出符合 Google Open Knowledge Format (OKF) v0.1 标准，可移植到任何 OKF 兼容工具。自动在合适位置插入 Mermaid 图表（序列图、ER 图、状态机、流程图），且每次更新都验证图表有效性，损坏的图表会降级为纯文本并在下次修复。

    典型使用场景

    场景一：大型项目新人 Onboarding

    一个拥有 200+ 微服务的后端仓库，新工程师通常需要两周才能理清架构。部署 OpenWiki 后，CI 在每次合并主分支时自动更新架构文档、模块关系图和 API 速查表。新人 clone 下来后 openwiki visualize 一眼看到全局，配合 AGENTS.md 让 AI 编码助手也能精准理解上下文。

    场景二：个人知识中台

    技术负责人的知识散落在 Notion 笔记、Gmail 重要邮件、Twitter 收藏的技术讨论和 HN 热帖中。OpenWiki Personal 模式一次性接入所有源，定期 ingest all 同步，自动去重、关联、归纳成带链接的知识网络。需要回忆某个技术决策时，可视化图中一眼定位。

    场景三：Agent 记忆层

    团队使用 Claude Code 或 Codex 做日常开发，但 Agent 的上下文窗口有限，无法容纳整个代码库历史。OpenWiki 生成的 AGENTS.md 作为持久记忆层，每次 Agent 启动时自动加载 Wiki 摘要，理解架构后再动手写代码，减少幻觉和无效重构。

    推荐理由

    作为 LangChain 官方出品，OpenWiki 解决了一个非常实际的问题：文档总是过时。传统方案要么靠人肉维护（没人愿意做），要么用静态文档生成器（只管骨架不管灵魂）。OpenWiki 的思路很聪明——把「写文档」这件事交给最懂代码的 Agent，同时保留人类对文档的所有权（纯 Markdown，版本控制）。

    我个人最喜欢的三个设计：
    ① Copilot 复用——如果你已经有 GitHub Copilot 订阅，直接拿来跑推理，不用再掏钱买 API Key；
    ② .openwikiignore——安全意识很好，从根源上防止密钥泄露进文档；
    ③ 可视化节点图——不是花哨功能，对于理解陌生代码库真的有用，比翻几十个 README 快十倍。

    13K+ Stars、日增上千的趋势也说明社区对这个方向的认可。如果你正在维护一个中等规模以上的项目，或者想让 AI 编程助手更懂你的代码库，OpenWiki 值得一试。

    下载地址

  • 谷歌一个月修掉1072个Chrome漏洞，比过去两年加起来还多

    谷歌周四发了一份白皮书，里面有个数字挺扎眼：Chrome 上个月发布的两个版本，一共修掉了 1072 个安全漏洞。而在这之前的两年里，23 个版本加起来才修了 1036 个。

    一个月，超过过去两年的总和。谷歌把功劳记在了自家的 AI 工具头上。

    谷歌 Chrome 浏览器
    谷歌称 AI 工具大幅提升了 Chrome 漏洞的发现与修复速度｜图片来源：Klaudia Radecka/NurPhoto/Getty Images，via TechCrunch

    那条曲线突然立起来了

    谷歌把每个 Chrome 大版本称作一个”里程碑”。作为参照，Chrome 126 是 2024 年 6 月发布的，而最新的 149 和 150 发布于上个月。白皮书里附的那张统计图，前面两年基本是一条贴着地面的平线，到最近两个版本直接拔地而起。

    这条曲线其实是安全圈预测了好几年的东西。大模型刚火起来的时候，就有研究者提醒过：AI 会让漏洞被挖出来的速度呈指数级上升，防守方要是不跟着上 AI，就只能眼看着攻击方先一步拿到弹药。

    现在这个预测开始有数据支撑了。

    谷歌工程总监的原话

    大模型从根本上改写了网络安全的经济账，把漏洞发现变成了一件自动化、工业规模的事情。

    说这话的是 Chrome 工程总监 Doug Turner。他补了一句：靠 Gemini 这类模型，团队现在是在漏洞被利用之前就先把它补掉，”每次更新都让 Chrome 更安全一点”。

    “工业规模”这个词用得很准。以前找漏洞靠的是研究员盯着代码逐行看，或者靠模糊测试碰运气，产能天然受人手限制。模型介入之后，这件事的成本结构变了——同样的时间里能扫过的代码量，跟人力时代不是一个量级。

    不止谷歌一家

    本月早些时候，微软在例行的”补丁星期二”里一口气修了 570 个安全漏洞，创下纪录。微软给出的解释和谷歌几乎一模一样：用上 AI 了。

    苹果那边的情况则完全不同。根据一份独立统计，苹果 2026 年至今修复了 482 个漏洞，这个节奏跟去年基本持平，甚至和 2015 年的数量差不多。换句话说，苹果的曲线还是平的。TechCrunch 就此向苹果求证，没有得到回复。

    • 谷歌 Chrome：上月两个版本修复 1072 个漏洞，超过前两年 23 个版本之和（1036 个）。
    • 微软：7 月单月补掉 570 个漏洞，破自家纪录，同样归因于 AI。
    • 苹果：2026 年至今 482 个，与去年、甚至与 2015 年的量级接近。

    补丁变多，等于更安全吗

    这里得说句公道话：1072 这个数字既是好消息，也是坏消息。好消息是这些洞在被人利用之前就被堵上了；坏消息是它们本来就一直在那儿，只是过去没人有能力把它们全翻出来。一个用了十几年的浏览器，代码库里的隐患比大家想象的多得多。

    更值得琢磨的是攻守两端的对称性。谷歌能用模型批量挖洞，攻击者当然也能。这场竞赛真正的变量不是谁挖得多，而是谁能把”发现—修复—推送到用户设备”这条链路跑得更快。对浏览器这种自动更新的产品来说，这条链路天然占优；但对那些更新周期以季度甚至年计的企业软件和 IoT 设备，同样的 AI 能力落到攻击方手里，结果会难看得多。

    至于苹果的平曲线，有两种读法。一种是它的代码质量确实更好，没那么多洞可挖；另一种是它还没把 AI 大规模接进安全流程，所以曲线还没到抬头的时候。从行业趋势看，第二种解释的可能性更大一些。

    对普通用户来说，从这条新闻里能提取的操作建议其实只有一条：别再拖着不重启浏览器了。那 1072 个补丁只有装到你机器上才算数。