Terminal
终端
用文字命令告诉电脑进入哪里、启动什么或停止什么。
什么时候用：运行 Agent 给出的命令前，先确认目录、作用和停止方式。
39 TERMS · 6 GROUPS
Reference 02 · Concept Glossary
先用白话理解，再把术语放回项目
术语卡不是需要背诵的定义。遇到问题时搜索一个词，看看它对应页面、文件还是工作流程，然后复制一条自然说法交给 Agent。
工作台
6 个Package Manager
npm
读取项目清单，安装依赖并执行项目已经写好的脚本。
什么时候用：先看 package.json，再运行 install、dev 或 build。
Dev Server
开发服务器
把本地项目临时变成一个浏览器可以访问的网址。
什么时候用：它只服务当前电脑上的开发，不等于作品已经公开上线。
DevTools
浏览器开发工具
查看页面结构、样式、报错、请求和性能证据的检查台。
什么时候用：不要只相信 Agent 的总结，要在真实页面里验证。
package.json
项目清单
记录项目名称、依赖和可以执行的脚本。
什么时候用：安装或启动以前先读它，避免混用包管理器和猜命令。
Hot Reload
热更新
保存文件后，让浏览器尽量只更新发生变化的部分。
什么时候用：页面没有变化时，先确认文件、路由和开发服务器属于同一个项目。
项目地图
7 个Frontend
前端
用户在浏览器里看见和操作的页面。
什么时候用：文字、布局、按钮和交互反馈通常先从这里检查。
Backend
后端
接收请求、处理规则并读写数据的服务端部分。
什么时候用：密码、权限和真正的密钥不能只交给页面判断。
Component
组件
把一块会重复或会变化的界面整理成可以单独维护的部分。
什么时候用：先找到负责当前画面的组件，再决定修改范围。
State
状态
页面此刻正在加载、成功、失败、展开或关闭等变化。
什么时候用：很多“偶尔不对”的问题都来自遗漏状态，样式往往只是表面现象。
Route
路由
把一个网址路径对应到具体页面和参数。
什么时候用：页面打不开或改错入口时，先核对当前 URL 与页面文件的映射。
API
接口
让页面与服务端或第三方能力交换请求和结果的约定。
什么时候用：UI 原型优先使用 Mock；连接真实接口前要确认数据、失败与权限边界。
Props
组件参数
父组件交给子组件的内容和配置。
什么时候用：同一组件需要显示不同内容时，先看哪些差异应该成为 Props。
界面与状态
6 个Button
按钮
触发保存、提交、打开或删除等当前页面动作的控件。
什么时候用：如果点击后只是前往另一个网址，通常应该用 Link。
Link
链接
把用户带到另一个页面、位置或外部地址。
什么时候用：链接应该能被复制、在新标签打开，并向辅助技术说明目的地。
Input
输入框
接收短文本、邮箱、数字或搜索关键词。
什么时候用：需要同时说明标签、格式、错误和禁用状态，不要只依赖 placeholder。
Dialog
对话框
在当前页面上方暂时打开一项需要集中处理的任务。
什么时候用：打开后要管理焦点、Escape 和关闭后的返回位置。
Dropdown / Popover
下拉浮层
从一个触发器附近展开短列表、选择项或补充内容。
什么时候用：需要检查键盘操作、碰撞避让和屏幕四周的安全边距。
Empty State
空状态
没有数据、搜索无结果或用户还没开始时的页面状态。
什么时候用：它要解释发生了什么，并提供合理的下一步，而不是留下空白。
布局与视觉
6 个Responsive Design
响应式
根据屏幕与输入方式重新安排内容，而不只是缩小桌面页面。
什么时候用：手机上要重新检查阅读顺序、触控目标、浮层与主要任务。
Breakpoint
断点
当可用空间不足时，界面开始改变结构的宽度条件。
什么时候用：断点应该由内容何时挤坏决定，不必机械追随某个设备型号。
Flexbox
弹性布局
沿一个主要方向排列、对齐和分配空间的 CSS 布局方式。
什么时候用：导航、工具栏和一排操作通常适合 Flex；二维结构再考虑 Grid。
CSS Grid
网格布局
同时控制行和列的二维布局方式。
什么时候用：并列卡片、仪表盘和明确矩阵适合 Grid，普通文章不需要为了整齐强行分栏。
Design Token
设计 Token
为颜色、字号、间距和圆角提供有语义的统一名称。
什么时候用：让 Agent 使用现有 Token，比在每个页面重复写裸数值更可控。
z-index
层叠顺序
决定同一层叠上下文中的元素谁显示在上面。
什么时候用：浮层被遮挡时先检查 stacking context，不要无限增加数字。
Agent 协作
7 个Task Instruction
Prompt
你交给 AI 的任务、背景、限制和完成标准。
什么时候用：它需要提供可检查的信息，信息越清楚，结果越容易验收。
Context
上下文
Agent 当前能看到的项目规则、文件、对话和证据。
什么时候用：不要只补更多文字，要补当前判断真正缺少的信息。
Acceptance Criteria
验收标准
完成后可以逐项观察、操作或测量的结果。
什么时候用：把“更高级”改成具体的尺寸、状态、设备和行为。
Diff
差异
逐行显示 AI 删了什么、加了什么和改了哪些文件。
什么时候用：接受修改前先看 Diff，排除误删、调试代码和密钥。
Scope
任务范围
这一轮明确要处理和不处理的页面、行为与文件。
什么时候用：范围写清楚以后，Agent 才不会把一次小改动扩展成重构。
Implementation Plan
实现计划
把目标拆成可以逐步实现、验证和撤回的动作。
什么时候用：计划要对应真实文件与证据，不是复述需求的漂亮清单。
Guardrail
护栏
限制 Agent 能做什么、何时停止和哪些动作需要人工确认。
什么时候用：密钥、生产数据、付款和不可逆操作需要更明确的护栏。
保存与发布
7 个Version Control
Git
在本地记录项目版本，让改动可以比较和恢复。
什么时候用：GitHub 是托管副本的平台，不等于 Git 本身。
Commit
提交
把一组已经检查过、服务同一目的的改动保存成版本。
什么时候用：Commit 默认在本机；Push 后远程仓库才会收到。
Environment Variable
环境变量
让本地、测试和线上环境读取不同配置的方式。
什么时候用：前端公开变量会进入浏览器，真正密钥只能留在服务端。
Deployment
部署
把检查过的项目构建并放到别人可以访问的线上环境。
什么时候用：本地能运行不代表线上成立，发布后还要重新验收。
Branch
分支
从一个已知版本分出独立修改路线，不影响主线继续工作。
什么时候用：一轮任务放在独立分支里，更容易 Review、撤回和合并。
Pull Request
合并请求
把分支改动、说明和验收证据交给团队 Review 的入口。
什么时候用：PR 不是结果截图，要说明范围、风险、测试和仍需人工确认的部分。
Production
生产环境
真实用户访问、使用真实配置和数据的线上环境。
什么时候用：本地通过不等于生产通过，上线后需要重新走主要路径。
信息架构参考了VibeHub的领域与子主题组织方式。GoodVibe 的中文解释、使用场景和可复制说法均按本课程工作流重新编写。