在我们持续探索“分形”方法论的实践中，一次意料之外的集成问题，为我们提供了一个值得深思的观察窗口。此前，我们已通过六篇文章，分享了如何利用cli_coder这一编程智能体，以“分形”的方式逐步构建一个强类型的"简历智能体"系统。整个过程强调可组合性、编译时契约和人机协同的边界。然而，当我们将独立验证无误的前后端进行"集成"时，第一个API端点/status便未能如期工作：前端期望的字段，与后端实际返回的字段存在不匹配。

这一情况，让我们重新审视了《分形生成实验（二）》中关于“API合约驱动”的讨论。我们曾设想清晰的契约能成为人机协作的坚实桥梁，而这次的实验结果，则为我们提供了一个反思的契机。

一个同名异义的观察实例

问题的根源，似乎在于两个同名但不同义的UserStatusResponse结构体。这两个结构体分别在“分形”流程的不同阶段被生成：

• 第三阶段（Web层）：在构建API路由和响应格式时，大模型在src/responses.rs中定义了如下结构：

  #[derive(Serialize, Deserialize, Debug)]
  pub struct UserStatusResponse {
      pub user_id: String,
      pub is_new_user: bool,
      pub token_used: u64,
      pub token_limit: u64,
      pub trial_requested: bool,
      pub system_trial_available: bool,
  }
  

  这一定义直接服务于/api/v1/status的Handler，在当时的上下文中是自洽的。

• 第四阶段（业务逻辑层）：在实现TrialsService等业务逻辑时，大模型又在src/models/trials.rs中定义了另一个UserStatusResponse：

  #[derive(Debug, Clone, Serialize)]
  pub struct UserStatusResponse {
      pub is_new_user: bool,
      pub system_daily_limit_reached: bool,
      pub user_token_used: u64,
      pub user_token_limit: u64,
      pub has_requested_trial: bool,
  }
  

  值得注意的是，这个版本的字段，恰好与前端所期望的完全一致。然而，由于最终API的响应使用了第三阶段的定义，导致了集成失败。

回顾当时的指令，我们在第三阶段要求“实现统一的请求/响应格式”，在第四阶段要求“实现TrialsService”。大模型在各自的任务上下文中，都生成了看似合理的代码。但它似乎并未将“UserStatusResponse”视为一个需要在整个项目中保持一致的全局契约。它可能“忘记”了前一个阶段的定义，或者，更可能的是，在缺乏显式复用指令的情况下，它倾向于在新的上下文中创建一个满足局部需求的新类型。

对“分形”方法论执行者能力的初步思考

这一观察，促使我们思考“分形”方法论成功的一个潜在前提：执行者或许需要具备较强的契约感知与上下文连贯性能力。

“分形”的核心思想是，通过定义清晰、自相似的单元，并确保这些单元在组合时能无缝衔接，从而构建出复杂的系统。这里的“无缝衔接”，其基石就是契约的一致性。每一个“分形”单元的输出，必须严格符合其下游单元的输入契约。

对于人类开发者而言，这种契约意识通常是内建的。我们会通过查阅文档、IDE提示等方式，来确保不会重复定义或错误使用一个关键类型。然而，对于当前的大模型，其工作模式更像一个“上下文窗口内的专家”，一旦任务切换到新的抽象层级，它可能会倾向于在新的上下文中重新定义，而非主动追溯和复用已有的全局契约。

因此，本次实验中观察到的现象，可能反映出大模型在执行“分形”这类方法论时，存在两个值得关注的方面：

1. 局部合理性与全局一致性之间的张力：它能在单个任务中生成高质量、类型安全的代码，但要保证这些局部成果在全局视角下能和谐共存，可能需要额外的机制。
2. 契约的显性化需求：它可能将类型定义更多地视为实现细节，而非需要在整个项目生命周期中被严格守护的契约。这或许意味着，我们需要更显式地向模型传达契约的“第一性”。

结语：一次实验，一个待解的课题

这次经历，并非意在否定“分形”方法论，反而凸显了该方法论的价值——正是因为它对结构和契约有着清晰的要求，才使得问题能够被精准地定位。我们更倾向于认为，这反映了当前AI协同编程工具在能力上，与先进方法论的要求之间，可能存在一个需要弥合的gap。

我们的初步看法是：“分形”方法论本身是可行的，但其有效实施，可能对工具链提出了更高阶的要求。我打算为cli_coder开发出具有守护“契约”的能力，这无疑是一个值得我们继续探索和实验的方向。

相关文章:

• 当大模型替我们写完整个系统，开发者还剩下什么？
• 分形生成实验：在有限上下文中构建可组合的强类型单元
• 分形生成实验（二）：API 合约驱动的轻量化强类型协作框架
• 分形生成实验（三）：Rust强类型驱动的后端分步实现与编译时契约
• 分形生成实验（四）：超越编译器——构建AI生成代码的行为验收闸门
• 分形生成实验（五）：人机协同破局–30万token揭示Actix-web状态管理的微妙边界
• 分形生成实验（六）：数据建模–AI 协同编程中被低估的“契约”