第 4 课 给候选问题打分：挑一个出错也兜得住的小试点

第 3 课的访谈可能找出几个不同问题：夜班消息难查、群里的设备叫法与台账对不上、维修完成后没有留下结果。如果同时做一个完整的“智能设备平台”，每个问题都要接数据、改流程，最后很难判断哪一步真正有用。

因此先选一个范围小、能看见效果、出错后可以退回原流程的问题。把每个卡点写成候选任务，再比较谁会用、需要什么数据、如何验收。这就是第一个试点的选题。

选题前需要区分：概念验证（Proof of Concept，POC）回答“技术上能不能做到”；试点（pilot）回答“在真实工作里有没有人用、有没有用”。

项目常见的一种结局是停在概念验证：演示很顺利，之后却没人接手。原因通常是没有具名用户，没嵌进具体工作环节，也没人负责说“继续”。打分时就要把这些问清楚。

示例：五个候选问题

这里的“工单”指维修任务的记录，写明是哪台设备、由谁处理、目前处理到哪一步。

• A：把群里的异常照片和文字整理成结构化登记草稿（设备、时间、现象），班组长确认后保存
• B：交接班前生成一份“未关闭异常清单”
• C：让 AI 看报警照片判断是否停机，并自动通知停机
• D：自动在维修系统里建工单并派发
• E：做一个设备故障预测平台

第一步：过红线

命中任意一条，本期不做：

• [ ] 结果直接影响人身安全、停机或放行
• [ ] 必须写入真实业务系统才能验证
• [ ] 需要把真实客户或员工数据交给未经授权的外部工具
• [ ] 出错后无法撤回，或查不到是谁在什么时候做的
• [ ] 没有具名的业务负责人

逐个看五个候选：

• C 命中第一条。
• D 现阶段命中第二条。它得先在与生产隔离的演练环境（沙箱）里验证，还要备齐身份核验、最小权限、参数校验、人工审批、日志和回滚，审批通过后才谈得上碰真实系统，不适合打头阵。
• E 没越线，但范围太大，短期内给不出可验收的结果，先放进“以后再做”。

第二步：给剩下的打分

每项 1–3 分，3 分最好。下面是示例打分，你的项目要用自己的访谈证据来打。

B 在“真需要 AI”一项只得 1 分：一张共享表格加一份交接班模板就能做到。更轻的方案能解决，就用更轻的。

A 要把照片和随手写的文字变成规整记录，AI 在这里有用处，但每条草稿都要有人确认。所以这一期选 A，B 作为 A 的附带视图：记录规整之后，未关闭清单顺手就能生成。

第三步：写试点定义卡

一句话问题：夜班异常发群后难查找、难追踪，处理结果不回流
一线用户：二号车间操作员、班组长、维修工（具名待填）
业务负责人：[待确认]          有权叫停：[待确认]
范围：一个车间、一类设备，时长[待确认]
输入：先用经授权的脱敏历史样例或自编测试样例，再用试点期新上报内容
AI 做什么：提取设备、时间、现象，生成登记草稿
人做什么：班组长确认、修改或退回；维修工补填处理结果
本期不做：不判断停机，不写入维修或生产系统，不自动通知任何人
数据与工具：只读样例，不回写系统；只用经批准的工具；保留每条草稿和修改记录
回退方式：原有群聊流程照常保留，停掉试点即恢复原样
验收：[待与业务负责人确定，如记录字段完整程度、找到一条夜班异常所需时间]
停止条件：草稿反而让班组长更费时；出现未授权的数据外流；负责人叫停

今天先做一步

把你的卡点改写成至少三个候选问题。用红线清单逐条过一遍，划掉命中的。

本章产物

• 一张候选问题打分表、一张试点定义卡
• 验收标准：
• 红线已逐条检查
• 每个分数都有访谈证据
• “本期不做”至少写了三条
• 验收写成可观察的变化，未定的数字标“[待确认]”
• 业务负责人已经看过，或已约好确认时间

常见错误

• 挑最好演示的问题，而不是最常卡住的问题。
• 第一个试点就写入真实系统，或者自动触发动作。
• 普通表格就能解决的事，也包装成 AI 项目。
• 验收写成“提升效率”“更智能”，没人能判断是否达成。