术语表 – Agentic Work in Real Life
本术语表汇总了 “Agentic Work in Real Life” 系列中使用的专业术语,并补充了一些当前 AI 与 Agentic Engineering 讨论中经常出现、但未必是正文重点的概念。
所有解释都刻意保持简短并强调实践语境。部分术语——尤其是 AGI、ASI、Agentic AI、Frontier Model、Memory、Skill 和 Vibe Coding——并没有统一标准,不同服务商或社区的用法可能略有差异。
产品、模型、组织和论文名称不会被完整收录。像 SWE-bench 或 ARC-AGI 这样的名称是例外,因为它们已经逐渐成为常见专业术语或 Benchmark 家族的名称。
| 术语 / 缩写 | 全称 | 简要说明 |
|---|---|---|
| Acceptance Criteria | — | 用于判断某项需求或变更在业务和技术上是否已满足的标准。 |
| Acceptance Test | — | 检查系统或功能是否满足既定业务验收标准的测试。 |
| Accepted Change | — | 经过充分技术和业务验证后,可以被接受并纳入系统的变更。 |
| Access Control | — | 控制谁或什么可以访问数据、功能或系统的机制。 |
| Active Parameters | — | 在 Mixture-of-Experts 模型中,针对某个具体 Token 或计算步骤实际被激活的模型参数子集。 |
| ADR | Architecture Decision Record | 简短且版本化的文档,用于记录重要的架构决策、背景和理由。 |
| Affected Analysis | — | 判断一次变更实际影响哪些项目、模块或测试,以便有针对性地缩小工作与验证范围。 |
| Agent | — | 通过组合模型、Context、Tools 等机制,跨多个步骤追求目标的系统。 |
| Agent File | — | 面向项目或工作区的 Agent 指令文件,例如包含架构、构建或工作规则。详见第 04 篇。 |
| Agent Harness | — | 通过编排 Context、Tools、循环、状态和执行,把模型变成 Agent 的软件环境。 |
| Agent Infrastructure | — | 支持 Agentic Work 的可复用技术与组织基础,例如规则、Skills、Tests、Tooling 和验证机制。 |
| Agent Skill | — | 可复用的操作手册或工作流程,用于告诉 Agent 某类任务应如何处理。 |
| Agent Time | — | Agent 自主处理任务所花费的时间。 |
| Agent-readable | — | 系统的一种特性:其关键结构、规则和信息对 Agent 来说可发现、可理解。 |
| Agent-verifiable | — | 系统的一种特性:Agent 可以通过 Build、Lint、Tests 或架构规则等可执行检查验证结果。 |
| Agentic AI | — | 对不仅生成答案,还能跨多个步骤追求目标并执行动作的 AI 系统的统称。 |
| Agentic Coding | — | 由 Coding Agents 自主承担分析、修改、测试等部分开发流程的软件开发方式。 |
| Agentic Work | — | 由 AI Agents 以一定自主程度处理多步骤任务的工作方式。 |
| AGI | Artificial General Intelligence | 没有统一定义的概念,通常指在多个领域具备广泛、可泛化、接近或达到人类水平能力的 AI。 |
| AI | Artificial Intelligence | 对执行通常与感知、语言、学习、规划或问题求解相关任务的计算机系统的统称。 |
| AI Coding Assistant | — | 帮助开发者编写或修改代码的 AI 工具;相比 Coding Agent,通常自主调用工具和自主执行的程度更低。 |
| AI Safety | — | 研究和工程领域,目标是限制强大 AI 系统产生有害、非预期或失控行为。 |
| Alignment | — | 使 AI 系统按照预期目标、规则以及人类监督来行动的相关工作。 |
| Anonymization | — | 对数据进行处理,使个人不再可被识别;真正匿名化的数据应与假名化数据区分。 |
| API | Application Programming Interface | 定义明确的软件接口,用于软件组件或服务之间的通信。 |
| ARC-AGI | Abstraction and Reasoning Corpus for Artificial General Intelligence | 用于衡量泛化和新技能学习能力的一类 Benchmark;高分并不等于普遍证明已经实现 AGI。 |
| Architecture Constraint | — | 限定允许或禁止某些结构性方案、从而缩小 Solution Space 的架构规则。详见第 08 篇。 |
| Architecture Review | — | 重点检查某项变更是否符合系统职责、边界、依赖关系和整体架构的 Review。 |
| ASI | Artificial Superintelligence | 假设性概念,通常指通用认知能力显著超越人类的 AI;具体定义并不统一。 |
| Authorization | — | 判断某个用户、Agent 或系统是否有权访问资源或执行操作。 |
| Benchmark | — | 用于衡量模型或系统特定能力或属性的标准化任务或任务集合。 |
| Benchmark Contamination | — | Benchmark 任务或高度相似的数据已经出现在模型训练中,从而可能使评测结果失真的问题。 |
| Benchmark Overfitting | — | 模型或系统过度针对已知 Benchmark 优化,但通用能力并未相应提升。 |
| Big Ball of Mud | — | 指结构难以辨认、耦合度高且积累了大量历史例外的系统。 |
| Broken Windows | — | 一种隐喻:可见但长期无人处理的例外或违规,会促使更多类似偏差出现。 |
| Build | — | 将源代码及其他产物转换为可执行或可交付形式的过程,期间通常也会暴露错误。 |
| Cached Tokens | — | 来自重复 Context 的 Input Tokens,其已计算状态可能被服务提供方复用。 |
| CapEx | Capital Expenditure | 用于长期资产的资本性支出,例如自有 AI 硬件。 |
| Chain of Thought (CoT) | Chain of Thought | 对模型中间 Reasoning 步骤的称呼;可见的推理摘要不一定等同于完整的内部推理轨迹。 |
| CI | Continuous Integration | 自动集成并检查变更的过程,通常包括 Build、Lint 和 Tests。 |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | 用于检查、构建,并根据具体模式交付或部署软件的自动化流水线。 |
| Cloud Model | — | 通过外部或内部云服务商的基础设施使用的 AI 模型。 |
| Coding Agent | — | 能够检查代码库、修改文件、运行 Tools、处理错误并生成连贯软件变更的 Agent。 |
| Cohesion | — | 衡量一个模块或组件内部各项职责在概念或业务上有多紧密相关的程度。 |
| Compute Budget | — | 为一次模型请求、Agent Run 或 Evaluation 可使用的有限计算资源。 |
| Computer Use | — | AI 系统像人一样通过鼠标、键盘或类似操作使用图形界面的能力。 |
| Constraint | — | 明确规定哪些解决方案、数据流或操作允许发生的规则或边界。 |
| Context | — | 模型在当前处理过程中实际可以访问的信息。 |
| Context Engineering | — | 有意识地选择、组织并持续维护模型和 Agents 所需相关 Context 的工作。详见第 04 篇。 |
| Context Window | — | 模型或某个具体 Endpoint 在一次处理中能够考虑的最大 Context 容量。 |
| Contract | — | 系统各部分之间对接口、数据格式、行为或职责的明确约定。 |
| Converge | — | 在关键决策已经做出后,尽可能严格地在剩余 Solution Space 内实施的阶段。属于 Diverge · Decide · Converge,详见第 10 篇。 |
| Coordination Time | — | 人员用于交接、提问、同步、Context Switching 以及协调 Agents 或工作步骤的时间。 |
| Cost per Accepted Change | — | 衡量一项期望变更直到经过充分验证并被接受为止的总成本的工程指标。详见第 13 篇。 |
| Cost per Run | — | 单次模型或 Agent Run 的成本。 |
| Cost per Successful Run | — | 每次技术上成功的 Agent Run 的成本,其中也包含达到成功前失败尝试的成本。 |
| Cost per Token | — | 按模型处理或生成的 Token 计算的价格或成本。 |
| Coupling | — | 模块或组件之间的依赖程度;高耦合通常会让独立修改更加困难。 |
| CQRS | Command Query Responsibility Segregation | 刻意将读取操作与改变状态的操作分离的架构模式。 |
| Credit | — | 某个 AI 服务产品自定义的计费单位;技术上并不等同于 Token。 |
| CRUD | Create, Read, Update, Delete | 创建、读取、更新和删除数据的四种基本操作。 |
| Data Minimization | — | 只处理或提供实现某个具体目的真正需要的数据的原则。 |
| Decide | — | 对开放选项进行评估并有意识做出关键决策的阶段。属于 Diverge · Decide · Converge,详见第 10 篇。 |
| Dependency Direction | — | 规定模块或层之间依赖关系允许朝哪个方向建立的架构规则。 |
| Dependency Graph | — | 以图形或技术方式表示模块、Libraries、Services 或其他系统部分之间的依赖关系。 |
| Determinism | — | 系统在相同状态和输入下能够可重复地产生相同结果的属性。 |
| Developer Experience (DX) | Developer Experience | 开发者工作环境的质量,例如可理解性、Tooling、反馈速度和本地可运行性。 |
| Diff | — | 展示两个文件或代码版本之间差异的形式。 |
| Discovery | — | 在实现之前理解并澄清问题、Requirements、开放决策、风险和技术背景的阶段。 |
| Distillation | — | 把较大模型的知识或行为迁移到较小模型中的技术。 |
| Diverge | — | 有意识地打开并探索多个解决路径、假设或选项的阶段。属于 Diverge · Decide · Converge,详见第 10 篇。 |
| DPA / AVV | Data Processing Agreement / Auftragsverarbeitungsvertrag | 用于规范数据处理方处理个人数据的合同;在德国通常称为 Auftragsverarbeitungsvertrag,简称 AVV。 |
| Drift | — | 系统经过多个决策或行动步骤——无论是在单次 Run 之内,还是跨越多次变更——逐步偏离期望规则、架构、语义或行为的现象。详见第 06 篇。 |
| DRY | Don’t Repeat Yourself | 避免不必要重复知识或逻辑的原则;并不意味着必须强行抽象所有相似之处。 |
| GDPR / DSGVO | General Data Protection Regulation / Datenschutz-Grundverordnung | 欧盟 GDPR 的德语缩写,规范个人数据保护及其处理。 |
| DTO | Data Transfer Object | 用于在系统部分或接口之间传输信息的数据结构,通常不包含自身业务逻辑。 |
| E2E | End-to-End | 跨多个系统部分覆盖完整流程的测试或观察方式。 |
| Embedding | — | 内容的数值向量表示,可用于计算语义相似度或关系。 |
| Engineering Capability | — | 个人或组织可靠地理解、开发、修改、验证和运行软件的能力。 |
| Eval | Evaluation | 依据定义好的任务、标准和测量方法,对模型或 Agent System 进行有针对性的评估。 |
| Evaluation Harness | — | 运行 Evals、提供 Tools 和环境、记录过程并评估结果的基础设施。 |
| Executable Architecture | — | 不仅写在文档里,而且可通过 Tools、Tests 或 Static Checks 机械验证的架构规则。 |
| Feedback Loop | — | 由执行、观察、验证和纠正组成的重复循环,用于逐步改进工作。 |
| File Boundary | — | 文件或存储访问层面的边界;它并不能自动保证同一信息不会通过其他路径被访问。 |
| Fine-Tuning | — | 在已有模型基础上继续训练,并有针对性地调整其参数。 |
| Fixed Cost | — | 不随后续使用次数直接变化的前期成本,例如 Agent Infrastructure 或自有硬件。 |
| Foundation Model | — | 经过广泛训练、可作为多种不同任务和应用基础的通用底层模型。 |
| Frontier Model | — | 非正式术语,指在某一时点处于公开或工业可用 AI 能力前沿的模型。 |
| Function Calling | — | 允许模型请求以结构化方式调用外部函数或 Tools 的机制。 |
| Generative AI | — | 能够生成文本、图像、音频、视频或代码等新内容的 AI 系统。 |
| GPU | Graphics Processing Unit | 并行计算处理器,因矩阵计算能力强而常用于 AI 模型的 Training 和 Inference。 |
| Ground Truth | — | 被视为正确的参考值或目标答案,用来评估模型或系统。 |
| Grounding | — | 把模型回答与具体外部数据、来源或系统状态关联起来,以限制纯粹基于“看起来合理”的生成。 |
| Guardrails | — | 用于限制 AI 系统不期望输入、输出或动作的技术或组织保护机制。 |
| Hallucination | — | 模型生成的看似合理、但实际错误或没有依据的输出。 |
| Happy Path | — | 没有错误、异常或特殊情况时的理想系统流程。 |
| Human Active Time | — | 人员必须主动分析、决策、解释、验证或纠正所花费的时间。 |
| Human Capital | — | 人的知识、技能、经验和判断力,作为长期经济资源。 |
| Human Review | — | 由人对结果进行检查,尤其适用于需要领域知识、责任承担或上下文判断的情况。 |
| Independent Evidence | — | 不会仅仅重复待验证结果所依赖的相同假设或生成路径的验证证据。 |
| Inference | — | 使用已经训练好的模型,根据输入计算输出的过程。 |
| Inference-Time Compute | — | 模型执行具体任务时投入的计算量,例如额外的 Reasoning。 |
| Information Boundary | — | 规定哪些信息可以离开某个领域、流程、Agent 或 Trust 区域的边界。 |
| Information Flow | — | 信息在来源、系统、Agents、Tools、存储和输出之间流动的路径。 |
| Information Hiding | — | 把内部决策和实现细节隐藏在稳定接口后的架构原则。 |
| Input Tokens | — | 进入模型请求的 Tokens,包括用户可见内容和系统补充的信息。 |
| Invariant | — | 无论具体变更如何,在系统中都应始终成立的规则或属性。 |
| Jailbreak | — | 通过特制输入尝试绕过 AI 系统安全或行为限制的行为。 |
| KI(德语 AI 缩写) | Künstliche Intelligenz | 德语“Künstliche Intelligenz”的缩写,也就是 AI;本系列主要使用国际上更常见的 AI。 |
| KV Cache | Key-Value Cache | 缓存 Attention 状态,以减少 Token 生成过程中重复计算的中间存储。 |
| Layer | — | 具有特定职责和明确依赖规则的架构层。 |
| Least Privilege | — | 安全原则:用户、Agent 或进程只获得完成任务所需的最小权限。 |
| Legacy System | — | 已经存在并通常长期演化的系统,其结构和依赖可能让变更更加困难。 |
| Lint / Linter | — | 不执行代码而根据预定义质量、风格或错误规则进行静态检查。 |
| LLM | Large Language Model | 处理 Token 序列并通常逐步生成新 Tokens 的大型语言模型。 |
| LLM-as-a-Judge | — | 使用一个语言模型来评估其他模型输出质量或正确性的方法。 |
| Local Evidence | — | 从现有 Repository 或系统中找到的示例、结构和规则,可作为 Agent 判断期望方案的本地证据。 |
| Local Inference | — | 在自有或自行控制的基础设施上运行 AI 模型。 |
| Local Model | — | 可在本地或自行控制的基础设施上运行的模型。 |
| Long-Horizon Agent | — | 能够在较长时间和大量步骤中持续处理复杂任务的 Agent。 |
| Machine Learning | — | AI 的一个分支,让模型从数据中学习行为模式,而不是由人把所有规则明确编程出来。 |
| Marginal Cost | — | 增加一个额外单位产生的成本,例如多一次 Agent Run 或多一项变更。 |
| MCP | Model Context Protocol | 开放协议,用于让 AI 应用以标准化方式连接 Tools 和外部数据源。 |
| Memory | — | 位于模型权重之外的持久化存储,之后可把其中信息重新带入当前 Context。 |
| Model | — | 经过训练的数学系统,用于处理输入并计算输出。 |
| Model Card | — | 描述模型能力、Evaluation、限制、风险和预期用途的文档。 |
| Model Review | — | 由另一个模型检查结果;有帮助,但并不自动独立于生成模型所采用的假设。 |
| Model Routing | — | 根据任务、风险、成本或所需能力选择不同模型或配置。 |
| Model Score | — | 模型在某个 Benchmark 上的分数;对于 Agents,结果可能强烈受到 Harness、Tools、Context 和 Compute 的影响。 |
| Module Boundary | — | 定义模块边界,规定哪些内部细节保持隐藏,以及其他部分可以通过哪些接口访问。 |
| MoE | Mixture of Experts | 由多个专家子网络组成的模型架构,每个处理步骤只激活其中一部分。 |
| Monorepo | — | 多个应用、Libraries 或 Services 在同一个 Repository 中统一版本化和管理的结构。 |
| Multi-Agent System | — | 多个 Agents 围绕子任务或共同目标协同工作的系统。 |
| Multimodal | — | 模型或系统处理或生成文本、图像、音频、视频等多种模态的能力。 |
| Noise | — | 不必要、无关或低质量的输出,会掩盖真正有用的信息。 |
| Non-Determinism | — | 相同或高度相似的输入不一定产生完全相同的解题路径或输出的属性。 |
| Open Source | — | 源代码在相应许可证下可访问、使用和修改的软件;在 AI 领域并不自动等同于 Open Weights。 |
| Open Weights | — | 模型的已学习权重可获得;这并不意味着训练数据、训练代码或完整流程也开放。 |
| OpEx | Operating Expenditure | 持续性的运营支出,例如 API 使用、电力、Hosting 或运维管理。 |
| Output Tokens | — | 模型在一次请求中生成的 Tokens。 |
| Paradigm Drift | — | 逐步偏离原本选择的架构或开发范式,转向其他竞争模式的现象。 |
| Parameters | — | 模型通过训练得到的数值参数,共同决定模型行为。 |
| Pass@1 | — | 衡量第一个生成的解决方案是否成功的 Benchmark 指标。 |
| Pass@k | — | 衡量 k 个生成尝试中至少有一个成功方案的概率的 Benchmark 指标。 |
| Path Dependency | — | 早期决策会影响后续可用解决路径和 Context 的特性。 |
| Personal Data | — | 与已识别或可识别自然人相关的信息。 |
| Post-Training | — | 基础 Pre-Training 之后的训练和调整阶段,例如用于行为、Reasoning、安全或任务专门化。 |
| Pre-Training | — | 基础训练阶段,模型从大规模数据中学习通用模式和能力。 |
| Privacy by Design | — | 从系统架构和设计阶段就纳入隐私保护,而不是事后补加的原则。 |
| Probabilistic | — | 描述输出基于概率分布的系统,因此相同输入不一定产生完全相同输出。 |
| Progressive Disclosure | — | 只有当信息或 Skills 对当前任务相关时,才将其加载进 Context 的原则。 |
| Prompt | — | 为一次具体处理提供给模型的输入或指令。 |
| Prompt Caching | — | 复用 Prompt 或 Context 中重复部分的已计算状态,以降低成本或延迟。 |
| Prompt Engineering | — | 设计模型指令和输入的工作;在 Agentic Systems 中越来越与 Requirements Engineering 和 Context Engineering 紧密结合。 |
| Prompt Injection | — | 一种攻击或非预期指令:Context 中的内容试图诱导模型执行违背用户或系统真实意图的动作。 |
| Pseudonymization | — | 用替代标识符替换或分离直接身份信息的处理方式;若仍可重新识别,数据仍属于个人数据。 |
| Quantization | — | 降低模型数值精度,以减少内存占用和计算量。 |
| RAG | Retrieval-Augmented Generation | 在生成前或生成过程中检索外部信息,并把它作为额外 Context 提供给模型的方法。 |
| Reasoning | — | 用于更系统地解决复杂任务的额外内部或显式处理步骤。 |
| Reasoning Effort | — | 控制模型在某项任务上投入多少计算或 Reasoning 资源的配置。 |
| Reasoning Model | — | 针对多步骤问题求解和更高 Inference 计算投入优化的模型称呼。 |
| Reasoning Tokens | — | 某些 API 单独统计的 Tokens 或计算步骤,用于内部 Reasoning,未必会完整显示为输出文本。 |
| Red Teaming | — | 通过有意的对抗性测试,主动寻找漏洞、错误行为或不希望出现的边界情况。 |
| Reinforcement Learning (RL) | Reinforcement Learning | 通过反馈或奖励信号来优化行为的训练方法。 |
| Repository | — | 使用版本控制管理的源代码、配置、Tests 和其他项目产物集合。 |
| Requirements | — | 规定系统或变更需要实现什么,以及必须满足哪些条件的业务和技术要求。 |
| Requirements Engineering | — | 系统化地获取、澄清、记录并验证系统或变更需求的过程。 |
| Responsibility Drift | — | 职责逐渐漂移,使代码或组件开始承担原本应位于其他位置的任务。 |
| Responsibility Verification | — | 不仅检查变更是否能工作,还检查它是否位于正确的业务或技术职责中。 |
| Retrieval | — | 为当前任务有针对性地查找并提供外部或已存储信息。 |
| Review | — | 由人或其他系统从正确性、质量、风险和系统兼容性等角度评估变更。 |
| Review Bottleneck | — | 变更生成速度超过其被合理检查和接受速度时产生的瓶颈。 |
| RLHF | Reinforcement Learning from Human Feedback | 使用人类偏好或评价作为信号,调整模型行为的 Reinforcement Learning 方法。 |
| ROI | Return on Investment | 投资产生的经济收益与投入成本之间的比例。 |
| Sampling | — | 从模型评估出的候选下一个 Token 中选择具体 Token 的过程。 |
| Scaffold | — | 围绕模型搭建的 Agent 或 Evaluation 结构的另一种称呼,常与 Harness 含义相近。 |
| Scope | — | 任务或变更的明确范围,包括明确不属于范围的部分。 |
| SCS | Self-contained System | 一种架构方式,将业务切分后的系统设计得尽可能独立,只通过清晰定义的集成点交互。 |
| Semantic Search | — | 基于语义相似性而不仅是完全相同词语进行搜索,通常依赖 Embeddings。 |
| Separation of Concerns | — | 有意识地把不同职责和问题类型分离的原则。 |
| SLM | Small Language Model | 对相对较小语言模型的非严格统称,通常针对较低成本、本地运行或专门任务进行优化。 |
| Solution Space | — | 一个问题原则上所有可能解决路径的集合;Requirements 和 Constraints 可以缩小这个空间。 |
| Specification | — | 对预期行为、某项变更或系统尽可能具体的描述。 |
| Static Analysis | — | 不运行代码而进行分析,例如检查类型错误、Lint Rules 或架构违规。 |
| Stop Condition | — | 预先定义的条件,一旦满足,Agent 停止自主工作并需要提问或人工决策。 |
| SWE | Software Engineering | 系统化设计、开发、验证、运行和持续演化软件的学科。 |
| SWE-bench | Software Engineering Benchmark | 使用真实 GitHub Issues 和 Repository 变更来评估 Coding Models 与 Agents 的 Benchmark 家族。 |
| SWE-bench Pro | — | 更困难的 SWE-bench 变体,覆盖更广的 Repository 和任务类型,更强调真实 Agentic Software Work。 |
| SWE-bench Verified | — | 由人工审核的 SWE-bench 子集,旨在减少有问题或含糊不清的任务。 |
| Synthetic Data | — | 人工生成、用于模拟或补充真实数据的数据,可用于 Training、Tests 或隐私保护等场景。 |
| System Prompt | — | 用于规定一次会话或应用中模型行为、角色和边界的高层指令。 |
| System Score | — | 对由模型、Harness、Tools、Context 和其他运行条件共同组成的完整系统进行评测得到的分数。 |
| TDD | Test-Driven Development | 在实现之前或紧邻实现之前编写测试,并让测试主动影响设计的开发方法。 |
| Technical Debt | — | 由于短期技术决策、缺少维护或有意推迟质量工作而产生的未来额外成本。 |
| Temperature | — | Sampling 参数,控制高概率 Token 相对于低概率选项被偏好的程度。 |
| Test-Time Compute | — | 模型使用阶段额外计算量的另一种叫法,与 Inference-Time Compute 基本相关。 |
| Token | — | 语言模型的处理单位,可以代表一个词、词的一部分、字符或其他文本片段。 |
| Token Budget | — | 为 Context、生成或一次 Agent Run 设定的最大或计划 Token 数量。 |
| Tokenizer | — | 把文本转换为语言模型处理的 Token IDs 的组件。 |
| Tool | — | 模型或 Agent 可调用的外部能力,例如文件访问、搜索、Shell、Browser 或 API。 |
| Tool Calling | — | 模型通过外部 Tools 触发结构化动作的机制。 |
| Top-K | — | 只在概率最高的 k 个下一 Token 候选中进行选择的 Sampling 方法。 |
| Top-P | Nucleus Sampling | 选择累积概率至少达到 p 的最小高概率 Token 候选集合进行 Sampling 的方法。 |
| Total Parameters | — | 模型参数总数,不论每次计算是否所有参数都被激活。 |
| Training | — | 使用数据和优化目标调整模型参数的过程。 |
| Trajectory | — | 记录 Agent 的观察、模型步骤、Tool Calls、动作和中间状态的完整执行路径。 |
| Transformer | — | 基于 Attention 的神经网络架构,对现代 LLM 的发展具有决定性影响。 |
| Trust Boundary | — | 不同信任或保护等级区域之间的边界,跨越该边界应被有意识地控制。详见第 09 篇。 |
| Unit Test | — | 针对软件中一个较小、尽可能隔离的单元进行的测试。 |
| Validation | — | 检查是否解决了正确的问题或实现了业务意图;实践中经常不会与 Verification 严格区分。 |
| Variable Cost | — | 随着使用量或产量增加而增长的成本,例如 API 或 Token 成本。 |
| Vector Database | — | 用于存储 Embeddings 等向量表示并支持相似度搜索的数据库。 |
| Verification | — | 检查有哪些可靠证据能够证明一项变更或主张是正确且可接受的。 |
| Verification Debt | — | 被推迟或缺失的验证工作,会在未来造成不确定性和额外检查成本。详见第 12 篇。 |
| Verification Diversity | — | 组合不同的验证方法,避免所有检查共享相同假设和错误类型。详见第 12 篇。 |
| Verification Surface | — | 一项变更在被负责任地接受之前,需要验证的全部方面。详见第 12 篇。 |
| Vibe Coding | — | 一种非正式开发方式,软件主要通过自然语言和 AI 生成代码完成;狭义上通常直接代码检查较少。 |
| VLM | Vision-Language Model | 同时处理视觉信息和语言的模型;这一术语越来越多用于多模态系统。 |
| VRAM | Video Random Access Memory | GPU 的显存;在本地 Inference 中,经常是限制模型大小和 Context 的关键因素。 |
| Wall Clock | — | 一个过程从开始到结束的真实经过时间,不论其中多少时间是人的主动工作时间。 |
| Weights | — | 神经网络训练得到的数值权重;在 LLM 日常语境中常几乎与模型 Parameters 同义。 |
| Workflow Lock-in | — | 当流程、Tools、数据和 Agent Infrastructure 与特定服务商或 Workflow 深度绑定后产生的更高切换成本。 |
| World Model | — | 对环境如何运作以及动作如何改变其状态的内部或显式表示。 |
更新:2026 年 9 月。本术语表按照这些概念在本系列和当前技术讨论中的实际用法进行解释。对于尚未标准化的术语,简要说明刻意采用实践性的定位,而不是规范性定义。