随着AI技术的兴起，近些年有一个岗位被反复提起：前沿部署工程师（Forward Deployed Engineer, FDE）。这个岗位既不是开发工程师，也不是部署工程师，而是直接派驻到客户公司去，把AI接入客户真实的生产场景中。
这个岗位解决了一个问题：AI模型越来越强，但是并没有在客户真实的业务场景中兑现价值。原因是缺少一个角色，负责把用户真实的、来自生产环境的、广义上的知识接进AI。
前段时间我对这个岗位的一些职责没想清楚。随后重读了毛选中的《实践论》，把疑惑点重新梳理了一遍，逐渐有了一些答案。
1 从《实践论》讲起
1.1 三组概念
1.1.1 实践与认识
《实践论》指出“人类的生产活动是最基本的实践活动，是决定其他一切活动的东西。”“人的认识，主要地依赖于物质的生产活动”。
实践与认识的关系我们可以概括成四层：第一实践是认识的来源。第二实践是认识的动力。第三实践是认识的目的。第四实践是检验认识的标准。
第一层关系回答了认识从哪里来。第二层关系是指当实践无法推进时，实践迫使我们更深层地去理解事物本质。第三层关系是指提高认识的最终目的是用于实践。第四层是说“真理的标准只能是社会的实践”。
1.1.2 感性认识与理性认识
《实践论》指出认识有两个层次，第一层是感性认识，第二层是理性认识。
感性认识是我们通过听到的、看到的、摸到的得到的感觉和印象。感觉和印象通常是表面的，片面的，暂时的。
理性认识是我们把多次得到的感觉和印象进行提炼和加工，使用判断和推理，得到合乎论理的理论。这就是理性认识。
这时认识上升了一个新的高度，不是数量的增加，而是性质的变化。我们对事物的本质开始有了把握。
1.1.3 直接经验与间接经验
自己亲自下场得到的经验被称为直接经验。别人下场得到的经验，我们通过后天习得的，被称为间接经验。
《实践论》指出“一切真知都是从直接经验发源的。”当然我们不可能事事亲自下场，事实上“多数的知识都是间接经验的东西”。我们需要知道，间接经验也发源于亲自下场者的直接经验。
这两种经验不是对立的关系，如果只有直接经验，那么需要事事亲力亲为。如果只有间接经验，那么会变成唯书本论。这两种经验一定要相结合。
1.2 两次思想飞跃
1.2.1 从看得到到想明白
从感性认识到理性认识，从表面的认识到本质的认识，《实践论》称之为“能动的飞跃”。
这一步不是凭空产生的，感觉的材料需要具体的、真实的、全面的。如果材料本身是模糊的、虚假的、片面的，那么也提炼不出正确的理性认识。
我们在处理复杂任务时，由于各种客观条件所限，有时一次性难以得到全面的感性认识，所以不得不采取盲人摸象的办法。但是我们也要反复地、多维度地、诚实地摸象，逐步了解大象的全貌。
1.2.2 从想明白到做出来
认识走到理性，我们的路程才进行了一半。《实践论》讲“认识的能动作用，不但表现于从感性的认识到理性的认识之能动的飞跃，更重要的还须表现于从理性的认识到革命的实践这一个飞跃”。
这告诉我们方案在会议室里面可以自洽，逻辑可以闭环，但理性认识在真实世界中是否成立，只有放到真实世界才知道。
1.3 循环往复
从实践到感性认识，再到理性认识，最后回到实践，这是一次认识循环。这种循环我们在解决复杂任务时可能会经历多次。
本轮的实践结果可能推翻本轮的理性认识，下一轮的实践结果可能推翻上一轮的或者上几轮的理性认识。
这是做了无用功吗？并不是。我们至少知道了哪些路是行不通的，这让我们下一轮站在更高的起点上。
每一轮得到的理性认识都是相对真理。《实践论》讲“无数相对的真理之总和，就是绝对的真理”。
2 FDE这个岗位
2.1 FDE与开发岗位的关系
FDE驻点在客户公司，面对和收集的是客户的具体问题，深入的是客户的真实业务流程。一边和业务人员聊，一边写代码（可能是客户公司系统），搭AI工作流，写脚本，把智能体嵌入真实业务场景，拿到可量化的结果。
我认为在一次认识循环中，FDE至少走到感性认识这一层。他蹲在现场，把看到的、听到的、问到的东西，变成对业务的感觉和印象。当然不是说FDE不需要提炼和总结，他也会把问题梳理清楚并写成方案，但再往上抽象成理论那是开发的主要工作。
当FDE把在多家客户现场发现的问题提交和反馈回来，开发从中看出共性，进行抽象，从本质上解决问题。我认为在一次认识循环中，开发侧重于理性认识。
当开发完成功能迭代后再告知FDE，FDE回到客户公司现场验证新功能，看看之前的问题有没有真正解决。
这就是一次认识循环。FDE从实践里得出感性认识，开发把感性认识提炼成理性认识，FDE再把理性认识放回实践里验证。FDE和开发就是这样配合，完成许多轮认识循环，一轮一轮往上走，飞轮才转得起来。
2.2 FDE岗位职责
FDE需要长期扎根业务部门，而不是坐在研发部，熟悉业务术语、痛点、流程，和业务部门同频。这样让业务部门觉得是一起冲锋陷阵，而不是“我来指导你们”。拿不到真实的材料，感性认识就建立不起来，更遑论形成正确的理性认识。
FDE需要具备一定的开发能力，而不是不假思索地把问题丢给开发。第一当发现流程卡点或者数据孤岛时，这种小需求通过开发工具或者写脚本快速验证。第二发现大需求时梳理清楚，输出方案交给开发人员。
FDE需要持续迭代，陪跑业务，跟进指标，而不是做完就走，需要对业务结果负责。这就是实践检验理性认识，是空谈还是灼见，实践中见分晓。
这个岗位不只是对外部客户。对内也一样，相对研发部门来说，人事、财务这些部门同样是“外部”，同样需要有人沉进去做AI升级。
2.3 珍贵又昂贵的上下文
上下文之所以珍贵，是因为这是业务真实的数据、真实的解决方案。它是感性认识的基础，直接决定理性认识能不能成形。这部分数据从公开渠道搜不到也买不来，是公司真真正正的宝贵资产。
上下文之所以昂贵至少体现在四个方面。
第一在有AI之前，我们所说的数据默认指结构化数据，例如一份结构清晰的文档，数据库里行列清晰的数据。有了AI之后，过程数据也被纳入了数据的范围，开始产生价值，例如2个小时的会议录像，150分钟的会议录音，2000轮的工作聊天记录。
第二《道德经》说“道可道，非常道”，真正的规律很难用文字或者语言说出来。工作中一些诀窍或者最佳实践，很难以数据的形式沉淀，而是存在经验丰富的业务人员的脑子里。
第三数据维护问题。一是万事万物以熵增的方式演进，从有序到无序，落到技术系统里就是功能蔓延、文档腐化。功能或者业务每天变化一点，数据没有跟进维护，日积月累就远远落后于真实业务。二是数据存在多个版本，版本一和版本二的逻辑可能截然不同，却被同时投喂到知识库中。
第四FDE的授权问题。公司内部数据会有涉密部分，业务部门对于哪些数据愿意让渡和共享，这不是FDE所能决定的，需要公司更高层级的授权。
2.4 如何获取上下文
既然上下文如此珍贵与昂贵，那么获取上下文就有必要但也有难度。获取上下文难在技术吗？不全是。获取上下文主要难在技术、沟通、管理三个维度。
技术这个维度要求FDE具有一定的开发能力，开发一些顺手的工具，例如开发平台或者脚本，对数据获取很有帮助。
FDE固然要写代码，但这不是最主要的工作。最主要的工作是与业务人员打成一片，识别卡点和孤岛，把最佳实践拿到手。要做到这一点，没有良好沟通能力是不行的。
管理这个维度，第一是要推动建立数据版本维护制度，例如知识库的更新时机和责任人机制。我们在写技术方案时会指定负责人，并在文档首节建立维护记录表格，这是同一个道理。第二是对FDE的授权要明确，名不正则言不顺，FDE要有一定的授权对原有业务流程提出意见，客户公司高层也要把这些意见当回事，这需要两方公司更高层去决定。
3 文章总结
为什么模型这么强落地还是难？因为模型缺的不是能力，是上下文，而上下文只能从实践中来，这一步模型替不了人，所以这个岗位会一直在，因为总得有人在现场听见炮声。
