内部培养
适合条件
领域知识敏感、需要长期沉淀平台能力，并且已有可承担生产责任的工程团队。
必要基础
明确的业务 Owner、工程负责人、可用数据和允许团队持续迭代的组织空间。
常见误区
只培训工具操作，却没有真实项目、工程标准和岗位责任变化。
01 / OPERATING MODEL
组织方式不同，前置条件和失败方式也不同
不要先拿三家报价再讨论目标。先确认企业希望长期保留什么能力、谁承担生产责任，以及首个场景需要多快验证。
直接招聘
适合条件
已有明确场景，需要一个长期贴近业务、能承担端到端交付责任的核心角色。
必要基础
清晰的汇报关系、可调用的工程资源、合理权限，以及与岗位难度匹配的招聘标准。
常见误区
把 FDE 当作一个人包办产品、售前、研发、实施、运维和变革管理。
外部服务
适合条件
首个试点需要加速，或内部暂缺特定行业、模型评测、集成与部署能力。
必要基础
数据边界、知识产权、交付物、验收、知识转移、维护和退出条款。
常见误区
演示完成即视为交付，企业没有代码、文档、评测集或接管能力。
02 / EVALUATION
要求候选人或服务商提交证据，不只回答观点
以下维度是本站建议的核验框架，不是固定权重的行业标准。应根据场景风险和组织能力调整优先级。
| 评估维度 | 现场追问 | 应提供的证据 |
|---|---|---|
| 问题判断 | 是否会质疑“这个问题是否该用 AI”，并把现状流程、例外与基线说清楚？ | 访谈记录、流程图、场景取舍和不做清单。 |
| 生产工程 | 能否处理数据、集成、权限、调试、部署、可观测性、回滚和维护？ | 可运行系统、架构决策、测试记录和运行手册。 |
| 评测能力 | 是否定义了真实样本、质量标准、失败类型、人工基线、成本和延迟？ | 评测集、评分规则、失败样本与回归结果。 |
| 安全合规 | 能否说明数据从哪里来、谁能访问、如何审计，以及外部模型如何处理数据？ | 数据流图、权限矩阵、日志策略和风险清单。 |
| 业务采用 | 是否与真实用户共创，把系统嵌入工作流，并观察有效任务而不是只看登录量？ | 用户反馈、采用数据、培训材料和流程变更记录。 |
| 可接管性 | 项目结束后，企业能否继续运行、定位问题、调整评测并替换关键依赖？ | 代码与文档、资产清单、维护责任、知识转移和退出演练。 |
03 / DELIVERY GATES
把 PoC 拆成四个可停止的决策关口
试点的价值不只是证明能做，也要尽早证明何时不该继续。每个关口都应同时写通过条件和停止条件。
- G0PASS / STOP
立项关口
- 通过条件
- 问题、用户、当前基线、数据条件、Owner 和不做边界已明确。
- 停止或补证
- 只有“做一个 AI 助手”的模糊愿望，或没有真实用户与可用数据。
- G1PASS / STOP
离线验证关口
- 通过条件
- 关键假设已用真实样本验证，并记录质量、失败、成本和人工对照。
- 停止或补证
- 只展示精心挑选的成功案例，无法复现失败样本或说明评测方式。
- G2PASS / STOP
小范围上线关口
- 通过条件
- 权限、日志、监控、人工兜底、回滚和支持责任已经落实。
- 停止或补证
- 原型直接接入高风险流程，或出现问题时没有责任人与停止机制。
- G3PASS / STOP
扩展与移交关口
- 通过条件
- 有效任务、运行成本和风险表现达到约定标准，内部团队可以接管。
- 停止或补证
- 采用数据不足、维护高度依赖个人，或退出后关键资产无法带走。
04 / RISKS
出现这些信号时，先暂停承诺
危险信号不一定意味着对方不专业，但足以要求补充证据、缩小范围或重新约定合同。
- 承诺固定准确率、收益或上线周期，却无法说明数据、任务难度和假设。
- 回避失败案例，只演示经过挑选的输入和单一路径。
- 把模型能力当作完整方案，忽略系统集成、权限、日志、回滚和用户流程。
- 案例无法确认客户、场景、发布方或证据边界。
- 报价与交付物不对应，代码、数据、提示词、评测集和文档归属不清。
- 没有知识转移与退出安排，维护只能继续依赖同一服务团队。
用一套明确门槛启动第一个试点
先确认问题、样本、责任、数据边界和停止条件，再比较团队与报价。上线前继续使用生产验收清单复核。