服务
FDE 外包服务
派工程师进你的现场，把 AI 接进你现有的系统、权限和流程，交付一个能验收的生产系统。
我们具体做什么
把「AI 能做什么」翻译成「你的业务里该做什么」，然后把它做出来、接进去、跑到生产上。中间这一段是绝大多数企业真正卡住的地方。
01
判断该做什么
业务部门有痛点但说不清要什么，技术团队懂模型但不了解业务现场。我们先到现场看流程、和实际使用者聊，把模糊的痛点收敛成可执行的技术任务。
02
把它做出来
用大模型、智能体、检索增强等能力实现方案本身。这一部分是把模型能力与你已有的系统数据结合起来，做成能跑的应用。
03
接进已有系统
接口对接、权限方案、数据同步、异常处理。让新系统长在你的 IT 环境里，而不是成为一个需要人工搬运数据的孤岛。
04
推到生产并交付
上线、评测、监控、移交文档，并约定上线三个月后的回看。系统真正被人用起来，才算交付完成。
四种服务形态
按你的需求清晰程度和投入意愿选择。四种形态的价格结构不同，我们不做按人天计费。
FDE 诊断
- 周期
- 1–2 周
- 适合
- 还不确定该不该做、从哪做起
一次完整的现场诊断：看清场景、数据、组织三件事，产出一份书面判断与优先级建议。这一步本身就有价值 —— 结论可能就是「现在不该做」。
交付物书面诊断报告 + 场景优先级清单 + 范围与验收标准草案
固定范围试点
- 周期
- 3–8 周
- 适合
- 想先小成本验证能力
一个边界清楚的场景，在真实数据与真实使用者上跑通。范围在开始时冻结，验收标准提前约定，效果达标再考虑扩大。
交付物可运行系统 + 真实数据评测报告 + 上线方案
驻场交付（北京）
- 周期
- 按项目周期
- 适合
- 涉及敏感数据、必须现场协作
工程师进入你的办公场所工作，与业务和 IT 团队坐在一起。适合数据不能出内网、或者需要高频当面沟通的场景。北京地区可安排。
交付物同试点，另含现场协作流程与知识转移
长期陪跑
- 周期
- 按月或按季度
- 适合
- 有多个场景要陆续落地
以固定节奏持续投入，逐个把场景推到生产。适合已经验证过一轮、准备系统性推进 AI 落地的团队。
交付物季度场景路线图 + 持续交付 + 内部能力转移
说明：除北京外，中国其他地区与海外以远程交付为主 —— 通过远程接入、屏幕共享与定期视频会议推进。远程交付对客户侧的配合要求更高，我们会提前明确需要你提供什么。
未来计划：我们正在建立 FDE 人才库，目标是让就近的工程师可以到你的城市上门服务。这件事目前尚未落地，如果你所在的城市有需求，欢迎告诉我们，这会影响我们招募的方向。
典型的六类场景
以下几类是我们在制造业、金融、医疗、政务、消费零售等行业反复见到的需求形态。具体的场景清单见行业场景页面。
客服与工单
把重复问题交给智能体处理，复杂问题转人工时带上完整上下文。难点通常不在模型，在于历史工单数据的质量与转人工的判断规则。
企业知识库问答
把散落在文档、Wiki、邮件、聊天记录里的知识变成可查询的问答系统。难点在于权限隔离 —— 不同岗位能看到的内容不一样。
文档与票据处理
合同、订单、发票、检验报告的自动识别与结构化录入。这类场景效果最容易衡量，通常也最容易算清投入产出。
数据问答与分析
让业务人员用自然语言查询数据，不必每次都找数据团队写 SQL。难点在于口径统一与结果的可解释性。
流程自动化
把跨系统的重复操作串成自动流程，减少人工搬运与等待。适合流程规则清晰但系统之间没有打通的场景。
质量与设备监控
基于产线数据做异常识别与预警。这类场景对数据采集的完整性要求最高，需要先评估数据基础是否具备。
什么情况适合找我们
我们宁愿在开始前劝退，也不愿意做到一半发现方向不对。以下是明确的判断标准。
适合
- 需求不标准，现有产品无法直接覆盖，需要有人先帮你把需求定义清楚
- 涉及多个存量系统的对接、权限梳理或数据整合
- 已经试过一轮但没落地，需要有人找到卡点并真正推到生产
- 业务部门与技术团队之间存在沟通断层，需要一个能同时对话两边的角色
- 有明确的业务指标要改善，而不只是「想试试 AI」
不适合
- 需求标准化，市面上已有成熟产品或 SaaS 能直接满足 —— 买产品更便宜
- 本质是想要低价人力做明确的外包开发 —— 找人力外包更省钱
- 还没有任何业务方参与，纯粹是技术团队想做个 AI 项目
- 期望按人天采购工程师、由你方指挥具体工作内容
- 预算与周期完全无法容纳一次诊断与试点的最小投入
怎么判断一家 FDE 服务商靠不靠谱
这一节是给采购方的工具，不是自我宣传。无论你最终是否选择我们，都可以用这份清单去问任何一家候选供应商。愿意正面回答这些问题的供应商，通常也更值得合作。
- 01
第一个客户和第十个同类客户，分别需要多少工作量？
这是区分 FDE 与外包最直接的问题。如果答案都是「差不多」，说明这家公司没有沉淀能力，你付的是人力费而不是方法费。
- 02
项目结束时，除了系统，你们会留下什么？
好的答案会具体到组件、连接器、模板、评测集这类可复用的产物。含糊的回答通常是「完整的文档」—— 文档是交付的一部分，不是沉淀。
- 03
你们怎么判断一个场景不值得做？举一个你们劝退客户的例子。
一家从来没劝退过客户的服务商，要么客户筛选极严，要么就是在什么单都接。
- 04
项目开始前，验收标准由谁定、什么时候定下来？
如果验收标准要等到交付时才讨论，这个项目大概率会以扯皮收场。标准必须在开工前书面确认。
- 05
如果做了一半发现关键假设不成立，怎么结算？
这个问题会暴露对方的商业模式。按阶段结算、允许中途停止的，说明对自己的判断有信心；要求全额预付或按人天清算的，风险在你这边。
- 06
上线之后谁负责？出问题多久响应？
大量 AI 项目死在上线后三个月 —— 模型漂移、数据变化、没人维护。没有明确维护责任人的交付是不完整的。
- 07
客户的数据和业务规则，会不会进入你们给别的客户做的方案里？
这个问题问的是沉淀的边界。可复用的是通用方法与组件，不能是客户的具体业务规则、数据或系统细节。答案必须能在合同里写清楚。
- 08
这个项目具体由谁做？他做过什么类似的事？
FDE 的执行高度依赖具体的人。要问清实际投入的人，以及他们在类似场景里的经验，而不是看公司的整体介绍。
常见问题
你们和普通的外包公司有什么不同？
区别有三层。第一，进场时机：传统软件外包公司通常在需求明确之后进入、按约定实现功能；我们从需求还模糊的时候进场，先把它定义清楚。第二，计价单位：外包公司按人天或人力卖时间，我们按范围与阶段卖结果。第三，也是最重要的一层 —— 项目结束时留下什么：只留下一个能跑的系统是外包，把去掉客户信息的经验沉淀成可复用组件、让下一个同类项目更快，才是 FDE。一句话：不看是否驻场，看结束时留下了什么。
你们能上门吗？外地怎么办？
北京地区可以上门驻场。中国其他地区与海外以远程交付为主，通过远程接入与定期会议推进。我们正在建立 FDE 人才库，未来希望让就近的工程师上门服务 —— 这件事目前还在计划阶段。
一个项目大概多少钱？
我们不按人天报价，而是按范围与阶段定价，具体取决于场景数量、存量系统复杂度和数据可用程度。诊断阶段的投入最小，适合先从这里开始判断可行性。详见收费方式页面。
你们做过哪些行业？
我们能公开的行业经验目前集中在制造业、金融、医疗、政务与消费零售这几类的需求形态上。出于客户保密要求，我们没有可公开的具体客户案例 —— 这一点我们不做包装。你可以在诊断阶段要求我们说明同类场景的做法与遇到过的坑。
数据安全怎么保证？
这需要在项目开始前谈妥，而不是靠承诺。我们会先明确数据访问范围、以什么身份访问、如何留痕、哪些数据不得离开你的环境。涉及敏感数据时可以采用驻场方式，在你能控制的网络环境内工作。
不确定自己的场景该不该做？
先做一次诊断。产出是一份书面判断，包含优先级建议 —— 如果结论是不该做，我们会明确写出来。