docs: record transformative internet product innovations

appendices/internet-product-innovations.md

@@ -0,0 +1,244 @@
+# 互联网产品历史上的革命性创新
+
+本文记录改变互联网产品使用方式的代表性创新：它们面对什么长期问题，引入了什么新模型，以及用户因此可以怎样工作、获取内容或使用软件。范围包括 Web 产品，以及 iPhone 等改变互联网使用方式的设备与分发平台。
+
+这里的“革命性”是产品设计分析，指基本交互、信息组织、协作或分发模式发生变化，不是销量排名，也不是对所有案例影响程度相同的判断。产品能力和历史节点依据各条所列资料；问题归纳、前后对比与设计意义属于本文分析。例子用于说明模型，不表示所有早期产品都采用同一种做法。
+
+历史归属区分三种情况：提出新思想、实现可用产品、将已有思想组合并推广。代表产品不自动等于最早发明者；没有足够证据时，不使用“首次”或给出精确首发年份。本文提供一组可继续扩充的案例，不构成完整互联网史，也不定义 Endorphin 的语言规则。
+
+## 创新索引
+
+| 方向 | 代表产品或系统 | 长期问题 | 核心变化 |
+| --- | --- | --- | --- |
+| 交互 | iPhone | 固定键盘挤占屏幕，输入方式难以适应不同任务 | 多点触控、直接操作、按情境出现的软键盘 |
+| 信息连接 | World Wide Web | 跨系统访问文档需要不同工具和路径知识 | 可链接的资源与通用浏览器 |
+| 信息发现 | Google / PageRank | 匹配关键词后仍难判断哪些网页更重要 | 把链接结构纳入排序 |
+| 内容分发 | Facebook News Feed | 查看许多人的更新需要逐个访问主页 | 将动态聚合为可排序的信息流 |
+| 内容分发 | TikTok For You | 发现内容依赖主动搜索或预先关注 | 依据兴趣与行为反馈推荐内容 |
+| 文档协作 | Google Docs | 副本往返、版本合并和编辑冲突 | 多人共同编辑同一个在线对象 |
+| 知识协作 | Wiki / Wikipedia | 发布与修正文档依赖集中维护者 | 读者参与编辑，共同维护页面 |
+| 设计协作 | Figma | 设计文件、评审和交付使用不同副本 | 通过链接访问同一份协作设计 |
+| 开发协作 | GitHub Pull Request | 变更、讨论与合并决定分散 | 把变更提案组织成可审查的对象 |
+| 信息组织 | Notion | 文档、表格与任务工具彼此割裂 | 块、页面、数据库和视图的组合 |
+| 数据组织 | Airtable | 普通表格容易上手，数据库难以使用 | 用表格界面操作结构化记录及关系 |
+| 知识组织 | Roam Research / Obsidian | 单向链接难以显示概念被哪些笔记引用 | 网络化笔记与反向链接 |
+| 软件交付 | Salesforce / SaaS | 企业采购软件后还需部署和维护 | 使用供应商持续运营的在线服务 |
+| 软件分发 | App Store | 应用发现、购买、安装和更新分散 | 统一面向用户与开发者的分发入口 |
+| 工具组合 | Zapier | 跨应用工作依赖人工搬运或定制集成 | 配置触发条件、动作和数据映射 |
+
+## 交互、发现与内容分发
+
+### iPhone：固定键盘让位于可变化的触控界面
+
+早期手机和不少智能手机使用数字键盘、实体 QWERTY 键盘或触控笔。实体键盘的形状与位置固定，却需要同时服务拨号、文字输入、浏览网页等不同任务。
+
+2007 年公布的 iPhone 把大面积多点触控屏幕、手指操作和软键盘组合成主要交互方式。用户可以直接触碰屏幕中的对象，输入文字时再显示键盘；看照片、地图和网页时，同一块屏幕可以承担其他操作。
+
+核心变化是**让交互界面由软件按任务改变**。固定键盘占用的空间可以用于内容和操作对象，界面设计也不再必须围绕同一套物理键位安排。
+
+历史归属与边界：iPhone 是这一组合的代表性产品，不能据此认定它发明了触摸屏或多点触控。“不需要按键”应准确理解为减少对固定实体键盘的依赖；初代 iPhone 仍保留实体 Home 键等硬件按键。
+
+来源：[Apple，2007 年 iPhone 发布公告](https://www.apple.com/newsroom/2007/01/09Apple-Reinvents-the-Phone-with-iPhone/)，重点为多点触控、软键盘和网页浏览说明。
+
+### World Wide Web：把文档放进可以跨站连接的空间
+
+跨机构的信息可能存放在不同计算机和系统中。使用者需要知道资源的位置、访问工具和操作方式，文档之间的引用也未必能直接跳转。
+
+Web 将资源标识、超文本和访问协议组合起来，用浏览器访问页面，再通过链接进入其他资源。CERN 的历史记录将 Web 的提出追溯到 1989 年，并记录了 1993 年公开释放 Web 软件的节点。
+
+核心变化是**把跨系统的信息访问变成沿链接浏览**。发布者可以独立发布页面，其他人可以引用它，共同形成跨站点的信息网络。
+
+历史归属与边界：超文本早于 Web。Web 的贡献包含将超文本放入开放的网络体系并推广使用；这套体系仍有链接失效、内容变化和引用持久性问题。
+
+来源：[CERN，The birth of the Web](https://home.cern/science/computing/the-birth-of-the-web/)，重点为 1989 年起源与 1993 年开放节点；[Doug Engelbart Institute，1968 年 NLS 演示记录](https://www.dougengelbart.org/mousesite/1968Demo.html)，记录了更早的超文本与协作演示。
+
+### Google / PageRank：链接结构成为判断重要性的信号
+
+搜索能够找到包含关键词的网页，但匹配并不等于有用。网页数量增加后，用户还需要判断哪些结果更值得先看。
+
+Google 的早期研究把超文本链接结构纳入检索与排序；PageRank 是其中利用链接关系评估页面重要性的代表机制。链接不仅承担跳转，也可以成为排序信号。
+
+核心变化是**利用整个网络中的关系辅助理解单个网页**。搜索结果的价值不只来自“找到多少”，还来自能否把更有用的候选放在前面。
+
+历史归属与边界：Google 没有发明搜索引擎；PageRank 也不是完整搜索排序的全部因素。这里记录的是链接分析与大规模检索结合的代表案例，不认定所有相关思想都始于 Google。
+
+来源：[Brin 与 Page，1998 年论文的官方摘要与书目信息](https://research.google/pubs/the-anatomy-of-a-large-scale-hypertextual-web-search-engine/)，重点为利用超文本结构改进大规模搜索。本文不复述未取得的论文全文或算法公式。
+
+### Facebook News Feed：从访问主页转为接收动态序列
+
+当关注的人越来越多，逐个访问主页检查更新会变得繁琐。内容已经存在，但用户还要自己发现哪些地方发生了变化。
+
+Facebook 于 2006 年推出 News Feed，把来自不同人的动态聚合成序列。其后持续发展的排序机制决定每个人优先看到哪些内容。
+
+核心变化有两层：**把分散更新汇集到一个入口；把内容变成可以逐条排序的单元**。后一层使系统可以依据用户关系、反馈等信号调整展示顺序。
+
+这也解释了信息流与推荐算法的关系：统一的内容序列便于对候选内容评分、排序，并观察展示后的反馈。这是对产品结构的分析；推荐系统在信息流之外同样可以成立。
+
+历史归属与边界：信息流、按时间排列的更新和订阅聚合并非 Facebook 独创。信息流也不等于算法推荐，它可以按时间排序；是否使用无限滚动则是另一个交互选择。
+
+来源：[Facebook，Building a Better News Feed for You](https://about.fb.com/news/2016/06/building-a-better-news-feed-for-you/)，重点为 2006 年推出 News Feed 的回顾，以及排序目标与用户反馈说明。
+
+### TikTok For You：内容发现不必从关注关系开始
+
+按关注关系组织内容时，用户需要先知道该关注谁；主动搜索则要求用户先表达自己要找什么。对陌生领域，两种路径都有门槛。
+
+TikTok 把 For You 推荐流放在产品体验的中心，根据交互、视频信息等信号给内容排序。其 2020 年说明中包括点赞、分享、关注以及是否看完较长视频等反馈。
+
+核心变化是**将兴趣发现融入连续消费过程**。用户可以遇到尚未关注的创作者，观看与反馈又成为后续推荐的输入。
+
+历史归属与边界：推荐算法早于 TikTok。这里记录的是以推荐流为中心的产品组合，不能理解为完全不用关注关系，也不能把 2020 年说明视为今天算法参数的完整披露。
+
+来源：[TikTok，2020 年 For You 推荐机制说明](https://newsroom.tiktok.com/en-us/how-tiktok-recommends-videos-for-you)，重点为推荐因素、完播反馈与个性化发现。
+
+## 共享对象与多人协作
+
+### Google Docs：多人编辑同一个文档
+
+通过附件协作时，每个人持有不同副本。修改后要重新发送，再判断哪个版本较新、哪些改动需要合并。
+
+Google Docs 让多人共同编辑一个在线文档，用共享权限、评论与修订历史组织协作。文档链接成为访问同一个对象的入口。
+
+核心变化是**将协作的中心从交换副本改成共同修改状态**。例如两个人分别修改报告的不同段落，不必等一人完成并发送附件后，另一人才开始。
+
+历史归属与边界：多人协作与实时编辑存在更早的研究和产品，1968 年 NLS 演示已经展示过远程协作。Google Docs 是在线办公的代表产品；当前功能资料不能用来认定全部能力在同一天首发。
+
+来源：[Google Docs 官方产品说明](https://workspace.google.com/products/docs/)，重点为共同编辑、权限、评论和修订历史；[1968 年 NLS 演示记录](https://www.dougengelbart.org/mousesite/1968Demo.html)，用于说明更早的协作来源。
+
+### Wiki / Wikipedia：阅读者也可以维护知识页面
+
+集中维护的网站需要作者或管理员收集反馈、修改内容并重新发布。知识贡献者和页面发布者可能因此分离。
+
+Wiki 将编辑能力带到页面使用过程中，让参与者直接维护共享内容与链接。Ward Cunningham 的回顾确认了 1995 年的 Web Wiki；Wikipedia 则是 Wiki 模式用于共同维护百科内容的代表。
+
+核心变化是**把知识更新开放为持续参与的活动**。一份介绍不只由最初作者维护，后来的读者也能补充、修正和连接内容。
+
+历史归属与边界：WikiWikiWeb 与 Wikipedia 的贡献应分开记录，不能把 Wiki 的发明归给 Wikipedia。开放编辑也没有自动解决事实准确性和共识形成，相关治理仍属于产品机制的一部分。
+
+来源：[Ward Cunningham，Correspondence on the Etymology of Wiki](https://c2.com/doc/etymology.html)，重点为 1995 年确认、早期 Web 程序及对 Wikipedia 的回顾。
+
+### Figma：设计文件成为共同访问的在线工作空间
+
+设计协作容易产生不同的文件副本。设计师修改源文件后，还需要更新评审材料、原型和交付内容；团队成员可能依据旧稿工作。
+
+Figma 将专业设计工具放进浏览器，并提供多人编辑。官方回顾记录了 2016 年多人编辑节点，强调设计更新后共享 URL 保持不变，以及团队通过同一对象获得最新内容。
+
+核心变化是**把设计、查看和反馈围绕同一份持续更新的内容组织起来**。同事打开链接即可参与，协作过程不必以反复导出和发送文件为中心。
+
+历史归属与边界：Figma 没有发明在线协作。这里记录的是将共享对象模式应用到专业设计流程的贡献，不照搬官方营销文字中的所有“首个”判断。
+
+来源：[Figma，Reflecting on Figma’s First Year](https://www.figma.com/blog/reflecting-on-figmas-first-year/)，重点为 Collaborative design 小节及共享 URL、设计交付说明。
+
+### GitHub Pull Request：把一次改动组织成可讨论的提案
+
+软件贡献需要展示改动、解释原因、接收反馈，再决定是否合并。如果代码、邮件讨论和合并决定分别存放，参与者需要自己拼合上下文。
+
+GitHub 在 2008 年发布 Pull Request 功能。它后来发展为围绕变更提案组织讨论、差异、审查和检查结果的协作对象。
+
+核心变化是**让“建议修改什么、为什么修改、是否接受”有一个共同入口**。维护者可以在接受改动之前讨论它，提议者可以继续完善同一提案。
+
+历史归属与边界：Git、补丁审查和请求拉取的工作方式都不是 GitHub 从零发明的。2008 年公告描述的早期功能也不能等同于今天完整的 Pull Request 体验。
+
+来源：[GitHub，2008 年 Pull Request 公告](https://github.blog/news-insights/the-library/oh-yeah-there-s-pull-requests-now/)；[GitHub，当前 Pull Request 参考](https://docs.github.com/en/pull-requests/reference/pull-requests)，分别用于核对历史节点与成熟后的协作模型。
+
+## 信息单元、数据库与知识网络
+
+### Notion：块、页面与数据库组合成可搭建的工作空间
+
+文档适合连续表达，表格适合结构化记录，任务工具适合跟踪状态。分开的工具容易让同一件事重复出现在说明文档、任务表和项目看板中。
+
+Notion 用块组成页面，块可以移动、重排或转换；数据库中的每条记录又是一张页面，可以同时具有属性和自由内容。同一组记录可以通过不同视图呈现。
+
+核心变化是**让内容、结构化记录和展示方式在一个模型中连接起来**。一项任务可以有状态、负责人等属性，也可以打开为包含背景、图片和讨论的完整页面。
+
+这比“文档工具加了一张表格”更深入：数据库行本身具有页面内容，页面又可以包含数据库。用户因此可以组合自己的工作空间，而不只填写固定产品提供的表单。
+
+历史归属与边界：块编辑、复合文档和终端用户数据库都有更早来源。Notion 应记录为这种组合的代表产品；当前帮助文档不足以证明它是各项机制的首创者。
+
+来源：[Notion，What is a block](https://www.notion.com/help/what-is-a-block)，重点为块转换与重排；[Notion，Intro to databases](https://www.notion.com/help/intro-to-databases)，重点为每条记录都是页面、属性与多视图。
+
+### Airtable：用表格的入口提供数据库的组织能力
+
+电子表格容易编辑，但当一张表需要管理客户、项目或库存时，单元格中的重复文字不容易表达对象之间的关系。传统数据库则往往要求更专业的操作知识。
+
+Airtable 把表格式界面与结构化记录、字段和记录关联结合起来。其 2015 年公开资料明确把“让非程序员使用数据库”作为产品方向。
+
+核心变化是**让业务使用者可以直接建立自己的数据模型**。例如将客户和项目分别作为记录，再关联起来，而不只在每个项目行里重复录入客户信息。
+
+历史归属与边界：面向普通用户的数据库早于 Airtable。它代表的是数据库能力与易上手、可协作的 Web 产品体验结合；表格外观不表示它只是电子表格的另一种皮肤。
+
+来源：[Airtable，2015 年 Democratizing the Database](https://www.airtable.com/newsroom/democratizing-the-database-3)，重点为产品方向与面向普通用户的数据库；[Airtable，关联记录说明](https://support.airtable.com/docs/linking-records-in-airtable)，用于核对记录关系。
+
+### Roam Research / Obsidian：通过关系重新组织笔记
+
+文件夹要求用户选择笔记的存放位置。笔记可以包含多个主题，即使添加了单向链接，打开某个主题时也未必知道哪些笔记引用过它。
+
+Roam Research 的知识网络思路强调节点、连接和重叠的组织关系。Obsidian 的反向链接功能则明确展示当前笔记的链接提及与未链接提及：如果笔记 A 链接到 B，打开 B 时可以看到来自 A 的引用。
+
+核心变化是**让一个概念的上下文从引用关系中汇集出来**。例如不同会议记录都链接到“用户身份”，该主题页的反向链接就成为寻找相关讨论的入口。
+
+历史归属与边界：这里常说的“双向链接”，通常是正向引用加可查询的反向索引，不必在两篇笔记中分别手写链接。更早的 Xanadu 已明确讨论双向链接；Roam 与 Obsidian 不应被认定为这个思想的发明者。笔记库内的反向索引也不同于整个 Web 都提供双向可追踪的链接。
+
+来源：[Obsidian，Backlinks](https://obsidian.md/help/plugins/backlinks)，重点为 Linked mentions 与 Unlinked mentions；[Xanadu，2001 年结构说明](https://xanadu.com/nxu/)，用于核对更早的双向链接设计；[Roam 白皮书的社区镜像](https://heckler.roam.garden/@white-paper/)，仅使用摘要及知识图谱相关小节说明其设计思想，镜像不能独立证明产品首发时间或全部功能已实现。
+
+## 软件交付、分发与组合
+
+### Salesforce / SaaS：软件由供应商持续运营
+
+企业购买传统软件后，可能还要承担服务器配置、安装、升级和维护。购买许可与开始使用之间，存在一段较长的交付过程。
+
+Salesforce 是将企业 CRM 作为在线服务提供的代表。其官方历史将这一方向追溯至 1999 年创立时期。SaaS 指由供应商运营软件，通过网络向客户提供使用能力的服务模式。
+
+核心变化是**把客户的主要任务从拥有并维护软件转成使用服务**。供应商持续交付能力，客户通过账号和配置组织业务。
+
+历史归属与边界：远程软件服务存在更早来源，不能把全部 SaaS 思想归给 Salesforce。SaaS 是交付与运营方式，订阅是商业模式，两者常一起出现，但不能当作同义词。
+
+来源：[Salesforce，Our story](https://www.salesforce.com/ca/company/our-story/)，重点为 1999 年历史节点及将 CRM 带到云端的说明。
+
+### App Store：应用分发成为平台的统一能力
+
+应用发现、购买、下载、安装和更新如果分散在不同渠道，用户需要分别理解操作方式，开发者也需要自行建设相应渠道。
+
+Apple 在 2008 年推出 App Store，将应用发现与分发组织到统一入口，连接用户和第三方开发者，并提供平台侧的分发与支付体系。
+
+核心变化是**让开发者围绕产品开发工作，让用户通过熟悉的入口获取不同应用**。这与 iPhone 的交互创新属于不同层面：一个改变怎样操作设备，另一个改变怎样获得设备上的能力。
+
+历史归属与边界：软件商店、下载平台和包管理器早于 App Store。这里记录的是面向大众移动设备的成熟分发组合；统一入口也意味着平台承担准入与分发规则的制定权。
+
+来源：[Apple，The App Store turns 10](https://www.apple.com/newsroom/2018/07/app-store-turns-10/)，重点为 2008 年推出节点、开发者分发及支付体系说明。
+
+### Zapier：跨应用工作可以由用户配置
+
+业务流程常横跨表单、数据库、邮件和团队沟通工具。每个应用都能完成自己的部分，但应用之间的衔接需要人工复制，或由程序员开发集成。
+
+Zapier 将跨应用自动化表达为触发条件、一个或多个动作，以及步骤间的数据映射。例如收到新线索后，创建客户记录，再通知相关团队。
+
+核心变化是**将应用连接的能力交给配置工作流的人**。用户选择事件和动作，并把前一步产生的字段映射到后一步输入，不必为每条流程重新编写完整集成程序。
+
+历史归属与边界：工作流自动化、事件驱动和可视化编程都有更早来源。Zapier 是跨 Web 应用组合的代表产品，具体能连接哪些操作仍取决于应用开放的接口和授权。
+
+来源：[Zapier，What is a Zap](https://help.zapier.com/hc/en-us/articles/8496309697421-What-is-a-Zap)，重点为触发条件、动作和数据映射。
+
+## 从这些案例中观察到的共同变化
+
+下表是本文对案例的归纳，用于比较设计方向，不表示所有产品都经历过完全相同的演进。
+
+| 变化 | 代表案例 | 被改变的基本单位或职责 |
+| --- | --- | --- |
+| 操作方式可以随任务变化 | iPhone | 固定硬件输入变为软件定义的交互 |
+| 信息关系参与组织与判断 | Web、PageRank、双向链接 | 单个文档之外的连接成为可利用的信息 |
+| 内容进入统一的分发序列 | News Feed、For You | 用户逐个寻找来源，转为系统组织内容候选 |
+| 协作围绕共同对象开展 | Google Docs、Figma、Pull Request | 副本与分散讨论，转为共享状态或变更提案 |
+| 用户可以组合信息和工具 | Notion、Airtable、Zapier | 固定应用功能，扩展为可配置的数据与工作流程 |
+| 通用交付工作由服务或平台承担 | SaaS、App Store | 部署、维护或分发成为供应商持续提供的能力 |
+
+识别后续案例时，可以继续记录：旧流程中哪一步长期需要用户手工补偿；新产品改变了什么对象或关系；用户能否因此采用不同的工作方式；贡献属于原创思想、产品组合还是推广。仅增加一个按钮、换一种视觉风格或扩大用户规模，不足以单独说明基本模型发生了变化。
+
+## 来源核查与维护
+
+核查日期：2026-10-08。各条来源链接指向对应原页；标明社区镜像的 Roam 白皮书除外。当前帮助文档用于核对能力模型，历史公告和回顾用于核对时间节点，两类证据不互相替代。
+
+本次已读取所引用页面的相关正文或明确标出的摘要。Google 早期论文仅取得官方摘要；Roam 白皮书使用社区镜像，并保留其可用范围。未取得正文的 Google 历史博客、论文全文与个别产品页面未作为全文依据。
+
+后续增加案例时，保留长期问题、核心变化、具体例子、历史归属与来源。涉及“最早”“首次”等判断时，需要额外核对前驱产品；来源改变或失效时更新核查记录。这里的设计分析不自动成为本项目的语言决定。
+
+[返回目录](../README.md)