ISSUE / 01
POC 过了，生产没过
演示用的 20 条整洁样例，撑不住每天 8000 单的真实数据：错别字、简称、串行的历史脏数据、上游系统半夜改了字段。
过去两年，多数企业的 AI 项目都停在同一个位置：演示很惊艳，生产很沉默。 这不是模型能力的问题，是交付方式的问题。
演示用的 20 条整洁样例，撑不住每天 8000 单的真实数据：错别字、简称、串行的历史脏数据、上游系统半夜改了字段。
关键字段散在 ERP、WMS、企业微信群和几十个部门自己维护的 Excel 里。没有人同时有这几个系统的权限，也没有人被授权去打通。
模型给出了建议，但审批链、岗位职责和考核口径一个都没改。于是建议被打印出来，压在文件夹底下。
方案交了、款结了。三个月后上游接口变更、模型版本更新、效果开始漂移，没有人还在现场。
FDE 的做法是把工程师放到问题发生的地方，按阶段推进、按里程碑验收。 下面这张表在项目启动第一天就会贴在双方的会议室里。
判断一个 AI 项目是否真的落地，最简单的办法是看结项那天客户拿到了什么。 下面左边是我们交的，右边是我们明确不交的。
共同点：高频、有明确对错、今天靠人肉硬扛、且上游有可拿到的结构化数据。 场景越窄，跑通得越快。
顾问交方案不碰代码，外包接需求不问业务。FDE 的位置在两者中间—— 既要能在客户的生产环境里改代码，也要能坐在会议室里推动流程改动。
对交付结果负责的唯一一个人。手机号给到客户业务负责人，项目期内随时可打。既写代码也参加客户的业务例会。
负责数据与集成：打通 ERP / WMS / MES / OA，处理权限、网络隔离、私有化部署与上线后的可观测。
负责业务口径与评测：把"做得对不对"翻译成可自动判定的评测集，和业务专家一起标注边界情况。
由客户指定、我们强制要求的一个角色。没有这个人，项目不启动——因为流程改动只有内部人推得动。
我们不绑定任何一家模型厂商。选型在阶段 01 用你的真实数据跑评测决定， 并且保证换模型时不用重写系统。
我们把付款节点和验收口径绑死。这样双方在阶段 01 就会认真对待那份基线数字， 而不是留到结项时才开始争论"算不算做成了"。
2 天，含差旅自理。产出候选场景清单与可行性分级。诊断完你可以直接拿着清单找别家做。
双方签字确认场景定义、基线指标与验收口径后支付。此时尚未写一行业务代码。
系统在真实数据上连续稳定运行 2 周后支付。演示环境跑通不算上线。
客户工程师独立完成一次迭代发布后支付。移交完成才算项目结束。
能。三种部署形态里有一种是完全离网：模型权重、向量库、应用全部落在你的机房，我们的工程师在你的场地、用你的设备开发，代码通过你的审计流程出入。代价是可选模型的范围会变窄、单次推理成本更高，这些会在阶段 00 就明确告诉你。
这是常态，不是例外。阶段 01 的一半时间就用在这件事上：确认每张表由谁维护、能不能定时导出、字段口径是否一致。实在没有接口的，我们用数据库只读账号、定时文件投递或 RPA 兜底，但会明确标注这是临时方案以及它的失效条件。
咨询公司交的是判断和方案，通常不进代码库；软件外包接的是写清楚的需求文档，通常不质疑需求本身。FDE 两件事都做：既在你的生产环境里写和改代码，也会在业务口径不合理时把问题摆到会议室里。代价是我们只接窄场景，接不了"整体数字化转型"。
这正是阶段 03 存在的原因。移交的目标不是"你自己再建一个团队"，而是让你现有的 1–2 名工程师能维持系统运行、改提示词、跑评测、发版。如果连这个都没有人，我们会在阶段 00 就建议你先别做，而不是先签合同。
阶段 02 的第一周就会有可运行版本给业务方试用，但那时候还不好用。可靠的判断点是阶段 02 的连续运行期——真实数据上跑满 2 周的数字，比任何演示都可信。整体上，从第一次现场诊断到能拿数字汇报，通常是 6–14 周。
一个。这是我们最硬的一条规矩。同时铺三个场景的项目，我们见过的结局基本都是三个都半途而废。第一个场景跑通、移交、稳定运行一个月之后，再谈第二个。