刚开始 AI 编程，先听懂这些开发术语

不是背编程词典，而是沿一次真实开发流程，讲懂 Bug、测试、重构、API、Git、缓存、构建和部署等最常遇到的术语。

刚开始接触编程，真正让人难受的往往不是代码，而是讨论里突然冒出来的一串词：

“这个 Bug 能稳定复现吗？”“先补个单测，跑一下回归。”“这里耦合太高，先别重写，做个小重构。”“本地没问题，可能是生产环境依赖不一样。”“先 commit，别急着 push。”

每个字都认识，连在一起却像另一门语言。

这篇文章不打算做一份“术语大全”。只保留 AI 编程、RPA、数据处理和日常开发里真正高频的词，并把它们放回实际场景里。目标只有一个：以后看 AI 的解释、同事的代码评审和项目报错时，至少知道大家正在讨论哪一层问题。

先从最常见的一句话开始：这是 Bug，还是异常？

很多新手会把“程序报错”统称为 Bug。实际开发里，这两个词不是一回事。

复现先证明问题到底怎样发生

复现（Reproduce），就是按照明确步骤重新触发同一个问题。

场景：有人说“导出 Excel 偶尔失败”，开发者通常不会立刻改代码，而会先问：用了哪个店铺、什么日期范围、点了哪个按钮、失败时页面是什么状态。能把这些条件重新走一遍并再次失败，才叫“复现出来了”。

复现很重要，因为它把一句“好像有问题”，变成一个可以验证的输入和结果。

偶现不是每次都坏，才最难查

偶现指问题不是每次都出现，相同操作有时成功、有时失败。

场景：RPA 连续跑 20 次，19 次正常，1 次因为网页加载慢而找不到按钮。它不是“无法复现”，而是需要找到触发它的时机、网络、数据或页面状态。

边界条件专门看最容易被忽略的极端情况

**边界条件（Edge Case）**不是单纯指“大数、小数”，而是正常规则走到边缘时的情况。

场景：订单数量为 0、退款率刚好 100%、API 返回空列表、Excel 只有表头没有数据、文件名里有中文和空格。这些输入平时不多，但特别容易暴露程序假设。

日志程序给自己留下的运行记录

**日志（Log）**可以理解为程序运行时留下的“时间线”。

场景：自动化凌晨失败，人不在现场。第二天通过日志看到“02:13 打开订单页 → 02:14 请求超时 → 重试 3 次 → 02:16 任务退出”，排查就不必靠猜。

日志不是越多越好。真正有用的是能回答：执行到哪一步、输入是什么、发生了什么、为什么停下。

测试不是一个动作，而是从小到大检查不同范围

“跑一下测试”听起来像一件事，实际可能是在测试一个函数，也可能是在模拟用户从登录一路点到提交。

冒烟测试先确认系统没“整体趴下”

**冒烟测试（Smoke Test）**不是追求全面，而是先跑最关键的几条主流程。

场景：刚部署一个新版本，不急着把全部测试跑一遍，先打开首页、登录、创建一条任务、保存成功。如果这几步都挂了，就没必要继续测细节。

回归测试这次修好了，别把旧功能改坏

**回归测试（Regression Test）**关注的是：代码变化之后，原来正常的功能是否仍然正常。

场景：你修复了“退款金额计算错误”，除了验证退款计算本身，还要确认没有顺手破坏销售额、采购成本和看板汇总。

AI 说“重构一下”时，它到底想改什么？

这一组词最容易让 AI 编程新手误判“代码是不是写得不高级”。很多时候，简单代码反而更好。

重构 vs 重写一个尽量保留，一个重新做

技术债今天省下来的时间，未来可能要还

**技术债（Technical Debt）**是为了更快交付而接受的代码或设计负担。

场景：临时把店铺名称写死，今天 10 分钟就能上线；一个月后增加第二个店铺时，到处都要找这个名称改。这个“以后要处理的成本”就是技术债。

技术债不等于“烂代码”。有时为了先验证业务，主动欠一点债是合理选择，关键是知道自己欠了什么。

硬编码把本来会变化的东西直接写死

**硬编码（Hardcoding）**是把应该来自配置、输入或数据源的值，直接固定在代码里。

shop_name = "航世京东自营旗舰店"

如果这个脚本永远只服务一个固定店铺，这不一定有问题；如果下一周就要支持多个店铺，写死就会变成维护负担。

所以“硬编码”不是看到常量就判错，关键要问：这个值是不是业务上会变化。

耦合改 A 的时候，为什么 B、C、D 都跟着动？

**耦合（Coupling）**描述模块之间依赖有多强。

场景：一个导出函数同时负责读数据库、算利润、拼 HTML、发钉钉。现在只想改导出格式，却担心消息发送也受影响，这就是耦合过强带来的维护成本。

封装我只需要知道怎么用，不必知道里面怎么做

**封装（Encapsulation）**就是把内部细节藏在明确入口后面。

场景：业务代码只调用 get_order_cost(order_id)，不需要每次都重新关心数据库连哪个表、税率怎样处理、异常怎样记录。这些细节由函数内部负责。

抽象把几个具体问题提炼成一个共同规则

**抽象（Abstraction）**是从多个具体实现里找共同概念。

场景：抖音、京东、淘宝都要“读取订单”。如果它们真的有稳定的共同输入输出，可以抽象成统一的订单读取接口；如果三套逻辑差异很大，强行抽象反而会更难懂。

抽象不是代码越少越高级。 对新项目来说，先把真实逻辑写清楚，往往比提前设计“万能框架”更可靠。

幂等点两次，不应该多做一份

**幂等（Idempotent）**指同一个操作重复执行时，不会因为“重复”而额外改变预期结果。

场景：自动化因为网络超时，不确定“订单状态更新”到底成功没有，于是重试一次。如果接口是幂等的，两次请求仍然只把订单改成同一个状态；如果不是，可能重复扣库存、重复发消息。

幂等强调的是业务效果，不要求每次返回的时间戳、请求 ID 都一模一样。

依赖你的项目需要别人提供的什么东西？

**依赖（Dependency）**是项目运行、构建或开发所依赖的库、工具或模块。

场景：Python 项目用了 pandas，它就是项目依赖；前端项目需要某个 npm 包，这也是依赖。别人说“先安装依赖”，通常就是先把这些外部库装齐。

API、SDK、CLI：都是“使用能力”的入口，但入口长得不一样

API程序之间约定好的“办事窗口”

**API（Application Programming Interface）**可以先理解成程序之间约定好的调用方式。

场景：你的 Python 脚本向订单平台发送“查询订单”请求，平台按约定返回订单编号、金额和状态。你不需要知道对方内部数据库怎样设计，只需要按 API 规则调用。

SDK把常用调用封装成一套开发工具

**SDK（Software Development Kit）**通常包含现成的代码库、类型、示例或工具，让开发者更方便使用某个平台能力。

场景：平台原本要求你自己拼 URL、签名、请求头；官方 SDK 把这些细节包起来，你只调用 client.send_message()。

CLI不点界面，直接在终端发命令

**CLI（Command-Line Interface）**就是命令行界面。

场景：git status 看代码状态，npm run build 构建网站，python app.py 运行脚本。AI 编程时经常会看到 Agent 执行 CLI 命令验证项目。

前端、后端：一个更靠近用户，一个更靠近数据和规则

**前端（Frontend）**通常负责用户直接看到和操作的部分：页面、按钮、表格、输入框、交互。

**后端（Backend）**通常负责服务器侧的业务逻辑、权限、数据处理、数据库读写和 API。

场景：利润看板上“日期筛选器不好用”，更像前端问题；“同一个 SKU 的利润算错了”，可能发生在后端计算逻辑或数据层。

这不是绝对边界。静态网站可能没有传统后端，桌面程序也可能把界面和数据处理放在一个项目里。先把它理解成“用户界面层”和“业务 / 数据处理层”的常见分工即可。

同步 vs 异步：要不要原地等它做完？

异步不是“更快”的同义词。它主要解决的是等待期间怎么安排其它工作。

Webhook别一直问“好了吗”，好了以后它来告诉你

Webhook是一种事件通知方式：某件事发生后，对方主动向你提供的地址发送请求。

场景：支付完成后，支付平台主动通知你的系统“这笔订单已付款”。这样你的程序不必每隔 5 秒去问一次“付款了吗”。

与 Webhook 相对的常见做法是轮询（Polling）：自己定期去检查状态有没有变化。

数据库和缓存，都是存数据，但目的完全不同

数据库系统长期管理结构化数据的地方

**数据库（Database）**用来持久保存和查询业务数据。

场景：订单、商品、用户、任务状态长期保存在数据库里，程序重启后数据仍然存在。

缓存拿空间换时间，减少重复计算或重复查询

**缓存（Cache）**把近期常用、获取成本较高的数据临时保存起来，下次优先读取副本。

场景：商品资料每分钟会被程序查几百次，但一天只变化一次。把结果缓存 10 分钟，可以减少重复访问数据库或 API。

缓存的麻烦也很典型：源数据已经变了，缓存还没过期。 所以遇到“明明改了，页面怎么还是旧的”，开发者常会先怀疑缓存。

Git：它不是“上传代码”，而是一套修改历史

AI 编程很快就会碰到 Git。先把它理解成：在本地保存一系列可追踪的代码版本，再选择什么时候和远端仓库同步。

Repository / Repo仓库

**仓库（Repository，常简称 Repo）**是被 Git 管理的一套项目文件和历史记录。

场景：博客项目整个目录就是一个 Git 仓库，其中既有当前文件，也有过去每次提交留下的历史。

Branch分支

**分支（Branch）**是一条独立的修改线路。

场景：正式代码在 main，你另开一个分支做新功能。功能没完成时，不必让主线代码跟着一起变化。

Commit在本地历史里保存一个明确版本

**提交（Commit）**可以理解成给当前一组代码变化拍一个带说明的“版本快照”。

场景：修完搜索按钮后执行 commit，并写“fix home search layout”。以后可以知道这次到底改了哪些文件。

Push把本地提交发到远端

Push是把本地已经存在的 commit 上传到 GitHub 等远端仓库。

所以“已经 commit”不等于“GitHub 已经有了”。

Pull把远端的新变化取回来并整合到本地

Pull通常意味着把远端最新提交获取下来，再合并到当前分支。

场景：另一台电脑昨晚 push 了新代码，今天这台电脑先 pull，再继续开发，避免基于旧版本修改。

Merge / Conflict合并，以及“双方都改了这里怎么办”

**Merge（合并）**是把两条开发历史整合起来。

**Conflict（冲突）**出现在 Git 无法自动判断该保留哪一份改动时。

场景：你和同事同时改了同一行配置。Git 不敢替你决定，于是标记冲突，让人明确选择最终内容。

环境、构建、部署：为什么“我电脑上能跑”还不算结束？

环境同一份代码，是在哪套条件里运行？

**环境（Environment）**是程序运行时所处的一整套条件，包括操作系统、运行时版本、依赖、配置、数据库和外部服务等。

常见说法：

• 开发环境（Development）：开发者日常写代码和调试。
• 测试 / 预发布环境（Test / Staging）：上线前验证。
• 生产环境（Production，常简称 Prod）：真实用户正在使用。

场景：“本地正常、线上报错”，经常不是玄学，而是两边环境不一致，例如 Python 版本、环境变量或依赖版本不同。

环境变量把运行配置放在代码外面

**环境变量（Environment Variable）**是程序从运行环境读取的一类配置。

场景：数据库地址、API Token、运行模式不直接写进仓库，而由部署环境提供。

环境变量并不会自动变安全；敏感值是否安全，还取决于保存方式、权限和日志是否泄露。

构建把源码加工成可运行或可发布的产物

**构建（Build）**是把开发阶段的源码、资源和依赖经过编译、打包、生成等步骤，变成目标环境需要的产物。

场景：Astro 博客执行 npm run build 后生成静态 HTML、CSS 和 JavaScript 文件；这时只是“产物做好了”，还没有自动出现在网站上。

部署把产物送到目标环境，并让它真正提供服务

**部署（Deploy）**发生在构建之后：把版本放到服务器、云平台或静态托管平台，并切换到可访问状态。

场景：博客构建完成后，GitHub Actions 把静态产物发布到 GitHub Pages，这一步才是部署。

CI/CD把重复的验证和交付流程自动化

CI/CD不是某一个具体工具，而是一类自动化流程。

• CI（Continuous Integration，持续集成）：代码变化后自动执行测试、检查、构建等验证。
• CD（Continuous Delivery / Deployment）：把验证通过的版本继续交付或部署到目标环境。

场景：你 push 到 main 后，GitHub Actions 自动安装依赖、构建博客、发布 Pages，这就是一条 CI/CD 流程。

回滚新版本不对，先退回已知可用版本

**回滚（Rollback）**是在新版本出现严重问题时恢复到之前的稳定版本或状态。

场景：新版本上线后首页打不开。与其在线上边猜边修，不如先恢复上一版，让服务恢复，再继续排查。

旧术语表里有些词，我为什么没有继续塞进正文？

原笔记里还有竞态条件、死锁、内存泄漏、索引、事务、守护进程、心跳、容器化、限流等术语。它们都是真实而且重要的概念，但对刚开始 AI 编程的人，不需要在第一篇里一次吃完。

最后，把常见开发对话翻译成人话

如果以后再遇到一个陌生术语，不必先问“标准定义是什么”。先问三个问题通常更有效：它出现在开发流程的哪一步？它解决什么问题？如果不理解它，我现在会做错什么？

这才是术语真正有用的地方。