本文译自「Design a screen, get a Clean Architecture feature — Spec-Driven Development that keeps AI-generated KMP code from drifting」，原文链接https://proandroiddev.com/design-a-screen-get-a-clean-architecture-feature-and-keep-ai-generated-kmp-code-from-drifting-c134ffc9bfc2，由Ali Sadeghi发布于2026年7月23日。

描述简单来说，就是让AI在Android和iOS平台上完成设计、构建、测试和审查，并强制执行“整洁架构”（Clean Architecture），而不是仅仅寄希望于此。

使用AI生成功能时，有一个没人会提醒你的潜在问题：每个功能单独来看似乎都没问题。第一个屏幕很简洁，第二个屏幕也很简洁。但到了第五个屏幕，应用就出现了两种不同的状态约定、一个仓库悄悄地访问ViewModel，以及一个屏幕文件夹，其中的布局完全不一致。并非某个提示本身有问题，而是代码库发生了偏移，因为在提示之间，架构没有得到任何约束。

你无法通过改进提示来解决这个问题。你需要将架构作为模型必须满足的约束，而不是一个可以随意重新解释的建议。

这就是KMPilot的作用：我构建的一个模板，旨在让AI严格遵循“整洁架构”。我把它应用到了一个真正的应用程序上：Kickoff26，一个 2026 年世界杯配套应用，它是先设计后功能构建的。这篇文章记录了我从中学到的关于如何保持 AI 生成代码规范的经验。

为什么 AI 生成的代码会偏离规范

规范驱动开发并非我首创。 GitHub 的 spec-kit 和 OpenSpec 等工具已经让这种做法在通用代码库中流行起来：先编写规范，然后让 AI 基于规范进行构建，而不是在不断滚动的聊天记录中进行规划。其理念很简单：将约定写下来，放在代码旁边，让代码遵循规范。我的做法是将其应用于 Kotlin 多平台领域，并分为三个部分：

• 架构是约束。 整洁的架构，每个功能都具有相同的结构，且不可更改。这并非出于礼貌：一个钩子会物理阻止对功能代码的直接编辑，因此模型无法悄悄地重塑它。它在结构内部执行。

• 设计是输入，而不是事后考虑。 屏幕最初是一个已批准的原型，原型中的元素会流入代码。

• 动态的 spec.md 文件就是规范。 每个功能对应一个规范，版本控制，并随着代码的更改而更新。它是模型在执行任何操作之前读取的内存。

底层，KMPilot 是一组运行在 Claude Code 之上的技能和代理。Kickoff26 中的每个屏幕都是基于它构建的。

功能实际上是如何构建的

我一开始并不相信这一点。几周以来，我一直期待着打开这个项目并发现常见的人工智能蔓延：做同一件事的三种方法，一个层悄悄地泄漏到另一个层，无论如何我最终都会自己编写测试。它从未出现过。我最接近混乱的是我自己的：我让每个功能保留自己的网络层副本，到第四个功能时，重复就无法忽视。这通常是你一直推迟的清理工作，因为它涉及到一切。在这里，我描述了一次更改，规格准确地告诉了我每个功能决定了什么以及原因，并且它是在一个下午完成的，没有破坏任何东西。

它还很年轻：Kickoff26 仍然说正在开发，并且 KMPilot 有粗糙的边缘我还没有打磨。但在观察了人工智能辅助的代码库快进腐烂了几个月之后，我不断回想起的部分是，这个代码库并没有。一切都没有漂移。这就是重点。

尝试一下