Insights

翻译：Transwan 校对：Carl Cui 从 Demo 到生产的“死亡之谷” 如果你做过 AI 功能，大概率有过这样的体验：团队在开发一个让人兴奋的新功能，发布排期已经敲定；模型能给出近乎完美的回答，系统原型看起来就像德芙那样丝滑。会议室里，每个人都开始想象它上线后会变成一个流行的产品，许多次，我曾坐在这样的会议室里，那种气氛确实很棒。 然后，你开始做发布前测试： 移动端延迟飙升到 10 秒；模型在占实际用户查询 15% 的边缘案例上开始产生幻觉。经过一番努力，你从 A/B 测试结果上看不到明显的提升，因为 AI 输出的方差太大，使得传统的假设检验基本上失效。安全团队第一周就标出了 340 个失败案例，而你每天都在调试那些以各种新颖方式失败的非确定性案例。 很多时候，这不是模型能力问题，而是工程规范问题。发布 AI 产品和交付传统软件很不一样，我吃了苦头之后才明白这一点。下面这份 playbook，就是我从这些经验里总结出来的经验教训。 延迟预算 每个 AI 功能都会带来额外的延迟开销。大语言模型推理需要时间，实际可能是 500 毫秒，也可能是 5 秒，甚至 50 秒，这取决于模型大小、输入长度以及基础设施配置。对 ToC 产品来说，用户往往期待低于 200 毫秒的交互响应，所以系统响应延迟不是一个上线后再优化的小问题，而是设计阶段就必须正面处理的硬约束。 我最常见到的错误，是团队只看 p50 延迟。一个 p50 为 800 毫秒的功能听起来还不错，直到你发现它的 p90 是 15 秒。这意味着每 100 个用户里，就有 10 个要坐在那里等 15 秒以上。放到规模化产品里，这就是每天成千上万次糟糕体验。 我的做法是按交互类型定义延迟预算，而不是给所有场景设一个统一标准： 同步交互，也就是用户盯着 loading 状态等待结果的场景，应该在 1 秒内完成 渐进式交互，也就是输出逐个 token 流式返回的场景，首个 token 应该在 500 毫秒内出现，完整响应最好控制在 5 秒内 异步交互，也就是用户可以继续做别的事的场景，可以在有进度提示的情况下放宽到 20 秒左右 冷启动也要单独测量。模型加载到内存后的第一个请求，可能比后续请求慢 10 倍。如果你的流量是突发型的，冷启动会特别惩罚那些在高峰时段进入产品的高活跃用户。 ...

Claude Fable 5 发布了，Claude Fable 5 下线了，这是在 2026 年 6 月初发生在前后脚的事情。 Anthropic 在 2026 年 6 月 9 日发布了 Claude Fable 5。它被称为一个带有安全限制的 Mythos 模型，面向 Pro、Max、Team 和 Enterprise 用户开放，本来这个开放窗口就很短：从 6 月 23 日开始，Fable 5 不再包含在默认订阅计划中，而是要消耗额外额度。 然后没几天，美国政府以国家安全为由，对 Anthropic 的 Fable 5 和 Mythos 5 实施出口管制，限制外国政府、外国公司和非美国人员访问这些模型。由于 Anthropic 难以在现有系统中可靠地区分用户国籍和访问资格，最终选择暂停所有客户对这两个模型的访问。 这个新闻当然炸裂。它牵涉模型能力、安全边界、出口管制、地缘政治等等因素。 但我想谈的是另一个问题：即使 Fable 5 没有下线，我们真的应该默认使用最强模型吗？ Fable 到底是贵，还是便宜？ Fable 5 发布后，围绕它的一个很有意思的讨论是“它到底值不值”。乍一看，像是在讨论价格，其实是跟工程决断有关。 国外 Mitchell Hashimoto 在社交媒体分享过一个的测试，他让 Fable、GPT-5.5 和 GLM-5.1 处理普通的“实现这个功能”类的编码任务，最终三个模型都给出了可接受的结果。不过成本差距非常明显：GLM-5.1 不到 1 美元，GPT-5.5 大约 1.50 美元，而 Fable 跑了 40 分钟，花了 9 美元。 ...

翻译：Transwan 改写：Carl Cui 最近几条新闻放在一起看，很有意思：Microsoft 开始收缩部分团队对 Claude Code 的使用，把工程师引回自家的 GitHub Copilot CLI；Uber 在 2025 年底向数千名工程师部署 Claude Code，结果四个月烧完了全年 AI 编程预算；Klarna 曾高调用 AI 替代大量客服，后来又重新招聘人工客服。 这 3 个故事很容易被解读成极端的版本：一种可能会说 AI 编程工具失败了，另一种可能会说这些公司只是暂时没做好成本管理。这两种说法都不准确，我觉得问题的本质其实是：AI 确实能加速一部分工作，但是很多企业把 AI 加速的这部分工作当成了全部工作。 Microsoft：好用，不代表可无限放大 Microsoft 是 AI 时代最激进的玩家之一，向 OpenAI 投入巨资，也深度推进自家的 AI 编程工具。但 Microsoft 内部很多工程师仍然偏好 Claude Code。工具好不好用，工程师的选择已经给出了答案。 问题不在于 Claude Code 没价值，而在于它在企业规模下太容易失控。一个工程师偶尔用 AI 写代码，和一个大型部门把 AI Agent 接进日常开发，是两种完全不同的成本结构。后者消耗的不是一个固定订阅费，而是持续增长的 token、上下文、工具调用和自动化尝试。 所以 Microsoft 的动作，与其说是“停止使用 AI”，不如说是企业终于开始重新思考：哪些 AI 工具值得用，在哪些场景里用，谁来付账，成本上限在哪里，数据和工作流又该留在谁的平台里。 这不是 AI 无用，而是 AI 进入企业主流程之后，凸显出预算、治理和平台控制权的重要性。 Uber：使用量不是价值 Uber 的数据看起来更像一场成功推广：工程师采用率很高，AI 参与的代码提交比例很高，Agentic AI 功能使用率也快速上涨。按很多公司的 AI KPI，这几乎可以写进成功案例。 ...

翻译：Transwan 改写：Codex 校对：Carl Cui 关于 AI 如何影响大脑，作者调研了来自国内、外的多项研究，从多个维度探讨了 AI 对于人类认知的影响。作者还在文中附上了参考链接，这些研究的结论并不是一边倒的，有些研究的结论甚至互相冲突，不禁让我联想最近耿同学曝光的学术圈造假丑闻。于是，对于各项研究，我们保持谨慎态度；关于 AI 会对人类产生哪些影响，我们需要进行独立思考。 图片来源：Shutterstock 引言 从 2023 年 ChatGPT 改变公众对 AI 的想象开始，到 2026 年今天，MIT、Wharton、Harvard、Stanford、Microsoft、OpenAI、Oxford、Google DeepMind，以及中国多所高校的研究者，都在研究同一个问题：AI 聊天机器人到底会怎样影响人的认知、学习和心理状态？ 这些研究的类型很杂，也很有价值：有脑部扫描和 EEG 实验，有数千人规模的随机对照试验，有纵向调查、荟萃分析（Meta-analysis），也有发生在真实课堂和工作场所里的实地实验。其中既有预印本，也有已经经过同行评审的论文。 但问题在于，这些研究常常以孤立新闻的形式出现。一篇论文发布，一个耸动标题刷屏一天，然后很快被下一轮话题淹没。结果是，很多人隐约觉得 AI 可能正在改变我们的思考方式，却很少有人真正看到完整图景。 这篇文章试图把这张图拼起来。我汇总了 30 多项研究，逐项看它们到底发现了什么：当我们使用 AI 聊天机器人时，大脑活动、思维方式、学习效果和情感生活会发生哪些变化。更重要的是，我也会指出目前科学界还不知道什么。 最终浮现出来的是一个悖论。这个悖论会影响政策制定、产品设计、个人使用习惯，以及我们整体上如何和这项既令人兴奋又令人不安的新技术相处。 I. 你的大脑活动会下降 目前已经有少量但不断增加的研究，把人放进脑部扫描仪，或在他们使用 ChatGPT 时佩戴 EEG 传感器。相比自我报告和普通行为测试，神经影像学工具更接近直接观察大脑活动，因此这些研究虽然样本量通常不大，却很值得关注。 Your Brain on ChatGPT，Kosmyna 等人（arXiv 预印本，2025，N=54）：MIT Media Lab 用 32 通道 EEG 跟踪三组参与者数月内的写作过程：ChatGPT 用户、Google 搜索用户和无辅助写作者。结果显示，ChatGPT 组的神经连接最弱，比无辅助写作者低最高约 55%。随着实验推进，他们越来越依赖复制粘贴。到了第 4 阶段，当 ChatGPT 组被要求独立写作时，大脑活动仍然处于受抑状态，研究者称之为“认知债务”。相反，原本无辅助写作的人在第 4 阶段首次使用 ChatGPT 时，大脑连接反而增强。Kosmyna 的总结很关键：“时机可能很重要。” Lower engagement of cognitive control, attention, modulation networks and lower creativity in children while using ChatGPT，Horowitz-Kraus 等人（bioRxiv 预印本，2025，N=31）：这是目前少见的使用 fMRI 同时观察儿童和成人与聊天机器人互动时大脑活动的研究。成年人在认知控制网络中表现出更强的网络内连接；儿童则在认知控制、注意力和调节网络上的参与度较低。这暗示儿童大脑可能比成人更容易受到 AI 使用方式的影响。 EEG during creative design with AI tools，Wang 等人（Frontiers in Psychology，2025，N=64）：这项研究给出了相反方向的证据。使用 ChatGPT、Midjourney、Stable Diffusion 等 AI 创意工具的设计专业学生，比使用传统软件的对照组表现出更高的专注度和更好的创意表现。关键区别在于，他们不是被动接收答案，而是在主动指挥 AI 作为创意工具。 Effects of different AI-driven chatbot feedback on learning outcomes and brain activity，Yin 等人（Nature portfolio，2025，N=87）：研究者用 fNIRS 测量学生和聊天机器人互动时的大脑激活情况。不同反馈方式会激活不同区域。元认知反馈，比如“你为什么认为那是答案？”，会增加额极区激活，并与更高的迁移分数相关；中性反馈则更多激活背外侧前额叶皮层。换句话说，聊天机器人怎么和你说话，会改变你的大脑怎么工作。 NeuroChat: A neuroadaptive AI chatbot for customizing learning experiences，Baradari 等人（arXiv 预印本，2025，N=24）：MIT Media Lab 做了一个能实时监测 EEG 的原型系统。当它检测到参与度下降时，会调整回复方式。相比标准聊天机器人，它显著提升了 EEG 测得的参与度和自我报告参与感，但没有改善短期学习结果。这说明“认知脱离”不是不可避免的，产品设计可以介入。 结论：大脑成像证据仍处在早期阶段，样本量小，预印本多，而且结果并不完全一致。但整体模式已经比较清楚：被动使用 AI，也就是让 AI 直接给答案，往往会降低与费力思考相关的大脑参与；主动使用 AI，也就是把它当作需要你指挥和挑战的工具，则可能维持甚至提高参与度。关键变量不是有没有 AI，而是 AI 到底要求你的大脑做什么。当 AI 替你思考时，你的大脑自然会少做一些。 ...

1. Composio 是什么 在智能应用的开发中，让 AI 与外部应用交互常是复杂的一步，开发者需要逐一处理每个软件的 API 文档、复杂的 OAuth 认证和繁琐的令牌刷新。Composio 的核心价值在于将所有这些复杂性“一键封装”，让开发者只需一次接入，即可为自己的 agent 赋予操作海量应用的能力。它是一个专为 AI agent 设计的“万能工具集”和“连接中枢”。 你可以把它理解成 AI 界的“乐高”，Composio 为 AI agent 提供了海量的标准化积木（即各种 SaaS 服务的连接工具），让 agent 能轻松地执行发送邮件、更新表格、创建代码仓库等任务。 1.1 主要功能 Composio 提供下面这些主要功能： 庞大的工具库 - 支持超过 250+ 软件和系统，横跨主流办公、协作、开发与数据平台 开箱即用 - 内置 OpenAI、LangChain 等几乎所有主流 AI 开发框架的插件，能与现有工作流无缝集成 MCP 协议支持 - 全面支持 Model Context Protocol，让不同框架的 AI 模型能用标准化的“语言”发现并调用各种工具 平台托管：平台统 - 管理所有第三方工具的 OAuth、API Key 认证流程和自动刷新，代理无需直接接触敏感凭证 全链路安全管理 - 提供 SOC 2 Type II 等企业级安全认证，具备基于角色的权限控制 RBAC、审计日志等特性 ...

1. 前言 最近读到一篇文章 Software, in a Time of Fear，这是作者 Ed Lyons 写的一篇随笔，以登山为比喻，描述了他从攀登艰难山路的过程中学到的经验教训，探讨如何在 AI 时代的恐慌中保持清醒。作者不否认 AI 会淘汰一部分人，但是他认为 AI 对软件开发者的威胁被严重夸大了，大量的恐慌其实是来自“注意力漩涡”——那些靠贩卖焦虑吸引流量的网红和社交媒体，而不是来自真实的一手经验。 作者经常带自己的孩子们爬山，有一年打算去比弗山 Beehive 之前在网上查看了很多评论，结果作者越看越不敢尝试。因为评论里害怕的人和为了吹嘘自己的人都在渲染一种 Beehive 很危险的感觉。最终去过之后，作者发现其实 Beehive 没那么糟糕。作者把 Beehive 比作注意力漩涡。 2. 什么是注意力漩涡 心理学上，注意力漩涡是一个比喻性的概念，用来描述一种注意力被持续卷入、难以自拔，最终导致心智资源耗尽的状态，就像水中的漩涡一样，你的注意力被某种力量持续牵引、卷入，在其中不断消耗。生活中，我们每个人都会遇到各种各样的注意力漩涡。 2.1 算法制造的注意力漩涡 互联网平台会通过算法机制，根据你的停留时间、完播率、互动行为实时调整推荐，系统性地捕获、延长、加深用户的注意力投入，让用户在不知不觉中被卷入、消耗，难以自主退出： 本想看一眼朋友圈，结果刷了半小时还停不下来 本想放松一下看个短视频，结果一个接一个，放下手机时更累了 你以为你在主动选择看什么，实际上你看的内容都是被算法挑选出来的 无论哪种形态，算法制造的漩涡，你几乎不需要做什么就被引入其中，比如一个红点或者一条推送。 2.2 人际关系中的注意力漩涡 生活中，大家肯定碰到过“操弄”注意力漩涡的“高手”，他们可能出现在你的家庭、职场、社交圈中，你与他们相处后，总觉得疲惫、困惑，甚至开始怀疑自己。他们也许并不坏，但你总感觉自己的注意力、情绪、判断力在被某种看不见的力量牵引。 分化大师 - 在 A 面前说 B 的坏话，在 B 面前讲 A 的不是，他们不直接处理矛盾，而是把自己的负面情绪传导给第三方。你永远不知道他们对你的真实态度，因为他们对不同的人说着不同的话。当所有人都在互相不满，并且因此缺乏直接、真诚的联系时，他们就成了关系网络中不可绕过的枢纽。 美化大师 - 这类人总是将与自己相关的一切包装得光鲜亮丽，将无关或对立的一切贬得一文不值。比如对自己或亲人的成就严重夸大，一个普通的学历会被说成“出类拔萃”，一段微小的经历会被描述成“辉煌成就”。反过来，他们不喜欢的人或事，则会被描绘得极其糟糕。他们无法接受“人就是普通的，事就是平常的”这样的“灰色现实”，要求周围人的注意力也留在这个叙事中，为之鼓掌或为之愤怒。 紧急制造者 - 这类人频繁使用“现在”“马上”“立刻”等词汇，总是制造“现在必须处理”的假象。无论事情是否真正紧急，他们都能让你产生“如果不立刻回应就会出大事”的错觉，让你来不及判断，只能被动响应。 立场强制者 - 在他们的世界里，任何问题都必须站队。不站在他们那边，就是反对；保持中立，就是背叛。中立在他们看来是一种威胁，因为它意味着你不受他们控制。他们会不断测试你的立场，并通过各种方式迫使你表态，例如“你到底是帮谁”，或者“你说是不是这样”。 无论表现形式如何，这些手段都有几个共同点： 制造依赖：让你觉得需要他们才能理解情况、做出判断 消耗认知：把你的注意力从“重要的事”转移到“他们的事”上 扭曲现实：让你逐渐分不清“他们说的”和“实际发生的” 情感绑架：让你为他们的情绪负责，而不是为自己的生活负责 用“漩涡”这个词，强调的是外部存在一种结构性的力量在捕获你的注意力，而不是你“意志力不够”。识别这些手段，不是为了贴标签或对抗，而是为了让自己在关系中保持清醒：我的注意力是我的资源，只有我自己有权决定它投向哪里。 2.3 漩涡中的人会经历什么 注意力漩涡不是简单的“分心”或“走神”，它总不经意间影响你，消耗你的认知，妨碍你进行独立思考。而且危害往往是累积性、结构性的，不易察觉，却深刻影响着一个人的生活质量、关系健康和自我存在感。 ...

译者：Carl Cui 在 2024 年年中，The Innovation Game 上线。 The Innovation Game（简称 TIG）是一个基于区块链技术的现代项目，它协调大约 7000 个独立的、不可信的贡献者，针对那些具有重要科学价值的问题，迭代改进其算法。TIG 将这些问题作为挑战发布，例如 SAT 求解、车辆路径规划、二次背包问题、向量搜索和神经网络优化器设计等问题，贡献者提交解决这些问题的算法，算法测试者则被激励采用最高效的算法进行工作量证明，从而形成一种抗干扰的机制，用以奖励表现最优的算法。本质上，TIG 为算法开发创造了一个全新的经济框架。 这些贡献者之间无需相互信任。没有哪个中心机构规定什么才是好的，不过经过独立贡献者 476 次增量提交后，TIG 现在提出的二次背包问题的解决方案，已经超过了 Hochbaum 等人 2025 年在 European Journal of Operational Research 上发表的算法的质量。 TIG 这种协调机制几乎与当今最先进的 multi-agent 框架中采用的设计模式相同，通过分析 TIG，我们可以了解未来集群智能 swarm intelligence 的发展趋势。 1. Generator-Verifie 模式 在 agentic system 设计中，最老且最可靠的模式是将 Generator 和 Verifie 解耦：一个 agent 发起提议，另一个 agent 评估该提议。这种设计随处可见，比如 AlphaCode 的生成再过滤流程，比如宪法 AI 的批评修改循环，比如任何写代码然后运行测试的 coding agent。 TIG 在社会层面上实现了这一模式： 贡献者（Generator）将算法实现提交到一个开源仓库 算法测试者（Verifiers）针对实际问题运行这些算法并报告结果 贡献者获得的奖励与其算法的采用率成正比，即有多少算法测试者真正选择使用他们的算法。 ...

作者：Tanmay Bansal 译者：Carl Cui 译者之前翻译整理过 Wes McKinney 一篇 关于 AI Agent 的文章。和 Wes McKinney 那篇相比，Tanmay Bansal 这篇文章的思考深度差了不少。Wes 用了具体的代码库规模数据、自己的亲身经历、以及《人月神话》的理论来支撑其论点；而这篇文章更像是把流行观点重新包装了一遍。译者会在结尾第 9 节讨论这篇文章深度不足的地方。以下开始至第 8 节是文章内容。 大多数人认为 AI 将取代程序员、设计师和作家。这种说法有失偏颇。第一批悄然消失的工作更容易预测，而且隐蔽性很强。一不留神，你现在可能就在做着这样的工作。 这不是一个关于未来的理论警告。这已经在发生了，只是你还没有注意到。 1. 普遍观点 随便刷刷哪个技术论坛或者社交动态，都能感觉到那种恐惧。大家都觉得语言模型和 coding copilot 的到来，意味着工程部门和创新部门要被取代了。人们看到 AI 能写出过得去的代码，或者能生成文章，立刻就得出结论：那些正在做这些事情的人已经过时了。 表面上看这说得通：我们看到一台机器输出文字，就把它和“作家”这个职位联系起来；我们看到它输出一个 React 组件，就把它和“开发者”联系起来。 但这忽略了 AI 在现实世界中的实际应用情况。 2. 真实规律 这里的核心观点：人工智能取代的不是工作，而是取代那些可预测、可重复、也容易评估的任务。 The upcoming job scenario with AI: Image by Tanmay Bansal 仔细看看软件行业和现代知识密集型工作，你会发现其中有很多工作的产出其实只是把一些高度可预测的输出拼接了起来。这正是自动化首先冲击的领域。 3. 实际上正在被取代的工作 让我们分析一下那些正在悄然消失的工作类别。 3.1 中间层知识工作 想想那些纯粹为了喂算法或填写公司报告而生成的海量内容：基础的 SEO 文章生成、每周指标的总结，或是初级市场研究报告的汇总。 我自己管理着一份技术简报，从数据中可以看到：读者渴望独特的洞见，但网络上充斥着泛泛的总结。那些专门生产这些泛泛总结的工作，其产出高度结构化且易于验证，正在迅速减少。 3.2 协调与“胶水“角色 企业环境中充斥着纯粹用于将信息从 A 点传送到 B 点的角色。例如，做会议记录、根据 Slack 线程更新 Jira 工单、为高层管理人员格式化状态报告以及起草内部沟通摘要。 ...

作者：Wes McKinney 译者：Carl Cui 作者 Wes McKinney 是专注于分析计算领域的工程师和创业者，pandas 的创始人，《Python for Data Analysis》的作者。曾创立 Voltron Data 和 Ursa Labs，现任 Posit 首席架构师。作者的这篇文章从《人月神话》的核心观点出发，讨论了 AI Agent 给软件工程所带来的影响。 和很多人一样，我发现 AI 严重影响了我的睡眠。以前我会在凌晨四点或四点半短暂醒来喝口水或上个厕所，现在却很难再次入睡。以前我每晚能睡七八个小时，现在能睡六个小时就不错了。我基本上已经不再抗争了：现在当我在早上 5:07 辗转反侧，脑子里全是喂给 AI coding agent 的想法时，我就直接起床开始新的一天。 在我的工程师和数据科学家朋友圈里，大家都在讨论我们作为人类的竞争优势还能持续多久。当 agent 开始自己产生更好的想法时，拥有好想法（而且要多）还重要吗？现在感觉，人类专家的参与是从 agent 那里获得良好结果的必要条件。那这种状态，直到某个想法在我们睡觉时可以被 agent 转化为能运行、有品味的软件之前，还能持续多久？这是否会是一种温和淘汰，让我们愉快地交出控制权，还是别的什么？ 目前，我感觉自己还是被需要的。我不把自己现在这种工作方式描述为“vibe coding”，因为这听起来像是以一种贬义的“轻松搞定”的方式来构建 AI 垃圾软件项目。我一直在构建像 roborev 这样的工具，为我的并行 agent 会话带来严格性和持续监督，并对 agent 的工作进行严格审查。这种全新的工作方式让人不得不思考软件工程的未来。 我职业生涯中引用最多的书大概是 Fred Brooks 的《人月神话》，其中著名的 Brooks 定律认为“向一个已经延期的软件项目增加人手只会让它更晚”。最近我发现自己在思考这本书的教训是否适用于这个 agentic 开发的新时代。一个才华横溢的开发者指挥一群 AI agents，能否更快更好地构建复杂软件？短期的生产力提升是否会带来长期的项目成功？还是我们会遇到同样的问题？范围蔓延 scope creep、架构漂移 architectural drift 和沟通成本 coordination overhead，这些已经困扰软件团队几十年的问题。 1. 重读《人月神话》 Brooks 的核心论点之一是：少数精英组成的小团队胜过大量普通人组成的大团队。这能使得系统设计具有高度的概念完整性，就好像“一个人设计了它，即使是很多人参与了构建”。 Agentic 工程似乎放大了这些问题，因为其所构建软件的质量仅取决于参与其中的人类的水平：他们负责策划和完善 spec、对功能说“是或否”，以及控制不必要的代码和架构复杂性。《人月神话》中的一个比喻是“泥潭”：“每个人都能看到野兽在里面挣扎，看起来任何一只都能轻易逃脱，但泥潭把它们都困住了。”现在，我们有了一个新的“泥潭”，“agentic 泥潭”，我们的并行 Claude Code 会话和 git worktree 需要应付虚拟同事导致的代码膨胀和偶然复杂性。你可以系统地重构，但 agentic 代码库不可避免地会比任何人工构建的更大、更臃肿。这是前所未有的技术债务，以机器的速度累积。 ...

作者：Dean Wampler 译者：Carl Cui 1998 年，LAMP 的出现第一次清晰描述了用于构建网站的主要开源软件，也让无数开发者找到了构建 Web 应用的共同语言。二十多年后，生成式 AI 的浪潮同样呼唤一套属于这个时代的标准答案，PARK 栈由此而来。作者 Dean Wampler 在这篇文章中为我们展现了 AI 时代开源“风景”，更难得的是，作者在文章穿插了大量引用，方便感兴趣的读者继续探索。 1. 背景：LAMP 技术栈 根据 Wikipedia，LAMP 技术栈这个缩写是由 Michael Kunze 于 1998 年提出的，用于描述当时流行的用于构建网站的开源软件组合。在 20 世纪 90 年代初，随着万维网（WWW）的普及，各大组织使用各种专有工具和操作系统，外加一些开源软件（OSS - open source software）来构建网站。LAMP 技术栈迅速成为最受欢迎的开源组件集合。 LAMP 是一个缩写词，分别代表以下内容： 字母 组件 职责 L Linux 操作系统 A Apache HTTP Server 网络服务器 M MySQL 数据库 P Perl、PHP 和/或 Python 应用程序编程语言 在当时，依赖开源软件的想法是有争议的。因为源代码对所有人可见，人们担心缺乏支持和存在软件漏洞，最终这些问题解决了。开源之所以具有不可抗拒的吸引力，是因为流行的 OSS 项目提供了极大的灵活性、成本效益、无供应商锁定以及快速迭代。LAMP 堆栈成为企业采用开源的主要驱动力之一。 2. PARK 技术栈 就像互联网的兴起一样，大型语言模型（LLMs）、视觉模型（VMs）和其他生成式 AI 的突然爆发，促使人们去识别最适合生成式 AI 的 OSS 组件。这个时代出现了 PARK 技术栈。它是由 Ben Lorica 去年 11 月在文章 Trends Shaping the Future of AI Infrastructure 中首次提出的。 ...