领域驱动智能体：为何AI在遗留代码中失效及如何实现“AI就绪”

核心要点

• 环境差异显著：LLM在全新项目（Greenfield）中表现优异，但在充满技术债务的遗留系统（Brownfield）中效率大幅下降。
• 失败的根本原因：遗留代码库中缺乏统一的领域语言和明确的语义，导致AI模型在处理复杂逻辑时频繁产生错误猜测。
• 模型并非瓶颈：AI代理的表现不佳并非因为模型本身需要升级，而是因为代码库尚未做好“AI就绪”的准备。
• 增量式改进路径：通过逐步清理代码异味、明确系统含义，可以使复杂的遗留系统重新获得AI驱动的生产力提升。

详细分析

从“绿地”到“棕地”：AI代理的效能落差

在软件工程领域，LLM（大语言模型）的应用已经展现出巨大的生产力潜力。作者在过去几年的实践中发现，在全新的、小型的“绿地项目”（Greenfield projects）中，AI代理能够精准地理解指令并执行任务。例如，当要求在干净的代码库中添加一个“职位申请状态”字段时，模型通常能完美完成。然而，当同样的任务被置于一个运行多年、拥有沉重依赖树和强耦合关系的“棕地项目”（Brownfield projects）时，AI的表现会发生剧烈波动。这种现象揭示了AI工具在处理现实世界复杂系统时的局限性。

语义缺失与错误的“猜测”

在复杂的遗留系统中，AI代理的失败往往呈现出一种特定的模式。由于代码库在长期的迭代过程中缺乏统一的架构决策，同一个概念可能存在多种不同的实现或拼写方式。当AI代理试图介入时，它往往会发明出第四种拼写方式，或者在不该使用适配器的地方错误地编写适配器。这种行为的本质是：系统本身并没有在任何地方给出明确的答案，导致模型不得不进行猜测。而在技术债务深厚的代码库中，这种猜测往往是错误的。深层的困境在于，技术深度之下隐藏着意义的缺失和共享语言的匮乏，这正是模型陷入困境的“泥潭”。

构建“AI就绪”的代码库

面对AI在遗留代码中的乏力，作者认为解决方案不在于等待更强大的模型，而在于改变代码本身。技术债务是软件开发中为了追求交付速度而产生的自然产物，但它也导致了代码异味（Code Smell）的不断累积。为了让AI重新发挥作用，开发者需要有意识地将工程预算投入到代码清理中。这种改进不需要一蹴而就，而是可以采取增量式（Piece by piece）的方法。通过明确代码的意图、统一领域语言，我们可以构建出一种“就绪性”（Readiness），使遗留系统变得对AI友好，从而打破技术债务对生产力的束缚。

行业影响

该分析为AI时代的软件工程提供了重要的启示。它挑战了“只要模型足够强大就能解决一切代码问题”的盲目乐观情绪，重新强调了领域驱动设计（DDD）和代码整洁之道在AI辅助开发中的核心价值。对于企业而言，这意味着在引入AI代理提升效率之前，必须先解决内部系统的语义一致性和技术债务问题。这可能会推动一波以“AI就绪”为目标的旧系统重构浪潮，使软件维护和演进进入一个新的阶段。

常见问题

问题 1：为什么AI在处理旧代码时会发明重复的概念？

因为遗留代码库（棕地项目）通常缺乏统一的命名规范和架构决策。当系统内部对同一个业务概念有多种表达且没有明确标准时，AI模型无法判断哪一个是“正确的”，从而根据概率生成新的、不一致的代码实现。

问题 2：如何判断一个代码库是否具备“AI就绪”性？

一个“AI就绪”的代码库通常具有清晰的领域语言、低耦合的模块设计以及明确的逻辑表达。如果一个人类开发者在不询问他人的情况下能通过阅读代码准确理解系统逻辑，那么AI代理通常也能较好地处理该系统。反之，如果代码中充斥着歧义和缺失的含义，则不具备就绪性。

问题 3：解决AI在遗留系统中表现不佳的策略是什么？

核心策略是实施增量式的代码改进。开发者应分配部分工程预算用于清理技术债务，通过重构来消除代码异味，并建立共享的领域语言。这种做法旨在为AI提供一个语义明确的上下文环境，减少其错误猜测的概率。