一个企业提出要做知识库。销售把它记成商机，产品经理拆成文档上传和智能问答，工程师接好向量数据库。等系统完成，团队才发现同一份制度有多个版本，没有人能确认哪份有效，普通员工还能检索到特殊客户的价格。
每个人都完成了自己的任务，客户的问题却还在那里。
Forward Deployed Engineer（FDE，前线部署工程师）要持续看住从问题到结果之间的断点。他未必要独自包办销售、产品、架构、研发、实施和客户成功，但必须看见整段工作：当前缺的是业务负责人、真实数据、模型能力、系统权限，还是上线后的使用意愿。需要专业人员加入时，他还要把问题讲到对方可以行动的程度。
AI 扩大了 FDE 可以亲手负责的范围。它能协助查资料、整理访谈、画原型、生成代码、补测试、维护文档，也能把几个月的项目记录变成可检索的上下文。判断客户是否值得投入、系统能否上线、风险由谁承担，仍然由 FDE 和项目负责人决定。
这篇文章先给出一张完整能力地图。后续系列会分别展开客户筛选、流程调查、方案设计、RAG、Agent、MCP、模型部署、发布运维、企业培训和项目交接。
AI 让 FDE 接住更多职能
传统软件项目通常分工明确：销售负责合同，售前准备方案，产品经理拆解需求，研发编写代码，实施人员推动上线，客户成功关注后续使用。成熟业务可以这样协作，因为问题、产品和交付方式已经相对稳定。
企业 AI 项目刚开始时，问题、数据和技术路线经常同时变化。每转交一次，现场信息都可能少一层。客户说「要做 AI 客服」，真实问题可能是客服反复回答同一批问题，也可能是制度更新太慢，或者用户找不到正确入口。三种问题都能做成聊天窗口，背后的数据、权限、风险和验收方式完全不同。
架构与研发经验能帮助 FDE 判断系统边界、数据流、集成方式、模型能力和部署条件。AI 工具又把这种能力延伸到调研、沟通和交付。如果视线停在准确率、延迟和吞吐量，项目仍可能做成一个运行流畅却没人使用的演示系统。
FDE 的价值来自连续责任。AI 可以承担更多准备工作，FDE 因而可以减少等待不同职能依次交接的时间，但不能把未经确认的判断当成事实，也不能把生成结果当成发布证据。
先筛选客户，再讨论技术
客户选错以后，技术能力越强，投入越容易被放大。筛选时可以先看四个条件：
问题是否正在产生可观察的时间、成本、收入或风险代价；
客户内部是否有人对结果负责，并有权协调参与者；
团队能否接触真实流程、真实数据和真实用户；
第一阶段能否缩小到几周内验证的一项工作。
我碰到过一开始就想做「全公司 AI 改造」的企业。继续追问第一批用户、当前数据、配合部门和验收方式时，没有人能确认。另一些团队的目标很小，只想缩短一项重复工作，负责人却愿意提供真实样本，也愿意每周参与评测。后者的预算未必抢眼，项目反而更容易推进。
预算表达愿望，日常工作暴露准备度。适合 FDE 进入的客户通常已经在解决某个问题，只是当前办法太慢、太贵或走不通。FDE 帮助这项工作变得更有效，而不是独自推动整家公司改变。
这一步需要行业理解和商业判断：预算来自哪里，错误由谁承担，流程改变后谁受益，谁会增加工作，谁可能失去原来的决定权。这些答案不在技术文档里，却决定技术能否进入生产。
把沟通变成工程输入
会议纪要不足以成为工程输入。FDE 要把不同角色的话翻译为同一张工作图：谁在什么时候收到什么输入，打开哪个系统，根据什么作判断，遇到例外找谁，结果写到哪里。
正式流程往往省略真实接口。工作人员可能在群里催数据，用个人表格补系统，在正式审批前先打一通电话。这些绕路暴露了数据从哪里来、决定怎样发生、哪些例外没有进入系统，也是 AI 项目必须处理的部分。
AI 可以准备访谈问题、整理记录，并把内容初步分成事实、判断、假设、决定和待确认项。最后的确认仍要交给拥有相应信息或权限的人。
我在早期项目里踩过一个坑：团队太相信「大家都知道这件事」。等范围发生争议，几个人翻遍群聊，才发现每个人记得的版本不同。后来我开始用 Markdown 管理项目记忆：原始材料单独保存，AI 只能提出更新建议；事实、决定、风险和负责人进入正式文件前，要标明来源和确认状态。
这些文件逐渐成为项目控制面。客户何时同意缩小范围，一项技术选择基于什么条件，哪项风险仍没有负责人，都要留下记录。信息只存在于聊天记录时，AI 记得再多，也只是帮助团队更快翻旧账。
把方案压成可以验证的决定
一次沟通可能留下几千字记录，仍然回答不了「第一阶段做什么」。交付方案至少要确定：
当前工作怎样运行；
第一阶段只改变哪一步；
谁会使用这项能力；
什么证据表示它有效；
哪些内容本轮明确不做；
双方分别提供什么；
何时转人工处理，什么条件下停止。
我遇到过希望覆盖多个部门的平台项目。跟着真实流程走过一遍后，团队发现最痛的只有其中一个环节。删掉大平台，先处理一项每天发生、几周内可以验证的工作，用户、输入和错误影响才真正变得清楚。「提升企业智能化水平」也终于变成可以验收的工作变化。
方案阶段要提前检查技术假设：扫描 PDF 能否稳定解析，CRM 接口是否支持目标写入频率，受限资料能否按用户身份隔离，模型出错后谁来接管。暂时无法确认的内容应写成假设，并配一个成本尽量低的实验和截止时间。
架构图说明系统准备怎样搭。交付方案还要解释为什么值得搭、做到哪里停止，以及什么证据允许它继续进入生产。
技术能力必须走到生产
我的主要工作一直是架构设计和软件研发。开始承担 FDE 职责后，这些经验帮助我从系统边界、数据流、集成实现、发布和运维观察问题，也让我更清楚模型效果只是系统的一部分。企业 AI 交付还要同时处理知识、应用、工具、权限、基础设施、评测、发布和运维。
FDE 可以与专业团队协作，但自己至少要能做出端到端版本，并判断问题发生在哪一层。
RAG 先处理错误的知识
企业知识库最先要处理文档本身，向量数据库可以晚一点选择。
同一份制度可能有多个版本，文档没有 Owner，特殊价格混在普通资料里，扫描件解析后丢失表头和脚注。这些内容直接进入 RAG，模型回答越流畅，错误越难被察觉。
文档应先补齐版本、生效时间、Owner、权限和原文位置，再处理状态过滤、去重和召回。关键词检索适合产品编号、条款号和精确名称，向量检索适合语义相近内容，必要时再做融合排序。答案要保留证据；资料不足、版本冲突或用户无权查看时，系统应停止回答。
评测除了比较答案，还要检查引用的是否为当前版本，证据是否支持结论，权限是否泄露，以及系统是否在应该拒答时拒答。模型、切分方式或检索策略变化后，同一批真实问题要重新执行。
Agent 和 MCP 接通工具后才开始处理风险
让模型查询客户、生成摘要并调用写入接口，很快就能完成一个 Agent 演示。进入企业后，还要继续回答：这次调用代表谁，能访问哪个租户，写入前是否需要审批，参数是否有上限，超时重试会不会重复写入，出错后能否审计和撤销。
MCP 统一工具与数据的描述、发现和调用方式，认证、授权、租户隔离与业务审批仍由具体系统实现。身份、scope、幂等键和资源归属要由服务端检查。模型生成一句「审批已通过」不产生授权效力；外部文档中的操作指令也只能作为不可信数据处理。
这条边界可以概括为：AI 负责理解、提议和规划，确定性代码检查可编码的规则，人对高风险动作作出授权。
API 或本地部署要回到真实负载
「数据不出域」不能直接推导出采购机器，「外部模型能力更强」也不能直接推导出调用 API。部署选择需要拆成具体问题：哪些数据不能离开内部环境，脱敏后是否可以，峰值并发多大，输入输出多长，延迟要求是什么，故障可以持续多久，谁负责升级和夜间运维。
模型大小不能替代任务评测。一台机器跑通，也不能证明大量员工同时使用时仍然稳定。压测要使用真实输入长度、目标硬件和并发曲线，观察首字延迟、整体吞吐、显存、排队与失败恢复。
成本比较要覆盖每个合格任务的总成本。API 成本包含多步调用、长上下文、缓存和业务增长；本地部署包含闲置容量、冗余、电力、升级、安全和运维人力。只比较 API 单价和显卡价格无法支持业务决定。
很多企业最后会采用混合部署：敏感资料和检索留在内部，通用能力调用外部模型，高风险任务保留本地模型或人工审核。方案不必形式整齐，只要符合真实约束。
上线前必须允许系统说「不行」
发布时，我会把应用、模型、Prompt、知识索引、工具和策略视为一个完整版本。产品、安全和运维分别确认，回滚目标提前写清，核心制品执行哈希校验，关键测试重新运行。
一次发布检查中，我并行运行了多组检查，生产门禁第一次拦住了发布。按既定发布顺序单独执行后，制品和依赖测试才全部通过。我没有继续猜测第一次失败的原因，只保留了可以证明的结果。
这件事对应真实上线的基本要求：工程师说「刚才在本地跑过」不构成发布证据。生产需要固定制品、可重复顺序、明确审批和真正演练过的回滚。
上线后还要观察质量、延迟、费用、工具调用和人工接管。用户报告答案错误时，应能追溯当时的模型、知识版本和证据；工具写错数据时，应能确认谁发起、谁批准、参数是什么。缺少这些信息，团队只能靠猜测处理事故。
技术上线以后，还要推动组织采用
我做企业内部沟通和培训时发现，员工放弃新工具通常有更具体的原因。入口可能离原有工作太远，多了一次复制粘贴；系统连续出错后，使用者失去信任；工具替一线人员节省时间，却给主管增加审核任务；也有人担心经验进入系统后，原来的职责和位置会变化。
培训要让不同角色用自己的任务练习一次，知道什么时候可以采纳结果，什么时候应该停止，反馈交给谁处理。业务专家还要参与评测，因为「什么叫答对」本来就掌握在他们手里。模型能力和功能操作只是其中一部分。
FDE 要把系统放进原有工作入口，让真实用户参与修改。错误发生时及时承认和处理，保留人工接管，并让使用者看见反馈怎样进入下一版。技术上线和组织采用是两项不同工作，FDE 要持续做到后者发生。
客户能够独立运行，交付才结束
项目验收后，如果客户遇到故障仍然只能在群里寻找原工程师，交付就没有结束。
交接材料应覆盖架构与数据流、部署与回滚、评测证据、安全权限、资料和数据 Owner、已知限制、事故手册、培训和支持边界。文档完成后，还要让客户团队独立发布一次、更新一次知识、处理一次模拟故障，再完成回滚。
FDE 在旁边观察，不替客户操作。只有客户亲自走完，交接中的空白才会暴露：某条命令依赖个人电脑，某个账号仍由外部团队掌握，某项评测只有原工程师知道怎样解释。
每次实践都要让下一次更轻
如果每个客户都从空白代码和空白文档开始，FDE 很快会变成昂贵的驻场开发。
一次实践结束后，可以复用的未必是客户代码。问题发现方法、行业对象模型、连接器、评测结构、权限策略、发布检查和交接模板，都能成为下一次工作的基础。
架构与研发经验让我能把一套技术方案设计出来、实现出来并带到生产。FDE 进一步要求我把客户、流程、工程、上线和采用连接起来。反复出现的判断和工具必须留下，下一次交付才能减少从头开始的工作。
一名 FDE 需要懂什么、会什么、做到什么
| 能力范围 | 需要理解 | 需要亲手完成 | 完成证据 |
| 客户与业务 | 行业对象、成本来源、利益关系、客户准备度 | 筛选问题，找到负责人，确认真实代价 | 明确的 Owner、样本、基线和验证窗口 |
| 流程与产品 | 正式流程、实际动作、例外、权限与采用阻力 | 访谈、观察、定义范围、写出非目标 | 可验收任务、责任分工、停止条件 |
| 知识与模型 | 文档治理、检索、生成、评测和拒答 | 搭建 RAG，建立真实评测集，追溯证据 | 版本、引用、权限和失败样本可检查 |
| Agent 与工具 | MCP、Workflow、身份、授权、幂等与审计 | 接入工具，设置审批与重试，验证结果 | 每次动作可归因、可限制、可恢复 |
| 部署与生产 | 负载、延迟、吞吐、成本、安全和运维 | 压测、发布、观测、告警与回滚 | 固定制品、门禁记录、运行指标和演练结果 |
| 组织与交接 | 角色变化、培训方式、支持边界与所有权 | 推动真实使用，让客户独立运行和恢复 | 使用反馈、独立操作记录、完整事故手册 |
| 产品复用 | 共性问题、维护成本和通用边界 | 整理方法、模板、连接器和公共能力 | 下一次项目减少重复调查与重复实现 |
这张表用于定义责任视野，不作为招聘 JD，也不要求一个人永远独立完成所有工作。FDE 应知道何时自己动手，何时邀请专业人员，以及用什么证据判断工作真正完成。
后续系列会从「怎样判断第一个客户是否值得做」开始，把每一项能力拆到可执行的方法、交付物和验收标准。
