# 当速度开始改变探索 当一个概念可以在一天内被实践，速度改变的不只是开发效率，也会改变判断、实验和认识世界的方式。但当生成快过经验，速度同样会制造进展幻觉，让探索退化为复制。 ## 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-07-25 - Tags: ai, speed, exploration, judgment, software-engineering ## Content 最近，因为一个很具体的麻烦，我开始做自己的 Lightroom 替代工具。 在中国区，续订 Lightroom 依然是一件相当繁琐的事。与此同时，随着 AI 和新一代图像工具不断发展，Adobe 的订阅套餐对我的吸引力也越来越低。 真正让我决定动手的，还是多年使用中反复遇到的那些别扭之处。许多操作至今仍要绕上好几步，有些功能看起来什么都有，真到了工作里却总差一点；一些我期待已久的功能，也始终没有出现。一套处理流程走下来，常常还得在几个软件之间来回切换。 我并不打算完整复刻一个属于自己的 Lightroom。更想做的是把这些长期积累的痛点放在一起重新思考，做一个更贴合自己的工作方式，也能真正用上今天这些新技术的工具。 三天左右，代码接近十二万行，基本功能已经可以使用，GPU 管线也已经打通。中间还发生过一次结构性的重构，因为最初的设计方向并不完全合适。 十二万行代码当然不等于十二万行价值，三天完成的东西也不能和成熟产品多年积累的可靠性相提并论。真正值得注意的是，功能实现、真实运行和结构调整，已经可以在三天里发生在同一个反馈循环中。 过去，即使有上百人的团队，也很难把这个循环压缩到如此短的时间。限制团队的未必是写代码的速度，还有分工、沟通、排期，以及每次方向变化带来的协调成本。 现在，一个原本需要长期立项的方向，可以先被做出来，再用真实结果判断是否值得继续。 速度改变的已经不只是开发效率。 它开始改变想法进入现实的方式。 ## 慢速时代的开发方式 过去有一个软件想法，通常要先回答一连串问题。 它需要多少人？要做多久？预算是否足够？值得占用几个月吗？架构怎么设计？哪些功能必须先做，哪些只能暂时放弃？ 这些问题都很合理，因为实现很贵。 一个方向即使看起来不错，也可能只能停留在讨论里。并非它没有价值，而是验证它的成本太高。许多探索在真正开始以前，就已经被排期、资源和机会成本筛掉了。 因此，传统的软件开发倾向于把判断放在前面。需求要尽量明确，设计要尽量周全，架构最好提前稳定下来。后面的每次修改都可能影响多人，走错方向的代价也远不止废弃几段代码。 这种工作方式不会消失，但它依赖的一个前提正在松动：实践必须很慢。 ## 实践开始赶上思考 如果一个概念可以在一天内成为可运行的东西，很多判断便不必只靠想象完成。 一种交互是否顺手，一套照片管理方式能否长期使用，一个渲染管线有没有实际价值，一种工作流是不是只在纸面上优雅，都可以更早接触真实文件、真实设备和真实操作。 过去，这些证据来得很慢。现在，AI 可以把一个模糊目标迅速推到可运行状态。它会补齐界面和数据结构，接入图像处理管线，处理错误，也会在发现问题以后重新调整模块边界。 人不需要事先规定所有步骤，但仍然需要在过程中不断判断。哪些结果符合原来的目的，哪些问题暴露了错误的假设，哪些修改值得保留，哪些方向应该及时结束。 判断没有消失，也不只是被推迟到实现以后。它从一次性的事前决定，变成了贯穿实践过程的连续选择。 软件开发也因此更像实验：先让一个判断与现实接触，再根据结果修正下一步。 ## 当反馈循环接近连续 还可以设想一种更极端的情况。 如果足够强的执行模型被固化进硬件，吞吐率达到每秒十万 token，读代码、修改实现、运行测试、分析错误和重新生成方案，可能会形成接近连续的循环。 这里真正重要的并不是十万这个数字，而是等待时间跨过某个界限以后，人会开始采用不同的工作方式。 当一次修改需要几周，人会尽量避免修改。 当它只需要几分钟，人会自然地比较更多方案，允许几套架构暂时并存，也更容易推翻已经证明不合适的结构。 重构不再总是一项需要专门立项的工程，也可以成为思考过程中的正常动作。架构的意义随之发生变化：它不再负责证明最初的判断永远正确，而要让系统能够承受判断的变化。 但 token 的速度并不等于现实的速度。 编译需要时间，GPU 任务需要时间，导入大量原始照片需要时间。色彩是否可靠，工作流能否长期使用，软件会不会在边缘条件下崩溃，也必须通过真实环境才能知道。 模型可以更快地给出方案，世界却没有以同样的速度提供证据。 这两种速度之间的差距，会成为下一个问题。 ## 速度制造的进展幻觉 AI 擅长加快向内生成的过程。 它可以从已有代码、产品和知识中生成更多方案、更多实现和更多组合。但认识世界还需要向外获得经验，而经验的形成通常慢得多。 新的想法可能来自长期使用中的不满，来自一次偶然观察，来自技术限制，也可能来自和他人协作时反复出现的摩擦。这些东西无法仅靠提高吞吐率获得。 当生成速度超过经验输入，系统就会开始消费自己已经生产出来的东西。 仓库不断增长，页面不断增加，功能接连发布，看起来一切都在迅速向前。但产出的数量和认识的进展并不是同一件事。一个系统可以持续增加功能，却没有更加接近真实问题；一个人也可以连续实现十个想法，却没有认真使用其中任何一个。 速度由此制造出一种繁荣的表象。 这种现象在今天的互联网软件行业已经相当明显。大量产品采用相似的界面、工作流、商业模式和产品语言。新的工具不断出现，许多却只是在已有结构外面更换包装，再把同样的逻辑复制到另一个细分领域。 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)