从零到一：软件开发全流程技术名词图谱

开发一个完整的软件项目，会接触到大量陌生的技术名词。起初可能只是想写一个简单的程序，后来逐步接触到项目构建工具、后端框架、数据库、缓存、容器化、版本控制、接口设计。再往后开始开发 AI 应用，又会遇到大语言模型、Token、向量嵌入、检索增强生成、模型上下文协议、Agent 循环、编排框架、有向无环图、调度器等概念。

这些名词有些是技术，有些是工具，有些是架构思想，还有些只是描述某种开发流程的术语。如果没有一张完整的知识地图，很容易出现一种情况：每个词都好像听过，但不知道它们之间有什么关系。

因此，本文按照一个软件项目从零到一的开发过程，整理常见技术名词，帮助读者建立体系化的认知。

---

一、需求与产品定义阶段

写代码之前，首先需要明确要做什么。这一阶段的核心任务是搞清楚“为什么做”“做什么”“为谁做”“做到什么程度”。

1.1 需求文档体系

PRD（Product Requirements Document，产品需求文档）
描述产品功能、业务规则和需求的文档。它通常包含功能列表、交互流程、边界条件、优先级等，是开发、测试、设计协同的基础。一份好的 PRD 应当做到“开发看了能写代码，测试看了能写用例”。

BRD（Business Requirements Document，业务需求文档）
主要描述业务目标和商业价值。它回答的是“这个项目能为业务带来什么”，通常面向管理层和业务方，侧重投入产出比、市场机会和战略对齐。

MRD（Market Requirements Document，市场需求文档）
分析市场、用户和产品机会。它关注的是外部视角：目标用户是谁、市场规模多大、竞品如何、产品切入点在哪里。MRD 通常在 BRD 之后、PRD 之前完成。

三者关系可以简单理解为：MRD 回答“市场要不要”，BRD 回答“业务值不值”，PRD 回答“具体怎么做”。

1.2 需求表达方法

User Story（用户故事）
从用户角度描述希望完成什么事情。典型格式为：“作为一名[角色]，我希望[完成某件事]，以便[获得某种价值]。”用户故事强调价值交付而非功能罗列，常用于敏捷开发。

Use Case（用例）
描述用户与系统完成某个目标的交互过程。与用户故事相比，用例更结构化，通常包含前置条件、主流程、异常流程和后置条件，适合复杂业务场景的建模。

Acceptance Criteria（验收标准）
判断一个功能是否真正完成的具体条件。它通常以清单形式附在用户故事之后，是测试用例设计的直接输入。验收标准应当具体、可验证，避免模糊表述。

1.3 验证与迭代策略

MVP（Minimum Viable Product，最小可行产品）
先实现核心价值，再逐步完善。MVP 的目的是用最小成本验证核心假设，获取真实用户反馈，避免在错误方向上投入过多资源。

POC（Proof of Concept，概念验证）
验证某种技术或方案是否可行。与 MVP 面向用户不同，POC 通常面向技术团队，用于验证关键技术风险，例如“某算法能否在可接受时间内完成计算”“某架构能否支撑目标并发量”。

Prototype（原型）
用于展示产品交互和设计思路的初步模型。原型可以是纸面的，也可以是可交互的数字模型，目的是在编码之前对齐设计意图。

1.4 界面与体验设计

Wireframe（线框图）
页面布局的低保真草图。它关注信息层级和功能布局，不涉及视觉细节，是快速沟通结构设计的有效工具。

Mockup（视觉稿）
更接近最终视觉效果的静态界面设计。它在 Wireframe 的基础上加入色彩、字体、图标等视觉元素，但仍不可交互。

UI（User Interface，用户界面）
用户看到和操作的部分。UI 设计关注控件的布局、一致性、可点击区域、反馈状态等。

UX（User Experience，用户体验）
关注使用过程是否方便、自然。UX 的范围比 UI 更广，涵盖用户在整个使用旅程中的感受，包括信息架构、交互流程、响应速度、容错能力等。

---

二、项目基础与工程化阶段

需求明确之后，进入工程搭建阶段。这一阶段的核心任务是建立可协作、可构建、可交付的工程基础。

2.1 版本控制与协作

Git
分布式版本控制系统，用于跟踪代码变更、支持多人协作和分支管理。围绕 Git 形成的工作流（如主干开发、特性分支、代码评审）是现代软件团队协作的基础。

代码评审（Code Review）
在代码合并前由其他开发者检查代码质量、逻辑正确性和风格一致性的过程。它是知识共享和质量保障的重要手段。

2.2 项目构建与依赖管理

Maven
Java 生态中常见的项目构建与依赖管理工具。它通过声明式的配置文件管理依赖版本、构建生命周期和插件，使项目构建可重复、可移植。

Gradle
另一种构建工具，相比 Maven 更灵活，支持 Groovy 或 Kotlin DSL 编写构建脚本，常用于 Android 和大型多模块项目。

依赖冲突
当多个库依赖同一组件的不同版本时，可能导致运行时行为异常。构建工具通常提供依赖调解机制，但开发者仍需理解依赖树，主动排查冲突。

2.3 后端框架

Spring Boot
Java 生态中广泛使用的后端开发框架。它通过自动配置和起步依赖简化了传统框架的繁琐配置，使开发者能快速构建独立运行的服务。

MVC（Model-View-Controller）
一种经典的分层架构模式，将数据、展示和逻辑分离。在后端开发中，通常体现为 Controller 接收请求、Service 处理业务、Repository 访问数据。

REST API（Representational State Transfer API）
一种基于 HTTP 的接口设计风格。它使用资源路径、HTTP 方法和状态码来表达操作语义，具有无状态、可缓存、分层等特性，是前后端分离架构中最常见的接口形式。

2.4 数据存储与缓存

MySQL
关系型数据库，以表结构存储数据，支持事务、索引和 SQL 查询。适合需要强一致性和复杂查询的场景。

Redis
内存数据结构存储，常用作缓存、会话存储和消息代理。它支持字符串、列表、哈希、集合等数据结构，读写性能高，适合热点数据加速。

缓存穿透、缓存击穿、缓存雪崩
缓存使用中的典型问题。穿透指查询不存在的数据导致请求打到数据库；击穿指热点键过期瞬间大量请求涌入数据库；雪崩指大量键同时过期导致数据库压力骤增。对应有布隆过滤器、互斥锁、过期时间打散等应对策略。

2.5 容器化与部署

Docker
容器化工具，将应用及其依赖打包成镜像，实现“一次构建，到处运行”。它解决了环境不一致问题，简化了交付流程。

Kubernetes
容器编排平台，用于自动化部署、扩缩容和管理容器化应用。它提供 Service、Deployment、ConfigMap 等抽象，是云原生应用的事实标准。

CI/CD（持续集成/持续交付）
持续集成指频繁将代码合并到主干并自动构建测试；持续交付指在 CI 基础上自动部署到类生产环境。CI/CD 流水线是现代软件交付的核心实践。

---

三、AI 应用开发阶段

当软件项目开始集成 AI 能力，会进入一个全新的概念领域。这一阶段的核心任务是理解大模型的工作原理，并将其有效地嵌入到应用系统中。

3.1 大模型基础

LLM（Large Language Model，大语言模型）
基于海量文本训练的深度神经网络，能够理解和生成自然语言。它通过预测下一个 Token 的方式生成文本，具备一定的推理、总结和代码生成能力。

Token
模型处理文本的基本单位。一个 Token 可能是一个词、一个子词或一个字符。Token 数量直接影响模型的输入长度限制和调用成本。

上下文窗口（Context Window）
模型单次能够处理的最大 Token 数量。超出窗口的内容需要截断或分段处理，这是设计 AI 应用时必须考虑的限制。

Prompt（提示词）
输入给模型的指令或问题。Prompt 工程关注如何设计输入以获取更准确、更稳定的输出，包括角色设定、示例引导、格式约束等技巧。

Temperature
控制生成随机性的参数。值越低输出越确定，值越高输出越多样。不同任务需要不同的温度设置，例如事实问答适合低温，创意写作适合高温。

3.2 向量与检索

Embedding（向量嵌入）
将文本映射为高维数值向量的过程。语义相近的文本在向量空间中距离更近，这使得基于语义的检索成为可能。

向量数据库
专门用于存储和检索向量数据的数据库。它支持近似最近邻搜索，能够在海量向量中快速找到与查询向量最相似的条目。

RAG（Retrieval-Augmented Generation，检索增强生成）
一种将检索与生成结合的模式。系统先从知识库中检索相关内容，再将检索结果作为上下文输入模型，从而提升回答的准确性和时效性。RAG 有效缓解了模型幻觉和知识过时问题。

3.3 协议与编排

MCP（Model Context Protocol，模型上下文协议）
一种标准化协议，用于规范模型与外部工具、数据源之间的交互方式。它使模型能够以统一的方式调用外部能力，降低了集成复杂度。

Agent Loop（智能体循环）
智能体反复执行“观察—思考—行动”的循环过程。模型根据当前状态决定下一步动作，执行后获取结果，再进入下一轮，直到任务完成或达到终止条件。

DAG（Directed Acyclic Graph，有向无环图）
一种描述任务依赖关系的数据结构。在 AI 工作流中，DAG 用于编排多个处理步骤，确保执行顺序正确且无循环依赖。

Scheduler（调度器）
负责按依赖关系和资源情况安排任务执行的组件。在 AI 工作流中，调度器决定哪些节点可以并行、哪些必须串行，以及如何处理失败重试。

3.4 智能体工程实践

工具调用（Tool Calling）
模型根据用户请求决定调用哪个外部工具，并生成符合工具接口要求的参数。工具调用使模型能够获取实时信息、执行计算或操作外部系统。

记忆（Memory）
智能体在对话或任务执行过程中保持和利用历史信息的能力。短期记忆通常指当前会话上下文，长期记忆则涉及外部存储和检索。

护栏（Guardrails）
对模型输入输出进行约束和过滤的机制，用于防止有害内容、敏感信息泄露或不符合业务规则的输出。

评估（Evaluation）
对 AI 应用输出质量进行系统化衡量的过程。常见方法包括人工评估、自动指标（如准确性、相关性）和对抗测试。

---

四、名词之间的关系与学习路径

上述名词并非孤立存在，而是围绕“构建一个可交付的软件系统”这一目标层层展开。

从纵向看，需求阶段的 PRD、User Story 定义了“做什么”；工程阶段的框架、数据库、容器化解决了“怎么构建”；AI 阶段的 LLM、RAG、Agent 则回答了“如何让系统具备智能”。

从横向看，每个阶段都有其核心概念和工具链。例如数据存储阶段，关系型数据库、缓存、向量数据库分别对应不同数据类型和访问模式；AI 应用阶段，Prompt、Embedding、RAG、Agent 构成了从“调用模型”到“构建智能体”的递进路径。

建议的学习路径是：先理解需求与工程基础，再进入 AI 应用开发。因为 AI 应用本质上仍然是软件系统，需要后端框架、数据库、接口设计等工程能力作为支撑。在此基础上，再掌握大模型交互、检索增强和智能体编排，才能构建出真正可用的 AI 应用。

---

五、总结

从需求分析到 AI Agent 工程，软件开发的每个阶段都伴随着大量技术名词。这些名词背后，是不同层次的问题和解决思路。建立一张完整的知识地图，不仅能帮助开发者快速定位所需技术，还能在跨阶段协作中形成共同语言。

技术名词会不断更新，但分层理解、按需深入的方法论是稳定的。希望本文能为读者提供一张从零到一的技术名词图谱，在开发实践中起到参考和导航的作用。