哈喽，大家好，我是南鸢，今天我们不讲生图，来讲 Vibe Coding。
相信大家很多人都不是什么计算机专业的，没有学过写代码和网页设计。所以自己想要搞出来一个网站的时候，头上的头发都要拔干净了，也想不出来怎么样精确表达一个词、一个效果。
所以我为大家这一期直接整理了 12 个前端的网页基础术语。
保证你看过之后能力就像坐火箭一样提升，然后和 AI 对话手拿把掐～
担心再次找不到，可以复制链接直接收录到自己的知识库，下次就不用到处翻找啦。
那么废话不多说，我们就来直接进入正题吧！
01｜Frontend 前端：用户真正接触到的那一层
Frontend，就是前端。
简单点解释就是：指的是用户在网页、小程序或软件里能够直接看到、点击和输入的那一层。
比如一个登录页面里的标题、输入框、登录按钮、加载提示、成功信息和报错信息，都属于前端。它是给用户看的那一层东西。
但前端显示「登录成功」，不代表账号一定通过了验证。密码是否正确、用户有没有权限、数据有没有保存，这些通常还要看后端返回的真实结果。
所以如果你在和 Agent 交流时它说「前端已经完成」时，你可以继续追问一句：页面只是显示出来了，还是点击、提交、成功和失败状态都已经验证过了？
💡 架构图解：图中浏览器内的内容展示、输入点击、过程反馈和结果状态，都属于前端。右侧后端负责验证、权限和保存，两边通过请求与返回结果连接。
你可以直接复制给 Agent 的一句指令：
检查这个登录页面的前端流程：输入、点击、加载、成功和失败状态都要真实可见，不要只确认页面已经显示。
02｜HTML：网页上有什么，以及它们是什么
HTML 负责网页的内容结构和语义。
它就是 AI 写出来的网页里面 < > 里面的一大堆英文。
然后网页会把里面一大堆的英文渲染出来，它是一种固定的语言格式，专门供浏览器渲染用的。
标题、段落、图片、链接、表单、按钮和输入框，都会通过 HTML 告诉浏览器：页面里有什么，它们之间是什么关系。
例如文章标题应该使用标题元素，跳转到另一个页面应该使用链接，执行提交动作应该使用按钮。它们可能都能通过样式做成相似的样子，但在键盘操作、无障碍阅读、搜索识别和默认行为上并不一样。
HTML 只描述内容的结构和含义，不决定颜色、间距等视觉样式，也不负责点击后的业务逻辑。 视觉样式和复杂交互通常交给 CSS 和 JavaScript。
所以页面少了一段内容、标题层级错误、按钮被放进了错误区域，应该先检查 HTML，而不是只改 CSS。
你可以和 Agent 这样交流：
检查这篇文章的 HTML 结构：页面主标题是否使用正确的标题元素，查看原文使用真实链接，提交操作使用按钮，并保留现有视觉样式。
03｜CSS：网页最后长什么样
CSS 负责网页的外观、布局，以及页面在不同屏幕宽度下怎么响应式变化。
颜色、字体、字号、间距、圆角、阴影、对齐方式、桌面端三列和手机端一列，通常都由 CSS 控制。
一个按钮在 HTML 里已经存在，也能正常点击，但它仍然可能是灰色的，或者在手机上超出屏幕。这时问题多半不是按钮缺失，而是某条 CSS 规则覆盖了原来的颜色或尺寸。
CSS 里的「C」代表层叠（Cascading）。同一个元素可能同时匹配多条样式规则，浏览器会根据匹配范围、优先级和先后顺序计算最终结果。
💡 架构图解：左侧 HTML 用标签确定标题、正文和按钮；右侧 CSS 在保留这些内容的前提下，改变颜色、间距和视觉层级。
所以看到样式不对，不要让 Agent 顺手重写点击逻辑。先让它找出是哪条规则生效、哪条规则被覆盖。
你可以直接复制给 Agent：
这个主按钮可以点击，但颜色仍然是灰色。请检查它匹配到的 CSS 规则和最终计算样式，找到覆盖主题色的声明，不要改 HTML 结构和点击行为。
04｜Markdown：用简单符号写出结构化文本
Markdown 现在估计是我们最熟悉的一种语言了，它是一种轻量标记语言，是一段结构化的纯文本格式。
你在 AI 对话、README 或知识库里看到的 #、-、** 和三个反引号，很多时候就是 Markdown 语法。
它用很少的符号表示标题、列表、粗体、链接和代码块。原文件仍然是纯文本，经过支持 Markdown 的工具渲染后，才会变成有层级和样式的内容。
同一段文字贴进不同工具，显示效果可能不一样。有的编辑器支持表格、任务清单和脚注，有的只认识最基础的标题和列表，还有的不会渲染，直接把符号显示出来。
Markdown 适合写文档和保存可维护的文字结构，遇到网页的精确视觉设计的时候，还是优先考虑 HTML、CSS 和 JavaScript。
💡 架构图解：左侧的
#、-、**和反引号仍是纯文本符号；经过渲染后，才会变成右侧有标题、列表、重点和代码块的阅读页面。
你可以直接复制给 Agent：
把这份说明整理成 Markdown：标题表达层级，步骤使用列表，命令放进代码块。完成后检查渲染效果和所有代码块是否正确闭合。
05｜Component 组件：可以重复使用的界面单元
Component，就是组件。
它把一块界面以及这块界面负责的行为放在一起，方便在不同页面重复使用。改一个地方就能够让其它地方同步更新。
例如首页、搜索页和收藏页都要显示商品卡片。每张卡片都有图片、商品名、价格和收藏按钮，这一整块就适合做成一个商品卡片组件。
以后要把价格格式从「899 元」改成「¥899」，只改这一个组件，使用它的页面就能一起更新。
但组件不等于整个页面，也不是页面上每个小文字都必须单独拆一个组件。是否要拆，关键看这块内容有没有独立职责、会不会重复出现、以后是否需要一起维护。
💡 架构图解：图中只有一个组件母版，却生成了三张结构一致的商品卡片。以后修改按钮样式或价格格式，应该回到母版修改，而不是分别改三个页面。
你可以直接复制给 Agent：
首页、搜索页和收藏页使用的是同一种商品卡片。请把它整理成一个可复用的 Component，同时保留每个页面传入不同商品数据的能力。
06｜State 状态：界面此刻需要记住的状态
State，就是状态。
它是界面当前需要记住、并且会随着用户动作或请求结果发生变化的信息。
一个提交按钮最开始可以点击，这是默认状态；点击后显示「正在保存」，这是加载状态；请求成功后显示「已保存」，失败后显示错误和重试入口，这些都是不同的 State。
弹窗现在是打开还是关闭、购物车里有几件商品、当前选中了哪个筛选条件，也都属于状态。
状态不等于组件，更不等于数据库。 页面上的 State 变成「保存成功」，不代表服务器真的保存了数据。刷新以后内容消失，往往说明页面只改了临时状态，没有完成真实持久化。
💡 架构图解：同一个提交控件可以依次处于默认、保存中、成功和失败状态。状态变化应该跟着真实操作结果走，不能刚点击就提前显示成功。
你可以这样和 Agent 说：
检查保存流程的 State：点击后先进入正在保存，成功后再显示已保存，失败时显示错误和重试入口，并阻止用户重复提交。
07｜DOM：浏览器此刻正在使用的页面树
DOM 的全称是 Document Object Model，中文常叫文档对象模型。
浏览器读取 HTML 后，会把标题、段落、按钮和列表等内容组织成一棵可以被程序读取和修改的节点树，这棵树就是 DOM。
它和最初写在文件里的 HTML 不一定完全相同。
比如源文件里只有一条任务。用户点击「添加」以后，JavaScript 可以向 DOM 插入第二条任务，于是页面上出现了新内容，但你在原始 HTML 里找不到它。
DOM 的变化只说明当前页面发生了变化。刷新之后还能不能看到，取决于数据有没有保存到浏览器存储（LocalStorage / IndexedDB）或后端数据库。
💡 架构图解：左侧是最初的 HTML，右侧是浏览器正在使用的 DOM。橙色 LI 是 JavaScript 在运行时新增的节点；它可以立刻出现在页面里，但刷新后是否还在，要看数据有没有另外保存。
可以和 Agent 交流的一个示例：
点击添加后页面出现了新任务，但源 HTML 里没有。请检查运行时 DOM 新增了什么节点，并继续确认数据是否真的保存，刷新后是否仍然存在。
08｜Title Tag：浏览器标签页里的页面标题
Title Tag 是写在 HTML 文档头部（<head>）的页面标题。
它最直接的作用，是让浏览器标签页显示当前页面叫什么。搜索系统也可能参考它生成搜索结果标题，但不保证完全照搬。
Title Tag 和页面正文里的大标题 H1 不是同一个东西。
一篇商品详情页的 H1 可以只写「按摩座椅」，而 Title Tag 可以写成「按摩座椅｜西昊300」，帮助用户在多个标签页里分清页面和网站。
如果所有商品页的标签都只显示「商品详情」，即使页面里的 H1 不同，用户切换标签页时仍然很难判断自己打开的是哪一个商品。
💡 架构图解：浏览器顶部的标签页文字来自 Title Tag，正文里的「按摩座椅」来自 H1。它们可以相关，但位于不同位置，需要分别设置和验证。
你可以直接复制给 Agent：
给每个商品详情页设置独立的 Title Tag，包含对应商品名，同时保留页面里的 H1。切换两个商品页，确认浏览器标签标题会跟着变化。
09｜Page Metadata：写给页面外部读取者的信息
Page Metadata，就是页面元数据。
它通常放在 HTML 文档头部，不直接显示在正文里，却会被浏览器、搜索系统、分享平台或安装入口分别读取。
浏览器标签页读取页面标题，搜索结果可能参考页面描述，社交平台读取分享卡片信息，可安装网页还会读取 Manifest。
这些都属于 Page Metadata 的范围，但它不是一个「元数据已完成」的总开关。
标签页正常，不代表分享卡片一定有图；分享卡片正常，也不代表网站安装后的名称和启动路径正确。 检查时要先问清楚：这条信息究竟是给谁读取的？
💡 架构图解：同一个网页会向不同位置提供不同信息：Favicon 进入浏览器标签页，Open Graph 生成分享卡片，Manifest 决定安装后的图标和启动方式。它们都属于 Page Metadata，但不能用一份配置互相代替。
你可以直接复制给 Agent：
分别检查这个页面提供给浏览器标签、搜索摘要、链接分享和安装入口的 Page Metadata。列出每个读取方使用的字段，并验证各自的真实结果。
10｜Favicon：标签页和书签里的小网站图标
Favicon 是浏览器用来识别网站的小图标。
它会出现在标签页、书签和浏览历史等浏览器界面里。用户同时打开很多页面时，往往会先通过这个小图标找到网站。
Favicon、网页头部的 Logo 和按钮旁边的功能 Icon，不是同一个东西。
它们可以使用同一套品牌视觉，但修改网页里的 Logo，并不会自动替换浏览器标签页里的 Favicon。
Favicon 更新后仍显示旧图，也不一定是代码没有生效，浏览器缓存可能还保留着旧资源。需要同时检查图标文件、页面引用和真实浏览器结果。
你可以直接复制给 Agent：
替换网站的 Favicon，但不要改网页头部 Logo 和功能图标。检查页面引用的图标资源，并在标签页、书签和浏览历史里验证；如果仍是旧图，请说明缓存证据。
11｜Open Graph：链接分享出去时的预览卡片
Open Graph，常简称为 OG，是一组用来描述链接分享预览的元数据。
当你把文章链接发到聊天工具或社交平台时，对方看到的标题、描述、封面图和网址，通常会参考 og:title、og:description、og:image 和 og:url。
网页正文里已经有一张封面图，不代表分享平台一定能拿到它。
Open Graph 的图片需要使用外部平台能够访问的绝对公网地址。 只存在于本机、需要登录或者使用相对路径的图片，都可能导致分享卡片没有封面。
平台还可能缓存以前抓取的结果。因此改完代码，只看网页源信息还不够，还要用真实分享预览重新验证。
你可以直接复制给 Agent：
为这篇文章补齐 Open Graph 的标题、描述、绝对图片地址和规范网址。不要把正文封面正常显示当成完成，请用真实的外部分享预览验证结果。
12｜Web App Manifest：网页安装后的身份和启动方式
Web App Manifest 通常是一个 JSON 文件，用来描述网页应用安装后的名称、图标和启动方式。
其中常见的信息包括 name、icons、start_url 和 display。浏览器可以读取这些字段，生成安装入口，并决定安装后显示什么名称、使用什么图标、从哪个地址启动，以及以网页标签还是独立窗口打开。
Manifest 里的图标也不等于 Favicon。Favicon 主要服务浏览器标签页和书签，Manifest 图标主要服务安装后的应用入口。它们可以长得一样，但由不同配置负责。
有 Manifest 也不等于网站已经是一套完整的 PWA，更不代表离线时一定能用。 离线缓存还需要 Service Worker 等其他运行机制。
你可以直接复制给 Agent：
检查页面引用的 Web App Manifest，确认 name、icons、start_url 和 display。修改后删除旧安装并重新安装，再验证名称、图标、启动地址和窗口模式，不要把可安装等同于支持离线。
这 12 个词，学到这里就够了
现在再看到 Agent 的回复，你至少可以先判断它在谈哪一层：
- 在谈整个用户界面：Frontend
- 在谈网页的内容结构：HTML
- 在谈网页的样式与布局：CSS
- 在谈带有标题、列表和代码块的纯文本：Markdown
- 在谈重复使用的一块界面：Component
- 在谈界面当前记住了什么：State
- 在谈浏览器运行时的页面节点：DOM
- 在谈标签页标题：Title Tag
- 在谈给浏览器、搜索、分享和安装入口读取的信息：Page Metadata
- 在谈标签页和书签的小图标：Favicon
- 在谈链接分享卡片：Open Graph
- 在谈网页安装后的名称、图标和启动方式：Web App Manifest
不用一次把定义全背下来。
下一次 Agent 抛出一个陌生词，先问自己两个问题：
- 它负责哪里？
- 我应该看到什么结果？
只要能把这两个问题说清楚，你和 Agent 的沟通就已经从「帮我看看哪里不对」，变成了可以定位、可以验证的明确需求！