附录 A · 术语表
这不是一本词典，而是一张现场用语速查表。它只收本书正文涉及的概念与词，每条给一句话定义；标了「为什么关心」的，是实际项目中最容易被误解、或最容易让人踩坑的词。不同公司对同一个概念常有不同叫法，以你所在组织的定义为准。
使用说明
| 分组 | 你能在这里查到 | 主要出现在 |
|---|---|---|
| FDE 角色与交付 | 角色、阶段、能力与交付结果 | 第 1、3、6 章 |
| AI/LLM | 模型、提示、RAG 与评测 | 第 4、7、8 章 |
| 数据 | 数据地图、接入、质量与漂移 | 第 5、8 章 |
| 工程与云 | 接口、环境、发布与可观测 | 第 4、8 章 |
| 安全与合规 | 权限、注入、PII 与中国合规 | 第 4、8、10 章 |
| 商业与组织 | 价值、指标、采购与组织 | 第 5、9、10 章 |
三条使用建议：先查你正在做的阶段，不要从头背；看到一个词就回到对应章节看上下文；把你们团队自己的叫法补在旁边，术语表最大的价值是让团队说同一种话。
一、FDE 角色与交付
- FDE（Forward Deployed Engineer，前沿部署工程师）：嵌入客户现场、对业务结果负责的工程师，把模糊问题变成可验证系统并送上生产。→ 为什么关心：全书所有能力最终都落在这个角色上。
- 现场（field）：客户真实使用系统的环境，包含数据、流程和人。
- 现场五问：谁痛？痛多大？现在怎么解？为什么是现在？谁为结果买单？→ 为什么关心：答不全，项目就不该立项。
- 六阶段：发现 → 定义 → 原型 → 试点 → 生产 → 移交与规模化。
- FDE 部署飞轮：现场发现 → 窄场景验证 → 生产闭环 → 产品反哺 → 规模化。
- 能力罗盘：工程力、业务力、产品力、现场力四维能力模型。→ 为什么关心：用它定位短板，比什么都学一点有效。
- L1–L4（跟随 / 独立 / 主导 / 定义）：能力罗盘的四级行为标准。
- 三种 FDE（产品型 / 伙伴型 / 内部型）：分别把现场发现变成平台能力、在服务商里交付客户项目、在企业内服务业务部门。
- 价值证据金字塔：Demo < Pilot 指标 < 生产 KPI < 业务结果 < 合同与续约。→ 为什么关心：你在哪一层，决定客户信你几分。
- 概念验证（PoC, Proof of Concept）：用最小成本证明方案可行。
- 试点（Pilot）：小范围、有指标、有退出标准的真实验证。→ 为什么关心：试点不是缩小版上线，要回答值不值得继续。
- 生产（Production）：真实用户、真实数据、有值守和回滚的运行状态。→ 为什么关心：Demo 与生产之间隔着一整套工程。
- 移交（Handover）：把系统、文档和责任交给客户团队或内部团队。→ 为什么关心：交接做不好，信任会一次还回去。
- 规模化（Scale）：把一次成功复制到更多场景、团队或客户。
- 产品反哺（product feedback）：把现场解法沉淀成产品需求或平台能力。→ 为什么关心：这是 FDE 与驻场外包最本质的差别之一。
- 退出标准（exit criteria）：进入下一阶段前必须满足的条件，通常写成 Go/No-Go。
- 砾石路与高速公路：先在现场铺一条能走的砾石路，再把反复走的路径修成平台的高速公路。
二、AI / LLM
- 大语言模型（LLM, Large Language Model）：用海量文本训练、能按上下文生成文本的模型。
- token：模型处理文本的最小计费与长度单位，约等于半个到一个汉字。→ 为什么关心：成本、时延和上下文上限都按它算。
- 上下文窗口（context window）：模型一次能「看到」的 token 上限。
- 提示词（prompt）：你发给模型的指令与上下文。
- 少样本提示（few-shot）：在提示词里给几个输入输出示例，让模型照做。
- 检索增强生成（RAG, Retrieval-Augmented Generation）：先检索资料，再让模型基于资料回答。→ 为什么关心：企业知识类需求的第一方案，能降幻觉、给来源。
- 向量与向量检索（embedding / vector search）：把文本映射成数字向量，再用相似度检索相关资料。
- 工具调用（tool calling / function calling）：让模型输出结构化的调用参数，去触发外部函数或接口。
- 智能体（Agent）：能自己规划步骤、调用工具、根据结果继续行动的系统。→ 为什么关心：上限由工具和评测决定，不只由模型决定。
- 微调（fine-tuning）：用自有数据继续训练模型，让它更贴合特定任务。→ 为什么关心：数据少、需求变得快时，先想 RAG 和提示词。
- 幻觉（hallucination）：模型编造看似合理但不真实的内容。→ 为什么关心：对外输出都需要引用、校验或人工复核。
- 评测集（黄金集，golden set）：一组人工确认过标准答案的样本，用于回归比较。→ 为什么关心：没有它，改完提示你无法证明变好还是变坏。
- LLM-as-judge：用另一个模型按评分标准批量评判输出。
- 分层抽样（stratified sampling）：按类别、难度或来源分层取样本。
三、数据
- 数据地图：记录数据在哪、谁负责、多久更新、质量如何、怎么接入的一页表。→ 为什么关心：项目卡住，多半卡在数据地图没画清。
- 源系统（source system）：数据最初产生的地方，如工单系统、ERP、CRM。
- 数据 owner（数据负责人）：对某个数据集的质量、权限和使用负责的人。→ 为什么关心：没有 owner 的数据，默认不可用。
- 数据可用性评分卡：按完整性、时效性、一致性、权限、接入难度给数据打分。
- 数据质量与清洗：处理缺失、重复、格式不一、口径冲突等问题。
- 数据接入（ingestion）：把数据从源系统取到可用环境的过程。
- 数据管道（data pipeline）：数据从源端到消费端的自动流转链路。
- 结构化与非结构化数据：前者是表格和字段，后者是文本、图片、文档。
- 标注（labeling）：给数据打上标准答案，如分类标签、抽取结果。
- 标签体系（分类体系）：业务上互斥、穷尽、有层级的一套分类。→ 为什么关心：分类任务的效果上限，常由标签体系决定。
- 数据漂移（data drift）：线上数据分布随时间偏离训练或评测时的分布。→ 为什么关心：不监控漂移，指标会悄悄下滑。
四、工程与云
- HTTP 与 API：HTTP 是网络请求协议，API 是系统之间约定好的调用接口。
- JSON：一种键值对文本格式，是接口和模型输出最常见的载体。
- 命令行（CLI）：用文本命令操作文件、服务和日志的界面。
- Git：代码版本管理工具。
- SQL：查询和操作关系型数据库的语言。
- 环境（environment）：开发、测试、预发、生产等相互隔离的运行空间。→ 为什么关心：用生产环境做实验，是最贵的一类事故。
- 环境变量与密钥（secret）：把配置和密码放在代码之外的管理方式。→ 为什么关心：密钥进了 Git，等于把门钥匙贴在门口。
- 容器（container，如 Docker）：把应用和依赖打包成可一致运行的镜像。→ 为什么关心：客户环境的差异，靠容器才能压到最小。
- CI/CD：持续集成与持续交付，自动完成构建、测试和部署。
- 日志（log）：系统运行时记录的事件与上下文。
- 可观测性（observability）：通过日志、指标和链路追踪（trace）理解系统内部状态的能力。→ 为什么关心：AI 系统的问题往往不报错，只是答得不对。
- 告警与值班（alert & on-call）：指标越界时自动通知，由值班人按流程处理。
- 灰度发布与回滚：先放量给小部分用户，出问题快速切回旧版本。→ 为什么关心：上线前最该先做的两件事。
五、安全与合规
- PII（个人可识别信息，Personally Identifiable Information）：能直接或间接识别到某个人的信息。→ 为什么关心：进模型的每一行数据，先问是不是 PII。
- 脱敏（data masking）：在保留可用性的前提下遮蔽、替换或聚合敏感字段。
- 最小权限原则与默认拒绝：只给完成任务所需的最小权限，没有明确允许的一律拒绝。→ 为什么关心：AI 能调工具时，权限就是攻击面。
- 提示注入（prompt injection）：把恶意指令藏进文档或网页，诱导模型越权行动。→ 为什么关心：只要模型读外部内容，就假设它会被注入。
- 越权：用户通过系统拿到了本不该访问的数据或操作。→ 为什么关心：RAG 检索也要按用户权限过滤，不能只靠提示词。
- 审批疲劳（approval fatigue）：审批太多导致人机械点「通过」，防线失效。
- 红队（red teaming）：主动模拟攻击，找系统的安全与质量漏洞。
- 审计日志（audit log）：记录谁在何时做了什么操作、且不易被篡改的日志。
- 数据不出域：数据不离开指定的地理或网络边界。
- 私有化（on-premise）：把系统部署在客户自己的机房或云账户里。
- 信创：信息技术应用创新的国产化替代要求，涉及芯片、操作系统、数据库等。
- 中国 AI 合规四件事：数据安全法、个人信息保护法、生成式 AI 服务管理暂行办法、网络安全等级保护。
六、商业与组织
- ROI（投资回报率，Return on Investment）：收益与投入的比值，通常按年化计算。
- 基线（baseline）：项目开始前的现状指标。→ 为什么关心：没有基线，所有提升都无法证明。
- KPI 与领先 / 滞后指标：KPI 是结果指标；领先指标（leading）先动，滞后指标（lagging）后动、事后确认。→ 为什么关心：试点阶段主要看领先指标，否则等不到结果。
- 归因（attribution）：判断指标变化中有多少由你的方案带来。
- 经济买家（economic buyer）：真正有权批准预算、为结果买单的人。→ 为什么关心：找到他，项目才可能从试点走到合同。
- 干系人地图：记录每个相关角色的关注点、影响力、态度与接触策略。→ 为什么关心：项目失败常因为漏了一个能说不的人。
- 项目章程（project charter）：一页纸写清问题、目标、范围、角色、里程碑与退出标准。
- 项目治理与风险登记：周会、风险清单、变更审批、升级路径等机制，以及风险的概率、影响、负责人和应对动作。
- 范围蔓延（scope creep）：需求不断增加，而范围和验收标准不更新。→ 为什么关心：试点失败最常见的原因，没有之一。
- 验收标准（acceptance criteria）：双方确认的、可测量的交付合格条件。→ 为什么关心：验收标准模糊，最后一定会吵。
- NRR（净收入留存率，Net Revenue Retention）：老客户续约与增购带来的收入留存比例。
- 按结果收费（outcome-based pricing）：按实际解决的业务量或结果计费。
- 灯塔客户（lighthouse customer）：愿意共同打磨、能产生示范效应的标杆客户。
- 项目制采购与人天模式：前者按项目立项、招标、验收、付款；后者按投入人力天数计费。→ 为什么关心：前者定回款节奏，后者天然鼓励待着。
- 驻场外包（staff augmentation）：按人头补位、按工时计费的外包模式。
- 真空层：大项目中真实使用方与决策层之间信息失真的中间层。→ 为什么关心：不穿透它，你会在错误的指标上验收。
小结
- 术语只在语境里有意义：同一个词在客户嘴里、在合同里、在技术方案里可能指三件事，先对齐定义再讨论方案。
- 这张表覆盖的是本书的工作语言；更细的 AI 技术词、云产品名不在收录范围内，遇到时查官方文档。
- 如果你的团队有内部黑话，最值得做的一件事是把它翻译成本表里的词，写进项目章程。
说明：本术语表由本书作者根据正文用法整理，英文写法采用行业通用形式，不引用外部词典。不同组织对同一概念可能定义不同，一切以你所在项目的书面约定为准。术语与正文不一致时以正文为准；欢迎在 GitHub 提 Issue 纠错。相关页面：附录 B · 模板工具箱 · 附录 C · 案例与资料来源 · 附录 D · 常见问题。