--- title: "214万 Token、2小时交付：一次真实 Cursor Composer 2.5 Fast 复盘" date: 2026-03-31 description: "当你以为\"加个 Campaign 页面\"只是多一条路由时，成熟项目里的祖传 Layout、SSR 水合与四国 i18n 会立刻把简单需求变成全链路排雷。本文用 214.1 万 Token、约 2 小时墙钟时间的真实结对记录，拆解 Cursor Composer 2.5 Fast 在代码走读、国际化、响应式与导航消失案中的边界，以及人类工程师何时必须踩下回滚刹车。" canonical_url: "https://yijinlee.com/articles/article-45" tags: - "AI Coding" - Cursor - "Composer 2.5 Fast" - "Nuxt 3" - "Vue 3" - "Vue I18n" - SSR - 结对编程 - Campaign topic: "AI 外骨骼" --- METRICS: 214.1万 Token · 约2小时 · 107万/h · Campaign 四国落地页 你可能也在各类技术社区里看过无数形如"AI 编程让我效率翻倍"的爽文，但作为一个在一线摸爬滚打多年的前端，我过去对这种言论大都持保留态度。直到最近，在维护公司某跨境内容站项目时，我接到了一个看似平平无奇的需求：在导航栏"Download"后新增一个"Campaign"页面入口，完成首屏落地页开发，同时支持四国语言与移动端自适应。 "不就是加个路由、画个静态页吗？"如果只看产品文档，大部分人脑海里闪过的第一反应都是这句。但真正做过成熟项目重构或维护的人都知道，越是"加个页面"的简单需求，里面暗藏的"祖传代码屎山"和"全链路依赖"就越多。这一次，我决定把整个开发上下文彻底移交给 **Cursor Composer 2.5 Fast**，和它进行了一场长达 2 小时的深度结对编程。在这场拧螺丝的战斗中，我们疯狂消耗了 **214.1 万 Token**。今天不想吹嘘 AI 有多神，只想卸下防备，跟你聊聊这次真实交付中的阵痛、决策，以及 AI 在工程落地时的真正边界。 ### 一、账单里的秘密：214万 Token 到底花在哪了？ 开工前，我们先来看一组好玩的数据。这是我记录的"AI 协作战报"： | 核心指标 | 坐下开工前 | 抬头起身后 | 净增量 / 消耗 | | :--- | ---: | ---: | ---: | | 累计 Token 数 | 4470.2 万 | 4684.3 万 | **214.1 万** | | 官方高额额度占比 | 21.2% | 22.9% | +1.7% | | 墙钟时间 (Wall Time) | — | — | **约 2 小时** | 平均每小时吞掉 **107 万 Token**。看到这个数字，你的第一反应可能是："你这是让 AI 写了一部四大名著吗？"当然不是。作为前端，我们心里都清楚，写代码从来不是"啪啪啪"盲打键盘的过程。 💡 **Token 去向速览：** 这 214 万 Token 里面，真正变成 template 和 style 的可能不到 **10%**。剩下的 **90%**，全是 Cursor 在帮我干这些苦力活：阅读老项目的组件上下文、肉眼排查 Nuxt 3 SSR 的水合问题、分析多语言 JSON 文件的嵌套层级，以及……陪我一起推演各种妥协的架构方案。 或许有人会心疼算力：为了一个静态页烧掉两百万 Token，真的划算吗？算一笔账就清楚了。在如今的商业开发里，这点算力成本甚至换不来一线城市程序员 15 分钟的工时费。但 AI 用这 214 万 Token，帮我把全站代码盲区排查、上下文切换、以及无休止的"肉眼 Bug 走查"带宽拉到了极致。**这笔买卖，性价比高得惊人。** ### 二、第一阶段：别急着敲键盘，先带 AI"拜码头" 很多人用 AI 效率低，往往是因为第一步就错了——直接丢一句："帮我写个 Campaign 页面。"相信我，在成熟的商业项目里，这样做得到的代码 99% 会因为不符合项目规范而被你直接 `git checkout .`。 我们拿到的这个老项目技术栈是 **Nuxt 3 + Vue 3 + Vue I18n + PostCSS (pxtorem)**，同时有着非常严格的 PC/Mobile 双端自适应布局。所以，我坐下后的前 20 分钟，一口雷达都没有放，而是拉着 Composer 先去"拜码头"（代码库走读）： #### 走读 1：摸清导航的底细 锁定 `AppHeader.vue`，让 AI 分析现有的 `navList` 数据结构，搞清楚它是怎么判断高亮（active 状态）和路由跳转（`toPage`）的。 #### 走读 2：拆解双端布局 翻开 `DesktopLayout` 和 `MobileShell`，看一看到底是纯 CSS 媒体查询，还是走的总线 UA 判断？Header 组件在双端是怎么复用的？ #### 走读 3：盘点国际化资粮 检查 `locales/` 下的 `en/zh/ja/ko.json`，摸清他们现有的 Key 命名习惯。是扁平化的 `"header_title"`，还是层级嵌套的 `"header": { "title": "..." }`？ 这一阶段，我们的代码产出是 **0**。但事实证明，磨刀不误砍柴工，这帮我们规避了后续至少 **3 次以上**的方向性返工。 ### 三、第二与第三阶段：骨架搭建与让人头疼的国际化 当 Cursor 摸清了项目的脾气，真正的开发就像顺水推舟了。 #### 1. 骨架与 SEO 灌水 我们新建了 `pages/campaign/index.vue`。Nuxt 3 的 `useHead()` 配置极其繁琐，各种 title、description 还有 og:image 等 Meta 标签。交给 Cursor 吧，它熟练得像个干了十年的全栈，按照项目既有的 FAQ 页面依葫芦画瓢，一秒钟生成完毕。 接着是 Hero 首屏核心组件 `components/campaign/HeroSection.vue`。这个页面包含 Badge、大标题、CTA 按钮、以及第三方评价组件区。为了减少网络请求和资源管理的麻烦，我让 Cursor 把第三方评价组件的图标直接切成了内联 SVG。干净利落。 #### 2. 多语言无痛补齐 前端最痛苦的体力活是什么？多语言绝对排得进前三。开发完页面，你得去四个不同的 JSON 文件里硬编码对应的翻译。稍不留神漏掉一个 Key，线上就会给用户展示大写的 `ERROR_KEY_NOT_FOUND`。 这一次，我把页面组件往 Composer 里一丢："帮我把这个组件里所有的硬编码文案提取出来，同步写入 en、zh、ja、ko 的 JSON 文件里，注意保持原有的嵌套规范。" 中间有个小插曲：第一轮跑完，Cursor 漏掉了中英双端的部分字段，导致页面局部"开天窗"。要是以前，我得自己去比对四个大文件，而现在我只需要在终端截图或者复制报错提示给它，它能在 5 秒钟内定位到漏掉的那个逗号，并瞬间补齐。 ### 四、第四阶段：响应式适配，才是细节里的魔鬼 UI 工程师的勋章，大多是在适配移动端时被授予的。当我们在 PC 端看着完美的画面时，一拉小浏览器窗口，或者切到移动端视图，灾难往往就发生了。 💡 **提效心法：** 不要让 AI 去盲目发明新的响应式样式，而是让它去"复用全站已经验证过的 CSS 范式"。这样写出来的样式，不仅视觉上跟全局高度统一，而且代码极度克制。 #### 翻车 1：大标题断行异常 **现象：** 屏幕缩到 692px 左右时，主标题因为字数太长，撑爆了容器。 **AI 的解法：** 抛弃了生硬的媒体查询换行，直接帮我改用 `clamp(24px, 4vw, 48px)` 的流式字体控制，让标题随着屏幕丝滑缩放。 #### 翻车 2：CTA 按钮"叠罗汉" **现象：** 空间不够时，两个并排的按钮挤成了一坨。 **AI 的解法：** 快速重构为 `flex-wrap`，并在移动端自动切换为上下纵向排列，顺便补上了优雅的 `gap`。 #### 翻车 3：第三方评价组件区域越界 **现象：** 评价区的宽度在移动端显得过于臃肿。 **AI 的解法：** 像素级致敬了项目中已有成功实践的 `@media (max-width: 768px)` 媒体查询方案。 ### 五、第五阶段：惊心动魄的"导航消失案"与回滚抉择 如果说前四个阶段只是丝滑的"降维打击"，那么第五阶段的故障排查，才让我真正感受到了结对编程的魅力。 在桌面端自适应测试全部通过后，我掏出真机进行最后的走查。一进入 `/campaign` 页面，我的心凉了半截：**移动端网页顶部的 Header 导航栏，竟然凭空消失了。** 白字白底？样式遮挡？z-index 太低？如果按照传统的排查思路，我可能会在 Chrome DevTools 里不断勾选样式，折腾个十来分钟。 我把这个现象丢给了 Cursor。通过对全项目上下文的检索，它在 30 秒内给出了一个完全出乎我意料的推断：**"这不是 Header 的样式问题。根源在于项目的 MobileShell 路由分流逻辑。这个祖传的移动端模板内部压根就没有引入 AppHeader 组件，它默认页面自己去处理导航！"** 破案了。AI 紧接着给我出了两套方案： **方案 A（激进）：** 改造路由分流逻辑，强行让 Campaign 页面在移动端也挂载 DesktopLayout 的魔改版。 **方案 B（稳健）：** 大面积重构移动端 Layout 的 DOM 结构，把 Header 统一塞进去。 坐在电脑前的我，看着这两个方案，陷入了沉思。这两个方案听上去都很诱人，都能解决问题，甚至能给项目带来所谓的"架构优化"。但是，我今天接到的需求只是加一个 Campaign 的活动页，而不是去重构全站的布局体系。**动了 Layout，全站其他几十个活着的页面一旦哪个出了错，那就是通宵起步的线上事故。** 于是，我做出了这次协作中最重要的一次决策：**全部回滚，另辟蹊径。** 我们果断调用 Git 撤销了对全局布局的大胆尝试。为了既不污染全局，又能彻底解决移动端导航缺失的问题，我指示 AI 采用了一种更精准的局部解耦方案： ```vue ``` 这种做法虽然在架构层面上有些"特殊处理"，但它把变更风险完美控制在了当前页面内部，彻底杜绝了 SSR 水合（Hydration）不一致导致的线上白屏隐患。 💡 **回滚哲学：** AI 最大的优势，是帮我们把试错成本降到了近乎为零。10 分钟写出来的复杂架构方案，不合适时，我们可以在 10 秒钟内无痛删掉。**敢于回滚，这也是当前阶段人类工程师必须握紧的刹车闸。** ### 六、深度思考：AI 时代的结对编程，我们该如何自处？ 复盘这忙碌的 2 个小时，我深刻体会到，AI 并没有抢走我的饭碗，它更像是把原本套在我手脚上的沙袋摘掉了。 📌 **那些可以闭眼交给 AI 的事** - 代码检索与定位："帮我找出所有引用了 active-menu 的地方"，速度堪称降维打击。 - 枯燥的样板代码：I18n 翻译对齐、Nuxt SEO 灌水、枯燥的 SCSS 嵌套，AI 永远不会疲劳，也不会敲错单词。 - 第一轮 Bug 诊断：当控制台抛出一段冗长莫名的 SSR 报错时，AI 往往能一针见血地指出是哪个生命周期钩子里用了 `window` 对象。 ⚠️ **人类工程师必须死守的防线** - 确立需求的边界：明白"什么该改，什么不该动"。AI 永远有重构全世界的冲动，但你需要对生产环境保持敬畏。 - 踩死架构的刹车：当 AI 给出好、中、差三种方案时，你要有能力评估技术债的利弊，并果断在合适的时候选择"回滚"。 - 交付的终极验收：真机上的丝滑程度、弱网环境下的体验、真正的 SEO 爬虫抓取预期，这些直觉性的东西，依然掌握在人的手里。 ### 尾声：写在最后 这次的交付谈不上惊天动地，甚至可以说是前端日常中最琐碎、最接地气的一种需求。但当我在 2 小时内关闭所有 Tab、提交 Pull Request 的那一刻，我看着空空如也的待办列表，由衷地感到一种久违的轻松。 AI 真正压缩的，不是我们写核心代码的时间，而是那些我们在查阅文档、核对字段、切换上下文、以及在代码堆里玩"捉迷藏"时浪费掉的生命。**不要把 AI 当成一个自动写代码的机器，把它当成一个随时待命、不知疲倦、熟读你项目所有源码的高级副驾。** 握好你的方向盘，接下来，把枯燥的直线加速，都交给它吧。 ## 参考文章：相关链接 - [Cursor · Composer](https://docs.cursor.com/composer)（官方文档）— Composer 官方能力与限制，解读 214 万 Token 账单。 - [OpenAI · Token usage](https://platform.openai.com/docs/guides/text-generation)（权威引文）— Token 计费与上下文窗口常识，向管理者解释成本结构。 - [如何降低 AI 代码的方差：Cursor 规则工程](https://yijinlee.com/articles/article-40)（站内深度）— 烧 Token 之前先降方差。 - [300 万 Token 的幽灵 Bug 捕获实录](https://yijinlee.com/articles/article-52)（站内深度）— 另一份高 Token 成本的排障账单。