AI 与医疗旅游就算把编程交给 AI，也值得了解的开发术语
要点
- 没有必要背下所有开发术语。不过，只要了解其中几个，就更容易判断 AI 正在做什么、已经完成到哪一步、下一步该确认什么。
- 从把任务交给 AI 的那一刻起，到真正应用到线上服务为止，我按流程整理了经常出现的术语。
- 创建了 PR 并不代表已经合并，提交了也不代表已经推送到远程仓库。
- 稍微了解一些术语后，向 AI 提出请求的句子也会变得具体起来。
借助 AI 智能体进行氛围编程（vibe coding）时，常常会遇到一些陌生的词汇。
“我创建了一个分支（branch）。”
“我来提交（commit）并推送（push）。”
“构建（build）通过了，但 E2E 测试失败了。”
明明只是让它写代码，可要看懂结果，却好像还得再学一门语言。
没有必要背下所有开发术语。不过，只要了解其中几个，就更容易判断 AI 正在做什么、已经完成到哪一步、下一步该确认什么。
从把任务交给 AI 的那一刻起，到真正应用到线上服务为止，我按流程整理了经常出现的术语。
向 AI 说明工作时使用的词
| 术语 | 通俗解释 | 使用示例 |
|---|---|---|
| 提示词 · Prompt | 向 AI 传达的请求或指令。 | “做一个注册页面，如果输入有误，就显示提示文字。” |
| 规格说明 · Specification, Spec | 具体写明需要实现的功能和条件。 | “邮箱为必填项；如果该地址已经注册，就提示用户该邮箱已注册。” |
| 上下文 · Context | AI 判断如何开展工作时参考的信息。包括对话、代码、文档、工具运行结果等。 | 先让它读取现有的设计和登录方式。 |
| 词元 · Token | AI 处理文字和代码的单位。它与字数或词数并不完全相同。 | 传入大量长文档和代码，处理的词元也会随之增加。 |
| 上下文窗口 · Context Window | AI 在一次处理中能够处理的信息量上限。 | 在较长的任务中，把重要决定和当前状态单独整理出来，再交给它。 |
| 智能体 · Agent | 根据目标决定下一步行动，并使用工具推进工作的 AI 系统。 | 读取并修改文件，再根据测试结果继续修正。 |
尤其要把上下文和永久记忆区分开来理解。对话变长后，视工具不同，之前的内容可能会被概括，或有一部分被舍弃。让 AI 接着做之前的工作时，最好简短整理一下当前目标、已确定的条件以及尚未解决的问题。
描述所开发服务结构的词
比如，设想这样一个功能：出现一个申请页面，用户填写内容，提交的信息被保存下来。页面和保存处理相互关联，但分工不同。
| 术语 | 通俗解释 | 使用示例 |
|---|---|---|
| 前端 · Frontend | 负责用户看到的页面以及在页面上发生的交互。 | 制作按钮、输入框、菜单和错误提示。 |
| 后端 · Backend | 在服务器端负责数据处理和服务规则等。 | 检查并保存提交的内容，或校验访问权限。 |
| API | 程序按照约定方式使用其他程序的功能或数据的接口。 | 从页面把申请内容传给服务器。 |
| 数据库 · Database, DB | 有条理地存储和查询数据的系统。 | 存储会员、商品和申请记录。 |
| 模式 · Schema | 规定数据的字段、格式、关系等的结构。 | 决定在申请记录中设置申请编号、日期和处理状态。 |
| 组件 · Component | 构成页面或功能、可以复用的部件。 | 在多个页面使用同一个申请按钮。 |
| 库 · Library | 预先做好、可以直接拿来使用、实现所需功能的代码集合。 | 直接调用日期计算或图表显示功能。 |
| 框架 · Framework | 为开发应用程序提供一套基本结构和工作方式的骨架。 | 按照既定结构编写页面和服务器功能。 |
| 依赖项 · Dependency | 项目运行或开发所需要的其他代码或工具。 | 需要所用库的特定版本。 |
了解这种区分，就能理解“页面已经做好了，但保存用的 API 还没有接上”这样的说明。也就是把“页面能显示”和“信息真正被保存”分开来确认。
记录和合并变更的词
| 术语 | 通俗解释 |
|---|---|
| Git | 记录和管理代码变更历史的工具。 |
| GitHub | 在线托管 Git 仓库，并支持变更审查与协作的服务。 |
| 仓库 · Repository, Repo | 管理项目文件和变更历史的空间。 |
| 分支 · Branch | 从现有历史中分出来、单独继续进行变更的工作线。 |
| 工作树 · Worktree | 让你可以在同一个仓库中，在不同的文件夹里处理不同分支的 Git 功能。 |
| 差异 · Diff | 显示变更前后新增、修改、删除的内容差异。 |
| 提交 · Commit | 把选定的变更记录为 Git 历史中的一个节点。它与保存文件是两回事。 |
| 推送 · Push | 把本地仓库的提交等内容同步到远程仓库的操作。 |
| 拉取 · Pull | 从远程仓库获取变更，并整合到当前分支的操作。 |
| 拉取请求 · Pull Request, PR | 请求审查变更内容并将其合并。 |
| 合并 · Merge | 把不同的开发历史合并到一起的操作。 |
| 冲突 · Conflict | 变更无法自动合并、需要判断保留哪些内容的状态。 |
这里只要记住：保存文件 → 提交 → 推送 → PR → 合并，这些都是不同的动作。创建了 PR 并不代表已经合并，提交了也不代表已经推送到远程仓库。 同时把工作交给多个 AI 时，可能会遇到“工作树”（worktree）这个概念。它有助于让每项工作在单独的文件夹中进行，但之后合并和审查变更的过程依然不可或缺。
代码在哪里、以什么设置运行
| 术语 | 通俗解释 | 值得了解 |
|---|---|---|
| IDE | 帮助编辑代码、运行程序、查看错误等的集成开发环境。 | 可以把它理解为做开发工作的工作室。 |
| 终端 · Terminal / CLI | 终端是用文字输入命令的窗口，CLI 是通过命令操作程序的方式。 | AI 执行安装、运行、检查等命令时经常出现。 |
| 本地 · Local / localhost | 本地是指当前工作所用电脑的环境。localhost 指发起访问的这台电脑本身。 | 把自己电脑上的 localhost 地址发给别人，对方也打不开同样的页面。 |
| 开发环境 · Development | 开发、修改和检查功能的环境。 | 开发环境也可能连接到外部数据或服务。 |
| 预发布环境 · Staging | 在上线到生产环境之前，为最终检查而准备的环境。 | 与 Git 中挑选待提交变更的“暂存”（staging）不是一个意思。 |
| 生产环境 · Production | 真实用户使用的线上运行环境。 | 这里的变更可能会影响真实用户。 |
| 环境变量 · Environment Variable | 由运行环境传给程序的配置值。 | 按环境分别指定服务器地址或功能设置等。 |
| API 密钥 · API Key | 视服务而定，用于识别调用方或验证 API 访问权限的值。 | 需要保密的密钥不能写进公开代码，也不能写进会发送到浏览器的代码里。 |
“在本地运行正常”这句话说明的是已确认的环境范围。在真实服务中是否也能运行，需要连同生产环境的设置和连接状态一起确认。仅仅放进环境变量，也并不意味着机密值就安全了。
发现问题、确认是否正常运行的词
| 术语 | 通俗解释 | 使用示例 |
|---|---|---|
| 缺陷 · Bug | 使程序无法按预期运行的错误。 | 连按两次提交按钮，申请就被重复保存。 |
| 调试 · Debugging | 重现问题、找出原因并修复的过程。 | 确认重复保存是页面造成的，还是服务器处理造成的。 |
| 日志 · Log | 程序留下的运行记录。 | 查看请求是什么时候进来的、在哪里失败的。 |
| 单元测试 · Unit Test | 单独测试小的功能单元。 | 确认折扣金额计算是否正确。 |
| 集成测试 · Integration Test | 测试多个部分连接在一起时的行为。 | 确认申请处理和数据保存能否协同工作。 |
| 端到端（E2E）测试 · End-to-End Test | 从头到尾测试用户的操作流程。 | 登录、提交申请表，一直走到完成页面。 |
| 代码检查 · Lint | 在运行代码之前，检查是否违反既定规则或存在可疑模式等。 | 找出未使用的变量或容易出错的写法。 |
| 类型检查 · Type Check | 检查数据类型及其使用方式是否匹配。 | 确认是否在需要数字的地方传入了字符串。 |
| 回归测试 · Regression Test | 修改后确认已有功能没有被破坏。 | 修改注册功能后，也重新检查原有的登录。 |
| 重构 · Refactoring | 在保持外部可观察行为不变的前提下，改进代码内部结构的工作。 | 把重复的代码归并到一处，使其更易修改。 |
收到“测试通过”的报告时，最好也看看测试了什么、在什么条件下测试的。检查计算功能的测试，和在真实浏览器中完成申请的测试，确认的范围并不相同。如果测试中用了模拟响应，那可能并没有验证到与真实外部服务的连接。 代码检查和类型检查虽然有用，但并不能保证用户想要的功能已经完成。完全可以写出一个遵守代码规则、却把申请结果显示错的程序。
把完成的代码发布到服务时使用的词
| 术语 | 通俗解释 | 值得了解 |
|---|---|---|
| 构建 · Build | 把源代码准备成可运行或可部署形式的过程。 | 构建成功与功能实际正常运行，要分开确认。 |
| 部署 · Deploy | 把准备好的程序发布到运行环境中的操作。 | 既可以部署到测试环境，也可以部署到真实的生产环境。 |
| 托管 · Hosting | 提供运行环境，让网站或服务能够运行并被访问。 | 存放代码的仓库与服务运行的环境，作用不同。 |
| 持续集成（CI） · Continuous Integration | 频繁集成代码变更，同时自动执行构建、测试等检查的开发方式。 | 配置成在共享变更时自动运行检查。 |
| 持续交付 / 持续部署（CD） · Continuous Delivery / Deployment | 指让变更始终保持可部署状态，或自动部署通过检查的变更的方式。 | 确认这里的 CD 指哪种含义，以及实际部署这一步是否也会自动执行。 |
| 回滚 · Rollback | 出现问题时恢复到之前版本或状态的操作。 | 即使回退了代码版本，已经改动的数据也不会自动恢复。 |
有些项目设置成在推送或合并后自动部署。因此，听到“我来推送”这样的说明时，最好也弄清楚这一步是否连着部署。
MCP
连接 AI 工具时，还会遇到“MCP”这个词。MCP 是 AI 应用程序连接外部数据和工具时使用的开放标准。根据所连接工具的功能和权限，AI 应用程序可以读取资料或执行操作。
提问会变得不一样
稍微了解一些术语后，向 AI 提出请求的句子也会变得具体起来。
可以不再问“好了吗？”，而是这样问。
“请把修改代码、测试、提交、推送、部署分开，告诉我你完成到了哪一步。也请一并说明哪些功能实际确认过，哪些部分还没能确认。”
修改之前，可以先确认工作范围。
“先说明这次请求会改动哪些页面和功能。也请整理一下对现有功能的影响，以及确认是否完成的方法。”
审查结果时，可以把精力放在理解变更内容上。
“请根据差异（diff），用通俗的话说明改了什么、为什么改。也告诉我出问题时怎么回退。”
学习开发术语最实用的时机，就是提出这类问题的时候。你就能从 AI 的工作说明中了解当前状态，并判断下一步该做什么。
