我们先看什么
诊断阶段要弄清楚的四件事
这四件事不清楚，做出来的东西一定用不起来。诊断阶段一般一到两周，产出是一份问题清单和收益估算。
| 诊断项 | 具体看什么 | 输出 |
|---|---|---|
| 流程断点 | 哪几步靠人重复搬运、重复抄录、重复解释；等待和返工发生在哪个环节 | 按环节标注的问题清单与频次 |
| 数据现状 | 数据存在哪、格式是否统一、谁维护、多久更新一次、能不能取到 | 数据源台账与可用性评估 |
| 经验依赖 | 哪些判断只有老师傅会做、判据能不能写下来、能不能教会别人 | 可标准化判断项的候选清单 |
| 边界约束 | 数据能不能出内网、有没有等保要求、现有系统能不能改、谁有权改 | 技术可行性前提条件 |
常见落地场景
我们做过、也最常被问到的四类
下面每一类都标明了适合的场景和它的局限。看清楚边界，比事后返工划算。
01
文档与工单信息提取
合同、工单、检测报告、报关单据等非结构化文档，批量抽取关键字段并写入业务系统。
适合字段相对固定、文档量大且格式统一的场景；扫描件质量过差时需要先做图像预处理。
02
质检异常与反馈归因
把质检记录、售后工单、客户投诉按类型和问题环节自动归类，替代人工翻阅统计。
适合分类边界清晰、有历史数据积累的场景；样本太少时先用规则打底再逐步替换。
03
内部知识库问答
设备手册、工艺文件、售后记录建检索库，员工用自然语言提问，给出带出处引用的答案。
适合知识分散、重复咨询多的场景；答案必须带引用，否则容易出现看似合理的错答。
04
流程节点辅助判断
在关键工位给出建议或预警，替代部分依赖经验的初判，人工保留最终确认权。
适合判据可量化、错误代价可控的环节；安全相关的最终决策不建议交给模型。
交付方式
工程师进现场，和业务同事并排干活
项目周期内，工程师会定期到现场，看真实的操作流程。哪些字段对不上、哪些步骤在系统里走不通， 当场就能发现并改，不用等验收时才发现。
模型部署同样可以放在企业自己的机房或内网服务器上。涉及模型权重、训练数据和业务数据， 全程不出企业环境；确有必要调用外部服务时，会单独说明并由企业决定。
| 部署形态 | 适用情形 |
|---|---|
| 完全私有化 | 数据不能出内网、有等保要求、已有运维能力 |
| 专属实例 | 允许多租户，但需要独立存储与访问控制 |
| 混合调用 | 常规处理本地完成，复杂推理按策略调用外部服务 |
验收标准
怎么算做完了
验收标准在方案阶段就写死，不做事后解释。下面这些是每期都会检查的项目。
| 验收项 | 判定方式 |
|---|---|
| 功能完成度 | 按需求文档逐条走查，业务方现场确认 |
| 准确率 | 用双方共同准备的样本集测试，达不到约定指标不予验收 |
| 稳定性 | 连续运行观察，记录异常次数与处理时长 |
| 性能 | 在约定并发和数据量下，响应时间达到约定值 |
| 数据安全 | 确认数据流向符合约定，敏感字段处理方式符合要求 |
| 可交接性 | 企业技术人员在培训后能独立完成常规操作与配置 |
推进节奏
四个阶段，各自的产出物
STEP 01
诊断
梳理流程与数据，产出问题清单和收益估算。约一到两周。
STEP 02
方案
技术路线、周期、人力、验收标准逐条确认，写进交付计划。
STEP 03
实施
按周期开发，每期交付可运行版本，业务方同步参与验收。
STEP 04
移交
源码、文档、部署脚本移交，留一段陪跑期解决遗留问题。
先判断这事值不值得做
第一次沟通我们只做一件事：判断你的场景适不适合。如果结论是「用规则更划算」，我们会直接说。