当AI让一切变“快”之后：我们是否还愿意做“难”的事？

一、一个值得警惕的反常现象

在AI辅助编程日益普及的今天，我观察到一类值得深思的开发者群体。

他们工程经验一般，但借助Copilot、ChatGPT等工具，能够快速完成从前难以独立实现的小型项目——一个爬虫、一个聊天机器人、一个数据看板。他们的能力边界被AI极大地拓展了，甚至发出“竟然能完成以前想都不敢想难度的项目”的感叹。这听起来像是技术进步的理想图景。

但与之相伴的，是另一个令人不安的事实：他们几乎不再启动需要持续投入数周甚至数月的高复杂度项目。

他们沉迷于短平快的开发节奏——两三天出一个Demo，一周发布一个小工具，然后迅速转向下一个“有趣”的点子。长周期项目的规划、架构、迭代、调试、重构，这些需要耐心与深度专注的工作，在他们身上逐渐消失了。

这不是个别现象。在短视频与AI共同塑造的时代认知环境下，开发者的行为模式正在发生深层迁移。而这种迁移，可能比“AI取代工作”更隐蔽，也更危险。

二、追根溯源：为什么短平快如此诱人？

要理解这一现象，不能简单归咎于“开发者变懒了”。背后存在三重结构性推力。

1. 短视频重塑了认知耐心阈值

短视频的底层逻辑是高频、低延迟、强刺激反馈。长期浸泡其中，人的注意力持续时间被系统性压缩。软件开发恰恰是反其道而行之的——它需要长时间的专注、延迟满足、以及忍受调试期的低反馈。当大脑习惯了每15秒获得一次新鲜刺激，面对一个三天都跑不通的编译错误，本能反应不是迎难而上，而是转向下一个“更快出成果”的项目。

2. AI降低了入门门槛，也降低了坚持的动力

过去，攻克一个复杂项目需要大量前期积累。开发者会因为“已经投入了很多时间”而更加珍惜项目、坚持到底。AI的出现改变了这一点：启动一个新项目的成本极低，放弃的成本也极低。当“重新开始”比“继续啃硬骨头”更容易时，理性选择往往指向前者。

3. 社交反馈机制的扭曲

GitHub上的星标、社交媒体的点赞、社区里的“快速产出”人设，都在奖励短平快。一个三天完成的有趣小工具，远比一个三个月打磨的重构项目更容易获得即时正反馈。开发者的成就感被外部评价体系驯化，逐渐从“我解决了一个复杂问题”转向“我又产出了一个可展示的东西”。

三、短平快陷阱的核心危害：不是慢，而是浅

有人会说：能做小项目也不错，总比什么都不做强。但这种观点忽略了问题的本质——短平快模式伤害的不是开发速度，而是认知深度。

• 架构能力无法在小项目中生长：高复杂度项目迫使开发者思考模块划分、接口设计、错误处理、可扩展性。这些能力在小项目中根本遇不到。
• 调试能力被AI遮蔽：当AI生成大部分代码，开发者遇到错误的第一反应不是分析根因，而是“重新问一下AI”。长此以往，真正的排错能力不增反降。
• 项目韧性不被训练：任何有实际价值的中大型项目，都会经历“最无聊的中段”——新鲜感已过，离完成尚远，处处是坑。能否扛过这个阶段，决定了能否做出真正有价值的成果。短平快模式恰恰绕过了这个最宝贵的训练场。

一句话：短平快让你“会做很多事”，但不会“做难的事”。而在工程领域，真正的稀缺能力恰恰是后者。

四、AI不是问题的制造者，而是放大器

需要澄清的是：AI本身不是短平快陷阱的根源。根源在于使用者的习惯与时代环境的塑造。但AI确实在放大这一问题。

在没有AI的时代，一个开发者想做小项目也没那么快，往往被迫投入更长的时间，反而在过程中获得了额外的成长。AI把“快速产出”的门槛降到极低，也就把“是否选择做难事”这一决定，完全交到了个人的自律与认知上。

同时，AI提供了一种虚假的完成感。当一个AI辅助完成的项目跑通时，开发者很容易高估自己的贡献，低估其中省略掉的思考环节。这种“被赋能”的幻觉，进一步削弱了挑战高复杂度项目的内在动机。

五、应对策略：如何在快时代保留做“难事”的能力？

面对这一困境，个人、教育者与团队都需要有意识的应对。以下是具体可行的策略。

1. 个人层面：建立“反脆弱”的开发习惯

• 主动设置长周期项目：每半年选择一个至少需要持续6周的核心项目，禁止中途切换。可以是重构一个开源项目、从零实现一个迷你数据库、或构建一个完整的全栈应用。
• 区分“探索模式”与“深耕模式”：用小项目快速试错、用大项目深度积累。两者不矛盾，但不能让前者吞噬后者。
• 刻意练习无AI时段：在复杂逻辑设计、架构决策、关键算法实现时，刻意关闭AI，强制自己完成深度思考。AI应该用来加速执行，而不是替代判断。

2. 教育层面：重新设计课程与评价体系

• 增加长周期项目制课程：不是两周的课程作业，而是贯穿整个学期、需要持续迭代的真实项目。考核不仅看最终产出，也看过程文档、架构演进、问题解决记录。
• 限制AI的“无差别使用”：在基础阶段明确划分“AI可用区”与“AI禁用区”。例如，语法查询和样板代码允许AI辅助，但核心算法设计和系统架构必须手写完成。
• 训练项目韧性：刻意在课程中设置“困难中段”——在学生最想放弃的时候提供结构化支持，而不是降低难度。帮助他们体验“熬过去之后的突破感”。

3. 团队与行业层面：创造支持深度工作的环境

• 保护大块专注时间：团队应避免用即时消息、频繁会议切割开发者的时间。可以设立“无打扰编码时段”。
• 奖励复杂问题的解决：在技术评审、晋升评价中，给予高复杂度项目与长期投入以更高的权重，而非只看产出数量。
• 建立长周期项目社区：鼓励开发者分享“做难事的经验”——包括失败、卡壳、中途想放弃的时刻。让长周期项目不再是一个人的孤独战斗。

六、结语：快是能力，慢是选择

短视频和AI时代给了我们前所未有的“快”——快速获取信息、快速验证想法、快速产出成果。这是一种巨大的能力提升，不该被否定。

但真正的危险在于：当我们习惯了快，就可能永远失去做慢事的能力。

对于开发者而言，快的能力可以让你在短期内看起来很高效，但只有做难事、做长周期项目的能力，才能支撑你走得更远、站得更高。架构师不是靠写一万个小工具练成的，而是靠扛过无数次长周期项目的重压下磨出来的。

AI让一切变快了，但选择做什么、选择投入多久、选择在哪个坡道上坚持，仍然是人类开发者必须自己回答的问题。

快是能力，慢是选择。而选择做难事，恰恰是这个时代最稀缺、也最有价值的品质。