前 言
过去几年，大语言模型的能力提升很快。代码生成、合同阅读和专业问答等能力，已经可以通过标准化接口接入应用系统，模型服务的获取成本也在下降。按理说，企业采用这类技术的门槛应当随之降低；但在实际项目中，能够从演示阶段进入日常业务流程的试点仍然不多。问题通常不只在模型本身：数据分散在彼此独立的系统中，同一指标在不同部门有不同口径，掌握审批权的人对新系统缺乏信任，系统上线后也没有明确的指标和证据说明它究竟改善了什么。
这类工作过去常被归入“实施”或“项目交付”，在传统软件工程分工中没有得到充分讨论。生成式人工智能的普及，使它成为决定项目能否落地的关键环节：工程师需要理解客户真正要解决的问题，让模型在权限可控的条件下使用企业数据和文档，验证系统是否完成了业务要求，并在出现错误时及时发现、转交人工处理和修正。产业界通常把承担这类工作的工程师称为前线部署工程师（Forward Deployed Engineer，FDE）。本书讨论的，正是这一角色所需要的工程方法。
一、为什么以交付为中心
FDE 这一角色通常被认为最早在 Palantir 等公司的客户项目中成形。公司为情报机构和大型企业建设数据平台时发现，客户的业务流程、数据环境和既有系统各不相同，产品的通用能力与现场需求之间往往存在差距；这段差距需要工程师深入客户环境，通过配置、集成和定制开发来弥合。近年来，模型公司和企业软件公司也出现了类似团队。它们的共同特征是：工程师深入客户的业务环境，交付运行在客户系统中的软件，工作成效由业务结果和系统运行指标衡量，而不是由功能清单是否完成来衡量。
围绕这一岗位，已有不少书籍和文章讨论它的来源、招聘、定价和职业发展。这些问题并非没有价值，但对于希望掌握这门工程实践的学生和工程师，更直接的问题是：进入陌生部门后，第一周应当做什么？怎样判断客户提出的需求背后是否存在更根本的问题？什么情况下应当使用大语言模型，什么情况下规则、普通函数或一条 SQL 查询已经足够？怎样让模型在权限边界内查询数据库、读取文档？怎样证明系统上线后确实产生了业务价值？又怎样把系统交给客户团队继续维护？本书围绕这些问题组织内容。
由此形成了本书的取舍原则：每种方法都必须落实为一份可检查、可运行或可复用的交付物（artifact）。每章都要求读者在同一案例上完成一项交付，可能是一份范围说明书、一套评估集、一个可运行的服务、一份安全测试报告，或一份移交手册。作者反复用一个标准检查论述是否足够具体：如果删去代码、数据和评估脚本，剩下的内容仍然可以原样成立，那么这一章很可能只是在讲抽象道理，需要补足工程约束和验证方法。
在这些交付物中，评估集具有特殊地位。传统软件通常可以用确定性的测试检查行为；大语言模型的输出会受到模型版本、提示内容、上下文和采样设置等因素影响，同一个回答在演示环境中看似合格，放入具体业务流程后可能并不适用。因此，评估贯穿全书：在构建系统之前，先与业务人员约定什么算正确、哪些错误可以接受、哪些情况必须转交人工；每增加一项能力，都用同一套标准进行回归检查；系统上线后，再持续抽查质量是否发生变化。
本书的另一条原则是先用确定性方法，再使用模型。凡是规则、查询或普通函数能够稳定完成的工作，都不交给模型处理；只有当步骤无法完全预先确定时，才考虑使用智能体。这样做不是为了限制模型，而是为了让系统更容易测试、审计和交接，这些条件决定了企业软件能否长期运行。书中会提到一些具体产品和协议，但它们只用于说明一般性的工程问题。由于模型、框架和接口变化较快，正文尽量讨论不依赖具体版本的设计原则，操作细节放在附录和配套代码仓库中。
这种取舍也意味着不回避失败。书中将讨论 AI 项目常见的失败方式，以及何时应当缩小范围，甚至停止项目。一名合格的 FDE，需要能够明确告诉客户某个场景暂时不适合使用 AI，同时说明当前可以先完成哪些工作。
二、贯穿案例：合众通信
为了让各章的方法落在同一个具体场景中，本书构造了一家虚构的移动通信运营商：合众通信。案例发生在其东部区域分公司。该区域约有 800 个基站站点和 30 个传输汇聚机房，网元分为无线基站设备、传输设备、动力与空调设备三类。运维人员约 40 人，网络运维中心实行 7×24 小时监控，外场维护班组负责上站处理故障；与网络运维相关的部门还包括网络规划部、采购部、信息技术部和财务部。书中的公司、人物、编号和数据均为虚构，不对应任何真实运营商或城市。数据全部为合成数据，但按真实企业数据的方式组织，并保留了企业数据中常见的不一致和缺失。
与网络运维相关的数据分散在多个系统和文件中。故障工单和网络资源台账存放在关系数据库中，部分工单由客户投诉触发；网管系统持续产生告警事件，并以 15 分钟为粒度记录小区可用率、掉话率、机房温度和电源电压等性能数据；备件库存由独立的旧系统管理。厂商提供的设备维护手册和维保合同以 PDF 文件保存，基站巡检报告包括手写表格扫描件和现场照片，外场工程师上站时还会录制语音笔记。这些系统由不同部门在不同阶段建设，彼此之间缺少统一接口。
读者会在书中反复遇到几位人物。网络运维中心主任 Tom 是项目发起人，负责预算；值班主管 Alice 负责故障调度和工单跟进；资深外场维护工程师 Bob 上站经验最丰富；信息技术部负责人 David 管理企业系统、账号权限和安全审查；采购部专员 Emma 负责备件采购和厂商维保合同；财务分析师 Frank 负责成本及投入产出核算。承担项目的工程团队称为“FDE 小组”，读者可以把自己看作其中一员。第一次会议上，Tom 提出的需求是：“希望用 AI 预测基站故障，减少网络中断。”判断这句话是否准确描述了合众通信真正需要解决的问题，是 FDE 小组进场后的第一项任务。
从第 3 章开始，各章在这家企业的数据上逐步叠加交付物。前面章节留下的问题，会在后续章节中暴露出来，这与真实项目的推进方式相似。到全书结束时，读者交付的是一套工作系统：它能够查询工单、网元和库存数据，从有人负责并按版本维护的知识库中检索设备维护手册并给出引用，关联告警、工单与备件，生成带有证据引用的故障复盘报告，在写入企业系统前请求人工批准，并输出运行指标和交接手册。最终成果不是一个聊天机器人，而是一项可验证、可运行、可交接的业务能力。
选择电信网络运维作为案例，并不要求读者具备通信专业背景。书中涉及的领域知识只用于理解业务对话，不展开无线或传输原理。这类场景在能源、交通、制造和公用事业等行业具有相似结构：设备分布在不同地点，告警、工单、备件和合同分散在多个系统中，现场经验掌握在少数资深工程师手里。面对陌生行业，如何在第一周建立术语表、厘清指标口径、画出数据流向，本身就是 FDE 需要训练的能力，第 3 章将专门讨论这一点。
三、阅读路径建议
全书分为七篇，按照一次真实交付的顺序编排。第一篇（第 1、2 章）说明企业 AI 为什么难以落地，以及 FDE 的职责与工作流程。第二篇（第 3 至 6 章）讨论问题发现与证据，包括需求发现与现场观察、价值指标与现状基线、评估集与验收门槛，以及方案选型。第三篇（第 7、8 章）介绍模型调用与结构化输出，并做出第一个可运行的版本。第四篇（第 9 至 14 章）把企业数据库和文档接入系统，讨论数据契约、自然语言查询数据库、文档解析与信息抽取、企业知识库建设与治理、检索增强，以及跨系统的实体与证据链。第五篇（第 15 至 17 章）讨论工具调用与 MCP、工作流与智能体、微调与小模型。第六篇（第 18 至 22 章）讨论系统集成与权限、安全与合规、容量与发布门禁、监控与事故处置，以及私有化与离线部署。第七篇（第 23 至 26 章）回到价值本身，讨论效益量化与因果验证、用户采纳与流程改造、运维移交与组件沉淀，以及失败案例与停止条件。
第一篇至第三篇是全书的基础。这部分默认读者能够编写中等规模的 Python 程序，会用 SQL 做多表查询，熟悉版本控制和单元测试，了解机器学习的基本概念，但不要求有大模型应用的开发经验。第一次系统学习这一领域的读者，包括计算机相关专业的高年级本科生和研究生，适合从头按顺序阅读，并完成每章的实验与习题。实验和习题的设计，也便于将本书用作高校相关课程的教材。
已经在企业从事 AI 应用开发的工程师、解决方案架构师和技术负责人，可以先读第二篇，建立问题发现与评估的框架，再根据手头的工作选择第四篇至第六篇的相关章节。第七篇讨论的价值核算、用户采纳与交接，是多数技术资料很少涉及、却常常决定项目能否推广的内容，也可以优先阅读。第 17 章和第 22 章是选读章，分别讨论微调与小模型、私有化与离线部署；第 11 章最后一节讨论语音与图像处理，也属于选读内容。跳过这些内容不影响后续章节的阅读。
各章的结构基本一致。章首导读说明本章要解决的现场问题，以及它与上一章交付物的衔接；正文穿插合众通信案例；技术章节各有一个完整实验，其中包括评估方法和故障注入，即有意制造脏数据、越权访问、模型返回格式错误或资料互相矛盾等情况，检验系统能否作出正确反应。只在顺利情况下验证过的系统，离生产环境还很远。章末附有习题，并列出本章交付物；延伸阅读统一列在书末。
四、配套资源与说明
全书实验共用一个配套代码仓库，其中包含合众通信的合成数据，以及每章实验的起始代码、参考实现和自动化测试。实验环境由 Python、PostgreSQL、对象存储、开源 OCR 引擎和容器编排工具组成。每个实验都提供云端和本地两个版本：云端版调用商用模型接口，便于观察接近企业部署条件的效果；本地版运行开源小模型，不消耗接口额度，也适合网络受限的环境。两个版本的效果和资源需求并不等价，实验说明会明确标出差异；这些差异也可作为第 6 章和第 17 章讨论方案选型的依据。安装步骤和版本说明见附录 A 及仓库说明文件。
记录实验结果时，本书要求区分不同证据等级：哪些结果是在明确记录的条件下实际观测到的，哪些只是计划中的假设，哪些来自特意构造的模拟数据，哪些通过了预先定义的检查，哪些得到有权限人员对特定版本的验收，哪些仍然缺少证据。这种区分对应交付工作中常见的争议，例如本地运行成功是否等于完成，客户口头认可是否等于验收。本书把证据条件写进实验和交付物，而不把不同性质的结论混在一起。
写作过程中，作者参考了多部关于前线部署工程和企业 AI 交付的著作，包括Nasser Ghanemzadeh、Phil Brennan 等作者的作品。书中借鉴的是这些著作中的方法框架和问题结构，完整书目列在书末；案例的情节、人物和数据均已改写为本书的贯穿案例。官方规范、论文和调研报告等外部资料，列在书末的延伸阅读中。
本书写于 2026 年。模型、框架和接口变化较快，涉及具体版本的内容均注明“截至写作时”，例如第 15 章的 MCP 示例基于 2026 年 7 月发布的规范版本。配套仓库会随版本更新，正文则尽量建立在不依赖具体版本的工程问题和设计原则之上。