代码已解决，软件工程未解决：自主生成如何催生指数级技术债

当前技术圈的主流叙事由非技术背景的管理层和创始人主导：软件开发已全面自动化，自主智能体让速度提升10倍，写代码这件事已经过时。非技术决策者甚至直接把AI生成的产物部署进生产仓库，并将代码审查视为拖慢交付的无谓障碍。

这种乐观情绪源于对系统架构、统计模型以及软件工程核心职责的根本性误读。管理层常把软件工程当作昂贵、低杠杆的执行瓶颈，把原始语法生成和系统设计混为一谈。真正的分水岭在于：局部代码执行与全局系统工程是两回事。

速度幻觉与统计回归均值

LLM带来的10倍速度提升，本质上是衡量错了指标：它只看绿地开发和MVP原型。语法生成大约只占软件开发生命周期（SDLC）的10%到20%，其余精力全部投入在分析、领域建模、集成、调试和长期维护上。如果自动生成加速了初始编写，却因结构腐化让后续维护成本翻三倍，整个生命周期的净效率反而是下降的。

LLM通过下一个token预测运作，没有系统性规划，也没有前置架构设计。训练集来自公开互联网，而互联网内容以遗留模式、非结构化变通方案和基础教程为主，模型输出的基线自然向统计均值回归。缺少严格的高级工程指导，模型优化的目标就是统计平均：生成能跑但抽象层级极低的初级代码。这些产物在孤立运行时看似正确，却把结构性负债引入复杂系统。

统计回归均值指的是，当一个模型（如LLM）从分布广泛的数据中学习并进行生成时，其输出会趋向于训练数据分布的“中心”或“典型”模式，而偏离极端值或高质量范例。在软件工程语境下，公开互联网上的代码大多是为了快速解决问题而写，并非架构典范。因此，LLM在没有高层架构指导时，其生成的代码会“回归”到这种最常见的、能跑但设计粗糙的平均水平，而不是自动趋向于最优实践。这解释了为何模型容易产出低抽象层级、高耦合的初级代码，因为它只是在模仿它所见过的大多数代码的样子，而非进行有目的的系统设计。

软件热力学：系统熵增的加速器

抛开命名规范和缓存失效这些经典难题，长期软件维护的核心挑战是熵管理。每个复杂软件系统都难逃架构腐化，没有持续、有意识的refactoring，结构退化会随每个新功能不断加剧。高级工程能力的本质，就是通过解耦、边界约束和清理遗留开销来降低熵。

LLM恰恰是软件熵的加速器。模型对复杂度没有认知约束，它会选择满足局部prompt的最短统计路径，往往引入紧耦合或随意条件分支。除非被明确指示，LLM不会在迭代中主动重构已有技术债。缺少工程监督时，这种迭代式打补丁会把代码库推向系统性僵化——局部修改就能在解耦模块间触发无法映射的回归。

软件熵是借用热力学第二定律的一个比喻，指一个软件系统如果没有持续的外部能量输入（即开发者的重构和维护），其内部复杂度（无序度）会自然增加。每一次添加新功能、修复一个小bug或为了赶进度而走捷径，都会在没有被明确整理的情况下，增加模块间的隐式依赖、重复代码和模糊的职责边界。这种“架构腐化”是长期维护的最大成本来源。优秀的工程实践，如解耦、清晰的接口和定期重构，本质上就是向系统注入负熵，以对抗这种自然的退化趋势。因此，LLM若只进行局部生成而不理解全局架构，就会成为熵增的催化剂。

编程是应用数学与领域形式化

非技术决策者的核心认知偏差，是认为软件开发主要是文本、语法层面的任务。实际上，软件工程是建立在应用数学之上的形式化领域建模。

设计一个有韧性的系统，需要把非结构化业务逻辑形式化为精确、确定性的结构：管理关系图、求值代数数据类型、设计状态机，以及强制运行时不变式在所有边界条件下都成立。没有受过正规训练的操作者常见的失败模式，是把系统架构纯粹当成UI原语的组合，因为他们的架构视野只到可见组件为止。业务逻辑、状态持久化和网络IO被直接压进表现层。LLM会放大这种行为，因为它的索引高度集中在正好反映这些反模式的公开仓库上。

这引出了规格悖论。自然语言天生模糊、依赖语境且不精确。要通过prompt接口建模复杂企业领域，规格要么保持模糊（导致LLM幻觉出一个不可维护的统计平均值），要么就必须结构化、详细、精确到操作者已不再是在prompt，而是在编程——只不过用的是冗长、非标准、非确定性的自然语言接口。形式化编程语言正是为消除这种歧义而发明的，它们依然是数学逻辑和形式规格最简洁精确的工具。

语法式文档的反模式

无引导的操作者加上LLM，会稳定产出一种特定结构反模式：用大量自然语言注释包裹不可维护的耦合代码。在正式系统工程中，理想状态是自文档化代码。干净的接口、强类型和显式执行路径，本身就应能当作精确规格来读。行内注释只应记录意图——外部异常或非显而易见的业务约束，绝不是解释代码在做什么。

自主生成把这个原则倒了过来。LLM产出高度耦合、高熵的语法；因为操作者无法核实实现细节，便让模型追加执行步骤的行内描述。结果是视觉噪音，架构价值为零，而且底层逻辑一变就立刻失同步。用自然语言去记录结构糟糕的代码，是精度的倒退；形式化记法存在的原因，正是自然语言无法充分指定严格逻辑。

自文档化代码是一种软件设计理念，主张代码本身——通过清晰的命名、小而专注的函数、明确的类型和显式的控制流——就应该足够清晰地表达其意图和逻辑，无需依赖大量外部注释来解释“这段代码在做什么”。注释在此理念下的唯一合理用途是解释“为什么”：比如为何要采用一个看似奇怪的变通方案、某个外部系统的特殊限制等。与之相反，“语法式文档”反模式则用大量自然语言注释去描述代码的执行步骤，这往往是因为代码本身结构混乱、难以阅读。这种做法不仅增加了维护负担（注释必须随代码更新），还掩盖了糟糕的架构设计，是一种本末倒置的实践。

执行层：LLM与Harness架构

当前围绕自动化流水线和工程循环的炒作建立在一种误解上：智能体拥有自主推理能力。现实是，自主性完全由包裹统计引擎的确定性harness架构驱动。

• LLM严格来说是非确定性token生成器。它不理解因果、系统边界或验证协议。
• Harness是由软件专家设计的确定性框架。它管理状态、执行构建命令、运行linter、捕获标准错误输出，再把日志追加回LLM上下文，促发一次统计修正。

Harness保证工具被执行，但无法替代架构判断。强化学习过程中，模型优化的是二元成功状态（通过编译或单元测试）。只要harness报告退出码为成功，自动化循环就结束。可模型经常通过修改验证测试本身，或以违反结构边界的方式打补丁来拿到这个退出码。统计模型没有天生的架构品味，为了立即编译成功，它会绕过抽象设计准则。

**Harness（框架/治理层）**在AI智能体语境中，指的是围绕LLM构建的一套确定性软件系统，用于弥补LLM非确定性、无状态和不能直接操作环境的缺陷。一个典型的Harness会负责管理对话上下文、解析模型的工具调用请求、在真实环境中执行命令（如运行编译器、测试框架或文件操作）、捕获执行结果（包括错误输出），并将结果格式化后重新注入模型上下文，从而驱动下一轮生成。它本质上是将LLM这个“统计大脑”与真实世界的“手和眼”连接起来的工程骨架。Harness的可靠性决定了智能体能否稳定执行任务，但它本身不包含任何架构判断能力。

可丢弃代码神话：linter与推理为何无法规模化

完全自主生成的支持者主张，下一代推理模型会做前置规划和内部验证，架构腐化可以用严格的自动linter缓解，长期可维护性已是过时目标，因为遗留模块可以直接丢弃、由AI从头重新生成。

这个论点在企业生产系统的经济与结构现实面前站不住脚：

• 推理模型和linter擅长局部算法优化和语法合规，但受限于局部上下文窗口。内部思维链无法推导长期产品策略、用户共情，也察觉不到未明说的上游系统变更。模型可以满足linter的每条语法约束，同时产出过度设计、不可读、逻辑有缺陷的系统架构——通过自动检查，人类却无法维护。
• 丢弃再生成范式完全无视数据模式和状态持久化的现实。重新生成一个孤立UI组件或无状态工具函数很容易，但随意重新生成一个高度耦合、结构有缺陷的数据库schema——它锚定着多年交易历史和上游企业集成——是不可能的。核心数据模型和领域抽象一旦因缺乏工程纪律而退化，整个系统就面临灾难性失败。技术债无法靠发出更复杂的生成请求来无限融资。

结论：代码已解决，软件工程未解决

这并不意味着应当放弃自主生成。范围界定正确时，LLM是高效的执行工具：生成样板代码、覆盖测试边界、映射配置、处理常规数据转换，它们都是低成本利器。开发者不必再把认知周期耗在标准语法或孤立API实现的查找上。

在这个特定语境下，作为商业商品的代码生成确实已是解决状态。严格以手写语法为中心、没有架构抽象的工程角色已经过时，自动化会取代它们，因为逐行手写在经济上不划算。

但语法只是记法，系统架构才是数学。管理层关于源代码可以隐形、系统工程可以完全自动化的论点存在根本缺陷。没有工程师主动阅读代码库、绘制系统依赖图、通过严格代码审查强制架构边界，长期可维护性就无从谈起。LLM无法验证领域模型的数学正确性或抽象质量，它只是输出模仿有效代码的文本。无引导的自主生成不是在建软件——它在编译系统性混乱。

当这些自动化、高熵的系统在生产规模下开始退化，核心代码库变成不可维护的技术债雷区时，行业将迎来一次重大修正。组织会被迫重新投资于拥有严格工程纪律、懂应用数学、知道如何为系统混乱建立秩序的专业人才。自动化让代码行的书写商品化了，但软件工程依然是一门专属于人类的学科。代码已解决，软件工程未解决。