一个前端一天可以做多少页面?

一个前端一天能做多少页面?这个问题没有固定答案,但在真实项目中,绝大多数情况下是 0.5–3 个页面/天(中等复杂度),极端情况下能到 5–10+ 个(纯切图/高度重复/用 AI 工具)。

下面按 2025–2026 年国内互联网/外包/大厂/中小厂的真实反馈和观察,给你一个务实的分层对比表(基于知乎、掘金、V2EX、Reddit、脉脉等高赞讨论共识):

页面类型 & 复杂度典型日完成量(经验中级前端,8小时有效编码)影响因素 & 真实案例备注对应场景 / 项目类型
极简静态页(纯 HTML+CSS,无交互)3–8 个复制粘贴模板 + 改颜色/文字,AI 工具(如 v0、Cursor)可 10+ 个外包低价站、营销落地页批量
简单业务页(表单、列表、Tab切换)2–4 个有基本交互 + 响应式 + 调接口,设计师给好设计稿中后台管理系统、H5 活动页
中等复杂度页(复杂布局、动画、组件封装)1–2 个涉及自定义组件、状态管理、性能优化、适配多端官网、电商详情页、小程序主页面
高复杂度页(重交互、3D、WebGL、大屏、复杂表单校验)0.3–1 个(甚至 2–3 天/页)需要写大量 JS 逻辑、调试浏览器兼容、像素级还原、跟设计师反复对齐营销 H5、数据可视化大屏、复杂 SaaS 页面
使用 AI 工具加速后(Cursor / v0 / Claude / Windsurf)+50% ~ +300%(1 天干传统 3–10 天活)先让 AI 生成布局/组件,再手动修交互/逻辑/性能,2025–2026 年已成主流提效方式创业公司/个人项目/快速原型

更现实的“一天工作量”拆解(中级前端,正常 8 小时)

  • 纯切图/布局阶段:2–5 个页面(Tailwind / UnoCSS / Shadcn 等现代工具下更快)
  • 加交互 + 调接口 + 联调:通常砍一半,只剩 1–2.5 个
  • 像素级还原 + 动效 + 兼容性 + 测试:再砍一半,0.5–1.5 个
  • 开会/需求澄清/改稿/写文档/ code review:有效编码时间经常只剩 4–6 小时 → 再砍 30–50%

所以大厂/中大型项目里,一个前端一个月交付 15–30 个页面(中等偏上复杂度)已经算正常偏快节奏了。
外包/小厂/创业公司如果赶工期,经常 1 天 3–5 个,但质量和可维护性通常打折。

影响“一天多少页”的核心变量(排序从高到低)

  1. 设计稿质量 & 复杂度 → 设计师给的稿越乱/细节越多,前端越慢
  2. 交互/动效需求 → 简单 Tab vs 复杂拖拽/粒子动画/3D 差 5–10 倍时间
  3. 是否需要像素级还原 → 要像素级 vs “大概像就行” 差 2–4 倍
  4. 框架/工具链 → Vue/React + Tailwind + Shadcn vs 纯原生 CSS/JS 差 2–3 倍
  5. AI 辅助程度 → 2026 年用好 Cursor/v0 的前端,效率轻松翻倍甚至更多
  6. 经验 & 专注度 → 5 年+ 老手 vs 1 年新人,速度差 2–3 倍
  7. 联调/后端接口稳定性 → 接口经常变/没 mock,前端时间浪费在等和改上

一句话总结(最扎心的版本):

一个正常业务项目里,中级前端一天真正“高质量交付”的页面数,通常是 1–2 个(中等复杂度)。
吹一天 5–10 个的,要么是极简页/批量复制、要么是 AI 神助攻、要么是质量/可维护性不要了。

你现在问这个,是自己被 leader 压 KPI 了,还是在评估某个项目的工作量?
或者想知道用 AI 工具后能提效到什么程度?说说你的具体情况(技术栈、页面类型、公司类型),我可以给你更针对性的估算~

Read more

【Web】RCTF 2025 wp(随便看看

随便看看 目录 photographer RootKB Auth maybe_easy photographer 看到要求Auth::type()小于0才能拿到flag 而$user['type']是从findById里取出来的 findById是个左联查询,返回的不只是user的信息,还有photo的信息 题目用的是SQLITE3_ASSOC模式,也就是返回以列名索引的数组 这里有个前置知识 而user和photo均有type字段 photo的type字段是从mime-type里取的 先随便注册个用户 访问/compose路由上传背景图片 Content-Type改为-1 设置背景图片 再访问superadmin.php拿到flag RootKB 题目是最新版的 https://github.com/1Panel-dev/MaxKB/tree/v2 创建工具处可以在线运行python代码 但有些限制 2.3.1版本tool_code.py多了个LD_PRELOAD

uni-app——uni-app 小程序 之 【按钮失效问题排查(前端+后端)】

一、问题背景 在某业务流程系统中,当业务单据进入特定待处理状态后,用户需要在对应操作页面完成核心操作,点击页面中的两个关键操作按钮(提交类、完结类)以推进流程流转。 然而实际操作时,两个按钮均出现报错提示,无法正常触发流程跳转,业务无法继续推进。 二、问题复现 操作步骤: 1. 登录系统账号(具备对应操作权限) 2. 进入业务单据列表,找到一条处于特定待处理状态的单据 3. 点击进入该单据的操作详情页面 4. 填写页面所需基础信息、上传相关附件 5. 点击页面中的提交类或完结类按钮 6. 结果:按钮点击后报错,流程无法流转到下一节点,操作失败。 三、问题分析 经过多轮排查,发现问题并非单一环节导致,而是涉及前端和后端两层,属于接口调用、参数传递及数据校验的联动异常,具体分析如下: 1. 前端:页面加载时未获取核心业务数据 操作详情页面进入后,未先调用查询接口获取单据关联的核心数据,直接使用空值的关键标识调用操作接口,导致后端无法查询到对应业务记录,接口调用失败。

用 ASCII 草图 + AI 快速生成前端代码

引言 从想法到代码,中间往往要经历画原型、出设计稿等环节。 用 ASCII 草图,可以跳过大量原型绘制、结构拆解和手动搭骨架的中间步骤。 这种表达方式其实一直存在,但真正让它进入工程流程的,是 AI 的能力提升。大语言模型对结构化文本具有很强的解析能力,能够识别文本中的层级、对齐关系与空间划分,并将这些结构信息稳定地映射为组件树和页面布局。 因此,ASCII 不再只是沟通草稿,而成为一种可执行的结构描述。 什么是 “ASCII 草图” 提到 ASCII,很多人的第一反应可能是那个年代久远的“字符画”。没错,ASCII 草图就是用字符来构建页面布局。 在 AI 时代,这种看似简陋的草图,其实蕴含着巨大的能量。大语言模型(LLM)对结构化文本的理解能力极强。相比于模糊的自然语言描述(“我要一个左边宽右边窄的布局”),ASCII 草图提供了一种所见即所得的结构化 Prompt。 简单来说,ASCII 草图充当了视觉蓝图的角色,AI 根据这个结构生成代码。