214万 Token、2小时交付：一次真实 Cursor Composer 2.5 Fast 复盘

开工前，我们先来看一组好玩的数据。这是我记录的"AI 协作战报"：

平均每小时吞掉 107 万 Token。看到这个数字，你的第一反应可能是："你这是让 AI 写了一部四大名著吗？"当然不是。作为前端，我们心里都清楚，写代码从来不是"啪啪啪"盲打键盘的过程。

或许有人会心疼算力：为了一个静态页烧掉两百万 Token，真的划算吗？算一笔账就清楚了。在如今的商业开发里，这点算力成本甚至换不来一线城市程序员 15 分钟的工时费。但 AI 用这 214 万 Token，帮我把全站代码盲区排查、上下文切换、以及无休止的"肉眼 Bug 走查"带宽拉到了极致。这笔买卖，性价比高得惊人。

很多人用 AI 效率低，往往是因为第一步就错了——直接丢一句："帮我写个 xxxM 页面。"相信我，在成熟的商业项目里，这样做得到的代码 99% 会因为不符合项目规范而被你直接 git checkout .。

我们拿到的这个老项目技术栈是 Nuxt 3 + Vue 3 + Vue I18n + PostCSS (pxtorem)，同时有着非常严格的 PC/Mobile 双端自适应布局。所以，我坐下后的前 20 分钟，一口雷达都没有放，而是拉着 Composer 先去"拜码头"（代码库走读）：

这一阶段，我们的代码产出是 0。但事实证明，磨刀不误砍柴工，这帮我们规避了后续至少 3 次以上的方向性返工。

当 Cursor 摸清了项目的脾气，真正的开发就像顺水推舟了。

1. 骨架与 SEO 灌水

我们新建了 pages/xxxm/index.vue。Nuxt 3 的 useHead() 配置极其繁琐，各种 title、description 还有 og:image 等 Meta 标签。交给 Cursor 吧，它熟练得像个干了十年的全栈，按照项目既有的 FAQ 页面依葫芦画瓢，一秒钟生成完毕。

接着是 Hero 首屏核心组件 components/xxxm/Hero.vue。这个页面包含 Badge、大标题、CTA 按钮、以及 Trustpilot 评价区。为了减少网络请求和资源管理的麻烦，我让 Cursor 把 Trustpilot 的图标直接切成了内联 SVG。干净利落。

2. 多语言无痛补齐

前端最痛苦的体力活是什么？多语言绝对排得进前三。开发完页面，你得去四个不同的 JSON 文件里硬编码对应的翻译。稍不留神漏掉一个 Key，线上就会给用户展示大写的 ERROR_KEY_NOT_FOUND。

这一次，我把页面组件往 Composer 里一丢："帮我把这个组件里所有的硬编码文案提取出来，同步写入 en、zh、ja、ko 的 JSON 文件里，注意保持原有的嵌套规范。"

中间有个小插曲：第一轮跑完，Cursor 漏掉了中英双端的部分字段，导致页面局部"开天窗"。要是以前，我得自己去比对四个大文件，而现在我只需要在终端截图或者复制报错提示给它，它能在 5 秒钟内定位到漏掉的那个逗号，并瞬间补齐。

UI 工程师的勋章，大多是在适配移动端时被授予的。当我们在 PC 端看着完美的画面时，一拉小浏览器窗口，或者切到移动端视图，灾难往往就发生了。

如果说前四个阶段只是丝滑的"降维打击"，那么第五阶段的故障排查，才让我真正感受到了结对编程的魅力。

在桌面端自适应测试全部通过后，我掏出真机进行最后的走查。一进入 /xxxm 页面，我的心凉了半截：移动端网页顶部的 Header 导航栏，竟然凭空消失了。 白字白底？样式遮挡？z-index 太低？如果按照传统的排查思路，我可能会在 Chrome DevTools 里不断勾选样式，折腾个十来分钟。

我把这个现象丢给了 Cursor。通过对全项目上下文的检索，它在 30 秒内给出了一个完全出乎我意料的推断："这不是 Header 的样式问题。根源在于项目的 MobileLayout 路由分流逻辑。这个祖传的移动端模板内部压根就没有引入 BaseHeader 组件，它默认页面自己去处理导航！"

破案了。AI 紧接着给我出了两套方案：

方案 A（激进）： 改造路由分流逻辑，强行让 xxxM 页面在移动端也挂载 PCLayout 的魔改版。

方案 B（稳健）： 大面积重构移动端 Layout 的 DOM 结构，把 Header 统一塞进去。

坐在电脑前的我，看着这两个方案，陷入了沉思。这两个方案听上去都很诱人，都能解决问题，甚至能给项目带来所谓的"架构优化"。但是，我今天接到的需求只是加一个 xxxM 的活动页，而不是去重构全站的布局体系。动了 Layout，全站其他几十个活着的页面一旦哪个出了错，那就是通宵起步的线上事故。

于是，我做出了这次协作中最重要的一次决策：全部回滚，另辟蹊径。 我们果断调用 Git 撤销了对全局布局的大胆尝试。为了既不污染全局，又能彻底解决移动端导航缺失的问题，我指示 AI 采用了一种更精准的局部解耦方案：

<!-- 最终的局部保命解法方案 -->
<template>
  <div class="xxxm-page-wrapper">
    <BaseHeader :current-page="'xxxM'" />
    <main>
      <XxxMHero />
    </main>
    <ClientOnly>
      <MobileNavPatch v-if="isMobile" />
    </ClientOnly>
  </div>
</template>

这种做法虽然在架构层面上有些"特殊处理"，但它把变更风险完美控制在了当前页面内部，彻底杜绝了 SSR 水合（Hydration）不一致导致的线上白屏隐患。

复盘这忙碌的 2 个小时，我深刻体会到，AI 并没有抢走我的饭碗，它更像是把原本套在我手脚上的沙袋摘掉了。

这次的交付谈不上惊天动地，甚至可以说是前端日常中最琐碎、最接地气的一种需求。但当我在 2 小时内关闭所有 Tab、提交 Pull Request 的那一刻，我看着空空如也的待办列表，由衷地感到一种久违的轻松。

AI 真正压缩的，不是我们写核心代码的时间，而是那些我们在查阅文档、核对字段、切换上下文、以及在代码堆里玩"捉迷藏"时浪费掉的生命。不要把 AI 当成一个自动写代码的机器，把它当成一个随时待命、不知疲倦、熟读你项目所有源码的高级副驾。 握好你的方向盘，接下来，把枯燥的直线加速，都交给它吧。