如果你过去一年里一直在用 LLM 写代码而且觉得效率高了不少那这篇文章值得停下来看完。因为我们要讨论的不是“LLM 好不好用”而是一个正在开发者圈子里被反复提起但很少有人系统说清楚的概念——Programmatic Stagnation编程停滞。简单说它描述的是这样一种状态你每天提交的代码越来越多但脱离 AI 后写代码、读代码、修代码的能力却在明显退化。功能开发看起来很快真正出问题时却寸步难行。LLM 提升了产出速度却没有同步提升开发者对系统的理解甚至还在削弱它。这篇文章主要解决 4 个问题什么是 Programmatic Stagnation它的表现和触发机制是什么。LLM 辅助编程为什么容易带来停滞而不只是“效率提升”。如何用工程化手段识别自己或团队是否已经进入停滞。哪些实操方法可以在保留 LLM 效率的同时避免技能空心化。文章后面会给出自测脚本、代码示例、排查表格和一套可以直接落到团队协作里的检查流程。不管你是个人开发者、技术 leader还是正在用 AI 写业务代码的工程团队都建议按文中的清单做一次自查。1. 核心概念速览能力项说明关注对象使用 LLM 辅助编程的开发者个体与软件团队核心概念Programmatic Stagnation指开发者长期依赖 LLM 生成代码后出现的理解力、调试力与独立编码能力退化典型表现能够生成代码但无法解释遇到报错反复让 AI 猜代码审查流于形式自动化测试覆盖下降主要诱因无差别接受 AI 输出、缺少代码审查、没有独立调试过程、学习和纠错回路被跳过受影响人群初级开发者、中期工程师、团队技术负责人均可能受影响影响层次不同可逆性可逆但需要主动设计学习和验证机制不能指望自然恢复与 AI 的关系LLM 是加速器不是替代思考的终端停滞产生于使用方式而非工具本身应对思路保留无 AI 练习、强制代码解释、设置质量门禁、维护核心代码人工审查清单一句话概括编程停滞不是“AI 用多了”造成的而是“只接受结果、不消化过程”造成的。2. 现象LLM 辅助编程带来的生产力幻觉先看一组很常见的开发场景。以前写一个分页查询接口要自己翻文档、写 SQL、调参数、处理边界情况。现在把需求粘给 LLM几十秒得到一段看起来可运行的代码。你复制、调用、接口通了提交。这个过程可能只花 10 分钟你会觉得自己效率很高。但这里有一个隐藏问题整个过程中你没有做任何一次判断。你没有思考为什么这里用LIMIT而不是OFFSET没有考虑索引在深分页场景下的失效问题没有验证 SQL 在数据量增长后的执行计划。LLM 替你写了代码也替你跳过了决策过程。决策过程才是编程能力增长的核心而不是最终那几行代码。这类场景积累到一定数量后就会出现一些非常典型的现象让开发者不借助 AI 写一个排序算法他能写出来但说不清时间复杂度的推导。代码报错时第一反应是“把错误贴给 AI”而不是先看调用栈、查文档、定位变量状态。代码评审时评审人看不懂提交者的实现意图因为提交者自己也说不清楚。项目里出现大量结构相似但彼此冲突的工具函数都是 AI 在不同时间点“按需生成”的。依赖版本混乱同一个功能有三套实现没有人知道该删哪一套。单独看每一条都像小事但合在一起就是软件工程能力的系统性衰退。生产力指标在短期内是上升的长期维护成本和事故率却会慢慢爬升。这就是为什么文章标题把 LLM 和编程停滞放在一起讨论——工具变强了并不意味着使用者的工程能力变强了。3. 停滞机制为什么越用越容易停3.1 技能退化手写与手修能力下降编程能力本质上是一种程序性记忆也就是通过反复练习固化的动作序列。你第一次写递归时觉得别扭写了 20 次之后基本不需要查资料。这个过程依赖的是重复练习中的试错和反馈。LLM 介入后试错环节被压缩到近乎为零。你不需要再为了一个空指针异常翻半小时代码AI 直接告诉你哪里有问题。听起来是好事但代价是你的大脑不再为“调试”建立新的神经回路。下次遇到一个 AI 无法解决的、需要人工定位的复杂并发问题时你会发现自己的排查能力远低于预期。这不是错觉而是长期跳过练习导致的技能衰减。从工程经验看手写代码能力就像一个阈值下限。你可以不用它作为日常产出方式但不能丢掉它。一旦丢掉你就失去了评估 AI 输出质量的最基本参照系。3.2 理解浅化会跑但不会讲代码能运行不代表你理解它。很多 LLM 生成的代码包含大量隐含逻辑内存分配、缓存策略、锁的粒度、事务边界。这些内容不会出现在需求描述里也不一定反映在最终的“能跑”上面。开发者把代码粘进项目跑通测试后就算完成而生成过程中涉及的每个设计决策都被跳过了。这样做最直接的后果是当系统行为不符合预期时没有人知道该从哪个层面入手排查。传统的编程学习路径中犯错是理解系统的最佳契机。你写错了事务注解线上出现数据不一致你回去查资料、看日志最终修正——这个闭环完成后你对事务机制的理解是深度的。LLM 帮你直接写出正确的事务代码看起来省了事实际也省掉了理解事务的机会。长期下来开发者的知识体系会变成“孤岛式”的知道某个代码能完成任务但不清楚它在整个系统中的位置、依赖和代价。项目越大这种理解浅化带来的风险越大。3.3 盲区固化错误模式被 AI 放大LLM 的一个特点是它生成的代码往往在风格和模式上高度一致。这本身不是问题。但如果开发者不具备批判性评估能力就会无差别接受 AI 的输出于是同样的设计缺陷会被复制到项目的各个角落。典型例子包括所有数据库操作都套同一个“万能模板”完全没有考虑查询频率和数据量。异常处理一律吞掉只打印一行日志线上问题无法追踪。大量不必要的依赖注入只因为 AI 示例代码里这么写了。工具类函数越来越“臃肿”参数越来越多最后变成无人敢改的公共类。在一个人工编码的团队里不同开发者写出的代码风格有差异这种差异本身就构成一种分散风险——某个人的坏习惯不太可能被复制到整个代码库。但 LLM 辅助编程模式下如果主导者偏好某一种模式AI 会非常高效地把这种偏好或错误模式批量复制到所有模块中。这就是盲区固化你不会的知识盲区AI 不只不会帮你发现还会帮你把它大规模工程化。3.4 反馈回路缺失没有纠错的学习闭环人之所以能从经验中成长是因为存在“行动 → 反馈 → 修正”的闭环。传统编程中你可以通过编译失败、运行时报错、线上告警获得反馈。每次修一个 bug你就对这个系统多一层理解。LLM 出现后反馈回路变成了“报错 → 粘贴给 AI → 得到修复方案 → 继续开发”。这个回路里没有你自己的分析过程也没有真正的认知修正。你没有做错也就没有从错误中学习。这是编程停滞最隐蔽也是最危险的一点表面上一路通畅但每一次都是同一水平的你。这也是为什么有些团队在使用 LLM 半年后代码产出速度很快但一旦核心成员离职接班人完全接不住这套系统——因为没有人深度理解这些代码的“为什么”所有人都只看到了“是什么”。4. 工程层面的具体风险4.1 代码质量重复与依赖膨胀LLM 不擅长从全局视角判断“这段代码是否已经存在”。于是你会看到项目里出现大量重复逻辑三个文件里各有一个formatTime函数每个的实现细节略有不同有人用 A 库发送 HTTP 请求有人用 B 库两人都说是 AI 推荐的项目依赖里同时出现两个功能高度重叠的库。这种问题靠 LLM 自己发现不了需要人工做架构审查。但如果开发者已经习惯完全依赖 LLM 输出往往没有动力去清理。小项目里这是卫生问题大项目里这会直接拖慢构建速度增加安全审计范围最终变成技术债的一部分。4.2 安全风险LLM 生成的漏洞安全社区已经有大量研究指出LLM 生成的代码中会出现已知的漏洞模式SQL 注入、路径穿越、不安全的反序列化、缺少输入校验。关键问题在于如果一个开发者的安全知识本身就不够扎实他很难识别这些代码中的风险点。他会认为“AI 写的代码应该没有低级错误”然后把存在隐患的代码直接提交上去。这不是 LLM 的问题而是使用者的能力与信任度不匹配的问题。AI 可以帮你写代码但它不能代你建立安全意识。安全能力的培养仍然依赖阅读漏洞报告、分析攻击路径、复现问题等传统学习路径这些路径无法被自动生成代码替代。4.3 架构腐化没有人理解整体架构决策需要理解业务目标、数据流向、团队协作模式和演进方向。LLM 参与的单点代码生成无法感知这些全局约束。所以LLM 辅助编程到后期容易出现架构腐化局部代码合理整体结构混乱。每个函数单独看都写得挺工整但模块之间的关系越来越复杂调用链越来越长数据流向越来越不清晰。这种问题不像 bug 那样直接暴露它藏在代码组织的深处最终以“系统越来越难改”的形式呈现。等到架构需要调整时团队会发现没有人能够完整说出系统当前的工作方式因为系统中的大部分代码已经不是“人写出来的”而是“AI 拼出来的”。4.4 调试能力的断崖调试能力是编程能力的温度计。它要求你读代码、跟踪状态、提出假设、验证假设最终定位问题根因。LLM 辅助编程时代很多开发者的调试流程变成了“把报错信息复制给 AI让它给修复方案”。如果 AI 一次没修好就接着问循环往复。这种模式下开发者实际上退出了调试过程只保留了“复制粘贴”这个动作。结果显而易见当遇到 LLM 也没有见过的、需要结合业务上下文或系统全局状态才能定位的 bug 时开发者会非常被动。因为他的调试能力从来没有跟上他写的代码复杂度。5. 如何识别自测清单与量化指标5.1 个人自测先回答这 10 个问题维度自查问题独立编码不借助任何 AI 工具能否从零写出一个带错误处理的小模块代码解释能否完整解释昨天提交代码中每一行的作用调试定位遇到 bug 时是否先阅读报错栈和日志而不是直接贴给 AI设计决策能否说清你最近一次技术选型的理由和取舍条件依赖关系项目的核心依赖是否升级过升级时你了解会影响哪些模块吗代码审查你上次在 code review 中提出具体改进建议是什么时候测试编写你写的代码是否有配套测试测试是你自己写的还是 AI 生成的架构理解能否画出当前项目核心模块的依赖关系图编程热情你最近有没有因为“想弄明白”而去读源码知识更新最近一次通过阅读文档或源代码学到新知识是什么时候如果答案中有 5 项以上是“否”说明你已经处在停滞边缘。不需要恐慌但需要立刻调整使用 AI 的方式。5.2 团队健康度量化指标参考团队层面的停滞更隐蔽也更难通过主观感受发现。可以配合一些量化指标做辅助判断。指标一代码重复率。可以把jscpd这类工具接入 CI 流水线定期输出重复代码占比。# 安装 jscpd 并分析项目重复度 npm install -g jscpd jscpd ./src --min-lines 5 --min-tokens 50 --output ./reports/jscpd-report.json重复率持续上升说明团队内部可能出现了大量不经统一设计的 AI 生成代码。指标二测试覆盖率的有效性。只看行覆盖率不够还要看断言密度。# 统计测试文件中的断言数量结合覆盖率做交叉对比 grep -r expect(\|assert(\|should( tests/ | wc -l如果覆盖率很高但断言数量很低测试可能只是为了通过流水线而生成的垃圾用例。指标三代码评审参与度。统计最近 30 天的 merge request 中有多少条评论是实质性技术讨论有多少只是“LGTM”。# 伪代码按 MR 评论类型统计评审质量 # 输入MR 评论列表 # 输出实质性评论占比 def count_substantive_comments(comments): substantive_keywords [为什么, 考虑, 风险, 重构, 性能, 边界, 安全] total 0 substantive 0 for comment in comments: if comment.is_generated_by_author: continue total 1 if any(kw in comment.content for kw in substantive_keywords): substantive 1 if total 0: return 0.0 return round(substantive / total, 2) report { total_comments: 87, substantive_ratio: count_substantive_comments(comments_data) } print(report) # 输出示例{total_comments: 87, substantive_ratio: 0.46}如果这个比例低于 0.3说明 code review 正在变成流程摆设这是一个非常危险的信号。5.3 代码库症状如何从仓库上发现停滞在 Git 仓库层面有几个可以用来快速判断异常的信号。仓库症状可能原因建议行动单个文件超过 1000 行且没有拆分AI 持续向同一函数追加逻辑手动重构禁止 AI 修改该文件出现大量_v2、_final、_copy命名开发者不理解已有实现直接让 AI 重写清理重复实现明确唯一实现依赖文件体积急剧膨胀每次用 AI 解决问题都顺手引入新库审计依赖建立依赖引入规范大量注释缺失但代码风格统一AI 生成代码未被人工消化增加解释型注释要求README 更新频率远低于代码提交团队已无法用自然语言描述系统状态恢复文档更新制度这些信号不需要跑复杂工具打开仓库扫一遍就能看到。早点发现代价很小拖到架构腐化后再处理成本会高几个数量级。6. 避免编程停滞个人层面的工程方法6.1 设定“无 AI 时段”如果想保住自己的核心编程能力最简单有效的方法是给自己设定一个“无 AI 时段”。具体操作方法每周固定 2 到 4 个小时关闭所有 AI 辅助工具。只靠编辑器、编译器和调试器完成一个真实任务。任务不一定大但必须包含设计、编码、调试三个完整环节。关键点是不要用“这个任务太简单没必要写”来跳过。无 AI 时段的目的是恢复大脑的编程回路而不是产出高效代码。你可以选一些日常工作里最不想做的、难度中等的任务比如重构一个老模块、复现一个偶现 bug、优化一个慢查询。持续几周后你会明显感觉到回归 AI 辅助工作时你能更清晰地判断它生成代码的优劣而不是被动接受。6.2 强制解释让 LLM 输出带理由的代码继续用 LLM 没问题但要在提示词里加入解释要求。请为下面的需求生成代码并完成以下要求 1. 每个关键函数注明时间复杂度和空间复杂度。 2. 对非平凡的逻辑给出详细注释说明为什么这样实现。 3. 列出这段实现可能的边界条件和失败场景。 4. 如果存在多种实现方案请对比后说明推荐哪种及原因。 需求实现一个支持并发读取、过期自动清理的内存缓存。这种提示词的目的是把“隐藏的设计决策”显式化。你不用自己去推导一切但至少能看到关键决策的轮廓。之后再独立判断这些理由是否成立能判断说明你在成长不能判断说明这个知识点你需要补课。6.3 坚持“核心代码人工编写”每个项目里都应该有一份“不允许 AI 修改”的清单。典型的清单内容文件类型理由核心业务规则引擎出错影响面大需要人工精确控制安全鉴权与权限判断安全逻辑不能用“看起来对”的代码支付/计费等资金相关逻辑需要审计和溯源人工可读性优先数据库迁移脚本时序敏感AI 无法感知线上数据状态高并发核心路径性能瓶颈需要人工理解和调优这些文件不是“永远禁止 AI 参与”而是要求审核严格度更高。开发者需要亲自写或者至少写完后能逐行解释。如果无法解释不能合并。这样做的意义在于每个团队保底有一块“技术飞地”维护着最核心的工程能力。6.4 用测试倒逼理解让开发者验证自己是否真的理解代码最直接的方法是要求他为代码编写测试。要求是测试不能只覆盖正常路径至少要包含一个边界条件和异常场景。import pytest from cache import TTLCache def test_cache_returns_none_for_expired_key(): cache TTLCache(ttl_seconds1) cache.set(key, value) # 模拟时间流逝到过期之后 cache._now lambda: cache._now() 2 value cache.get(key) assert value is None, 过期缓存不应返回值 def test_cache_evicts_only_expired_entries(): cache TTLCache(ttl_seconds10) cache.set(a, 1) cache._now lambda: cache._now() 11 cache.set(b, 2) # 写入 b 时应当触发清理 assert cache.get(a) is None assert cache.get(b) 2如果开发者能独立写出类似测试说明他对缓存的过期机制、清理时机和边界行为有实际理解。如果他只让 AI 生成测试、直接粘进仓库那么这个流程就失去了意义。团队层面可以通过抽查方式落实这一点。6.5 定期阅读源码和文档这个动作和 AI 无关但在 AI 时代变得更重要。每周花 30 分钟读一个你当前项目依赖的第三方库的源码。可以只读一个函数、一个类的实现关键是理解它“为什么这样做”。比如你用了 HTTP 客户端库就去看它的连接池实现用了缓存库就去看它的淘汰策略。你读得越多越能感受到 LLM 生成代码中那些“看似正确但缺少工程考量”的部分。这种感知力是防止编程停滞最有效的免疫系统。7. 团队层面的工程实践7.1 人机结对让 AI 扮演“建议者”而不是“执行者”个人可以靠自觉控制 AI 的使用方式团队则需要把它制度化成协作模式。推荐的一种做法是“人机结对”人类工程师负责架构设计、模块切分和验收标准LLM 负责生成符合标准的实现片段再由人类工程师逐行审查并合入。这跟“把整个需求发给 AI直接把结果提交”有本质区别。前者把 AI 当成一个经验丰富的执行者把开发者保留在设计者和审查者的位置后者则取消了开发者的思考环节。落地方式任务拆分时明确哪些子任务可以给 AI 生成哪些必须人工编写。AI 产物进入代码库前必须经过一次人工修改哪怕只是变量重命名或添加注释。禁止未经修改就直接提交 LLM 生成的完整代码。这个流程会让 AI 使用效率稍微下降但能保住质量底线长期看是值得的。7.2 建立 AI 代码审查基准当 AI 参与代码生成后传统的 code review 基准已经不够用。需要增加专属于 AI 生成代码的检查项。# .ai-ai-code-review-rules.yaml 示例 # 用于 AI 生成代码的合并前检查项 rules: - id: REQUIRED_EXPLANATION message: AI 生成的复杂代码必须附实现说明包含设计选择和已知边界。 level: error - id: BANNED_GENERIC_TEMPLATE message: 禁止无差异复制上一个模块的模板代码必须按当前场景调整。 level: warning - id: DEPENDENCY_GUARD message: 新增依赖必须注明用途并说明与现有依赖的功能差异。 level: error - id: TEST_QUALITY message: AI 生成的测试必须包含至少一个边界条件用例。 level: warning这套规则不要求很复杂核心是让团队成员形成习惯AI 生成的代码不等于免检代码必须经过同样的质量标准。7.3 重构 AI 滥用的重复实现当仓库里出现“三个文件各有一个 formatTime”的情况时要当成一个问题来处理而不是下一次顺手就把第四个也加上。操作步骤扫描全仓库找出功能相同或多处重复的代码片段。人工设计统一的公共实现明确参数和使用方式。让 AI 负责“把旧调用替换成新实现”这种机械性工作。人工检查替换后每个调用点的语义是否正确。这个流程的好处是人决定了“应该是什么样”AI 负责执行。知识导向在人这边工作量交给 AI既保效率又保理解。7.4 知识分享与文档制度LLM 让代码产出加速但文档往往会被忽略。没有文档团队对系统的理解会越来越依赖“临时问 AI”而不是沉淀在组织内部。建议在团队内恢复以下制度每次重要的架构调整后由负责人写一篇 200 字以上的变更说明。每个核心模块至少有一名“负责人”能完整解释其实现。每季度安排一次代码走查重点是人能不能讲清楚自己的代码而不只是跑通。这套东西不复杂但能有效对抗编程停滞在团队层面的蔓延。8. 常见误区和判断排查8.1 关于 LLM 与编程停滞的三个误区误区事实“用 LLM 写代码就是高效开发”短期产出高不代表工程能力高维护成本会滞后暴露“AI 会取代程序员学不学习无所谓”恰恰相反能评估 AI 输出质量的人最有价值“停止用 AI 就能避免停滞”完全不用 AI 会丢掉效率优势问题在于使用方式核心不是“用或不用”而是使用 AI 的同时是否保留自己的判断和练习回路。8.2 个人状态排查表状态表现可能原因排查方向应对建议离开 AI 不会写代码长期未做无 AI 练习能否独立完成一个带错误处理的小模块设置每周无 AI 时段代码能跑但讲不清设计理解浅化只接受了结果能否说清关键函数的时间/空间复杂度增加解释型提示词遇到 bug 只会贴给 AI调试能力退化是否先读报错栈和日志再求助强制自己定位到具体行再问 AI测试覆盖率很高但质量低AI 生成了大量无效测试是否存在断言密度不足抽查 AI 测试中的边界用例仓库重复代码不断增加没有统一设计AI 按需生成是否重复实现了相同功能做一次重复代码清理8.3 团队状态排查表团队表现可能原因排查方向应对建议MR 评论大量是“LGTM”code review 流于形式统计实质性评论占比建立 AI 代码审查基准依赖快速膨胀每个问题都引入新库是否有依赖引入规范审计并限制新增依赖核心人员离职后无人接盘知识只在 LLM 会话里没有沉淀文档与负责人制度是否有效恢复文档和走查制度线上事故后根因分析做不下去团队对系统理解不够能否讲清调用链与会话模型建立核心模块负责人制度代码提交量很大但迭代速度变慢技术债在累积重构频率是否下降定期做架构审查9. 关键结论与行动清单这篇文章需要你记住的核心结论只有三条第一LLM 不是编程能力下降的原因无意识的依赖才是。工具越强大使用者越需要保持对输出质量的判断力。第二编程能力靠“行动 → 反馈 → 修正”闭环维持任何跳过这个闭环的工具都会加速停滞。这决定了你使用 LLM 的方式应当是“辅助判断”而不是“替代判断”。第三停滞是可以逆的而且越早干预代价越小。每周 2 小时无 AI 练习、强制代码解释、核心代码人工编写这三件事只要坚持 4 周你就能感受到明显变化。值得马上采取的行动按优先级排列今晚回答一次本文章节 5.1 中的 10 个自测问题。本周设置第一个“无 AI 时段”完成一个真实任务。下周开始给 LLM 提示词加上“解释设计决策”的要求。如果你是技术负责人把 7.2 质量门禁规则落地到仓库里并抽查一个月。关于 LLM 辅助编程最终的判断标准不是“它帮你写了多少代码”而是“你还能不能独立写出一段自己完全理解的代码”。如果答案变得越来越模糊那不管当前交付速度多快都该停下来重新校准一下使用方式了。毕竟工具可以换能力长在自己身上。别让“生成代码”代替“理解代码”也别让每天的提交记录掩盖掉一年后的寸步难行。 编程停滞：当LLM提升产出速度，却在悄悄削弱你的工程能力
如果你过去一年里一直在用 LLM 写代码而且觉得效率高了不少那这篇文章值得停下来看完。因为我们要讨论的不是“LLM 好不好用”而是一个正在开发者圈子里被反复提起但很少有人系统说清楚的概念——Programmatic Stagnation编程停滞。简单说它描述的是这样一种状态你每天提交的代码越来越多但脱离 AI 后写代码、读代码、修代码的能力却在明显退化。功能开发看起来很快真正出问题时却寸步难行。LLM 提升了产出速度却没有同步提升开发者对系统的理解甚至还在削弱它。这篇文章主要解决 4 个问题什么是 Programmatic Stagnation它的表现和触发机制是什么。LLM 辅助编程为什么容易带来停滞而不只是“效率提升”。如何用工程化手段识别自己或团队是否已经进入停滞。哪些实操方法可以在保留 LLM 效率的同时避免技能空心化。文章后面会给出自测脚本、代码示例、排查表格和一套可以直接落到团队协作里的检查流程。不管你是个人开发者、技术 leader还是正在用 AI 写业务代码的工程团队都建议按文中的清单做一次自查。1. 核心概念速览能力项说明关注对象使用 LLM 辅助编程的开发者个体与软件团队核心概念Programmatic Stagnation指开发者长期依赖 LLM 生成代码后出现的理解力、调试力与独立编码能力退化典型表现能够生成代码但无法解释遇到报错反复让 AI 猜代码审查流于形式自动化测试覆盖下降主要诱因无差别接受 AI 输出、缺少代码审查、没有独立调试过程、学习和纠错回路被跳过受影响人群初级开发者、中期工程师、团队技术负责人均可能受影响影响层次不同可逆性可逆但需要主动设计学习和验证机制不能指望自然恢复与 AI 的关系LLM 是加速器不是替代思考的终端停滞产生于使用方式而非工具本身应对思路保留无 AI 练习、强制代码解释、设置质量门禁、维护核心代码人工审查清单一句话概括编程停滞不是“AI 用多了”造成的而是“只接受结果、不消化过程”造成的。2. 现象LLM 辅助编程带来的生产力幻觉先看一组很常见的开发场景。以前写一个分页查询接口要自己翻文档、写 SQL、调参数、处理边界情况。现在把需求粘给 LLM几十秒得到一段看起来可运行的代码。你复制、调用、接口通了提交。这个过程可能只花 10 分钟你会觉得自己效率很高。但这里有一个隐藏问题整个过程中你没有做任何一次判断。你没有思考为什么这里用LIMIT而不是OFFSET没有考虑索引在深分页场景下的失效问题没有验证 SQL 在数据量增长后的执行计划。LLM 替你写了代码也替你跳过了决策过程。决策过程才是编程能力增长的核心而不是最终那几行代码。这类场景积累到一定数量后就会出现一些非常典型的现象让开发者不借助 AI 写一个排序算法他能写出来但说不清时间复杂度的推导。代码报错时第一反应是“把错误贴给 AI”而不是先看调用栈、查文档、定位变量状态。代码评审时评审人看不懂提交者的实现意图因为提交者自己也说不清楚。项目里出现大量结构相似但彼此冲突的工具函数都是 AI 在不同时间点“按需生成”的。依赖版本混乱同一个功能有三套实现没有人知道该删哪一套。单独看每一条都像小事但合在一起就是软件工程能力的系统性衰退。生产力指标在短期内是上升的长期维护成本和事故率却会慢慢爬升。这就是为什么文章标题把 LLM 和编程停滞放在一起讨论——工具变强了并不意味着使用者的工程能力变强了。3. 停滞机制为什么越用越容易停3.1 技能退化手写与手修能力下降编程能力本质上是一种程序性记忆也就是通过反复练习固化的动作序列。你第一次写递归时觉得别扭写了 20 次之后基本不需要查资料。这个过程依赖的是重复练习中的试错和反馈。LLM 介入后试错环节被压缩到近乎为零。你不需要再为了一个空指针异常翻半小时代码AI 直接告诉你哪里有问题。听起来是好事但代价是你的大脑不再为“调试”建立新的神经回路。下次遇到一个 AI 无法解决的、需要人工定位的复杂并发问题时你会发现自己的排查能力远低于预期。这不是错觉而是长期跳过练习导致的技能衰减。从工程经验看手写代码能力就像一个阈值下限。你可以不用它作为日常产出方式但不能丢掉它。一旦丢掉你就失去了评估 AI 输出质量的最基本参照系。3.2 理解浅化会跑但不会讲代码能运行不代表你理解它。很多 LLM 生成的代码包含大量隐含逻辑内存分配、缓存策略、锁的粒度、事务边界。这些内容不会出现在需求描述里也不一定反映在最终的“能跑”上面。开发者把代码粘进项目跑通测试后就算完成而生成过程中涉及的每个设计决策都被跳过了。这样做最直接的后果是当系统行为不符合预期时没有人知道该从哪个层面入手排查。传统的编程学习路径中犯错是理解系统的最佳契机。你写错了事务注解线上出现数据不一致你回去查资料、看日志最终修正——这个闭环完成后你对事务机制的理解是深度的。LLM 帮你直接写出正确的事务代码看起来省了事实际也省掉了理解事务的机会。长期下来开发者的知识体系会变成“孤岛式”的知道某个代码能完成任务但不清楚它在整个系统中的位置、依赖和代价。项目越大这种理解浅化带来的风险越大。3.3 盲区固化错误模式被 AI 放大LLM 的一个特点是它生成的代码往往在风格和模式上高度一致。这本身不是问题。但如果开发者不具备批判性评估能力就会无差别接受 AI 的输出于是同样的设计缺陷会被复制到项目的各个角落。典型例子包括所有数据库操作都套同一个“万能模板”完全没有考虑查询频率和数据量。异常处理一律吞掉只打印一行日志线上问题无法追踪。大量不必要的依赖注入只因为 AI 示例代码里这么写了。工具类函数越来越“臃肿”参数越来越多最后变成无人敢改的公共类。在一个人工编码的团队里不同开发者写出的代码风格有差异这种差异本身就构成一种分散风险——某个人的坏习惯不太可能被复制到整个代码库。但 LLM 辅助编程模式下如果主导者偏好某一种模式AI 会非常高效地把这种偏好或错误模式批量复制到所有模块中。这就是盲区固化你不会的知识盲区AI 不只不会帮你发现还会帮你把它大规模工程化。3.4 反馈回路缺失没有纠错的学习闭环人之所以能从经验中成长是因为存在“行动 → 反馈 → 修正”的闭环。传统编程中你可以通过编译失败、运行时报错、线上告警获得反馈。每次修一个 bug你就对这个系统多一层理解。LLM 出现后反馈回路变成了“报错 → 粘贴给 AI → 得到修复方案 → 继续开发”。这个回路里没有你自己的分析过程也没有真正的认知修正。你没有做错也就没有从错误中学习。这是编程停滞最隐蔽也是最危险的一点表面上一路通畅但每一次都是同一水平的你。这也是为什么有些团队在使用 LLM 半年后代码产出速度很快但一旦核心成员离职接班人完全接不住这套系统——因为没有人深度理解这些代码的“为什么”所有人都只看到了“是什么”。4. 工程层面的具体风险4.1 代码质量重复与依赖膨胀LLM 不擅长从全局视角判断“这段代码是否已经存在”。于是你会看到项目里出现大量重复逻辑三个文件里各有一个formatTime函数每个的实现细节略有不同有人用 A 库发送 HTTP 请求有人用 B 库两人都说是 AI 推荐的项目依赖里同时出现两个功能高度重叠的库。这种问题靠 LLM 自己发现不了需要人工做架构审查。但如果开发者已经习惯完全依赖 LLM 输出往往没有动力去清理。小项目里这是卫生问题大项目里这会直接拖慢构建速度增加安全审计范围最终变成技术债的一部分。4.2 安全风险LLM 生成的漏洞安全社区已经有大量研究指出LLM 生成的代码中会出现已知的漏洞模式SQL 注入、路径穿越、不安全的反序列化、缺少输入校验。关键问题在于如果一个开发者的安全知识本身就不够扎实他很难识别这些代码中的风险点。他会认为“AI 写的代码应该没有低级错误”然后把存在隐患的代码直接提交上去。这不是 LLM 的问题而是使用者的能力与信任度不匹配的问题。AI 可以帮你写代码但它不能代你建立安全意识。安全能力的培养仍然依赖阅读漏洞报告、分析攻击路径、复现问题等传统学习路径这些路径无法被自动生成代码替代。4.3 架构腐化没有人理解整体架构决策需要理解业务目标、数据流向、团队协作模式和演进方向。LLM 参与的单点代码生成无法感知这些全局约束。所以LLM 辅助编程到后期容易出现架构腐化局部代码合理整体结构混乱。每个函数单独看都写得挺工整但模块之间的关系越来越复杂调用链越来越长数据流向越来越不清晰。这种问题不像 bug 那样直接暴露它藏在代码组织的深处最终以“系统越来越难改”的形式呈现。等到架构需要调整时团队会发现没有人能够完整说出系统当前的工作方式因为系统中的大部分代码已经不是“人写出来的”而是“AI 拼出来的”。4.4 调试能力的断崖调试能力是编程能力的温度计。它要求你读代码、跟踪状态、提出假设、验证假设最终定位问题根因。LLM 辅助编程时代很多开发者的调试流程变成了“把报错信息复制给 AI让它给修复方案”。如果 AI 一次没修好就接着问循环往复。这种模式下开发者实际上退出了调试过程只保留了“复制粘贴”这个动作。结果显而易见当遇到 LLM 也没有见过的、需要结合业务上下文或系统全局状态才能定位的 bug 时开发者会非常被动。因为他的调试能力从来没有跟上他写的代码复杂度。5. 如何识别自测清单与量化指标5.1 个人自测先回答这 10 个问题维度自查问题独立编码不借助任何 AI 工具能否从零写出一个带错误处理的小模块代码解释能否完整解释昨天提交代码中每一行的作用调试定位遇到 bug 时是否先阅读报错栈和日志而不是直接贴给 AI设计决策能否说清你最近一次技术选型的理由和取舍条件依赖关系项目的核心依赖是否升级过升级时你了解会影响哪些模块吗代码审查你上次在 code review 中提出具体改进建议是什么时候测试编写你写的代码是否有配套测试测试是你自己写的还是 AI 生成的架构理解能否画出当前项目核心模块的依赖关系图编程热情你最近有没有因为“想弄明白”而去读源码知识更新最近一次通过阅读文档或源代码学到新知识是什么时候如果答案中有 5 项以上是“否”说明你已经处在停滞边缘。不需要恐慌但需要立刻调整使用 AI 的方式。5.2 团队健康度量化指标参考团队层面的停滞更隐蔽也更难通过主观感受发现。可以配合一些量化指标做辅助判断。指标一代码重复率。可以把jscpd这类工具接入 CI 流水线定期输出重复代码占比。# 安装 jscpd 并分析项目重复度 npm install -g jscpd jscpd ./src --min-lines 5 --min-tokens 50 --output ./reports/jscpd-report.json重复率持续上升说明团队内部可能出现了大量不经统一设计的 AI 生成代码。指标二测试覆盖率的有效性。只看行覆盖率不够还要看断言密度。# 统计测试文件中的断言数量结合覆盖率做交叉对比 grep -r expect(\|assert(\|should( tests/ | wc -l如果覆盖率很高但断言数量很低测试可能只是为了通过流水线而生成的垃圾用例。指标三代码评审参与度。统计最近 30 天的 merge request 中有多少条评论是实质性技术讨论有多少只是“LGTM”。# 伪代码按 MR 评论类型统计评审质量 # 输入MR 评论列表 # 输出实质性评论占比 def count_substantive_comments(comments): substantive_keywords [为什么, 考虑, 风险, 重构, 性能, 边界, 安全] total 0 substantive 0 for comment in comments: if comment.is_generated_by_author: continue total 1 if any(kw in comment.content for kw in substantive_keywords): substantive 1 if total 0: return 0.0 return round(substantive / total, 2) report { total_comments: 87, substantive_ratio: count_substantive_comments(comments_data) } print(report) # 输出示例{total_comments: 87, substantive_ratio: 0.46}如果这个比例低于 0.3说明 code review 正在变成流程摆设这是一个非常危险的信号。5.3 代码库症状如何从仓库上发现停滞在 Git 仓库层面有几个可以用来快速判断异常的信号。仓库症状可能原因建议行动单个文件超过 1000 行且没有拆分AI 持续向同一函数追加逻辑手动重构禁止 AI 修改该文件出现大量_v2、_final、_copy命名开发者不理解已有实现直接让 AI 重写清理重复实现明确唯一实现依赖文件体积急剧膨胀每次用 AI 解决问题都顺手引入新库审计依赖建立依赖引入规范大量注释缺失但代码风格统一AI 生成代码未被人工消化增加解释型注释要求README 更新频率远低于代码提交团队已无法用自然语言描述系统状态恢复文档更新制度这些信号不需要跑复杂工具打开仓库扫一遍就能看到。早点发现代价很小拖到架构腐化后再处理成本会高几个数量级。6. 避免编程停滞个人层面的工程方法6.1 设定“无 AI 时段”如果想保住自己的核心编程能力最简单有效的方法是给自己设定一个“无 AI 时段”。具体操作方法每周固定 2 到 4 个小时关闭所有 AI 辅助工具。只靠编辑器、编译器和调试器完成一个真实任务。任务不一定大但必须包含设计、编码、调试三个完整环节。关键点是不要用“这个任务太简单没必要写”来跳过。无 AI 时段的目的是恢复大脑的编程回路而不是产出高效代码。你可以选一些日常工作里最不想做的、难度中等的任务比如重构一个老模块、复现一个偶现 bug、优化一个慢查询。持续几周后你会明显感觉到回归 AI 辅助工作时你能更清晰地判断它生成代码的优劣而不是被动接受。6.2 强制解释让 LLM 输出带理由的代码继续用 LLM 没问题但要在提示词里加入解释要求。请为下面的需求生成代码并完成以下要求 1. 每个关键函数注明时间复杂度和空间复杂度。 2. 对非平凡的逻辑给出详细注释说明为什么这样实现。 3. 列出这段实现可能的边界条件和失败场景。 4. 如果存在多种实现方案请对比后说明推荐哪种及原因。 需求实现一个支持并发读取、过期自动清理的内存缓存。这种提示词的目的是把“隐藏的设计决策”显式化。你不用自己去推导一切但至少能看到关键决策的轮廓。之后再独立判断这些理由是否成立能判断说明你在成长不能判断说明这个知识点你需要补课。6.3 坚持“核心代码人工编写”每个项目里都应该有一份“不允许 AI 修改”的清单。典型的清单内容文件类型理由核心业务规则引擎出错影响面大需要人工精确控制安全鉴权与权限判断安全逻辑不能用“看起来对”的代码支付/计费等资金相关逻辑需要审计和溯源人工可读性优先数据库迁移脚本时序敏感AI 无法感知线上数据状态高并发核心路径性能瓶颈需要人工理解和调优这些文件不是“永远禁止 AI 参与”而是要求审核严格度更高。开发者需要亲自写或者至少写完后能逐行解释。如果无法解释不能合并。这样做的意义在于每个团队保底有一块“技术飞地”维护着最核心的工程能力。6.4 用测试倒逼理解让开发者验证自己是否真的理解代码最直接的方法是要求他为代码编写测试。要求是测试不能只覆盖正常路径至少要包含一个边界条件和异常场景。import pytest from cache import TTLCache def test_cache_returns_none_for_expired_key(): cache TTLCache(ttl_seconds1) cache.set(key, value) # 模拟时间流逝到过期之后 cache._now lambda: cache._now() 2 value cache.get(key) assert value is None, 过期缓存不应返回值 def test_cache_evicts_only_expired_entries(): cache TTLCache(ttl_seconds10) cache.set(a, 1) cache._now lambda: cache._now() 11 cache.set(b, 2) # 写入 b 时应当触发清理 assert cache.get(a) is None assert cache.get(b) 2如果开发者能独立写出类似测试说明他对缓存的过期机制、清理时机和边界行为有实际理解。如果他只让 AI 生成测试、直接粘进仓库那么这个流程就失去了意义。团队层面可以通过抽查方式落实这一点。6.5 定期阅读源码和文档这个动作和 AI 无关但在 AI 时代变得更重要。每周花 30 分钟读一个你当前项目依赖的第三方库的源码。可以只读一个函数、一个类的实现关键是理解它“为什么这样做”。比如你用了 HTTP 客户端库就去看它的连接池实现用了缓存库就去看它的淘汰策略。你读得越多越能感受到 LLM 生成代码中那些“看似正确但缺少工程考量”的部分。这种感知力是防止编程停滞最有效的免疫系统。7. 团队层面的工程实践7.1 人机结对让 AI 扮演“建议者”而不是“执行者”个人可以靠自觉控制 AI 的使用方式团队则需要把它制度化成协作模式。推荐的一种做法是“人机结对”人类工程师负责架构设计、模块切分和验收标准LLM 负责生成符合标准的实现片段再由人类工程师逐行审查并合入。这跟“把整个需求发给 AI直接把结果提交”有本质区别。前者把 AI 当成一个经验丰富的执行者把开发者保留在设计者和审查者的位置后者则取消了开发者的思考环节。落地方式任务拆分时明确哪些子任务可以给 AI 生成哪些必须人工编写。AI 产物进入代码库前必须经过一次人工修改哪怕只是变量重命名或添加注释。禁止未经修改就直接提交 LLM 生成的完整代码。这个流程会让 AI 使用效率稍微下降但能保住质量底线长期看是值得的。7.2 建立 AI 代码审查基准当 AI 参与代码生成后传统的 code review 基准已经不够用。需要增加专属于 AI 生成代码的检查项。# .ai-ai-code-review-rules.yaml 示例 # 用于 AI 生成代码的合并前检查项 rules: - id: REQUIRED_EXPLANATION message: AI 生成的复杂代码必须附实现说明包含设计选择和已知边界。 level: error - id: BANNED_GENERIC_TEMPLATE message: 禁止无差异复制上一个模块的模板代码必须按当前场景调整。 level: warning - id: DEPENDENCY_GUARD message: 新增依赖必须注明用途并说明与现有依赖的功能差异。 level: error - id: TEST_QUALITY message: AI 生成的测试必须包含至少一个边界条件用例。 level: warning这套规则不要求很复杂核心是让团队成员形成习惯AI 生成的代码不等于免检代码必须经过同样的质量标准。7.3 重构 AI 滥用的重复实现当仓库里出现“三个文件各有一个 formatTime”的情况时要当成一个问题来处理而不是下一次顺手就把第四个也加上。操作步骤扫描全仓库找出功能相同或多处重复的代码片段。人工设计统一的公共实现明确参数和使用方式。让 AI 负责“把旧调用替换成新实现”这种机械性工作。人工检查替换后每个调用点的语义是否正确。这个流程的好处是人决定了“应该是什么样”AI 负责执行。知识导向在人这边工作量交给 AI既保效率又保理解。7.4 知识分享与文档制度LLM 让代码产出加速但文档往往会被忽略。没有文档团队对系统的理解会越来越依赖“临时问 AI”而不是沉淀在组织内部。建议在团队内恢复以下制度每次重要的架构调整后由负责人写一篇 200 字以上的变更说明。每个核心模块至少有一名“负责人”能完整解释其实现。每季度安排一次代码走查重点是人能不能讲清楚自己的代码而不只是跑通。这套东西不复杂但能有效对抗编程停滞在团队层面的蔓延。8. 常见误区和判断排查8.1 关于 LLM 与编程停滞的三个误区误区事实“用 LLM 写代码就是高效开发”短期产出高不代表工程能力高维护成本会滞后暴露“AI 会取代程序员学不学习无所谓”恰恰相反能评估 AI 输出质量的人最有价值“停止用 AI 就能避免停滞”完全不用 AI 会丢掉效率优势问题在于使用方式核心不是“用或不用”而是使用 AI 的同时是否保留自己的判断和练习回路。8.2 个人状态排查表状态表现可能原因排查方向应对建议离开 AI 不会写代码长期未做无 AI 练习能否独立完成一个带错误处理的小模块设置每周无 AI 时段代码能跑但讲不清设计理解浅化只接受了结果能否说清关键函数的时间/空间复杂度增加解释型提示词遇到 bug 只会贴给 AI调试能力退化是否先读报错栈和日志再求助强制自己定位到具体行再问 AI测试覆盖率很高但质量低AI 生成了大量无效测试是否存在断言密度不足抽查 AI 测试中的边界用例仓库重复代码不断增加没有统一设计AI 按需生成是否重复实现了相同功能做一次重复代码清理8.3 团队状态排查表团队表现可能原因排查方向应对建议MR 评论大量是“LGTM”code review 流于形式统计实质性评论占比建立 AI 代码审查基准依赖快速膨胀每个问题都引入新库是否有依赖引入规范审计并限制新增依赖核心人员离职后无人接盘知识只在 LLM 会话里没有沉淀文档与负责人制度是否有效恢复文档和走查制度线上事故后根因分析做不下去团队对系统理解不够能否讲清调用链与会话模型建立核心模块负责人制度代码提交量很大但迭代速度变慢技术债在累积重构频率是否下降定期做架构审查9. 关键结论与行动清单这篇文章需要你记住的核心结论只有三条第一LLM 不是编程能力下降的原因无意识的依赖才是。工具越强大使用者越需要保持对输出质量的判断力。第二编程能力靠“行动 → 反馈 → 修正”闭环维持任何跳过这个闭环的工具都会加速停滞。这决定了你使用 LLM 的方式应当是“辅助判断”而不是“替代判断”。第三停滞是可以逆的而且越早干预代价越小。每周 2 小时无 AI 练习、强制代码解释、核心代码人工编写这三件事只要坚持 4 周你就能感受到明显变化。值得马上采取的行动按优先级排列今晚回答一次本文章节 5.1 中的 10 个自测问题。本周设置第一个“无 AI 时段”完成一个真实任务。下周开始给 LLM 提示词加上“解释设计决策”的要求。如果你是技术负责人把 7.2 质量门禁规则落地到仓库里并抽查一个月。关于 LLM 辅助编程最终的判断标准不是“它帮你写了多少代码”而是“你还能不能独立写出一段自己完全理解的代码”。如果答案变得越来越模糊那不管当前交付速度多快都该停下来重新校准一下使用方式了。毕竟工具可以换能力长在自己身上。别让“生成代码”代替“理解代码”也别让每天的提交记录掩盖掉一年后的寸步难行。