---
title: "我是如何用 AI 把4小时的前端需求缩短到75分钟的？"
date: 2025-11-11
description: "实战复盘利用 AI 协同将 4 小时前端需求缩短至 75 分钟，实现 71% 的效能提跃。展示了从“代码考古”向精准导航的转变、利用 Prompt 约束实现 5 种状态机与 30 条多语言文案的生成。探讨“信任但验证”的闭环机制，通过诊断工具纠偏，确保产出零 Bug 生产级代码。分享 AI 时代从机械体力劳动向高价值架构驱动进化的智能工作流，显著提升交付水平，重塑单兵作战能力。"
canonical_url: "https://yijinlee.com/articles/article-25"
tags:
  - "AI 协同"
  - 前端提效
  - "Prompt 工程"
  - 状态机
  - "0 Bug 提测"
topic: "AI 外骨骼"
---

早上10点，一杯美式刚下肚，产品经理的经典开场白就在我耳边响起了：“咱们 PromoPage 和首页需要上个促销活动模块，需求很简单，怎么实现你看着办，最好这周能上。”

我打开需求文档扫了一眼，眉头渐渐皱了起来。这哪里是“简单需求”？

组件要求：得从零手搓一个通用的 Promotion（促销）组件；

接口对接：要集成三个不仅名字长、逻辑还绕的 API（查询活动页、查询记录、活动下单）；

状态流转：包含“未领取、已领取、已使用”等整整 5 种不同的交互状态；

国际化：不仅得支持中文，还得配齐英文和日文；

业务规矩：除了前端展示，还得加上埋点上报，符合规范。

如果是以前，接到这样一个中等复杂度的需求，我的大脑会自动规划出一套标准但折磨人的“体力劳动流”：先去庞大的代码仓库里Ctrl+Shift+F“大海捞针”找类似的 API 怎么调；接着吭哧吭哧写模板、配状态机；然后把整理好的文案丢进翻译软件或者等翻译团队给反馈，最后再花大把时间处理那些在不同状态下容易出 Bug 的交互逻辑。粗略一算，怎么也得大半天（差不多4个多小时）搭进去。

但这次，我决定换个玩法。作为团队里的“效率偏执狂”，我决定让 AI 全程深度参与这次开发。不是简单地让它帮我写个正则表达式或者查个报错，而是把它当成一个“高级外包”，跑通一个**“从需求理解到代码交付”的全链路智能工作流**。

结果？这套原本需要 255 分钟的活儿，我只花了 75 分钟就搞定了，而且是零 Bug 提测。

接下来，我就复盘一下，这不可思议的 71% 效率提升，到底是怎么发生的。

阶段一：从“大海捞针”到“精准导航”，代码探索的降维打击

每一个前端老兵都知道，接手新需求最痛苦的往往不是写代码，而是“找代码”。
去哪里找现成的工具类？上一个接口别人是怎么封装的？埋点上报的公共方法到底藏在哪个 utils 文件夹里？

以往，这个过程我称之为“考古”。但在 AI 的加持下，考古变成了“问路”。

我没有去翻代码，而是直接把本地代码库作为上下文，给 AI 下达了第一个指令：
“我要在 PromoPage 开发促销模块，请帮我分析全局代码，找出：1. fetchCampaignBySlot 等三个 API 的定义和调用规范；2. 路由跳转（如中日文页面跳转）相关的工具函数；3. 现有的埋点上报标准模式。”

奇迹发生了。AI 就像一个在这个项目里干了三年的老员工，瞬间帮我梳理出了所有关键信息：它不仅找到了 jumpLocalizedPromoPage 和 getUserRegion 这两个我大概率会漏掉的工具函数，还极其清晰地把国际化文案（i18n）的结构和多语言配置方案给我列了个表格。

数据说话： 这个通常需要我反复跳转文件、耗时 45 分钟以上的代码走读工作，在 AI 的“精准导航”下，仅仅花了 15 分钟。我连一口咖啡都没喝完，地基就已经打好了。

阶段二：告别“复制粘贴”，高质量代码的瞬间生成

摸清了底细，重头戏来了——写组件。

以前写这种包含复杂状态的组件，最烦的就是写又臭又长的 switch-case 或者 if-else，还要兼顾各种边界情况。这次，我把需求文档里的规则（3条展示规则、3条交互规则、5种错误处理方案）揉在一起，加上明确的质量要求，写了一个堪称“紧箍咒”的 Prompt（提示词）丢给 AI：

“请基于以上梳理的 API 和工具库，使用 React+TypeScript 编写 Promotion 组件。要求：严格遵循 SOLID 原则；使用状态机模式管理 NOT_CLAIMED 等 5 个状态；处理 5 种特定的错误边界；并同时生成中/英/日三语共 30 条文案配置。要求产出高质量、0 语法错误的代码。”

当我按下回车，看着 AI 一行行吐出代码的时候，那种感觉就像是你在旁边监工，看着一个极其靠谱的高级前端在疯狂敲键盘。

它不仅把 5 个状态的管理写得明明白白，甚至连我没想到的兜底 UI 都做了处理。最让我惊艳的是那 30 条多语言文案，以往我要在一个硕大的 JSON 文件里疯狂找括号对齐，现在 AI 直接按照项目的目录结构和配置方式，给我生成了可以直接 Copy-Paste 的结构化数据。

当然，身为老鸟，我不可能盲目信任 AI。代码生成后，我立刻跑了项目里的 getDiagnostics 工具进行自动化校验。结果屏幕上亮起绿灯：0 语法错误，类型完全匹配，直接可用。

数据说话： 原本预计需要 120 分钟的组件开发，加上 60 分钟的多语言配置，总计 3 小时的苦力活。在 AI 的操刀下，仅仅耗时 55 分钟（组件40分钟 + 多语言15分钟）。

阶段三：兵来将挡，让产品经理尽情改需求吧

做开发的都知道，世界上最可怕的一句话是：“我这里有个小逻辑想改一下”。

在组件初步成型后，产品经理凑了过来，看了一眼写死数据的 Demo，搓了搓手：“那个……UI 细节咱再微调一下？还有个重要逻辑忘写了，如果券码被抢光了，或者活动过期了，这个活动模块得完全隐藏掉，不能让用户点进来报错。”

放在过去，这意味着我得回去改状态逻辑，甚至可能要重构部分渲染树。但我当时内心毫无波澜，甚至有点想笑。

我直接把 UI 调整的设计截图喂给 AI，并加上了新的文字补充：“根据截图调整 CSS 样式，并增加两条拦截逻辑：券码发放完毕，或当前时间 > 活动期限时，组件 return null。”

AI 瞬间理解了这种“隐式需求”。它不仅快速更新了样式表，还非常聪明地在组件生命周期的最前面，把拦截逻辑加了进去，甚至帮我把日期的对比转换逻辑都处理得严丝合缝。

数据说话： 这套包含回归测试和修 Bug 的“验证+修改”环节，传统方式至少得折腾半小时。这次，从给 AI 提需求到代码更新、测试通过，只用了区区 5 分钟。

复盘：为什么我的 AI 不是“人工智障”？

看完上面这些，你可能会问：“为什么我用的 AI 生成的代码总是一堆 Bug，而你却能提升 71% 的效率？”

其实，这背后的核心差异在于“使用姿势”。这次任务让我深刻总结出了保障代码质量和效率的三个关键秘诀：

1. 像管理下属一样设计 Prompt（提示词）
不要只给 AI 说“帮我写个促销组件”。你要明确质量标准！在提示词中加上“充分走读上下文代码”、“符合规范原则”、“要求 0 语法错误”、“涵盖多少种状态”等约束条件。你越严谨，AI 就越专业。

2. 建立“信任但验证”的迭代机制
不要指望 AI 一次性写出完美无瑕的万行代码。把任务拆解成小块，每完成一个阶段（比如生成了 API 调用逻辑），就用项目自带的检查工具（如 getDiagnostics）做一次自动化检查。把错误及时抛给 AI 修复，不让 Bug 堆积过夜。

3. 把“上下文”喂到它嘴里
很多人的 AI 写出的代码没法直接用，是因为 AI 不懂你们公司的代码规范。通过第一阶段的“代码探索”，我让 AI 深刻理解了现有项目的 API 设计习惯、国际化方案和埋点规则。带着这些上下文写出来的代码，自然带着一股“原汁原味”的团队风格。

写在最后：当效率提升 71%，我们在期待什么？

算一笔总账：

代码走读：45分钟 ➔ 15分钟（提效 67%）
组件开发：120分钟 ➔ 40分钟（提效 67%）
多语言配置：60分钟 ➔ 15分钟（提效 75%）
测试验证：30分钟 ➔ 5分钟（提效 83%）

总耗时从 255 分钟锐减至 75 分钟，综合提效高达 71%！

这绝不仅仅是“少敲几行代码”那么简单。它代表着一种彻底的效率革命——从需求理解、代码探索、逻辑实现到质量验证的全链路优化。

对于我们开发者而言，这意味着什么？

这意味着，相同的薪水，你可以少加无数个班；这意味着，那些消耗你热情的、枯燥的“体力活”（比如写模板、配多语言、查报错），终于可以外包出去了。省下来的这三个小时，你可以去喝杯好咖啡，可以去优化项目的底层架构，可以去思考更有价值的业务创新。

AI 从来不是来抢开发者饭碗的，它是来淘汰那些只会“复制粘贴”的机器人的。当 AI 成为你的“超级副驾”，你会发现，其实我们每个人，都可以拥有 10x 高级工程师的战斗力。

## 参考文章：相关链接

- [Cursor · Agent / Composer](https://docs.cursor.com/composer)（官方文档）— Composer 工作流官方说明，对照 4h→75min 的分工方式。
- [Google · Accelerate / DORA metrics](https://dora.dev/research/)（权威引文）— 交付效能研究框架，用领导层听得懂的语言谈提效。
- [全栈开发实战复盘：30分钟搞定评论系统](https://yijinlee.com/articles/article-28)（站内深度）— 另一组可量化的 AI 交付数据。
- [214万 Token、2小时交付：Cursor Composer 复盘](https://yijinlee.com/articles/article-45)（站内深度）— 更大规模 Token 账本下的交付边界。