LangClaw 如何助力 FDE：把一线交付经验变成可复用的 AI 能力

AI 项目里，模型跑不通的情况不多，问题多出在项目结束之后：交付、验收、撤场，下一个场景换一拨人，环境重新摸一遍，坑再踩一遍。

经验跟人不跟组织，做到第十个场景，成本跟第一个差不多。

行业为此长出 FDE（Forward Deployed Engineer，前沿部署工程师），不只是把工程师放到现场，而是把“该做什么”的决定权一并交到现场，跟业务一起对结果负责。

但现场摸出的判断能留下多少，还是看人是否能沉淀出来。FDE 解决了“做对一次”，没解决“做对之后怎么复用”。

澜舟科技想解决的就是这一步：沉淀不该靠个人经验，应该长在交付流程里。

做这件事的底座是 LangClaw，澜舟自研的企业级数字员工平台，企业在这里构建、管理和调度自己的 AI 执行体。落到功能上其实很具体：团队里口口相传、但从没写下来的经验，由它整理成结构化、可版本化、能被直接调用的 FDE Skill，也就是技能包。

澜舟内部已经跑着一套自己的 FDE Skill，里面包含了真实客户的系统架构、部署参数和生产事故的原始记录，交付团队每天都在用，它已经是项目交付中的标配工具。

下面先看两个真实项目，再教你怎么为自己的团队搭一套。

先看两个项目

一、某头部股份制银行 · 法律合规智能问答系统

第一个是某头部股份制银行，要做一套法律合规的智能问答系统，覆盖两块业务：法律合规审查，和内部合规运营。这里说的“生产场景”没什么玄机，就是这套系统真要给一线业务人员用，不是拿去演示的。

进场之前，客户已经拿现成的问答产品做过一轮验收：业务部门出题，系统作答，人工判分，数答对了多少。通过率 54%，差不多一半的问题答不对，业务部门不认。

我们的 FDE 团队进场，在现场定位到四类差距，一条一条改：

四条差距里，按法条切片和效力层级这两条最容易被忽略，也最容易卡住，展开说两句。

先说切片。AI 读文档得先切段，通用做法是按固定字数切。但法律文本的效力单位是“条”，一条法条从中间切断，前半句是前提、后半句是结论，检索的时候命中一段，读出来的只有半截意思。所以这里改成按法条切，一条就是一条。

再说效力层级。法规之间有严格的上下位关系，宪法高于法律，法律高于行政法规，行政法规高于司法解释，往下依次是部门规章、监管通知。另外还有三条通用规则：上位法优于下位法、新法优于旧法、特别法优于一般法。普通检索按“文字像不像”排序，做不了这种判断，于是就会出现引用了一个很像、但不该适用的条款。

两个月，通过率做到 75% 以上，后来在全国分行推广。

这个项目本身说明的是定制交付能做到什么程度。跟 FDE Skill 的关系在下一步：这四项优化没有随着项目结束丢掉。它们被拆成可以复用的做法，连同这次摸清的系统架构、解析管线、部署参数，一起放进了技能包。下一个同类场景进场，工程师不用再从头想一遍。

二、某装备制造行业头部公司 · 生产环境排障

第二个是某装备制造行业的头部企业。他们的真实生产环境是三台服务器组成的集群。项目实施中碰到过几类故障：音频文件访问返回 404、会议纪要服务异常退出、容器挂载文件后读到的还是旧版本。

原来怎么做：故障解决了，在工单里记一笔。下次遇到，重新排查几个小时。
现在怎么做：每一起故障都整理成一张三列表，现象 → 根因 → 修复各一列，收进技能包。
结果：同类问题下次直接命中，不用再从零定位。

一个人踩过的坑，别人不用再踩第二遍。

这两个项目正好对上 FDE Skill 的两种用法。一种用在进场，少走弯路：架构文档帮团队更快摸清环境，排障对照表和工程师手册让方案设计有据可依，部署指南加快数据接入。另一种用在过程里，把单次经验当场接住，不用等谁想起来再去翻。

经验是怎么存下来的

澜舟在交付上真正花力气的地方，就是把这部分固定下来。听起来像“整理文档”，实际是一套完整的机制。

以前项目一结束，解决方案就散在各处：部署手册在个人电脑里，排障过程在群聊记录里，架构图在某个人的画图工具里。下一个人接手，要从头拼一遍。

现在交付过程中产生的每一份材料，最终都由 LangClaw 提炼成一个可调用的 Skill（技能包）。底层是一条五步流水线：

这五步分别是：

上传素材。部署手册、排障实录、架构图、操作流程、运维脚本，都传到同一个地方（澜舟智库）；
读取分块。模型一次读不完一整本手册，系统先按语义把每份文档切成小段，一段讲一件事，切的时候尽量不把上下文拆散；
蒸馏提炼。这是最关键的一步，也是“蒸馏”这个词的由来：像把一锅汤熬成浓缩汤底，把大量零散记录压成少数几条结论。具体压成三类：场景动作（遇到 A 情况，执行 B）、路由表（遇到什么问题，该查哪份材料）、排障表（现象 → 根因 → 修复）；
产出成包。把这三类结论组织成一个主文件，加若干份分册；
打包分发。压缩成一个能导入导出的文件，按版本迭代。

五步里决定成败的是第三步。这一步做不好，后面只是把一个凌乱的文件夹打了个包。

材料统一进入澜舟智库（了解详情：从流程自动化到认知智能化：LangClaw 携手澜舟智库打造业务决策型数字专家）。LangClaw 提炼时直接从库里取用，换个任务、换个人接手都不必重复上传；材料本身也始终留在企业自己的知识库里。经验就这么从“跟着人走"变成"跟着组织走”。

四步建一个具备 FDE Skill 的数字员工

上面讲的是系统内部怎么运转，落到操作界面上，就是四步。这条路径在 LangClaw 里从头走一遍，得到的是一个能直接被调用的交付数字员工。

你们拿自己手上的资料，也能照着做一份属于自己的具备 FDE Skill 的数字员工。

01 构建交付知识库

先把手上的资料收拢：产品架构文档、部署手册、排障记录、工程师手册，散在个人电脑、聊天记录、工单系统里的都拿出来，在任务对话框里统一上传到澜舟智库。

解析、分类、结构化留存都由系统自己做，不用人工先把格式统一。

这一步决定了后面所有事的上限。三条实操要求：

一篇文档只讲一件事。部署归部署、排障归排障。混在一起写，切分的时候容易把“场景”和“结论”切散，后面蒸馏出来的动作就没了前提。
文件名带上产品、版本、环境。路由表靠文件名建索引，命名含糊的文档，后续很难被准确命中。
排障记录必须写全“现象 → 根因 → 修复”三列。只写一句“已解决”，等于什么都没留下。

02 让系统把资料蒸馏成 Skill

资料上传完，下一步是在 LangClaw 的任务对话框里下指令。这里不用学任何特殊语法，说清三件事就行：这批资料是干什么用的、你要它产出什么形态。

我们实际用过的指令大致长这样：

上述是公司智库产品的相关架构、组件、安装部署，常见问题的文档，以此为基础形成智库产品的交付工程师技能库。

第一版一定是粗的，真正把它磨出来的是后面持续的真实提问。每次答错，就回头看是哪份材料没写清、哪条路由没建对，补进去，再发一版。

这是个持续校准的过程，不是一次性的配置。

03 创建数字员工

技能要挂到一个数字员工身上才能被调用。数字员工的配置项就四项：名称、角色描述、模型（主模型 + Embedding）、知识库与技能绑定。

其中 Embedding 值得单独说一句：它是一种专门做"检索"的模型，作用是把文字变成一串数字，这样系统就能按“意思相近”来找内容，而不是只认字面相同的词。主模型负责理解和组织答案，Embedding 负责把对的材料找出来，两者分工不同。

数字员工之所以“懂行”，靠的是三层沉淀叠加，缺一层就会退化成通用问答机器人：

一次配置，长期复用。之后团队里新人和老人用的是同一套角色、同一个知识库、同一份标准，结论不会因为这次是谁去问而改变。

04 按版本发布

FDE Skill 可以不断地补充所需知识，版本迭代

技能在磁盘上是一个文件夹，结构是“薄”主文件 + “厚”分册：主文件只放关键词路由表与速查，完整内容下沉到分册目录里，配套脚本单独存放，最后打包成一个自包含的压缩包。

理由很实际：把所有内容塞进一个文件，文件会越来越长，既没人愿意读，AI 也难以精准命中。薄目录负责“找得到”，厚分册负责“讲得透”。

建好之后，现场怎么用

FDE Skill 装好之后，工程师面对的界面就是一个对话框。

下面两个例子来自真实交付场景：一个是配置类问题，一个是现场故障，正好对应技能包里最常用的两类分册。

场景一 · 配置咨询：“智库要更换大模型，都需要改哪些地方的配置？”

它不会甩出一大堆文件让人自己找。先把问题拆成几种情况：换模型分三类情况，最常见的是只换地址和密钥，那就只用改模型配置文件里的对接段，改完重启对话服务就生效；如果连模型类型一起换，才需要动分词器相关配置。

以前的做法是翻部署手册，对着配置文件一行行核；这里的路径是一句分场景的结论，加一条可复制的命令。

场景二 · 现场排障：“现场环境，会议视频解析到 49% 卡住了”

它按离线管道的阶段定位法往下走。澜舟智会的解析链路是 pre → asr → nlp → post，分别是预处理（抽音轨、分片）、语音识别（把人声转成文字）、语义理解（整理成纪要）、后处理（排版与归档）。

第一步先判断卡在哪个阶段：去日志系统里查这条会议记录的处理状态，看前两道工序的状态码走到哪一步；定位到 nlp 阶段后，再按这次任务的唯一编号，去对应服务的日志里找错因；最后给出按可能性排序的动作：ASR 超时（长音频）> ASR 服务内存溢出 > NLP 未就绪，可以先重启相关服务，仍不通再按保留数据的方式重建 ASR 服务。

这段推理在技能包里不是一段散文，而是“现象 → 根因 → 修复”的三列对照表：每个阶段卡住有哪些典型现象、去查哪条日志、动哪个服务，全部写在分册里。老工程师脑子里的定位顺序，被固化成了任何人都能照做的步骤。

澜舟 FDE Skill 如何作用于 FDE 交付流程

《FDE 部门建设体系》定义了标准的 S0–S7 八阶段流程，分为三个时期。

定义期：判断该不该做、做什么。先进场做准入评估，再做现场发现与业务建模。进场要先画三张图、再定一条基线：业务图（有哪些角色、环节，谁对结果负责）、系统图（数据从哪来、接口在哪、边界划在哪）、数据图（有哪些数据源、质量如何、能不能拿到）。三张图不清楚、基线不定，就不开工。之后对多个候选场景排序，产出业务基线、投入产出判断和明确的范围界定。
验证期：判断做得对不对。先定架构与评测基线，验收标准由客户签字。这里有一条硬规则：评测集必须先于开发建立，没有尺子不开工。之后用客户的真实数据端到端跑通一个完整场景，拿出量化对比结果。
落地运营期：判断能不能长期跑。生产化工程、正式上线、持续运营迭代。产出不只是“一套能跑的系统”，还包括可回用的交付资产，以及回流到产品团队的需求。

Skill 的价值，是把团队沉淀的「部署、排障、架构、生产化」知识，精准注入到每个阶段的「关键动作」里。

三个时期各有明确的产出物和交付门槛。对客户来说，好处是在任何节点都能清楚知道：现在到哪一步了、下一步是什么、什么时候能验收。