它不是外包交付
外包按需求交付、责任转移，需求由客户单方定义；陪跑按能力共建，客户团队要参与设计、编码与验收。交付物除了系统，还包括可维护的代码、文档与评测集，结束时客户能独立运营，验收也围绕这一点展开。
起点是业务问题
从一条可量化的业务链路开始，先确认输入、判断点、输出与复核人，再决定用模型、规则还是检索。跳过这一步直接选平台，常见结果是开发到中期才发现场景不成立，业务方也不使用，前期投入很难回收。
适用：有团队缺方法
已有业务负责人，且至少有一名能读代码、能改配置的技术人员，缺少的是场景拆解、评测设计与工程规范。项目结束时能力留在内部，第二次做场景会明显更快，日常维护也接得住，不必再长期请外部团队。
不适用：无人承接
若客户没有指定产品负责人，技术人员全程缺席，陪跑会退化为远程外包，知识留在外部，系统上线后无人维护。这种阶段更适合先做岗位培训或采购成熟产品，等有承接人再谈，否则合作容易两败俱伤。
适用与不适用
适合谁
- 有技术人员、希望自建 AI 能力的成长型企业
- 业务负责人愿意每周参与评审与验收的项目
不适合谁
- 没有技术人员、也不愿为项目配置承接人的团队
典型场景
某建材企业的销售预测长期靠区域经理手工汇总。企业指定运营负责人与两名数据工程师参与，陪跑方先梳理字段口径与例外规则，再搭离线原型，由财务复核预测偏差后接入订单系统，最终代码、文档与评测集移交企业，第二个场景由企业自己主导。
可执行步骤
- 确认业务负责人、技术对接人与验收人三个角色，并把分工写进项目章程
- 用一个真实业务月的数据跑通最小闭环，同时把失败样本整理成问题清单
- 把字段口径、例外规则与评测样本写成文档，双方各留一份并注明版本号
- 共同评审架构与关键代码，每过一个里程碑就减少一部分对外部团队的依赖
常见坑
- 客户只派协调员不派技术人员，评审会变成汇报会，代码最终无人接手，项目结束后系统停在演示状态。
- 把陪跑当外包，需求单向传递，出问题时双方都没有判断依据，返工只能靠加人加时间，责任也说不清。
- 合同未约定知识移交范围，文档与脚本留在外部团队手里，第二年想改一个字段都要重新采购，成本更高。
自检与验收清单
- 是否指定业务负责人、技术接口人与验收人并写入项目章程
- 是否有可用的真实业务数据，以及过去出过错的历史样本
- 是否在合同里约定代码、文档与评测集的移交清单
- 是否安排客户团队独立运行一个完整业务周期并留存记录
常见问题
陪跑和外包到底差在哪？
差别在责任与能力归属。外包由服务方承担交付责任，客户提需求、验收结果；陪跑由双方共同承担，客户团队参与设计与编码，服务方提供方法与评审。合同名称不决定性质，能否独立运行才是分界。
没有技术团队能做陪跑吗？
不建议。陪跑的前提是有人承接，否则知识无法沉淀。这类企业更适合先做岗位培训或采购成熟产品，等配了技术接口人再启动，否则投入容易变成一次性项目，第二年又要重新找人重做。
陪跑一定要驻场吗？
不必须。常见做法是每周固定评审加关键节点驻场，其余时间远程协作。是否驻场取决于系统集成复杂度与客户团队经验，应在确认单里写明频次与响应方式，避免后期争议。