企业官网建设流程全解析

如果你过去一年里一直在用 LLM 写代码，而且觉得效率高了不少，那这篇文章值得停下来看完。因为我们要讨论的不是“LLM 好不好用”，而是一个正在开发者圈子里被反复提起但很少有人系统说清楚的概念——Programmatic Stagnation（编程停滞）。

简单说，它描述的是这样一种状态：你每天提交的代码越来越多，但脱离 AI 后写代码、读代码、修代码的能力却在明显退化。功能开发看起来很快，真正出问题时却寸步难行。LLM 提升了产出速度，却没有同步提升开发者对系统的理解，甚至还在削弱它。

这篇文章主要解决 4 个问题：

1. 什么是 Programmatic Stagnation，它的表现和触发机制是什么。
2. LLM 辅助编程为什么容易带来停滞，而不只是“效率提升”。
3. 如何用工程化手段识别自己或团队是否已经进入停滞。
4. 哪些实操方法可以在保留 LLM 效率的同时，避免技能空心化。

文章后面会给出自测脚本、代码示例、排查表格和一套可以直接落到团队协作里的检查流程。不管你是个人开发者、技术 leader，还是正在用 AI 写业务代码的工程团队，都建议按文中的清单做一次自查。

1. 核心概念速览

一句话概括：编程停滞不是“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 个问题

如果答案中有 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 仓库层面，有几个可以用来快速判断异常的信号。

这些信号不需要跑复杂工具，打开仓库扫一遍就能看到。早点发现，代价很小；拖到架构腐化后再处理，成本会高几个数量级。

6. 避免编程停滞：个人层面的工程方法

6.1 设定“无 AI 时段”

如果想保住自己的核心编程能力，最简单有效的方法是给自己设定一个“无 AI 时段”。

具体操作方法：

• 每周固定 2 到 4 个小时，关闭所有 AI 辅助工具。
• 只靠编辑器、编译器和调试器完成一个真实任务。
• 任务不一定大，但必须包含设计、编码、调试三个完整环节。

关键点是：不要用“这个任务太简单没必要写”来跳过。无 AI 时段的目的是恢复大脑的编程回路，而不是产出高效代码。你可以选一些日常工作里最不想做的、难度中等的任务，比如重构一个老模块、复现一个偶现 bug、优化一个慢查询。

持续几周后你会明显感觉到：回归 AI 辅助工作时，你能更清晰地判断它生成代码的优劣，而不是被动接受。

6.2 强制解释：让 LLM 输出带理由的代码

继续用 LLM 没问题，但要在提示词里加入解释要求。

请为下面的需求生成代码，并完成以下要求： 1. 每个关键函数注明时间复杂度和空间复杂度。 2. 对非平凡的逻辑给出详细注释，说明为什么这样实现。 3. 列出这段实现可能的边界条件和失败场景。 4. 如果存在多种实现方案，请对比后说明推荐哪种及原因。 需求：实现一个支持并发读取、过期自动清理的内存缓存。

这种提示词的目的是把“隐藏的设计决策”显式化。你不用自己去推导一切，但至少能看到关键决策的轮廓。之后再独立判断这些理由是否成立，能判断，说明你在成长；不能判断，说明这个知识点你需要补课。

6.3 坚持“核心代码人工编写”

每个项目里都应该有一份“不允许 AI 修改”的清单。

典型的清单内容：

这些文件不是“永远禁止 AI 参与”，而是要求审核严格度更高。开发者需要亲自写，或者至少写完后能逐行解释。如果无法解释，不能合并。

这样做的意义在于：每个团队保底有一块“技术飞地”，维护着最核心的工程能力。

6.4 用测试倒逼理解

让开发者验证自己是否真的理解代码，最直接的方法是要求他为代码编写测试。

要求是：测试不能只覆盖正常路径，至少要包含一个边界条件和异常场景。

import pytest from cache import TTLCache def test_cache_returns_none_for_expired_key(): cache = TTLCache(ttl_seconds=1) 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_seconds=10) 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”的情况时，要当成一个问题来处理，而不是下一次顺手就把第四个也加上。

操作步骤：

1. 扫描全仓库，找出功能相同或多处重复的代码片段。
2. 人工设计统一的公共实现，明确参数和使用方式。
3. 让 AI 负责“把旧调用替换成新实现”这种机械性工作。
4. 人工检查替换后每个调用点的语义是否正确。

这个流程的好处是：人决定了“应该是什么样”，AI 负责执行。知识导向在人这边，工作量交给 AI，既保效率又保理解。

7.4 知识分享与文档制度

LLM 让代码产出加速，但文档往往会被忽略。没有文档，团队对系统的理解会越来越依赖“临时问 AI”，而不是沉淀在组织内部。

建议在团队内恢复以下制度：

• 每次重要的架构调整后，由负责人写一篇 200 字以上的变更说明。
• 每个核心模块至少有一名“负责人”能完整解释其实现。
• 每季度安排一次代码走查，重点是人能不能讲清楚自己的代码，而不只是跑通。

这套东西不复杂，但能有效对抗编程停滞在团队层面的蔓延。

8. 常见误区和判断排查

8.1 关于 LLM 与编程停滞的三个误区

核心不是“用或不用”，而是使用 AI 的同时是否保留自己的判断和练习回路。

8.2 个人状态排查表

8.3 团队状态排查表

9. 关键结论与行动清单

这篇文章需要你记住的核心结论只有三条：

第一，LLM 不是编程能力下降的原因，无意识的依赖才是。工具越强大，使用者越需要保持对输出质量的判断力。

第二，编程能力靠“行动 → 反馈 → 修正”闭环维持，任何跳过这个闭环的工具都会加速停滞。这决定了你使用 LLM 的方式应当是“辅助判断”，而不是“替代判断”。

第三，停滞是可以逆的，而且越早干预代价越小。每周 2 小时无 AI 练习、强制代码解释、核心代码人工编写，这三件事只要坚持 4 周，你就能感受到明显变化。

值得马上采取的行动，按优先级排列：

1. 今晚回答一次本文章节 5.1 中的 10 个自测问题。
2. 本周设置第一个“无 AI 时段”，完成一个真实任务。
3. 下周开始，给 LLM 提示词加上“解释设计决策”的要求。
4. 如果你是技术负责人，把 7.2 质量门禁规则落地到仓库里，并抽查一个月。

关于 LLM 辅助编程，最终的判断标准不是“它帮你写了多少代码”，而是“你还能不能独立写出一段自己完全理解的代码”。如果答案变得越来越模糊，那不管当前交付速度多快，都该停下来重新校准一下使用方式了。

毕竟，工具可以换，能力长在自己身上。别让“生成代码”代替“理解代码”，也别让每天的提交记录，掩盖掉一年后的寸步难行。