从前慢：两种慢，两种命运
TLDR
AI 消除了工作流里的摩擦，却也悄悄跳过了成长路上的必经之路。GitHub Copilot 改计费只是一个信号：不是所有的慢都该变快。
一个计费变更引发的思考
2026 年 6 月 1 日，GitHub Copilot 改了计费规则。
原来按「请求次数」收费，一次快速的问答和一次跑了一个小时的 agentic 任务，算同样的价钱。现在改成按 token 实际消耗计费，单位叫 GitHub AI Credits——模型越贵、跑得越久，花得越多。
订阅价格没变，但这两天微信群和技术群里吐槽声不断。
有人发现自己平时的用法，在新计费模式下账单会翻好几倍。有人的 credits 一天半就跑完了，只能切回质量差一档的模型继续干活。还有人感叹：「由奢入俭难。」
更有意思的是另一种声音：「要学会高效利用。」
这句话听起来是个建议，但仔细想想，它本身就是一种新的摩擦——以前用 AI 根本不需要想这件事，现在要专门腾出精力，研究怎么「用得更省」。AI 本来是来消除摩擦的，结果自己又制造了一种新的中间成本。
这让我想到一个更大的问题：AI 在重新定价的，到底是什么？
第一种慢——系统的包袱
先说工作流。
一个典型的工程工作流，往往不是在单一系统里完成的。需求在 Jira，代码在 GitHub，部署在 Jenkins，监控在 Grafana，文档在 Confluence，通知在飞书。每个系统有自己的 API、自己的数据格式、自己的交互方式。
从输入 A 到输出 F，中间要经过 B、C、D、E——每一步都是一次格式转换、一次系统切换、一次手动搬运。这些中间步骤从来都不是有价值的东西，它们只是历史遗留的混乱，是各个系统在不同年代、由不同团队搭建时留下的缝隙。
AI 特别擅长处理这类问题。输入是非结构化的、各系统格式和接口五花八门、多平台之间摩擦不断——这正是 AI 的主场。你把需求描述丢给它，它帮你生成 Jira ticket、起草 PR description、更新文档、发飞书通知。B、C、D、E 被直接消化掉，你从 A 直达 F。
这种「消除」是真正的效率提升，没有损失。那些中间步骤本来就不应该存在，或者说，它们存在只是因为我们以前没有更好的工具来处理系统间的混乱。AI 补上了这个缺口，是好事。
但这里有一个值得注意的 trade-off。传统做法是花一次工程成本开发 adapter 或 ETL，之后就几乎不用再追加投入。用 AI 处理则反过来：前期几乎零成本，但每次执行都在消耗 token，原本的「一次性成本」变成了「按次叠加的 API 账单」。
当 token 被补贴的时候，AI 路显然更香。但 Copilot 改计费这件事，恰好说明补贴正在结束——这个 trade-off 的天平开始重新倾斜。工作流里的摩擦，该消除，但消除的代价正在被真实定价。这是第一种慢：它的存在本来就是一个错误，只是以前我们付出的代价还不够显眼。
第二种慢——成长的密度
也是慢，但性质完全不同。
再说工程师的成长。
一个初级工程师成长为资深工程师或架构师，中间要经历的事情大致是：学会一门语言、啃透一个框架的文档、在调试一个诡异 bug 上花掉两天、在一次生产事故里被教训、在无数次 code review 里被指出自己没想到的问题。这些经历加在一起，慢慢沉淀出一种东西——判断力。
判断力不是知识。知识可以被检索，可以被生成，可以被 AI 即时提供。但「这个地方有坑，我以前掉进去过」「这个方案看起来行，但规模一上去就会出问题」——这类直觉，只能从真实的摩擦里长出来。
AI 的出现，让初级工程师可以跳过大量的 B、C、D、E，直接产出看起来像 F 的结果。借助 AI，他能写出可以运行的代码，能解释一个复杂的架构设计，能给出一份像模像样的技术方案。从外部看，这个人好像已经到了 F。
但判断力没有跟着到 F。
当 AI 给出一个答案的时候，他没有能力判断这个答案在什么情况下是错的。当系统出了一个 AI 解决不了的问题，他没有那个「我以前见过类似的」的直觉可以调用。他跳过了那些「慢」的时刻，也跳过了那些时刻本来会留下的东西。
这不是 AI 的错，也不是工程师的错。只是，第二种慢和第一种慢，是完全不同的东西。第一种慢是噪音，第二种慢是信号。
从前慢
木心有一首诗，叫《从前慢》。
记得早先少年时 大家诚诚恳恳 说一句 是一句
清早上火车站 长街黑暗无行人 卖豆浆的小店冒着热气
从前的日色变得慢 车，马，邮件都慢 一生只够爱一个人
从前的锁也好看 钥匙精美有样子 你锁了 人家就懂了
很多人喜欢这首诗，但喜欢的方式不太一样。有人喜欢的是那种慢的氛围，怀旧，温情。但我觉得这首诗真正说的，是慢带来的深度。
「一生只够爱一个人」——不是因为那个年代的人更专情，而是因为慢，让每一件事都有了足够的重量。写一封信要三天，这三天里你把想说的话翻来覆去地想清楚了。等一封回信要一个月，这一个月里那段关系在你心里慢慢发酵。慢不是缺陷，慢是深度的来源。
对工程师的成长来说，道理是一样的。
一个 bug 追了两天，那两天里你把整个系统的运作方式装进了脑子。一份烂文档啃了一周，那一周里你对这个框架的设计哲学有了真实的感知。一次生产事故处理完，你对「什么叫系统在极端情况下的行为」有了切身的理解——不是看了一篇文章之后的理解，是手抖过之后的理解。
这些慢的时刻，不是低效，是学习真正发生的地方。
现在这些时刻正在被快速跳过。不是因为有人决定跳过，只是因为工具太顺手了，慢下来反而显得奇怪。就像从前写信，现在发消息——没有人规定你不能写长信，但你自然而然地就不写了。
两种账单
GitHub Copilot 改计费之后，有一个功能很有意思：billing preview。你可以看到自己上个月的用量，在新计费模式下会花多少钱。有人打开一看，数字让他倒吸一口凉气。
这张账单是可见的。有 dashboard，有数字，有超出预期时的提醒。你知道自己用了多少，花了多少，还剩多少。
成长的账单不一样。
一个靠 AI 跳过了大量积累过程的工程师，他的「透支」不会显示在任何 dashboard 上。没有通知说「你的判断力余额不足」，没有月底的账单提醒你「本月跳过了 47 次应该自己想清楚的问题」。一切看起来都很正常，甚至很顺利——代码在跑，需求在交付，绩效也不差。
账单要晚几年才来。
来的时候，往往是在一个 AI 帮不上忙的关键时刻：一个诡异的线上问题，需要你凭直觉判断从哪里下手；一个架构决策，没有标准答案，需要你从过去的经验里提炼出自己的判断；一次技术面试，考官问的不是「这个问题怎么解」，而是「你当时为什么这么决策」。
这时候才会发现，那些被跳过的 B、C、D、E，它们留下的不只是结果，还有一种叫做「我真的懂了」的东西。而那个东西，没有办法补课。
我们需要做的区分
AI 不做这个区分。
它不知道你现在需要的是一个答案，还是需要自己找到答案的过程。它只知道你问了什么，然后尽力给出最好的回应。它本来就是这么工作的。
区分的责任，在人。
工作流里的第一种慢，能自动化的就自动化，能消除的就消除。那些系统间的摩擦、格式转换、重复的手工操作——让 AI 去处理，你去做真正需要判断力的事。这是 AI 最该做的事，也是它做得最好的事。
但成长里的第二种慢，得自己主动留着。不是所有问题都应该先问 AI。有些问题，值得先自己想二十分钟，哪怕最后得出的答案和 AI 给的一样。那二十分钟不是浪费，是你在给自己的判断力充值。
这不是在反对用 AI，也不是在鼓吹刻意的低效。而是说：工具的边界，需要使用工具的人来划定。
GitHub Copilot 改计费，让开发者开始重新审视自己的用量——哪些调用是真正必要的，哪些只是因为顺手。这种审视本身是好事。而同样的问题，也值得问在成长这件事上：哪些时候真的需要 AI 给答案，哪些时候其实应该先自己想一想。
从前慢，是因为没有更快的选择。现在我们有了，但「可以快」和「应该快」之间，还有一段值得停下来想想的距离。
第一种慢，交给 AI。第二种慢，留给自己。
