https://www.wsj.com/tech/ai/amazon-ceos-talks-with-u-s-officials-triggered-crackdown-on-anthropic-models-dcc90578?st=Yct6gx&reflink=desktopwebshare_permalink

GLM-5.2 正式发布：智谱推行全面开放的前沿智能

智谱（Zhipu）正式发布其迄今为止能力最强的开源模型 GLM-5.2。官方针对近期部分前沿模型因非技术原因突然受限的情况表达了遗憾，并重申其“激进开放”的态度：科学应具有全球性，通往通用人工智能（AGI）的道路不应被高墙封闭。AGI 应成为全人类协作探索智能边界、解决复杂挑战的基石，而非少数人可以垄断且随时可被撤销的特权。

模型核心能力包括：

• 支持真正可用的 100 万（1M）token 上下文窗口。
• 在长程任务（long-horizon tasks）的独立执行能力上保持持续领先。
• 为构建复杂智能体（Agent）应用提供坚实的基础设施支持。
• 继续作为智谱打造最强国产编程模型的主力引擎。

发布安排：

• GLM-5.2 已于当晚 5:21 正式向所有 GLM Coding Plan 用户开放，涵盖 Lite、Pro 及 Max 版本。
• API 将于下周上线。

官方表示，此次发布旨在让每位专注的开发者都能更接近前沿智能，并强调“AI 的未来是开放的，是属于人民的”。

SQL to ER Diagram 是一款免费的浏览器端开源工具，专门用于将 SQL 数据库模式（主要是 CREATE TABLE 语句）即时转换为交互式实体关系图（ERD）。用户无需注册账号、安装软件，也无需将数据上传至任何服务器，所有处理均在本地浏览器完成。

核心功能

• 即时可视化：将 SQL DDL 粘贴到编辑器后，工具会自动解析并渲染出包含表、列、主键、外键及表间关系的交互式图表。
• 交互编辑：支持拖拽调整表位置、滚动缩放画布、双击重命名元素；同时提供自动布局功能，并允许添加注释。
• 语法兼容性：支持 PostgreSQL、MySQL、SQLite 和 SQL Server 的 CREATE TABLE 与 ALTER TABLE 语法，可识别主键、外键、唯一约束及非空约束。

隐私与本地运行

该工具强调 100% 本地处理：SQL 模式不会离开用户的浏览器，不会被上传或存储到任何服务器，保障数据隐私。

导出与分享

完成图表后，用户可将其导出为高分辨率 PNG 或矢量 SVG，也可将完整项目保存为本地文件，或生成一个把图表信息编码在其中的可分享链接。

使用门槛

无需安装，桌面端和移动端的浏览器均可直接访问，完全免费且开源。

https://news.sky.com/story/derbyshire-police-officer-investigated-for-using-ai-to-create-evidence-in-multiple-cases-13553661

居家AI编程的三种低成本方案与最佳实践

文章探讨了个人在家进行AI编程时，避免像企业一样高额投入的三种可行路径，核心选择依据在于对未来一年硬件与模型迭代速度的判断。

一、本地自建（Self-Hosting） 购买设备本地部署开源模型，一次性投入后无按token计费成本。但前期硬件支出高，且家用设备能运行的模型性能通常弱于前沿实验室的版本。该方案仅在需要让设备长期高负载运行（如通宵处理耗时任务）时才具备成本优势。多数家庭用户难以持续打满机器负载，且当前购入的硬件可能在一年后迅速贬值。

二、API租用开源模型 跳过硬件采购，直接向服务商按API调用付费使用开源模型。这是大多数个人的最优选择：避免在配置标准尚未稳定时投入数千美元购买GPU；省去了压榨本地模型长时运行性能的调优工作；可随时切换至更便宜或更先进的新模型，无需转售设备。借助OpenRouter等平台，切换成本几乎仅为一行代码的改动。

三、精打细算前沿订阅 购买OpenAI、Anthropic等顶级厂商的包月订阅（约400美元/月），其包含的token量按官方API标价折算约值2800美元，性价比极高。但这类方案设有使用上限，大规模AI原生工作流会快速耗尽配额。因此，它们更适合由人工手动驱动的高价值思考与规划任务，而非作为7×24小时运行的Agent引擎。

推荐策略：混合方案 实践中最有效的方式是结合后两种：保留前沿订阅用于处理复杂逻辑思考与技术规格（spec）撰写；将具体、机械性的编码实现交给按量付费的开源模型API。通过“规格驱动开发”（Spec-Driven Development），让昂贵的前沿模型输出设计方案，由廉价模型执行填充。采用此策略，个人有望以约1000美元的成本，在一个月内完成传统上需要20名工程师才能交付的工程量。

作者将大语言模型（LLM）的上下文窗口划分为智能区与愚笨区。无论厂商标称的窗口容量有多大（20万、100万甚至200万 token），真正可靠、注意力集中的“智能区”大约仅在前 10 万 token 左右。一旦超出此范围，模型便会开始遗忘早前信息，表现明显下降。

这对编程智能体（coding agents）尤其危险，因为它们消耗 token 的速度极快：几次文件读取、一场长时间调试或一次大规模测试运行，很容易在半天内就突破 10 万 token。然而，RULER 研究与 Chroma 关于**上下文腐烂（context rot）**的报告均指出，有效上下文长度只是标称值的一小部分，且模型性能会随着窗口被填满而逐步衰减。因此，巨大的上下文窗口在很大程度上只是营销数字；底层架构虽然能支撑更大的窗口，但并未真正解决注意力机制的根本缺陷。

现代智能体工具（如 Claude Code）开始引入**自动压缩（auto-compaction）**机制：当会话过长时，自动总结历史记录并重新开启会话。这虽有一定缓解作用，但本质上属于事后补救——压缩往往在模型已经进入“愚笨区”后才触发，且总结本身也是由已 degraded 的模型生成，质量难以保证。

作者推荐更主动的应对策略：手动结束当前会话，然后基于自己撰写的规格说明（spec）开启新会话。这种“面包屑”（breadcrumb）式交接比自动总结的信噪比更高，因为人可以直接决定哪些信息对未来真正重要。更进一步，可借鉴 obra/superpowers、mattpocock/skills 等项目，将智能体工作流 Structured 在小型、具名的产物（PRD、计划、技能、子智能体交接文档等）之上。核心思路是主动将信息移出实时会话，固化为外部产物，让下一个会话直接读取。

归根结底，作者建议将上下文窗口视为预算：默认只有最前面的一小块真正可靠；任何能从实时会话中移出、写入明确产物的内容，都能减少注意力机制的负担，确保工作始终停留在智能区。

GameBoy Workboy 摘要

Workboy 是一个未发行的 Game Boy 游戏/外设，由 Montague-Weston 开发，计划授权给 Fabtek, Inc. 发行。其核心概念是将 Game Boy 转变为一个功能丰富的微型工作站，通过配套的键盘外设，用户可以管理日程安排、地址、笔记、银行账户余额和电话号码，并进行温度、货币转换以及在五种语言之间进行翻译。

尽管在当时的游戏杂志上刊登了大量广告，该游戏最终从未正式发布。不过，其 Game Boy 卡带的 ROM 文件在 2020 年 9 月的任天堂泄露事件中被发现。原本被认为已丢失的配套键盘原型，在 2020 年 12 月由 DidYouKnowGaming? 频道的 Liam Robertson 通过视频首次公开展示，证明该泄露的 ROM 可以与键盘配合正常工作。

泄露的 ROM 中存在版本信息差异：标题画面显示版本号为 8.87，但代码中的相关字符串显示其内部版本号为 5.74。ROM 中包含支持五种语言（英语、西班牙语、意大利语、德语、法语）的标题文本，这些文本在显示前会从 ROM 中读取，并将版本号“5.74”替换为“8.87”。

在泄露内容的分类中，Workboy 被归类为任天堂的 官方配件，与 Family BASIC、Famicom Disk System、Super Game Boy 等并列。

Phoenix LiveView 1.2.0 已发布，用户只需将 mix.exs 中的依赖版本更新为 {:phoenix_live_view, "~> 1.2.0"} 并重新获取依赖即可完成升级。

该版本的核心新功能是同位 CSS（Colocated CSS）。基于 1.1 版本为 Phoenix.LiveView.ColocatedJS 所做的工作，开发者现在可以直接在任意 HEEx 模板中编写 CSS。通过在 <style> 标签上设置 :type={MyApp.ColocatedCSS} 属性，LiveView 会在编译时将标签内容提取到 _build/phoenix-colocated 目录中，随后由构建工具（如 Tailwind 或 Esbuild）将其纳入常规 CSS 流水线处理。

为避免组件样式意外泄露到其他页面元素，LiveView 1.2 引入了基于 CSS @scope 规则的作用域机制。HEEx 编译器会在模板根元素上添加可配置的特殊属性（如 phx-r 用于标识模板边界，以及唯一的 phx-css-* 属性用于标识组件作用域根），从而支持类似如下的写法：@scope ([phx-css-foo]) to ([phx-r]) { ... }，使样式仅作用于特定组件内部。

为实现同位 CSS，HEEx 模板的编译流程被重构为独立的 tokenization 和 parsing 两个阶段。这一改动不仅支持宏组件（如 colocated CSS 和 JS），还简化了整体编译逻辑，并复用了原本在模板编译与格式化之间重复的逻辑。

需要注意的是，由于 @scope 规则在当前主流浏览器中的支持度尚不成熟，LiveView 1.2 默认不直接内置作用域实现，而是提供了一个 @behaviour 供开发者自行实现作用域策略。官方文档中同时提供了基于 @scope 的示例实现，供愿意早期采用的用户参考。启用根元素边界标记需要通过 config :phoenix_live_view, root_tag_attribute: "phx-r" 进行编译时配置。

除上述主要功能外，1.2 版本还包含多项细节改进：

• 支持通过实现 Phoenix.LiveView.HTMLFormatter.TagFormatter 行为，使用外部工具（如 prettier）格式化 HEEx 中的 <script> 和 <style> 标签；
• 通过 push_event 发送 Phoenix.LiveView.JS 结构体时，若使用 Jason 或内置 JSON 模块，将自动完成编码，亦可手动调用 JS.to_encodable/1；
• HEEx 调试注解现支持按模块配置（@debug_heex_annotations、@debug_attributes）；
• 测试警告现可按类别进行配置；
• JavaScript 客户端拥有了独立的文档。

更多细节可参阅官方更新日志。

文章介绍了一款名为《Pac-Man, but you're the ghost》的网页小游戏，其核心理念是逆转传统《吃豆人》的玩法，让玩家扮演幽灵。作者出于对原作中幽灵角色的共情——它们平时巡逻围堵吃豆人，却会在对方吃下能量球后反被追杀——因此制作了这款“站在幽灵视角”的作品。

游戏的主要机制包括：

• AI 控制的吃豆人：吃豆人由独立的 AI 驱动，自动在迷宫中移动并试图吃光所有豆子。
• 玩家的任务：操控幽灵，在吃豆人清空前迷宫前将其抓住。
• 经典反转：如果吃豆人吃到了能量球，局势会瞬间翻转，吃豆人会反过来追杀玩家控制的幽灵，持续数秒，此时玩家必须拼命逃跑。

这款游戏已在 GitHub Pages 上线，可直接通过链接 https://garritfra.github.io/pac-hunt/ 在浏览器中游玩，文章内还附有一张游戏截图。

ReactOS 是一款致力于与微软 Windows 程序及驱动程序实现二进制兼容的开源操作系统。历经 28 年开发，该项目近日达成了一项新的里程碑：成功在真实硬件上运行经典游戏《半衰期》（Half-Life）。

根据 ReactOS 开发者在 X 平台（原 Twitter）公布的消息，这是首次有报道称该游戏不仅能在 ReactOS 上成功启动，还能顺利进行实际游戏操作。虽然数年前曾有该游戏在 ReactOS 下完成初始化的报道，但此次似乎是首次确认其在游戏过程中稳定运行。

此次测试由 ReactOS 用户 “Zombiedeth” 完成。测试所用的硬件为一台戴尔 OptiPlex 主机，搭载英特尔酷睿 i5-2400（Sandy Bridge）处理器和 NVIDIA GeForce 8400GS 独立显卡。

文章指出，尽管如今通过 Wine 等兼容层在 Linux 等平台上运行《半衰期》已十分成熟，但在 ReactOS 上实现该游戏的可玩性，依然标志着这款开源系统在追求 Windows 二进制兼容性的道路上取得了切实进展。

开发团队通过 X 平台分享了相关截图与更多细节。

第10代本田思域车机逆向工程进展更新

作者Eric McDonald对其2021款本田思域车机（headunit）逆向工程项目提供了最新进展。自三年前公布初始研究以来，该项目在更新机制分析和工具开发方面取得重大突破。

AOSP测试密钥签名漏洞

研究发现，本田车机通过USB进行更新，更新包为经签名的AOSP格式文件，并由Android recovery程序执行安装。关键漏洞在于：本田使用了公开已知的AOSP测试密钥对更新文件进行签名，该密钥直接存放在系统的res/keys路径下。尽管本田修改了recovery二进制文件，但其中的verify_file签名验证逻辑与原生AOSP完全一致。

这意味着攻击者只需使用公开可获取的AOSP测试密钥对任意固件包签名，即可通过USB端口在车机上安装任意代码，无需传统的root权限（如利用su或setuid）。任何能够物理接触车辆前部USB端口的人，都可以在headunit上实现任意代码执行。作者将这种攻击（类似于"evil maid"攻击）命名为**"EvilValet"（邪恶代客泊车攻击）**，即代客泊车员或拥有物理访问权限的攻击者可在车主不知情的情况下植入恶意更新。

作者强调该文并非技术细节报告，完整的技术文档已另行发布。同时，他已发布工具ota-builder，可帮助用户轻松制备能被车机接受的更新文件——例如创建一个包含setuid权限的su二进制文件、从而root设备的更新包。

此外，作者通过分析公开渠道获取的欧盟版软件更新包MRC_EU_SW_v12_4.zip，确认其同样使用AOSP测试密钥签名。因此推测所有官方更新可能均使用该公开密钥，但仍需更多贡献者验证不同版本和车机变体。

工具开发：apk-rebuilder

除更新机制外，项目另一项核心成就是apk-rebuilder工具。该工具能够接收互联网上的本田思域更新文件，并自动输出一套干净的文件树，完成逆向工程师原本需手动执行的各项任务，包括：解析资源、重建.smali代码、重新打包APK、提取ramdisk等。

该工具具有重要法律与协作意义：由于无法直接发布本田受版权保护的源代码，项目转而发布一个"函数"——接收用户自行获取的更新文件作为输入，输出本田的.smali代码、图像资源等。结果文件遵循清晰的目录结构，便于在文档中引用，而无需上传敏感文件本身。

待办工作与社区贡献机会

作者呼吁技术爱好者和社区贡献者协助推进以下工作：

• 已知版本收集：更新机制高度依赖版本号匹配。构建更新包前需了解目标车机期望的版本号，且不同软件版本可能存在差异，错误的版本信息可能导致recovery循环（软砖）。项目仓库设有"Known Versions, Display Audio Software"章节，欢迎第10代思域车主贡献数据。
• ARMv7工具链：作者本地已有一套基于Docker的实验性工具链，可使用与原厂二进制文件相同版本的编译器和构建标志将C代码编译为ARMv7。计划在未来发布干净、通用的版本。
• 自定义主题：主题资源位于三菱 fork 的AOSP框架内，且车机应用经过minified处理、依赖硬编码资源ID。要实现自定义主题需对厂商框架进行外科手术式修改，难度极高，但欢迎贡献者尝试。
• 改进aidl-rebuilder：现有工具可解析.smali文件并生成/映射车机上的所有AIDL接口。完善后可支持开发虚拟仪表盘等自定义应用。

关于文档与LLM的理念

作者有意减少传统参考文档的维护，转而专注于打造可靠、确定性的工具。其理念是：工具能将复杂的原厂代码转换为更易消化的形式（如结构化的smali、资源文件），用户随后可利用LLM基于这些"更易消化的形式"回答具体问题。这样避免了维护可能随车机代码迭代而过时的技术文档，因为车机代码本身才是唯一可信的"真相源"。

项目展望

作者表示，他个人计划逐步减少在该headunit上的深入调查工作，转向其他项目。但项目仓库不会废弃，将持续接受社区Pull Request。

在 Behringer DDX3216 调音台上从零编写 x86 BIOS 并运行 DOS

作者于 2026 年发现 Behringer DDX3216 数字调音台内置真正的 AMD Elan SC300 386 SoC，遂决定从零编写 BIOS，深入学习 x86 启动流程，并最终运行完整的 DOS 系统。该设备主要硬件包括：AMD Elan SC300（集成 UART、PCMCIA、GPIO、LCD 接口）、64 KB ROM（27C512）、16 MB DRAM、4-bit LCD（Toshiba T6A39/T6A40 控制）、外部 TLC16C552 双串口+并口、PCMCIA 转 CF 卡槽，以及未焊接的 Intel 82078 软驱控制器。

由于市面上找不到可用的 SC300 BIOS（PC Engines 仅存 SC400 及以上源码，Phoenix/General Software 也无法提供 32 年前的资料），作者只能自行开发。x86 CPU 复位后固定从地址 0xFFF0 的复位向量开始执行，进入 16 位实模式。他用汇编编写复位向量（先 cli 再跳转到 start），并通过 GCC 链接脚本确保该代码位于 64 KB ROM 的 0xFFF0 处；同时梳理了实模式段式寻址与 1 MB 内存布局，明确留给 DOS 的常规空闲内存仅约 605 KB。

为了加快迭代，他用 PicoROM/OneROM 项目（基于 Raspberry Pi Pico 模拟 ROM 芯片）代替反复烧录 EEPROM。通过逆向外部 UART（Toshiba TLC16C552，IO 基址 0x1000）输出调试字符，并配置约 20 个 SC300 寄存器，将 SoC 主频设为 33 MHz。在驱动 LCD 时，由于显存文本缓冲区位于 0xB800 段，而 BIOS 代码运行在 0xF000 段，他使用内联汇编操作 ES 段寄存器实现远地址读写；又因 SC300 无内置字库，他还嵌入了一套 8×8 ASCII 字模（约 22 KB）。

完整的 BIOS 还需要初始化中断向量表（IVT）、BIOS 数据区（BDA）、8254 定时器（使用 1.1892 MHz 时钟分频得到约 18.2 Hz 的 IRQ0）、XT 键盘控制器及 CF 卡接口。CF 卡默认处于 PCMCIA 内存模式，作者利用 SC300 的内存映射系统（MMS）读取 CIS（Card Information Structure）后将其切换为 TrueIDE 模式，随后即可通过标准 ATA IO 端口（0x1F0）以 LBA 方式读写扇区。

为了让 DOS 能够运行，他实现了 INT 10h（视频）、INT 12h（内存容量）、INT 13h（磁盘）、INT 16h（键盘）等关键 BIOS 中断，并梳理了 DOS 启动流程：BIOS 加载 MBR 到 0x7C00 → 加载活动分区引导扇区 → 加载 IO.SYS → 加载 MSDOS.SYS → 加载 COMMAND.COM。尝试启动 MS-DOS 6.22 时，系统虽能显示 "Starting MS-DOS..."，但随后在处理异常的 INT 15h 调用后卡死；期间还因 DOS 重新布置栈而导致冲突，作者通过为 BIOS 中断单独分配高地址栈缓解了部分问题，但参考 MS-DOS 4.0 源码后仍未能解决，最终放弃 MS-DOS 6.22。

随后作者转向 FreeDOS 1.4：在 QEMU 中创建虚拟硬盘安装系统，再用 Rufus 将磁盘镜像逐扇区写入真实 CF 卡。将该卡插入 DDX3216 后，系统成功进入 FreeDOS 命令行，整个项目历时约三周。

文章还介绍了调音台内部的其他硬件：LED 由多级移位寄存器通过 IO 总线（如地址 0x3000）控制，奇偶 LED 分别接 VCC 与 GND，作者给出了点亮 VU 表 LED 的示例代码。设备中的 PIC16 单片机以及通过一次性可编程逻辑器件连接的 Analog Devices SHARC DSP

https://www.bloomberg.com/news/features/2026-06-12/india-s-extreme-heat-is-hurting-its-economy-and-workers

Intel 于 1980 年推出的 8087 浮点协处理器，其所有算术运算（加减乘除、平方根及超越函数）最终都归约到二进制加法，因此芯片心脏是一个 69 位加法器，它位于尾数（significand）数据通路的中央，直接决定整体运算性能。

芯片与数据通路布局
8087 晶粒面积约 5 mm × 6 mm，边缘为金属焊线与 40 个引脚相连。顶部为总线接口单元，负责与 8086 主处理器及内存协调；中央是定义指令的微码 ROM。晶粒下半部为执行运算的数据通路，分为指数数据通路和尾数数据通路，而中央的红色区域即为加法器。若要对指数执行加法，需先将指数复制到尾数数据通路。

加法器架构：分块加速进位
为加速 69 位加法，8087 将进位链切分为 4 位一组。核心挑战是进位传播速度：若等待进位从最低位逐位串行传递，延迟将过大。每个 4 位块采用两种技术并行优化：

• 块内使用 曼彻斯特进位链（Manchester carry chain）；
• 块间使用 进位跳过（carry-skip） 机制。

曼彻斯特进位链
该技术源自 1959 年的 Atlas 计算机，核心概念为 Generate（生成）、Propagate（传播）和 Delete（消灭/杀死）。对两比特及进位输入进行加法时：

• 1+1 产生进位，与低位进位无关；
• 0+0 消灭进位，无论低位是否有进位；
• 0+1 传播进位，进位输出等于进位输入。

这些信号可在所有位并行生成。随后通过开关（NMOS 传输管）构建进位链，使进位以导线中的信号速度传播，而非受逻辑门延迟限制。8087 对电路进行了优化：将 Generate 与 Delete 两种情况合并，利用输入 F 直接置位或清零进位，propagate 则负责把 Cin 传递到 Cout。

进位跳过与 NMOS 预充电
由于 NMOS 传输管每经过一级会损失电压，8087 每 4 位就重置一次“新鲜”进位。同时，若检测到 4 位块内所有位均为 Propagate，则块输出进位等于块输入进位，进位跳过电路直接旁路块内进位链，进一步提速。

8087 采用 NMOS 工艺，其晶体管下拉（到低电平）远快于上拉（到高电平）。因此加法器在最开始时对进位线 预充电（precharge） 至 5 V；信号逻辑取反，使得初始高电平表示“无进位”，需要时再由电路下拉至地表示“有进位”。每个 4 位块的最后一级多路选择器额外接入预充电输入和进位跳过输入，确保时序与块间同步。

位宽与物理实现
虽然 8087 的尾数名义为 64 位，但加法器输入为 69 位、输出为 70 位，原因如下：

• 3 个低位用于 Guard、Round、Sticky 舍入位，确保正确舍入方向；
• B 寄存器值可被加倍（乘法需求），需额外 1 位；
• 减法使用补码表示，需额外 1 位符号位。

输出 70 位经 Sum Shifter 右移两位后裁剪为 68 位，额外的高位由 tmpC 等特殊寄存器和 Skip Shifter 处理。

文章展示了移除金属层后的晶粒照片：水平金属线用于块内互连与尾数总线穿越；左侧粗线为地，右侧为电源；垂直布线为多晶硅与掺杂硅区域，其中多晶硅线被特意加宽以降低电阻、调节时序。

周边寄存器与运算
加法器的两个输入分别来自 尾数总线（F） 和 B 寄存器（B），输出写入 Sum 寄存器。为加速乘法，8087 采用 基-4 Booth 乘法，由 Skip Shifter 每次移位输出两位，据此选择 2B、B、0 或 -B 进入加法器；再由 Sum Shifter 将和右移两位。除法通过重复加减与移位完成，平方根则类似纸笔开方，两者迭代循环均由 硬件直接实现，而非微码控制，从而提升性能。

总结
8087 在晶体管数量受限的条件下，以曼彻斯特进位链配合进位跳过结构，在速度与复杂度之间取得了平衡。尽管后续处理器（如奔腾的 Kogge-Stone 加法器）采用了更宏大、更快速的设计，但 8087 的 69 位加法器在当时已成为其浮点性能的关键枢纽。

《如何赚取十亿美元》是保罗·格雷厄姆（Paul Graham）基于在牛津联盟演讲撰写的文章，旨在解释通过创业合法成为亿万富翁的路径，并反驳“不作弊就不可能赚十亿美元”的观点。

作者以Y Combinator联合创始人的身份指出，创办成功的初创企业是成为亿万富翁最常见的途径。YC自2005年创立以来已资助约6500家公司，其中约30位创始人已成为亿万富翁，还有更多正在成长中。

文章的核心论点是：指数增长让巨额财富的积累在数学上完全可行，且无需依靠欺骗或剥削。作者用两个计算说明了这一点：假设一家公司月增长率为93%，从200万美元起步，只需约9.45个月（即计算 log(500, 1.93)）就能增长500倍，达到十亿美元级别。即便采用更保守的15%月增长率，5年（60个月）后收入也会增长约4384倍（1.15^60）；若创始人目前月收入为1万美元，五年后月收入将达约4400万美元（年收入约5.26亿美元），届时其持股价值足以使其成为亿万富翁。

这种爆发式增长并非来自剥削，而是来自用户口碑驱动的自然扩张。当创始人做出用户极度喜爱的产品时，用户会主动推荐给朋友，从而形成指数级增长。因此，作者每次与创始人见面首先询问增长率，因为这直接反映产品是否真正满足了用户需求。

关于如何找到这样的创业点子，文章提出了几项反直觉的建议：

• 从自己的需求出发：年轻创始人最该为自己和朋友打造产品，因为年轻人的需求往往预示未来的大众需求，是最有价值的需求信号。
• 不要刻意寻找“创业想法”：最好的点子起初听起来往往很糟糕（如苹果、Facebook、Airbnb，以及后来改名Twitch的Justin.TV）。刻意寻找会让人变得保守，过早筛掉那些看似离谱却潜力巨大的机会。
• 和朋友一起做有趣的项目：许多伟大的公司（如苹果、谷歌、Facebook）最初只是出于兴趣的项目，并非一开始就以成立公司为目标。

作者强调，创业成功的关键是对用户的深刻理解与同理心——思考用户真正想要什么，如何让他们的生活显著变好。只要持续让客户满意，指数增长及其带来的财富就会自动发生，根本不需要作弊。

文章最后总结：决定初创企业规模、从而决定创始人财富的有两个数字——增长率和持续增长的时间。前者通过打造好到让用户主动推荐的产品来实现；后者通过身处足够大的市场来实现。在大市场中实现指数增长，公司就会变得极有价值，创始人作为股东也会因此致富。这不仅无需作弊，反而是竭力服务用户的自然回报。