整洁架构遇上AI：利用Cline编写可靠的Java功能代码

整洁架构与AI编程的完美结合，探索Cline在Ja va项目中的应用。

核心内容：

1. 整洁架构在AI编程中的价值和应用

2. 如何将Cline融入整洁架构下的Ja va项目

3. 团队Ma ven项目中package约定及代码编写原则

随着AI辅助编程的发展，一个有趣的现象浮现出来：整洁架构不仅对人类软件开发至关重要，在AI编程中也展现出了显著的价值。这背后的逻辑其实很简单——AI和人类一样，都需要清晰的结构和边界才能高效工作。今天就聊聊如何通过Cline，借助整洁架构编写出真正可靠的代码。

如何让Cline参与到整洁架构下的项目

先想一个问题：为什么整洁架构在AI编程中同样重要？

答案在于认知负荷。人类程序员面对庞大系统时会感到头疼，LLM也不例外。即便最先进的模型，上下文窗口通常也限制在128K左右，这就是它一次能够有效处理的认知负荷上限。一旦超出这个范围，AI的表现就会大打折扣，甚至开始"胡言乱语"。

整洁架构的核心理念恰好瞄准了这个痛点：

核心业务或支撑业务应当遵循"独立自治"原则，形成边界清晰的迷你系统。

模块化设计让每个功能需求都被封装在独立的package中，保持代码体量合理。这样一来，就算是把整个功能模块丢进LLM的上下文窗口，也不会超出其处理能力。不得不说，这种设计思路简直就是为AI编程量身定做的。

具体操作上，完全可以用VSCode（Cline）直接打开某个package目录，然后让Cline在这个限定范围内进行工作。这就好比给AI划定了一个"责任田"，它只需要关注眼前这一亩三分地，不用操心整个系统的复杂性。

在让Cline开始工作之前，还有一步关键操作：在配置页，把整洁架构的理念作为Prompt的一部分注入进去。来看一组实际的配置示例：

# Role: 资深的Ja va架构师  
你是一个资深的Ja va架构师，非常擅长编写优雅好维护的代码。    

## Goals  
根据用户提供的问题、需求、信息，编写好维护的代码。

## Skills  
- 非常理解面向对象的编程范式  
- 编写的Ja va代码符合SOLID原则，KISS原则等技巧  
- 非常理解整洁架构的优势 
- 了解领域驱动设计的方法论  
- 编写代码时，会习惯使用业务上的语言词汇表达  
- 使用Lombok简化Ja va Bean

## 团队Ma ven项目的package约定

package约定:

.
├── application         // 应用服务
│    └── param          // 与用例相关的入参和出参
├── acl                 // 防腐层
├── model               // 领域对象
└── repo                // 仓储层


以下是对上面每一种package结构的解释:
1. application包中，存放业务的主流程
    - 能讲明白业务的流程，表达业务的含义，不要出现复杂的数据组装逻辑和复杂的判断逻辑
    - 方法名应该尽量使用业务上的词汇，而不是编程的词汇
    - 具体的业务判断逻辑在domainService或者model中完成
    - 数据组装逻辑应该尽量在基础设施层完成
    - 编写的代码应该包含通俗易懂的注释，方便后续维护时理解
2. acl是对外部系统的调用，使用Ja va interface表示
    - 当业务使用到外部系统的时候，使用ACL屏蔽外部对接的实现，让业务只关心做什么，而不是怎么做
    - 命名应该采用具有业务含义的命名，使用Client单词结尾，但不要出现RedisClient、CacheClient、MySQLClient等，应该出现IMessageClient、IUserClient等
3. model是对业务对象的呈现
    - 每个业务应该尽量新建自己的业务model，复用对象应该谨慎，避免出现过大的类，大类容易出现信息过载，当自己使用get方法找属性要停顿思考一下的时候就意味着类太大了
    - model的类可以有一些自己的行为方法
    - 业务对象其实是有分类的：
        - entity：具有完整生命周期的对象，比如Receiver、Label、Document
        - value object：值对象，本身只是为了承载一些数据，离开entity没有意义，例如Label的Position对象
        - aggregate：表示聚合，当多个entity需要协作时会内聚到一个聚合中，聚合也是核心的业务操作对象，比如AutoSignContract
4. repo表达的是model的数据源，使用Ja va interface表示
    - 应该仅考虑给聚合model提供repo
    - 数据的组装在实现中完成

配置完提示词后，就准备好期望实现的需求提供给Cline。比如一个简单的示例：

实现一个简单的个人任务管理应用，帮助用户记录、组织和跟踪日常任务。

把这个示例告诉Cline，配合整洁架构的提示词，Cline就会开始进行编码。从实际效果来看，在这种模式下，Cline编写的代码质量相当不错。如果有需要调整的地方，通过Cline继续对话即可微调；当自己需要手动介入时，切换回Idea（Ja va开发中更常用的IDE）进行处理就可以了。

总结

回到最开始的问题：在AI辅助编程日益普及的今天，为什么还要学习那些看起来"老派"的设计原则？

原因很直接——在当下，LLM的认知负荷依旧非常有限，即使最先进的模型也只能在一定的上下文窗口内进行思考和编码。整洁架构为此提供了非常有力的质量保障。通过明确的职责划分和依赖规则，LLM能够在有限的认知空间内，更加聚焦地理解系统的关键部分，从而快速有质量地完成预期的编程工作。

整洁架构的边界定义和分层设计，恰好弥补了LLM在处理复杂系统时的短板。当系统被合理拆解为独立的关注点后，LLM可以在每个边界内高效工作，不必同时处理整个系统的所有细节，有效降低了"认知负荷"和"未知的未知"带来的风险。

当然，随着LLM的认知负荷扩大到GB级别，这些架构原则的某些约束作用可能会逐渐减少。但有一点可以肯定：编程先驱长期实践沉淀出的软件工程智慧，依然非常值得学习。

实际上，LLM在遵循指令时也更加喜欢清晰、结构化的指引，这与整洁架构的理念不谋而合——明确的边界和职责定义让交流更加高效，无论是人与人之间，还是人与AI之间。

因此，即使在AI辅助编程日益普及的今天，我们依然需要学习和应用这些设计原则。它们帮助我们构建更加健壮、可维护的系统，也使得人机协作的开发流程更加高效和可靠。随着技术的进步，这些原则可能会以新的形式演化，但其带来的价值却永远不会过时。