方法论
从 Demo 到生产，中间隔着四道工程关
我们把这件事拆成可检验的步骤。如果某一步过不去，我们会告诉你，而不是硬做下去。
为什么多数 AI 试点停在演示阶段
超过 60% 的企业 AI 尝试停留在试点阶段。原因通常不在模型能力，而在演示环境与生产环境之间的差距。这个差距可以拆成四件事：
01
真实数据与演示数据不是一回事
演示用的是清洗过的样本。生产环境里同一个字段可能有三种格式、五处缺值，历史数据里还混着早已废弃的业务规则。接数据这一步的工作量，常常超过模型接入本身。
02
系统对接与权限
模型要读的那张表，可能在三个不同的系统里；能读它的人只有两位，其中一位已经离职。权限梳理与接口对接不性感，但它决定了系统能不能真正跑起来。
03
流程要改，而不只是加一个工具
如果新系统不嵌进现有流程，它就会变成又一个需要额外维护的页面。真正落地意味着有人要改变自己每天的工作方式 —— 这件事需要业务部门参与，而不是 IT 部门单方面推动。
04
上线之后没人维护
模型会漂移，数据分布会变，业务规则会调整。没有明确的维护责任人与回归测试机制，系统在上线三个月后开始失准，然后被悄悄停用。
我们的三阶段交付流程
每个阶段都有明确的产出物与停止条件。我们不把「继续做下去」当作默认选项。
诊断与定义
1–2 周现场看流程、见真实使用者、摸清存量系统与数据。产出一份书面判断：这件事值不值得做、卡点在哪、大致需要多少投入。
产出物
- 场景可行性判断（含明确的"不建议做"结论）
- 现有系统与数据清单
- 范围与验收标准草案
停止条件
如果诊断结论是不该做，或我们判断自己不是合适的人，我们会直接说，并说明理由。
试点与验证
3–8 周在真实数据与真实使用者上做一个范围固定的试点。目标是证明它在生产条件下降本增效，而不是在演示环境里跑通。
产出物
- 可运行的系统
- 在真实数据上的效果评测报告
- 使用者反馈记录
- 上线与回滚方案
停止条件
如果关键指标达不到事先约定的门槛，试点就到此结束。按阶段结算，不强行推进下一期。
沉淀与移交
与阶段二重叠把这次交付中通用的部分抽出来：连接器、提示词模板、评测集、失败案例。这决定了下一个同类场景要花多久。
产出物
- 可复用组件与连接器清单
- 技术文档与运维手册
- 同类场景的复用说明
停止条件
如果某个环节无法复用（因为它高度依赖客户特有逻辑），我们会如实标注，不假装它是通用能力。
外包、项目制、FDE：分界线在哪
区分这三者，不看是否有人驻场，而看项目结束之后留下了什么。这条分界线是行业通用的判断方式，我们用它来要求自己：
| 项目结束时留下的东西 | 这叫什么 |
|---|---|
| 只给客户一个能跑的系统，知识随人离开而消失 | 外包 |
| 带回了经验，但下一个客户用不上，一切从头再来 | 项目制交付 |
| 把去掉客户信息的行业经验，沉淀成可复用的组件、连接器与模板 | FDE |
| 沉淀后显著降低下一个同类客户的交付成本 | 可规模化的 FDE |
判据很具体：如果第一个客户需要 10 个人月，第十个同类客户仍然需要 10 个人月，说明模式没有跑通。另一条红线是，单客户占用的交付人力如果长期超过总量的 30–40%，业务实际上已经退化成高端人力外包。
沉淀具体怎么做
「沉淀」容易变成一句口号。在我们这里，它有两个方向，每个方向都有具体产物与一条硬性边界：
向客户方向：把人的经验变成系统能用的东西
业务人员脑子里的流程规则、例外处理方式、判断标准，通常没有写在任何文档里。我们把它整理成可被系统调用的知识库、规则与工作流。交付物要能让客户的业务人员看懂并维护。
向我们方向：把项目经验变成下一个项目能用的组件
系统接口怎么接、哪个环节容易出错、什么样的测试能发现问题、哪些做法验证过无效 —— 这些整理成可复用的连接器、模板与失败案例库。
硬性边界：客户的任何信息都不进入复用部分
客户数据、业务规则、系统细节不进入我们的复用资产。可复用的是行业通用的方法与组件，不是客户的具体实现。这一点必须在合同与技术上同时成立，而不是靠承诺。
交接设计：什么必须留在你手里
这一节讨论一个很少被写进方案的问题：项目结束时，除了代码，还有哪些东西的所有权决定了你以后能不能自己维护这个系统。行业里对这件事最尖锐的描述是 —— 风险不在于用了外部帮助，而在于合作结束时企业变得更没有能力、更依赖外部。
01
运行监控与日志
系统上线后你需要持续看到它在发生什么：调用了什么、失败在哪、效果有没有衰减。如果这套东西只在我们手里，我们一走，你对系统的可见性就一起走了。
02
效果评测套件
评测数据、判定标准、跑评测的脚本。没有它，你无法判断某次改动是变好了还是变坏了，也无法在模型升级后确认系统还准不准。
03
集成逻辑与配置
系统之间怎么对接、字段怎么映射、异常怎么处理。如果这些只存在于某个人脑子里或某个只有我们能改的配置文件里，你实际上没有真正拿到这个系统。
04
运行手册与决策记录
包括常见故障怎么处理、哪些参数不能随便改、以及当初为什么这么设计。没有决策记录，下一个接手的人会重复我们已经踩过的坑。
05
成本模型
这套系统跑起来每月大概花多少钱、花在哪、什么情况下会突然变贵（例如调用量翻倍、模型换代）。多数方案只给第一部分定价，然后把后面 18 个月当成理所当然。
一条实用的判断方法：问供应商「你们离开之后，我们自己能改哪些东西、不能改哪些」。如果答案里有很多"这个得找我们"，那不是技术限制，是商业设计。
验收标准清单
验收标准必须在项目开始前谈定，而不是交付时再说。以下是我们在每个项目里都会与客户逐条确认的内容：
功能与效果
- 明确写出这个系统要解决的业务问题，以及对应的可测量指标（如处理时长、准确率、人工介入率）
- 在客户真实数据上设定评测集，评测集在项目开始时冻结，双方各存一份
- 约定效果下限与测量方法，写清楚谁来测、什么时候测、用什么口径
系统与集成
- 列出必须对接的存量系统清单，并标注每一条接口的责任方
- 明确权限方案：系统以什么身份访问数据、谁审批、如何留痕
- 给出上线与回滚方案，包括出现故障时谁来处置、多久内恢复
- 确认运行监控与日志归你所有，我们离开后你仍能看到系统在发生什么
- 确认效果评测套件（含评测数据与判定标准）交给你，而不只留在我们手里
- 确认集成逻辑与配置以你能维护的形式交付，而不是只有我们能改的黑盒
组织与使用
- 确认谁是系统真正的使用者，以及他参与过设计过程
- 确认上线后由谁负责日常维护与问题反馈，写进文档而不是口头约定
- 约定上线三个月后的回看机制 —— 一次验收通过不代表系统真的在被使用
责任边界：谁负责什么
项目失败最常见的原因不是技术，而是双方对各自职责的理解不一致。因此在开始前我们就把这张表谈清楚：
我们负责
- 场景判断与技术方案，包括明确告知哪些做不了
- 系统实现、集成对接与上线支持
- 沉淀可复用资产，并如实标注哪些不可复用
- 主动暴露风险与坏消息，不等到交付日才说
需要客户负责
- 指定业务专家并保证其时间投入 —— 这是最常见的卡点
- 提供生产数据与系统的访问权限，并完成内部审批
- 指定一位有决策权的对接人，避免需求多头
- 协调内部 IT 部门配合接口与权限对接
这四项中任何一项长期无法落实，项目大概率会在中后期停滞。我们会在诊断阶段就判断这一点，而不是等到项目中途才发现。
需求变更是常态，怎么处理
试点期间出现新的重要需求
记录下来但不立即纳入。先完成当前范围，把它作为下一期的输入。范围蔓延是试点失败的主要原因。
关键假设被证伪（例如数据根本不可用）
立即停下来重新评估，而不是加倍投入试图救回来。如果结论是不该继续，我们按已完成部分结算。
组织侧承诺无法兑现（业务专家抽不出时间等）
项目暂停并书面说明。继续做下去只会产出一个没人使用、也没有人验收的系统。
交付上我们不做的四件事
- 不做没有验收标准的项目。说不清怎么算成功，就不该开始。
- 不做交付后不管的项目。上线三个月后我们会回来做一次回看。
- 不做范围会无限扩张的项目。需求可以变，但变更走下一期，不吸收进本期。
- 不做只留下代码、不留下理解的交付。文档与知识转移是交付物的一部分，不是附赠。
常见问题
你们的交付周期一般多久？
诊断阶段通常 1–2 周，试点 3–8 周。整个周期取决于存量系统的数量和数据的可用程度 —— 数据不可用是最常见的延期原因，这一点我们会在诊断阶段先查清楚。
系统上线后归谁？源代码给不给我们？
代码与数据归客户所有，这一点会在合同里写清楚。我们保留的是不含客户信息的通用方法、组件与模板。具体条款在合同阶段逐条确认。
如果做了一半发现方向不对怎么办？
停下来重新评估。我们按阶段结算，不会要求你为已经不成立的方向继续付费。这也是把项目拆成三个阶段而不是一个大项目的原因。
你们会不会和我们的 IT 部门产生冲突？
这个问题值得认真对待。现实中 FDE 进现场最常遇到的阻力，恰恰来自内部团队认为外部团队在否定他们的工作。我们的做法是把 IT 部门当作必须共同交付的一方：接口、权限、上线流程由双方一起定，成果写双方的名字。如果客户的组织结构决定了这件事做不到，我们会在诊断阶段说出来。
想先看我们怎么判断一个场景值不值得做？
把你在推的那个场景讲给我们听。诊断阶段的产出是一份书面判断，包含明确的不建议做结论。