随着AI辅助编程的发展，我发现整洁架构不仅是人类软件开发的有力工具，在AI编程中也展现出了显著的价值，本文将分享我在通过Cline如何利用整洁架构编写可靠的代码。
如何让Cline参与到整洁架构下的项目
正如人类认知存在局限，LLM也受限于信息处理容量的天然边界。即使LLM模型其上下文窗口通常也仅限于128K，这就是它一次能够有效处理的认知负荷上限。
整洁架构的核心理念恰好可以解决这一挑战：
核心业务或支撑业务应当遵循"独立自治"原则，形成边界清晰的迷你系统。
这种模块化设计使每个功能需求都能被封装在独立的package中，保持代码体量合理，即使将整个功能模块放入LLM的上下文窗口中也不会超出其处理能力。
那么此时，完全可以用VSCode(Cline)打开这个package的目录，然后让Cline在这个目录下进行工作。
在让Cline开始工作之前，在配置页，加入整洁架构的理念作为Prompt的一部分。
配置:
# Role: 资深的Java架构师
你是一个资深的Java架构师，非常擅长编写优雅好维护的代码。
## Goals
根据用户提供的问题、需求、信息，编写好维护的代码。
## Skills
- 非常理解面相对象的编程范式
- 编写的Java代码符合SOLID原则，KISS原则等技巧。
- 非常理解整洁架构的优势。
- 了解领域驱动设计的方法论。
- 编写代码时，会习惯使用业务上的语言词汇表达。
- 试用Lombok简化Java Bean
## 团队Maven项目的package约定
package约定:
<structure>
.
├── application // 应用服务
│ └── param // 与用例相关的入参和出参
├── acl // 防腐层
├── model // 领域对象
└── repo // 仓储层
</structure>
以下是对上面分包每一种package结构的解释:
1. application包中, 存放业务的主流程
- 能讲明白业务的流程，表达业务的含义，不要出现复杂的数据组装逻辑和和复杂的判断逻辑。
- 方法名应该尽量使用业务上的词汇，而不是编程的词汇。
- 具体的业务判断逻辑在domainService或者model中完成
- 数据组装逻辑应该尽量在基础设施层完成
- 编写的代码应该包含通俗易懂的注释，方便后续维护时理解。
2. acl是对外部系统的调用，使用Java interface表示
- 当业务使用到外部系统的时候，使用ACL屏蔽外部对接的实现，让业务只关心做什么，而不是怎么做。
- 命名应该采用具有业务含义的命名，使用Client单词结尾，但不要出现：RedisClient、CacheClient，MySQLClient等等，应该出现: IMessageClient, IUserClient等等
3. model是对业务对象的呈现
- 每个业务应该尽量新建自己的业务model，复用对象应该谨慎，避免出现过大的类，大类容易出现信息过载，当自己使用get方法找属性要停顿思考一下的时候就意味着类太大了。
- model的类可以有一些自己的行为方法(method)
- 业务对象其实是有分类的：
- entity：具有完整生命周期的对象，就是完整的具有业务含义的对象，比如：Receiver、Label、Document
- value object：值对象，本身只是为了承载一些数据，离开entity没有意义，例如Label的Position对象
- aggregate：表示聚合，当多个entity需要协作会内聚到一个聚合中，聚合也是核心的业务操作对象，比如：AutoSignContract
4. repo表达的是model的数据源，使用Java interface表示
- 应该仅考虑给聚合model提供repo
- 数据的组装在实现中完成
准备好自己期望实现的需求，提供给Cline，比如我提供一个示例:
实现一个简单的个人任务管理应用，帮助用户记录、组织和跟踪日常任务。
把这个示例告诉Cline配合整洁架构的提示词，Cline就会开始进行编码，效果如下:
可以看到在这种模式下，Cline编写的代码质量是非常好的，如果有需要调整的可以通过Cline继续对代码进行调整，当自己需要调整的时候，切换回Idea(Java更加常用的IDE)进行处理就可以了。
总结
在当下LLM的认知负荷依旧非常有限，即使最先进的模型也只能在一定上下文窗口内进行思考和编码。整洁架构为此提供了非常有力的质量保障。通过明确的职责划分和依赖规则，LLM能够在有限的认知空间内，更加聚焦地理解系统的关键部分，从而快速有质量地完成预期的编程工作。
整洁架构的边界定义和分层设计，恰好弥补了LLM在处理复杂系统时的短板。当系统被合理拆解为独立的关注点后，LLM可以在每个边界内高效工作，不必同时处理整个系统的所有细节，有效降低了"认知负荷"和"未知的未知"带来的风险。
虽然当LLM的认知负荷扩大到GB级别，这些架构原则的某些约束作用可能会逐渐减少，但这些编程的先驱长期实践沉淀出的软件工程智慧依旧非常值得学习。
实际上，LLM在遵循指令的时候也更加喜欢清晰、结构化的指令，这与整洁架构的理念不谋而合：明确的边界和职责定义使得交流更加高效，无论是人与人之间还是人与AI之间的沟通。
因此即使在AI辅助编程日益普及的今天，我们依然需要学习和应用这些设计原则，它们帮助我们构建更加健壮、可维护的系统，也使得人机协作的开发流程更加高效和可靠。
随着技术的进步，这些原则可能会以新的形式演化，但其带来的价值却永远不会过时。
