AI 代码洪水正在侵蚀软件设计：如何遏制「认知债务」蔓延

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

虽然 AI 代码生成器帮助团队以前所未有的速度交付产品，但这种速度带来了一种隐藏的杀手：理解债（Comprehension Debt）。一旦 AI 生成的代码在功能上正确、却违反了你的领域边界，团队就会失去对系统的心智模型。在这里，我将展示如何从被动文档转向可执行架构（Executable Architecture），使用基于 Python 的测试工具如 pytest-archon 和 CI/CD 流水线。

AI 编码智能体（Agent）能做的最危险的事情，就是生成能工作的代码。

如果一个初级开发者写了糟糕的代码，会导致构建或预发布环境崩溃。团队会发现它、回滚它、并讨论它。但如果一个 AI 编码智能体生成了 500 行功能正确且无 bug 的代码，却微妙地违反了系统的边界，它就会毫无问题地被合并。

"AI 编码智能体能做的最危险的事情，就是生成能工作的代码。"

渐渐地，AI 将你的计费服务连接到用户认证组件。它让表现层获得了数据库访问权。它以一种能工作、但违反了维护系统的人类开发者设计假设的方式连接依赖。

技术债已经让位给更紧迫的问题——理解债：代码编写速度与人类团队理解其架构程度之间日益扩大的差距。问题不在于逻辑混乱，而在于心智模型的丧失。当团队不再知道代码库存在的原因时，这种情况就会发生。

如果你把 AI 视为一台更快打字的机器，架构就已经开始退化。要在 AI 驱动编码的时代中持续发展，架构执行必须转变——从文档转向可执行架构。

文档的幻象

关于 AI 辅助开发的公认指导是："制作更好的文档，让 AI 理解规则。"

这是一个谬论。文档会变得过时。如果你的 AI 智能体发现一条更简单的路径来达成目标——比如跳过服务层——它就会走那条路。而且由于人类评审者越来越难以审查成千上万份 AI 生成的 Pull Request，这些绕道会在代码审查中溜过。

"你不能依赖人类来检测架构漂移。你必须信任 CI/CD 流水线。"

你不能依赖人类来检测架构漂移。你必须信任 CI/CD 流水线。

如果你的架构边界很重要，就要像检查任何业务需求一样检查它们。我们需要健身函数（fitness functions），当 AI 智能体违反边界条件时，让构建失败。

在 Python 中引入可执行架构

在 Java 生态系统中，ArchUnit 等工具传统上用于强制执行架构边界。在 Python 中，pytest-archon 做同样的工作。

考虑一个具体的例子。你为电子商务应用构建了一个模块化单体（modular monolith），并建立了严格的边界：

计费领域永远不应该从物流领域导入。

领域模型代码不应该从基础设施（AWS SDK、SQLAlchemy 等）导入。

你给 AI 智能体分配任务：根据用户的计费等级添加运费计算。AI 没有考虑架构，直接将物流计算器导入计费服务。测试通过。应用能工作。但架构失败了。

以下是 pytest-archon 如何阻止智能体这样做的方法。

步骤 1：安装依赖

首先，安装架构测试依赖。

pip install pytest-archon

步骤 2：将架构规则定义为测试

不是在 Wiki 页面上查找规则，而是将它们定义为 pytest 功能。我们在测试文件夹中创建 test_architecture.py 文件。

from pytest_archon import archrule

def test_billing_is_isolated_from_shipping():
    """
    Ensure the billing module never imports shipping logic.
    This prevents the AI from creating tight coupling between distinct domains.
    """
    (
        archrule("billing_isolation", comment="Billing must not know about shipping")
        .match("ecommerce.billing*")
        .should_not_import("ecommerce.shipping*")
        .check("ecommerce")
    )

def test_domain_models_are_pure():
    """
    Ensure domain models only depend on standard libraries or pydantic.
    Prevents the AI from leaking infrastructure (DBs, APIs) into the core logic.
    """
    (
        archrule("pure_domain", comment="Domain models must not import infrastructure")
        .match("ecommerce.*.models")
        .should_not_import("sqlalchemy*")
        .should_not_import("boto3*")
        .check("ecommerce")
    )

步骤 3：关闭智能体反馈循环

然后，一旦 AI 智能体推送其 Pull Request，pytest 作为 CI 工作流的一部分自动运行。无论 AI 智能体生成计算运费代码的能力有多好，构建都会立即失败，类似于：

FAILED tests/test_architecture.py::test_billing_is_isolated_from_shipping -
AssertionError: Rule 'billing_isolation' violated:
ecommerce.billing.invoice imports ecommerce.shipping.calculator

人类评审者不需要手动追踪整个导入树。最重要的是，最优秀的工程团队永远不会依赖人类来做这件事。

再次，我们将这些失败的 pytest 测试的输出直接反馈到 AI 智能体的上下文窗口中，使用 Aider 或自定义 CI/CD 脚本，AI 可以在没有人类帮助的情况下修复架构问题。

避免理解债的策略

仅运行架构测试是不够的。以下是如何保护你的团队免受理解债：

1. 硬边界 vs. 软约定

AI 智能体遵守硬约束，但不遵守软建议。抛弃基于文件夹的松散架构，建立清晰的模块边界。使用 import-linter 或 pytest-archon 等工具用物理屏障阻止禁止的导入。最省力的路径必须是架构上最合理的。

2. 限制自动化复杂度

定义良好的 API 和边界很好，但不足以让你摆脱混乱复杂的实现。如果 AI 在你的计费模块中创建了意大利面代码，导致凌晨 3 点因竞态条件而宕机，人类工程师仍然需要维护和理解那个代码库。

为此，在 CI 流水线中 alongside 运行架构测试和圈复杂度守门人（如 Ruff、Radon 或 SonarQube）。设置硬性复杂度限制，强制 AI 将大函数分解为小函数。

3. 检查接口，而不仅仅是实现

在 AI 生成的 PR 代码审查中，开发者的心智是宝贵资源。别再看每一行代码，试图破译循环和变量赋值。看系统从外部发生了什么变化。相反，检查是否有新的依赖？PR 是否暴露了新的 API 端点？是否更改了数据schema？如果没有，你的心智模型就是完整的。

AI 编码者非常强大，但有一个很大的缺陷——他们非常务实。他们不关心你代码的可维护性——只关心完成你分配给他们的任务。

"AI 编码者非常强大，但有一个很大的缺陷。他们只关心完成你分配给他们的任务。"

如果你试图仅依赖人类因素来控制你的系统设计，你迟早会被理解债淹没。这不是放慢 AI 实现过程的问题——而是让你的环境更具抵抗力的问

你不需要研究 AI 生成代码的每一行。你只需要为这个 AI 创建一个笼子。