2026 年 3 月，我们在整个平台上更新了 moonshot.ai 的体验。这次更新看起来很简单：新的配色方案、更紧凑的排版，以及更新的动效。但实际上，它涉及了共享组件、设计 token、路由，以及整个网站的交互层。
我们使用了以 Kimi K2.5 为底层能力的 Kimi Code CLI 作为 AI 编程 agent，协助完成这次重建。这个项目实际上是在检验一个基于终端的 agent 能否融入真实的生产工作流——而不是在演示环境里试用。本文将介绍我们是如何使用它的，以及我们从中学到了什么。
这次改版到底是关于什么
moonshot.ai 的这次改版并不是从零开始重新设计品牌。绝大部分设计工作已经在 Figma 中完成。真正的挑战在于，如何把这些更新一致地应用到现有代码库中。
这意味着要追踪共享 token、更新组件、检查交互行为，并确保分析统计和无障碍功能不受影响。很多改动单独来看都很小，但它们分布在网站的多个层级中。
这类工作的难点并不在于算法复杂度，而在于覆盖面和一致性。挑战在于，要清楚一次改动会影响到哪些地方,并确保没有遗漏。为此，我们通过 Model Context Protocol（MCP）连接 Figma，让设计规范与实现更好地对齐，帮助 agent 理解结构，减少人工解读的工作量。
基本规则：让 agent 真正发挥作用
第一步不是写提示词，而是设定上下文。我们使用 /init 命令生成了一份 AGENTS.md 文件，然后花了大约一个小时对其进行完善。在这份文件中，我们记录了这次改版的范围、哪些内容不能改动、项目结构，以及构建流程是如何运作的。我们还额外添加了一份规则文件，涵盖命名规范、间距和对比度要求。
这样的准备工作减少了后续反复解释的需要，也让 Kimi Code CLI 的工作流程更加一致。如果没有针对项目的具体上下文，AI 编程 agent 往往只能给出合理但比较泛化的结果。有了这些上下文之后，它的表现就更接近一个已经熟悉代码库的团队成员。
我们实际是怎么用的
这一部分详细拆解了改版过程中 Kimi Code CLI 的实际用法——包括依赖追踪、设计对齐、行为调研、性能检查，以及集成风险审查。我们关注的重点不是自动化本身，而是降低这次大规模重构中的不确定性。
了解一次改动会影响到什么
在动手改动任何内容之前，我们会让 Kimi Code CLI 中的 agent 阅读目标区域，并列出还有哪些内容依赖于它。比如一个按钮的颜色改动，就可能影响到主视觉区块、下载区块、hover 状态和共享 token，而共享组件、动效时长和分析统计钩子还会进一步扩大影响范围。先拿到一份依赖清单，减少了之后出现意外的可能性，也让改动过程更可预期。
让代码与设计规范匹配
接下来，我们逐个区域地对照设计规范来检查组件：主视觉区块、导航、产品区块、下载 CTA 和页脚。agent 通过比较样式与设计 token、布局数值，生成了属性级别的改动清单。这个过程更像是结构化的设计系统自动化，而不是人工的视觉比对。 大多数差异都很小，比如间距、边框圆角或字重，但偶尔也会发现更大的不一致——本应共享同一变体的组件，随着时间推移逐渐产生了偏差。最终得到的是一份具体的改动清单，而不是靠肉眼猜测的过程。
调研新的交互行为
这次改版引入了代码库中此前没有实现过的新 UI 行为：自定义光标、由运行时驱动的主视觉区块、hover 时播放动画的插画卡片，以及滚动触发的入场动效。
针对每一个新功能，我们把文档和仓库状态一起加载进来，把 Kimi Code CLI 当作一个上下文环境来使用。这正是 Kimi K2.5 发挥作用的地方：更长的上下文让我们能够在同一个地方，同时对照实现代码和参考资料进行推理。
实际遇到的问题包括：
hover 动画在鼠标移出时，应该播放完再结束，还是应该立即取消？
光标状态是否应该与主视觉画布产生交互？
当多个层叠加在一起时，哪些地方会出问题？
得益于这个大上下文窗口，我们能够以一种更连续的方式使用 kimi code 工作流，让设计意图和代码始终存在于同一个会话中。
检查体积和性能
这次改版引入了新字体、更多动效以及额外的资源文件，从而增加了页面体积。我们让 agent 帮忙调整了原有的字体子集化脚本，并验证输出结果；后来它还帮助我们解读 Lighthouse 报告，从而尽早发现性能退化问题。目标不是等到最后再统一优化，而是在改动还比较小的时候，及时做出保留或裁剪的决定。
合并前追踪集成风险
入场动画、光标、主视觉画布等多个交互层虽然分布在不同的组件中，但彼此之间共享排序和指针行为，因此其中一层的改动仍可能影响到其他层。我们还需要考虑跨浏览器和跨操作系统的差异，因为 CSS 和渲染行为并不总能保持一致。 在合并一批改动之前，我们会把 diff 输入给 Kimi Code CLI，让它追踪哪些交互可能受到影响，然后再在浏览器中检查这些路径，并在各个环境中做一轮轻量级的排查。
MCP 集成与 Skills
Model Context Protocol（MCP）让 Kimi Code CLI 能够直接连接到包含项目数据的外部系统。我们用 mcp Figma 直接从 Figma 中提取设计变量、布局数据和字体样式，减少了设计与代码之间的手动转译，同时还接入了内部工具，让任务、规范和边界情况无需切换上下文即可获取。
添加一个服务器只需一条命令：
这种模式在整个 MCP 生态中都适用。以下例子可供参考，你可以将智能体连接到：
Figma —— 官方提供的 MCP，用于从画布获取设计上下文、变量和布局数据
Atlassian Cloud —— 通过 Atlassian 的远程 MCP 接入点访问 Confluence 页面和 Jira 工作项（文档与 Rovo 一并提供）
数据库、CMS API —— 厂商或社区提供的 MCP 服务器；各类注册表按分类列出了数百种选项
你的技术栈可能有所不同——可能是私有文档 API、内部设计变量服务，或是数据仓库。思路是一样的：让智能体连接到已经掌握相关数据的系统。关于配置文件、服务器定义，以及在 Kimi Code CLI 中接入 MCP 的其他方式，请参阅平台指南。
代码审查技能
我们还写了一个用于代码审查的技能。这是一份规则文件，告诉 Kimi Code CLI 如何端到端评估一个合并请求：阅读 diff，追踪受影响的文件和组件，检查是否违反设计系统规范（原始颜色字面量、脱离网格的间距、缺失的无障碍降级方案），按区域评估风险，并生成一份结构化报告。
报告遵循固定格式：
意图和范围概述
按严重程度分组的发现（阻断合并的严重问题、建议改进项、次要一致性建议）
针对每项发现：diff 中的证据、影响评估，以及一条具体的行动建议
该技能还会标记出可能需要快速浏览器或设备验证的潜在风险——即智能体不确定，但验证成本较低的情况。
实际操作中，moonshot.ai 视觉改版期间的每个 PR 在完成审查前都会经过这一结构化流程。输出内容始终包括意图回顾、按严重程度排序的发现、证据以及修复方案。
这有助于减少后期反复修改，并提升了 Kimi Code 工作流的一致性，发现了诸如与共享常量并存的硬编码 URL、需要对齐的分析字段，以及移动端交互边界情况等问题。
一些出乎意料的发现
在重构过程中，出现了一些起初并不明显的模式。
从规范到代码的速度超出预期
在同一线程中使用 Figma MCP 和 Kimi Code CLI，尺寸和设计变量以结构化输入的形式呈现，而不需要人工转录。结果是每个环节的迭代循环变短——属性级的改动和修复往往一次就能完成，而不用在工具之间来回切换。
研究类提示词的收益超出预期
此次改版在很大程度上依赖于长篇的、以文档为驱动的浏览过程，涉及运行时文档、参考实现以及代码仓库。将这些材料保留在与代码相同的会话中，往往和修改本身一样有价值。
审查技能把细小的不一致整理成了清单
该结构化报告揭示了前面提到的同类问题——与共享常量并存的硬编码 URL、需要对齐的分析字段，以及移动端交互边界情况。每一项单独来看大多是小问题，但一旦归到同一批次中，就更容易处理。
长会话的恢复成本依然很低
像 kimi --continue 和 /compact 这样的命令，意味着跨天的工作不需要每天早上重新构建上下文。这减少了重复提示，也让同一个 Kimi Code 工作流保持稳定推进。
关于如何恢复会话、在会话间切换，以及使用 /compact 及相关命令管理上下文的更多内容，请参阅 Kimi Code CLI 会话指南。
重建 moonshot.ai 的经验总结
如果再做一次类似的 moonshot.ai 视觉改版，我们会在一些地方采取不同的做法。
从上下文开始，而不是从代码开始
花第一个小时记录范围、约束条件和规范，比之后任何提示词调整都更省时间。提前建立好这些内容，能让 Kimi Code CLI 等工具在整个工作流中表现更一致。
尽早连接一个真实数据源
在我们的案例中，这个数据源是 Figma。在其他项目中，也可能是 CMS、内部 API 或设计系统。关键是要确保系统使用的是真实数据，而不是靠推断得出的假设，尤其是在前端重构场景中使用 AI 编程 agent 时。
把设计上下文和任务上下文放在同一个循环里
把变量、规范和实现汇入同一个共享上下文，减少了来回沟通，让迭代周期更稳定。正是在这一点上，涉及 Figma MCP 和 Kimi Code CLI 的工作流表现得尤为出色，它们帮助设计意图和代码改动在一个连续循环中保持一致。
如果你不想写代码：Kimi 建站
以上描述的都是以开发者为中心的工作流——终端、diff、上下文文件。不过，当速度比框架级控制更重要时，同样可以在不依赖这套技术栈的情况下，实现一个精致、响应式的网站。
Kimi 建站 使用的同样是 Kimi K2.5 模型，但通过的是可视化、无代码的界面。你只需用自然语言描述想要的效果，通过对话逐节调整，一键发布即可。它还能以现有截图作为输入，重构出对应的布局结构。
对于正在打磨落地页的创业者，或是在紧迫时间线下上线活动页面的市场人员来说，这提供了一条比直接使用传统前端技术栈更快的路径。
结语
Kimi Code CLI 和 Kimi K2.5 在项目中广度大于复杂度的部分发挥了最大作用。视觉改版很少涉及难题，更多是需要在整个系统中保持一致的大量细小改动。这对人来说很耗时，但对能够跨文件追踪和比对的智能体来说，相对更适合处理。
决策仍由我们来做，每一处改动也都经过我们的审核和最终结果的验证。智能体负责重复性的追踪、比对和初步审查工作。实践证明，这种分工是将 AI 编程 agent 融入生产工作流的一种可行方式。对于跨文件重构、设计到代码的验证，以及大规模一致性工作，这种方式被证明是有效的。