这是一页参考索引，从 AI 像一门更高级的编程语言 一文中拆出。那篇的主线观点是：AI 接走了编码以后，准确的专业语言仍然决定产品质量。这里保存完整的术语表，供不确定一个词时回查。
下面按一项产品工作通常经过的环节排列。它不追求教科书式定义，只记录一个词能帮我们说清什么。团队之间的叫法会有差异，使用前还要结合项目里的具体约定。
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 目标用户 Target User | 产品优先服务的具体人群 | 判断功能为谁解决问题，哪些人暂时不在范围内 |
| 问题陈述 Problem Statement | 用户处境、现有阻碍和期望变化 | 在讨论功能以前确认问题是否真实 |
| 待办任务 Jobs to Be Done | 用户在某个情境下想完成的进展 | 避免把需求只写成页面和按钮 |
| 用户故事 User Story | 某类用户为了某个目的需要一种能力 | 把需求放回用户、目标和价值中表达 |
| 用例 Use Case | 角色与系统完成目标的交互过程 | 展开主流程、异常流程和边界条件 |
| 产品需求文档 PRD | 记录目标、范围、规则和验收约定 | 让产品、设计、开发和测试依据同一份需求工作 |
| 功能需求 Functional Requirement | 系统需要提供的具体行为 | 描述用户能做什么，系统应该怎样响应 |
| 非功能需求 Non-functional Requirement | 性能、安全、可靠性和兼容性要求 | 防止功能可用却无法在真实环境交付 |
| 范围 Scope | 当前版本明确包含和排除的内容 | 控制任务膨胀，给 agent 划出允许修改的边界 |
| 约束 Constraint | 方案必须遵守的技术或业务限制 | 保留兼容接口、合规规则、预算和时间边界 |
| 验收标准 Acceptance Criteria | 判断需求完成的可观察条件 | 把“做好了”改成页面行为、接口结果或指标 |
| 最小可行产品 MVP | 用最小范围验证核心假设的版本 | 在大量投入前验证用户是否真的需要 |
| 需求池 Backlog | 尚未完成并持续排序的工作集合 | 管理后续需求、缺陷和技术改进 |
| 就绪定义 Definition of Ready | 工作项进入开发前应具备的条件 | 检查目标、依赖、范围和验收是否足够清楚 |
| 完成定义 Definition of Done | 工作项结束前必须满足的统一质量条件 | 约束代码、测试、文档和发布准备是否齐全 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 通用语言 Ubiquitous Language | 团队在代码和交流中共同使用的领域语言 | 统一业务名词、数据字段和代码命名 |
| 领域模型 Domain Model | 业务概念、关系、行为和规则的表达 | 把真实业务翻译成可以设计和实现的结构 |
| 限界上下文 Bounded Context | 一套领域模型保持明确含义的边界 | 处理同名概念在不同业务中的差异 |
| 不变量 Invariant | 系统运行中始终要成立的规则 | 定义金额、状态和权限不能破坏的条件 |
| 状态机 State Machine | 状态、事件和允许转换的集合 | 设计订单、审批、任务和设备生命周期 |
| 契约 Contract | 调用双方对输入、输出、错误和兼容性的约定 | 设计 API、事件和模块接口 |
| 架构决策记录 ADR | 一项关键设计选择及其背景和取舍 | 保存以后难以从代码里还原的决策原因 |
| 耦合 Coupling | 模块之间相互依赖的程度 | 判断一次修改会影响多少地方 |
| 内聚 Cohesion | 一个模块内部职责相关的程度 | 判断代码是否围绕同一件事组织 |
| 事务边界 Transaction Boundary | 需要一起提交或一起回滚的一组操作 | 划定数据一致性的范围 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 概念验证 Proof of Concept | 一条关键技术路线是否可行 | 在正式设计前验证最不确定的技术点 |
| 技术探针 Spike | 有时间限制的调查或试验任务 | 估算未知成本，比较候选方案 |
| 征求意见稿 RFC | 可讨论的方案、接口和取舍说明 | 在大改动开始前收集团队反馈 |
| 任务拆分 Task Breakdown | 把目标拆成可独立验证的小任务 | 控制 agent 单次改动范围并安排依赖顺序 |
| 分支 Branch | 与主线隔离的一组代码变化 | 并行开发功能、修复和实验 |
| 提交 Commit | 带有说明的最小版本变化记录 | 保存可审查、可回退的工作节点 |
| 合并请求 Pull Request | 请求把一组变更合入目标分支 | 集中展示差异、测试结果和讨论 |
| 代码审查 Code Review | 检查实现、风险和可维护性的过程 | 在合并前发现设计偏差和隐蔽错误 |
| 重构 Refactoring | 在保持外部行为的前提下改进代码结构 | 降低后续修改成本，清理重复和混乱职责 |
| 技术债 Technical Debt | 为短期速度留下的未来维护成本 | 决定哪些妥协需要记录和偿还 |
| 语义化版本 Semantic Versioning | 用主版本、次版本和修订号表达兼容变化 | 发布库、API 和可复用组件 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 用户界面 UI | 用户直接看到和操作的页面元素 | 讨论布局、组件、视觉层级和交互状态 |
| 用户体验 UX | 用户完成目标时经历的完整过程 | 评估流程是否清楚、顺畅且可恢复 |
| 信息架构 Information Architecture | 内容、页面和导航之间的组织关系 | 设计栏目、菜单、层级和查找路径 |
| 设计系统 Design System | 可复用的视觉规则、组件和使用约定 | 保持多个页面与产品的一致性 |
| 设计令牌 Design Token | 颜色、字号、间距等基础设计值 | 让设计规则能在代码中统一复用 |
| 组件 Component | 封装界面结构、行为和样式的单元 | 复用按钮、表单、卡片和业务模块 |
| 状态管理 State Management | 界面状态的来源、更新和共享方式 | 处理跨组件数据、异步请求和复杂交互 |
| 客户端渲染 CSR | 页面主要在浏览器中生成 | 构建交互密集的单页应用 |
| 服务端渲染 SSR | 服务器在请求时生成页面 HTML | 改善首屏、动态内容和搜索收录 |
| 静态生成 SSG | 构建阶段提前生成页面 HTML | 发布博客、文档和变化较少的内容 |
| 水合 Hydration | 给服务端生成的 HTML 接上客户端交互 | 排查页面可见却暂时不能操作的问题 |
| 响应式设计 Responsive Design | 页面适配不同屏幕和输入方式 | 处理手机、平板和桌面布局 |
| 可访问性 Accessibility | 残障用户也能感知和操作界面的能力 | 检查键盘、读屏、对比度和语义结构 |
| 核心网页指标 Core Web Vitals | 衡量加载、响应和视觉稳定性的指标 | 发现真实用户感受到的前端性能问题 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 应用接口 API | 软件之间交换能力和数据的边界 | 连接前端、后端和外部服务 |
| REST | 以资源和 HTTP 语义组织接口的风格 | 设计常规 Web API |
| RPC | 像调用函数一样请求远程服务执行操作 | 处理内部服务间的明确命令调用 |
| Webhook | 事件发生后由服务主动回调外部地址 | 接收支付、仓库和第三方平台通知 |
| 中间件 Middleware | 在请求主逻辑前后执行的通用处理 | 统一认证、日志、限流和错误处理 |
| 认证 Authentication | 确认请求者是谁 | 登录、令牌校验和设备身份识别 |
| 授权 Authorization | 判断请求者可以做什么 | 角色权限、资源归属和数据隔离 |
| 数据迁移 Schema Migration | 受版本管理的数据结构变更 | 新增字段、修改索引和升级生产数据库 |
| 索引 Index | 用额外数据结构加速查询 | 优化数据库检索、排序和关联 |
| 缓存 Cache | 保存可复用结果以减少重复计算或访问 | 降低延迟和数据库压力 |
| 消息队列 Message Queue | 暂存并异步传递待处理消息 | 削峰、重试和解耦耗时任务 |
| 发布订阅 Pub/Sub | 发布方把事件分发给多个订阅方 | 驱动跨模块事件和异步协作 |
| 幂等 Idempotency | 同一业务请求重复执行不产生额外结果 | 处理重试、重复回调和消息重复消费 |
| 最终一致性 Eventual Consistency | 允许短暂不一致，并按规则收敛 | 设计异步流程和跨服务协作 |
| 背压 Backpressure | 下游处理不过来时限制上游输入 | 保护队列、流式任务和推理服务 |
| 限流 Rate Limiting | 限制单位时间内的请求数量 | 防止突发流量耗尽服务资源 |
| 超时与重试 Timeout and Retry | 限定等待时间并处理暂时性失败 | 调用网络服务和不稳定依赖 |
| 熔断 Circuit Breaker | 依赖持续失败时暂时停止调用 | 防止故障在服务之间扩大 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 测试用例 Test Case | 输入、步骤、预期结果和前置条件 | 把验收标准展开成可以重复执行的检查 |
| 单元测试 Unit Test | 隔离验证一个较小逻辑单元 | 快速检查分支和边界条件 |
| 集成测试 Integration Test | 验证多个真实组件能否正确协作 | 检查数据库、消息队列和外部服务接入 |
| 契约测试 Contract Test | 验证接口双方仍遵守同一约定 | 防止 API 或事件升级后互不兼容 |
| 端到端测试 End-to-End Test | 从用户入口走完一条完整业务流程 | 验证关键流程能够交付 |
| 验收测试 Acceptance Test | 从业务或用户角度判断需求是否满足 | 在交付前确认验收标准已经成立 |
| 回归测试 Regression Test | 检查已有功能是否被新改动破坏 | 发布前复查高风险旧流程 |
| 冒烟测试 Smoke Test | 快速检查版本最基本的能力是否可用 | 部署后判断能否继续深入测试 |
| 测试替身 Test Double | 用可控对象代替真实依赖 | 隔离数据库、网络和外部服务 |
| 测试覆盖率 Test Coverage | 测试执行到的代码或分支比例 | 发现明显缺口，不能单独证明质量 |
| 不稳定测试 Flaky Test | 相同代码下结果偶尔成功、偶尔失败的测试 | 排查并发、时间、环境和共享状态问题 |
| 基于性质的测试 Property-Based Test | 生成大量输入，检查始终成立的性质 | 验证解析器、状态机和复杂数据规则 |
| 负载测试 Load Test | 在预期并发和数据量下测量系统表现 | 验证容量、延迟和资源使用 |
| 压力测试 Stress Test | 超过预期负载以寻找系统极限 | 观察过载后的退化和恢复能力 |
| 安全测试 Security Test | 检查漏洞、越权和数据暴露风险 | 上线前验证认证、授权和输入处理 |
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 构建 Build | 把源码转换成可运行或可分发结果 | 编译、打包和生成静态资源 |
| 制品 Artifact | 一次构建产生并可追踪的文件或镜像 | 在不同环境部署同一版本 |
| 持续集成 CI | 每次变更自动执行构建和检查 | 尽早发现合并冲突、测试和质量问题 |
| 持续交付 CD | 自动把通过检查的版本送到可发布状态 | 缩短从合并到部署的时间 |
| 环境 Environment | 开发、测试、预发布和生产等运行空间 | 隔离配置、数据和发布风险 |
| 配置 Configuration | 随环境变化但不写死在代码里的参数 | 调整地址、开关和运行策略 |
| 密钥 Secret | 需要受控保存的密码、令牌和证书 | 连接数据库、云服务和第三方 API |
| 容器 Container | 把应用和运行依赖封装成可移植单元 | 保持本地、测试和生产环境一致 |
| 基础设施即代码 IaC | 用版本化文件声明基础设施 | 创建云资源、网络和权限配置 |
| 部署 Deployment | 把一个版本安装到目标环境 | 更新服务器、容器或静态站点 |
| 发布 Release | 让已部署的能力对用户可用 | 配合版本、开关和发布说明开放功能 |
| 正式上线 Launch | 把产品或重要版本正式推向目标用户 | 协调发布、公告、渠道和支持准备 |
| 功能开关 Feature Flag | 用运行时开关控制功能是否生效 | 分离代码部署和功能开放 |
| 金丝雀发布 Canary Release | 先让少量实例或流量使用新版本 | 控制风险并观察真实指标 |
| 蓝绿发布 Blue-Green Deployment | 在两套环境间切换新旧版本 | 快速切换和回退完整版本 |
| 回滚 Rollback | 让代码、配置或数据回到可工作状态 | 处理发布失败和严重回归 |
| 可观测性 Observability | 通过日志、指标和追踪判断系统状态 | 排查线上问题和验证运行结果 |
| SLI、SLO 与 SLA | 指标、内部目标和对外承诺三个层次 | 定义可用性、延迟和错误率要求 |
| 事故 Incident | 已经影响或可能影响服务的异常事件 | 启动响应、沟通和恢复流程 |
| 运行手册 Runbook | 处理常见操作和故障的可执行步骤 | 值班、发布和应急处置 |
| 复盘 Postmortem | 事故后的事实、原因和改进行动记录 | 修复系统问题并跟踪后续任务 |
| RTO 与 RPO | 恢复所需时间和可接受的数据丢失范围 | 设计备份、容灾和恢复方案 |
这里的宣发指产品怎样被目标用户看见、理解和尝试，以及发布后怎样判断用户是否留下。它和产品规划、内容运营会有交叉，重点仍是把传播目标和结果说清楚。
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 产品定位 Positioning | 产品为哪类用户解决什么问题，和替代方案有何差异 | 决定首页、介绍文案和渠道选择 |
| 理想客户画像 ICP | 最可能获得价值并愿意采用产品的客户特征 | 聚焦早期用户和销售线索 |
| 价值主张 Value Proposition | 用户选择产品能够得到的明确价值 | 写产品介绍、落地页和发布文案 |
| 信息表达 Messaging | 面向不同受众稳定使用的一组说法 | 统一官网、社交媒体和销售材料 |
| 市场进入策略 Go-to-Market | 产品进入市场的受众、渠道、定价和节奏 | 规划新产品或重要版本的推出方式 |
| 落地页 Landing Page | 承接某次传播并引导用户采取行动的页面 | 发布产品、投放内容和收集注册 |
| 行动按钮 CTA | 明确希望用户下一步采取的动作 | 引导注册、试用、订阅和下载 |
| 获客渠道 Acquisition Channel | 用户第一次接触产品的来源 | 比较搜索、社区、内容和广告效果 |
| 内容营销 Content Marketing | 用持续内容帮助用户理解问题和产品 | 写博客、案例、教程和行业解释 |
| 搜索优化 SEO 与 ASO | 改善网页或应用在搜索结果中的发现能力 | 获取长期自然流量 |
| 发布说明 Release Notes | 面向用户解释本次版本变化 | 告知新增能力、修复和使用影响 |
| 变更记录 Changelog | 按版本持续记录产品变化 | 给用户和开发者提供可追踪历史 |
| 转化漏斗 Funnel | 用户从看见产品到完成目标的一组阶段 | 定位流失发生在哪一步 |
| 转化率 Conversion Rate | 完成目标动作的用户比例 | 衡量注册、试用、购买和订阅效果 |
| 激活 Activation | 新用户第一次获得核心价值的时刻 | 设计新手流程和首个成功体验 |
| 留存 Retention | 用户在一段时间后继续使用产品的情况 | 判断产品是否形成持续价值 |
| A/B 测试 | 随机比较两个版本对目标指标的影响 | 验证页面、文案和流程改动 |
| 归因 Attribution | 判断一次转化应归到哪个来源或触点 | 评估渠道和活动投入 |
| 获客成本 CAC 与用户价值 LTV | 获得一个客户的成本和客户长期贡献 | 判断增长方式是否能持续 |
这组术语以 Codex、Claude Code 这类可以读写代码库并调用工具的 coding agent 为语境。不同产品对 System Prompt、Skill 和 Harness 的文件结构与优先级定义并不相同，表里只保留它们共同的工程含义。
| 术语 | 它约束什么 | 常见使用场景 |
|---|
| 上下文窗口 Context Window | 模型一次处理能够容纳的上下文范围 | 决定放入哪些代码、文档和历史信息 |
| 系统提示 System Prompt | 应用在会话中提供的高优先级行为约束 | 放项目规则、角色边界和输出要求 |
| 工具调用 Tool Calling | 模型按结构化参数请求外部工具执行动作 | 让 agent 读文件、查数据和调用服务 |
| Agent 循环 Agent Loop | 模型读取结果、决定下一步并继续调用工具的循环 | 理解 agent 怎样完成多步任务 |
| MCP | 连接 AI 应用与外部工具、数据源的开放协议 | 接入数据库、浏览器和业务系统 |
| Skill | coding agent 中可复用的任务说明、参考材料和执行资源 | 固化团队反复使用的工作方法 |
| Harness | 包围模型的上下文、工具、权限和反馈系统 | 提高 agent 执行复杂任务的稳定性 |
| 护栏 Guardrail | 在输入、工具或输出层强制执行的限制 | 阻止越权操作和不合规结果 |
| 沙箱 Sandbox | 隔离代码执行范围和权限的环境 | 运行未知代码或低信任任务 |
| 评测 Eval | 用固定任务和判定标准反复测量 agent 表现 | 比较模型、提示词和工具链变化 |
| 检查点 Checkpoint | 保存可恢复、可审查的中间状态 | 支持长任务续跑、回退和人工确认 |
这份索引适合在不确定一个词时回查，不适合一次塞进 prompt。先判断当前工作处在哪个环节，再挑能缩小范围、明确方案或约束验收的词。术语用得多，不代表任务写得更专业。
通用术语也替代不了项目自己的领域语言。每个业务词写一句定义，补上不能混用的近义词，再链接到对应代码或业务文档。这个文件可以叫 CONTEXT.md、GLOSSARY.md，也可以放进现有项目说明。文件名不重要，agent 能找到并持续使用才有价值。