2026 年 7 月 16 日，Kimi 官方发布 K3，并把网站生成列为 Agent 的核心能力之一。随后，开发者 Max Weinbach 公开了一次 Agent Swarm 实验：让 Kimi 生成一个可以交互的网页版 macOS。公开记录显示，这次任务持续约 3 小时 20 分，并消耗了约 60% 的月度额度。
本文没有拿到项目仓库，也不声称“审过源码”。下面的判断只来自 2026 年 7 月 18 日访问到的公开页面、JavaScript/CSS 构建产物和原始发布记录。资源 hash 与统计值以后可能变化。
先看结果：它不是一个单文件玩具
在线演示提供桌面、窗口、Dock、Finder、Safari、设置等多种交互。浏览器下载到的主 JavaScript 为 2,419,416 字节，主 CSS 为 83,650 字节。体积不能直接证明质量，但足以说明这不是“几百行 HTML 一次生成”的轻量案例。
| 可复核项 | 本次观察 | 能说明什么 |
|---|---|---|
| JavaScript | 2,419,416 字节 | 功能面较大；仍需关注拆包和首屏成本 |
| CSS | 83,650 字节 | 存在较完整的视觉系统 |
| 源路径痕迹 | 98 个可识别的 TypeScript/TSX 源文件路径 | 构建产物显示组件已经拆分 |
| 设计变量 | 172 个 CSS 自定义属性 | 颜色、圆角、阴影和动效并非全部散落硬编码 |
| 无障碍痕迹 | aria-label 多次出现 | 构建产物存在无障碍语义痕迹；不等于通过完整无障碍审计 |
构建产物能告诉我们什么，不能告诉我们什么
压缩后的 JavaScript 仍保留了部分源路径，可以看到 WindowManager、Finder、Safari、Settings 等组件名。CSS 变量也覆盖颜色、尺寸、圆角、阴影和动画时长。因此，把这个案例描述成“所有逻辑都挤在一个文件里”或“改一个圆角要翻遍项目”并不准确。
反过来，构建产物也不能证明类型设计优秀、异常分支完整或长期维护成本很低。编译后的 JavaScript 无法可靠还原 TypeScript 中是否滥用 any；看到 localStorage 和错误处理字符串，也不等于数据迁移、容量上限和恢复路径都经受过测试。
合理的结论应当与证据强度匹配：我们可以说“看到了组件拆分和设计变量”，不能因此说“源码已经工程化完毕”。
如果这是我的项目，上线前会补四类验证
- 性能：记录首屏资源、长任务和低端移动设备交互；按功能拆包，而不是只看桌面浏览器效果。
- 状态：列出 localStorage 的 schema、容量、迁移和清空策略；验证刷新、版本升级和损坏数据。
- 可访问性：用键盘走完窗口、菜单和应用切换；检查焦点顺序、语义、对比度和 reduced motion。
- 交付：固定依赖与构建命令，加入自动测试、错误监控、回滚路径和第三方资源清单。
这与站内上一篇《AI 生成的 HTML 小工具，怎样从一次性 Demo 变成可维护的本地应用？》形成互补：上一篇给出通用方法，这一篇用真实案例说明“先确认事实，再谈工程判断”。
真正值得学习的是验证方式
Kimi K3 Agent 展示了长时间、多步骤生成复杂 Web 应用的能力。这个案例的完成度令人印象深刻，但“能生成”“能部署”“能长期维护”仍是三个不同问题。
面对下一个 AI 编程爆款，我会先保存原始任务和运行条件，再抓取页面实际加载的资源，最后把每个判断标成“已验证”“可推断”或“未知”。这套方法比一张主观星级表更慢一点，却更可信，也更容易复现。