LangClaw 助力 FDE 提升交付效率

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 的数字员工。 构建交付知识库。

先把手上的资料收拢：产品架构文档、部署手册、排障记录、工程师手册，散在个人电脑、聊天记录、工单系统里的都拿出来，在任务对话框里统一上传到澜舟智库。 解析、分类、结构化留存都由系统自己做，不用人工先把格式统一。 这一步决定了后面所有事的上限。 三条实操要求：一篇文档只讲一件事。 部署归部署、排障归排障。 混在一起写，切分的时候容易把“场景”和“结论”切散，后面蒸馏出来的动作就没了前提。 文件名带上产品、版本、环境。 路由表靠文件名建索引，命名含糊的文档，后续很难被准确命中。

排障记录必须写全“现象 → 根因 → 修复”三列。 只写一句“已解决”，等于什么都没留下。 让系统把资料蒸馏成 Skill。 资料上传完，下一步是在 LangClaw 的任务对话框里下指令。 这里不用学任何特殊语法，说清三件事就行：这批资料是干什么用的、你要它产出什么形态。 我们实际用过的指令大致长这样：上述是公司智库产品的相关架构、组件、安装部署，常见问题的文档，以此为基础形成智库产品的交付工程师技能库。 第一版一定是粗的，真正把它磨出来的是后面持续的真实提问。

每次答错，就回头看是哪份材料没写清、哪条路由没建对，补进去，再发一版。 这是个持续校准的过程，不是一次性的配置。 创建数字员工。 技能要挂到一个数字员工身上才能被调用。 数字员工的配置项就四项：名称、角色描述、模型（主模型 + Embedding）、知识库与技能绑定。 其中 Embedding 值得单独说一句：它是一种专门做“检索”的模型，作用是把文字变成一串数字，这样系统就能按“意思相近”来找内容，而不是只认字面相同的词。 主模型负责理解和组织答案，Embedding 负责把对的材料找出来，两者分工不同。

数字员工之所以“懂行”，靠的是三层沉淀叠加，缺一层就会退化成通用问答机器人：一次配置，长期复用。 之后团队里新人和老人用的是同一套角色、同一个知识库、同一份标准，结论不会因为这次是谁去问而改变。 按版本发布 FDE Skill 可以不断地补充所需知识，版本迭代。 技能在磁盘上是一个文件夹，结构是“薄”主文件 + “厚”分册：主文件只放关键词路由表与速查，完整内容下沉到分册目录里，配套脚本单独存放，最后打包成一个自包含的压缩包。 理由很实际：把所有内容塞进一个文件，文件会越来越长，既没人愿意读，AI 也难以精准命中。

薄目录负责“找得到”，厚分册负责“讲得透”。 建好之后，现场怎么用 FDE Skill。 装好之后，工程师面对的界面就是一个对话框。 下面两个例子来自真实交付场景：一个是配置类问题，一个是现场故障，正好对应技能包里最常用的两类分册。 场景一 · 配置咨询：“智库要更换大模型，都需要改哪些地方的配置？ ” 它不会甩出一大堆文件让人自己找。 先把问题拆成几种情况：换模型分三类情况，最常见的是只换地址和密钥，那就只用改模型配置文件里的对接段，改完重启对话服务就生效； 如果连模型类型一起换，才需要动分词器相关配置。

以前的做法是翻部署手册，对着配置文件一行行核； 这里的路径是一句分场景的结论，加一条可复制的命令。 场景二 · 现场排障：“现场环境，会议视频解析到 49% 卡住了”它按离线管道的阶段定位法往下走。 澜舟智会的解析链路是 pre → asr → nlp → post，分别是预处理（抽音轨、分片）、语音识别（把人声转成文字）、语义理解（整理成纪要）、后处理（排版与归档）。 第一步先判断卡在哪个阶段：去日志系统里查这条会议记录的处理状态，看前两道工序的状态码走到哪一步；

定位到 nlp 阶段后，再按这次任务的唯一编号，去对应服务的日志里找错因； 最后给出按可能性排序的动作：ASR 超时（长音频）> ASR 服务内存溢出 > NLP 未就绪，可以先重启相关服务，仍不通再按保留数据的方式重建 ASR 服务。 这段推理在技能包里不是一段散文，而是“现象 → 根因 → 修复”的三列对照表：每个阶段卡住有