你有没有发现自从习惯了用 AI 辅助编程之后自己手写一个完整模块的机会反而越来越少我最近在梳理团队的后端项目时注意到一个很有意思的现象需求的交付速度明显提高了但部分同学对代码的“掌控感”却在下降。尤其是当并发容器、线程池、缓存策略这些细节都被 AI 自动补全之后写代码本身似乎变成了一件“只要会描述需求就能完成”的事。这让我开始认真思考一个问题LLM 辅助编程普及之后开发者的基本功是否正在悄悄退化这种现象在英文技术社区里有一个很形象的词叫 Programmatic Stagnation。这篇文章就来完整拆解这个概念并结合实际工程经验聊聊如何避免被 AI 工具“喂养”成一名只会提需求的开发。本文面向所有日常使用 LLM 辅助编程的开发者包括后端、前端、测试和刚入行的新人。读完你会理解 Programmatic Stagnation 的本质、成因能对照检查自己是否已经出现停滞信号并且拿到一套可以立刻落地的对抗方案其中包含提示词设计、代码重构示例、单元测试验证、安全边界意识等完整内容。1. 什么是 Programmatic StagnationLLM 时代的新停滞现象1.1 从“写更多代码”到“让 AI 写代码”过去十几年开发者的核心能力评判标准始终离不开“写代码”。刷 LeetCode、读源码、维护开源项目本质上都是在训练一种把复杂问题拆解成代码结构的能力。但 2023 年之后以 GitHub Copilot、ChatGPT、Claude Code、Cline 为代表的 LLM 编码工具大规模进入日常工作编程活动本身发生了肉眼可见的变化。以前你写一个订单超时关闭功能需要自己设计定时任务、考虑分布式锁、处理分页扫描、设计补偿机制每一步都要想清楚。现在你在 IDE 里输入一个注释或方法名AI 就能把整段逻辑补全。这个变化带来的效率提升是巨大的但它也悄悄改变了“能力积累”的路径。过去能力是在“写错 - 调试 - 理解 - 再写”的循环中建立的。现在很多人的循环变成了“描述 - 生成 - 复制 - 下一个需求”。前者建立的是对系统的深层理解后者建立的只是对工具的熟练操作。1.2 编程停滞的定义与典型表现Programmatic Stagnation 可以直译为“程序化停滞”在本文语境里我把它定义为开发者在技术能力成长上进入平台期——每天能产出大量代码但底层能力数据结构与算法、设计模式、并发思维、调试推理、架构权衡长期没有进步甚至出现倒退的现象。它的核心特征是“任务完成率上升能力成长率下降”。典型表现通常包括这么几种遇到编译错误不再先读堆栈而是直接把报错信息粘贴给 AI等待它给出修复方案对 AI 生成的代码缺少审辨能力只要测试通过就默认它是正确的被要求画系统架构图或解释某个模块的调用链时只能提供 AI 给出的描述自己讲不清楚为什么这样设计独立写一个稍微复杂的算法时明显感觉到思维卡顿甚至需要依赖 AI 补全每步逻辑代码量看起来很多但真正属于自己的设计决策很少更多时候只是在“装配”AI 输出的零件。这些表现有一个共同点不是能力彻底消失而是能力的形成机制被切断了。就像健身时如果长期有人替你发力肌肉虽然还在但已经无法独立完成大重量动作。1.3 为什么现在要重视这个问题有人可能会说“只要 AI 能一直帮我写代码我为什么要自己会写”这个问题在短期看似乎成立但在真实工程环境中站不住脚。第一AI 生成的代码需要被审查和纠错如果开发者自己对目标领域没有足够的理解根本无法判断生成结果是否正确。第二越复杂的系统越依赖设计决策而这些决策恰恰是 AI 最不擅长、也最需要人来负责的部分。第三当 AI 工具出现故障、生成内容明显离谱时最终承担责任并修复问题的人还是你。换句话说LLM 把“编写代码”的门槛降低了但没有把“对代码负责”的门槛降低。如果开发者放弃了能力积累只保留了对工具的依赖那么在遇到新问题、老系统维护、性能瓶颈排查这些场景时停滞感就会非常明显。这也是为什么“LLM 辅助”的正确姿势应该是让工具扩展能力而不是替代能力。2. 编程停滞是如何形成的2.1 思考起点从零变成了补全结果在没有 LLM 辅助的时代开发过程通常是先理解需求再拆解模块然后从空白文件开始写第一行代码。每一步都需要大量的上下文记忆和逻辑推演你的大脑必须持续保持对全局的掌控。使用 LLM 之后思考起点发生了改变。你不再从零开始设计而是先让 AI 生成一个“候选答案”自己再在它基础上修改。这个过程把“构造性思维”偷换成了“评价性思维”。举个例子当 AI 生成一段基于 CompletableFuture 的并发代码时开发者如果本身没有认真学过异步编程模型大概率只会看“结果对不对”而看不出“这里没有设置线程池拒绝策略”“这里异常处理链路是断的”这类深层问题。评价级思维长期替代构造级思维的结果就是底层知识树越来越稀疏。2.2 角色从构造者变成审查者工程团队中有一个说法写代码的人应该对代码拥有“所有权感”。在传统模式下代码是你自己写的每一行都包含你的推理和取舍所以你对它有天然的责任感。而当代码变成 AI 生成的“外部输入”时开发者容易变成流水线上只管送入和送出的操作员失去对产品的内部结构感。这种角色变化在代码审查中表现得尤其明显。过去 review 别人的代码时你能很自然地指出“这里的锁粒度太大了”“这个缓存没有考虑击穿问题”因为这些知识是你自己踩坑踩出来的。现在当你面对 AI 生成的代码时如果你的知识结构不完整review 就变成形式主义的“看着没问题”——可你根本不知道问题藏在哪个角落。审查者角色本身没有错但你必须先有能力成为一个合格的“审查者”而这份能力恰恰来自你自己扎实写过、调过、优化过代码。2.3 即时反馈缩短了试错学习的机会学习一项技术的深度往往是在“试错”中获得的。你写了一个并发程序出现死锁你通过排查线程转储找到原因这个过程中的收获比读十篇教程都要大。LLM 辅助工具改变了这条学习路径。它的最大特点就是“即时反馈”——报错可以立刻粘贴代码可以立刻生成方案可以立刻给答案。这种模式在解决具体问题时效率极高但它剥夺了“试错-反思-总结”的闭环。当你不再需要为每一次失败花时间时也就不再有机会去深入理解失败背后的机制。这也是为什么不少使用 AI 编程的新人会出现一种奇怪的状态能快速完成任务但问起原理却一无所知。知识像是悬浮在半空中没有扎到自己的经验土壤里。2.4 知识获取方式从检索变成生成过去遇到不懂的知识点开发者的习惯是去搜索引擎查文档、翻官方 issue、看社区讨论这个过程虽然慢但会形成完整的上下文。现在很多人已经习惯直接问 AI“帮我解释一下 Redis 分布式锁怎么实现。”AI 会给出一个工整的答案但这份答案是否准确、是否过时、是否忽略了边界条件需要读者自己判断。问题在于一个对分布式锁没有基础认知的开发者根本无法判断这份答案的完整度。于是“看起来明白了”代替了“真正明白了”。这种知识获取方式如果长期占据主导你的知识体系会变得非常扁平——知道很多名词但无法把它们连接成可用的系统。3. 判断自己是否进入停滞状态3.1 需要警惕的七个信号如果你不确定自己是否已经出现编程停滞可以先对照下面这张信号清单逐条检查信号典型场景停滞程度不读报错堆栈看到 Exception 直接复制给 AI明显从不重构生成代码AI 给什么用什么能跑就行明显无法解释设计理由只会说“AI 是这么生成的”明显离开补全写不出来手写一个循环都犹豫很久严重单元测试覆盖下降依赖“AI 帮我看对不对”中等对依赖版本无感知升级依赖后出错不知道原因中等不愿意做技术分享怕被问到底层原理严重这里要说明一下出现一两个信号并不能说明你“废了”它只是提醒你该调整使用 AI 的方式了。如果三条以上都命中那就需要引起重视。3.2 一个可以立即执行的自我检测与其靠“感觉”不如做一个简单的无工具实验。找一个周末或工作日晚上的两小时关掉所有 AI 辅助插件用最原始的编辑器完成下面这个小任务写一个带 TTL 过期时间的本地缓存工具类要求线程安全支持自动清理过期 key不能引入第三方依赖并提供一个最简单的单元测试。如果你能在没有 AI 的情况下顺畅完成说明你的基础能力还在可以放心地继续把 AI 当效率工具用。如果你发现自己连 ConcurrentHashMap 的复合操作都开始犹豫那这篇文章接下来的部分值得你认真读完。4. 对抗编程停滞的工程实践4.1 保留无辅助编码的刻意练习对抗停滞最重要的一条原则是不要把所有编码时间都交给 AI。我建议你每天至少保留 30 到 60 分钟的“无辅助编码时间”在这段时间里关掉自动补全和 AI 对话框纯粹依靠自己的思维完成开发任务。这段时间用来做什么不是让你重复写业务 CRUD而是刻意练习那些最体现基本功的部分并发控制、数据结构设计、算法实现、复杂状态机、问题排查。这些内容正是 LLM 最容易帮你代劳、也最需要你亲自掌握的。你会发现一开始很慢甚至会怀疑“这不就是在浪费时间吗”但只要坚持两到三周当你再回到 AI 辅助模式时你看代码的眼光会完全不同——你会开始挑剔 AI 生成的实现是否合理而不是无条件接受。4.2 重构 AI 生成代码从“能跑”到“可信”AI 生成代码最大的问题不是“跑不起来”而是“看起来能跑但经不起推敲”。我建议你把 AI 生成的代码当成“候选人代码”拿到手之后一定要做一轮主动重构。下面我用一个实际例子说明这轮重构应该怎么做。假设我们让 AI 实现一个带过期时间的本地缓存工具类它的第一版本输出可能是这样的import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class TtlCacheK, V { private final MapK, CacheEntryV map new ConcurrentHashMap(); public void put(K key, V value, long ttlMillis) { map.put(key, new CacheEntry(value, System.currentTimeMillis() ttlMillis)); } public V get(K key) { CacheEntryV entry map.get(key); if (entry null) { return null; } if (entry.expireAt System.currentTimeMillis()) { map.remove(key); return null; } return entry.value; } private static class CacheEntryV { final V value; final long expireAt; CacheEntry(V value, long expireAt) { this.value value; this.expireAt expireAt; } } }这个版本确实“能跑”但作为工程代码它存在明显的缺陷。最大的问题是过期 key 只在调用 get 时被惰性删除如果某一批 key 写入后再也没有人读它们会一直占着内存。这在一个长期运行的 Java 服务里是非常危险的内存泄漏隐患。经过重构后我加入了一个后台清理线程并显式控制缓存的生命周期import java.io.Closeable; import java.util.Map; import java.util.Objects; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.Executors; import java.util.concurrent.ScheduledExecutorService; import java.util.concurrent.TimeUnit; public class TtlCacheK, V implements Closeable { private final MapK, CacheEntryV map new ConcurrentHashMap(); private final ScheduledExecutorService cleaner; public TtlCache(long sweepIntervalMillis) { this.cleaner Executors.newSingleThreadScheduledExecutor(r - { Thread t new Thread(r, ttl-cache-cleaner); t.setDaemon(true); return t; }); this.cleaner.scheduleWithFixedDelay(this::cleanUp, sweepIntervalMillis, sweepIntervalMillis, TimeUnit.MILLISECONDS); } public void put(K key, V value, long ttlMillis) { Objects.requireNonNull(key, key must not be null); map.put(key, new CacheEntry(value, System.currentTimeMillis() ttlMillis)); } public V get(K key) { CacheEntryV entry map.get(key); if (entry null || entry.expireAt System.currentTimeMillis()) { return null; } return entry.value; } private void cleanUp() { long now System.currentTimeMillis(); map.entrySet().removeIf(e - e.getValue().expireAt now); } Override public void close() { cleaner.shutdownNow(); } private static class CacheEntryV { final V value; final long expireAt; CacheEntry(V value, long expireAt) { this.value value; this.expireAt expireAt; } } }重构后的版本虽然行数变多了但解决了真实工程中非常重要的三个问题线程安全清理、资源回收、生命周期管理。这个例子就是想说明AI 能生成一个“正确”的初版但“可信”和“健壮”的版本需要开发者的工程判断力来补完。4.3 用测试兜住 AI 代码的质量下限对抗停滞的另一个有效手段是为 AI 生成的代码补上单元测试。测试的本质是把“AI 说它能跑”变成“证据证明它能跑”。以往面那个 TtlCache 为例重构之后可以顺手写一个测试import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class TtlCacheTest { Test void shouldExpireEntryAfterTtl() throws InterruptedException { TtlCacheString, String cache new TtlCache(20); cache.put(key, value, 100); assertEquals(value, cache.get(key)); Thread.sleep(200); assertNull(cache.get(key)); cache.close(); } }这个测试只覆盖了最基本的功能但它价值很大它把“缓存过期”这个核心行为固化了下来。如果以后有人改了实现破坏了过期逻辑这个测试会立即报警。在 AI 辅助编码模式下我强烈建议你把“先让 AI 生成实现再自己补测试”这个流程固定下来。补测试的过程就是逼自己重新理解代码逻辑的过程也是避免你沦为“代码搬运工”的强约束。4.4 建立个人知识库把结论沉淀下来很多开发者的知识积累是“即时性”的——遇到问题问 AI得到答案用完就忘。第二天遇到相似问题依然要重新问一遍。这种模式不仅效率低也加剧了编程停滞因为你从来没有把外部知识转化为自己的长期记忆。我建议你建立自己的知识库推荐 Obsidian 这类本地 Markdown 笔记工具也可以用语雀、Notion 或飞书文档。重点是每解决一个典型问题就把“现象 - 原因 - 解决方案 - 可复现示例”完整记录下来。这里有一个很有用的技巧让 AI 帮你整理笔记结构但笔记中的代码和推理过程必须由你自己做一遍解释。当你的知识库积累到几百条之后你会发现自己对技术问题的判断速度越来越快因为很多问题不再需要临时搜索或问 AI而是可以直接从自己的知识体系中调取答案。4.5 用代码审查重新建立输入回路代码审查是抵御编程停滞最重要的团队机制但前提是审查不能流于形式。如果你想从 AI 辅助编程的“舒适区”走出来最简单的方式就是多去阅读别人的代码尤其是那些比你有经验的同事写的代码。你可以从这几个角度进行主动审查这段代码的核心状态是什么状态变化是否符合预期有没有潜在的并发问题锁的粒度是否合理有没有考虑失败场景异常分支是否覆盖完整有没有不必要的依赖能否用更小的 API 实现同样功能当你以“审查者”的身份去读代码时你的大脑会保持活跃因为你必须不断调用已有的知识去判断、去比较、去否定。这种高强度的认知活动正是对抗停滞所需要的输入回路。4.6 设置“不借助 AI”的固定开发时段如果你觉得自己很难做到整个白天都不用 AI那可以从固定时段开始。比如每周三下午的“无 AI 编码日”或者每天上午 10 点到 11 点的“纯手写时间”。在这个时间段里你关掉 GitHub Copilot、关掉聊天框、关掉自动补全用一种“逼自己”的方式完成当天的某一个小功能或维护任务。刚开始你可能会觉得效率骤降但这是必要的过程。你的目标不是证明自己能脱离 AI而是让大脑重新习惯“独立思考和构造代码”的节奏。5. LLM 辅助编程的安全边界5.1 不要在提示词中粘贴敏感信息使用 LLM 辅助编程时很多开发者习惯把一段报错日志、一行数据库连接串、甚至整个项目配置文件直接粘贴到对话窗口里。这个习惯存在明显的信息泄露风险。你的对话输入可能被用于模型训练也可能被服务商留存你无法保证这些信息不会被第三方获取。因此在向 AI 描述问题时建议先做脱敏处理把用户名、密码、令牌、IP、域名、真实表名替换成占位符。例如不要把真实的jdbc:mysql://10.0.0.5:3306/prod_order直接贴进对话可以改成jdbc:mysql://db-host/db-name。另外在团队协作中使用 AI 工具前要确认公司的信息安全规范是否允许是否只能使用内部部署的开源模型是否需要在沙箱环境中操作。合规问题不是个人偏好是底线问题。5.2 对生成的依赖和 API 保持怀疑LLM 存在“幻觉”问题它可能生成一个并不存在的 API、一个已经被废弃的依赖、或者一个配置项写错的值。这种错误在编译阶段可能暴露但也可能潜伏到运行期特别是当你无脑接受 AI 生成的依赖时。在把 AI 推荐的依赖引入项目之前一定要做三件事去 Maven 中央仓库、npm registry 或官方文档确认版本存在查看该版本的发布时间和常见问题确认许可证与你的项目兼容。任何时候都不应该让 AI 全权决定“用什么版本”版本升级和依赖引入必须由人来做最终决策。5.3 遵守团队与公司的合规要求现在不少公司已经制定了 AI 辅助编程的使用规范比如“代码必须经过内部审查才能合入”“禁止将未脱敏的客户数据输入公共 AI 工具”“生产环境变更必须走变更评审”。这些规则看起来很繁琐但本质上是在防止外部工具引入质量风险和安全风险。作为开发者最稳妥的做法是先确认规则再使用工具。不要因为想图方便就把公司核心代码粘贴到公共产品里。6. 常见问题与排查思路在实践过程中开发者对“编程停滞”的困惑通常集中在几个具体问题上。我整理成一张表方便快速对照问题现象常见原因解决思路离开 AI 就写不出代码长期依赖补全构造性思维退化每天固定 30 分钟无辅助编码练习AI 生成的代码线上出故障缺少审查和边界测试强制做代码重构补齐异常分支和单测对生成的依赖版本不放心模型幻觉导致版本不存在到官方仓库核对版本确认后再引入团队整体知识越来越薄审查流程流于形式建立代码评审、技术分享、结对编程机制想把 AI 用得更安全敏感信息泄露风险脱敏后再提交给 AI确认公司合规要求不知道如何提升技术深度知识获取太依赖问答建立个人知识库以输出倒逼输入排查“编程停滞”问题先按“个人 - 团队 - 工具”三个维度定位。个人问题靠调整学习习惯团队问题靠建立工程机制工具问题靠规范使用边界三者不能混为一谈。7. 最佳实践与团队落地建议7.1 个人编码习惯调整从今天开始你可以把下面几条习惯固化到日常工作里遇到报错时先自己读一遍堆栈尝试定位到具体文件和具体逻辑再决定要不要问 AIAI 生成的代码必须经过一轮主动重构检查边界条件、异常分支、并发安全、资源释放每个新知识点在项目里找到一处可落地的位置亲手写一遍每周至少写一个不依赖任何 AI 工具的完整代码模块定期复盘自己最近写的代码问自己这段代码我是否能完全讲清楚这些习惯的核心只有一个——让 AI 处于“辅助”的位置而不是“主导”的位置。7.2 团队工程机制建设如果你是团队负责人或技术组长只靠个人自觉是不够的建议在团队层面建立几个机制代码审查中增加“AI 生成代码”专项检查审查人必须说明是否通过了边界与异常评审每周一次技术分享主题必须是讲解一个自己不熟悉的技术点鼓励手写 demo结对编程时建议一方先独立设计再让另一方用 AI 辅助校验避免双方同时进入“依赖模式”在项目里程碑复盘时除了性能指标也关注团队成员的技术成长曲线定期交流。团队环境对个人成长的塑造非常明显。如果团队默认“能跑就行”“AI 生成直接合”那即便是基础扎实的开发者在一个季度后也可能被同化。反过来如果团队重视代码解释、设计评审、过程复盘AI 工具就会被用在正确的位置上。7.3 长期学习路线如果你想写出高质量代码、成为难以被替代的工程师可以在三个方向持续投入第一扎实底层数据结构、算法、操作系统、计算机网络、数据库原理。这些是 AI 无法替你“理解”的根基也是判断 AI 生成代码是否合理的依据。第二工程能力并发编程、分布式系统、可观测性、性能调优、安全加固。这些知识来自实战也最容易被 AI 时代掩盖但它恰恰是系统稳定性的关键。第三设计能力架构演进、领域建模、模块拆分、成本治理。当 AI 能生成越来越长的代码时唯一越来越值钱的就是把大规模问题拆成可维护模块的决策能力。有人说AI 不会抢走你写代码的工作但会抢走那些“只会写代码”的人的工作。这句话有些绝对但方向是对的。现在最有竞争力的人不是写代码最快的人而是最懂系统、能对代码质量负责的人。LLM 时代工具不再是稀缺资源判断力才是。如果你想从今天开始做一件事我的建议是关掉 AI 补全手写一个你最近用 AI 完成的模块然后对比一下看看你还能不能解释清楚它为什么这样设计。这个简单的动作就是你摆脱编程停滞的第一步。
你有没有发现自从习惯了用 AI 辅助编程之后自己手写一个完整模块的机会反而越来越少我最近在梳理团队的后端项目时注意到一个很有意思的现象需求的交付速度明显提高了但部分同学对代码的“掌控感”却在下降。尤其是当并发容器、线程池、缓存策略这些细节都被 AI 自动补全之后写代码本身似乎变成了一件“只要会描述需求就能完成”的事。这让我开始认真思考一个问题LLM 辅助编程普及之后开发者的基本功是否正在悄悄退化这种现象在英文技术社区里有一个很形象的词叫 Programmatic Stagnation。这篇文章就来完整拆解这个概念并结合实际工程经验聊聊如何避免被 AI 工具“喂养”成一名只会提需求的开发。本文面向所有日常使用 LLM 辅助编程的开发者包括后端、前端、测试和刚入行的新人。读完你会理解 Programmatic Stagnation 的本质、成因能对照检查自己是否已经出现停滞信号并且拿到一套可以立刻落地的对抗方案其中包含提示词设计、代码重构示例、单元测试验证、安全边界意识等完整内容。1. 什么是 Programmatic StagnationLLM 时代的新停滞现象1.1 从“写更多代码”到“让 AI 写代码”过去十几年开发者的核心能力评判标准始终离不开“写代码”。刷 LeetCode、读源码、维护开源项目本质上都是在训练一种把复杂问题拆解成代码结构的能力。但 2023 年之后以 GitHub Copilot、ChatGPT、Claude Code、Cline 为代表的 LLM 编码工具大规模进入日常工作编程活动本身发生了肉眼可见的变化。以前你写一个订单超时关闭功能需要自己设计定时任务、考虑分布式锁、处理分页扫描、设计补偿机制每一步都要想清楚。现在你在 IDE 里输入一个注释或方法名AI 就能把整段逻辑补全。这个变化带来的效率提升是巨大的但它也悄悄改变了“能力积累”的路径。过去能力是在“写错 - 调试 - 理解 - 再写”的循环中建立的。现在很多人的循环变成了“描述 - 生成 - 复制 - 下一个需求”。前者建立的是对系统的深层理解后者建立的只是对工具的熟练操作。1.2 编程停滞的定义与典型表现Programmatic Stagnation 可以直译为“程序化停滞”在本文语境里我把它定义为开发者在技术能力成长上进入平台期——每天能产出大量代码但底层能力数据结构与算法、设计模式、并发思维、调试推理、架构权衡长期没有进步甚至出现倒退的现象。它的核心特征是“任务完成率上升能力成长率下降”。典型表现通常包括这么几种遇到编译错误不再先读堆栈而是直接把报错信息粘贴给 AI等待它给出修复方案对 AI 生成的代码缺少审辨能力只要测试通过就默认它是正确的被要求画系统架构图或解释某个模块的调用链时只能提供 AI 给出的描述自己讲不清楚为什么这样设计独立写一个稍微复杂的算法时明显感觉到思维卡顿甚至需要依赖 AI 补全每步逻辑代码量看起来很多但真正属于自己的设计决策很少更多时候只是在“装配”AI 输出的零件。这些表现有一个共同点不是能力彻底消失而是能力的形成机制被切断了。就像健身时如果长期有人替你发力肌肉虽然还在但已经无法独立完成大重量动作。1.3 为什么现在要重视这个问题有人可能会说“只要 AI 能一直帮我写代码我为什么要自己会写”这个问题在短期看似乎成立但在真实工程环境中站不住脚。第一AI 生成的代码需要被审查和纠错如果开发者自己对目标领域没有足够的理解根本无法判断生成结果是否正确。第二越复杂的系统越依赖设计决策而这些决策恰恰是 AI 最不擅长、也最需要人来负责的部分。第三当 AI 工具出现故障、生成内容明显离谱时最终承担责任并修复问题的人还是你。换句话说LLM 把“编写代码”的门槛降低了但没有把“对代码负责”的门槛降低。如果开发者放弃了能力积累只保留了对工具的依赖那么在遇到新问题、老系统维护、性能瓶颈排查这些场景时停滞感就会非常明显。这也是为什么“LLM 辅助”的正确姿势应该是让工具扩展能力而不是替代能力。2. 编程停滞是如何形成的2.1 思考起点从零变成了补全结果在没有 LLM 辅助的时代开发过程通常是先理解需求再拆解模块然后从空白文件开始写第一行代码。每一步都需要大量的上下文记忆和逻辑推演你的大脑必须持续保持对全局的掌控。使用 LLM 之后思考起点发生了改变。你不再从零开始设计而是先让 AI 生成一个“候选答案”自己再在它基础上修改。这个过程把“构造性思维”偷换成了“评价性思维”。举个例子当 AI 生成一段基于 CompletableFuture 的并发代码时开发者如果本身没有认真学过异步编程模型大概率只会看“结果对不对”而看不出“这里没有设置线程池拒绝策略”“这里异常处理链路是断的”这类深层问题。评价级思维长期替代构造级思维的结果就是底层知识树越来越稀疏。2.2 角色从构造者变成审查者工程团队中有一个说法写代码的人应该对代码拥有“所有权感”。在传统模式下代码是你自己写的每一行都包含你的推理和取舍所以你对它有天然的责任感。而当代码变成 AI 生成的“外部输入”时开发者容易变成流水线上只管送入和送出的操作员失去对产品的内部结构感。这种角色变化在代码审查中表现得尤其明显。过去 review 别人的代码时你能很自然地指出“这里的锁粒度太大了”“这个缓存没有考虑击穿问题”因为这些知识是你自己踩坑踩出来的。现在当你面对 AI 生成的代码时如果你的知识结构不完整review 就变成形式主义的“看着没问题”——可你根本不知道问题藏在哪个角落。审查者角色本身没有错但你必须先有能力成为一个合格的“审查者”而这份能力恰恰来自你自己扎实写过、调过、优化过代码。2.3 即时反馈缩短了试错学习的机会学习一项技术的深度往往是在“试错”中获得的。你写了一个并发程序出现死锁你通过排查线程转储找到原因这个过程中的收获比读十篇教程都要大。LLM 辅助工具改变了这条学习路径。它的最大特点就是“即时反馈”——报错可以立刻粘贴代码可以立刻生成方案可以立刻给答案。这种模式在解决具体问题时效率极高但它剥夺了“试错-反思-总结”的闭环。当你不再需要为每一次失败花时间时也就不再有机会去深入理解失败背后的机制。这也是为什么不少使用 AI 编程的新人会出现一种奇怪的状态能快速完成任务但问起原理却一无所知。知识像是悬浮在半空中没有扎到自己的经验土壤里。2.4 知识获取方式从检索变成生成过去遇到不懂的知识点开发者的习惯是去搜索引擎查文档、翻官方 issue、看社区讨论这个过程虽然慢但会形成完整的上下文。现在很多人已经习惯直接问 AI“帮我解释一下 Redis 分布式锁怎么实现。”AI 会给出一个工整的答案但这份答案是否准确、是否过时、是否忽略了边界条件需要读者自己判断。问题在于一个对分布式锁没有基础认知的开发者根本无法判断这份答案的完整度。于是“看起来明白了”代替了“真正明白了”。这种知识获取方式如果长期占据主导你的知识体系会变得非常扁平——知道很多名词但无法把它们连接成可用的系统。3. 判断自己是否进入停滞状态3.1 需要警惕的七个信号如果你不确定自己是否已经出现编程停滞可以先对照下面这张信号清单逐条检查信号典型场景停滞程度不读报错堆栈看到 Exception 直接复制给 AI明显从不重构生成代码AI 给什么用什么能跑就行明显无法解释设计理由只会说“AI 是这么生成的”明显离开补全写不出来手写一个循环都犹豫很久严重单元测试覆盖下降依赖“AI 帮我看对不对”中等对依赖版本无感知升级依赖后出错不知道原因中等不愿意做技术分享怕被问到底层原理严重这里要说明一下出现一两个信号并不能说明你“废了”它只是提醒你该调整使用 AI 的方式了。如果三条以上都命中那就需要引起重视。3.2 一个可以立即执行的自我检测与其靠“感觉”不如做一个简单的无工具实验。找一个周末或工作日晚上的两小时关掉所有 AI 辅助插件用最原始的编辑器完成下面这个小任务写一个带 TTL 过期时间的本地缓存工具类要求线程安全支持自动清理过期 key不能引入第三方依赖并提供一个最简单的单元测试。如果你能在没有 AI 的情况下顺畅完成说明你的基础能力还在可以放心地继续把 AI 当效率工具用。如果你发现自己连 ConcurrentHashMap 的复合操作都开始犹豫那这篇文章接下来的部分值得你认真读完。4. 对抗编程停滞的工程实践4.1 保留无辅助编码的刻意练习对抗停滞最重要的一条原则是不要把所有编码时间都交给 AI。我建议你每天至少保留 30 到 60 分钟的“无辅助编码时间”在这段时间里关掉自动补全和 AI 对话框纯粹依靠自己的思维完成开发任务。这段时间用来做什么不是让你重复写业务 CRUD而是刻意练习那些最体现基本功的部分并发控制、数据结构设计、算法实现、复杂状态机、问题排查。这些内容正是 LLM 最容易帮你代劳、也最需要你亲自掌握的。你会发现一开始很慢甚至会怀疑“这不就是在浪费时间吗”但只要坚持两到三周当你再回到 AI 辅助模式时你看代码的眼光会完全不同——你会开始挑剔 AI 生成的实现是否合理而不是无条件接受。4.2 重构 AI 生成代码从“能跑”到“可信”AI 生成代码最大的问题不是“跑不起来”而是“看起来能跑但经不起推敲”。我建议你把 AI 生成的代码当成“候选人代码”拿到手之后一定要做一轮主动重构。下面我用一个实际例子说明这轮重构应该怎么做。假设我们让 AI 实现一个带过期时间的本地缓存工具类它的第一版本输出可能是这样的import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class TtlCacheK, V { private final MapK, CacheEntryV map new ConcurrentHashMap(); public void put(K key, V value, long ttlMillis) { map.put(key, new CacheEntry(value, System.currentTimeMillis() ttlMillis)); } public V get(K key) { CacheEntryV entry map.get(key); if (entry null) { return null; } if (entry.expireAt System.currentTimeMillis()) { map.remove(key); return null; } return entry.value; } private static class CacheEntryV { final V value; final long expireAt; CacheEntry(V value, long expireAt) { this.value value; this.expireAt expireAt; } } }这个版本确实“能跑”但作为工程代码它存在明显的缺陷。最大的问题是过期 key 只在调用 get 时被惰性删除如果某一批 key 写入后再也没有人读它们会一直占着内存。这在一个长期运行的 Java 服务里是非常危险的内存泄漏隐患。经过重构后我加入了一个后台清理线程并显式控制缓存的生命周期import java.io.Closeable; import java.util.Map; import java.util.Objects; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.Executors; import java.util.concurrent.ScheduledExecutorService; import java.util.concurrent.TimeUnit; public class TtlCacheK, V implements Closeable { private final MapK, CacheEntryV map new ConcurrentHashMap(); private final ScheduledExecutorService cleaner; public TtlCache(long sweepIntervalMillis) { this.cleaner Executors.newSingleThreadScheduledExecutor(r - { Thread t new Thread(r, ttl-cache-cleaner); t.setDaemon(true); return t; }); this.cleaner.scheduleWithFixedDelay(this::cleanUp, sweepIntervalMillis, sweepIntervalMillis, TimeUnit.MILLISECONDS); } public void put(K key, V value, long ttlMillis) { Objects.requireNonNull(key, key must not be null); map.put(key, new CacheEntry(value, System.currentTimeMillis() ttlMillis)); } public V get(K key) { CacheEntryV entry map.get(key); if (entry null || entry.expireAt System.currentTimeMillis()) { return null; } return entry.value; } private void cleanUp() { long now System.currentTimeMillis(); map.entrySet().removeIf(e - e.getValue().expireAt now); } Override public void close() { cleaner.shutdownNow(); } private static class CacheEntryV { final V value; final long expireAt; CacheEntry(V value, long expireAt) { this.value value; this.expireAt expireAt; } } }重构后的版本虽然行数变多了但解决了真实工程中非常重要的三个问题线程安全清理、资源回收、生命周期管理。这个例子就是想说明AI 能生成一个“正确”的初版但“可信”和“健壮”的版本需要开发者的工程判断力来补完。4.3 用测试兜住 AI 代码的质量下限对抗停滞的另一个有效手段是为 AI 生成的代码补上单元测试。测试的本质是把“AI 说它能跑”变成“证据证明它能跑”。以往面那个 TtlCache 为例重构之后可以顺手写一个测试import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class TtlCacheTest { Test void shouldExpireEntryAfterTtl() throws InterruptedException { TtlCacheString, String cache new TtlCache(20); cache.put(key, value, 100); assertEquals(value, cache.get(key)); Thread.sleep(200); assertNull(cache.get(key)); cache.close(); } }这个测试只覆盖了最基本的功能但它价值很大它把“缓存过期”这个核心行为固化了下来。如果以后有人改了实现破坏了过期逻辑这个测试会立即报警。在 AI 辅助编码模式下我强烈建议你把“先让 AI 生成实现再自己补测试”这个流程固定下来。补测试的过程就是逼自己重新理解代码逻辑的过程也是避免你沦为“代码搬运工”的强约束。4.4 建立个人知识库把结论沉淀下来很多开发者的知识积累是“即时性”的——遇到问题问 AI得到答案用完就忘。第二天遇到相似问题依然要重新问一遍。这种模式不仅效率低也加剧了编程停滞因为你从来没有把外部知识转化为自己的长期记忆。我建议你建立自己的知识库推荐 Obsidian 这类本地 Markdown 笔记工具也可以用语雀、Notion 或飞书文档。重点是每解决一个典型问题就把“现象 - 原因 - 解决方案 - 可复现示例”完整记录下来。这里有一个很有用的技巧让 AI 帮你整理笔记结构但笔记中的代码和推理过程必须由你自己做一遍解释。当你的知识库积累到几百条之后你会发现自己对技术问题的判断速度越来越快因为很多问题不再需要临时搜索或问 AI而是可以直接从自己的知识体系中调取答案。4.5 用代码审查重新建立输入回路代码审查是抵御编程停滞最重要的团队机制但前提是审查不能流于形式。如果你想从 AI 辅助编程的“舒适区”走出来最简单的方式就是多去阅读别人的代码尤其是那些比你有经验的同事写的代码。你可以从这几个角度进行主动审查这段代码的核心状态是什么状态变化是否符合预期有没有潜在的并发问题锁的粒度是否合理有没有考虑失败场景异常分支是否覆盖完整有没有不必要的依赖能否用更小的 API 实现同样功能当你以“审查者”的身份去读代码时你的大脑会保持活跃因为你必须不断调用已有的知识去判断、去比较、去否定。这种高强度的认知活动正是对抗停滞所需要的输入回路。4.6 设置“不借助 AI”的固定开发时段如果你觉得自己很难做到整个白天都不用 AI那可以从固定时段开始。比如每周三下午的“无 AI 编码日”或者每天上午 10 点到 11 点的“纯手写时间”。在这个时间段里你关掉 GitHub Copilot、关掉聊天框、关掉自动补全用一种“逼自己”的方式完成当天的某一个小功能或维护任务。刚开始你可能会觉得效率骤降但这是必要的过程。你的目标不是证明自己能脱离 AI而是让大脑重新习惯“独立思考和构造代码”的节奏。5. LLM 辅助编程的安全边界5.1 不要在提示词中粘贴敏感信息使用 LLM 辅助编程时很多开发者习惯把一段报错日志、一行数据库连接串、甚至整个项目配置文件直接粘贴到对话窗口里。这个习惯存在明显的信息泄露风险。你的对话输入可能被用于模型训练也可能被服务商留存你无法保证这些信息不会被第三方获取。因此在向 AI 描述问题时建议先做脱敏处理把用户名、密码、令牌、IP、域名、真实表名替换成占位符。例如不要把真实的jdbc:mysql://10.0.0.5:3306/prod_order直接贴进对话可以改成jdbc:mysql://db-host/db-name。另外在团队协作中使用 AI 工具前要确认公司的信息安全规范是否允许是否只能使用内部部署的开源模型是否需要在沙箱环境中操作。合规问题不是个人偏好是底线问题。5.2 对生成的依赖和 API 保持怀疑LLM 存在“幻觉”问题它可能生成一个并不存在的 API、一个已经被废弃的依赖、或者一个配置项写错的值。这种错误在编译阶段可能暴露但也可能潜伏到运行期特别是当你无脑接受 AI 生成的依赖时。在把 AI 推荐的依赖引入项目之前一定要做三件事去 Maven 中央仓库、npm registry 或官方文档确认版本存在查看该版本的发布时间和常见问题确认许可证与你的项目兼容。任何时候都不应该让 AI 全权决定“用什么版本”版本升级和依赖引入必须由人来做最终决策。5.3 遵守团队与公司的合规要求现在不少公司已经制定了 AI 辅助编程的使用规范比如“代码必须经过内部审查才能合入”“禁止将未脱敏的客户数据输入公共 AI 工具”“生产环境变更必须走变更评审”。这些规则看起来很繁琐但本质上是在防止外部工具引入质量风险和安全风险。作为开发者最稳妥的做法是先确认规则再使用工具。不要因为想图方便就把公司核心代码粘贴到公共产品里。6. 常见问题与排查思路在实践过程中开发者对“编程停滞”的困惑通常集中在几个具体问题上。我整理成一张表方便快速对照问题现象常见原因解决思路离开 AI 就写不出代码长期依赖补全构造性思维退化每天固定 30 分钟无辅助编码练习AI 生成的代码线上出故障缺少审查和边界测试强制做代码重构补齐异常分支和单测对生成的依赖版本不放心模型幻觉导致版本不存在到官方仓库核对版本确认后再引入团队整体知识越来越薄审查流程流于形式建立代码评审、技术分享、结对编程机制想把 AI 用得更安全敏感信息泄露风险脱敏后再提交给 AI确认公司合规要求不知道如何提升技术深度知识获取太依赖问答建立个人知识库以输出倒逼输入排查“编程停滞”问题先按“个人 - 团队 - 工具”三个维度定位。个人问题靠调整学习习惯团队问题靠建立工程机制工具问题靠规范使用边界三者不能混为一谈。7. 最佳实践与团队落地建议7.1 个人编码习惯调整从今天开始你可以把下面几条习惯固化到日常工作里遇到报错时先自己读一遍堆栈尝试定位到具体文件和具体逻辑再决定要不要问 AIAI 生成的代码必须经过一轮主动重构检查边界条件、异常分支、并发安全、资源释放每个新知识点在项目里找到一处可落地的位置亲手写一遍每周至少写一个不依赖任何 AI 工具的完整代码模块定期复盘自己最近写的代码问自己这段代码我是否能完全讲清楚这些习惯的核心只有一个——让 AI 处于“辅助”的位置而不是“主导”的位置。7.2 团队工程机制建设如果你是团队负责人或技术组长只靠个人自觉是不够的建议在团队层面建立几个机制代码审查中增加“AI 生成代码”专项检查审查人必须说明是否通过了边界与异常评审每周一次技术分享主题必须是讲解一个自己不熟悉的技术点鼓励手写 demo结对编程时建议一方先独立设计再让另一方用 AI 辅助校验避免双方同时进入“依赖模式”在项目里程碑复盘时除了性能指标也关注团队成员的技术成长曲线定期交流。团队环境对个人成长的塑造非常明显。如果团队默认“能跑就行”“AI 生成直接合”那即便是基础扎实的开发者在一个季度后也可能被同化。反过来如果团队重视代码解释、设计评审、过程复盘AI 工具就会被用在正确的位置上。7.3 长期学习路线如果你想写出高质量代码、成为难以被替代的工程师可以在三个方向持续投入第一扎实底层数据结构、算法、操作系统、计算机网络、数据库原理。这些是 AI 无法替你“理解”的根基也是判断 AI 生成代码是否合理的依据。第二工程能力并发编程、分布式系统、可观测性、性能调优、安全加固。这些知识来自实战也最容易被 AI 时代掩盖但它恰恰是系统稳定性的关键。第三设计能力架构演进、领域建模、模块拆分、成本治理。当 AI 能生成越来越长的代码时唯一越来越值钱的就是把大规模问题拆成可维护模块的决策能力。有人说AI 不会抢走你写代码的工作但会抢走那些“只会写代码”的人的工作。这句话有些绝对但方向是对的。现在最有竞争力的人不是写代码最快的人而是最懂系统、能对代码质量负责的人。LLM 时代工具不再是稀缺资源判断力才是。如果你想从今天开始做一件事我的建议是关掉 AI 补全手写一个你最近用 AI 完成的模块然后对比一下看看你还能不能解释清楚它为什么这样设计。这个简单的动作就是你摆脱编程停滞的第一步。
