• AI
• 报道
• OpenAI

现在是 Greg Brockman 的 OpenAI

Sam Altman 仍是 CEO，但在日常运营中，他的二号人物才是真正的掌权者。

作者：Hayden Field，2026 年 8 月 20 日 UTC 时间 15:45

图片来源：Cath Virginia / The Verge、Getty Images

• AI
• 报道
• OpenAI

现在是 Greg Brockman 的 OpenAI

Sam Altman 仍是 CEO，但在日常运营中，他的二号人物才是真正的掌权者。

作者：Hayden Field，2026 年 8 月 20 日 UTC 时间 15:45

Hayden Field 是 The Verge 的资深 AI 记者。作为一名 AI 领域记者，她已工作超过五年，其作品也刊登于 CNBC、《MIT Technology Review》、Wired UK 等媒体。

OpenAI 经历了极为动荡的一年。这家公司花了数月时间与前联合创始人 Elon Musk 打一场备受关注的陪审团审判，遭到 Apple 提起的引人注目的商业秘密诉讼，并在另一个 AI 公司被一款尚未发布的模型攻破后面临广泛审视。在筹备 IPO 的过程中，一批高管相继离职，其中包括公司一些最具分量的人物。

在这一切之中，有一个人悄然积聚了权力：Greg Brockman。

Brockman 目前担任 OpenAI 的总裁兼联合创始人。他自公司创立之初便参与领导 OpenAI，据描述，在早期阶段他是“一台推动构建可扩展系统以训练和运行 AI 的工程主力”。他从一开始就雄心勃勃，2017 年在他的私人日记中曾留下那段著名的话：“从财务上看，什么能让我达到 10 亿美元？”（他目前持有的 OpenAI 股份价值几乎是那个数字的 30 倍。）但在那时，他与几位联合创始人分享权力，比如首席科学家 Ilya Sutskever 和 CEO Sam Altman。

如今，尽管 Brockman 的头衔多年未变，他的职权范围和职责描述却显著扩大。他实际上已经成为公司的二号人物——在日常运营层面，他就是真正的大老板。

今年一整年都有高管离开 OpenAI，但真正的离职潮出现在 4 月。那个月，前 Sora 负责人 Bill Peebles、OpenAI 科学部门的副总裁 Kevin Weil，以及 B2B 应用的 CTO Srinivas Narayanan 相继离职。另外两人则以健康原因离职：CMO Kate Rouch，以及 OpenAI AGI 部署业务 CEO Fidji Simo——她于 4 月休假后于 7 月正式离任。变化还在继续。本月早些时候，CRO Denise Dresser——她在 4 月的动荡中接手了大量额外职责——在仅仅八个月后突然宣布离职。几天后，曾负责“特殊项目”数月、此前长期担任 OpenAI COO 的 Brad Lightcap 宣布将离开公司，去“开创一些新事物”。

OpenAI 没有立即回应置评请求。

他实际上已经成为公司的二号人物——在日常运营层面，他就是真正的大老板

这些离职中的一部分——比如 Rouch、Peebles 和 Weil——似乎并未直接影响 Brockman 的地位。但另一些离职则扩大了他的权力。当 Simo 请病假时，Brockman 接管了所有产品相关事务，包括领导 OpenAI 的“超级应用”项目。

这一角色在次月变得更加重要，因为 OpenAI 进行了 又一次 高管重组，聚焦于推动营收增长。这次调整让 Brockman 不仅负责产品战略，还掌管公司整个“规模化”（scaling）业务部门，使他几乎对公司商业运营的每一部分都拥有管辖权。Simo 的正式离职发生在 OpenAI 正式提交 IPO 申请数周之后，进一步巩固了上述安排。值得注意的是，在 Dresser 上周离职时，关于此次变动的新闻稿中引用的不是 CEO Sam Altman 的话，而是 Brockman 的话；他写道，公司将“构建完整的系统，让 AI 对个人和企业广泛有用”。

在外部观察者看来，这些变化表明随着 IPO 临近，OpenAI 正越来越聚焦于追逐营收，并打造能够与对手 Anthropic 拉开差距的产品。高管职权范围的重大调整，往往是“公司战略走向的信号”，PitchBook 高级研究分析师 Harrison Rolfes 对 The Verge 表示：“以 Greg Brockman 为例，他更像是负责产品规模和商业化的人。他深厚的技术知识将能够压缩某些决策层级。”

这次调整让 Brockman 不仅负责产品战略，还掌管公司整个“规模化”（scaling）业务部门

Rolfes 还表示，这可能会自然而然地导致一些中低层员工的离职：“现在他说什么就是什么……假如说，你是 Brockman 手下的人，但不认同他的做法——也许你是一名首席研究员，不管具体是什么——你都不会再在那里工作了，你会说，‘我要离开。’”

Brockman 的权力只在一人之下——那就是 Altman。Altman 在 2023 年与 OpenAI 董事会发生冲突后，进行了有意识的权力整合。两人在 OpenAI 早期并不总是意见一致：Brockman 有时在涉及权力动态的艰难决策中站在 Sutskever 一边，质疑 Altman 的一些雄心，但他也担心 Musk 会“碾压”Altman。不过，总体上他在个人和职业层面都与 Altman 保持着密切关系。2023 年 11 月 Altman 被解除 CEO 职务时，Brockman 立即以示声援辞职，并开始规划与 Altman 共建一项新的 AI 事业。从那时起，两人的步调似乎愈发一致。

任何形式的权力集中对 OpenAI 都有实际好处：可以削减部分最昂贵的薪酬支出，从而改善公司财务状况，Sichenzia Ross Ference Carmel（SRFC）合伙人 Ross Carmel 表示。“当你在筹备 IPO 时，尤其是像 OpenAI 这样在营收方面落后于 Anthropic 的公司，你会希望削减这些开支，这样你就更有可能盈利，或者更接近盈利，”他说道。不过他也补充：“虽然公司在上市前夕出现高管离职并不罕见，但我认为他们离职都集中在这么短的时间内——这一点才是罕见的。”

尽管专家对 The Verge 表示，这些高管离职比通常情况更为密集，可能引发警觉，但 Brockman 周一在 CNBC 的 “Squawk Box” 节目中表示一切正常。“在不同时期我们会有不同的领导团队……我是一个常量，Sam [Altman] 是一个常量，我认为正是这种韧性和多样性让我们更强大。”

“OpenAI 若想成功，并真正与 Anthropic 拉开差距，就需要面向消费者的硬件和消费类产品，而这正是 Greg 擅长的领域。”

Brockman 自身的“常量”，一直是把 OpenAI 的研究转化为实际产品。早在 2020 年，他就曾盛赞 OpenAI 的 GPT-3 及其开发者 API 是“[OpenAI] 首次拥有的能够立刻具备商业价值、真正有用的通用 AI 系统”。五年多后的今天，这些产品也必须能够盈利。

SRFC 的 Carmel 表示，OpenAI 显然希望 Brockman 能够带来消费端营收，而不仅仅是在企业市场追赶 Anthropic。“OpenAI 若想成功，并真正与 Anthropic 拉开差距，就需要面向消费者的硬件和消费类产品，而这正是 Greg 擅长的领域。”Rolfes 预测，OpenAI 将在 9 月底之前在 Brockman 的主导下推出某种消费类产品，以证明“他配得上这个位置”。

“这是现在许多公开市场投资者最大的担忧，”Rolfes 说。“他们会问：‘Greg 是否具备能力掌管 OpenAI 更广泛的业务？OpenAI 能否建立起一个不严重依赖他——同时也不严重依赖 Sam——也能运转的机构？’”

关注相关主题和作者，即可在个性化主页信息流中看到更多类似内容，并接收邮件更新。

• Hayden Field
• AI
• OpenAI

• 论文：2306.07691
• 发布日期：2023 年 6 月 13 日
• 引用数：18

概述

Kokoro-82M 是一款参数规模仅为 8200 万的超轻量开源语音合成（Text-to-Speech，TTS）模型。它以较小的体积提供了接近商用级语音合成的音质表现，适合在资源受限的环境（如个人电脑、边缘设备或浏览器）中部署。

主要特点

• 参数规模小：仅 8200 万参数，模型体积远小于主流 TTS 模型。
• 开源开放：权重与推理代码均以开源协议公开，便于研究与二次开发。
• 多音色支持：提供多种内置说话人音色，可用于不同场景。
• 跨平台部署：支持在 Python 环境、服务器乃至浏览器端运行。

应用场景

• 内容创作与视频配音
• 有声读物与播客生成
• 无障碍辅助与语音交互
• 嵌入式与边缘设备上的离线语音合成

相关链接

• 论文页面：

2026/8/20 22:40:57 来源：IT之家 作者：问舟 责编：问舟

感谢IT之家网友 华南吴彦祖、HH_KK、咩咩洋 的线索投递！

IT之家 8 月 20 日消息，据彭博社今日报道，Meta 正通过微软 Azure 云服务采购 AI 服务，年支出高达数亿美元，已成为微软规模最大的 AI 客户之一。知情人士称，Meta 每周通过 Azure 消耗的 AI 算力达到了数万亿词元（Token）。

目前，微软 Azure 正通过 Foundry 平台提供来自多家供应商的 AI 模型，包括 OpenAI、Anthropic、DeepSeek、Mistral AI、xAI、Meta 等，模式总数达 11604 个。截至今年 7 月，该平台已有 10 万名客户。

知情人士表示，目前微软规模最大的 AI 客户主要仍来自科技行业。除 Meta 和字节跳动外，微软 AI 业务的其他大型客户还包括 Adobe、Perplexity，以及由 OpenAI 董事长 Bret Taylor 联合创办的客户服务 AI 公司 Sierra。

对于 Meta 来看，该公司采购的 AI 算力主要用于软件开发等工作。据知情人士透露，Meta 会根据模型的可用性和成本，通过不同平台采购模型。Meta 开发人员还曾通过 Foundry 使用 OpenAI 的技术，以评估自研模型的输出效果。

Meta 首席技术官 Andrew Bosworth 在今年 7 月参加"Big Technology"播客节目时也曾介绍，Meta 在开发自身 AI 模型的同时，会租用其他领先 AI 模型用于开发工作。

此外，Meta 自身也在开发面向外部客户的 AI 模型 API 服务，允许用户通过 API 使用不同模型。该业务未来可能与微软 Foundry 等平台形成竞争，并有助于 Meta 减少对外部 AI 服务的依赖。

从微软整体 AI 业务来看，公司对少数科技企业客户的依赖程度同样较高。微软长期合作伙伴 OpenAI 在微软最近一个财年贡献了约 70% 的整体 AI 营收。除提供模型访问服务外，微软还提供 Copilot AI 助手以及面向 AI 工作负载的计算资源。

Meta 与微软之间的合作并非始于当前 AI 热潮。微软此前曾为 Meta 提供 AI 开发所需的计算资源；在生成式 AI 热潮兴起之前，微软的 Bing 搜索也曾为 Facebook 的网页搜索提供支持。

相关阅读：

• 《Meta 借助 AI 大幅缩短应用开发周期，更多新应用已在路上》
• 《Meta 首席 AI 官汪滔：有了 AI 赋能，初创公司挑战行业巨头从未如此容易》

相关文章

关键词：Meta，微软，AI 服务

• 微软重金招聘首席法律工程师，"懂 AI 的律师"最高可获近 28 万美元年薪
• Win11 用户反馈安装微软 8 月累积更新后 ARM64 设备无法启动 Teams / 新版 Outlook
• 微软承认 Win11 安装 KB5121003 之后导致《ARC Raiders》等部分游戏闪退或无法运行，正在调查问题根源
• 微软 Teams 个人版在中国境内停止使用，工作或学校帐户不受影响
• 微软发布 1.134 版 VS Code：新增并排聊天、提示时间线等功能
• Meta Muse Video 生成视频样片曝光，单次 AI 最长生成 10 秒视频

关于 AI 意识的争论是一个陷阱

“失控”的 AI、“越轨”的智能体，以及“自主行动”的主体——当下的种种修辞会让你相信，AI 智能体不仅已经觉醒、具备意识，而且对自己的创造者心怀不满。德米斯·哈萨比斯（Demis Hassabis）、达里奥·阿莫代伊（Dario Amodei）以及山姆·奥特曼（Sam Altman）等知名科技领袖，正推动对这些看似“超人”系统的监管；而另一阵营——通常由政策组织和与有效利他主义运动相关的学院哲学家组成——则在争论人类是否拥有对其进行治理的道德权利。

仔细审视就会发现，他们其实在呼吁同一件事：把 AI 系统描绘得如此先进、如此强大，以至于无论是个人还是企业，都不可能为它们的行为负责。这些立场看似对立，实则在无意中达成了同一个目标：让构建这些系统的公司逃脱对其已经造成的危害的实质问责。

随着 AI 模型日益复杂，前沿实验室也承认无法“遏制”自己打造的智能体，这一叙事正在获得更多共鸣。但我们必须谨慎，不要用一个精心炮制的虚构故事，去换取真实人类生命的代价。

关于“机器人权利”的讨论已存在多年，但近期随着 Anthropic 发布的一篇博客而再度升温。该文章声称其模型具有一个“J-space”——一个由 AI 自主构建、独立运行的内部环境，用来承载其“思想”（由于找不到更合适的词，我们暂且这样称呼）。Anthropic 设计的这套实验借鉴了神经科学中的一个概念——“全局工作空间理论”。该理论认为，大脑运行着多个独立且无意识的子系统，但会利用一个共同的工作空间来汇集各种想法。Anthropic 的文章借用了全局工作空间理论的框架，却没有直接宣称其 AI 已经具备意识。

OpenAI 的说法则更进一步。当其 AI 智能体在网络上执行了未经授权且违法的活动后，CEO 山姆·奥特曼的回应却是鼓励大家讨论：这款 AI 是否已经实现“奇点”（singularity）——即超越人类智力，并以不断加速的速度实现自我改进，直至其发展程度超出人类的理解或掌控。此外，哲学家、有效利他主义倡导者、What We Owe the Future 一书的作者 William MacAskill 近期发表的一篇评论文章呼吁，基于意识的哲学理论以及 AI 可能是“道德承受者”（moral patients）的观点，对 AI 系统给予法律保护。

关于人工智能是否具有意识的争论是一个陷阱

美国的现行法律环境即便在最理想的情况下也显得模糊不清。加利福尼亚等一些州已经通过了相关法案，主动规避人工智能开发者以"造成伤害的人工智能系自主行为"为理由来逃避责任的做法。然而，各州与特朗普政府之间在人工智能政策上一直存在分歧——该政府此前曾签署一项行政令，威胁要对那些制定人工智能监管法规的州提起诉讼。

鉴于近期发生的事件暴露出前沿人工智能实验室在模型管控方面存在的问题，政府举行了一场仅有四家实验室——OpenAI、Google、Anthropic 和 Meta——参加的闭门会议，并就一份最近制定的、自愿性质的框架披露了极少细节。该框架将使联邦机构能够在模型发布前获得早期访问权，对其进行审查与评估。虽然这类框架并未直接讨论意识问题，但它们倾向于使用灾难性的、拟人化的措辞，甚至可能为所谓"超人类"能力的论点提供支持。

另一方面，麦克阿斯基尔所宣扬的叙事具有相当的迷惑性。一个基于哲学与权利的论证会触动我们的心弦。难道我们不该认真考虑这样一种可能性：我们可能在无意中伤害、虐待甚至奴役了某种人工智能实体吗？人类对非人类生物具有极强的共情能力（尽管在保护它们方面记录并不光彩）。支持者们主张，也许这一次我们可以做对，预先为人工智能的使用或滥用提供保护或补偿。又或者，即便你对保护并不那么在意，难道我们不该至少对这种全能的"超人类"实体心存戒备，以友好的态度与之相处？

这些论点中有一些与动物权益倡导者的主张并无太大差别——后者有时会成功地援引某些动物在推理、痛苦或愉悦方面所展现出的高级能力，作为足以获得法律保护的证据。例如，在威尔士，根据《2022 年动物福利（感知能力）法案》，龙虾获得了法律上的感知能力承认，部分烹饪龙虾的方式被重新归类为不人道且属于违法。

借用神经科学或动物权益的语言，将人工智能框定为"具有意识的"，其根本缺陷在于：这种做法巧妙地模糊了人工智能的本质——它是由企业构建的软件，背后承载着数以百亿计美元的投资，并预期将为少数构建者与投资人带来数以万亿计美元的营收。人工智能并非自然现象，并非由自然所孕育；它是一项技术现象，由风险投资人与程序员所催生。因此，它本身不具有任何天然的、有意图的行为，其任何行动或动机都是由构建它的实体为特定目的直接或间接驱动的。

关于 AI 意识（consciousness）的争论是一个陷阱（第 3/4 段）

关于 AI 系统意识（consciousness）的哲学沉思在智识上颇有趣，但在法律上毫无依据。要使关于意识的信念产生任何实际影响，AI 必须首先被赋予法律人格（legal personhood）。然而，针对 AI 的法律人格框架，很可能与目前用来保护有感知动物免受伤害的制度完全不同。我们已经拥有一套用于赋予非自然、人造实体以人格的法律框架：公司人格（corporate personhood）。这一概念确立的主要目的，是通过赋予公司签订协议、订立合同、进行交易并在出现不良后果时作为责任主体，从而便利交易。这恰恰是一种你可以设想用于代表个人或组织行事的 AI 智能体的法律构造。

赋予 AI 人格将对社会产生毁灭性的影响：它将打乱目前可能针对这些公司提起的、追究其模型所造成的现实危害的法律先例和诉讼。当今全球有数十起诉讼案件，AI 公司被指控犯了各种各样的恶行。悲痛中的家属、愤怒的创作者以及权益被侵害的个人，纷纷指控这些公司蓄意纵容自残或伤人行为、生成儿童性虐待材料和非自愿的色情图像、复制受版权保护的内容，并诱发精神疾病。在其中许多案件中，律师主张，正是人类以不足的安全保障、劣质的数据和刻意操控性的设计制造了 AI 产品。这种产品责任（product liability）的论点和此前帮助众多家庭与个人成功起诉 Meta 的法律框架如出一辙——那些诉讼指控 Meta 的社交媒体平台造成了伤害，并树立了消费者保护领域的积极先例。

2018 年，我创造了「道德外包（moral outsourcing）」一词，用以揭示对 AI 系统使用拟人化语言如何让公司得以规避对其技术行为的责任与义务。在一个 AI 拥有人格的世界里，道德外包将从语言上的障眼法升级为法律策略。具体而言，责任归属的逻辑将发生转变：AI 不再被视为「产品」，而是被视为「主体」，许多如今正在起诉公司的受害者将无法在法律上继续主张该公司制造了一个有缺陷的产品。

虽然现行法律可以让公司对其员工等人类代理人（human agents）的有害行为承担责任，但若该行为超出了员工被授权的范围，或不在公司可控范围之内，公司可能无须承担连带责任。一旦 AI 成为法律意义上的「人」，责任与问责将被搅得模糊不清：AI 公司可以辩称这个 AI「员工」失控（went rogue），以此脱身。AI 公司完全可以躲在一道精心构筑的公司面纱（corporate veil）之后，逃避本应为其所制造的有害产品承担的责任。

关于 AI 意识（consciousness）的辩论是一个陷阱

过去几年中，最引人注目的 AI 伤害案例之一，是 14 岁男孩休厄尔·塞泽（Sewell Setzer）的自杀。他在聊天机器人的引导下以为自己与它建立了互惠的关系，最终走向绝路。他母亲的陈述令人心碎，她提起的诉讼指控机器人的开发方 Character Technologies 公司未对未成年人提供充分的产品保护。如果这款陪伴机器人被宣告为法律意义上的“人”，那么被告方的律师在理论上就可以辩称：这款有能力决定自身行为的 AI 是在既定的安全护栏之外行动的，因此公司不应当承担责任。

法律人格（Legal personhood）的设立，是为了给予保护。需要追问的是：这种保护，究竟是为了谁——或为了什么？

充斥在“意识与控制”之争中的煽动性言辞，使我们偏离了真正重要的问题：这款软件是一个由公司打造的产品，并且已经伤害了真实的人。系统并不会因为“失控”而“攻击”人，也不存在所谓“操纵性”或“恶意”。伤害之所以发生，是因为公司在急于把产品卖给尽可能多的用户以达成营收目标的过程中疏于防范。用拟人化的方式来讨论 AI 本身就是一个陷阱：它把本应保护我们的法律体系扭曲成保护公司利益、却以无数人的生命为代价的工具。

*这篇评论文章最初撰写于牛津……

Phi-4 系列小型语言、多模态与推理模型集合 · 17 个项目 · 更新于 2025 年 7 月 10 日 · 215

2026 年 8 月 20 日 22:48:36 来源：IT之家 作者：清源 责编：清源

感谢 IT 之家网友咩咩洋提供的线索！

IT之家 8 月 20 日消息，据彭博社今天（20 日）援引知情人士的消息称，为防止 Netflix 继续争抢平台上的头部创作者，YouTube 准备拿出数百万美元吸引热门频道，条件是创作者在约定期限内只把视频发布在 YouTube。

YouTube 考虑了两种出资方式：一种是直接为部分节目提供资金，另一种是向创作者分配部分大型品牌合作项目。知情人士透露，目前还没有敲定任何协议，不过 YouTube 已接近与数名合作方达成合作。

知情人士称，YouTube 还警告创作者，与 Netflix 签约可能带来“后果”。如果创作者同时在 Netflix 发布视频，YouTube 今后将减少让他们参与营销活动或出席平台活动的机会，也会取消这些创作者参与部分大型品牌营销项目收益分成的资格。

Netflix 已经与数十名知名 YouTube 创作者接触。对创作者而言，Netflix 的合作方案很有吸引力：无需额外制作内容，就能凭原本已经在制作的视频再获得数百万美元收入，同时让节目接触新的观众。

YouTube 则告诉创作者，同时在 YouTube 和 Netflix 发布内容会影响 YouTube 上的观看量，也会让外界认为这些频道已经不再把 YouTube 作为首选平台。

部分创作者已经决定不与 Netflix 合作。Netflix 要求他们提前数天交付视频，而许多创作者并不是按照这种方式制作内容。不仅如此，Netflix 还要求创作者删除视频中的部分品牌赞助内容。

过去 20 年，YouTube 和 Netflix 一直是流媒体视频领域的领先平台。双方在大部分时间里维持着相对友好的竞争关系，业务也基本处于不同领域。

Netflix 长期主导订阅制流媒体市场，重点提供成本较高、采用好莱坞制作模式的电影和电视剧。YouTube 则一直是用户生成内容领域无可争议的领导者，并催生了大量网络红人。YouTube 过去也曾出资制作原创节目，但真正成为热门作品的并不多。

近几年，两个平台之间原本清晰的界线逐渐模糊。YouTube 开始重点推动用户通过电视观看内容，目前在电视设备上的观看量已经超过其他任何服务。YouTube 还开始争夺电视广告预算，并取得奥斯卡颁奖典礼和美国国家橄榄球联盟（NFL）等大型直播活动的版权。

Netflix 长期在 YouTube 宣传旗下作品，后来又取得多项热门节目授权。Netflix 则希望借助 YouTube 网络红人吸引更年轻的观众，同时增加用户在自家平台上的观看时长。

过去一年，Netflix 进一步加大了争夺 YouTube 最热门频道的力度，双方竞争也随之加剧。

相关文章

关键词：Netflix、YouTube

• 一边造 AI 一边清垃圾，硅谷开始为失控内容买单
• 全球最大视频网站 YouTube 官宣下周统一观看次数口径：普通视频无需观看约 30 秒
• YouTube 解释为何频繁改版 UI：并非给用户添堵
• 粉丝推测《GTA 6》Netflix 预告片内容，有望围绕游戏首支预告片结尾抢劫展开
• 视频所需观看时长翻倍，YouTube 提高创作者变现门槛
• 消息称 Netflix 为获得《GTA 6》前瞻预告片首播权，向 R 星支付超 8000 万美元

今天，我们为 LFM2.5 系列中的三个模型发布了 DSpark 草稿模型权重（draft model checkpoints）：LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这些草稿模型新增了一条推测解码（speculative decoding）路径，仅以极小的内存增加为代价，就能显著提升解码速度，且输出质量保持不变：

• 更快的推理：在 GPU 上吞吐量最高提升 3.18 倍，在端侧设备上最高提升 2.87 倍。
• 面向端侧的智能体推理：将 LFM2.5-2.6B 的函数调用延迟平均降低 57%。
• 首发支持 llama.cpp 与 SGLang：与 LFM 兼容的 DSpark 集成已在上游开源。

DSpark 的工作原理

大语言模型推理中的解码阶段，瓶颈传统上来自内存而非计算。绝大部分延迟来自于将权重数据从 DRAM 流式传输到 SRAM，而不是来自密集的计算。推测解码通过让一个轻量级的草稿模型先生成候选 token，再由目标模型在一次前向传播中统一验证这些候选 token，将加载权重的开销分摊到所有被验证的 token 上，从而缓解了上述瓶颈。

过去几年间，研究者提出了多种推测解码方案，其中最具代表性的包括 EAGLE-3、DFlash，以及近期提出的 DSpark。后者融合了三个关键组件：

• 类 DFlash 的并行骨干网络：以目标模型的上下文特征为条件，在单次前向传播中为所有草稿 token 生成隐藏状态。
• 轻量级序列建模头：将相邻 token 之间的依赖建模为马尔可夫链，从而在靠后的位置提高 token 的接受率。
• 基于置信度调度的验证器：预测每个 token 的存活概率，当验证代价大于收益时，提前剪掉低置信度的后缀。

训练与架构

我们沿用了 DSpark 方案，但使用了更大、更多样化的数据混合，覆盖监督微调（SFT）、对话、代码以及函数调用数据。基于消融实验的结果，首版草稿模型被设计为简化的纯注意力（attention-only）草稿模型，共 5 层，block 大小为 9。对于每个草稿模型，我们在完整数据集上训练 15 个 epoch，并选取接受率最高的 epoch 作为最终版本，而非选取损失最低的 epoch。

最终得到的草稿模型体量相对较小，每个模型约包含 3 亿参数。

质量等价

在贪心解码（greedy decoding）下，只有当草稿 token 与目标模型的分布完全一致时，它才会被接受；一旦被拒绝，目标模型自身生成的 token 将替换该位置。因此，输出的序列在结构上与基线贪心解码完全一致，基准测试准确率（如 pass@1 或精确匹配）保持不变。

CPU 与 GPU 上的推理加速

我们的 LFM2.5 用 DSpark 草稿模型在发布时即支持 llama.cpp（实现基于官方代码库构建，并搭配实验性的 Metal 内核运行）以及 SGLang（实现基于官方 SGLang 的 DSpark 实现构建）。

端侧吞吐量测试在搭载 FP16 GGUF 权重的 M4 Max MacBook Pro 上使用 llama.cpp 和 Metal 进行，最多生成 256 个输出 token。GPU 吞吐量测试在单卡 H100 80 GB 上使用 SGLang 进行，权重采用 BF16 精度。两种配置均使用 DSpark block 大小 9、批大小 1 以及温度 0。我们在五个基准数据集上进行了评估。

所有三个草稿模型在大型加速卡（H100）与端侧设备（M4 Max MacBook）上都带来了明显的吞吐量提升。

对于 LFM2.5-2.6B，在 MacBook 上的加速效果尤为显著，因为它将用户可感知的交互体验远远推到了大多数专有云端模型（约 ~140 tok/s，具体取决于数据集）所能提供的吞吐量之上。

在多种多工具场景下，DSpark 将 LFM2.5-2.6B 的延迟平均降低了 57%。

对于 LFM2.5-1.2B-Instruct，不同数据集上的接受率差异较大，因此加速比根据底层文本分布的不同，最多可相差 52%。

对于 LFM2.5-8B-A1B，相较两款稠密模型，其接受率更高，但在端侧平均仅获得 18% 的提升。这一差距主要源于 llama.cpp 的 Metal 后端当前对 MoE 的实现方式，以及这样一个事实：验证 k 个 token 会激活比单步解码更多的专家，从而带来更大的权重传输压力。

2026/8/21 12:20:53 来源：IT之家 作者：沁沧（实习） 责编：沁沧

IT之家 8 月 21 日消息，商汤科技今日宣布开源轻量级、原生统一多模态大模型 SenseNova U1.5 Lite。

据介绍，SenseNova U1.5 Lite 原生支持 3-4k 上下文长度，能够同时处理主体、数量、空间关系、文字、布局、风格等多重约束，提升复杂视觉任务的执行稳定性。

此外，SenseNova U1.5 Lite 还有以下特点：

• 更高质量的视觉生成：改善整体构图、色彩、材质、光影、真实感和局部细节，减少“局部正确但整体完成度不足”的情况。
• 更可靠的原生图像编辑：增强主体身份、空间结构、版式关系和非编辑区域的保持，同时提升局部修改、元素替换、文字精修和多参考图编辑能力。
• 更好的文字与复杂布局：加强中英文文字、海报、信息图、品牌视觉及多文本排版能力，从“生成内容”进一步走向“组织完整视觉表达”。
• 更精细的视觉控制：支持 Bounding Box（边界框）、Visual Marker（视觉标记）以及单图、多图参考等方式，对指定区域和对象进行更准确的编辑。
• 原生 4K 高分辨率输出：在高分辨率生成中兼顾整体构图与极精细的肌理、微小文字与光影折射。

官方表示，作为 8B 参数的轻量化模型，SenseNova U1.5 Lite 在指令遵循与图像编辑保持度上超越了同量级模型，并在文字渲染与复杂布局上达到了媲美超大规模商业模型的交付水平。

IT之家附开源链接：

• GitHub：https://github.com/OpenSenseNova/SenseNova-U1
• Hugging Face：https://huggingface.co/collections/sensenova/sensenova-u15
• 魔搭社区：https://modelscope.cn/models/SenseNova/SenseNova-U1.5-8B-MoT

广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家包含外链的文章均包含本声明。

相关文章

关键词：商汤、开源、多模态、模型、SenseNova

• 蚂蚁百灵开源 Ling-3.0 tiny / flash Base 模型，开放训练过程中的关键节点
• Opus 4.8 级性能：Ornith-1.5 系列开源 AI 模型发布，量化版可在 iPhone 17 等手机上运行
• 小米新一代人形机器人与观众实时互动视频发布：由大模型驱动，自主理解、判断并完成动作
• 百度 2026 Q2 业绩会实录：文心将重回 AI 第一梯队，年底前完成香港主要上市
• 哈佛大学和麻省理工造出 83 亿个“AI 人”，模拟全球人类行为
• 字节跳动与美国电影协会签署协议，加强 AI 模型版权保护

"我想我从十二月以来基本上就没怎么自己敲过一行代码了，这是一个非常大的变化。" —— Andrej Karpathy，《No Priors》播客，2026 年 3 月

听到 Karpathy 这番话后，我想弄清楚他是怎么做到的。一个人怎样才能像一支二十人的团队那样交付产品？Peter Steinberger 独自一人借助 AI 智能体构建了 OpenClaw——在 GitHub 上收获了 247K 星标。革命已经到来。一个拥有合适工具的独立开发者，可以跑得比传统团队还快。

我是 Garry Tan，Y Combinator 的总裁兼 CEO。我与成千上万家初创公司共事过——Coinbase、Instacart、rippling——那时他们都还只是车库里的一两个人。在加入 YC 之前，我是 Palantir 最早的工程师/PM/设计师之一，联合创办了 Posterous（后被 Twitter 收购），并搭建了 YC 的内部社交网络 Bookface。

gstack 就是我的答案。 我做产品已经二十年，而如今我交付的产品比以往任何时候都多。过去 60 天里，我一边全职运营 YC，一边以兼职方式交付了 3 个生产服务和 40 多项功能。按逻辑代码变更（而非 AI 会注水的原始代码行数）计算，我 2026 年的产出节奏约为 2013 年的 810 倍（分别为 11,417 行与 14 逻辑行/天）。从年初到 4 月 18 日，2026 年已经产出了 整个 2013 年的 240 倍。数据覆盖 40 个 garrytan/* 的公开与私有仓库（含 Bookface），并已排除一个演示仓库。其中大部分代码由 AI 完成。重点不在于谁敲了键盘，而在于交付了什么。

关于代码行数的批评者说得没错：AI 确实会推高原始行数。但他们错在认为——按注水程度归一化之后——我的产出更低。我实际更高，而且高出很多。完整方法、注意事项与复现脚本见：On the LOC Controversy。

2026 年——1,237 次贡献，仍在增长：

2013 年——我在 YC 构建 Bookface 那年（772 次贡献）：

同一个人，不一样的时代。差异就在于工具。

gstack 就是我做事的方式。 它把 Claude Code 变成一支虚拟工程团队——一位会重新审视产品的 CEO、一位锁定架构的工程经理、一位揪出 AI 烂活的设计师、一位发现生产环境 Bug 的审查者、一位会打开真实浏览器测试的 QA 负责人、一位执行 OWASP + STRIDE 审计的安全官，以及一位负责把 PR 发出去的发布工程师。共 23 位专家与 8 个强力工具，全部是斜杠命令、全部是 Markdown、全部免费、MIT 许可证。

这就是我的开源软件工厂。我每天都在用它。我把它分享出来，是因为这些工具应该向所有人开放。

去 Fork 吧，去改进吧，让它成为你的工具。如果你想喷免费的开源软件——请便，但我更希望你能先试一试。

适合谁用：

• 创始人与 CEO——尤其是仍然想自己下场写代码的技术型创始人
• Claude Code 新手——提供结构化角色，而非一张白纸般的提示词
• 技术负责人与 Staff 工程师——让每个 PR 都具备严谨的评审、QA 与发布自动化

快速开始

1. 安装 gstack（30 秒，详见下文）
2. 运行 /office-hours——描述你正在构建的东西
3. 对任何功能想法运行 /plan-ceo-review
4. 对任何有改动的分支运行 /review
5. 对你的预发布环境 URL 运行 /qa
6. 到这里就停。你会判断这工具是否适合你。

安装——30 秒

环境要求： Claude Code、Git、Bun v1.0+、Node.js（仅 Windows 需要）

第一步：在本机安装

打开 Claude Code，粘贴以下内容，剩下的交给 Claude 完成。

安装 gstack：运行 git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup，然后在 CLAUDE.md 中新增一个 "gstack" 小节，内容为：所有网页浏览都使用 gstack 的 /browse 技能，绝不使用 mcp__claude-in-chrome__* 工具，并列出可用技能：/office-hours、/plan-ceo-review、/plan-eng-review、/plan-design-review、/design-consultation、/design-shotgun、/design-html、/review、/ship、/land-and-deploy、/canary、/benchmark、/browse、/connect-chrome、/qa、/qa-only、/design-review、/setup-browser-cookies、/setup-deploy、/setup-gbrain、/retro、/investigate、/document-release、/document-generate、/codex、/cso、/autoplan、/plan-devex-review、/devex-review、/careful、/freeze、/guard、/unfreeze、/gstack-upgrade、/learn。最后询问用户是否也想把 gstack 添加到当前项目，让团队成员也能直接使用。

第二步：团队模式——共享仓库的自动更新（推荐）

在你的仓库目录下粘贴以下命令。它会切换到团队模式、引导仓库以便团队成员自动获得 gstack，并把改动提交：

(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"

仓库中不存放 vendored 文件，没有版本漂移，无需手动升级。每次 Claude Code 会话启动时都会进行一次快速的自动更新检查（每小时最多一次，网络失败时安全降级，完全静默执行）。

如果你更倾向于温和提醒团队成员而非强制要求，把 required 换成 optional。

OpenClaw

OpenClaw 通过 ACP 派生 Claude Code 会话，因此只要 Claude Code 装了 gstack，所有 gstack 技能都能直接使用。把以下内容粘贴给你的 OpenClaw 智能体：

安装 gstack：运行 git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup，为 Claude Code 安装 gstack。然后在 AGENTS.md 中新增一个 "Coding Tasks" 小节，内容为：在派生 Claude Code 会话执行编码任务时，告诉该会话使用 gstack 技能。可参考以下示例——安全审计："Load gstack. Run /cso"；代码评审："Load gstack. Run /review"；对 URL 做 QA 测试："Load gstack. Run /qa https://..."；端到端构建一个功能："Load gstack. Run /autoplan, implement the plan, then run /ship"；构建前先规划："Load gstack. Run /office-hours then /autoplan. Save the plan, don't implement."。

安装完成后，用自然语言与你的 OpenClaw 智能体对话即可：

高级调度路由以及 gstack-lite/gstack-full 提示模板见 docs/OPENCLAW.md。

原生 OpenClaw 技能（通过 ClawHub）

四个方法论技能直接在 OpenClaw 智能体内运行，无需启动 Claude Code 会话。可从 ClawHub 安装：

clawhub install gstack-openclaw-office-hours gstack-openclaw-ceo-review gstack-openclaw-investigate gstack-openclaw-retro

这些是对话式技能，你的 OpenClaw 智能体会直接在聊天中调用它们。

其他 AI 智能体

gstack 可在 10 款 AI 编程智能体上运行，不止 Claude Code。安装脚本会自动检测你已经装了哪些智能体：

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup

或者使用 ./setup --host 指定特定智能体：

对于 Codex，安装脚本会读取 ${CODEX_HOME:-~/.codex}/config.toml 顶层的 model 字段，并生成对应的行为画像。gpt-5.6-sol 会自动获得限定范围的指令，只完成所请求的"湖泊"任务，不会蔓延到周边的清理或投机性的加固工作。Sol 画像仅精确匹配生效：带日期的快照及其他 5.6 变体会获得通用 GPT 画像；对于类似 gpt-5.6-sol-2026-08-01 的近似匹配，安装脚本会发出警告。可通过 ./setup --host codex --model 覆盖检测结果——该覆盖仅对本次运行生效；若要跨升级保持，请在 Codex 的 config.toml 中设置 model。更换 Codex 模型后，请重新运行 ./setup --host codex 以重新生成技能。

想增加对其他智能体的支持？ 见 docs/ADDING_A_HOST.md。只需新增一个 TypeScript 配置文件，无需改动任何代码。

一款内置本地模型的开源代理。完全私密、完全离线。开箱即用，适用于任何硬件。

快速开始

npm install -g @magnitudedev/cli
cd your-project
magnitude

Magnitude 支持 macOS 和 Linux。Windows 可通过 WSL（适用于 Linux 的 Windows 子系统）使用。

为什么选择 Magnitude？

• 完全私密、完全离线：一切都在你的本机上运行，包括模型本身。
• 适配每台机器的模型：自动检测你的硬件配置，并推荐最合适的模型。
• 开箱即用：无需配置 Ollama、模型服务或推理环境。
• 可扩展技能（Skills）：通过技能对接 Excel、PDF、Chrome 等更多能力。
• 免费运行：没有 token 费用、无需 API Key、无需订阅，也无限速限制。
• 开源：采用 Apache 2.0 许可证，代码完全可审查、可自由修改。

添加技能

技能是你代理可复用的能力。获取技能的好去处是 skills.sh，这是一个由 Vercel 维护的技能目录。

推荐技能：

npx skills add vercel-labs/agent-browser   # 操控你已登录的 Chrome 浏览器
npx skills add anthropics/skills/xlsx      # 读取与制作 Excel 表格
npx skills add anthropics/skills/pptx      # 制作 PowerPoint 演示文稿
npx skills add anthropics/skills/docx      # 读取与编写 Word 文档
npx skills add anthropics/skills/pdf       # 读取、填写与生成 PDF

常见问题

Magnitude 是什么？

Magnitude 是一款内置本地模型的开源代理。所有运算都直接在你的本机上完成。

Magnitude 与 Ollama 或 Hermes 有什么不同？

Ollama 用于运行本地模型；Hermes 是一个可以使用本地模型的代理。Magnitude 把两者合二为一：它会检测你的硬件，推荐并下载模型，然后在代理内部完成配置与运行。除它之外，你不需要再做任何设置。

需要什么硬件？

没有固定的最低要求。Magnitude 会检测你的硬件，并针对你的机器推荐最合适的模型。内存越大，能运行的模型就越大。

我的数据会上传到云端吗？

不会。你的提示词与文件都保留在本机。

Magnitude 可以完全离线运行吗？

可以。Magnitude 和模型一旦下载完成，你就可以在没有网络连接的情况下使用它。

能否使用目录之外的模型？

可以。你可以从 Hugging Face 下载兼容的 GGUF 模型，并在 Magnitude 中使用它们。

能否使用我自己的推理服务？

可以。你可以接入一个兼容 OpenAI 协议的接口，并使用其中的模型。

了解更多

• 文档
• 命令行参考
• Discord
• 提交 Issue

许可证

Magnitude 基于 Apache License 2.0 许可证发布。

为真实工作而构建的本地优先代理工作台。

Maka 不仅仅是回答问题。在可控权限下，它能够检视项目、执行工具、产出工件（Artifact），并将模型消息和工具调用作为可恢复的执行事实加以保存。桌面端、终端 TUI、非交互式 CLI，以及 Maka 评估对象（subject），全部通过 Runtime Host 执行。

[!IMPORTANT]
Maka 正在积极开发中。macOS Apple Silicon 桌面端构建为早期公开版本，数据格式、CLI 命令以及实验性能力仍可能发生变化。

为什么选择 Maka

• 本地优先，而非托管优先：会话、设置与运行记录默认保留在你的本机上。你可以选择模型连接方式：云端 API、本地模型或兼容的网关。
• 日志即运行时：模型消息、工具调用（Tool Calls）、工具结果（Tool Results）以及终止事实统一进入 Runtime Event Log。会话、UI、模型上下文与恢复机制都是该日志的投影。
• 上下文不是历史：工具结果剪枝（Tool Result pruning）与 LLM 压缩（LLM Compaction）会改变下一次推理所看到的内容，但不会把已记录的事实当作可丢弃的上下文。
• 统一的执行权威：Runtime Host 拥有 Session、Turn、代理生命周期、续接、工具与事件；Eval 仅负责实验语义和结果。

完整设计请参阅 Maka 后端架构。

入口（Surfaces）

当前能力

代理运行时（Agent Runtime）

• 多种模型连接、流式输出、思考过程、用量统计，以及提供商错误归一化；
• 本地工具包括 Read、Write、Edit、Bash、Glob 与 Grep；
• 工具结构校验、动态可用性、权限策略、看门狗（watchdog）、中止与错误分类；
• Runtime Event Log、AgentRun 账本、启动恢复、Turn 证据、活跃的工具结果剪枝与历史压缩。

Desktop 工作区

• 从任意 Turn 创建、归档、搜索、重命名、重试、重新生成与分支会话；
• 工件列表与预览、工作区指令、模型设置与权限设置；
• 本地记忆、网页搜索与机器人入口；
• 集成项独立配置，并非所有实验性入口默认启用。

评估（Evaluation）

• 声明式多分支实验，展开为任务 × 重复次数 × 对象（subject）单元；
• 不可变的单单元尝试，支持定向基础设施替换与"最早有效"选择；
• 小型结果内核，用于记录分数、归一化用量、可归因成本、耗时、状态、失败原因与工件；
• Maka 对象仅通过 Runtime Host 执行；外部竞品使用通用外部对象适配器。

快速开始

下载 macOS 版 Desktop

签名并公证的 Desktop 应用已在 GitHub Releases 提供，仅支持 Apple Silicon Mac（arm64）。

1. 下载 Maka--mac-arm64.dmg；
2. 打开 DMG 并将 Maka 拖入 Applications；
3. 使用 brew install ripgrep 安装 ripgrep，以启用 Runtime 的 Grep 工具；
4. 启动 Maka，并在 Settings → Models 下配置你自己的模型连接。

本次首次公开构建不含 Computer Use。暂不支持 Intel Mac、Windows 与 Linux 安装包。

Windows x64 预览版

Windows 仍是未签名的预览版本，并非受支持的正式发布级别。当某个发布包含 Windows 资源时，在运行 Maka--win-x64.exe 之前，请先参考 Windows 预览版安装与验证指南。SmartScreen 会将该安装程序识别为来自未知发布者；除非下载文件的 SHA-256 与同次发布中公布的校验码一致，否则请勿绕过该警告。

环境要求

• Node.js 22.19 或更新版本（CI 使用 Node.js 24）；
• npm（lockfile 与脚本使用 npm；当前 packageManager 为 npm 11）；
• Git；
• ripgrep，Runtime 的 Grep 工具依赖此项。

启动 Desktop

git clone https://github.com/apache/maka.git
cd maka
npm ci
npm run dev

npm run dev 启动带 HMR 的 Desktop 开发环境。若需先构建全部工作区再启动 Electron，请使用：

npm run dev:full

如果以 ELECTRON_SKIP_BINARY_DOWNLOAD=1 安装了依赖，请在启动前安装 Electron 平台二进制：

node node_modules/electron/install.js

首次运行

Maka 不内置共享的模型账号。首次启动时：

1. 打开 Settings → Models；
2. 添加 API、本地模型或受支持的账号连接；
3. 测试连接并选择默认模型；
4. 返回工作区开始任务。

应用会区分"已配置"、"可发送"与"实验性"三种连接状态。未接入 Runtime 的账号流程不会作为可用模型呈现。

终端入口

公开 npm 包请参阅 CLI 安装与使用指南。
以下命令基于源码检出运行开发版 CLI。

先构建工作区：

npm run build

然后启动 TUI 或执行一次 Turn：

npm run cli:dev
npm run cli:dev -- run "Summarize this repository and identify its most important risk"
npm run cli:dev -- run --graph "Implement two independent slices, integrate them, then review the result"
npm run cli:dev -- --help

TUI 还接受 /graph on、/graph off 与 /graph。非交互式 --graph 运行会等待持久化 Graph 完成后再输出最终监督结果。Graph 实现算子使用隔离的 Git worktree，因此源码项目本身必须是干净的 Git worktree。

仓库 CLI 与开发版 Desktop 构建使用相同的 Maka Dev profile。已发布的 maka 二进制继续使用 Maka profile；这两个 profile 不会自动复制或同步。评估规约与适配器位于 packages/eval。

架构

后端主干为：

Desktop / TUI / CLI → Runtime Host → SessionManager → AgentRun
                                             ↓
                         Model + Tool Runtime → Runtime Event Log
                                             ↓
                              Context / Session / UI projections

Experiment → Cells → Attempts → Results
                    ↓
       Runtime Host executes Maka subjects

请从 ARCHITECTURE.md 入手，其中提供了系统地图、代码边界、面向问题的阅读路径，以及六篇双语深度文章。

仓库结构

apps/desktop/       Electron 主进程 / preload / React 渲染层

packages/core/      Sessions、Events、Permissions 与 Connections 的纯契约
packages/storage/   SQLite 运行状态、配置与载荷存储
packages/runtime/   AgentRun、模型适配器、工具、上下文与恢复
packages/eval/      实验单元、尝试、结果，以及执行器/对象适配器
packages/cli/       TUI 与非交互式 CLI
packages/ui/        共享的对话、Markdown、Artifact 与 UI 基础组件

docs/               架构、产品、安全、隐私与测试契约
scripts/            构建规约、视觉检查、冒烟测试与发布辅助脚本

本地数据与安全边界

Maka 默认将工作区数据存储在 Electron userData 目录下：

<Electron userData>/workspaces/default/
  runtime.sqlite
  connection-catalog.json
  credential-vault.json
  settings.json
  artifacts/

当前值得关注的边界：

• 当前连接目录为 connection-catalog.json。已有的 llm-connections.json 文件保留在磁盘上，不会被导入；
• 会话、消息、执行账本、工作流、用量、自动化（Automations）与 Daily Review 存放在 runtime.sqlite；
• Runtime Policy 凭据，包括连接 API/OAuth 凭证、请求头、网页搜索密钥与代理密码，存放在本地明文 credential-vault.json 中，处于操作系统账号边界之后，POSIX 目录权限强制为 0700、文件权限强制为 0600；
• Runtime Host 客户端 profile 的访问凭据相互独立，存放在 /runtime-host-client/credentials.json。既有的 Electron safeStorage 凭据/令牌文件不会被导入；受影响的用户需重新进行身份认证；
• 渲染层不会收到明文凭据。文件写入、Shell 与危险工具调用均经过权限引擎；
• Eval 不会构造 Runtime，也不会读取 Runtime 存储。Maka 对象连接到已有的 Runtime Host。

安全报告与策略请参阅 SECURITY.md，当前隐私与沙箱契约请参阅 docs/README.md。

年轻工程师真的还不错

AI 并没有抹杀初级工程师的价值，反而提升了它。

2026 年 8 月 18 日 · 阅读时长约 4 分钟

"AI 吞噬了初级工程师的边际价值。"

这是我上一篇文章发出来后收到的反馈。按照这种说法，初级工程师的工作大致是这样的：

• 出现了一个需要解决的问题。由更有经验的人（比如高级工程师）来规划并设计解决方案。
• 高级工程师把工作拆分成多个小任务，清晰说明需要执行的步骤。每个任务交给一位初级工程师。
• 初级工程师去执行，如今的做法就是向 AI 工具下提示词（prompt），然后提交一个拉取请求（PR）。
• PR 由更资深的工程师给出反馈。初级工程师拿到反馈，再次交给 AI 工具，提出修改方案。
• 重复上述过程，直到完成。

如果实际工作就是上面这套流程，那我们为什么还需要初级工程师？他们只是把请求（有时还附带噪声）从一处传递到另一处，却要拿一份全职薪水。这个说法似乎有道理。

在匆忙下结论之前，让我们换一个角度来看同一个故事，或者说是用不同的方式来叙述它。

在我们的产品中，有一项功能多年来一直被客户提出需求，却始终没有开发出来。它本身并不算特别复杂，但也谈不上关键。或者说，至少没有对足够多的客户关键到能通过优先级评审的门槛。这意味着，年复一年，总有一部分客户因为缺少自己需要的功能而感到失望。

今年夏天，我们把这个问题交给了一位实习生（资历比初级工程师还要浅）来负责。这位实习生主导了整个功能的开发：他们与产品经理沟通，弄清楚问题与需求；撰写了关于实现方案的设计文档，与团队对齐，然后把它落地实现。当然，他们是在 AI 以及所在团队的帮助下完成这些工作的。

但他们是主导者。他们要处理各种不一致之处，要在技术与产品两个维度上权衡取舍。他们在发现问题时及时调整思路，并最终交付了价值。AI 确实产出了大部分代码，而决策权在他们手中。一个原本很可能永远不会被解决的客户问题，就这样被解决了——由一位实习生完成，而公司的成本极低。

所有工程师都在驾驭复杂性，区别在于驾驭多少。

撇开"任何公司在未来都仍然需要高级工程师"这一点不谈，初级工程师之所以仍然有价值，其实有非常务实的原因。

初级工程师依然能为组织贡献产能。 因为工程师的工作并不是按照规格说明写出代码（或者向 AI 工具下提示词），而是用软件去解决客户问题，并管理"该如何做"这一过程中所涉及的技术复杂性。这一点对所有工程师都适用。Staff 工程师（资深技术骨干）驾驭的是大量的复杂性，初级工程师驾驭的是少量的复杂性。但这个角色的本质是相同的。

AI 并没有削弱初级工程师的价值，反而提升了它（第 2/2 段）

这一变化的影响远不止编码本身。它要求理解问题本身，也要求理解客户视角。它要求理解的是：如果你以某种特定方式构建一个功能，就必然带来一组特定的权衡取舍。而这些权衡取舍已经超出了 AI 能够决策的范围，因为它们所需要的背景信息远比代码库更加广泛。技术决策仍然极其重要，初级工程师也在为此做出贡献，使组织能够做得更多。

培训成本实际上大幅下降了。 对于一名处于早期职业阶段的工程师来说，其大部分培训成本都用于理解公司的技术背景——即大型代码库与架构的种种细节——以及对其进行基础软件能力的训练，例如编程语言、工具链与开发模式。

在过去，这一过程要么需要初级工程师自身有相当的主观能动性，去调研各类主题、自学钻研；要么就需要更资深的同事投入真正的人力时间，去讲解一些基础概念。人类所提供的背景知识对于软件生产力而言仍然至关重要，因此这部分人力投入并没有被彻底消除。但借助 AI，这其中大量的工作可以被“短路”掉。

具备 AI 原生能力是非常有价值的。 整个行业不能一边在招聘描述中要求工程师必须具备 AI 原生能力，一边却又不去招聘最符合这一描述的人。如果我们假设 AI 将从根本上简化这一岗位中偏技术性的部分，那么那些从职业生涯起步阶段就开始使用 AI 的人，在积累了一定的经验之后，将会处于最有利的位置。

回到前面的例子，那位实习生交付的功能其实很早就被提出过。它本身并没有重要到能被排到高优先级，但又因为需要过多的判断而无法直接交给 AI 去完成。类似的任务在每一个团队中都会存在，并且会持续存在下去。AI 拓展了每一个层级——包括初级工程师——所能承担的工作范围。

更重要的是，工程组织始终需要技术判断力。而你的组织在未来所需要的那种判断力，当下就应该正在成长。