在分形生成实验（三）：Rust强类型驱动的后端分步实现与编译时契约中，我们展示了如何以Rust的强类型系统为“契约守卫者”，驱动AI生成一个能成功编译的后端骨架。当时我满怀信心地认为：“只要能编译，就说明分形单元已对齐全局契约。”然而，今日的实践体验却给我泼了一盆冷水——编译通过，远不等于系统可信。

一、幻觉的裂缝：当“能编译”掩盖了逻辑缺失

在尝试运行AI生成的单元测试时，我遭遇了意料之外的断裂：

error[E0432]: unresolved import `crate::repositories::user_state::MockUserStateRepository`

更令人警觉的是，在排查此问题时，我发现一个名为 generate_cookie 的函数——它赫然出现在测试代码中，却在主业务逻辑里完全缺席。设计文档中虽规定了“会话需安全生成标识”，但并未指定该函数名；它是AI在生成测试时“自行发明”的产物。

这两个现象共同指向一个严峻现实：Rust的类型系统能确保接口形状一致，却无法验证行为意图是否被正确实现。AI生成的代码通过了编译器的语法审查，却可能遗漏关键流程，甚至创造出“只活在测试中的幽灵函数”。这暴露了当前“分形实验”的致命短板：我们只有静态契约，没有动态验收标准。

二、从静态契约到动态验证：构建行为验收闸门

既然无法重做整个生成过程，我们便在现有代码基础上，尝试构建一道“行为验证闸门”。以下是几个值得探索的方向：

1. 定义“最小可验收场景”（Minimal Acceptable Scenarios, MAS）

放弃对“全覆盖”的幻想，转而聚焦核心业务路径。例如：

• MAS-01：携带有效Token请求 /startAnalyze → 响应状态码200，且Set-Cookie头包含签名安全的会话ID。
• MAS-02：配额耗尽时调用分析接口 → 返回429，且LLM客户端未被触发。

将这些场景编写为集成测试（而非单元测试），直接调用API端点并断言外部可观测行为。它们不关心内部函数名是否叫 generate_cookie，只验证“安全会话标识是否被正确设置”。

2. 契约即测试：让设计文档驱动验收

将设计文档中的关键流程描述，直接转化为BDD（行为驱动开发）风格的验收测试。例如：

Feature: Secure Session Management
  Scenario: New user starts analysis
    Given a valid authentication token
    When POST /startAnalyze is called
    Then a secure HttpOnly cookie named "session_id" is set
    And the response body contains a task ID

即使不使用 cucumber 等框架，也可用普通Rust测试函数模拟此结构。关键是让验收标准与设计意图显式对齐，而非依赖AI对“合理实现”的模糊猜测。

3. 引入静态分析，捕捉“幽灵代码”

在CI流程中加入轻量级检查工具：

• 使用 cargo-machete 扫描未使用的函数（如孤立的 generate_cookie）；
• 使用 cargo-tarpaulin 生成覆盖率报告，确保核心模块（如Handler、Service）被MAS覆盖；
• 通过 clippy 自定义lint规则，禁止“测试专用函数”出现在非测试模块。

这些工具无法证明逻辑正确，但能快速暴露“死代码”或“未覆盖路径”，为人工审查提供焦点。

三、结语：分形的一致性，需由运行时来见证

“分形生成”的理想，是每个局部单元都能自洽地反映整体结构。但若缺乏对行为一致性的验证，再完美的类型契约也只是一座空中楼阁。Rust的编译器是我们最忠实的守卫者，但它只能守住“形式”的边界；真正的分形一致性，必须由运行时的行为来见证。

本次探索并非终点，而是一次认知校准：在AI协作开发中，程序员的核心职责正从“写代码”转向“定义可验证的契约”。下一次实验，我们将尝试将MAS与设计文档一同注入AI生成流程，看看能否让“验收标准”成为驱动分形单元生长的新引擎。

📩 交流与合作：欢迎通过CSDN私信或cli_assistant仓库分享你的AI协作验收实践！