把"派人帮你做"变成
"按步骤交出可验收的东西"。
这句话听起来负责，但它不回答三个问题：派去的人按什么步骤做、每一步交出什么、什么时候算做完。没有这三样，服务会变成两种结局之一——客户觉得没做什么，或者我们无限期地待下去。
要防的三种失败
我们见过太多 AI 项目最后落到这三类结局里。它们都不是技术失败，是交付定义失败。
| 失败类型 | 表现 | 问题出在哪 |
|---|---|---|
| 顾问式 | 开展访谈、输出蓝图与架构设计、组织汇报会；三个月后业务流程未发生实际变化 | 交付内容为判断与建议，而非可运行的系统 |
| 外包式 | 驻场开发，需求逐项完成；验收通过后我方撤场，客户方修改一条规则仍需提交工单 | 交付内容为具体成果，未包含能力转移 |
| 工具式 | 完成部署、培训与文档交付，流程齐备；三个月后登录量降至个位数 | 交付内容为软件本身，而非已投入使用的作业方式 |
三种类型均非技术失败，而是交付定义不完整——未明确"交付什么才算完成"。因此本手册的首要任务，是把各阶段的产出物逐项明确。 《人工智能应用服务手册》· 编制说明
六段作业法
一道入口（启动与准入）、四步主干（定位 → 立标 → 交付 → 沉淀）、一道出口（移交与复盘）。入口与出口属于四步之外的准入与收尾环节，不构成独立的第五、第六步。
启动与准入
确认值不值得做、一把手在不在、数据拿不拿得到。目的是尽早说"不做"。退出：四项准入全满足。
定位
挑出最容易做成的那一件，写下验收标准。退出：选定一件事 + 验收标准书面确认。
立标
把现状量出来：耗时、人力、错误率、成本四项。退出：业务部门与财务部门双方确认。
交付
部署、开通、入库、配置、对接、上线。退出：跑满一个完整业务周期且结果达标，"演示通过"不算。
沉淀
技能入库、流程固化、内部管理员上手。退出：客户能独立发起新场景。
移交与复盘
交付物签收、责任划分、结项对账、双方复盘。退出：客户书面确认接手。
为什么"立标"不能省
多数 AI 项目失败在"没有基线"——事后无法证明价值、无法复盘、无法复制。所以第二步要业务口和财务口都签字。
耗时
单次人工分钟 × 频次。折算成工时，这是老板最直观的一类。
人力
涉及哪些岗位、各自投入比例。不是"大概一个人半天"。
错误率
近三个月的返工与退回次数。返工往往比时间更贵。
成本
外发费、加班费、外聘费、软件费。财务参与，事后才算得出钱。
验收怎么报
三类度量分别列示，不合并为单一的"效率提升 X%"。合并过程必然涉及加权，而加权比例由我方设定而非客户设定，会把客观数据变成主观结论。
| 类别 | 衡量对象 | 计算方式 |
|---|---|---|
| 第一类 · 工作量 | 该事项实施前后所需人工分钟，折算为工时 | 单次人工分钟 × 频次，前后比对 |
| 第二类 · 交付周期 | 自开始至交付的时长，衡量等待环节是否消除 | 等待不计入工时，但计入交期 |
| 第三类 · 产出量 | 同期完成的事项数量，衡量同等时间内的产出能力 | 与工作量、交付周期不重复 |
九份标准文档
这九份文档构成服务过程的完整记录。每份对应流程中的一个产出物，结构和用途统一。缺少任一份，对应环节将退化为口头确认。
| # | 文档 | 所属阶段 | 主要内容 | 签署方 |
|---|---|---|---|---|
| 1 | 准入评估表 | 入口 | 四项准入的逐项结论 · 不通过项的处置意见 | 我方交付负责人 + 客户决策层 |
| 2 | 立项说明 | 入口 | 实施范围、不在范围、参与方、完成标准 | 客户对接人 |
| 3 | 诊断访谈纪要 | 入口 | 按角色分别记录 · 专门记录例外情况与实际变通做法 | 无需签署，须回执确认 |
| 4 | 机会清单与打分表 | 第一步 | 候选场景逐项打分 · 选定理由 · 本轮不启动的事项及理由 | 客户决策层 |
| 5 | 现状基线表 | 第二步 | 四项口径 · 各项计算方式与数据来源 · 签署页 | 客户业务部门 + 财务部门 |
| 6 | 部署与配置记录 | 第三步 | 环境清单 · 模型路由与额度配置 · 内容安全规则及试运行结果 · 权限矩阵 · 对接方式 | 客户 IT 负责人 |
| 7 | 技能说明书 | 第三步 | 每条技能：解决的问题 · 输入 · 步骤 · 例外与边界 · 输出格式 · 需人工确认的情形 · 贡献人 | 客户业务负责人 |
| 8 | 首月运行报告 + 结项对账表 | 第三 / 四步 | 用量与成本 · 与基线逐项比对 · 拦截与命中记录 · 异常及处理 · 达标结论 | 客户业务部门 + 财务部门 |
| 9 | 移交清单 + 复盘记录 | 出口 | 交付物逐项签收 · 我方责任终止范围 · 内部管理员培养验证结果 · 复盘结论 | 客户对接人 |
这套方法参考了什么
我们不是凭空发明一套流程。下面这些方法论各自解决了一个具体问题，我们只取用得上的部分，不声称是其中任何一套的认证实施方。
| 方法论 | 我们取它解决什么 | 用在哪一步 |
|---|---|---|
| FDE（前置部署工程师） | 工程师进到业务里、和客户一起做，而不是远程交付；现场看到的东西带回产品里 | 贯穿全流程的角色设定 |
| 价值流失分布 | 把"项目为什么失败"拆成四段，其中超过一半发生在执行与执行完成之后——陪跑恰好覆盖这两段 | 第三步交付与第四步沉淀 |
| ADKAR 模型 | 把"采用"拆成认知、意愿、知识、能力、巩固五段，逐段检查 | 第四步沉淀的采用度评估 |
| Working Backwards / PR-FAQ | 先写清"做完之后业务是什么样"再决定做什么 | 入口的立项说明 |
| Shape Up | 写"愿意花多少时间"而不是"需要多少时间"；固定时间、可变范围 | 入口与变更机制 |
| 团队拓扑 | "赋能型团队"的定位是不代替他人做事、临时加入、教练式指导后退出 | 第四步沉淀与出口移交 |
用一次梳理验证这套方法
我们只要求一件事：你本人，或者分管这件事的副总，亲自参加那次深度诊断。