# 当速度开始改变探索 AI 缩短了想法接触现实的距离，也让生成开始快过经验。当生产不再等待观察，速度带来的可能不是探索，而是同一种东西的高速繁殖。 ## Metadata - HTML: https://glenzli.com/notes/speed-matters/ - Markdown: https://glenzli.com/notes/speed-matters.md - Collection: Notes - Language: zh-CN - Published: 2026-07-25 - Updated: 2026-08-17 - Tags: ai, speed, exploration, judgment, software-engineering ## Content 最近，因为一个很具体的麻烦，我开始做自己的 Lightroom 替代工具。 在中国区续订 Lightroom，依然相当繁琐。与此同时，AI 和新一代图像工具不断出现，Adobe 的订阅套餐对我的吸引力也越来越低。 真正让我动手的，还是多年使用里反复遇到的别扭。许多操作要绕好几步，有些功能看起来什么都有，真到工作里却总差一点；一些期待已久的能力始终没有出现，一套处理流程下来，还得在几个软件之间来回切换。 我不打算完整复刻一个自己的 Lightroom。更想做的是，把这些长期积累的痛点放在一起重新想一遍，做一个贴合自己工作方式，也真正用上今天这些技术的工具。 三天左右，代码接近十二万行，基本功能已经可以使用，GPU 管线也已经打通。中间还做过一次结构性重构，因为最初的方向并不完全合适。 十二万行不等于十二万行价值。三天做出的东西，也不能和成熟产品多年积累的可靠性相比。 真正不同的是，功能实现、真实运行和结构调整，已经能在三天里发生在同一个反馈循环中。 过去，即使有上百人的团队，也很难把循环压得这么短。限制团队的不只是写代码，还有分工、沟通、排期，以及每次改变方向带来的协调成本。 现在，一个原本需要长期立项的方向，可以先被做出来，再用真实结果判断是否值得继续。 速度改变的已经不只是开发效率。 它开始改变想法进入现实的方式。 ## 慢速时代 过去有一个软件想法，通常要先回答一串问题。 需要多少人？要做多久？预算够不够？值得占用几个月吗？架构怎么设计？哪些功能必须先做，哪些只能放弃？ 这些问题都合理，因为实现很贵。 一个方向即使不错，也可能只能停留在讨论里。不是它没有价值，而是验证成本太高。许多探索还没开始，就已经被排期、资源和机会成本筛掉。 所以，传统开发倾向把判断放在前面。需求要明确，设计要周全，架构最好提前稳定。后面的每次修改都可能影响很多人，走错方向的代价也不只是废弃几段代码。 这种工作方式不会消失。 但它依赖的一个前提正在松动：实践必须很慢。 ## 实践赶上思考 如果一个概念一天内就能成为可运行的东西，很多判断便不必只靠想象。 一种交互是否顺手，一套照片管理方式能否长期使用，一个渲染管线有没有实际价值，一种工作流是不是只在纸面上优雅，都可以更早碰到真实文件、真实设备和真实操作。 过去，这些证据来得很慢。现在，AI 可以把模糊目标迅速推到可运行状态：补齐界面和数据结构，接入图像管线，处理错误，发现方向不对以后再调整模块边界。 人不必事先规定所有步骤，却要在过程中不断判断：哪些结果符合目的，哪些问题暴露了错误假设，哪些修改值得保留，哪些方向应该结束。 判断没有消失，也不只是被推迟到实现以后。 它从一次性的事前决定，变成了贯穿实践的连续选择。 软件开发因此更像实验：先让一个判断碰到现实，再根据结果决定下一步。 ## 世界没有一起加速 还可以设想一种更极端的情况。 如果足够强的执行模型被固化进硬件，吞吐率达到每秒十万 token，读代码、修改实现、运行测试、分析错误和重新生成方案，可能会形成接近连续的循环。 重要的不是十万这个数字。是等待时间跨过某个界限以后，人会换一种工作方式。 一次修改需要几周，人会尽量避免修改。 只需要几分钟，人会自然比较更多方案，允许几套架构暂时并存，也更容易推翻已经证明不合适的结构。 重构不必总是一项专门立项的工程，也可以成为思考中的普通动作。架构的意义随之变化：它不再负责证明最初判断永远正确，而要让系统能够承受判断变化。 但是，token 的速度不等于现实的速度。 编译需要时间，GPU 任务需要时间，导入大量原始照片需要时间。色彩是否可靠，工作流能否长期使用，软件会不会在边缘条件下崩溃，也必须交给真实环境。 模型可以更快给出方案，世界却没有以同样的速度提供证据。 问题就藏在这两种速度之间。 ## 进展的幻觉 AI 擅长加快向内生成。 它可以从已有代码、产品和知识中，生成更多方案、更多实现和更多组合。但认识世界还要向外获得经验，而经验通常慢得多。 真正的新想法，可能来自长期使用的不满、一次偶然观察、某个技术限制，或者和他人协作时反复出现的摩擦。这些东西不会因为 token 吐得更快就自动增加。 当生成速度超过经验输入，系统就开始消费自己生产的东西。 仓库不断增长，页面不断增加，功能接连发布。看起来一切都在前进。但产出数量和认识进展不是一回事。系统可以持续增加功能，却没有更接近真实问题；一个人也可以连续实现十个想法，却没有认真使用其中任何一个。 速度制造出一种繁荣的表象。 今天的互联网软件已经有这种味道。大量产品使用相似的界面、工作流、商业模式和产品语言。新工具不断出现，许多只是在已有结构外换一层包装，再把同样的逻辑复制到另一个细分领域。 AI 让复制更便宜。 给模型一个模糊的软件目标，它很容易生成熟悉的卡片布局、账户体系、后台管理和 AI 入口。结果结构完整，也确实能运行，但里面未必有新的观察。 成品开始互相充当需求文档，竞品逐渐变成想象力的边界。整个行业看似高速迭代，实际上可能只是同一种东西在彼此复制和繁殖。 ## 生产开始索取想法 人的想法不是取之不尽的任务列表。 真实想法需要生活、观察和使用来补充。如果一个功能几小时就能完成，而新经验仍需要几天、几个月甚至几年，生产迟早会超过想法的生长速度。 最初的问题解决以后，执行能力不会自动停下来。 为了维持速度，人们会继续加功能、找方向、制造下一项任务。产品不再因为发现新问题而变化，而是因为开发不能停，所以必须不断生产可以开发的东西。 这时，速度不再服务探索。 探索反过来开始服务速度。 团队观察同行刚发布什么，个人要求模型再生成几个方向，产品因为能够增加功能而增加功能。每一轮都有新产出，却没有新经验进入系统。 想法就在这种节奏里迅速枯竭。 不是人突然失去创造力。是观察和思考还没来得及发生，下一轮生产已经开始了。 ## 判断不是刹车 判断力不能被理解成谨慎或保守。 它不是站在高速执行面前，不停要求减速。它决定哪些事情值得加速，哪些结果值得保留，什么时候继续，什么时候必须回到现实里等待证据。 速度越快，放弃错误方向的成本越低。与此同时，进入错误方向的次数也会更多。 没有判断，系统可以高效构建不重要的东西，迅速修复一个原本就不该存在的功能，也可以围绕错误假设搭起越来越完整的架构。 代码规模、界面完成度和功能数量，很容易让人误以为自己已经理解问题。 判断要分辨什么是新证据，什么只是新排列；什么解决了真实摩擦，什么只是沿用行业习惯；什么应该沉淀成长期系统，什么回答一次问题以后就可以删除。 速度扩大选择，判断决定这些选择能否产生意义。 ## 方法成为坐标 需求分析、架构设计、测试、评审和版本管理，不会因为执行变快而失去意义。当系统能迅速产生大量实现，它们反而要承担更多筛选和记录。 需求不只说明做什么，还要保存这件事为什么值得存在。 架构不只服务长期开发，也要允许系统在证据变化以后重新组织。 测试不只证明代码按预期运行，还要防止产品在连续修改中慢慢偏离最初的问题。 评审也不只检查实现质量，还要判断一项功能是否应该进入产品。 过去，这些方法常被放在昂贵实现之前，用来降低走错方向的风险。以后，它们会散布在高速实践的整个过程里，保存证据、识别偏离，并结束没有价值的方向。 传统方法没有消失。它们从开发前的关卡，变成了探索中的坐标。 软件本身也会成为探索记录。它记录哪些判断被尝试，哪些路径失败，哪些功能在真实使用中留下，哪些抽象后来被证明没有必要。 一个个人工具不必先证明自己可以成为产品。它可以从具体问题开始，在持续使用中长出稳定结构。 但快速生成的东西，也不能因为已经存在，就自动获得继续存在的理由。 有些软件会稳定下来，承担测试、文档、迁移和维护承诺。有些只服务一次实验，回答问题以后便可以结束。 生产越容易，删除功能、放弃方向和结束项目，反而越重要。 ## 速度不能代替探索 当一个概念可以在一天内被实践，人探索世界的方式一定会变化。 研究问题可以迅速变成模拟、数据处理和可视化。一种工作习惯不必继续忍受现有软件的限制，也可以长成自己的工具。一个很小、很私人的需求，也值得认真尝试，因为它不再需要先证明自己有足够大的市场。 但可以很快做出来，不等于应该全部做出来。 如果速度只是把已有模式复制到更多地方，它带来的不是探索，而是同一性的扩张。如果人没有时间使用、观察和形成新经验，再快的执行也只能反复消费旧想法。 速度真正有价值的地方，是缩短一个判断接触现实的距离。 它让人更快知道一件事是否成立，也让错误方向更容易被放弃。 重要的不是始终维持高速，而是拥有速度以后，仍然知道什么时候行动，什么时候观察，什么时候等待，什么时候停下来。 速度会改变探索。 判断决定其中能不能产生新的东西。 ## 相关材料 - [实现不再稀缺之后](https://glenzli.com/notes/when-implementation-is-no-longer-scarce) - [AI 时代的软件开发变迁](https://glenzli.com/notes/software-cognition-in-ai-era) - [当软件的时间开始松动](https://glenzli.com/notes/software-time-loosens) - [AI Software Engineering Notes](https://github.com/glenzli/ai-software-engineering-notes)