交付之后：真正的使用与离场

2025年10月9日，一个面向 Sun Finance 的生成式AI项目完成最终演示。它用来提取证件信息并辅助识别欺诈，由这家金融科技公司与AWS的生成式AI创新中心（Generative AI Innovation Center）共同推进。读到这里，很容易在心里给项目画上句号。

客户与AWS后来联署的技术文章，还列出了另外两个日期：11月14日技术交接，2026年1月22日投入生产。加上8月26日启动，同一个项目留下了四个节点。演示、交接和投产，各自是不同的事。¹

这份记录没有把当时的合作团队称作FDE，本章也不替它补上这个头衔。它提供的是一种与前线部署密切相关的共同工程实践，而且罕见地没有把整个过程压成“几周上线”的一句话。四个日期让我们看见：外部团队交出的技术成果，与客户接下来要承担的工作之间，存在一段必须走完的距离。

这段距离值得单独写一章。前几章解决了需求、数据、工程和上线验证；现在决定项目命运的，是客户会不会继续把真实任务交给系统，以及外部工程师逐渐退后时，工作会落在谁手里。

一次交付，四种不同的完成

把一个系统交给客户，可以先按四个问题理解。

第一，东西交到了吗？代码、配置和运行环境能否由接收方取得，约定的功能是否具备。第二，它进入真实工作了吗？工作人员有没有用它处理本来就要完成的任务。第三，工作因此变好了吗？等待、返工、服务质量或经济结果出现了什么变化。第四，当环境变化时，客户能否作出适当反应？知道如何诊断、何时停止、该找谁支持，是否能修改自己负责的部分。

四种完成可以发生在不同时间，也可能只发生了其中一部分。系统上线但无人愿意使用，是一种状态；员工每天使用，却花同样多的时间复核，是另一种状态。业务得到了收益，但每次更新都必须找原来的工程师，又是另一种状态。给它们同一个“已完成”标签，反而让下一步无从安排。

Sun Finance的四个节点证明了阶段之间确有间隔，却不能证明后面所有问题已经解决。2026年4月30日发表的原件，把人工介入和人员需求下降写成预计。生产上线有明确日期，经营上的人力变化则仍然是预期。¹ 如果读者把两者合成“上线后已节省人员”，就会在一张正确的时间表旁边，得到一个没有被证明的结论。

对企业负责人来说，这个区别关系到何时兑现预算；对技术负责人来说，它决定后续工作是谁的职责；对FDE来说，它影响自己究竟是在完成工程，还是在为尚未发生的经营结果背书。没有必要因此否认项目价值，但有必要让不同的完成得到不同证据。

系统有了入口，工作才可能进来

持续采用不总是从一场更好的培训开始。有时，更先要改变的是员工到哪里开始工作。

CoreWeave的一份案例展示了这样的改变。Cohere于2026年2月3日发表的记录称，合作由其解决方案架构师参与，企业AI工作平台North被接入客户原有的Slack支持流程。此前，支持工程师需要拼接问题信息，再通过另一个支持门户流转。调整后，工程师在Slack触发信息整理，核对并补充后确认，后续内部自动化再建单、召集相关工程团队。²

Slack在这里就是团队平日沟通和处理问题的工作软件。值得关注的不是又多了一个聊天机器人，而是谁仍须作判断：客户提出问题，支持工程师启动整理；系统提供资料，工程师决定它是否准确、是否还缺条件；确认以后，问题才继续流转。AI承担了一段明确的准备劳动，原来的专业责任仍有位置。

这份材料明确写的是解决方案架构师，不是FDE职衔；它也没有公开外部团队离开后的运行记录。我们借它观察的是采用如何落在工作动作上。把系统安置在原有入口，确实减少了员工为了使用它另起一段流程的需要；但入口接通，并不能单独证明员工信任它，更不能证明问题已经解决。

顺着这个区别，就能提出比“月活多少人”更有用的问题。在需要这项帮助的任务中，有多少进入了新流程？系统准备的材料，有多少直接可用，多少需要修改，多少被放弃？确认以后，问题是否到达了正确的接手者？员工是更快完成工作，还是把原来分散的补材料时间换成了集中检查时间？

这些是本书建议的观察角度，不是对CoreWeave内部指标的补写。对于任务频率差别很大的岗位，它们尤其有用。一位每月只遇到两次特殊问题的员工，两次都顺利完成，可能比每天打开系统却没有处理实际工作的人更充分地采用了工具。人数和打开次数看似直观，仍然需要合适的分母。

采用也不能靠强迫员工点击来证明。如果旧入口被关闭，人只能经过新系统，使用率自然会上升。此时更应观察绕行、返工和求助：有没有人在系统外重新做一遍，是否把未经检查的输出转交下一位同事，原来的等待又是否转移到了一个不容易被统计的群聊里。所谓进入流程，应该包括问题得到妥善接续，而不只是经过了一块屏幕。

员工不继续用，先看哪一步难了

当采用不如预期，笼统地说“组织不愿改变”很省力，也很难带来改进。对现场工程团队更有帮助的，是把一次具体放弃拆开看。

以下是一个教学情境。设备服务部门引入了维修资料助手。员工愿意让它搜手册，却很少采用自动生成的处理建议。一次跟随任务的观察发现，建议本身大多读得通，问题在于员工必须把设备型号、维修历史和现场照片分别搬进三个入口，输出又不能随工单留下来。需要帮助时，准备输入比熟悉的人工搜索更麻烦。

这种情况需要减少信息搬运。换一批更漂亮的培训材料，并没有触及员工放弃的位置。另一种情况恰好相反：所有资料已经自动到齐，但建议没有指出适用的设备版本。员工无法判断能否照做，只能回去查手册。这时应优先恢复判断依据，而不是继续缩短输入时间。

还可能存在第三种情况：助手做得不错，却要员工在自己的绩效时间里帮助别的部门核对资料。对整体流程有益的动作，落到个人身上是一笔新增负担。工程师能揭示这笔劳动，流程负责人才能安排它。否则，把采用问题交给技术团队，只会得到更多提醒、弹窗和使用说明。

这些可能性说明，采用是一次持续的设计判断。每当发现某类任务绕过系统，都可以追问：这个绕行是在弥补系统缺陷，还是在保留必要的专业判断？前者应该逐步消除，后者可能恰是安全运行的一部分。不能因为一条流程图没有画出人工通道，就认定通道本身是阻力。

FDE在这里的价值，也需要划定期限和对象。贴近工作可以帮助迅速找到卡点，但若所有流程讨论都只有外部工程师听得懂，客户仍然没有获得持续改进的能力。共同观察一次问题，比交付一份解释问题的报告更费时间，却能让接手的人同时学会如何发现下一个问题。

微软2026年9月的一份内部转型回顾也提供了一个相邻观察：大范围工具接入后，采用曾遇到平台期，团队随后梳理客户经理一周的实际工作，并组织围绕岗位任务的同伴学习。³ 这不是明确FDE项目记录，也没有单独证明同伴学习带来多少收益；它使“让员工学AI”变得更具体——先知道员工在哪一步需要帮助，再让改进进入那一步。

工作变好了，是怎样变好的

持续使用之后，负责人还会遇到一道判断题：变化来自系统，还是来自围绕系统进行的其他调整？CoreWeave的案例在解释处理时间改善时，同时提到了内部程序改进与North自动化。² 这是一种有价值的克制。入口重排、责任明确和资料自动整理一起发生，公开材料没有把它们各自的贡献分开。

项目团队不必为了得不到完美的因果证明而停止工作，但在决定下一笔投入时，应保留最有力的其他解释。例如，首批用户可能是经验更丰富、也更愿意配合的人；试点期间可能有专人紧盯异常；上线后恰好进入业务淡季。效果延续到其他班次、普通员工和更复杂任务时，原来的判断才经受了一次新的检验。

以下数字只用于说明。一组人员原来每次任务平均用二十分钟，使用系统后变成十五分钟。如果同期另一组在流程简化后也从二十分钟降到十七分钟，不能把前一组节省的五分钟全部记在AI名下。两组工作是否足够相似，还需要进一步比较；这个小算例的作用，是让“有改善”和“改善由谁造成”分开。

对不适合设置对照的业务，也可以保存变更前后的同口径任务记录，按复杂程度分组，说明同期变了哪些条件。低频任务可能需要较长观察，不能把几次成功包装成稳定收益。高频任务则要留心平均数之外的长时间等待：少量异常是否耗尽了节省下来的劳动。

这类记录应服务决定。若改善主要来自流程简化，可以把简单做法推广到没有部署AI的团队；若自动化在某类任务中特别有效，可以先扩展这一类；若它只在外部专家全程陪同下有效，就应先解决维护与能力问题。承认收益来源复杂，能够帮助项目找到下一步最便宜、最可靠的改进。

知道答案，与知道怎样改，是两种能力

能力转移已经成为一些FDE厂商公开强调的目标。Cohere的FDE作者在2026年8月提出，把共同构建和客户内部带教贯穿交付，让客户可以继续运行、评估、排障和扩展系统。AWS的FDE公告也把内部带头人、运行资料与自主运行能力列为交付方向。⁴⁵

公开原件目前能支持这些能力建设目标，也能支持前面的交接和投产日期；本次定向检索仍未找到一份足以重建“具名FDE离开后，客户独立完成一次变更”的记录。因此，本章不以离场成功作为既成结论，改用下面的演练检验承诺需要什么证据。听懂系统怎样工作，与有权、有条件把系统改好，相隔着好几步。

仍以刚才明确构造的维修助手为例。业务专家能指出一份手册过期，并不表示他应该获得修改运行程序的权限；工程师能更新文档索引，也不表示他有权决定某条维修规则是否适用。有效接手要让两种知识在需要时汇合：专家判断内容，技术人员实施变更，负责人决定是否开放给用户。每个人掌握的是自己那一段，组织拥有的才是完整能力。

这个区别能防止一种常见的交接错觉：培训了一个聪明、热心的内部联系人，便把他视为整个客户组织已经学会。一个人会用，不等于其他班次也会用；一个人记得原理，也不等于他休假或转岗时仍有人接住。与其要求每个人懂所有细节，不如把关键动作拆到可接替的位置，再让另一个人照着资料完成一次。

资料也有不同用途。给管理者看的系统图，回答钱和责任投在哪里；给值班者的处置说明，回答此刻应先看哪里；给维护者的变更记录，回答为什么不能把某条特殊规则随手删掉。把它们全部装进一套篇幅庞大的演示文稿，形式上容易交付，使用时却可能找不到入口。

更有帮助的资料围绕具体动作组织。出现某类异常，先确认它影响谁、有没有持续扩大，再判断是业务数据变化、连接问题还是模型输出问题；能够自行处理的部分写明步骤，必须升级求助的部分列明接收对象与所需信息。接手者不用背下整座系统，但应能沿着一条路径找到下一步。

这里要保留合理的求助。客户不必复制厂商的基础模型研究团队，也不应被要求自己修复没有权限进入的平台。需要留在客户手里的，是对自身业务范围、允许变更、风险后果和升级通道的控制。零求助率不是能力成熟的证明；把该升级的问题瞒下来，反而可能让一项本来可恢复的故障拖得更久。

把主驾驶的位置慢慢交出来

Google公开的SRE实践提供了一种清楚的接手方式。SRE是负责系统可靠运行的工程团队。其接手机制包含文档、实际操作训练，以及运行责任、变更和访问权限的渐进转移；过渡期间，原开发团队继续提供支持。⁶ 这是Google内部的工程方法，并非一个FDE客户成效案例，但它指出了交接中很实际的矛盾：需要交出责任，又不能在接手者第一次遇到异常时抽走所有帮助。

将这一点用于FDE交付，本书建议把“谁动手”作为比培训时数更直接的观察对象。开始时由外部工程师做，客户观察并追问；接着双方共同完成；再由客户执行，外部工程师只观察或在约定范围内提示。最后，外部团队不再参加日常动作，仍对超出客户职责的产品问题提供支持。

这种渐进方式的关键，不是硬性规定经过多少周，而是选对要移交的动作。对于一个低风险内部检索工具，更新资料和辨认过期答案可能最重要；对于能够修改业务记录的系统，停止执行、查明已完成哪些操作、恢复可核对状态，可能更重要。应当围绕后果选择演练，而不是给所有项目套同样厚的课程。

维修助手的隔离演练可以这样填。业务已决定停用旧教学手册V1；检索库需要同步这个变化，新手册V2只适用于X2型号。客户维护者负责更新检索资料，业务专家确认适用范围，发布负责人决定是否开放。外部FDE观察，只能指向已有操作说明；一旦练习越过隔离环境，必须立即介入。这里的手册和型号均为合成数据，不提供真实维修指令。

接手演练包提供任务、可用权限、允许帮助、首次失败与复测记录，以及空白演练表。没有举行真实培训，也没有把虚构通过写成客户能力成效。读者可以换一位同事按同样材料复做；第二个人能否找到适用范围和停止点，比培训材料厚度更能检验是否真的可接替。

接手还包括把权限和责任同步过去。一个团队如果要负责恢复服务，却没有查看必要记录或执行恢复的权限，就只有名义责任；如果拥有广泛修改权限，却无人确认变更后果，则是另一种缺口。权限不必一次全部放开，但每个已移交动作都应有与之匹配的授权、资料和支持安排。

投产以后，世界仍然会变化

Sun Finance的技术记录还有一处对交接很有启发：扩展到新的文档或语言，需要调整提示和校验规则，使用验证数据检查，再重新部署。¹ 即使第一次上线的代码已经交清，新的业务输入仍然会把工程工作带回来。

不必知道这些工具的内部名称，也能理解这条动作链。先描述系统将遇到的新材料，接着修改如何理解和检查它，再用已知答案的材料验证，最后把变更送到实际运行环境。只会打开现有系统，尚不足以完成这条链。能够解释错误，也不等于能够安全发布修正。

公开文章没有列出每个动作最后由谁长期承担，因此我们不能据此断言Sun Finance已经完全脱离外部帮助。它足以提醒读者：所谓可扩展，不只是软件允许增加一项配置，也意味着有人负责决定何时该增加、谁来验证、发生问题由谁处理。

把这一点放回项目第一周，交接就不再是最后几天才出现的任务。客户可以及早指定未来维护者，让他参与重要取舍；在第一次处理异常时共同留下原因；在第一次改动时保留能重新验证的材料。这样累积的知识带有来历，接手者知道某个看似多余的限制，是为了解决什么具体问题。

但也要防止把所有临时办法都永久供起来。一次赶工留下的绕行，可能只是当时的产品限制；以后产品改进了，继续保留它会增加维护负担。接手资料应同时说清为什么存在、什么条件下可以重新考虑。能继承判断的根据，比只能继承上一位工程师的习惯更有价值。

长期使用还会改变成本形状。建设期显眼的是开发投入，运行后更需要留意更新资料、排查错误、复核输出和支持新用户的劳动。有些成本落在业务团队，有些落在平台或安全团队。若只记录模型账单，项目可能显示越来越便宜，组织却每天投入更多时间让它继续可用。

这也是持续采用与经营结果必须分开看的原因。用得多意味着有更多机会产生价值，也意味着有更多机会暴露错误、消耗资源。应把完成的真实任务、质量变化和维护投入放在同一观察窗口，而不是用累计调用次数替代结果。窗口多长取决于任务周期，不能用一次热闹的上线周代替长期判断。

同时看业务结果与对个人的依赖

交接还有一种容易误判的进步：业务越来越顺利，原来的FDE却越来越忙。只看任务成功率，会以为系统在成熟；把私下答疑、临时修数据和代替客户作决定的时间也放进来，可能看见另一条曲线。

本书建议在相同任务范围内同时观察两件事：服务质量是否保持，外部某个人必须亲自介入的频率与耗时是否下降。质量保持或提高、个人介入下降，才比较接近能力转移的目标。若质量提高的同时，个人介入也增加，需要分辨是业务量扩大、困难任务增加，还是每次成功仍要靠原工程师救场；不能只凭咨询次数作结论。

维修助手可以用一次小变化来检验。客户维护者发现手册过期，能否按既定权限完成更新、重测和交出发布决定？若原FDE只需处理平台缺陷，内部已经接住日常责任；若每次都由他决定哪份手册有效，移交的可能只是操作入口。前面的隔离演练就因此有了长期观察用途，而不是培训结束当天的一次表演。

离场不是唯一的好结局

业务变化快、产品仍在频繁演进时，保留共同工程关系可能比客户完全内建更划算。小团队也可能没有足够工作量支持一套完整的维护岗位。长期合作可以是经过比较后的经营选择；问题在于，客户是否知道自己购买了哪部分持续支持，哪些能力留在内部，以及支持变化时能够如何应对。

可以把能力划成三个层次来讨论。日常工作能否由内部照常完成；范围内的小变化能否由内部判断并处理；涉及底层产品或新风险的变化能否清楚地提出需求、验证对方方案。第三层不要求客户独自写完所有代码，却要求客户有能力辨认问题是否真正得到解决。

这样的划分也让退出更务实。退出可以是某位驻场工程师不再参加日常会议，可以是客户接过一个工作流，也可以是双方改成按需要支持。关于合同、技术替换和商业锁定，后文还会专门讨论；在这里，应先确认运行责任有没有真实地从一个人移到另一组可持续的安排上。

客户第一次选择，是是否购买并开始建设。第二次选择发生得更分散：员工决定下一单还用不用，维护者决定一次小变更能否自己完成，负责人决定继续投入还是缩小范围。这些选择未必出现在项目庆功会上，却比“交付结束”的日期更接近系统的实际命运。

因此，FDE可以把离场当作一个检验机会，而非预先规定的终点。外部工程师退后一步，客户仍能知道系统正在做什么、哪里需要改变、遇事向谁求助。到这时，交出去的才不只是一个能运行的东西，还有一段能够继续运转的工作。