IT瘾google推荐

Google将在 AI 模式中增加来源链接和说明性摘要

Thu, 11 Dec 2025 01:35:38 CST

Google宣布将对其 AI 驱动的搜索功能“AI 模式”（AI Mode）进行更新，在回答中加入更多内嵌来源链接，并由 AI 生成简短说明，解释这些来源为何与当前问题相关。

Google展示的示例中，AI 模式在搜索结果页顶部给出一段概括性文字，紧接着在其下方以轮播形式列出相关网站链接，例如在回答“如何用低预算打造复古家居风格”时，系统会先用一段话总结这些文章主要提供的二手淘货建议、建筑细节改造思路（如线条、五金更换）以及 DIY 项目等内容，然后再呈现各家媒体的链接入口。 Google同时表示，用户今后会在 AI 模式生成的回答中看到更多被加上超链接的词语或短语，并配套一段对嵌入式来源的 AI 描述，以帮助理解这些链接的价值。

这一调整出现在欧盟监管机构加大对生成式 AI 搜索审查的背景下。几天前，欧盟委员会刚刚启动对Google的调查，评估其在 AI 功能中使用网络出版商内容时，是否违反了竞争规则、且未给予“适当补偿”；而在今年 8 月，有研究指出，当搜索结果中出现 AI 总结时，用户点击常规链接的意愿会下降，Google当时反驳称整体点击量仍“相对稳定”。

在强化来源展示的同时，Google还宣布与多家媒体启动试点合作项目，探索 AI 工具如何为新闻机构带来更高黏性的受众。参与的出版方包括《卫报》《华盛顿邮报》和《华盛顿观察家报》等，其中一项实验是在 Google 新闻中为文章配上 AI 撰写的概览摘要；Google也正与美联社及其他机构合作，将实时资讯通过 Gemini 应用推送给用户。

此外，Google还将一项名为“偏好来源”（preferred sources）的功能推广到全球英语用户，允许用户在新闻和信息流中更突出地看到自己偏好的媒体来源。 Google希望，通过在 AI 模式中增加更可见、更细致的外部链接说明，并与主流媒体展开实验性合作，缓解外界对其“截流”网站流量、却未给予足够回报的担忧。

查看评论

‎Google Gemini3有哪些实用且高效的应用场景

Wed, 03 Dec 2025 10:21:35 CST

结合 Gemini 1.5 Pro 强大的超长上下文和多模态能力，以下是大约 15个 极其实用且高效的应用场景：

📚 研究与文档处理 (利用超长上下文)

长篇报告摘要与问答：
- 场景： 上传一本厚厚的行业分析报告、学术论文或公司年报（数百页的 PDF）。
- 用途： 要求 Gemini 总结核心观点、提炼关键数据，或直接针对某个具体问题（如“2025年的主要增长驱动力是什么？”）进行精准问答。
代码库分析与审查：
- 场景： 将一个包含完整代码、文档和日志的压缩包（几万行代码）上传。
- 用途： 要求 Gemini 找出所有潜在的安全漏洞、提出优化代码结构或重构的建议，甚至根据日志找出 Bug 的根源。

🎥 媒体与多模态分析 (利用多模态能力)

视频内容精准定位与提炼：
- 场景： 上传一段 2 小时长的会议录像、教学课程或访谈视频。
- 用途： 询问视频中某个话题（如“谁提到了预算削减？”）的精确时间戳，或要求总结所有发言人的核心观点。
扫描手写文档的数字化：
- 场景： 上传一张模糊的、老旧的、手写的食谱或笔记的照片。
- 用途： 让 Gemini 不仅将其准确转录为电子文本，还能根据内容推断出一些模糊字迹的含义。
图表数据解读与对比：
- 场景： 上传包含大量复杂图表和数据的商业演示文稿（PPT/PDF）。
- 用途： 让 Gemini 分析图表的趋势，解释数据之间的关系，并将其结果总结为几点清晰的结论。

💡 规划与创意辅助 (利用高级推理)

复杂项目资料整合：
- 场景： 同时上传包含合同、设计草稿、供应商邮件、项目排期表的多个文件。
- 用途： 要求 Gemini 整合所有信息，找出项目中可能存在的“时间冲突”或“未解决的风险点”。
旅行路线优化与定制：
- 场景： 上传多篇旅行博客、地图截图和酒店预订信息。
- 用途： 让 Gemini 根据您的偏好（如“避开人群”、“美食优先”）规划出一条最优化、最顺畅的 5 日旅行路线。
专业术语和概念连接：
- 场景： 上传一本专业领域的入门教材和一本进阶教材。
- 用途： 让 Gemini 解释两个教材中某个关键概念的不同侧重点和演变历程。

🌐 个人与生活辅助

跨文件信息一致性检查：
- 场景： 上传您的简历、求职信和 LinkedIn 个人资料的文本。
- 用途： 让 Gemini 检查所有文件中关于您的工作经历、职位名称、或专业技能的描述是否完全一致，避免矛盾。
长期邮件/对话总结：

场景： 上传您和合作伙伴长达一年的邮件往来记录（或聊天记录）。
用途： 让 Gemini 总结你们在某个特定主题（如“上次的合作项目”）上，最终达成了哪些具体决定和未完成的事项。

11.实时数据流监控与预警

场景： 监控大型服务器、金融市场交易、或工业物联网 (IoT) 传感器传来的海量、持续的数据流。
Gemini 优势： 它可以同时处理并记住数小时甚至数天的数据，快速识别**“异常模式” 。它能将当前的实时数据与历史正常数据模式**进行比较，一旦发现哪怕是细微的偏差，立刻触发预警，远超简单阈值警报。

12. 持久记忆的个性化 AI 伴侣

场景： 将 Gemini 作为您的长期私人助理。
Gemini 优势： 由于上下文窗口巨大，它可以记住您数月来的所有对话、习惯、偏好、甚至细微的情绪变化。例如，您不用重复提到您对咖啡的偏好、您的家庭成员名字或您正在进行的项目进度。它能以一种前所未有的连贯性和深度来提供个性化服务。

13. 跨语言实时会议口译

场景： 国际会议、跨国商务谈判或教育研讨会。
Gemini 优势： 它可以 持续接收来自不同语言的音频输入，并提供 实时、高语境关联的口译。由于它能记住完整的对话流程和专业术语，因此翻译的连贯性和准确性远高于传统机器翻译。

14. 交互式教育与技能陪练

场景： 编程教学、复杂数学辅导或语言学习。
Gemini 优势： 它可以记住学生在整个课程中的所有测试结果、犯错的模式和学习进度。它能像人类导师一样，根据学生实时的输入，即时调整难度和教学策略，提供高度个性化和连续性的教学体验。

15. 复杂设备故障排除与辅助

场景： 维修复杂的机械设备、飞机引擎或医疗设备。
Gemini 优势： 维修人员可以将实时诊断数据、现场照片、甚至视频流同时输入给 Gemini。模型可以一边参考 整本设备维修手册（巨大的上下文），一边分析实时数据，给出逐步的、针对现场情况的、精确的排除故障指令。

Google 称 Gemma 3 使用一张 H100 GPU 就能获得与 DeepSeek R1 相当的性能

Thu, 13 Mar 2025 16:44:19 CST

Google 发布了新的多模模型 Gemma 3，开放权重，允许负责任的商业用途，128K 个令牌上下文，支持超过 140 种语言，提供了 10 亿、40 亿、120 亿、270 亿参数规模的模型可供选项。Google 称，Gemma 3 的 Elo 得分相当于 DeepSeek AI R1 模型的 98%，分别为 1338 分和 1363 分。但 DeepSeek 需要 32 张英伟达 H100 GPU 才能达到这一分数，而 Gemma 3 只需要一张 H100 GPU。Google 宣称 Gemma 3 是能在单张 GPU 或 TPU 上运行的最强大模型。

Google DeepMind 发布多模态轻量级开源模型 Gemma 3：性能与功能全面升级

Wed, 12 Mar 2025 20:07:38 CST

近日，Google DeepMind 团队推出了 Gemma 3，一款多模态轻量级开源模型，它在 Gemma 系列中引入了视觉理解、更广泛的语言覆盖和更长的上下文处理能力。本文将深入剖析 Gemma 3 的技术报告，探讨其创新之处以及对人工智能领域的潜在影响。

一、Gemma 3 的核心特性

（一）多模态能力

Gemma 3 不仅能够处理文本数据，还具备视觉理解能力。它通过定制版的 SigLIP 视觉编码器，将图像转化为模型可处理的软标记序列。为了减少图像处理的推理成本，模型将视觉嵌入压缩为固定大小的 256 个向量。此外，Gemma 3 采用了一种名为“Pan and Scan”（P&S）的技术，能够灵活处理不同分辨率和宽高比的图像，从而提升模型在视觉任务上的表现。

（二）长上下文处理

Gemma 3 的上下文长度显著提升，大多数模型版本支持至少 128K tokens 的上下文处理，而 1B 模型则支持 32K tokens。为了应对长上下文带来的内存爆炸问题，模型架构进行了优化，增加了局部注意力层与全局注意力层的比例，并缩短局部注意力层的跨度。具体而言，每 5 个局部层后跟 1 个全局层，全局层负责处理长距离依赖关系，而局部层则专注于较短范围内的信息交互。

（三）多语言支持

Gemma 3 在多语言能力方面也取得了显著进展。通过调整训练数据的混合比例和引入更多的多语言数据，模型能够更好地理解和生成多种语言的文本。这使得 Gemma 3 在跨语言任务中表现出色，进一步拓展了其应用场景。

二、模型架构与训练方法

（一）架构设计

Gemma 3 基于decoder-only 的 Transformer 架构，与前两代 Gemma 模型类似。但在细节上有所创新，例如采用 Grouped-Query Attention（GQA）和 RMSNorm 规范化方法。此外，模型还引入了 QK-norm 替代 Gemma 2 中的软封顶机制，以提升性能和稳定性。

（二）训练策略

Gemma 3 的训练过程包括预训练和指令微调两个阶段。在预训练阶段，模型使用知识蒸馏技术，从大规模数据中学习语言和视觉表示。训练数据涵盖了文本、图像以及多语言等多种类型，且经过严格的筛选和清洗，以减少有害内容和低质量数据的影响。在指令微调阶段，Gemma 3 采用了新颖的训练方法，重点关注数学、聊天、指令遵循和多语言等能力的提升。

三、性能评估与应用前景

（一）性能表现

Gemma 3 在多个基准测试中展现了卓越的性能。例如，在 LMSYS Chatbot Arena 的盲评中，Gemma-3-27B-IT 模型得分达到 1338，跻身前十名。在标准基准测试中，Gemma 3 在多语言理解、代码生成、数学推理等多个任务上均取得了优异成绩，部分指标甚至超越了更大规模的模型。

（二）应用潜力

凭借其多模态、长上下文和多语言等能力，Gemma 3 可广泛应用于智能助手、内容创作、教育、医疗等领域。例如，在智能助手方面，Gemma 3 能够理解用户的自然语言指令和图像输入，提供更加智能和个性化的服务。在教育领域，它可辅助教学内容生成、作业批改等工作。

四、安全与责任

Gemma 3 的开发团队高度重视模型的安全性和责任问题。在训练过程中，实施了严格的安全策略，对数据进行筛选和过滤，以减少有害内容的生成风险。此外，还对模型进行了碳足迹评估，并采取了相应的碳中和措施，以降低环境影响。

总之，Gemma 3 作为一款多模态轻量级开源模型，在性能和功能上实现了全面升级。它的发布为人工智能领域带来了新的机遇和挑战，有望在众多实际应用中发挥重要作用。

以下是Gemma 3技术报告英中对照版：

Gemma3技术报告英中对照版下载

Google搜索引擎架构Caffeine

Wed, 04 Dec 2024 22:09:28 CST

什么是 Google Caffeine？

Google Caffeine 是 Google 搜索引擎的一次架构重构，旨在满足不断增长的互联网内容和用户实时搜索需求。它替代了 Google 早期的分层索引系统，转而采用更加实时的索引机制，使搜索结果更加快速和新鲜。

发布时间：Google 于 2009 年 8 月发布 Caffeine 项目 Beta 版本，并于 2010 年 6 月正式启用。

Google Caffeine的产生背景

传统索引架构的局限性

在 Caffeine 出现之前，Google 使用的是一个分层的索引结构：

分层索引：
- 数据分为“主索引”和“增量索引”。
- 主索引：周期性地更新，通常需要几天或几周。
- 增量索引：包含最新的数据，但覆盖范围较小。
更新延迟：对于新增的网页或内容，用户可能需要等待较长时间才能在搜索结果中看到。
扩展性瓶颈：随着互联网内容的指数增长，传统架构难以高效处理。

Google Caffeine 的目标

提高索引速度：支持更快地抓取和处理新增内容（如新闻、博客、社交媒体）。
改进搜索结果的新鲜度：实现接近实时的搜索结果，用户能够快速获取最新信息。
扩展性：提升 Google 数据中心的存储和处理能力，满足日益增长的互联网规模。
提升性能：降低搜索延迟，改善用户体验。

Google Caffeine 的核心特性

实时索引：
- Caffeine 实现了一个单层实时索引系统。
- 新的网页和内容在被抓取后，几乎立即可供搜索使用。
分布式处理：
- 利用 Google 的分布式文件系统（GFS），对网页进行分片存储和处理。
- 大量服务器协同工作，提高数据处理速度。
高效的分片机制：
- 把网页划分为多个独立的“索引片”（index shard），每个片可以独立更新和查询。
改进抓取策略：
- 更频繁地抓取更新频率高的网站（如新闻网站）。
- 对重要页面和内容优先处理。
支持海量数据：
- Caffeine 的架构允许 Google 索引比以前多得多的网页内容，同时支持更多种类的数据（如图片、视频、实时内容）。

Caffeine 的技术优势

特性	传统索引架构	Google Caffeine
索引更新频率	周期性（数天至数周）	实时更新
处理速度	较慢	高效并行处理
扩展性	有限	动态可扩展
数据类型支持	主要是网页	多种数据类型

速度与效率：每秒可以处理数以千计的网页更新，显著提高了索引更新的频率。
可扩展性：动态扩展索引容量，适应互联网规模的持续增长。
新鲜度：通过实时处理机制，确保用户搜索结果中始终包含最新内容。
数据融合：Caffeine 不仅索引网页，还将图片、视频、社交媒体内容等多种类型数据整合到搜索结果中。

Google Caffeine的影响

对用户的影响

更快的搜索结果：用户可以几乎实时地获得最新的新闻、博客和社交媒体内容。
更全面的搜索覆盖：索引规模的扩大意味着用户能够搜索到更多样化的内容。
搜索体验提升：减少了延迟，搜索结果更加相关。

对网站管理员的影响

频繁抓取：Googlebot 的抓取频率增加，对频繁更新的网站尤为明显。
关注内容更新：网站需要更注重内容质量和频繁更新，以便在搜索中保持竞争力。
页面权重动态变化：页面排名可能会更快地反映内容的更新和链接关系的变化。

对互联网行业的影响

推动实时搜索：其他搜索引擎（如 Bing、Yahoo）也纷纷改进索引技术，以缩短数据处理延迟。
促进内容生产：更快速的内容索引激励了新闻网站和博客作者加速生产优质内容。
提高搜索质量：用户能够获得更加多样化和相关的搜索结果。

Google Caffeine 是一次革命性的搜索引擎升级，标志着搜索技术进入实时化时代。它不仅大幅提升了 Google 的搜索能力，还推动了整个互联网生态系统的快速发展。如果对其架构或技术实现有更深入的兴趣，可以讨论相关的分布式系统和大规模数据处理技术（如 GFS、 Bigtable、 MapReduce 等）。

Google Caffeine后更新

Google Caffeine 的推出是 Google 搜索引擎历史上的重要里程碑，但它并不是终点。Caffeine 后，Google 持续在搜索算法、基础架构和用户体验方面进行升级，以应对互联网快速变化的需求和挑战。

Google 在 Caffeine 后的升级，主要集中在以下几个方向：

更智能的查询理解：RankBrain、BERT、MUM。
用户体验优化：移动优先索引、页面体验更新。
实时性与动态性：实时数据索引和搜索。
安全性与透明性：加强数据隐私和搜索可信度。
生成式 AI 的应用：引入生成式 AI，提供更全面和互动的答案。

每一次升级都反映了 Google 对搜索体验优化的持续追求，同时适应了技术趋势和用户需求的变化。

以下是 Google 在 Caffeine 后的主要升级和改进：

RankBrain（2015 年）

RankBrain 是 Google 搜索引擎引入的机器学习算法，用于更好地理解用户查询背后的意图，特别是长尾查询和模糊表达。

核心功能：
- 将查询转换为向量形式（数值表示），便于理解和匹配用户意图。
- 提升了对自然语言查询的处理能力。
影响：
- 搜索结果变得更加相关和智能。
- RankBrain 成为 Google 排名因素之一，与内容相关性和页面权威性共同决定排名。

BERT（2019 年）

BERT（Bidirectional Encoder Representations from Transformers） 是 Google 推出的基于深度学习的自然语言处理技术，用于理解查询的上下文含义。

核心改进：
- BERT 能双向分析查询中的词语和短语，而不是孤立地理解单个词。
- 尤其对长查询和疑问句效果显著。
应用场景：在多个语言版本的搜索中使用，改善了 70 多种语言的搜索质量。
举例：查询 “2019年在巴西的游客需要签证吗？”
- BERT 可以正确理解“在巴西”是对游客的修饰，而不是对签证的修饰。

移动优先索引（Mobile-First Indexing，2016 年启动，2021 年完成）

随着移动设备使用量的增加，Google 改变了索引策略，从桌面优先转向移动优先。

核心概念：Google 搜索索引以网站的移动版本为基础，而非桌面版本。
影响：
- 网站需要优化其移动页面，以确保排名不受影响。
- 响应式设计和快速加载成为关键因素。

Page Experience Update（页面体验更新，2021 年）

Google 强调用户体验因素，将 Core Web Vitals（核心网页指标）纳入排名算法。

核心指标：
- LCP（Largest Contentful Paint）：页面主要内容的加载速度。
- FID（First Input Delay）：用户与页面首次交互的响应速度。
- CLS（Cumulative Layout Shift）：页面布局稳定性。
其他因素：
- HTTPS 安全性。
- 无侵入性广告。
影响：更注重用户友好的设计，缓慢或交互不佳的网站可能失去排名。

MUM（Multitask Unified Model，2021 年）

MUM 是 Google 搜索的多任务统一模型，旨在更智能地处理复杂查询，并提供综合答案。

核心特点：
- 使用多模态模型，能够同时处理文本、图像甚至视频数据。
- 支持多语言理解，并能将知识迁移到不同语言。
应用场景：复杂查询（例如：计划登山旅行需要哪些准备？），MUM 可以整合多种资源，生成更全面的答案。
改进：支持图文结合的搜索，比如用户上传一张图片并配以问题。

实时搜索与增强数据呈现

Google 持续增强搜索结果的动态性和直观性：

实时搜索：整合新闻、社交媒体动态（如 Twitter）、股市变化等实时数据。
丰富的结果展示：
- 使用知识图谱（Knowledge Graph）提供结构化信息。
- 提供更直观的搜索结果卡片（例如：直接在搜索页面上显示天气、赛事结果、影片简介等）。

神经匹配（Neural Matching，2018 年）

Neural Matching 是一种基于神经网络的算法，专注于更好地匹配用户查询和网页内容之间的相关性。

特点：更偏向于全局语义理解，而非关键词匹配。
应用场景：特别是在用户查询中未使用精确关键词的情况下表现突出。

AI 驱动的改进（2023 年及之后）

Google 不断使用更先进的 AI 模型改进搜索引擎，包括生成式 AI 的引入：

生成式 AI 回答：提供直接的、简短的答案，尤其在用户提出的问题非常具体时。
对话式搜索：搜索引擎逐渐具备类似 ChatGPT 的能力，能够与用户进行多轮对话。

数据隐私与安全性改进

近年来，Google 加强了对用户数据隐私的保护，同时确保搜索结果的可信度：

隐私保护：为用户提供更多控制搜索记录的方式。
搜索透明性：提供“关于此结果”（About This Result）的功能，帮助用户了解来源的可靠性。

Google 罕见的披露了给它带来最多广告收入的搜索查询词

Thu, 02 Nov 2023 19:31:36 CST

不是每一次搜索都能给 Google 带来收入。搜索巨人表示它通常只在五分之一的搜索查询结果中展示广告。此类的查询被称为“商业查询”。在 US v. Google 的反垄断诉讼中，我们有机会了解到了给 Google 带来最多广告收入的搜索查询词名单。该名单发生在 2018 年 9 月 22 日这一周，苹果的 iPhone 8 在这一周开始上市，因此给 Google 带来最多收入的是对苹果新手机的搜索。收入排在前 20 的关键词包括：iphone 8、iphone 8 plus、auto insurance、car insurance、cheap flights、car insurance quotes、direct tv、online colleges、at&t、hulu、iphone、uber、spectrum、comcast、xfinity、insurance quotes、free credit report、cheap car insurance、aarp 以及 lifelock。

如何高效地协作开发：一些 Google 的实践

Thu, 23 Mar 2023 08:00:00 CST

这是我一年前发在 TapTap 内部 Confluence 的一篇文章，经过一些修改后公开出来，希望对更多人有价值。同时也想顺便打下招聘广告（见文末）。

Google 的很多软件工程实践都在对外发布的各种 Tech Talk、CppCon 的演讲以及多本已出版的书里提到过（比如 Software Engineering at Google、Site Reliability Engineering 等），所以这篇文章的内容并不算新鲜事，只是贡献一些个人视角。另外我在 Google 工作已经是 10 多年前的事，现在可能已经变化很大，但我认为 2000~2010 年的时候是 Google 最有创造力、最高效、对人才的吸引力也最强的时候。

一点背景

有时言必谈前公司的人会有点让人讨厌，不过无论是之前创业，还是现在，讨论起工程方面的事情都很难避免提起 Google 是怎么做。Google 和所有公司一样，并不是所有方面都做得很好，比如产品能力以及饱受诟病的客户服务。但就是因为在 engineering 方面领先大部分公司很多，所以削弱了其他方面的弱点带来的影响。Google 取得成功的大部分产品基本都是在技术实现上大幅领先同时代的产品，从而实现用户体验上的领先，早期产品中最有代表性的是 Search、Maps 和 GMail。Google 的 engineering culture 也对包括 Facebook 等在内的大量硅谷公司以及国内包括字节这样的公司产生了深远影响。

我在 Google 的三年是在一个叫 Google Web Server（简称 GWS）的团队。这个项目可以说是 Google 历史最悠久的项目，从 Google 存在开始就有 GWS，到现在 20 多年，Google 的 HTTP header 里 server 还是 GWS，应该还是同一个项目、同一个 code base 和 binary。

GWS in Google's HTTP header

一开始的时候 Google Search 就是 GWS。后来从它里面拆出了一部分放到前面承担类似 SLB 的角色，叫 GFE（Google FrontendEnd）；又把实现单纯搜索的部分拆了出来叫做 Superroot。GWS 更多地成为了一个实现搜索相关的整体业务逻辑的服务，它后面有 15~20 个后端服务，除了 Superroot 外，还有广告、拼写检查、搜索词修正、query rewrite、用户偏好等等。经过多年的演变，GWS 的开发语言也从 Python 变成了 C，再变成 C++，后来又为了方便快速做试验内嵌了 Python 解释器。在整个过程中，GWS 从来没被真正意义上重写过，因为 Google 一直都有大量的业务需求等着实现，不可能有停下来重写或者重构的机会。所有大的改变都必须以渐进的方式来实现，包括换语言。尽管只有 Google 一家公司在用，但是 2010 年的时候 GWS 就支撑了全球 13% 的活跃网站，是排在 Apache、Nginx、IIS 之后的第四大 web server，因为 Google host 的网站很多都是 GWS 来 serve 的，包括自定义域名的 custom search 以及 enterprise search。

几乎所有在搜索结果页用户可见的改动都会需要改 GWS 的代码。这就涉及到了很多其他项目和团队，除了和搜索有紧密关系的广告外，还有地图、新闻、财经，甚至小到汇率转换、计算器。Google 的搜索框不仅是狭义的搜索，其实功能是很多的。这就导致项目非常复杂，改动也非常频繁。GWS 的二进制文件编译出来有 1G 多，在当年已经超过了 gcc 和 gdb 的上限，需要使用内部改过的版本。项目每周发布一个新版，平均有大几百个 changelist。Changelist 是 Perforce 的名词，相当于是 GitHub 的 pull request 或者 GitLab 的 merge request，是一次 code review 的单位，大小通常是多个 commit。

这样一个项目听起来似乎需要一个庞大的团队来维护，而且很容易成为瓶颈。我 2007 年加入的时候，团队有不到 20 人。2010 年我离开的时候有 40 人左右（负责的范围也变大了），分布在 Mountain View、芝加哥、匹兹堡、纽约。除了 GWS 外，这个团队还维护着一些服务端的基础组件，比如我们开发维护的一个项目是 Google 大部分 C++ 服务的基础，提供了标准的健康检查、feature flag、监控变量管理、实验框架等功能。团队成员还有时间发起一些 20% project，比如我和另外两位同事合作开发了一个 serve Google 所有静态文件的新服务，把这部分职责从 GWS 分离出来。听起来这么多的事情由那么小的团队来做是不可能的。秘诀在于 GWS 每周大几百个 changelist 中大部分并不是这个团队里的人写的代码。

GWS team 不负责实现其他产品在搜索里的需求，但是会花大量时间 review 其他产品的工程师提交到 GWS 的改动。由于每周的改动量巨大，很多人会花一半以上的工作时间在 code review 上。GWS team 自己也做开发，但是责任是不同的，日常开发大概有几类

为了提高 GWS 的性能和稳定性，或者为了团队本身的开发效率做的重构和改进
为了让其他团队能更容易地修改 GWS 而开发的模块化功能，比如 OneBox、ManyBox、Universal Search
为搜索和广告的整体业务需求增加的功能，比如试验框架
上一段所说的输出给其他项目的基础组件以及从 GWS 衍生出的新项目

因为这是我的第一份全职工作，其实在 Google 期间并没有觉得有多好，以为大公司都是这样的。但是离开之后才觉得，能有这段各团队之间能顺滑地高效协作的工作经历是很幸运的。这样的工作模式在大部分其他公司很难完全复制，因为它需要一些很强的基础设施做支持。以我们目前的工作模式，很难想象能达到同样的吞吐量，可能也很难复制同样的模式。但是分析一下别人做得好的地方还是能给我们提供一些方向上的参考，做一些努力能提高的空间还是很大的。下面我就介绍一下支撑 Google 团队间高效协作最重要的几个方面。

代码管理和安全

Google 的每个工程师都可以访问全公司 99.9% 的代码，这是决定 Google 的工作方式最根本的条件。剩下只有少数人能访问的那部分叫 HIP (High-value Intellectual Property)，主要是防 SPAM 的逻辑。这部分代码如果泄露了，很快就会被恶意网站利用使得搜索质量显著下降，并且没有可以迅速补救的办法。其他所有项目的所有代码都是对所有工程师开放的。

Google 全公司共用一个代码库，叫做 google3，用 Perforce 做版本管理，但是自己在 Perforce 的命令行客户端 p4 之外包了一个工具叫 g4（为了描述方便，以下 Git 和 Perforce 里 submit、merge 等名词区别就不纠结了，从上下文意思应该清楚）。每次一个工程师在自己本地创建一个 workspace 的时候，g4 会用 OverlayFS 从 NFS 上把最新版本的整个 google3 映射到本地。从工程师的视角，整个 Google 的代码树就是自己电脑上一个只读的大目录。当他 checkout 某个路径进行编辑的时候，g4 会把对应的子目录实际复制到本地，这样在他的视角那个目录就变成可读写的了。所以任何一个工程师都可以编译、测试、修改公司的任何一个项目。

很多人都会问，这样代码不会泄露吗？在那么大的公司可以肯定一定是会泄露的。2010 年前后有很多 Google 中国的人去百度，人民搜索（云壤）、盘古搜索也都是 Google 的人出来做的，要说没有知识产权外泄谁都不信。但是对公司而言，让自己跑得更快远比让竞争对手跑得慢一点更重要。所以大部分情况下保密措施应该是以不伤害效率为前提的。对用户数据的保密除外，但是保护用户数据的措施通常不会影响到大部分人的工作效率。

当时内部邮件列表每个人都可以建，项目管理工具的项目每个人都可以建，工程师可以看任何一个数据中心的任何机器上任何服务的日志，甚至可以动态修改它的 feature flag。理论上这些都可以被滥用或者误用，但是滥用往往缺乏动机，误用可以从设计上避免。一个大原则是风险可控或可逆的事情默认是没有流程的，只有实际发生了问题，证明必要时才会靠引入流程来解决。有了流程就需要有人审批有人执行，如果它解决的问题不常发生、有其他方案或者产生的危害不如流程带来的成本，那么设立流程就是不理性的。

共用一个开放的 repo 目的是让每个工程师都能访问、修改、运行公司的任何项目。要做到这一点，还需要每个项目都使用同样的基本工具。

构建工具

Google 使用的构建工具叫 Blaze，支持 Google 当时允许使用的四种语言：C++、Java、Python、JavaScript（ Closure）。后来 Blaze 开源了，改名叫 Bazel，由社区增加了对更多语言的支持。

无论哪个项目，编译的方式都是在 google3 目录运行 blaze build [path]，而 blaze test [path] 是运行项目里的所有测试。一个工程师如果需要对某个他不熟悉的项目做一些小的修改，需要的知识是很少的，只要做完改动后确保新的代码有测试覆盖，所有老的测试能通过，就可以提交到 code review 的系统了。

每个项目会有一个 Wiki 页面介绍怎么在本地运行和调试，通常来说是描述需要传递什么命令行参数来连接本服务依赖的线上或测试环境的其他服务。对于需要实际运行、进行人工验证的复杂改动，看了 Wiki 以后就能自己在本地跑一个实例，这类改动在 code review 时也通常会要求提供一个本地 demo 的地址。所以任何一个工程师都可以把 Google 的任何一个服务从源代码编译并运行起来。

自动化测试

GWS 作为一个 C++ 的项目，测试覆盖率保持在 90% 以上，这是非常不容易的。用静态语言的项目测试难度比动态语言大很多，因为对象的属性和方法无法动态替换，想要能在测试中 mock 掉 side effects 需要在设计上做更多的努力。自动化测试的好处相关的书上有很多，就不赘述了。我只说两点：第一，对自动化测试的要求确实可以产生更好的设计，比如鼓励面向接口的设计；第二，对于 Google 那样的协作模式来说，自动化测试不是一件锦上添花的事，而是必须。因为无论是去修改其他项目的信心，还是让其他人来修改自己的项目的信心，都来自于很高的测试覆盖率。

确保自己项目的稳定性和质量的方式不是不让别人改，而是把自己关心的东西加到测试里去。比如当时我们有一个用来表示用户请求的类叫 GWSRequest，一个 GWSRequest 对象的生命周期就是整个请求处理的过程，所以这个类自然就成了存这个过程中产生和消费的各种信息的地方。时间一久它的属性就越来越多，还出现了多个属性重复存了同样的信息的情况。后来我们加了一个测试 STATIC_ASSERT_LE(sizeof(GWSRequest), MAX_GWSREQUEST)，试图往 GWSRequest 加新属性的改动在编译时就会失败。如果有人想改 MAX_GWSREQUEST 的值，就需要说明为什么是必须的。有的比较卷的团队为了控制代码的复杂度，还把自己 code base 的行数上限放到了测试里。如果有人增加了 10 行代码，就需要重构其他地方的代码来省出 10 行，或者提供一个好的理由来提高上限。

Code Review

Code review 是每个 Google 的工程师日常工作中很核心的部分。每一个改动都需要经过除作者外至少另一个人的 review 才会 merge。无论是对发明 Python 的 Guido van Rossum 还是发明 C 的 Ken Thompson，都是如此。google3 代码树中每个项目的目录有一个 OWNERS 文件，里面是一些工程师的 ID。当有人提交一个 changelist 后，系统会自动把这个 changelist 分配给涉及到的每个目录的一个 owner 来 review，每个 owner review 通过，并且涉及到的各目录的测试都成功之后才能 merge。Guido van Rossum 加入 Google 后前几年的成果就是开发了内部的 code review 工具 Mondrian，可见这件事对 Google 的重要程度。

做 Review 的人主要关心几件事：

改动的业务逻辑是否正确，具体实现在性能和可读性方面是否合理；
是否符合 Google 的代码规范以及本项目附加的一些条件；
新的代码是否有足够的自动化测试覆盖；
用户可见的改动是否被产品经理批准（会要求提供 Buganizer 的链接，Buganizer 是 Google 自己开发的类似 Jira 的系统）。

除了日常的 code review 外，每个新员工会需要学习公司的代码规范，并通过工作中会用到的每个语言的可读性 review。方式是准备一个百行以上的 changelist，提交给一个有资格做 readability review 的工程师，通过之后才有权限提交用在生产环境的代码。有权做这类 review 的是在一个叫 readability committee 里的资深工程师，他们也负责制定公司的代码规范。比如当时给我做 C++ readability review 的是 Generic Programming and the STL 的作者 Matt Austern。我刚入职时同组的同事告诉我 Guido van Rossum 到 Google 后第一次 Python readability review 没有通过，不知真假。

Code review 除了让项目的 owner 保证代码质量，让其他项目可以快速推进需要的改动外，还起到传播知识的作用。很多时候一些在公司多年的工程师的 reviewer 是入职不久的新人，做 review 的人往往也能从别人的代码里学到很多东西。

版本管理和发布流程

Google 在内部做版本管理的方式就是不做版本管理，所有项目都 live at head。当然，每个项目都有对公司外的版本发布流程，live at head 是对内依赖的策略。一般不会出现一个项目依赖一个组件的 1.1，而另一个项目依赖这个组件的 1.2 这样的情况。每个项目在每次编译的时候，都会把所有依赖从最新的代码编译，使用到的依赖的版本是由编译的时间点决定的。这自然就意味着每一次提交后的代码状态都应该作为稳定版本对待。

一般外部的开源项目，会分不同的版本号，由用户决定什么时候升级，并且由用户做升级所需要的改动。按照 2015 年的数据， Google 有 20 亿行代码，其中的依赖关系错综复杂。而 C++ 对于一个项目用到的两个组件依赖同一个组件的不同版本的场景（菱形依赖）支持是很脆弱的。所以不太可能使用 SemVer 之类的版本方案，除了纯技术上的问题外，每个组件要为内部用户维护多个版本也是成本巨大的。所以 Google 把版本管理完全倒了过来，每个项目/组件都只要维护一个最新版，所有的改动最重要的原则是不能破坏任何测试。所以如果有人在一个共享组件里做了向前不兼容的改动，就会需要在同一个 changelist 里把整个代码库里所有调用到这个接口的地方改过来。有的改动会动到十多个项目，需要十几个 owner 来 review，这并不少见。当然 Google 有强大的代码搜索工具来辅助这样的事。据几年后 Google 工程师在 CppCon 上的分享，他们还用 MapReduce 做了大规模重构工具，不过是在我离开之后了。

没有内部版本管理就意味着要保证每个版本的稳定。Code review 的工具会保证每次 merge 前都运行了所有涉及的测试，但是有时还是会发生代码 merge 之后导致测试失败的情况。比如可能有 race condition，也就是两个人几乎同时 merge 了会相互影响的代码；也可能失败的测试和改动的文件不在一个目录，导致 merge 前没有运行。GWS team 有个工程师轮值的角色叫警长（sheriff），一旦 GWS 的任何测试变红，本周的警长就会找出来是谁干的，并把对应的改动撤销。后来有人做了工具把这个流程半自动化了，一旦有测试失败，就会自动生成一个 changelist 把对应改动撤销并发 code review 给警长，他只要确认、跑测试、点 merge 就行。再后来有的团队把这个过程完全自动化了，不用人工干预。

GWS 每周会做一次 binary push，也就是二进制文件的发布。流程是每周一早上负责发布的工程师从当前的代码做一个发布分支编译出一个二进制文件，交给 QA 开始测试，发现 bug 就把修复 cherry pick 到发布分支。由于大部分逻辑错误都会在开发过程中的自动化测试发现，QA 阶段发现的大部分是通过截图比对工具找到的某条线移了一个像素之类的问题。QA 流程通过后，就从单数据中心单台机器开始灰度，逐步发布到全球。如果到周四下班还没完成发布，本周的发布就会被放弃，下周再重复同样的流程。发生发布失败的情况很少，如果发生会作为事故来开会复盘。

除了 binary push 外，还有 data push，也就是数据发布。数据包括 GWS 的配置文件、各种黑名单白名单、模版文件等。Data push 比较轻量，每天有多次，都是采用灰度发布到全球的方式。

以上这样 live at head 的方式意味着不太可能有长期存在的功能分支。如果一个工程师在独立功能分支上开发了几周，那基本上是不太可能合并回主线的。无论是多大的新功能，都会需要拆成很多小的 changelist，高频地提交到主线。只是未完成的功能会用一个 flag 屏蔽掉，在生产环境不会运行。所有用户可感知的改动都是用与试验一致的方式发布，从单个数据中心千分之一的流量开始灰度到全量。如果发现问题，只要做 data push 把 flag 的值改回来就行，因为老的 code path 已经在线上运行了很久，所以改回来一定没问题。这让发布很安全，大家也有信心做大胆的尝试。

关于项目管理和排期

排期这个词在 Google 其实很少出现，离开 Google 之后都在小创业公司就更不会出现。如果大部分事情都需要项管排期，一件很小的事情也可能被排到一两个月后，而这件小事可能 block 了很多其他工作。把一个工程师的时间按开发任务线性地排列，完全做完一件事再开始做另一件事，也并不是高效的方式。工程师确实是需要专注的、避免多任务切换的时间，但这样的时间应该是以小时计，而不是以天或周计的。一个工程师应该把任务分割成尽可能小的单元，写完代码和测试后及时提交给别人 review，并且也需要 review 其他人的 merge request。从天和周的维度看，本来就是需要在多件事情之间切换的。

在 Google 的三年多里，我们团队的 project manager 对于工程师来说存在感一直毕竟低，项管不会过多干预个人的工作计划。每个工程师都相当于自己的项管，工程师之间会互相就优先级进行沟通达成共识和妥协。这样的好处是工作量小但 block 了其他人的事情会被快速完成；实际做事情的人用专业的语言沟通，不需第三者传话，也不容易造成误解；一些重要但不紧急的事情，比如重构、还技术债，也可以由工程师在日常工作中穿插地推进。我无法想象在 Google 当时的团队能按集中排期来安排工作。过去十多年里，硅谷比较成功的互联网公司都是用与 Google 相似的方式来工作的，这不是偶然现象。网状的沟通协作与传统的树状比，表面可能感觉混乱，但是因为不容易形成瓶颈、沟通中信息损耗少，效率是很高的。

我们能先从哪些事做起

Google 的人喜欢说 Google 的工程实践是为连续运行十年以上的软件设计的。10 年不是很长时间，已经基本站稳脚跟的公司需要探索在开发协作上更 scalable 的方式。我们不太可能去复制 Google 的所有东西，Google 的方式也未必放在所有公司都是适用的，但是有一些方向性的结论在整个业界是得到了共识的，我们也应该朝那个方向去努力。以下是我们可以在公司推动改进的一些方向。

在工程师团队里培养测试文化

在这个年代写完代码就交给 QA 去测试，靠人工来保证质量，是很落后的方式，因为它不能 scale。人工的测试做十次就是十倍的成本，哪怕每次内容都一样。自动化测试是所有人都知道好，很少人实际做，更少人能做好的事。Google 也不是从一开始就把测试做得很好，而是由一小群人努力地在全公司推动起来。最可见的一件事是 Testing on the Toilet，内部简称 TotT。他们在全球办公室的几百个马桶前都装上了这样的海报，这样大家在上厕所的同时还能学习如何写测试。久而久之，重视的人越来越多，开始在 code review 中执行测试覆盖率的要求，大部分的项目都逐步建立起高质量的测试。

让自己的项目更容易被别人改动

要改代码首先要看得到。我一直认为代码应该默认是对内公开的，虽然可能会增加泄露风险，但和效率的提高比是微不足道的。如果市值几千亿美元的公司都能对每个工程师开放代码，对大部分公司而言部门之间还互相捂得很严就太小气了。Git 本身不是为 Monorepo 设计的（虽然最近有一些支持，以及微软有全球最大的 Git repo），可能短期我们也难以大范围转为 monorepo，但是 GitLab 把 repo 组织成树状的设计一定程度上是为了在权限管理上模拟 monorepo 按目录管理的方式，是很容易做到默认 owner 可读写，其他人可读，让任何人都可以通过 merge request 改任何代码的。

让别人更容易改动还包括提供内部文档，让别人知道如何修改、运行、调试（别人包括团队新人、其他团队、未来的自己）；提高可读性和模块化，让别人容易理解；提高测试覆盖率，让别人不容易改坏。

尽量提交代码而不是需求

现在经常会遇到有一件事需要涉及多个项目的改动，把需求提到其他项目，发现要排到很久以后了。解决优先级上的冲突，让对自己重要的任务早点完成的最好办法就是把一件事的开发收缩到同一个团队，不管要改的代码在哪里，都尽可能由同一个团队完成开发，由 owner review。从经济上来说，由需求方投入资源也是更合理的方式。这样的工作方式偏爱能力全面的团队和工程师，在 Google 一个人经常性地提交 2~3 种语言的代码是很常见的。

当然，也不是所有的事情都能收敛到同一个团队进行。有的任务是需要对多个项目进行根本性的改动的，就会需要来自多个团队的工程师形成一个临时的小团队了。

建立代码规范

很多公司通常是从很小的时候就会建立公司范围的代码规范，因为有了一致的规范，才好使用同样的工具，阅读和修改其他团队的代码时才能比较容易。如果在规模较大时再从零开始做这件事会非常困难。可行的路径可能是自下而上的，各个团队先建立自己的规范，协作得多的团队可以取长补短，从能建立共识的部分形成共同的规范，逐步扩大适用的范围。

打一个招聘广告

TapTap 开发者服务（TDS）在招聘后端工程师、Android 工程师和技术支持工程师，详情请见我们的技术负责人在 V2EX 发的帖子。

大公司的企业病，Google员工说出了我不敢说的心里话！

Tue, 21 Mar 2023 08:47:58 CST

“Google 有17万员工，这些员工能力强，待遇优厚，但是一年又一年，他们干的活儿越来越少。”

Google员工就像老鼠一样，被困在一个迷宫里，这个迷宫是流程审批、法律审查、绩效审查、文件、会议、OKR、重组.......

老鼠被定期地投喂奶酪：晋升，奖金，美味的食物，更高的津贴。

很多人希望从工作中获得个人成就感和影响力，但是迷宫系统会训练他们忘掉这些欲望，而要学习如何“Google化”：别找麻烦，别捣乱。”

这段对大公司企业病的比喻非常精彩，我在我的公司也有这种困在迷宫中的感觉，但是没有如此清晰地表达出来，也不敢这么表达出来。

Google在我心目中一直是科技界的标杆企业，创新能力强，文化也很棒，可以说是光鲜亮丽，没想到内部也出现了大企业病的症状。

这篇文章的作者Praveen Seshadri不是土生土长的Google员工，他是AppSheet（一个低代码平台）的创始人，2020年被Google收购后加入，三年强制保留期结束后离职。

作为一个外来者，尤其是创业者，他对Google的观察非常深入，提出了Google出现的4个核心问题：

1、缺乏使命

2、没有紧迫感

3、例外主义的错觉

4、管理不善

这些问题都是由一个叫做“广告”的印钞机带来的结果，不断增长的广告收入掩盖了所有的问题。

Praveen对Google的吐槽集中在这几个领域：

一、忘记了为客户服务

Praveen在创业时，特别注意一点：为客户服务。

但是Google忘记了它服务的对象，他们通常服务于一些流程（“我负责审查隐私设计”）或一些技术（“我让CI/CD系统保持工作”），甚至服务于一些通用的Google技术或者“宗教信仰” （“我是代码可读性专家”，“我维护 SWE 阶梯描述文档””）。

每个人只为其他Google员工服务，而忘记了真正应该服务的对象：客户。

每个人得到的反馈都是来自于同事和经理，这就造成了一个封闭的世界，在这样的世界中，努力工作不仅没法创造新价值，还可能有相反的效果。

二、不尊重客户，而是尊重风险

虽然Google的两个核心价值观是“尊重用户”和“尊重机会”，但在实践中，系统和流程的设计目的是“尊重风险”。降低风险胜过一切。

1、你修改的每一行代码都是有风险的，因此请投入大量流程以确保每次代码更改都完美地避免了风险（不要介意它是否对用户有没有吸引力）。

2、你发布的任何东西都是有风险的，所以要进行大量的审查和审批，哪怕是一个小产品的小变化。

3、任何改变过去做事方式的行为都是危险的，所以要坚持过去的方式

4、和领导的任何分歧都是风险，所以对上层总是说：Yes

三、总是以为自己与众不同

在谷歌内部，有一种集体错觉，认为这家公司是与众不同的。

实际上，这家公司的成功是早期的大牛们所创造的，现在环境已经变化，可大家依然以为之前的做事方式非常完美，即使是大多数人悄悄抱怨整体效率低下也没关系。例如:

1、 Google拥有一个独特的、从内部发展起来的技术栈，称为“Google3”。

公司所有的大规模消费产品都建立在这个技术栈上。

这给大家造成一个错觉：谷歌拥有世界上最好的技术堆栈。

十年前这可能是真的，但今天肯定不是这样。外边很多公司没有使用这样的技术栈，也构建了大规模的、可扩展的服务。

公司要保持开放的心态，跟上世界的步伐，不应该禁止世界上其他有用的，可以提升工作效率的的技术，例如React，或者像Twilio，Intercom，Mixpanel这样的SaaS服务，它们能帮助公司更快地进行创新

2、Google的内部流程无疑是过时的。

Google已经陷入瀑布式规划流程中长达二十年。如果一个团队中的高级经理每年做六次计划（每次花一个月），休假一个月，然后用一个月进行绩效评估，那么剩下的时间足够进行一年一年的战略变更和组织重组，对吗？

什么都没完成，没有问题，也没有风险，发放奖金，然后继续前进。

3、Google价值观说要“尊重客户”，但实际上做不到。

除非客户付一大笔钱，否则只能得到一个非常“弱”的一线支持工程师，有多弱呢？对产品的了解甚至不如客户。

每个人都愿意花费上百小时来准备一个向管理层的汇报演示，但是不愿意花费10分钟帮助客户解决问题。

最后，作者呼吁Google做出变革：

高层要好好学学微软CEO Satya Nadella 在微软做的事情，致力于改变世界，为真正的客户提供价值，而不仅仅是关注技术（如AI）或者赚钱（如Google云收入）。

高管要真正地追求使命感，而不是鹦鹉学舌的口号，如果他们要“尊重客户”，副总裁和主管们要取消每周的一个小时会议，利用这些时间去直接面对客户。

中层要质疑过去25年积累起来的传统的东西，拥抱敏捷或者精益开发，将员工视为有特殊才能的人，而不是可替换的乐高积木，鼓励团队向客户做出承诺，并且信守承诺，构建客户想要，而不是VP想要的东西。

对所有员工，都要看看是否可以在团队、产品和客户层面做出积极改变。

说实话，我看到这些挺吃惊的，没想到Google内部也出了这么多的问题，联想到前一阶段无情的裁员（码农翻身注：参见文章《Google裁掉了最优秀的员工》），Google确实处于一个脆弱的时刻，尤其是在AI+微软的压力下。

大公司出了问题，想要走出困境挺难的，IBM在上世纪90年代初陷入亏损，郭士纳力挽狂澜（现在又不行了），本世纪10年代微软出现危机，纳德拉现身拯救，但不得不说都有运气成分，Google现在虽然财务良好，但内部的问题这么发展下去，一定会出事儿，到时候谁来拯救呢？

作者丨Beyond

一个NASA、Google都在用的开源CMS：wagtail

Fri, 03 Mar 2023 01:22:14 CST

说起开源CMS，你会想到哪些呢？WordPress？DoraCMS？joomla？

今天再给大家推荐一个非常好用的开源CMS： wagtail

图片

如果您正在选型的话，可以了解一下Wagtail的特点：

基于Django构建，具有出色的文档管理功能和友好的用户界面。
提供了一个灵活且易于使用的页面编辑器，支持多种类型的内容块，包括文本、图像、视频和HTML代码。
具有出色的SEO功能，包括友好的URL和元标记管理。
支持多语言网站，并提供了一个易于使用的翻译界面。
完全开源的CMS，拥有强大的社区支持和活跃的开发人员社区。
内容审核和版本控制：wagtail支持审核和审批工作流程，以确保您的内容在发布之前经过审核和批准。
网站搜索：wagtail提供了一个易于使用的搜索框架，支持全文搜索和过滤器。
云存储支持：wagtail支持多种云存储服务，包括Amazon S3和Google Cloud Storage，以帮助您管理和存储大量的媒体文件。
定制化：wagtail提供了一个灵活的插件系统，使您可以轻松地添加自定义功能和扩展。

wagtail的忠实用户中还有NASA、OXFAM、NHS、Google等知名公司

图片

目前wagtail在GitHub上拥有14.3k的Star，可见其用户与生态是非常庞大的。

总之，wagtail的功能非常强大且灵活，适用于各种不同类型的网站，包括博客、新闻网站、企业门户等。如果您是一位开发人员或具有一定的技术知识，那么wagtail绝对是一个值得考虑的选择。

官方网站： https://wagtail.org/
开源地址： https://github.com/wagtail/wagtail

欢迎扫描下方二维码，关注公众号：TJ君，订阅每日推荐，获取更多好用效率工具！

ChatGPT 式搜索对 Google 微软而言意味着成本增加 10 倍

Thu, 23 Feb 2023 23:50:17 CST

今天的搜索引擎首先需要构建一个庞大 Web 索引，用户搜索时对索引条目进行扫描、排序和分类，最相关条目出现在搜索结果中。整个搜索过程通常不需要一秒钟。相比之下，AI 聊天机器人 ChatGPT 搜索时需要启动一个庞大的神经网络模型，产生文本，可能还需要利用搜索引擎核查事实信息。整个过程要漫长得多，花费也更多。分析师估计，大语言模型的搜索成本可能是关键词搜索的 10 倍以上，意味着数十亿美元的额外成本。如果 Google 提供了 ChatGPT 式搜索它的成本每年将增加 60 亿美元。

Google 演示从文本描述生成音乐的 AI

Sat, 28 Jan 2023 17:46:34 CST

Google 演示了从文本描述生成音乐的 AI 系统，但因潜在风险，搜索巨人没有发布该 AI 的计划。Google 的 AI 系统称为 MusicLM，类似的 AI 音乐系统有 Riffusion、Dance Diffusion，以及 Google 自己的 AudioML 和 OpenAI 的 Jukebox。由于技术限制和训练用的数据集有限，此前没有一个 AI 系统能创作出复杂或高保真的歌曲。MusicLM 可能是第一个能做到的。Google 研究人员使用了 28 万小时的音乐数据集进行训练，学习从复杂的文本描述中生成连贯的歌曲。它创作的歌曲听起来像是人类音乐家可能创造出来的。研究人员也注意到了 MusicLM 系统面临的伦理挑战问题：倾向于将训练数据集中的版权音乐整合到生成的音乐中。

Google 称互联网的六成是重复内容

Sat, 26 Nov 2022 11:19:09 CST

在新加坡举行的 Google Search Central Live 活动上，Google Webmaster 趋势分析师 Gary Illyes 称，互联网上六成的内容是重复的。他没有对重复进行定义，是 100% 相同的重复，还是改个标题但实际内容一致的重复比如社交网络中的转载，或者进行搜索引擎优化之后的重复。互联网上有大量重复内容是众所周知的事实，问题是比例有多大，作为最大最流行的搜索引擎，Google 给出了它的答案。

程序员要进入Google、Amazon这样的顶级IT公司，需要达到什么样的技术水平？

Mon, 15 Aug 2022 00:00:00 CST

现在北美求职市场飘忽不定。能不能进入这些公司或毕业就上车，在一定程度上更取决于你的就业时间，而不是你的能力。我当年在USC见过很多水人赶上Amazon扩招直接两轮OA拿Offer的，也有很厉害的大神赶上市场缩招半年没有一个面试，被ICC拒了的。2020年疫情北美缩招，我在国内阿里的一个同学所在的组新招的应届生都是UCLA, UT-Austin，CMU 正统MSCS毕业，在北美没找到工作的。

北美互联网就业远比你想象的更具有不确定性，难度也远比你想象的大的多。身为过来人，我给你们的诚恳并且稳妥一点的建议是。 1.先拿到国内一线互联网公司的Offer在国内攒两三年工作经验。2. 一定要练英语口语，至少达到能不看字幕听懂老友记的水准。3. 申请一个北美两年制的硕士，尽量能在两年内发一篇CCF B类以上的论文，这能证明你在相关的领域达到一定的见解。4. 刷题刷题再刷题，尽量刷到800道以上，并且真正理解。

如果你能达到以上四点，即便遇到就业低峰期，你也是有可能在北美的就业市场分到一杯羹的。否则按照当前的形式，你留学两年的钱很有可能打了水漂。

最后劝各位不要听一些求职公司或者所谓润学人的胡言乱语，这群人的目标根本不是为了帮你就业，而是掏干你口袋里的钱让你报名他们的求职班等等。北美这些一线公司现在的门槛远比他们描述的高的多的多。

Google 准备将 Android 游戏带到 Windows 平台

Sat, 11 Dec 2021 13:00:40 CST

微软正与亚马逊等公司合作让包括游戏在内的 Android 应用能运行在 Windows 11 平台。现在，Google 准备了应对措施，将 Android 游戏带到所有 Windows 平台，不限于 Windows 11。Google 将在 2022 年发布 Google Play Games app，允许 Google Play 上的游戏应用能运行在 Windows 笔记本、平板和 PC 上。Google 自己开发了该应用，没有与微软等公司合作，将允许在不同平台上持续游戏，比如在手机上玩了之后可以在 PC 上恢复继续游戏。Google 没有透露它在 Windows 上模拟 Android 应用所采用的技术。

最快 3 分钟送到，Google 的无人机居然送出了 100000 单快递？

Mon, 30 Aug 2021 09:58:32 CST

等待总是让人焦虑。无论是在淘宝购物还是下单外卖，我总会守着物流追踪信息，订单的每一次动态变化，都是一剂能人暂时平静的镇定剂。

一旦订单正在派送，这种焦虑的心情就会到达顶峰，手机不能离开超过身边三尺，不能错过每一条电话和短信，这时我恨不得送货小哥能够马上飞到我身边。

「飞到身边」，真的可能吗？

就在这几天，Google 母公司 Alphabet 表示他们的「快递小哥」已经成功飞了 100000 次了。

首个达成「十万」成就的无人机快递

小型无人机自诞生以来就被人们赋予了很多的想象，航拍、特技表演、远程勘测……人们想用这台这个四轴飞行器挖掘更多航空价值，其中「送货」应该是大家对于无人机的最终幻想。

相信看过哈利波特的朋友都有过这样的憧憬：某一天醒来，一只雪白的猫头鹰站在你的窗边，用爪子敲打着你的玻璃，嘴上还叼着一封蜡封的牛皮信，通知你已经被一所职业技术学校录取了。

也许你穷极一生都不会等到海德薇的到来，但不要灰心，这种自巡航、点对点的派送服务不需要借助魔法也能实现，只是降落在你屋顶的不是猫头鹰，而是无人机。

无人机送货并不是什么新概念，早在 2013 年，电商巨头亚马逊就提出了 Prime Air 的无人机送货计划。

远有亚马逊、Google、UPS，近有京东、顺丰、美团等，你会发现能叫得上名的科技、物流公司都有发布过相应的无人机送货解决方案。

▲ 亚马逊概念视频

然而，这么多年过去了，我们的天空依然保持宁静，已经站在未来的我们没能等来会飞的汽车，也没等来会飞的快递员，红极一时的无人机送货概念就只像是昙花一现。

就当大家快要遗忘这个美丽的幻想时，Alphabet 宣布旗下的无人机派送公司 Wing 要突破 100000 笔订单的里程碑，人们这才发现，在世界的另一个角落有着一片不一样的天空。

Wing 主要在美国、澳大利亚和芬兰三个国家运营无人机送货服务，其中在澳大利亚的洛根市（Logan）取得了最大的成功——总计 100000 笔订单中，有超过 50000 笔是在洛根市交付。

洛根市并不是什么著名大城市，它的城市面积为 958 平方公里，人口约为 30 万，是个典型的澳大利亚郊区城市。

不过平静的郊区上空并不平静，自 2019 年 Wing 在这里放飞了第一架无人机之后，洛根市的上空每天都会有无人机穿梭上百次，其中大部分时候都是在解决市民的「口腹之需」。

根据 Wing 的统计，去年 Wing 的无人机一共在洛根市运送了 1 万杯咖啡、1700 包零食和 1200 只烤鸡。

这些订单平均运送时间在 10 分钟左右，最快的一笔订单为 2 分 47 秒，比开车去麦当劳的得来速取餐还快。

这不难解释 Wing 在洛根市的流行：在地广人稀的郊区城市里，利用无人机送货几乎是最方便和快捷的购物方式，你要做的只是在家里悠闲地下单和等待。

当然 Wing 并不是什么都能运送，当用户需要采购东西时，他需要先下载 Wing 的官方 app，再在上面挑选商品。

在 app 上仅提供了一些像咖啡、零食、寿司、蛋糕、宠物食品和运动服装等轻量货品，由于 Wing 的运力只有约 2.7Kg，你不能指望它给你运来一台冰箱。

为什么这么多无人机送货概念方案中，唯独 Wing 能真正落地呢？这要从 Wing 的运作模式说起。

无人机送货的核心：安全、安全还是安全

▲ 时速可达 110 Km/h

Wing 的无人机长得很有特点，它像是滑翔机和直升飞机的杂交体——机身左右不仅分别有 6 个悬停旋翼，还设计了机翼和 2 个巡航旋翼，让无人机既可以垂直升降和悬停，又能在横向飞行时平稳巡航。

为了尽可能降低无人机意外坠落对人的伤害，Wing 的机身用了泡沫材料包裹，并且重量很轻。

Wing 表示整机的设计工作是由包括弗吉尼亚理工大学等机构一起合作完成的，在设计过程中着重测试了飞机的安全性。

飞行过程中，Wing 一般会控制在距离地面 30-40 米的低空区域飞行，并且会遵守城市空域管理，基本不会对载人飞机造成影响。

而确保降落的安全性会是无人机送货的最大的难点之一，通常来说无人机需要利用传感器找到一个空旷、安全的地方平稳降落，但地面的情况太过于复杂，想要安全降落是一个工程难题。

▲ 现场没有一只猫咪受伤害

因为无人机派送的区域通常都是住宅区，即便降落点选得再空旷，谁也不敢保证在降落过程中不会有好奇的宝宝或者小狗冲出来摸一下高速旋转的机翼。

Wing 找到了一个很巧妙的解决方法——用绳索代替机身升降。

他们在机身的下方设计了一个收缩绳索的装置，在飞行过程中绳索会尽可能缩紧保证货物不会丢失，到达派送地时，无人机会下降到距离地面 7 米的低空悬停，再放下绳索投放货物。

当货物接触到地面时，它就会从特殊的钩子分离，这时无人机再收紧绳索，准备升空归程。

整个收货过程用户都不会接触到无人机，只要在一旁静静看绳索升降，两者保持了足够安全的距离，不仅避免了飞机升降可能存在的安全隐患，派送的效率也更高。

解决了派送的问题，Wing 还需要解决另一个棘手难题：怎样安全、自动地将货物运送到用户指定地点？

我们都知道两点之间直线最短，因此空中货运能够采用比陆运效率更高的直线路线运输。

然而与常识相悖的是，大多数情况下无人机派送都不会简单粗暴地采用直线飞行，因为缺乏路线规划的空中交通非常可怕，这就像是有人在空中开碰碰车，指不定哪天两架飞机就会撞在一起，后果不堪设想。

也就是说，光有「车」还不够，人们还需要在空中规划出「路」以及相应的交通秩序，无人机才能安全地在天上飞行。

背靠 Google 地图的 Wing 在这方面有着天然的优势，很快建立起了 Unmanned Traffic Management（UTM，无人驾驶交通管理）系统，对空中的飞行器进行统一地协调管理。

Wing 无人机每次起飞前都会在 UTM 系统的支持下，综合考虑天气、障碍、空域管制等因素自动规划一条安全的取货、送货路线，再出发前往取货地点。

订单完成之后，Wing 无人机会自动回程，降落在充电板上充电，这个过程中其他订单则由另外的无人机执行，调度的方式像极了一个小型机场。

我们离无人机快递还有多远？

Wing 的发言人乔纳森·巴斯在接受 The Verge 采访时提到，Wing 想把它在洛根市的成功模式复制到其他人口密度和洛根差不多的城市，例如新奥尔良、曼切斯特、佛罗伦萨等。

有趣的是，像纽约、东京等人口稠密的大城市并不在 Wing 的考虑范围之内。

乔纳森·巴斯解释称，寸土寸金的大城市对无人机送货并不友好，因为无人机很难找到一个没有树枝、电线杆和招牌的空旷位置投放货物。

无人机快递本质上是解决「快递最后一公里」的一种方法，它落地成功与否不仅受技术、政策的影响，还跟城市的物流体系息息相关。

相比起楼宇空旷的小城市，无人机确实很难在大城市的水泥森林里穿梭和歇脚，这对无人机派送的安全性和容错率有了更严苛的要求。

无人物流公司确实可以在城市里设立一些集中点来集中投放商品，但一番操作下来，用无人派送的成本并不比城市快递末端的人力成本便宜多少，甚至还要更贵。

无人机更像是属于大自然的鸟，在高楼林立的大城市里很难找到「栖息地」。

弗吉尼亚理工大学发布的一篇报告中提到，当一个城市的无人机投递系统投入使用五年后，每个消费者平均每年可以节约 56 小时的购物时间，零售业参与者可以平均每年增多 208000 美元的销售额，而城市平均每年可以减少 113900 吨二氧化碳。

省时、增收、环保，这些正面效益吸引到了很多物流公司参与到这次科技升级的浪潮之中，但是在运行过程中遇到的技术和法规问题又像一记闷棍，将视无人机技术为物流唯一未来的公司们打醒。

例如 Wired 就曾报道过亚马逊的 Prime Air 团队在今年年初大幅裁员，与五年前第一次试飞成功时相比，Prime Air 近几年来声势甚微，很大一部分原因是亚马逊的工程师还未能解决无人机的空中管理和安全投递的问题，导致过长的项目周期并没有带来合乎预期回报。

目前来看，无人机送货还存在各种各样的局限性，缺乏低空管理法规的城市还没准备好迎接它，具备落地条件的郊区又很难养活它。

无人机送货就和自动驾驶一样，站在了被全行业瞻望的科技顶点，但登顶的阶梯现在才刚开始搭。100000 笔订单的里程碑，也许只是登上这条阶梯的一小步。

黄智健

高一点，再高一点。

邮箱

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

如何写好技术文档——来自Google十多年的文档经验

Tue, 27 Jul 2021 12:33:58 CST

本文大部分内容翻译总结自《Software Engineering at Google》第10章节 _Documentation_。另外，该书电子版近日已经可以免费下载了 https://abseil.io/resources/swe_at_google.2.pdf，有兴趣的同学可以下载翻阅下。首先声明， 本问所说的文档不仅限于纯文本文档，还包含代码注释(注释也是一种特殊形式的文档)。

很多技术人自己非常轻视技术文档的书写，然而又时常抱怨文档不完善、质量差、更新不及时…… 这种在程序猿间普遍存在的矛盾甚至已经演变成了一个段子。

文档的重要性

高质量的文档对于一个组织或团队来说有非常多的益处，比如让代码和API更容易理解、错误更少；让团队成员更专注于目标；也可以让一些手工操作更容易；另外如果有新成员加入的话有文档也会让他们更快融入……

写文档有比较严重的 收益滞后性，不像测试，你跑一个测试case，它能立即告诉你是对还是错，它的价值马上就体现出来了。而写一份文档，随着时间的推移，它的价值才会逐渐体现出来。你可能只写一次文档，将来它会被阅读上百次、上千次，因为一份好的文档可以在未来替你向别人回答类似下面这些问题。

为什么当时是这么决策的？
为什么代码是这样实现的？
这个项目里都有哪些概念？
……

写文档同样对于写作者也有非常大的收益：

帮你构思规范化API： 写文档的过程也是你审视你API的过程，写文档时会让你思考你API设计是否合理，考虑是否周全。如果你没法用语言将API描述出来，那么说明你当前的API设计是不合理的。
文档也是代码的另一种展现： 比如你两年后回过头来看你写过的代码，如果有注释和文档，你可以很快速理解代码。
让你的代码看起来更专业： 我们都有个感觉，只要文档齐全的API都是设计良好的API，虽然这个感觉并不完全正确，但这两者确实是强相关的，所以在很多人眼里，文档的完善度也成为衡量一个产品专业度的指标。
避免被重复的问题打扰： 有些问题你只需要写在文档里，这样有人来问你的时候你就可以让他直接去看文档了，而不是又给他解释一遍。

为什么大多数人都不喜欢写文档？

关于文档的重要性，每个技术人或多或少都知道一些，但很多人还是没有写文档的习惯，为什么？除了上文中提到的文档的 收益滞后性外，还有以下几点原因：
很多工程师习惯将写代码和写作割裂开，不仅仅是在工作上，而且在思想上就认为它们是完全不相关的两项工作，这就导致好多人重代码不重文档。
也有很多工程师认为自己不善写作，索性就不写了。这实际是个偷懒的借口，写文档不需要华丽的辞藻、生动的语言，你只需要将问题讲清楚即可。
有时候工具不好用也会影响的文档写作。如果没有一个很好的写作工具将写文档嵌入到开发工作流程中的话，写作确实会增加工作的负担。
大多数人将写文档看做是工作的额外负担。 我代码都没时间写，哪有时间写文档！，这其实是错误的观念， 文档虽然前期有投入，但能让你代码的后期维护成本大幅降低，磨刀不误砍柴工这个道理相信大家都还是能理解的。

如何产出高质量文档

既然理解了好文档的重要性，我们如何保证在时间的长河中维护好一份文档，这里有些相关的方法论，大家可以参考下。

像管理代码一样管理文档

对于如何写出好代码，整个技术圈已经有好多经验的总结了，比如书籍《重构》《代码简洁之道》…… 针对各种编程语言，也有相关的规范，比如国外的Google C++规范，国内的 阿里Java开发规范等…… 但对于文档似乎相关的资料却很少。但实际上，不应该把文档和代码割裂开来，你可以简单粗暴地认为 文档其实就是用一种特殊语言书写的代码，这种语言就是人类的语言。这么想的话，实际上我们很多在代码和工程中总结出来的经验，也可以直接用在文档中，比如：

有统一的规范
有版本控制
有明确的责任人维护
有变更Review机制
有问题的反馈和更新机制
定期更新
有衡量的指标(比如准确性，时效性)

明确你的读者是谁

写文档有一个很常见的错误，那就是很多人文档都是写给自己看的，这种情况下就会导致你的文档只有自己或者和你有相似知识背景的人才能看懂，团队较小时这种问题还好，你们都做着类似的工作，所以也都能看懂文档。但当团队逐渐壮大后，问题就会凸显出来，新人有时候有着和你不同的工作背景，甚至现在都做着不同的工作内容，这时候你之前写的文档他们就很难读懂了。

所以在写文档之前请明确你文档可能的读者会是哪些人，然后针对他们的特点着重关注如何才能让他们理解。当然，文档也不一定要非常严肃和完美，只要能向你潜在的读者说明问题即可。记住 文档是写给别人看的，不是给自己看的。

根据专业水平可以大致将读者分为三种新手、老手和专家，针对不同水平的人写作需要有侧重点。比如针对新手，你需要重点介绍下里面涉及到的术语和概念，然后详细讲解具体的的实现。相反，针对专家你可以省去这些额外的信息。注意，这里没有严格的标准，因为有些文章新手会看，专家也会看，这里还是需要具体情况具体分析。

另外一种对读者分类的方式就是根据读者阅读文档的目的来分类，比如有人知道自己遇到了什么问题，就是来找解决方案的。还有一批人只有一个简单的想法，但不知道具体的问题。举个例子，以读数据库慢为例，前者已经知道数据库慢可能是因为数据量巨大且没有加索引，解决方案很简单加索引，这时候他可能需要知道的是如何正确地加索引。而后者可能着重关注的是为什么读数据库会慢，这时候你可能需要额外重点介绍下数据库相关的原理。

清晰的分类

文档大致可以分为以下几种类型，每种类型也有自己不同的特点和写作侧重点。

参考文档

参考文档也是大部分开发人员日常会使用和书写的文档，比如我们使用某个框架或者工具，都会有API说明文档，这就属于参考类文档。它并没有太多的要求，只要能向读者展示清楚如何使用即可，但无需向读者讲明具体的实现。

注：参考文档并不仅限于API文档，还包括文件注释、类注释、方法注释，要求都是能准确说明其用法。

设计文档

很多公司或者团队在项目开始前都要求有设计文档，设计是项目实施的第一步，所以在设计文档书写的过程中要求尽可能考虑周全，例如该项目的存储、交互、隐私……

好的设计文档应该包含以下几个部分：

设计目标
实现的策略
各种利弊权衡和具体决策
替代方案
各种方案的优缺点

写设计文档的过程也你对整个项目做规划、思考可能出现问题的过程，设计的越详细、思考的越多，未来遇到问题的可能性就会越小。

引导类文档

引导类文档也很常见，一般都是 Step by Step的形式。比如我们在使用某个框架或者工具的时候，一般都会有个引导类的文档一步一步帮助你快速上手。大家 写引导类文章大家非常容易犯的一个错误就是预设了很多背景知识。一般使用文档都是有开发者写的，他们都非常了解这个工具的相关的知识，所以习惯性的会认为， 啊这个知识点很简单用户也肯定会吧，实际上用户不一定会。这 本质上就是一种认知偏差，这种现象在跨团队协作尤其是多端协作的时候也非常明显。

这类型的文档写作中， 要求写作者尽可能站在用户的视角上思考，极力避免出现和用户的认知偏差，力争每个步骤做到明确无歧义，每两个步骤之间做到紧密衔接。

概念性文档

当参考文档无法解释清楚某些东西的时候，就需要概念性文档了，比如某个API的具体实现原理。其主要是为了扩充参考文档，而不是替代参考文档。有时候这和参考文档会有些内容重复，但主要还是为了更深层次的说明某些问题、解释清楚某个概念。

概念性文档也是所有文档中写作最难的，也是被阅读最少的，所以很多情况下工程师最容易忽视。而且还有另外一个问题，没合适的地方放，参考文档可以写代码里，落地页可以写项目主页里，概念性文档似乎也只能在项目文档里找个不起眼的角落存放了。

这类文档的受众会比较广，专家和新手都会去看。另外，它需要强调概念清晰明了，因此可能会牺牲完整性(可以由参考文档补齐)，也有可能会牺牲准确性，这不是说一定要牺牲准确性，只是应当分清主次，不重要的就没必要说了。

Landing pages(落地页)

Landing pages就先简单翻译成落地页了，没想到啥恰当的翻译词。比如一个团队或者项目的导航页，虽然没啥具体的内容，但应该包含其他页面的链接。比如你新入职一个团队，比较成熟的团队都会扔给你一个文档，这个文档里包含常用的工具、文档链接，这就是这个团队的落地页。
落地页的问题就是随着时间的推移，页面可能会变的越来越乱，而且有些内容会失效，不过这些问题都好解决，做好定期的维护和整理就行。
落地页的技术难度不高，但要求内容的有效性、完整性和分类清晰。

文档Review

在一个组织内，光靠个人去维护文档是不行的，必须得借助群体的智慧。在一个组织内部，文档的变更也应该像代码的变更一样，需要被其他人Review，以提前发现其中的问题并提升文档的质量。

如何Review文档：

专业的视角来保证准确性： 一般由团队里比较资深的人负责，他们关注的核心点是文档写的对不对，专不专业。如果Code Review做的好的话，文档的Review也属于Code Review的一部分。
读者视角保证简洁性： 一般由不熟悉这个领域的人来Review，比如团队的新人，或者文档的使用者。这部分主要是关注文档是否容易被看懂。
写作者视角保证一致性： 由写作经验丰富或者相关领域比较资深的人承担，主要是为了保证文档前后是否一致，比如对同一个专业术语的使用和理解是否有歧义。

写文档的哲学

上面部分站在组织和团队的视角来看如何提高文档质量，我们接下来看看站在个人写作者的视角上如何写出高质量的文档。

5W法则

5W法则相信大家已经听的多了，分别是Who What When Where Why，这是一个广泛被用在各行各业的法则，写文档当然也能用（5W法则堪称万金油，啥地方都能用）。

WHO： 前面已经说过了，文档是写给谁看的，读者是谁。
WHAT： 明确这篇文档的用途，有时候，仅仅说明文档的用途和目的就能帮你搭建起整个文档的框架。
WHEN： 明确文档的创建、Review和更新日期。因为文档也有时效性，明确相关日期可以避免阅读者踩坑。
WHERE： 文档应该放在哪！建议一个组织或者团队有统一的永久文档存放地址，并且有版本控制。最好是方便查找、使用和分享。
WHY： 为什么要写这篇文档，你期望读者读完后从文档中获得什么！

三段式写作

写文章一般都会有三个部分，专业写作者也讲究 凤头、猪肚、豹尾，这三个词概括出了好文章三部分应有的特点。技术文档也算是文章的一种，所以一般也都会有这三部分，每个部分有其自己的作用，比如 第一部分阐述问题，中间部分介绍具体的解决方案，第三部分总结要点。 但这也并不以为着文档应该有三个部分，如果文档内容比较多，可以将其做更细致的拆解，可以适当增加一些冗余的信息帮助读者理解文档内容。虽然很多工程师都讨厌冗余极力追求简洁，但写文档和写代码不同，适当的冗余反而可以帮助读者理解，很简单，举个例子，比如写作中经常举例子，举的例子本质上就是冗余信息，生动的例子肯定是能帮助读者理解抽象内容的（我想这就是自举
吧）。

结语

目前看到比较好的一个现象就是大家越来越重视文档了，但和测试相比重视的程度还不够。测试已经是工作流程中不可或缺的一部分了，而文档依旧还不是。当然这可能和文档本身的特性相关，测试很容易被自动化，也有非常多的客观指标来评估。文档却做不到，首先文档的书写需要人手动介入，而文档的质量也没有太多客观的指标评估，提升文档的数量和质量只能从文化和工作流程上去逐渐改变。

最后总结下本文几个关键点：

随着时间的推移和组织规模的壮大，文档会越来越重要。
文档也应该是开发流程的一部分。
一篇文档只专注在一件事上。
文档是写给读者看的，而不是给你自己看的。

Google用AAB取代Android APK 讓Windows 11的Android支援生變？亞馬遜表示會搞定

Sun, 18 Jul 2021 18:55:00 CST

Android就表示未來Google Play將全面改用AAB格式來，這也讓很多微軟的用戶感到有疑慮，那麼Windows 11怎麼辦？

微軟先前在 Windows 11 發表會上表示，未來Windows 11 將能執行 Android 應用程式，讓很多用戶都感到興奮。不過，就在他們宣布之後沒幾天，Android就表示未來Google Play將全面改用AAB格式來，這也讓很多微軟的用戶感到有疑慮，那麼Windows 11怎麼辦？

在Windows 11上的 Android 應用程式，主要是從 Microsoft Store 提供，但實際下載過程將通過亞馬遜應用商店（Amazon Appstore）進行。

微軟正在將亞馬遜應用商店串接到微軟應用程式商店中。使用者可以在Windows 11裡面直接尋找 Android 應用程式，打開微軟應用程式商店中的亞馬遜應用程式商店，然後點擊幾下就可以安裝應用。

6 月下旬，Google確認將要求應用開發者使用新的 Android App Bundle (AAB) 標準，而不是 Android Application Package (APK)。據Google表示，此政策適用於 Play 商店中的新應用程式，開發者將被要求未來的新應用程式要放棄當前的 APK 格式。

預計這種安裝格式將減少APK的可用性，App Bundles格式本身有一些優勢，包括較小的分發模組。這種做法的一個缺點是，新格式是針對特定裝置進行微調的，這意味著提取應用程式並使其可在其他地方分發將更加困難。目前，APK文件將在符合架構要求的大多數裝置上都可以直接執行和安裝。

這一變化將影響Windows 11上的應用程式的可用性，因為安裝將變得更加複雜。雖然從技術上講，Android APK 應用程式不會停止使用，因為 Android 將繼續直支援現有格式，但在Google開始對 Play 商店實施 AAB 格式後，開發人員可能會停止以 APK 格式發佈應用程式。

不過，這對 Windows 11 來說應該並不是問題。亞馬遜已經確認，他們的應用程式商店將會支援 Android App Bundle (AAB)。亞馬遜表示「亞馬遜應用程式商店正在積極針對新的格式進行支援。」

與Google Play不同，App Bundles在Amazon App Store中算是一種可選的格式而非強制性的，開發者可以繼續為他們的應用程式上傳APK文件，或者在新格式得到支援後使用。

Google Play和Amazon Appstore要求的另一個區別是，Google要求開發者提交他們的應用程式簽名密鑰，而Amazon則不需要。

想要解決AAB格式的問題時，無疑Google Play具有優勢，但微軟看來是談不到與Google的合作，也只能透過亞馬遜的App Store在Windows上提供Android應用程式，至少可以幫助微軟拉近應用程式之間的距離。

亞馬遜應用程式商店中的大多數應用程式，在獲得開發者許可後，未來都可以在 Windows 11 上下載執行。

加入T客邦Facebook粉絲團

SteveY对Amazon和Google平台的吐槽 | 酷壳 - CoolShell

Tue, 16 Feb 2021 14:00:18 CST

Steve Yegge， Amazon的前员工，现任Google员工，其本来想在Google+上和Google的员工讨论一些关于平台的东西，结果不小心把圈子设成了Public，结果这篇文章就公开给了全世界，引起了剧烈的反应。发布后很快他就马上把这篇文章删了，不过，互联网上早备份了下来—— SteveY’s Google Platforms Rant。后来，Steve在其Google+上作了一些解释，大体是说他喝多了，而且又是在凌晨，所以大脑不清，文章中的观点很主观，极端且不完整，还有Google的PR对他很好，等等，等等。

几个星期前看到时就一直都想翻译一下这篇文章，不过因为最近事情太多，文章又很长，所以现在才翻译完成，翻译的不好，还请大家指正。

导读

在你阅读正文以前，我想说明几点，希望你注意一下：

Steve这个人非常喜欢写长篇大论的东西。而且比较喜欢辛辣调侃和恶搞的文风，这点大家要注意！

文中先“骂”Amazon公司，再通过“骂”Amazon的创始人贝索斯Bezos并烘托出他的的悟性和雄心，最后教育了一下Google。

我把文章分成了三个部分，这样方便大家阅读和讨论。第一部分只是个人情绪化的抱怨，第二部分是说Amazon的成长，第三部分是教育Google，我觉得第二部和第三部分是重点。

对于我们来说，我们应该获取Steve那些关于平台（Platform）相关的那些有价值的观点。尤其是他说的Amazon如何进化成一个平台性的公司，以及阐述Google应该怎么做的那些观点。

关于对Amazon的那些指责，我想说，6年，对于一个世界级的互联网公司，已经很不一样了。

正文

第一部分

我曾在Amazon工作了六年半，现在，我在Google的日子也差没不多这么长了。对于这两家公司，有一件事总是萦绕着我——这种感觉一天比一天强烈──那就是，Amazon每件事都做错了，而Google每件事都做对了。当然啦，这是很笼统的话，但却是惊人的准确，相当的疯狂吧。大概有一百甚至两百种不同的地方可以让我们去比较这两个公司，而Google可能在每一项都能胜出，如果我记的没错，除了其中3项以外。因为，我曾用电子表格把这些项都列出来了，只是法务部门不会让我给任何人看，即使人事招募部门很喜欢这个报表。

这里，让我先给你个例子让你稍微体会一下：Amazon的人事雇用流程有根本上的缺陷，因为各个团队各招各的人，以至于，各团队之间的招聘标准相当的不一致性，即使他们通过各种努力来统一标准，但是实际操作上却是一团糟；他们没有真正的SRE（陈皓注：Site Reliability Engineer ），工程师们什么事都要做（陈皓注：所谓SDE – Someone Do Everything）、几乎没时间编码。当然，不同的部门有不同的情形，不过，这取决于你的运气。他们不搞慈善，也不帮扶贫困人群，也不搞社区贡献，或是其它相似的活动。在那里，他们从来不谈这些，或许只有在说笑话的时候才会提到。他们的办公环境是个灰尘及污迹四处的像农场一样的隔间，他们在公共区域连一分钱装修的都不会花，而且，他们的薪水和福利相当差，只是近来与Google和Facebook竞争人才，这个差距才变得非常地小。不过，他们没有我们有的津贴或额外奖金——他们只是给你录用信上的那个数字，就这么多。他们的程序代码完全就是灾难，无论什么都没有任何的工程标准，除了各别团队有一些。

公平起见，他们的确有套非常非常不错的版本控制管理系统，而这是我们（Google）需要尽力赶上他们的地方，他们还有一个漂亮的发布/订阅系统，我们也没有相对应的东西。不过，就大体而言，他们有的不过是一堆蹩脚的工具，用关系数据库来读取或写入状态机里的信息中罢了。我们不应该这么搞就算这样做是可以。

这就是我所所说的那3件事中的两件事Amazon比Google强的，那就是的他们的发布/订阅系统以及版本控制和管理系统。

我猜你也许会为他们争辩到——他们要更快更早地推出服务并通过狂热地迭代来不断地改进和完善。他们把服务发布的优先级看得比任何事都重，包括工程纪律或是其它一堆可能会让其花时间的事务。所以，即使这么做让他们在市场上有了某种程度的竞争优势，但也造成其他足够多的问题，总之，这样的做法算不上是个漂亮的扣篮。

但是，他们有一件事做的非常非常好，其好到可以把其他政治，理念，技术上的消耗和混乱完全弥补回来。

第二部分

Jeff Bezos是个臭名昭彰的微管理经理人，他的微管理都管理到了Amazon零售网站上的每一个显示像素。他雇佣了Larry Tesler——Apple的首席科学家，他可能是全世界最有名也最受尊敬的人机交互接口专家，然而，Bezos忽略了Larry三年来提出的每一个建议，直到Larry最后——明智地——终于离开了公司。Larry本应做一些大型可用性（Usability）研究，并可以系统地了解那个根本就没有人能够搞懂、使用那该死的网站，可是，Bezos对于那些像素不放手，这些页面上的那几百万个显示像素就像是他的孩子一样。所以，他的这些孩子还留着，而Larry没有。

当然，微管理不是第3项Amazon做的比我们好的事。我的意思是，没错，他们微控管理做地非常地好，但我不会把这项列在他们的强项清单上。我这样说只不过是为了我下文做铺垫，帮助你了解我后面要说的事儿。我们现在要说的这个人，是在多个严肃的公开场合说要来Amazon工作就应该付他钱才对的人。当有人跟他意见不同时，他会递出写有他名字的黄色即时贴以提醒那个人“谁是公司的老大”。这家伙是……，Steve Jobs，我想，除了没有品味和设计能力，他们很相似。千万别误解我，Bezos是个绝顶聪明的人，只不过他把那些正常的管控搞得像嗑了药的嬉皮士一样罢了。

所以，有一天，Jeff Bezos下了一份命令。当然，他总是这么干，这些命令对人们的影响来说就像用橡皮槌敲击蚂蚁一样。这个命令大概是2002年，我想误差应该是在正负1年内 —— 这个命令发布的范围非常地广，设想很大，让人眼珠子鼓出来的那种，这种惊讶程度和其他的命令相比，就好像你突然收到公司给你的奖金一样让人惊讶。

这份大命令大概有如下几个要点：（陈皓注：这里是本篇文章的要点！如果这真是Bezos发出来的，那么太赞了，Bezos完全就是一个系统架构大师啊，那可是2002年左右啊。作者调侃Bezos完全是正话反说啊）

1) 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。（陈皓注：Service Interface也就是Web Service）

2) 团队间的程序模块的信息通信，都要通过这些接口。

3) 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。

4) 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，Bezos不管这些。（陈皓注：Bezos不是微控经理吗？呵呵。）

5) 所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。

6) 不这样的做的人会被炒鱿鱼。

7) 谢谢，祝你有个愉快的一天！

哈哈！你们这150个前Amazon的员工，当然能马上看出第7点是我开玩笑加上的，因为Bezos绝不会关心你的每一天。

不过第6点是很真实的，于是，所以人们都去工作。Bezos并派出了几位首席牛头犬来监督并确保进度，领头的是和熊一样大的牛头犬：Rick Dalzell，Rick是以前是陆军突击队队员，西点军校毕业生，拳击手，和沃尔玛的首席虐刑官 / CIO，而且他也是个高大、和蔼、令人敬畏的人，还是经常使用”hardened interface”词的人，Rick 本来的走路和说话都比较hardened interface，所以不用多说，每个人都得干出有 重大的进展，这样Rick才能看得见。

在接下来的几年，Amazon内部转变成面向服务架构SOA(Service-Oriented Architecture)，在这华丽转身的过程中，他们学到了相当巨多巨多的东西。我在的那个时候，世界上就有很多很多的关于SOA的学术文档，但在Amazon的那种超大规模的面前，世间的这些文档就好像告诉印第安纳琼斯（陈皓注：电影夺宝奇兵男主角）过马路前要先看看两边有没有来车一样没用，Amazon的研发工程师们在这个过程中发现了很多很多的问题，并从中学到了很多。下面只是他们这些问题中的沧海一粟：

pager escalation（陈皓注：生产线上问题的寻呼系统）变得比较困难，因为ticket可能会转过来转过去（陈皓注：ticket就是处理问题的工单），只到转了20次，都找到真正能解决问题的团队和人。如果每一个呼叫都花去团队的15分钟的响应时间，那在找到真正的团队之前，几小时就已经过去了，除非，你能建造出很多很多的脚手架，测量标准和报告。

每一个和你的相关团队突然间都可能成为一个潜在性的DOS攻击者。没人可以让事情有进展，直到在每一个Service里放上配额（quota）与节流阀（throttling）的机制。

监控与QA是被统一了。如果你不进行一个大规模的SOA，你就不会这么去想。但是，等到你的Service说，“是的，我还好！”，但实际情况可能是，服务器里唯一能正常运作的功能就是一个快乐的机器声音在呼叫你：“我很好，收到，收到”。为了要确认整个服务能正常运作，你需要对Service的每一个部分都去Call一下。这个问题会以递归的形式地出现，直到你的监控系统能够全面性地系统地检查所有的Services和数据，此时，监控系统就跟自动化测试QA没什么两样了，所以两者完美的统一了。

如果你有上百个Services，而且你的程序只能通过由这些Services来跟其他团队的程序做沟通，那么，没有一套Service发现机制的话，你就不能找到这些Service。所以，你得先有一套Service的注册机制，这也是一个Service。所以，Amazon有一套全体适用的Service注册机制，以例可以通过反射机制来找到Service，并知道Service的API，以及是否可用，在哪儿。

调试其他人的代码以调查问题变得非常的难，几乎都不可能，除非有一套全面性的标准的方式，他可以在可被调试的沙盒里运行所有的Services。

上面这些只是极少数几个例子，在Amazon在进化的过程中，Amazon遇到这样的问题可能一打甚至数百个，Amazon都一一学习和总结了。对于把Service外部化甚至还有很多几乎没有人会想到的非常生僻的东西，当然，也不会有你想像的那么多，Amazon都学到了。把业务组织成Service让团队学会了不能相信对方，就如同他们不能信任公司以外的程序员一样。

当我在2005年中期离开Amazon加入Google时，这个努力进化的过程还在进行时中，但那时已经相当的先进了。从Bezos颁布法令的时间到我离开的时候，Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子Bezos工作。不过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA驱动出来的设计会产生出平台（Platform）。

是的，这就是Bezos的法令要达成的目标。他以前（现在也是）一点不关心各团队是否好，也不关心他们使用什么样的技术，实际也不去管他们如何运作他们的业务，除非团队开始把事搞砸。但是，Bezos比绝大多数的亚马逊人都很早很早就领悟到，Amazon必须成为一个平台。

如果是你，你会想到要把一个在线卖书的网站设计成为一个有扩展性，可程序化的平台？你真的会这样想吗？

嗯，第一件Bezos领悟到的大事是，为了销售书籍和各种商品需要的基础架构，这个基础架构可以被转变成为绝佳计算平台（Computing Platform）。所以，现在他们有了Amazon Elastic Compute Cloud（亚马逊弹性运算云平台EC2），Amazon Elastic MapReduce，Amazon Relational Database Service（亚马逊关系数据库服务），以及其他可到AWS aws.amazon.com查得到的一堆Service。这些服务是某些相当成功的公司的后台架构，比如我个人喜欢的 reddit 是这一堆成功公司的其中一个。

另一大领悟是，他知道他们不可能永远都创造出对的东西。我认为，当Larry Tesler说他妈妈完全搞不懂怎么使用那个该死的网站时，Bezos的某根筋被触动了，当然，我也不清楚到底是谁家母亲，这无关紧要，因为没有人的母亲能够会用那个该死的网站。事实上，连我这个在那工作超过5年的人都觉得Amazon网站的接口令人胆战惊心。

我并不是很确定Bezos是如何领悟到的——领悟到他不能创造出一个产品能适用于所有的人。不过，怎么来的这不重要，重要的是他的确领悟了。这种事有一个正式的术语，叫Accessibility，这是计算机世界中最最重要的事情了。

最！重！要！的！事！

如果你在心里面在想“哼？你是说，像盲人和聋人那种Accessibility吗？”，那么，你不是唯一这样想的人，因为我已经知道有 很多很多像你这样的人：这种东西对你们这种人来说是不可能有正确的Accessibility，所以这事你还不能理解。当然，不能理解也不是你的错，就像眼盲，耳聋，或是其他行动不便的残疾人，这些也不是他们的错。当Software——或ideal-ware——如果因为某些原因不能被存取或使用，那么，这就是软件或是那想法的错了。这就是Accessibility failure。

就如同生命中那些重大的事一样，每个事都有一个邪恶的双胞胎姊妹，它在幼年都受到父母的溺爱，现在它已经成长为同等强大的复仇女神（是的，Accessibility有不只一个复仇女神），这个复仇女神叫安全性（Security），他们在一起总是争执不休，冤家一对。

不过，我会和你争论Accessibility要比安全性来的重要多了，因为零Accessibility就意为着你根本没有做出产品来，而如果安全性为零，你仍然还是可以有一个某个程度上成功的产品，譬如说Playstation Network。

对了，也许你还没注意到，我其实可以为这篇文章写出一整本书，很厚的一本，其中填满了那家我曾工作过的公司里关于蚂蚁与橡皮槌的事。但是，我可能也就永远无法在这发表这短篇的夸夸其谈了，而你也就无法读到除非我现在开始结尾。

第三部分

那三件Amazon比Google强的中的最后一件事是，Google很不会做平台（Platform）。我们就不懂什么是平台。我们就根本不知道平台的内涵。你们其中一些人明白，但是你们是少数派。在Google过去这六年来，越清楚这一点就越让我痛苦。我曾有一线希望，来自Microsoft和Amazon，以及近来Facebook的竞争压力，会让我们全体人都清醒过来，并开始打造我们公司的Service。不是那种特制的或半生不熟的，而是多少和Amazon的类似的那种：一次到位，真正的，没有作弊或是欺骗，并且把它放在最高优先级的位置。

但实际上却不是，这个事被放在了好像是第10还是第11位，或是第15位，我不知道，反正是相当低。只有少数几个团队严肃地看待这个事，但大多数的团队不是 从没有思考过这个事，就是只有一很少的人很鼠目寸光地在看待这个事。

对大多数的团队来说，只要是让他们以提供给别人那种可程序化的方式存取他们的数据与运算的方式来开发软件，就算几个小小的粗糙的Service，对他们来说也是翻天覆地。他们大部分人都认为他们在做产品，但他们只是在提供那些凄惨粗糙的Service。回去看看前面我所列的那些部分的Amazon学到的东西，然后告诉我，哪一个粗糙的Service能让你有超凡脱俗的产品。迄今为止，就我所知，一个也没有。就算是这些粗糙的东西很不错，不过这就好像要汽车的时候，你却只有汽车的零件。

没有平台的产品是没用的，再精确一点，去平台化的产品总是被平台化的产品所取代。

Google+是我们完全失败的不懂Platform最明显的例子，从最高层的管理层（嗨，Larry、Sergey、Eric、Vic，你们好）一直到最最底层的员工（嘿，你）都不懂。我们全部统统都不懂。平台Platform的黄金守则是Eat Your Own Dogfood（吃你自己的狗食——自己都要用自己的平台）。Google+这个平台是个杯具的事后抄袭者。我们在发布它的时候完全没有任何API。我查了一下，目前也只有少得可怜的API。Google+的一个团队的成员在发布API时告诉我这个事，我问：“这是Stalker API（用来偷窥内部数据的API）吗？”，她郁闷地说，“是啊”。我的意思是，我那只是个玩笑话，但是，不，我们提供的唯一的API就是取得某人的信息流，所以，我想我把玩笑开到自己头上了。

Microsoft知道“狗食守则”至少有20年了。这已经成为他们世世代代文化的一部分了。不能是你吃人类的食物而给你的开发人员们喂狗食。那样做只会是为了短期的成功而掠夺了平台长期价值。平台就是要你考虑得长远。

Google+就像膝跳反射，一种短视的的东西，是基于以为Facebook其伟大产品的成功作出的错误判断。但那不是为什么他们能成功的东西。Facebook的成功是因为他们建立了一个可以让外界在其上上面开发的产品群。所以对Facebook对每个人来都不一样。有些人把全部时间花在“Mafia Wars”上，有些人则是花在“Farmville”（开心农场）。那里还有成百上千个不同的高质量的时间消耗类的游戏，所以，人们总是可以在那里找到他们想要的。

我们的Google+团队看了看说：“哎呀，看来我们需要一些游戏，让我们去找一些人来为我们写些游戏吧”。你是否开始看到这样的的思考有多么不靠谱了吗？问题在于我们试图在预测人们想要什么，然后推出产品给他们。

你不能这么做。真的不能。也不可靠。在这个世上，甚至在整个计算机的历史上，只有极少数几个人能够这么干，Steve Jobs是其中一个。但是我们没有Steve Jobs。对不起，我们真的没有。

Larry Tesler有可能说服了Bezos相信他并不是Steve Jobs，但Bezos意识到他不需要成为Steve Jobs也能提供给所有人好的产品：大家感到容易使用的接口与工作流。Bezos明白他只要有让第三方开发人员来做的平台，这些东西自然就会有的。

我要向一些人道歉，这些人会觉得我所说的是再明显不过的了。是的，的确是巨明显的。只是我们没有去做。我们没有领会平台，我们也无法领会到Accessibility。这两者本来就是同一件事，因为平台会解决Accessibility。而平台就是Accessibility。

是的，Microsoft领会到了。而且你们也像我一样知道Microsoft他们对这些东西一知半解。那是因为他们能够了解平台完全是他们商业上意外性的副产品，是他们一开始的业务就是提供平台。所以他们在这个领域有着三十多年的经验。如果你去看看 msdn.com，并多花点时间浏览一下，假设你以前从没去看过，你等着被吓到吧，因为那里面的东西可是多得不能再多。他们拥有 成千成千成千个API。他们拥有一个 超巨大的平台。说实话，太巨大了，因为他们要霸占一切，但至少他们做了。

Amazon也领会了到了。Amazon的AWS( aws.amazon.com)相当的惊人。去看看吧，四处点一下。令人羞耻吧。我们今天什么都还没有。

很明显Apple也领会到了。他们做了在基础上不开放的选择，具体来说是移动平台。但是他们明白什么是Accessibility，并且他们知道如何燃起第三方开发团体的力量，而且他们吃自己的狗食。你知道吗？他们的狗食做得很好吃啊。他们的APIs比Microsoft的要干净不知道多少倍，而且是远古的时候就这样了。

Facebook也领会到了。这正是让我所担心的。这使得我不得我抬起懒惰屁股写下这些东西。我恨写Blog。我恨……Plus（指Google Plus）不管怎么称呼它，反正在Google+上发表长篇大论，就算这是个糟糕的地方，但是你还是希望Google能成功.我真希望！我的意思是，Facebook想挖我，而且很容易就去了。但Google是我的家，所以我坚持我这个小小的家庭干涉，就算你不舒服。

等到你为Microsoft与Amazon提供的平台感到神奇后，当然，我想也你可能会被Facebook吓到（我不敢去看，因为我不想让我太沮丧），让我们回头看看 developers.google.com 。是不是有很大的差别？我们的这个平台看起来像是你家小学五年级的侄子搞出来的东西一样——让一个小学五年级的学生，试着为一个强大的的平台公司去设计平台，就像像我们问这个小学生：“如果这家公司什么资源都有，那你会做出个什么东西来？” 一样。

这里请不要误解我——我知道一个事实，dev-rel 团队为了发布这些API曾经不得不去“搏斗”。据我所知，这个团队很不错，因为他们知道什么是平台，并且他们如英雄般努力挣扎地要做出来，然而遇到的却是“平台冷漠”的环境，难听点还是那种有敌意的环境。

我只是在直白地描述出一下 developers.google.com 在外人眼里是什么样子。它看起来很幼稚。Maps APIs在哪呢，老天啊？其中有些东西还是实验性的项目，我点进去看的APIs……他们都毫无价值。他们很明显都是些真正的狗食。甚至都称不上是好的有机食品。跟我们内部APIs比起来，他们全部简直就是猪屎马粪。

当然，也不要错误地理解我对Google+的看法。他们还不算是最差的。这是文化氛围的事。我们现在做的简单来说就是要进行一场战争，是一场失败很多的少数的平台派和那些强大的信心坚持的产品派的战争。

那些从头到尾明白理解供外部可程序化的平台概念的团队都是受压迫的人——Maps跟Docs团队浮现在我脑海中，而且我也知道GMail是这个方向的先头部队，但是他们很难得到资金注入，因为这不是我们文化的一部分。Maestro的资金完全没法和Microsoft Office开发平台的资金相比：就像小白兔和暴龙相比一样。Docs团队知道自己永远无法和Office竞争，除非他们能赶上Office的脚本能力，而且他们得不到他们相要的资源。我的意思是我假定他们没有，现在应用的脚本能力只在电子表格中有，而且没有为API设置键盘快捷键。在我看来，这个团队完全没有被重视。

具有讽刺意的是，Wave是个伟大的平台，愿他能安静地长眠。我们需要知道，做一个平台并不会马上给带来成功。平台需要杀手级应用。Facebook——他们供应了的涂鸦墙和朋友关系网等其他东西——则是Facebook平台的杀手级应用。但是，如果你说没有Facebook平台，仅有Facebook应用也能像今天这样成功，那么，这会是一个非常严重的错误。

你知道吗？人们总是在说Google的傲慢自大。我是个Google人，所以我和你一样当听到那些话都会觉得很愤怒。但总体而言，我们并不傲慢。我们大约99%不自大。我在文章开头时就写到——如果你回去看看—— 我是这样描述Google的“所有的事都做对了”。我们知道人们为什么要这么说我们自大，因为我们没有雇用他们，或是因为他们对我们的政策不爽，或是那一类的事情。他们推断出我们自大是因为这样会让他们心理平衡一些。（陈皓注：作者在这里的反话正说）

但是，当我们摆出那种我们知道怎么给用户设计出完美的产品的姿态时，你最好相信我，我们就是笨蛋。你可以说是自大，天真，或是别的什么，无所谓，但最终的结果就是我们干的很愚蠢。因为，这世界不可能有一个产品对所有人都是完美的。

你看，我们的浏览器居然不能让人设定默认的字号。这就是我们对Accessibility的公然冒犯。我的意思是，我总有一天会老的，我也会得老花眼，并会变瞎的。我的意思是我不会变瞎，但是如果你到了40岁，你的老花眼让你看不清近的东西。那么，字号的选择会成为生和死的问题：某用户就会被完全排除在产品之外。但是Chrome团队就是这么NB傲慢：他们想要开发出无需配置的产品，他们对此相当自豪，去你TMD是瞎子还聋子，管你是谁，在你剩下的日子每访问一个页面都按一下Ctrl-+吧。

并不仅是他们是第一个。问题是，我们是一家“产品”公司，一直一直都是。我们开发的最成功最有吸引力的产品——搜索引擎，那样巨大的成功让我们产生了很多定式和偏见。

Amazon过去也是家产品公司，一道神秘的力量使得Bezos领悟到他们需要平台。那道神秘力量来源于，他们被逐渐蒸发的市值逼到墙角了，不得不想方设法突围出来。但他当时所拥有的只有一群工程师和他们的一堆计算机……除非他们能变成印钞机……你可以看到他们是怎么搞出来AWS的，而不是像我们Google+一样事后诸葛亮。

Microsoft从一开始就是个平台，所以他们有很多很多的实践。

Facebook：我有些没看透。我不是专家，不过我很肯定他们一开始也是一个产品，并且成功了很长时间。所以我不知道他们什么时候开始转变成为平台的。应该是很久以前的事了，因为他们要成为平台后，Mafia Wars这玩意才会出现（而Mafia Wars也很老了）。也许，Facebook只是看一眼我们，就问到：“我们如何击败Google？他们少了什么？”

我们面对的问题非常的庞大，因为我们需要经过剧烈的文化转变后，我们才能迎头赶上。我们没有内部的SOA平台，所以我们外部也没有。这就是说，我们整个公司都“没有领会到”：产品经理没有，工程师没有，产品团队没有，没人领会到。就算是个别人有，比如你你有，那也相当于没有，除非我们在生死存亡的时候。我们不能这样不断推出产品，并装作我们以后会把这些产品转变成迷人美丽的可扩展式的平台。我们试过了，不行。

平台的黄金守则，“Eat Your Own Dogfood 吃自己的狗食”，换句话说，“先打造出自己使用平台，然后把它用在所有的地方”。你不能事后再做，那样做就太困难了——你去问问那些把MS Office平台化、把Amazon平台化的人。如果你放在后面做，那么你比一开始要花十倍的精力才能做对。你不能作弊，你不能让内部软件走秘密通道以取得特定的优先权限，不为什么，你必需从一开始就要解决这个问题。

我不是说现在做已经太迟了，但我们等的越长，我们就会越接近——“太迟了”。

老实说，我不知道这篇文章怎么收尾。我今天在这里说得太多了。因为这篇文章花了我6年时间。请包涵我言语冒犯之处，包涵我可能误解了一些产品，团队，或某个人。也许我们真的在开始做了很多平台方面的东西，只是我没看到。我只想说声对不起。

但是，我们现在开始必需把事做对了！

（全文完）

苹果、亚马逊和Google联手开发开源智能家居标准

Thu, 19 Dec 2019 20:56:31 CST

PingWest品玩12月19日讯，据 CNBC报道，亚马逊、苹果、Google和Zigbee Alliance正在联手开发一种开源智能家居标准，旨在改善其智能家居设备的兼容性，简化新设备的开发并确保开发、使用安全。这四家企业准备成立名为“家庭互联IP专项小组”（Project Connected Home over IP）的组织，未来宜家、三星SmartThings和Signify等公司也将加入。

该项目希望，用户无论购买的是哪家的智能家居设备，都能够配合已有的智能手机或语音助手，从而获得无障碍的体验。

根据IDC 9月份的数据，“全球智能家居设备市场预计将在2019年同比增长23.5％，达到近8.15亿台设备出货量。” 预计到2023年，这一数字将增长到13.9亿台。要实现这一目标，并且为了使消费者保持理智，消费者将需要某种标准，使所有事物彼此对话。

Google做了6个超好玩的应用但目的却是让你放下手机

Sun, 27 Oct 2019 22:06:00 CST

随着越来越多的人“沉迷”手机，厂商也开始关注这方面的健康问题。苹果在 iOS 12 中推出了“屏幕使用时间”，用户可以查看并管理自己使用应用的频率。Google 也在 Android P 中新增了“数字健康”功能，还规定搭载 Android P、Android 10 的新设备出厂自带。

最近，Google 发起了一个新的“ 数字健康实验”项目，用 6 个有趣好玩的应用来帮你远离手机。这些创意看起来有些天马行空，但更大的意义是启发开发者，呼吁更多人来关注数字健康。

他们到底想出了哪些“鬼点子”？下面就一起来看一下吧。

Unlock Clock 解锁计数器

第一个是动态壁纸，下载后可以在壁纸设置中找到，或者配合 Google 的 Wallpapers 应用来使用。它的作用是在你每次打开手机时进行计数，就像翻页时钟一样。比起每周看统计数据时后悔跺脚，不如将事实直接展示在你面前。

Post Box 通知收纳盒

第二个应用叫 Post Box，它会把你手机上的通知统一收纳起来，只在固定时间查看。一天最多可以看 4 次，设定好时间，就再也不用担心各种弹窗广告影响你的注意力。Post Box 的设计做得也很美观，各个应用会以色块的方式排列，点进去只有最基本的文字信息，高效、省时。

We Flip 都别玩手机

第三个应用很有意思，它适用于聚餐还有会议场景。在这种情况下，大家默认是不应该玩手机的，活动开始时可以将所有人的状态调整为开启，期间只要有一个人没有经受住诱惑，切换到了其它界面，本次活动就自动结束，该扣工资、还是让他结账...... 大家就可以自行定夺了。（需要科学上网）

Paper Phone 纸片手机

第四个应用也很独特，前面的几个应用都是让你尽量减少手机的使用，而 Paper Phone 则是让你彻底扔掉手机。当然，生活中有很多地方是离不开手机的，Paper Phone 的作用就是把你今天要用到的内容，在纸上打印出来。它支持导出联系人、地图、备忘、日程等信息，将这张纸折成方块的形状，它就是你今天所需要的“手机”。

Desert Island 沙漠孤岛

第五个应用是一个启动器，它的理念有点类似之前的 Light Phone，只在手机上保留必要的功能。不过在 Desert Island 的选择要更多一些，你最多可以将 7 个应用常驻在桌面，其他应用需要点击右上角才能打开。使用一天之后，你会获得一份统计数据，查看最经常使用的应用是哪些，然后在第二天调整常驻列表。

Morph 场景启动器

手机最影响效率的一点，就是人们总是控制不住自己的手，上班时打游戏摸鱼、开车时回微信......Morph 的作用就是让你在正确的时间使用正确的应用。你可以按照场景选择需要的 App，设定开启的时间段，比如工作时只用办公工具，回家后可以玩一些游戏。

Google 推出的这几个数字健康应用，有一些还是很实用的，比如 Post Box、We Flip。有的脑洞很大，不过实用性不高，Google 的实际目的其实是启发开发者，让更多人来制作数字健康应用。

对于这件事，国产厂商也很重视，主流的几个手机品牌都加入了类似的管理功能。当然，数字健康是否真的有用，最终还是要看每个人的自觉性，工具只能是个辅助。

查看评论

Google 推出 DNS over HTTPS 的 DNS 加密服務

Wed, 03 Jul 2019 08:54:32 CST

Google 要提供 DNS 加密的服務，主要有下述幾種：

Google 推出 DNS over HTTPS 的 DNS 加密服務

曾經有政府跟 ISP 業者要民眾的網站造訪紀錄，若 DNS 這端都加密起來的話，就連 ISP 也無從查起~ 於是 DNS 加密服務就此產生~

此篇 Wiki 有整理 DoH 有目前有哪些地方提供支援，哪些程式語言有相關套件可以使用： DoH

Google 官方新聞可見： Google Online Security Blog: Google Public DNS over HTTPS (DoH) supports RFC 8484 standard

Google 提供的服務如下：(Google 現在將 DoH 支援 RFC 8484 的標準)

https://dns.google/dns-query (RFC 8484 – GET and POST)
https://dns.google/resolve ( JSON API – GET)
註：以前實驗性質是使用 dns.google.com，現在正式版一律使用 dns.google 取代

Google 正在实现自己的 curl

Mon, 24 Jun 2019 12:48:23 CST

curl 开发者 Daniel Stenberg 称， Google 正在实现自己的 curl。Google 使用 Chromium 的网络协议栈 Cronet 去实现名为 libcrurl 的库，并将提供 libcurl API。Google 将使用自己的库去创造自己的 curl 工具。为什么要重新发明轮子？Google 认为使用 Cronet 允许开发者无需再去学习新的接口和相应工作流，能通过第一方或第三方应用增加 Cronet 的使用。

Google 推出了一个游戏生成器，让不会编程的你也能自己设计游戏

Mon, 17 Jun 2019 10:53:53 CST

从像素时代开始，很多游戏就有「自定义模式」，它允许玩家将一些基本元素组合，制作出独特的关卡设计。这种玩法后来被《我的世界》发扬光大，超高的自由度让每个玩家都成了「创世神」，只要你想象力足够丰富，动手能力足够强，就可以在游戏世界里建造出任何东西。

最近 Google 也推出了一款叫做《Game Builder》游戏，你不仅能在里面随意建造物体，更可以通过引导设计出一个完整的游戏。它不需要你有任何编程基础，只要通过简单的卡片组合，就能实现复杂的交互逻辑。

是玩家，也是「上帝」

《Game Builder》目前已经在 Steam 上架，支持 Windows、Mac 平台，它的本质就是一款游戏。你可以新建一个项目，根据引导学习如何设计一款游戏。初始角色是一个机器人，你可以用 WASD 控制移动，空格键跳跃，Shift 加速。

遇到更高的台阶怎么办？以一个玩家的角度，当然是想办法去学习二段跳，或者踩在其它物体上进行跳跃。在《Game Builder》里，你除了是一个玩家，也是游戏设计师，可以站在上帝视角对游戏世界进行各种改动。

不用代码，拖动卡片就能实现复杂交互

界面顶部有 Play 和 Build 两个按钮，切换到 Build 可以进入建造模式。点击选中机器人，在 Logic 中找到 Player Control，调整 Walk and Jump 的 JumpHeight 参数，现在你的人物就可以跳得更高了。

在引导模式中，《Game Builder》会用游戏的方式引导你吃星星，沿途学习基本的游戏设计知识。你可以按 V 切换第一人称视角、第三人称视角、俯视视角，以此体验 FPS、RPG 等类型的游戏。

利用 If-Then 逻辑可以让角色与其它元素产生交互，冲撞树木使其变红，攻击敌人使其掉血。这些交互看似简单，实际在设计游戏时需要用代码实现，而《Game Builder》把这些复杂的操作简化成了卡片交互，只要拖动相应的卡片，选择触发动作和反馈方式，就可以创建复杂的交互逻辑。

人人皆是云玩家，云设计师

《Game Builder》的设想是让没有编程基础的人也能通过拖动卡片，设计出自己想要的游戏。它们将游戏中所需的各种要素都简化成了一个个卡片，移动、生命值、攻击、治疗药水，十分丰富。

为了让初学者更容易上手，《Game Builder》在主菜单页面提供了卡片 Demo，你可以控制机器人与游戏中的元素产生互动，旁边文字标明了这个行为会产生何种后果，以及它是怎么发生的。

Google 之前针对 3D 艺术家推出了 Poly 平台，用户可以上传和下载 3D 模型，这些模型现在可以直接用到《Game Builder》中。游戏建造还支持多人模式，你可以与朋友共同建造一个游戏世界。

《Game Builder》的更新文件中出现了 YouTube Textures 的信息，与云游戏平台 Stadia 的实现方式刚好吻合。Google 很可能是在用这种方式，让更多人参与到游戏创作中，而不仅仅是作为「云玩家」。

下载地址： Steam

编辑：Rubberso

Google 认为禁止华为使用 Android 会危及到美国国家安全

Fri, 07 Jun 2019 23:40:06 CST

以美国国家安全的名义，Google 告诉特朗普政府它应该继续向华为提供 Android 相关服务。因为出口管制禁令，Google 被禁止授权华为使用 Google Play 等 Android 核心服务。Google 认为这将迫使华为创建 Android 分支版本，不再包含 Google 服务（国行版本就是如此），其中之一是自动扫描恶意程序的 Google Play Protect。这意味着华为向全世界销售的智能手机将运行没有 Google 安全功能的 Android 手机，这将会降低其安全性更容易被入侵。如果美国人向使用这些手机的人发送敏感信息，无论有没有端对端加密，信息都更容易被窃取。因此 Google 认为美国的国家安全受到了威胁。

安全漏洞潜伏十四年，你的 Google 账号还好吗？

Wed, 22 May 2019 19:17:00 CST

雷锋网消息，5 月 22 日，Google 在博客中透露，公司最近发现了自 2005 年起就存在的安全漏洞，漏洞导致部分 G Suite 企业用户的密码以明文形式储存。

目前尚不清楚有多少企业用户受到了影响，但 Google 明确表示，暂无证据表明用户的密码被非法访问过。此外，Google 也在积极地采取补救措施，比如通知相关企业的 G Suite 管理员，或重置可能受到影响的账户密码。

“隐秘”了十四年的漏洞被发现

G Suite 是由 Gmail、Google 云盘、Google 文档等应用程序组合而成的一个办公套件，Google 在今年 2 月份透露，全球共有 500 万个组织订阅了该服务，其中包括 60% 的财富 500 强公司。

而该漏洞之所以出现，恰恰是因为 Google 专为企业设计的功能。

2005 年，为了方便企业管理成员的账号，尤其是帮助新员工入职，企业的 G Suite 管理员能够手动上传、设置和恢复成员的密码。然而，这种方式存在缺陷，因为它会将密码以明文的形式储存到管理控制台，而非通过哈希加密储存到 Google 服务器。

这样一来，用户的密码就处在了风险之中。随后，Google 删除了这一功能。

Google 工程部副总裁 Suzanne Frey 说道：

我们应该明确这一点，虽然这些密码没有经过哈希加密储存，但它们仍保留 Google 经过安全加密的基础设施中。现在，这个问题已得到解决，而且也没有明确证据表明这些密码遭到了不当访问或滥用。另外，这些明文密码一直存储在 Google 服务器里，比存储到开放互联网上的密码更难访问。

Google 的官方声明中还花了大量篇幅来解释哈希加密存储的工作原理，他们似乎不希望人们把这个漏洞与其他密码泄露问题归为一类。

不过，人们还是对这一情况感到担忧。TrustedSec 公司的 CEO David Kennedy 说道：

Google 在这方面一直拥有良好的声誉，然而，这个安全漏洞存在了十四年之久至今才被发现，这难免会让人感到不安。

新漏洞“潜伏”了近半年之久

图片来自：Angel Garcia / Bloomberg / Getty Images

雷锋网获悉，本月早些时候，Google 在对 G Suite 新用户注册流程进行故障排除时，发现了另一个明文密码漏洞。

自今年 1 月起，在 G Suite 新用户完成注册之后，Google 内部系统会自动地存储用户的明文密码，这些未加密的密码最多保存了 14 天，不过该系统只对数量有限的授权员工开放。

目前，这个存在了近半年的新漏洞也得到了修复，而且，同样没有证据表明这些数据遭到了恶意访问。

Suzanne Frey 在博客中写道：

除了密码之外，我们的身份验证系统还具有多层自动防御系统，即使恶意访问者知道密码，系统也会阻止它登录。此外，我们还为 G Suite 管理员提供了 “两步验证”（2SV）选项，包括安全密钥，我们自己的员工帐户就依赖于这些密钥。

雷锋网注：2VS 即 2-step verification，最常见的表现形式为通过邮箱/手机验证码进行双重验证

在博客的最后，Suzanne Frey 还表达了 Google 对此次事件的歉意，文中写道：

我们非常重视企业用户的安全，并为自己在用户安全方面的实践而自豪。不过，这一次我们没有达到自己的标准，也没有达到用户对我们的期望。我们在此表示歉意，以后会努力做到更好。

多家企业存在类似安全漏洞

雷锋网获悉，除了 Google，Facebook、Instagram、Twitter 和 GitHub 都曾存在类似的安全漏洞。

今年 3 月，Facebook 表示，“数亿”Facebook 用户的密码以明文形式存储，多达 2 万名 Facebook 员工可以访问这些密码；Twitter 也在今年3月建议总数为 3.3 亿的 Twitter 用户修改自己的密码。不过，这两家公司都认为没有必要自动重置用户密码。

TrustedSec 公司的 CEO David Kennedy 说道：

这些公司的漏洞导致明文密码在内部公开，然而，即使是在公司内部，它也会带来严重的隐私和安全隐患。

一位发言人证实，Google 已将本次的漏洞事件向数据保护监管机构进行了通报；出于极大的谨慎，Google 还将通知那些密码处在威胁之中的 G Suite 管理员，如果管理员没有重置密码，Google 则会帮助他们重置。

Google 在事后主动向相关的监管机构通报，并积极联系企业重置密码，也算是亡羊补牢了。

不过，Google 在长达十四年的时间里都未能发现这个安全漏洞，那么发现下一个漏洞要花多长时间呢？谁又会为这些漏洞买单呢？

Google Glass 企业版第二代发布，支持 Android 移动设备管理

Thu, 23 May 2019 01:34:43 CST

Google Glass 研发又有了新进展，周一 Google 发布了第二代企业版智能眼镜（Google Glass Enterprise Edition 2），售价为 999 美元。Google Glass 最早于 2013 年推出，当时面向普通消费者。

它利用微型投影仪将计算机生成的图像发送到用户眼中，图像看起来像是浮动在现实世界之中。最终因为原装 Google Glass 价格高昂和内置相机引发的隐私问题，针对消费者的最早 AR 设备宣告失败。

两年后 Google 推出了全新的 Google Glass，它将这款新产品重新定位为面向企业，为外科医生、工厂工人和其他专业人士使用的工具。企业版 Google Glass 升级了原有配置，更好的处理器，更高清的摄像头。如果用户不用来拍摄的话，续航时间能保持在 8 小时左右。第一代企业版的重量基本和传统眼镜相当，并仅在一边眼镜上方安装了小型投影仪。

第二代 Google Glass 和上一代外观设计上没有太大变化，不过依然在充电速度、芯片、镜架和移动设备管理方面进行了升级。

它会在功能更强大的高通 Snapdragon XR1 平台上运行，这一芯片专门针对 AR 和 VR 设计。Google 表示，凭借 XR1 的功能，新款智能眼镜将可以加入“计算机视觉和先进的机器学习功能”。

Google 还和史密斯光学公司合作开发出新的镜架，看起来和普通眼镜差不多，这意味着它相对其他智能眼镜而言，佩戴起来更为轻便。此外，电池续航时间和其他组件也有所改进。

这款新眼镜是基于 Android 平台开发，因此用户可以在移动设备上配置应用和服务。企业可以更便于分发给员工使用，并且能够管理员工的使用方式。一个例子是当设备遗失时，就会被设置为禁用状态。

第二代 Google Glass 企业版面向物流、制造和医疗等服务行业，主要客户包括 H.B 富勒、萨特健康、德国邮政 DHL 集团和 AGCO 等 50 多家公司。根据业务和 Google 签订合同的公司，他们能以更低的价格购买新产品。

之前有传言认为这款产品对标产品正是微软 HoLolens 2，后者于今年 2 月份推出，3500 美元的售价比 Google 新产品高出不少。不过现在看起来 Google Glass 企业版第二代似乎竞争力低一点，毕竟后者可以通过双眼查看，而且因为美国军方这个大订单，还加入了夜视仪功能。

去年 11 月，微软拿下美国陆军价值 4.8 亿的合同，包括首批订购 2500 个 HoloLens 眼镜，最终需求预计会达到 10 万个。而在微软推出 HoloLens 的 3 年里，本身也就卖掉 5 万个智能眼镜。

Google 没有透露初代 Google Glass 企业版的销售情况，来自独立产品分析机构 Forrester Research 的预计是到 2025 年它将贡献 20 亿美元销售额。

尽管新款 Google Glass 进行了不少升级，研发团队已经从 Google X 调整到AR/VR 部门，瞄准的消费对象还是企业和专业人士。普通消费者如果需要一款 AR 设备，面对 999 美元的定价，考虑购买的可能性并不算大。

题图来自：Google

我们做了一个壁纸应用，给你的手机加点好奇心。去 App 商店搜好奇怪下载吧。

Google I/O 2019上8个你不可错过的重磅公布

Wed, 08 May 2019 11:57:03 CST

Google I/O 2019紧接着微软的节奏开幕，不过相比微软现在全面往云计算、企业解决方案、开源和开发者偏重的主题，手握一大票硬件软件发布的Google反而显得平易近人起来，所以根据今天凌晨的主题演讲内容，我们现在简要概括一下本次Google I/O里你不想错过的那些新发布。

平价手机Pixel 3A

虽然国内无法以正常渠道买到Google的亲儿子手机，倾心的人总会有那么一撮。继承了Pixel系列一直以来的拍照能力，舍弃防水、无线充电等高溢价附加值一般的功能，大家得到了Pixel 3A和Pixel 3A XL两部手机。今天以399美元起售的Pixel 3A在国外可能是罕见能在性价比上和一加竞争的拍照手机。

Google Nest Hub Max

一言以蔽之，Google Nest Hub Max其实就等于Nest摄像头、Google Home Hub和Google Home Max合体，把安防摄像头、智能交互屏幕和智能音箱全部做进一个数码相框大小的桌面硬件上。不过三者合体给摄像头带来了一个额外升级：人脸识别。可用于识别不同家庭成员，提供定制化的交互回应。Nest Hub Max预定于今夏上市。

Android Q测试版三项新功能

Android Q测试版现在已经面向大众提供下载，这个版本中包含了三项（可能不算）新功能：

1、适用于所有标准安卓应用的夜间模式。夜间模式我们不陌生，很多app自己会内建，不过在Android Q里这个变成了一个个系统设置里的开关，而且夜间模式的颜色不是深灰色，而是真的纯黑，在OLED屏幕上可能效果最佳。

2、专注模式。在各大厂商着手于解决手机成瘾问题的现在，Google再进一步，专注模式现在提供一个基于时间段的特定应用禁用方案，你可以让这个功能规范自己的摸鱼行为，也能通过家庭账号链接来管控孩子的堡垒农药时间。

3、智能答复。该功能的主要进步在于现在可支持第三方社交通信app，举个例子形容一下，有点像我们所熟悉的短信智能卡片，不过智能答复是内嵌在消息通知里的，提供消息内容一键回复和相关的快捷操作。

Android Q视频实时字幕

如果你有科学上网手段，看过Youtube，你肯定也体验过Youtube实时字幕的厉害与不厉害的地方。现在这个实时字幕要来到Android手机上播放的所有视频内容，不管它是标准的网络视频，还是自己拍摄的视频，甚至和亲朋好友视频聊天都全部能打字幕，帮助听觉障碍者能无碍使用视频功能，消费视频内容。

Project Mainline

继Project Treble后，Google对于消除生态碎片化的努力再度强化。Project Mainline的作用是通过Google Play Store推送系统升级时，把新版本的系统软件全部模块化，让每一个软件模块只对应手机的某部分功能，如此可降低大型系统升级给现有硬件引入新bug的几率，也能方便排查故障。不走Google Play的我们应该还是可以无视。

Google地图提供化名模式

当你在地图上搜索地点时，在你不经意间你的搜索行为和内容说不定已经被第三方跟踪和收集，化名模式的存在意义便是杜绝这种现象，配上此前的自动清除定位信息和应用使用记录策略，隐私保护或许能上一个台阶。然鹅Google地图我们不采取特殊手段是用不了的。

Google Lens升级

Google Lens的能力我们应该都已经相当熟悉，通过计算机视觉来实现的文字图像识别和处理，国内的安卓厂商也开发了不少此类功能，好不好用实不实用则另当别论。升级后的Google Lens能扫描菜单提供菜肴的图案、扫描小票计算消费总额、当然还可以翻译文本并朗读出来。Lens的功能升级会在本月内推送。

Google Duplex哑巴了

由于去年的演示太过惊艳，惊艳到大家最后细思恐极，Google今年对Duplex就动了禁言手术。新版本基于Web的Google Duplex就不能代你打电话了，不过它还是能在了解你的信息后在网上帮你预定一些别的服务如租车和购买电影票。而且现在Google Duplex不能全部一手包办了，它自动填好表格之后还是要让你过目的。

于此同时Google Assistant也在持续变得人性化，可能是得到了Duplex的帮助，它将能帮助用户答复消息、撰写邮件和邮件标题，个人化语音导航和更佳的驾驶模式支持，而且现在要关掉闹钟也仅需说一句“停”而不用再加个Hey Google的沙雕关键字了。

新的语音功能会伴随今年的新款Pixel手机上线，你当这个手机不是Pixel 3A就好。

福利 | Android 将迎海量更新、Pixel 家族再添新成员：Google I/O 2019 前瞻

Mon, 06 May 2019 16:09:46 CST

今年的 Google I/O 大会已近在眼前，名曰「开发者大会」，这场一年一度的盛事对用户、开发者乃至整个 Android 生态的走向都有着重要的指导意义。那么这次的 I/O 大会又会有哪些可能的看点呢？

如何科学地关注 I/O 大会

今年 I/O 大会的召开地点依然定在 Google 加州总部山景城海岸线圆形剧场，大会召开时间为当地时间 5 月 7 日至 9 日。而整个大会的「开胃菜」、同时也是大多数用户最为关注的 Google Keynote 则会在北京时间 5 月 8 日凌晨 1:00 拉开帷幕。

如果你的时间和精力都比较充足，届时可以前往活动的官方 YouTube 直播频道或通过国内频道进行收看（当然，你也可以关注少数派当天晚些时候放出的 Keynote 回顾）。

国内转播来源 | 图：谷歌开发者

而如果你对 I/O 大会除 Keynote 以外的其他会议日程感兴趣，Google I/O 2019 配套应用就是必不可少的跟会神器了。

今年 Google 为 I/O 2019 配套应用带来了不少新东西，我们也可以提前在这款应用上窥见 Android 设计语言上的新动向 —— 去年是 Material Design 2，今年则是暗色模式（Dark Mode）。在 Google I/O 2019 应用的设置中新增了一个选择主题的功能，这个功能在 Android 9 上提供了「明/暗/遵循省电模式」三种主题策略，在 Android Q Beta 2 中则是「明/暗/系统默认」。结合最近越来越多的 Google 应用都加入了暗色模式这一事实，显然 Android Q 对全局暗色模式的支持也已经是板上钉钉的事了。

I/O 2019 配套应用

当然，Android 在设计上的变化我们下文再做展开，回到「跟会」这件事情上，对大多数不能到现场参加 I/O 大会的朋友来说，Google I/O 2019 其实也是即时跟进大会日程和关键动态的利器。

更新后的配套应用在往年基础上加入了几项贴心又实用的小功能：比如首页的 Announcement 小卡片，这里会第一时间推送一些大会上的关键信息发布动态，就算没时间看完所有场次的直播，我们也能在 Google I/O 2019 应用首页的公告更新中看到当下发布会的亮点内容；另外议程详情界面这一次还加入了针对单个活动的日历通知功能，如果你对某几个方面的产品特别感兴趣，不妨打开 Google I/O 2019 大致浏览或搜索一下会议日程、找到你想重点关注的那几场，然后点击日历小图标加入日历提醒即可。

今年的 I/O 有什么看点

那么就大会本身来说，我们在今年的 I/O 上又会看到哪些新东西呢？

Android Q 的新改动

根据 Google 在 Android Q Beta 1 放出时公布的时间线和往年惯例，本次 I/O 大会势必会放出 Android Q 的第三个 Beta 测试版本。

Android Q 测试时间线

在现有的测试版本中，Google 已经带来了不少可圈可点的新特性。

比如更加严格的隐私和权限管理。Android Q Beta 1 在以往「允许/拒绝」式简单授权的基础上新增了「仅使用时允许」这一权限控制维度，同时在首次运行那些没有适配运行时权限（runtime permission）的老应用时首先弹出权限控制窗口来方便用户进行管理。

权限管理会有更多新变化吗？

另外，个性化广告推荐、用量数据分享等涉及到用户隐私数据的设置项目在 Android Q 中也被提到了更加显眼的位置。显然，Google 在 Android Q 上想要讲的如何加强隐私和权限控制的故事，5 月 8 日凌晨放出的 Beta 3，或许也会对这部分改动进行更加清晰的阐释和完善。

再比如对 Android 9 现有手势操作的改进。很多用户都对 Android 9 引入的「药丸」Home 键手势颇有微词，Google 去年也承诺将在往后的版本中继续对原生 Android 的手势功能进行打磨。

在 Android Q 中我们会看到新的手势系统吗？尽管在目前的测试版本中我们在这方面几乎看不到任何变化，但答案还是很有可能的：此前 XDA 的开发者已经通过 adb 指令的方式开启过好几种隐藏于当前测试版本当中的手势操作，包括完全取消「返回」按键的纯 Home 键手势方案、类似 iOS 的「底部手势+侧边缘划动返回」方案等等。

其中一个正在测试的手势方案 | 图：XDA

Android Q 最终会采用哪一种手势方案，I/O 大会或许会给出答案。

当然，在用户和开发者社区中呼声同样不小的全局暗色模式也是 Android Q 的一大亮点更新。去年年底 Google 在开发者峰会上首次公开承认了 OLED 屏幕技术、暗色主题和电量消耗这三者之间的微妙关联，为 Android 系统和白得耀眼的 Material Design 2 带来暗色模式的进程就此开启。

Google 自家应用在明/暗主题下的耗电对比

虽然目前 Google 还没有在 Beta 2 中为 Android Q 加入正式的暗色模式开关，考虑到 Google 大部分自家应用都已加入了暗色主题，这一功能的跳票可能性很小，两天后的 I/O 大会上，我们应该能够看到全局暗色模式的正式亮相。

有些遗憾的是，早前我们颇为看好的 分区存储（Scoped Storage）特性要 不幸「跳票」了。从 Beta 3 开始，应用只要没有面向 Q 适配，就将默认采用与旧版本 Android 系统相同的存储机制，而非此前我们所介绍过的「沙盒」处理。

「沙盒」机制作用下的存储空间更加干净

从当前的测试版本来看，这一特性延迟上线其实也是可以理解的：分区存储机制会对那些没来得及适配的应用造成不小的冲击，导致包括用户数据丢失、基础功能失灵等一系列影响，那些存储行为不规范的应用在这一机制下甚至无法正常运行；另一方面，分区存储机制和早期的存储重定向应用一样，也存在着影响性能的 bug，Google 可能还需要一些时间来好好打磨。

气泡通知与改进后的分享菜单

除了上述特性，Android Q 还将加强了对单色摄像头的支持、引入单独存储图片深度数据的DDF（动态深度格式）架构同时默认开启最新的 TLS 1.3 协议。此前我们介绍过的气泡通知、分享菜单改进等特性在 Beta 3 版本中应该也会得到进一步完善。

Pixel 家族的新成员

从去年年底开始，有关入门版 Pixel（彼时还叫「Pixel Lite」）的流言便时有传出，去年曾准确爆料过 Pixel 3 XL 的俄罗斯网站 Rozetked.me 更直接放出过入门级 Pixel 的开发机实物照片。

而后随着 Android Q 测试进程的不断推进，关于入门版 Pixel 新机的曝光也不断浮出水面。从外媒最近公布的信息来看，Google 可能会在 I/O 大会上公布 Pixel 3a/3a XL 两款入门机型，Pixel 3a 在外观上具有与 Pixel 3 相似的设计风格，但相较后者还是有很多降级之处：

机身背面依旧是单摄像头、撞色设计，但不再使用金属和玻璃的拼接工艺，而采用了纯塑料材质。

屏幕的边框稍稍有些变宽。

前置的下扬声器也挪到了机身底部，顶部的听筒到底是不是兼任扬声器还不得而知。

机身顶部多了 3.5 mm 的耳机插孔，不知是因为机身空间有多还是阉割了防水特性。

图：Onleaks x 91Mobiles

最近曝光的零售包装盒也提供了更为丰富的细节：本次新机除了经典的黑白二色，还多了一款名为 Purple-ish 的淡紫配色。

Pixel 3a XL 零售包装 | 图：AndroidPolice

结合 Google Play 开发者控制台泄露出的配置信息，两款新机的硬件参数整理如下：

Pixel 3a：2220×1080 5.56英寸 LG OLED显示屏、高通骁龙 670 处理器、4GB RAM、 32G起步的存储空间、与 Pixel 3 相同的前置 800万像素镜头和 1200万像素后置镜头、电池 2915mAh（约 3000 mAh左右）、 USB C配 18W快充、3.5mm 耳机孔、Active Edge、Titan M安全芯片以及 eSIM 支持。

Pixel 3a XL：配置与 Pixel 3a 大体上一致，但屏幕尺寸为 6 英寸，分辨率 2160×1080，存储空间 64GB起步，处理器疑似升级为高通骁龙 710，电池也拓展到 3700mAh 左右。

在最让人纠结的价格环节，Google 以往在 Pixel 旗舰机型上给出的定价往往让人望而却步，此次作为入门版的 Pixel 3a/3a XL 则下探到 399 美元/479 美元起售，折合人民币约 2690 元/3230 元。

原汁原味的 Android 系统，经典拼接设计的个性化机身，虽然配置略降但摄像头表现毫不缩水的 Pixel 中端机，能够打开你的钱包吗？

还有什么值得期待

除了新系统和新手机，你还希望在 I/O 大会上看到哪些新东西呢？

就我个人而言， Google Assistant 的官方简体中文支持应该是愿望清单的头一项。就在不久前 Google 为 iOS 版 Google Assistant 应用推送了简体中文支持，少数派也第一时间进行了评测。

iOS 已经用上了简体中文版 Google 助理

无论从功能还是从本地化程度来说，简体中文下的 Google Assistant 都已经相当出色，要是本次 I/O 大会 Google 能向 Android 和其他硬件平台（包括 Google Home 系列产品）全面开放简体中文支持，势必又会为我们开启一个崭新的世界。

此前传闻中 Google 或许会 通过 Play 应用商店来推送 Android 系统更新的消息也格外值得我们关注：当下已经有很多包括 Google 自己在内的 OEM 厂商选择即将系统内置应用放在 Play 应用商店中更新，因为这样做的好处很明显，相较系统而言更新迭代需求更频繁的应用显然不适合与系统更新绑定在一起。

而常年在安全漏洞与安全更新补丁的「拉锯战」中经受洗礼的 Google，这一次似乎还想进一步让 Android 系统的更新也彻底摆脱周期和规律的束缚：外媒 9to5Google 不仅通过对 Play 应用商店的拆包挖掘到了通过 Play 应用商店进行 Android 系统更新的相关字符串，此前也已经有 Reddit 网友分享了它们通过 Play 应用商店进行 Android Q 测试版本更新的经历。

通过应用商店更新 Android 系统 | 图：Reddit

其他 OEM 厂商是否可以通过 Play 应用商店推送自家的系统更新呢？在更多围绕这项技术的细节正式披露前还很难说，一切还是要等到 I/O 大会见分晓。

最后，根据 9to5Google 编辑早前对 Fuchsia 代码的挖掘成果， Google 很有可能会在本次 I/O 大会上发布一款智能家居新品 Nest Hub Max。

早前 Google Store 官网意外上线的 Nest Home Hub 页面

综合代码信息和早前意外上线 Google Store 官网的页面来看，Nest Hub Max 将会是一款搭载 2GB 运存、10.1 英寸 LCD 显示屏和索尼 IMX 277「Nest」相机的智能显示设备。

不过这款产品的命名显然更加有趣 —— Nest 往后会成为类似 Pixel、但专注智能家居领域的独立子品牌吗？如果不是，这条产品线与当前的 Google Home 系列产品又将各自扮演怎样的角色？

小结

欢迎你在评论区说说：本次 Google I/O，你最期待哪个软件/硬件的发布？并简单说一说原因。我们将从中选择 5 位幸运儿各送出由 Google 官方提供的纪念 T 恤一件。

夏天到了，把 Google 穿在身上当一个骄傲的谷粉吧！

感谢 Google 官方 @Google 黑板报提供的奖品，除了少数派，你也可以关注 @Google 黑板报以及微博 #谷歌I/O大会# 话题获取更多关于 Google I/O 2019 的最新动态。

本文由 @ 路中南和 @ Clyde 联合撰写。

关联阅读：

Android Q 第一个 Beta 版发布，这是值得你关注的 6 大变化 | 具透

「沙箱」默认开启，Pixel 3 双卡双待……Android Q Beta 2 都有这些新变化 | 具透

无需第三方应用就能管好流氓应用，这可能是 Android Q 最重要的新功能 | 具透

参考链接：

> 下载少数派客户端、关注少数派公众号，第一时间了解科技圈的新鲜事

> 特惠、好用的硬件产品，尽在少数派 sspai 官方店铺

亚马逊、苹果和 Google 都有雇员听语音助手的录音

Sat, 13 Apr 2019 22:49:46 CST

亚马逊、苹果和 Google 都有员工，从智能助手和语音助手应用程序中收听客户语音录音，引发如何界定窃听和隐私的议论纷纷。彭博社在采访亚马逊“审听过”其智能语音助手 Alexa 录音的工作人员后，突出报道这一话题。上述三家公司都表示，偶尔会对语音录音进行审听，以提高语音识别能力。一些审听人员告诉彭博社记者，他们在内部聊天室里也会互相分享有趣的语音录音片段。他们也描述曾听到令人不安的片段，比如有可能发生的性攻击。亚马逊发布声明表示，它认真对待客户安全和隐私。审听客户录音样本有助于训练语音识别和自然语言理解系统，绝不允许滥用其制度。声明称，亚马逊的审听雇员也无法直接了解能确认客户身份的资料。

【PW早报】Google发布150美元TPU芯片开发板

Thu, 07 Mar 2019 08:07:56 CST

今天是2019年3月7日，离全年结束还有299天。1998年3月7日，世界上首条主要为互联网服务的海底光缆开通，连接纽约和伦敦。

今天，你应该关注的新闻有：

Google发布150美元TPU芯片开发板

根据 9to5Google报道，在今天举行的 2019年TensorFlow开发者峰会上，Google公布了一个智能硬件平台，用于解决从原型到产品的物联网硬件的端到端解决方案。

该平台目前发布的产品包括：搭载Edge TPU的Coral Dev Board单板计算机、可以为机器学习提供推理能力的USB Accelerator、500万像素的摄像头模块等。

发布会还将TensorFlow 升级为TensorFlow 2.0 Alpha版，Logo进行了扁平化设计。

据量子位介绍，Coral开发板（Coral Dev Board）是一款售价150美元（折合人民币约1000元）的小型计算机，具有可拆卸的模块化系统和一个定制的TPU芯片，类似于树莓派。Coral中的Edge-TPU尺寸大约只有一枚硬币的1/4，拥有1GB的LPDDR4内存和8GB的eMMC存储，安装Mendel版Linux或者Android，可以进行本地的离线运算。

Coral能够以每秒30帧的速度在高分辨率视频上运行深度前馈神经网络，或者以每秒超过100帧的速度运行MobileNet V2这样的单一模型。

USB Accelerator体内同样包含一颗Edge TPU，可以在任何64位ARM或x86平台的Debian Linux上运行。Coral USB加速器售价75美元，可以加速树莓派和Linux系统的机器学习推理。

三星正在研发两款新折叠屏手机

根据彭博社报道，在上个月推出三星Galaxy Fold之后，三星计划再推出两款折叠手机。其中一款类似翻盖式手机，还有一款的折叠方式与华为Mate X差不多。

据报道，三星准备今年晚期或者明年初期发布垂直折叠手机，它正在用模型优化设计。在这款新设备上，外部会有一块额外屏幕。而向外折叠的手机已经有了原型产品，因为没有外部屏幕，所以更薄。

三星还可能会植入屏下指纹传感器，就像上个月推出的Galaxy S10一样。除此之外，三星正在试图改进折叠屏幕的耐用性问题。Galaxy Fold的显示屏面板在折叠约1万次后会出现折痕，三星正考虑在推出新产品后，向用户提供免费屏幕更换。三星计划2019年生产至少100万部可折叠手机。

库克：去年苹果新员工一半没有本科学历

根据 9to5mac报道，库克近日前往华盛顿特区参加了美国生产力政策顾问委员会会议，席间表示该公司 2018 年雇佣的美国员工中有半数没有正规的 4 年大学本科学历。库克表示，大家都知道，苹果就是由辍学生（乔布斯）创办的，所以我们真的从来没有认为大学学历是必不可少的，我们一直在试着扩展我们的眼界。

另一方面，库克表示，苹果希望进一步推进其教育计划。他解释说，该公司致力于通过其“Everyone Can Code”计划扩大编码等技能的可用性。根据库克的说法，到目前为止，已有4,000所学校采用了“Everyone Can Code”课程。

Facebook开始转型：专注加密的短时消息

Facebook首席执行官马克扎克伯格在博客中表示，未来端到端的加密服务将贯穿于Facebook所有旗下包含即时通讯的业务功能，Facebook Messenger将向Whatsapp的模式靠拢。扎克伯格表示，加密将成为Facebook未来的关键服务之一。未来Facebook将在加密、缩短内容的存续、安全、互通和安全数据存储等方面进行转型。

除了使消息传递更加私密之外，扎克伯格还计划使消息传递具有互操作性。这将首先允许在Facebook服务之间发送消息，但Facebook最终希望使Instagram Direct，WhatsApp和与SMS互操作。为了保证安全，扎克伯格表示将重新设计信息保留功能：内容会自动过期或随着时间的推移而存档。

特斯拉首批3.5万美元基础版Model 3下线：两天生产500多辆

根据 electrek社报道，特斯拉宣布推出3.5万美元基础版Model 3不到一周，特斯拉已经生产出了首批使用标准电池的Model 3汽车。据报道，该公司在过去两天生产了首批500多辆Model 3汽车。目前，特斯拉已有550辆Model 3汽车准备出货。在特斯拉的内部系统中，特斯拉还将这些汽车列为“Model 3 50”，这通常指的是电池组容量，这意味着基础版Model 3电池组的容量为50kWh。

关于中国Tesla工厂建设进度，海市政府新闻办公室官方微博@上海发布发微博表示，特斯拉纯电动车项目进展顺利，预计5月份完成总装车间建设，年底部分生产线正式投产。

个人信息保护需立法明确数据所有权

根据新京报报道，在3月4日上午举行的十三届全国人大二次会议新闻发布会上，大会发言人张业遂在谈到今年的立法计划时表示，正抓紧研究起草个人信息保护法。

对于立法呼声很高的个人信息保护法，张业遂介绍，“事实上，我国已经有多部法律、法规、规章涉及个人信息保护。比如刑法、民法总则、消费者权益保护法、网络安全法、电子商务法等，都作出了相关的规定。但是从总体上看，呈现分散立法状态，所以需要根据形势的发展，制定有针对性的专门法律来加以规范，形成合力。”张业遂表示，全国人大常委会已将制定个人信息保护法列入本届立法规划，相关部门正在抓紧研究和起草，争取早日出台。

蔚来股价一夜暴跌21%

美三大股指周三低开低走，集体收跌。截至收盘，道琼斯工业平均指数下跌133.17点，报收于25673.46点，跌幅为0.52%；纳斯达克综合指数下跌70.44点，报收于7505.92点，跌幅为0.93%；标准普尔500指数下跌18.20点，报收于2771.45点，跌幅为0.65%。

中国概念股普跌，其中跌幅较大的公司包括：蔚来汽车（跌21.16%）、趣头条（跌19.94%）、第九城市（跌19.56%）、云米科技（跌15.90%）、极光数据（跌11.80%）、信而富（跌10.91%）、虎牙（跌8.81%）、无忧英语（跌7.55%）、趣店（跌7.06%）、寺库（跌6.18%）、聚美优品（跌5.26%）。

蔚来汽车此次暴跌受到此前受交付量预期降低和中止上海工厂计划影响。

3月6日凌晨，蔚来汽车（NYSE：NIO）发布了截至12月31日的 2018财年第四财季及全年财报。财报显示其净亏损为人民币33.613亿元（约合4.889亿美元），亏损环比扩大41.3%，同比扩大102.1%。

2018年第四季度ES8产量为8069辆，相比于第三季度4206辆增长91.8%。第四季度ES8交付数量为7980辆，相比于第三季度3268辆增长144.2%。2019年1月和2月ES8交付量分别为1,805和811辆，与2018年12月相比月交付量下滑高于预期。

蔚来在财报中透露已与相关方达成一致，取消2017年签订的在上海嘉定建厂的计划，公司将继续走江淮汽车为其代工的路线。此前消息显示，2018年2月，蔚来第二工厂正式完成选址，将落户在上海嘉定外冈镇，原计划2018年中旬动工，规划用地800亩左右。

3月6日，国家开发银行出售所持470万股蔚来汽车股票。根据国开国际投资有限公司公告，于2019年3月6日，董事会批准一项潜在出售事项，透过公开市场基于当时市况以不低于每股7.15美元的价格出售公司持有的蔚来汽车合共467.04万股美国预托证券（占蔚来汽车于公告日期已发行股本约0.44%）。

出售事项完成后，集团将不再持有任何蔚来汽车美国预托证券。蔚来汽车为中国高端电动车市场先驱，主要从事设计、共同制造及销售智能联网高端电动车。

熊猫直播被传破产

根据全天候科技报道，3月6日，有网友在社交平台爆料，称熊猫直播本月将申请破产，员工统一赔偿半个月工资；3月18日，熊猫直播将关闭服务器。

同时，还有一张网传截图显示，疑似熊猫直播COO张菊元的助理在熊猫直播员工群“潘达踢威”中表示，已经帮员工安排了多家公司的用人需求。

据报道，熊猫主播群里的工作人员（超管）证实“熊猫确定不做了”，“消息也是今天（3月6日）下午刚出来的”。还有一名熊猫直播离职员工表示，熊猫TV近期经营困难，很多员工都在另寻出路。