AI 全栈开发的前端语言：把页面需求说清楚的术语手册

现在借助 AI 写一个页面，可能只需要一句话：“帮我做一个好看的后台管理系统。”模型很快就能生成页面。但“好看”“现代”“简洁”不是可执行的规格：侧边栏是否固定？内容区需要多宽？筛选条件如何提交？表格是否分页？加载中、空数据和请求失败时又显示什么？

这些没说清楚，AI 就只能自行补全。我的核心观点是：前端术语是一套压缩歧义的工程语言。掌握它们不是为了背诵名词，而是为了准确描述界面结构、视觉规则、交互行为、数据流和验收条件。

一、先建立前端的整体地图

用户看到的页面
   ├── 结构：HTML / DOM
   ├── 表现：CSS / Layout / Responsive
   ├── 行为：JavaScript / State / Events
   └── 数据：API / Request / Response
                └── 后端服务与业务规则

• HTML 描述内容的语义结构，例如标题、表单、按钮和表格。
• CSS 决定尺寸、颜色、间距、排布和不同屏幕下的呈现。
• JavaScript / TypeScript 负责交互逻辑、状态变化、数据处理与请求调用。
• API 让前端与后端交换数据；页面不等于业务数据本身。

现代框架通过组件、状态和数据驱动页面更新，但这些底层概念仍然重要。

二、描述页面结构：元素、DOM 与组件

Element、Tag 与 DOM

Tag 是 HTML 源码中的标签；Element 是浏览器解析后形成的元素；DOM 则把文档组织成可查询和操作的树状对象结构。

与其对 AI 说“把右边那个东西调小一点”，不如说：“将用户详情卡片中的主操作按钮高度从 40px 调整为 32px，不改变卡片标题和其他按钮。”

Semantic HTML：语义化标签

<main>、<nav>、<form> 和 <button> 表达不同的内容角色或交互含义。语义正确有助于键盘操作、辅助技术和浏览器默认行为，也让代码更容易被人和 AI 理解。

Component：组件

常见组件包括 Button、Input、Modal/Dialog（模态弹窗）、Drawer（侧边抽屉）、Dropdown/Select（下拉选择）、Tabs（标签页）、Card（卡片）、Table/Data Grid（表格）、Pagination（分页器）和 Toast（轻提示）。

“增加一个确认弹窗”已经比“做一个小窗口”清楚；“复用现有 ConfirmDialog，点击确认后才提交请求，取消不产生副作用”则更接近可实施的任务。组件是代码组织和复用单位，不等于页面上任意一个矩形。

三、描述布局：把“摆得整齐”变成约束

术语	含义	需求表达示例
Container / Wrapper	控制整体宽度的容器	内容区最大宽度 1200px，居中显示
Flexbox	一维布局	标题靠左，操作按钮靠右
CSS Grid	二维行列布局	桌面端三列卡片，间距 24px
Gap	子项之间的间距	卡片之间使用 16px gap
Padding / Margin	内边距 / 外边距	卡片内边距 24px，标题下方留 20px
Overflow	内容溢出时的处理	表格过宽时允许横向滚动
Responsive Design	响应式设计	大屏三列、中屏两列、窄屏单列

简单原则：Flexbox 适合导航栏、按钮组等单方向排列；Grid 适合仪表盘和卡片墙等行列布局。响应式设计也不只是缩小页面，还要明确导航如何折叠、表格如何处理、小屏幕哪些内容可以换行。

四、描述视觉样式：不只是颜色

• Design Tokens：统一管理颜色、字号、间距、圆角和阴影等视觉变量。
• Typography：字体、字号、字重、行高和字距。
• Visual Hierarchy：通过尺寸、位置、颜色和留白表达信息层级。
• Contrast：文字与背景之间的对比度，影响可读性。
• Whitespace：有意保留的空间，不等于浪费空间。

“更高级一点”可以作为审美方向，但不能成为唯一验收标准。更有效的描述是：“页面以中性色为主，主操作使用统一品牌色；标题、正文、辅助信息形成三级字号层次；卡片使用轻边框，不使用大面积投影。”还应要求 AI 复用项目已有的设计令牌，避免每个组件各自定义颜色和间距。

五、描述交互：事件、状态与反馈

• Event：点击、输入、提交、键盘操作等触发行为。
• State：当前选中标签、弹窗开关、页码、请求状态等影响 UI 的数据。
• Loading State：请求进行中。
• Empty State：请求成功但没有数据。
• Error State：请求失败，并提供错误说明或恢复操作。
• Success Feedback：操作成功后的提示或页面更新。
• Disabled State：条件不满足时禁用控件。

一个完整的交互不能只描述成功路径。以保存表单为例，还要明确提交期间是否禁用按钮、失败时是否保留用户输入、字段错误显示在哪里，以及重复点击是否会触发多次请求。

Modal 通常用于需要集中处理的对话框；Drawer 适合详情和编辑面板；Popover 用于锚定元素的轻量操作；Tooltip 只适合简短说明。需求中最好明确选哪一种，而不是让 AI 猜。

六、描述数据流：API、Mock、分页与搜索

前端通常通过 HTTP 请求后端 API。需要明确请求何时发起、参数来自哪里、响应如何映射到界面、失败如何处理，以及筛选和分页发生在前端还是后端。

• Mock Data：后端未就绪时用于验证布局和交互的模拟数据，不应被误认为真实数据。
• Pagination：分页，可能是页码分页或游标分页。
• Sorting：排序，例如按创建时间倒序。
• Filtering：筛选，例如按状态或日期范围过滤。
• Debounce：停止输入一段时间后再执行，适合搜索框。
• Throttle：限制一段时间内的触发频率，适合某些高频事件。

数据量较大时通常应由后端分页和筛选；只对当前页数据做筛选，不等于对全量数据筛选。若接口尚未提供，也应明确是先用 Mock Data，还是同时实现后端 API。

七、路由、权限与表单

Routing 定义 URL 与页面的映射；Navigation 是用户在页面之间移动的方式。可以要求刷新后仍能访问当前路径，或通过 URL 参数还原筛选条件。

Authentication（认证）回答“你是谁”；Authorization（授权）回答“你能做什么”。只在前端隐藏按钮不构成真正的权限保护，敏感操作必须由后端进行权限校验。

Form Validation（表单校验）应明确必填字段、格式、校验时机、错误提示位置和提交中的状态。例如：“邮箱在失焦时校验格式；提交时执行完整校验；错误提示放在字段下方；提交期间禁用按钮；后端字段错误映射到对应输入框。”

八、工程术语：让 AI 在现有项目中正确修改

• Props：父组件传递给子组件的参数。
• State Management：管理跨组件或跨页面共享状态。
• TypeScript Types / Interfaces：描述数据结构与接口约束。
• Component Reuse：复用已有组件，避免重复实现。
• Build：把源码处理成可运行或可部署产物。
• Lint / Format：检查代码规则并统一格式。
• Unit / Integration / E2E Test：分别验证单元、模块协作和完整用户流程。
• Regression：修改后原有功能意外损坏。

给 AI 的任务应包含改动边界：“先检查项目结构、路由和组件库；沿用当前框架和请求封装；只修改用户管理页面及必要的共享组件；不要擅自升级依赖或重构无关模块。”

九、包管理与依赖治理：依赖不是“装上就行”

前端项目会通过包管理器引入组件库、路由、请求客户端、构建工具和测试框架。包管理相关术语影响 AI 是否能安全修改已有项目。

Package Manager、Registry 与依赖树

• Package / Package Manager：软件包 / 包管理器，例如 npm、pnpm、Yarn。
• Registry：包仓库，例如公共 npm registry 或企业私有仓库。
• Transitive Dependency：传递依赖，即当前依赖的依赖。
• package.json：项目元数据、脚本、直接依赖和版本范围。
• Lockfile：锁定完整依赖树的具体解析结果，例如 package-lock.json、pnpm-lock.yaml、yarn.lock。
• SemVer：语义化版本，常见 MAJOR.MINOR.PATCH 分别对应不兼容变化、兼容功能增加和兼容修复；具体仍需看包的发布说明。

^1.2.3 表示一个允许的版本范围，并不保证所有环境安装的版本永远相同；lockfile 用于进一步固定解析结果。AI 修改依赖时，必须同时检查清单和 lockfile，而不是只看 package.json。

dependencies、devDependencies 与 peerDependencies

• dependencies：运行时需要的依赖。
• devDependencies：构建、测试、Lint 等开发阶段使用的依赖。
• peerDependencies：声明由宿主项目提供的兼容依赖，常见于插件和组件库。

安装冲突不应一律用强制参数压掉。先分析版本约束、重复依赖和 peer dependency 冲突，再决定是否升级或替换包。

术语 / 命令	含义	注意点
install	安装依赖	检查是否改变依赖树
frozen / immutable install	严格按 lockfile 安装	适合 CI，避免依赖漂移
add / remove	添加或移除依赖	评估包体积、许可证、维护状态和安全风险
update / upgrade	升级依赖	区分补丁升级和可能破坏兼容性的主版本升级
peer dependency conflict	宿主依赖版本不兼容	先理解冲突，不要直接强制忽略

给 AI 的约束：“先检查项目使用的包管理器和 lockfile；优先复用现有依赖；引入新包前说明原因和替代方案；不要混用 npm、pnpm、Yarn，不要删除 lockfile 来规避冲突；完成后运行项目已有的类型检查、Lint 和测试。”

十、构建与工程化：代码能运行，不等于能上线

页面在本机能打开，只证明局部开发环境里的结果，不代表生产环境可用。全栈交付需要理解从源码到线上服务的完整链路。

Build、Bundle、Transpile 与 Tree Shaking

• Build：编译、处理资源并生成可运行或可部署产物。
• Transpile：把 TypeScript 或较新的语法转换成目标环境能理解的形式。
• Bundle：将模块及依赖组织成一个或多个输出文件。
• Tree Shaking：在静态分析可行时移除未使用的导出代码。
• Code Splitting：拆分代码加载单元，降低初始加载成本。
• Source Map：将转译或压缩后的代码映射回源码，辅助定位生产问题；是否公开需结合安全策略。

构建成功不等于功能正确：接口契约、权限、业务规则和用户路径仍然需要验证。

Environment、Configuration 与 Secret

• Environment：开发、测试、预发布、生产等环境。
• Environment Variable：部署时注入的配置，例如 API Base URL。
• Secret：Token、密码、私钥等敏感信息。

前端构建工具中的环境变量通常会被编译进公开资源。不能把私钥、数据库密码或服务端 Token 放进前端变量并认为它们安全。 浏览器收到的内容应默认可被用户查看。敏感凭据应保存在服务端或安全的 CI/CD Secret 中。

CI/CD、Pipeline 与 Artifact

• CI（持续集成）：自动运行依赖安装、Lint、类型检查、测试和构建。
• CD（持续交付 / 持续部署）：准备发布版本，或自动部署到目标环境；Delivery 与 Deployment 的细分含义因团队而异。
• Pipeline：编排检查、构建、制品保存、部署和健康检查的流水线。
• Artifact：某次构建生成、可追溯并可部署的文件或镜像。
• Release：有明确版本、提交和变更记录的发布。

Commit / Pull Request
  → Install from lockfile
  → Lint + Type Check + Test
  → Build Artifact
  → Preview / Staging
  → Smoke Test / Health Check
  → Production Release
  → Observe Metrics + Errors

Preview、Staging、Production 与 Feature Flag

• Preview Deployment：为分支或 PR 创建预览版本，在合并前验证页面。
• Staging：尽量接近生产的预发布环境。
• Production：真实用户使用的环境。
• Feature Flag：把功能开放与代码部署分离，支持渐进启用。
• Smoke Test：发布后快速验证首页、登录和关键 API 等路径。

平台显示“部署成功”只代表部署动作完成。还应验证页面、静态资源、API 地址、认证和关键操作是否正常。

发布、部署与回滚：从“推上去”到可恢复

这一节的核心术语包括 Rollback、Canary Release、Blue-Green Deployment、Cache Invalidation 与 Database Migration。

Rollback、Canary、Blue-Green 与 Cache Invalidation

• Rollback：恢复到上一个已知可用版本；需要考虑数据库变更兼容性。
• Canary Release：先让少量流量使用新版本，观察指标后逐步扩大。
• Blue-Green Deployment：准备两套环境，验证后切换流量。
• Cache Invalidation：处理 CDN、浏览器或 Service Worker 中的旧资源；内容哈希文件名有助于安全缓存。
• Database Migration：数据库结构或数据迁移，往往比回滚应用代码更复杂。

常见问题包括 HTML 已更新但旧 JavaScript 仍被缓存，以及前端已发布却调用了尚未部署或不兼容的 API。发布方案应考虑前后端兼容窗口，而不是假设所有组件同时更新。

模糊表达	更准确的工程表达
帮我发布一下	明确目标环境、构建命令、部署目标和验收路径
线上打不开	区分网络 / HTTP 状态码、静态资源、运行时异常和 API 错误
页面还是旧的	检查部署版本、CDN / 浏览器缓存、Service Worker 和资源哈希
先上去看看	创建 Preview Deployment，在预览环境执行关键路径验收
出问题就回退	明确回滚版本、触发条件、负责人和数据兼容性

十一、把术语变成可执行的 AI 需求

维度	需要说明什么
目标与用户	谁使用页面，要完成什么任务
页面结构	页面区块、组件层次、导航关系
布局与视觉	宽度、列数、间距、对齐、主题
交互与状态	用户动作、状态变化、加载与错误反馈
数据与接口	字段、请求、响应、Mock 或真实 API
工程约束	技术栈、现有组件、改动范围、权限
验收标准	什么结果可被观察、测试和判定为完成

示例：用户管理页面

目标：管理员可以查找、查看和编辑用户。
结构：左侧导航，右侧主内容区；包含标题、筛选表单和用户表格。
布局：内容最大宽度 1200px；筛选区使用 Flex，字段间距 16px。
表格：姓名、邮箱、状态、创建时间、操作。
交互：按姓名/邮箱搜索，按状态筛选，支持后端分页。
编辑：打开右侧 Drawer；取消不保存，确认后提交。
状态：提交时 Loading 并防止重复提交；处理成功、空结果、失败和字段错误。
工程约束：复用项目已有组件、请求封装和权限机制。
验收：所有操作可实际使用；加载、空数据、错误和成功状态明确；
      窄屏布局可用；通过项目已有 lint、类型检查和相关测试。

这里真正起作用的不是 Prompt 更长，而是把目标、约束、状态和验收分开。AI 更容易据此制定计划，开发者也更容易检查结果。

十二、我的进一步思考：术语是一种“压缩歧义”的接口

人与 AI 的协作也需要接口。自然语言很灵活，但“做一个弹窗”可能对应 Modal、Drawer、Popover，甚至独立页面。术语提供相对稳定的概念边界；示例、尺寸、状态和验收条件进一步限制解释空间。

模糊目标
   ↓ 术语澄清
结构化需求
   ↓ 工程约束
实现计划
   ↓ 代码生成
可运行结果
   ↓ 测试与人工验收
反馈 / 修正

我认为最值得优先掌握的不是所有前端 API，而是三类知识：结构词汇（组件、布局、路由、表单、状态）、行为词汇（事件、校验、加载、错误、权限、请求），以及验证词汇（响应式、可访问性、类型检查、测试、回归）。它们能覆盖大量日常页面开发，也能帮助后端工程师更准确地描述全栈任务。

十三、结语

AI 降低了编写代码的门槛，却没有让需求歧义、系统边界和质量验证自动消失。前端术语不是为了显得专业，而是为了把“我想要什么”转换成“系统应该如何表现，以及怎样证明它做对了”。

好的 AI 开发沟通，不是把一句话写得更华丽，而是让每个关键要求都能被实现、观察和验证。

参考

• 参考文章：CSDN · Dontla
• MDN Web Docs
• React 文档
• Vue 文档