不只是让 AI 写代码：ViewCompose 把 Android UI 做成了可编译、可渲染的闭环

小强闯江湖2026-09-01 16:54

AI 真正的问题，从来不是"能不能生成 Kotlin"，而是：它写的是不是你当前版本真实存在的 API？代码能不能编译？页面能不能渲染？结果和设计是否一致？

ViewCompose 的答案不是再加一个聊天框，而是把框架本身改造成一套机器可读、可搜索、可编译、可渲染、可比较的 AI 开发接口。

在上一篇文章《ViewCompose：让原生 Android View 进入声明式时代》中，我介绍了 ViewCompose 的核心定位：使用状态驱动的 Kotlin DSL 描述界面，最终仍然生成一棵真实的 Android View 树。

这一次，我想讨论它的另一项重要能力：怎样让 AI 不只是"看起来会写 ViewCompose"，而是真的能够正确使用 ViewCompose。

ViewCompose 目前已经把版本化 AI Reference、13 个本地 MCP 工具、6 个 Agent Skill、Kotlin 编译、Preview 渲染、布局诊断、XML 迁移和 Screenshot → UI 验证链路打包成可直接安装的 GitHub Release。

开发者不需要克隆 ViewCompose 源码，不需要自己构建 MCP，不需要手动复制 Skill，也不需要把任何模型密钥交给框架。只用两条命令，就可以让 Codex、Claude Code 或 Cursor 接入一个全新或已有的 Android 项目。

更关键的是：工具链会和项目实际使用的 ViewCompose 版本绑定，不会因为"AI 工具更新了"就偷偷拿最新 API 去指导旧项目。

这才是 ViewCompose 所理解的 AI-first。

一、AI 写框架代码，最大的风险不是不会写，而是"写得很像"

今天让大模型写一个 Android 页面并不难。

难的是，当它面对一个新框架、一个独立版本化的多模块框架，或者一个训练语料中很少出现的 API 时，模型很容易写出这种代码：

kotlin 复制代码 
Column(
    modifier = Modifier
        .fillMaxSize()
        .padding(16.dp),
) {
    Text("Hello")
}

这段代码非常像 Jetpack Compose，也非常符合人的直觉。但"像"不等于"属于 ViewCompose 当前版本的真实 API"。

模型可能会：

  • 把 Jetpack Compose 的参数或 Modifier 直接套过来；
  • 使用已经改名或尚未发布的 API；
  • 混用不同 ViewCompose 模块的版本；
  • 给出语法正确、静态看起来合理、实际无法编译的代码；
  • 声称"已经实现"，却没有运行过 Preview，更没有比较布局结果；
  • 在旧项目里加载最新知识，生成只有新版本才存在的用法。

传统解决方式是把 README、几篇示例和报错信息反复贴进对话，让模型自己猜。

但这并不是一个稳定的工程接口。

如果框架没有向 AI 提供确定的事实、明确的版本和可执行的验证，模型再强，也只能把"概率上可能正确"包装成"语气上非常确定"。

ViewCompose 的目标因此不是"让 AI 多写一些代码"，而是缩短从生成到可信结果之间的距离。

二、不是给框架加一个 AI 按钮，而是让框架成为 AI 可正确使用的系统

ViewCompose 的 AI 能力由四层组成：

text 复制代码 
Codex / Claude Code / Cursor
              ↓
       Agent Skills + MCP
              ↓
  版本匹配的 Knowledge Pack
              ↓
生成 / 转换 / 分析 / 诊断
              ↓
静态检查 → 编译 → Preview → 布局/像素比较
              ↓
       带证据等级的结果

2.1 机器可读的 AI Reference

普通文档主要为人设计：章节叙事完整，但模型不一定能稳定定位参数、默认值、模块归属、生命周期约束和可编译样例。

ViewCompose 会从公开 API、能力登记、规则和编译样例生成版本化 Knowledge Pack，其中包含：

  • API 与组件索引；
  • 参数、符号、模块与能力归属；
  • 可检索的规则、限制和常见错误；
  • 经过编译门禁的 Sample；
  • llms.txt 与完整 AI Reference；
  • 发布 Artifact 与源码修订之间的对应关系。

当前 0.3.0 工具 Release 的已发布版本画像登记了 38 个独立版本化 Artifact，其中 30 个带有机器可读知识，共覆盖 70 项能力。

这让 Agent 获取的是结构化事实，而不是在整份 README 中做模糊匹配。

2.2 本地 MCP：把事实和工具交给 Agent

MCP Server 通过本地 stdio 工作，不启动公网服务，也不持有模型 Provider Credential。

模型、账号、对话和源码修改授权仍然属于 Codex、Claude Code 或 Cursor；ViewCompose 只提供框架事实、确定性工具与验证证据。

2.3 Agent Skill：让不同客户端复用同一套工作流

只有工具列表还不够。Agent 还需要知道什么时候先查 API、什么时候必须编译、什么时候不能把静态结果说成渲染成功。

ViewCompose 提供 6 个标准 Skill：

  • viewcompose-api-reference
  • viewcompose-create-screen
  • viewcompose-convert-xml
  • viewcompose-review
  • viewcompose-debug-layout
  • viewcompose-validate

它们不是只为某一个产品写的提示词，而是可以安装到 Codex、Claude Code 和 Cursor 项目中的规范工作流。

2.4 可执行证据：让"应该能运行"变成"确实运行过"

AI Reference 解决"知道什么"，MCP 解决"能调用什么"，Skill 解决"按什么顺序做"。

最后一层则回答最实际的问题：生成的东西到底有没有通过验证？

三、两条命令，让常见 AI Agent 接入新旧 Android 项目

先安装固定版本的公开 GitHub Release：

bash 复制代码 
npm install --global --ignore-scripts \
  https://github.com/ViewCompose/ViewCompose/releases/download/ai-tooling-v0.3.0/viewcompose-ai-tooling-0.3.0.tgz

然后在 Android 项目根目录选择客户端：

bash 复制代码 
viewcompose-agent init --client <codex|claude-code|cursor> \
  --project-root "$(pwd -P)"

就这两条命令。

不需要：

  • Checkout ViewCompose 仓库；
  • 在本机编译 MCP 或打 npm 包；
  • 手动编辑 JSON/TOML 配置；
  • 分别下载和复制 Skill；
  • 安装独立 Gradle；
  • 提供 OpenAI、Anthropic 或其他模型密钥。

init 会以事务方式合并项目级 MCP 配置，并安装 6 个 Skill：

客户端 MCP 配置 Skill 目录
Codex .codex/config.toml .agents/skills
Claude Code .mcp.json .claude/skills
Cursor .cursor/mcp.json .agents/skills

它不会覆盖无关设置。重复执行相同内容保持幂等；如果发现已有配置、Skill 被用户修改，或者项目路径不是物理绝对路径，它会停止并报告冲突，而不是留下"装了一半"的状态。

安装后可以执行：

bash 复制代码 
viewcompose-agent doctor --client <codex|claude-code|cursor> \
  --project-root "$(pwd -P)"

当结果为 project-bound-ready 时，说明 MCP、Skill、框架版本画像和深层验证所需环境都已就绪。

四、AI 工具不能盲目升级：知识必须和项目框架版本匹配

这是 ViewCompose AI 工具链里很重要、也很容易被忽略的一点。

假设用户项目依赖的是旧版 ViewCompose，而全局 AI 工具悄悄更新到了最新版。新知识库很可能指导模型调用旧版中不存在的 API。工具"更新成功"，生成结果却更不可靠了。

所以 ViewCompose 明确禁止把"工具版本更新"当作"框架兼容"的证据。

初始化时，工具会在不执行项目 Gradle 构建逻辑的前提下，读取项目中实际声明的 com.viewcompose 依赖：

  • 精确的 Maven Coordinate；
  • 项目实际使用的 libs.versions.toml 条目；
  • Dependency Lock 中的确定版本。

然后只选择能覆盖这组 Artifact-version 的 Released Knowledge Pack，并把内容寻址的 Profile ID 写入 MCP 环境。后续 API 检索、静态验证、编译和 Preview 都加载同一个 Bundle。

text 复制代码 
项目中的 ViewCompose 依赖
            ↓
解析精确 Artifact + Version
            ↓
匹配 Released Framework Profile
            ↓
绑定 Knowledge + Harness + Validation

对于动态版本、互相冲突的版本或无法识别的依赖，工具会在修改项目配置之前失败。它不会猜，也不会静默升级项目依赖。

升级同样遵循这个原则：

bash 复制代码 
viewcompose-agent upgrade --client <codex|claude-code|cursor> \
  --project-root "$(pwd -P)"

升级器会先识别项目版本，再从不可变 GitHub Release 中寻找最新的兼容版本 ，而不是全局 latest。没有匹配画像时返回 no-compatible-update，保留当前接入不变。

换句话说：

宁可诚实地告诉用户"暂无兼容更新"，也不让 AI 用错误版本的知识生成一份自信但不可用的代码。

五、13 个 MCP 工具，不只是一个"文档搜索器"

当前工具可以分为四组。

5.1 API 与样例检索

  • get_api_reference
  • get_component_reference
  • search_component
  • get_sample

Agent 可以先确认组件、参数、模块和可编译样例，再开始写代码，降低"凭印象补 API"的概率。

5.2 验证、预览和项目分析

  • validate_code
  • render_preview
  • diagnose_layout
  • analyze_project

这里最重要的是 validate_code：静态检查只能证明代码表面上符合某些规则，Compile Mode 才会真正使用已发布 Maven Artifact 编译有界 Kotlin Snippet。

5.3 XML → ViewCompose

  • convert_xml_to_viewcompose

这不是把标签名做字符串替换。工具会处理限定范围内的 XML 与资源依赖，生成中间设计树和 ViewCompose Kotlin，并在可用时继续编译、渲染、比对和诊断。

它特别适合拥有大量 LinearLayout、FrameLayout、TextView、ImageView 和资源文件的存量 Android 项目。

5.4 Screenshot → ViewCompose

  • prepare_screenshot
  • validate_screenshot_inference
  • resolve_screenshot_inference
  • generate_screenshot_viewcompose

视觉模型负责理解截图，ViewCompose 工具链负责验证推断结构、解析类型与资源、确定性生成 Kotlin，并继续执行编译、Preview、布局比较和符合条件时的 RGBA 像素比较。

这一区分非常重要：ViewCompose 不假装自己内置了一个视觉模型，也不会把模型的一次猜测直接包装成"还原完成"。

六、比 MCP 数量更重要的，是五级证据链

很多 AI Coding 产品的问题不是没有工具，而是对结果的描述不诚实。

"我生成了代码"不等于"代码编译通过"；"编译通过"不等于"页面成功渲染"；"渲染成功"更不等于"和目标设计一致"。

ViewCompose 把证据划分为五个等级：

证据等级 它能证明什么 它不能证明什么
knowledge 找到了版本匹配的 API、规则和 Sample 生成代码可编译
static 通过确定性静态规则检查 Kotlin/Android 编译成功
compiled 使用目标发布 Artifact 真正编译通过 页面能够渲染
rendered Preview 已生成，并重新打开精确 PNG 与 Render Tree 和目标视觉一致
compared 已进行语义、几何或像素比较 超出比较边界的产品体验完全正确

Agent Skill 被要求只报告已经取得的证据等级，并明确说明更深层 Lane 为什么不可用。

一个典型闭环是：

text 复制代码 
自然语言 / XML / Screenshot
              ↓
查询真实 API 与编译 Sample
              ↓
生成 ViewCompose Kotlin
              ↓
Static Validation
              ↓
Kotlin Compilation
              ↓
Preview Render
              ↓
Layout / Pixel Compare
              ↓
根据结构化诊断继续修正

这让 AI 的输出从"建议"逐步变成"带可复核证据的工程结果"。

七、为什么没有源码，也能做 Kotlin 编译和 Preview 渲染？

这是 0.3.0 解决的另一个关键问题。

如果每个用户都必须克隆 ViewCompose 源码、对齐仓库构建环境、手工运行 Gradle，所谓 AI 接入仍然很重。

因此发布包携带了一套隔离、内容寻址的 Build Harness，包括 Gradle Wrapper 和编译/Preview 入口。它使用 Maven Central 上的精确 ViewCompose Artifact 来编译工具生成的 Kotlin，而不是依赖本地源码。

当前 Harness 固定了 Gradle 9.3.1、AGP 9.1.1、Kotlin 2.2.10、Android 36 与受控的 ViewCompose/Preview Artifact。

更重要的是，它不会执行用户项目的：

  • Gradle Wrapper；
  • settings.gradle；
  • Plugin；
  • Task；
  • Build Script。

用户项目根目录只是一个有界、只读的授权边界。生成代码在隔离 Harness 中验证，避免为了证明一个 Snippet 能编译，就执行一个陌生项目的任意构建逻辑。

第一次请求编译或 Preview 时可能需要下载固定的 Gradle Distribution 和 Maven 依赖，之后使用经过完整性校验的本地缓存。

八、三个真正能降低 Android 项目成本的使用场景

8.1 从一句需求开始，但不止于生成代码

你可以在 Agent 中直接说：

使用 ViewCompose 创建一个 Material 3 登录页面。编写前先检索准确 API 和已编译 Sample，执行当前可用的全部验证 Lane，并报告已取得的证据等级以及不可用的更深层 Lane。

Agent 会先查当前版本真实 API，再生成代码并尝试取得静态、编译和渲染证据。

这与"请按你记忆写一段 ViewCompose"是两种完全不同的可靠性模型。

8.2 把存量 XML 页面迁移成声明式 View

对多数 Android 团队来说，最有价值的 AI 场景不是从零生成 Demo，而是处理多年积累的 XML 页面。

text 复制代码 
XML + Resource Context
          ↓
解析布局、属性与依赖
          ↓
生成 Design IR
          ↓
生成 ViewCompose Kotlin
          ↓
编译 + Preview + 语义/几何比较
          ↓
报告已映射项与未解决项

业务监听器、复杂样式继承和项目特有约束仍然需要开发者审查，但大量机械迁移工作可以进入可验证流水线，而不是停留在一次性文本转换。

8.3 按截图实现页面，并知道"差在哪里"

Screenshot → UI 最容易陷入"看起来差不多"的主观判断。

ViewCompose 把这条链路拆成截图预处理、模型推断验证、类型化 Resolution、Kotlin 生成、编译、Preview、语义/布局比较，以及满足条件时的精确像素比较。

最终 Agent 不只是返回一段 DSL，还可以基于 Render Tree、布局诊断和像素差异继续修正。

视觉理解仍由用户选择的 Agent/模型完成，框架负责把后半段变成确定性、可验证的工程流程。

九、对使用者而言，真正的优势是什么？

如果只看"AI 能生成页面"，ViewCompose 并不是唯一选择。

它真正有差异的地方在于：

9.1 AI 生成结果仍然落在原生 Android View 生态

ViewCompose 最终生成的是 TextView、EditText、RecyclerView、ViewGroup 或受控接入的第三方 View。

团队可以在获得声明式表达力的同时，继续利用原生 View 在输入法、焦点、无障碍、主题、窗口、地图、相机、播放器和 OEM 适配上的现有资产。

9.2 新框架也能给 AI 提供高质量上下文

模型对 Jetpack Compose 很熟悉，是因为公开语料足够多。一个新框架不应该被动等待多年语料积累，而应该主动发布机器可读、版本化、可检索、可验证的开发接口。

ViewCompose 把这部分能力作为框架正式交付物，而不是维护者本地的一组私有提示词。

9.3 生成、迁移和验证共享同一套事实

API 检索用的是当前版本 Knowledge Pack，编译用的是对应发布 Artifact，Preview 使用固定 Harness，升级仍然按同一 Framework Profile 选择。

它们不是四套各自漂移的工具。

9.4 失败边界比"自动化程度"更重要

遇到版本冲突、用户修改过的 Skill、未知 MCP 配置、无效路径或缺少 Host 前提时，工具会停止并返回结构化原因。

不会为了表现得"全自动"而覆盖用户文件，也不会把较低证据等级冒充成成功。

十、安全与供应链：AI 工具也必须像正式开发工具一样发布

ViewCompose AI Tooling 0.3.0 不是仓库里的一个临时脚本目录，而是不可变 GitHub Release。

Release 包含：

  • viewcompose-ai-tooling-0.3.0.tgz
  • manifest.json
  • SHA256SUMS

发布流程会：

  • 重复构建两次并验证结果可复现；
  • 校验精确文件清单；
  • 验证离线安装与卸载生命周期；
  • 验证三个 Agent Client 的配置和 6 个 Skill；
  • 验证两个 MCP Protocol 版本；
  • 为三个 Release Asset 创建 GitHub Artifact Attestation。

npm Package 没有运行时依赖，也不会在安装时执行脚本。模型 Credential 始终留在用户选择的 Agent 中。

升级采用内容寻址的 Side-by-side 安装和可恢复事务；如果迁移中断，会保留或恢复旧接入状态。

这些能力不会直接让 UI 更漂亮，却决定了一套 AI 工具能不能放心进入真实项目。

十一、它目前仍然有哪些边界？

一套可信的 AI 能力，应该同时说明自己不能做什么。

  • ViewCompose 仍处于 Alpha，公开 API 仍可能继续收敛。
  • 工具包不包含模型；Prompt 理解和 Screenshot 视觉推断由用户选择的 Agent/模型负责。
  • 当前深层渲染主要面向工具确定性生成的 XML/Screenshot 页面，以及另行 Allowlist 的固定 Target；它不会任意执行和渲染现有 Application Code。
  • 首个 0.3.0 Release 只携带当前已发布 Artifact Vector 的 Framework Profile；历史版本只有在某个 Release 明确包含匹配 Profile 时才受支持。
  • 基础知识和静态能力要求 Node.js 24.19.0 或更高版本；编译、Preview 和布局证据还需要 JDK 17/21 与 Android SDK Platform 36。
  • 首次深层验证需要下载固定构建依赖，耗时会高于纯文本生成。

这些限制降低了"什么都能自动做"的宣传强度，却让每一次成功声明都更可信。

十二、五分钟开始体验

第一步，安装发布包：

bash 复制代码 
npm install --global --ignore-scripts \
  https://github.com/ViewCompose/ViewCompose/releases/download/ai-tooling-v0.3.0/viewcompose-ai-tooling-0.3.0.tgz

第二步，在项目根目录接入你的 Agent：

bash 复制代码 
viewcompose-agent init --client codex --project-root "$(pwd -P)"

把 codex 换成 claude-code 或 cursor 即可接入对应客户端。

然后试试这几个任务：

使用 ViewCompose 创建一个 Material 3 设置页面。先查询准确 API 和可编译 Sample，然后编译并渲染生成结果。
把 activity_login.xml 转换为 ViewCompose。保留资源引用，报告不能确定迁移的部分，并执行可用的编译与 Preview 验证。
按这张截图实现一个 ViewCompose 页面。先生成结构化设计推断，再编译、渲染并报告布局或像素差异。

结语：AI-first 的关键，不是生成更多，而是更少地生成错误

ViewCompose 的第一层价值，是让原生 Android View 获得状态驱动、可组合、可增量更新的声明式开发模型。

它的第二层价值，是让这套新框架从一开始就为 AI 提供正式接口：

  • 机器可读，而不是只给一份 README；
  • 版本匹配，而不是永远加载最新文档；
  • 可搜索，而不是靠模型回忆；
  • 可编译，而不是停在代码块；
  • 可渲染、可比较，而不是只说"已经完成"；
  • 可安全升级和回滚，而不是覆盖用户环境。

未来的开发框架，不只需要对人类开发者友好，也需要让 Agent 能够获取正确事实、调用确定工具并交付可验证结果。

ViewCompose 正在尝试证明：AI 不应该只是帮你写声明式 Android UI，它还应该能说明自己为什么写对了。

了解更多

如果你正在维护一个拥有大量 XML 和原生 View 资产的 Android 项目，又希望获得声明式 UI 与 AI Coding 的效率，欢迎尝试 ViewCompose，也欢迎在 GitHub 提交 Issue、反馈真实迁移场景或参与贡献。

相关推荐
肆仲冬3 小时前
不用框架手写 AI Agent：ReAct 推理链和上下文管理的工程实践
人工智能
明月_清风3 小时前
发现一个超系统的 AI Agent 学习地图 —— Agent Atlas 推荐
人工智能·后端·agent
百度Geek说4 小时前
商业客户端Harness资产管理与应用实践
人工智能
MacroZheng4 小时前
同事问我："Claude Code经常失忆，不怕它把项目搞炸？"，我："怕，三个Markdown文件给它装个永不丢失的外置大脑！"
java·人工智能·后端
小酒星小杜4 小时前
一个人，也能做出有人设、能追更、可商业化的漫画内容 IP
人工智能·产品·设计
字节跳动视频云技术团队4 小时前
从出片到出海：AI MediaKit 重塑短剧全链路生产力
人工智能·音视频开发
hunterandroid4 小时前
StateFlow 与 SharedFlow 的边界：状态与事件的正确建模
android·前端
YF02114 小时前
Android遥控器对频详解
android·android things
一点一木4 小时前
憋了7周没动静，OpenClaw 2.0带着16000个PR杀回来了
人工智能·github
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03ZCode 周末送额度活动开启：3 亿 Token 免费领取04历年考研数学一、数学二、数学三真题试卷及答案PDF052026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路09Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费10VSCode+CodeX扩展，无法启动