600个文件，一条命令：moonshot.ai 的代码重构揭示了AI Agent在实战中的价值

2026年3月，moonshot.ai推出了全新外观。更新日志读起来就像设计师的心愿清单：全新的色彩方案、更紧凑的排版、更新的动效。然而，幕后工作却一点也不光鲜。

此次更新涉及整个网站的共享组件、设计令牌、路由和交互层。没有一项编辑在算法上很难。挑战在于广度：要知道每个改动影响到什么，并确保不出任何差错。这种工作正是AI编码Agent能够体现价值的地方，也可能在噪声中烧光预算的地方。

Moonshot的工程团队使用由Kimi K2.5驱动的Kimi Code CLI作为这次重构的主要助手。该项目运行在一个具有实际限制的生产代码库上：没有演示沙箱，没有精心挑选的任务。发布在一份详细的事后分析中的结果，让我们得以冷静地审视一个基于终端的Agent到底擅长什么，以及哪些环节仍需要人类介入。minimax-launches-m27-model-with-strong-software-engineering-and-office-productivity-skills

核心见解：广度胜于复杂度

Moonshot的更新并非重写核心逻辑，而是追踪共享令牌、更新组件、检查交互行为，并确保分析和无障碍功能完好。每一项单独看都很简单。合在一起，却令人筋疲力尽。how-local-llms-like-gemma-and-qwen-are-taming-open-source-repository-triage-at-scale

团队的第一步不是编写提示词。他们运行/init生成AGENTS.md文件，然后花费大约一个小时进行完善：明确哪些在范围内、哪些不能更改、项目的结构如何、构建如何运行。他们还为命名、间距和对比度添加了规则文件。

前期的投入得到了回报。如果没有项目特定的上下文，AI Agent往往会产生合理但通用的结果。有了上下文后，Agent的行为更接近已经了解代码库的队友。

Agent的实际使用方式

重构过程定义了六个不同的工作流，每个都针对生产流程的特定阶段, , 不是为了自动化而自动化，而是为了减少不确定性。

在修改代码前追踪依赖关系

在编辑任何内容之前，团队要求Kimi Code CLI读取目标区域并列出依赖它的内容。例如，修改按钮颜色可能会波及主视觉区、下载号召性用语、悬停状态和共享令牌。首先获得这张依赖图谱，使得编辑变得可预测，并减少了意外出错的可能性。

将代码与Figma设计稿匹配

通过与Figma的模型上下文协议（MCP）连接，Agent直接从设计工具中提取设计令牌、布局数据和排版。逐组件比较变成了一个结构化流程：主视觉、导航、产品区域、页脚。Agent通过将样式与设计令牌和布局值进行匹配，生成了按属性排列的变更清单。大多数差异很小（间距、圆角、字重），但Agent也暴露了较大的不一致之处, , 那些本应共享变体的组件随着时间的推移已经出现了偏差。

研究新的交互行为

此次更新引入了现有代码库中不存在的功能：自定义光标、运行时驱动的主视觉、悬停播放的插画卡片以及滚动触发的入场动画。针对每一项，团队都将文档和代码库状态加载到同一个会话中。Kimi K2.5的大上下文窗口让Agent能够一次性推理实现逻辑和参考资料。

这些问题非常实际：悬停动画应该在退出时完成还是取消？光标状态是否与主视觉画布交互？多层重叠时会发生什么故障？将设计意图和代码保留在同一会话中，使得更快获得这些答案成为可能。

检查体积和性能

此次更新引入了新的字体、更多的动效和额外的资源。Agent调整了现有的字体子集化脚本，验证输出，并帮助尽早解读Lighthouse报告。目标不是在最后优化所有内容；而是在改动还很小的时候做出保留或删除的决定。

在合并前追踪集成风险

多个交互层（入场动画、光标、主视觉画布）共享排序和指针行为。Agent追踪了跨多个差异（diffs）的潜在交互冲突，标记了一个层的更改可能破坏另一个层的情况。跨浏览器和跨操作系统的差异增加了另一个维度。

通过自定义Skill进行结构化代码审查

团队编写了一个Skill，即一个规则文件，告诉Kimi Code CLI如何端到端地评估一个合并请求。Agent读取差异，追踪受影响的文件和组件，检查设计系统违规（原始颜色字面量、偏离网格的间距、缺少无障碍备用方案），按区域评估风险，并生成一份按严重程度分组的结构化报告。

更新期间的每个PR在审查完成之前都经过了这一轮检查。输出总是包含意图总结、按严重程度排序的发现及其依据，以及具体的行动项。硬编码的URL与共享常量相邻、需要对齐的分析字段以及移动端交互的边缘问题，在这里被捕获，在它们到达审查者的收件箱之前就被发现了。cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

让团队意外的事情

出现了三个在开始时并不明显的模式。

设计稿到代码的速度比预期更快。借助在同一线程中的Figma MCP和Kimi Code CLI，尺寸和设计令牌以结构化输入的形式传入。每个部分的迭代周期缩短了。属性级别的更改和修复通常一次提交就能完成，而不是在工具之间来回切换。

研究提示词的回报超出了预期。此次更新高度依赖长时间的、由文档驱动的过程，这些过程涉及运行时文档和参考实现，以及代码库本身。将这些材料与代码保持在同一个会话中，其价值往往与修改本身一样大。

审查Skill将小的不一致之处变成了一个可管理的列表。硬编码的URL、分析对齐、移动端边缘情况。大多数单独来看都很小，但一旦在单次检查中分组处理，就更容易解决。长对话线程通过kimi, continue和/compact命令保持低成本，避免了每天早晨重建上下文。the-hidden-bottleneck-in-ai-inference-why-deepseeks-dspark-rewrites-the-rules-of-speculative-decoding

分界线：谁做什么

团队明确划分了职责：他们做出决策、审查每项更改并验证最终结果。Agent处理重复的追踪、比较和初步审查工作。这种区分很重要，因为它定义了AI编码Agent在生产工作流中的实际边界。

对于跨文件重构、设计到代码验证以及大规模一致性工作，这种方法被证明是有用的。Agent消除了最繁琐的部分（人类需要在脑海中记住600个文件并逐一比较差异的部分）。但它并没有取代架构师、审查者或对最终体验签字确认的人。

对于考虑类似工作流的团队，经验教训很明确：提前投入项目上下文的建设，尽早连接事实来源（Figma、CMS、内部API），并将设计意图和代码保持在同一个循环中。Agent放大了一致性工作方面的广度。人类拥有决定性的决策权。ibms-open-source-cuga-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list