深圳 AI 定制开发公司怎么选？12 项技术尽调清单与评分表
适用读者：正在评估 AI 定制开发供应商的技术负责人、产品经理、企业 IT
阅读时间：约 8 分钟
结论先行：别看案例 PPT，先要两样东西——评测集和源码交付条款。这两样给不出来的，后面 11 项不用问了。
一、为什么"看过往案例"几乎无法判断能力
案例只能证明"做过"，不能证明"做得好"，更不能证明"你的项目能做好"。三个具体原因：
- 案例是筛选后的结果。 十次里成一次也会写成案例，失败的那九次不会出现在 PPT 里。
- 演示环境不等于生产环境。 Demo 里 20 条数据跑得通，生产里 20 万条文档、并发 50、断网重连，是另一回事。
- 复杂度可能远低于你的需求。 一个"AI 客服"案例，可能是接个知识库加个对话框；你需要的可能是多轮工单流转、权限隔离、审计留痕。
真正能区分供应商水平的，不是案例数量，是过程资产：评测集、部署文档、源码归属、模型切换能力。这些东西做不出来，就是没做。
二、12 项技术尽调清单
A 组：交付物（4 项）
| 编号 | 检查项 | 怎么验 |
|---|---|---|
| A1 | 源码全量交付，含构建脚本与依赖锁定 | 让对方打开仓库，现场看 git log 提交节奏；只有一次 "init" 提交的要警惕 |
| A2 | 数据库设计文档 + 迁移脚本 | 要求现场执行一次空库初始化 |
| A3 | 接口文档（OpenAPI / Swagger） | 打开 /docs 或 openapi.json，不是 Word 截图 |
| A4 | Prompt、评测集、标注规范是否交付 | 这一项最能区分"做工程"和"调提示词" |
B 组：架构（3 项）
| 编号 | 检查项 | 怎么验 |
|---|---|---|
| B1 | 模型可切换：同一份业务代码换模型不改代码 | 现场把 DeepSeek 换成 Kimi 或别的模型，看要改几行 |
| B2 | 有模型网关：超时、重试、降级、限流、token 计量 | 拔掉主模型网络，看是否自动降级且报错可读 |
| B3 | 检索有评测：召回率怎么测、测了多少条 | 要测试集文件和测试报告，不要口头说"效果不错" |
C 组：数据与部署（3 项）
| 编号 | 检查项 | 怎么验 |
|---|---|---|
| C1 | 能否全私有化（含向量库、embedding 模型） | 问清楚哪些组件必须出公网 |
| C2 | 数据边界：是否用你的数据训练、留存多久、怎么删 | 要书面条款，不接受"我们不会看的" |
| C3 | 日志与审计：请求、响应、操作是否可追溯 | 看后台有没有可检索的操作日志 |
D 组：合同（2 项）
| 编号 | 检查项 | 怎么验 |
|---|---|---|
| D1 | 验收标准可测 | "能用"不是标准，"50 条真实问题上准确率不低于约定值"才是 |
| D2 | 源码托管与违约条款 | 验收不通过怎么办、维保多长、二次开发是否受限 |
三、评分表：怎么把 12 项变成可比的分数
每项 0–5 分，按组加权：
| 维度 | 权重 | 说明 |
|---|---|---|
| A 交付物 | 30% | 没有源码，等于被锁定 |
| B 架构 | 25% | 决定三年后还能不能改 |
| C 数据与部署 | 25% | 决定合规与事故半径 |
| D 合同 | 20% | 决定出问题时的救济手段 |
判定规则：
- 总分低于 60 分不建议签约
- A1（源码）或 C2（数据边界）单项 0 分 → 一票否决，不管总分多少
- 两家分差在 5 分以内时，看 D 组，合同条款比技术参数更影响长期成本
四、现场验证的 4 个动作
看 PPT 不如让对方当场做四件事，两小时出结论：
- 用你的真实数据跑一次。 不是 demo 数据。给 20 份真实文档、10 个真实问题，看输出。
- 现场换模型。 从 A 模型切到 B 模型，记录需要改动的位置和行数。
- 现场制造一次失败。 断网、改错 key、给超长输入，看降级逻辑和报错信息是否可读。
- 打开监控面板。 看线上真实 QPS、错误率、P95 延迟。拿不出监控的，说明还没跑过生产。
这四步做完，基本不需要再看别的。
五、报价怎么拆才算清楚
要求供应商给三列：模块 / 工作量（人天）/ 单价。只给总价的报价，后期变更一定会扯皮。
周期口径供参考（这是我们自己的交付口径）：
- 小程序、轻量业务系统：4–8 周
- 含大模型能力的系统：8–16 周
明显低于这个区间的报价，通常是省掉了评测、文档或私有化适配中的某一项。省掉的部分，最后会在上线后以返工的形式补回来。
六、什么情况下不该做定制开发
这部分写给自己人看：以下情况我们会建议客户先别做定制。
- 现成 SaaS 能覆盖 80% 需求 → 先买，把预算留给真正的差异点
- 预算只够模板站或简单小程序 → 定制开发做不下来，做下来也维护不起
- 组织内没有能接手运维的 IT → 先定运维归属，否则上线即失控
- 需要"保证效果"的书面承诺 → 任何负责任的供应商都不该签这种条款
七、把清单用起来的最小动作
如果你只想记住一件事：签约前把 A1（源码交付）和 A4（评测集交付）写进合同附件，其余 10 项按前文的验法逐条过一遍。这两条谈不下来，说明对方没打算让你在项目结束后具备自主运维能力，后面的技术承诺都要打折。
清单本身是可以被检验的：把自己收到的方案对着 A 到 D 四组过一遍，答不上来的项，请对方在合同附件里补书面答复，而不是在会议上口头解释。
本文为技术方法讨论，不含商业推广内容。
浙公网安备 33010602011771号