一

方法论回顾

两件事

六纵 · 四横

五性一刻

两套怎么接 · 一张总表

二

案例：汽车租赁

沿六纵走六步

每一步看：团队做了什么、用到哪一横、客户形成了哪个判断

三

回看与练习

把总表填完

三道课堂推演

①

把有价值的系统做出来

→ 六纵四横

关注价值怎样被交付

②

让客户理解价值、愿意投入，在使用中真正感到效果

→ 五性一刻

关注客户怎样理解、选择和体验价值

第 1 纵

行业研究

问这门生意怎么运转？常见问题在哪？

交出对生意的理解：怎么赚钱、成本在哪；客户熟悉的场景

偏差把业内一句常说的话，直接当成事实

第 2 纵

需求调研

问具体的人怎样工作？遇到什么困难？

交出一组有依据的判断，不是一张越长越好的需求表

偏差问客户“你想要什么 AI”，照单列功能

第 3 纵

需求分析

问哪些是真问题？哪些最值得先解决？

交出第一期目标，和判断是否有效的标准

偏差把客户的一句愿望，直接翻成一个功能

第 4 纵

架构设计

问数据、功能、系统和人员怎样配合？

交出分工：哪些交给 AI、哪些交给规则、哪些交给人

偏差把所有工作都交给模型

第 5 纵

方案实施

问放进实际工作中，能不能用、怎么调？

交出一条用真实材料跑通的链路

偏差用演示代替运行

第 6 纵

交付验收

问按约定的标准，问题解决了没有？

交出分层检查的结论；要不要扩大使用

偏差只看页面能打开，只报一个准确率

价值认知

解决什么问题才值得投入？客户实际获得什么收益？

看和收入、成本、现金流、管理负担的关系

流程认知

工作怎样流转？谁负责哪一步？谁有权限处理？

看实际怎样发生、在哪交接、哪里返工

体验认知

用户能否看懂、用顺，并轻松完成关键动作？

看不同角色是否更容易完成工作

架构认知

各部分能否衔接？业务变化后，系统能否继续运转和扩展？

看数据、规则、权限和历史长期一致

相关性

“你说的就是我的情况。”

让对方觉得你懂他：从客户熟悉的场景谈起

方法稿的例子：先讲月底退款、扣费、到账分在不同表里

必要性

“这个问题确实需要解决。”

带来多大影响，要能量化：跟着做一遍真实工作

例子：确认对账持续占用大量时间

紧迫性

“现在就值得行动，继续拖会有代价。”

需要一个时刻：政策出台、上级要求、期限临近

例子：大促或结账期限已经临近

唯一性

“为什么这个方案或团队更适合我？”

要有具体的适配优势和比较依据

例子：和现有工具比，在哪些环节更适合

确定性

“有这些证据，我相信这件事能做成。”

来自客户对成功的信心

证据：过往案例、真实样本测试、可交接的资料

Aha 时刻

“原来这么好用，我自己就能用出效果！”

来自亲手使用后的直接感受

一次顺畅、看得懂、能完成工作的体验

1

两套方法，各管一件

六纵四横关注价值怎样被交付；五性一刻关注客户怎样理解、选择和体验价值

2

两套靠证据接上

每一步交付，都为客户的判断提供真实证据

3

一轮带出下一轮

用真实交付支撑客户判断，再用持续使用中的结果推动下一次投入

做什么

车辆供应 · 驾驶服务

日常运营 · 费用管理

项目结算

不只是把车租出去

想要什么

希望 AI 帮自己看清经营，找到：

盈利点

业务拓展点

成本控制点

现状

已经上了数字化系统，但没完全用起来

内部员工对系统比较抵触

自己试过把表格交给 AI 分析

1

这家公司怎么赚钱

2

业务怎么流转

3

数据为什么对不上

4

哪些工作适合交给 AI

2014 年

公务用车制度改革

推动普通公务出行社会化

同时保留必要的特定用途车辆

2016 年

中央企业公务用车制度改革

强调分类保障

不是所有央国企都不能购车、持车或使用经营保障车辆

固定车辆

车 + 司机

只采购驾驶服务

油费谁承担

有的客户承担，有的要求服务商承担

采购方

买的是

持续、合规、可追溯的用车保障

车辆服务企业

赚的是

把车辆、人员和管理组织起来后的服务收益

自有车辆

合同收入能否覆盖：

车辆投入、折旧或融资

保险、维修

约定承担的运营费用

合作车辆

分别算清：向客户收多少、向车主付多少

企业自己还承担哪些管理和服务成本

差额 ≠ 净利润

驾驶或综合服务

按实际合同识别：人员、车辆和其他费用分别由谁承担

不能沿用同一套成本模型

第一层

政企单位为什么采购车辆服务？

→ 这是这家公司的商业模式

解决出行保障

第二层

这家公司为什么采购 AI 服务？

→ 这才是我们的价值命题

解决经营管理中的信息准备、判断效率和执行成本

后台

需要完整关系

车辆、客户、部门、项目、合同，按日期保存

前台

不必让人重复填写

能按车辆、业务日期和有效关系带出的，由系统完成

关系缺失或有歧义时，再交给有权限的人

招投标中的市场判断，仍需要人

部分车辆调派由甲方主导，首期不扩成完整调度系统

财务及敏感数据，有安全顾虑

1

什么最影响经营

本案：费用归属不清，历史成本会算错单位

2

什么正在造成重复劳动

本案：先人工筛数据再问 AI；一件事为分类重复提交

3

什么必须先明确规则

本案：历史归属按发生日期；单据、确认、付款分状态

4

什么暂时不适合交给 AI

本案：招投标判断；甲方主导的调派；按金额猜到账对应

A

利润看板

客户最先提的：看盈利

B

单据录入

司机上传照片和票据，AI 提取

C

结算规则整理

把各合同的结算方式写清

有来源

出自哪份合同、哪一条

有适用范围

对哪个客户、哪个项目、哪类车

有生效时间

从哪天起、到哪天止

算出来能解释

结果能追回到规则和原始记录

业务事实

车辆、司机、客户、项目、合同、费用、结算、收付款：关系和状态要清楚

历史记录保留当时依据，不被后改的主数据悄悄覆盖

AI 辅助

OCR 识别文字和候选字段；AI 协助理解材料、归纳信息、提示异常

保留原图、来源和修正记录

证据不足时，允许“不确定”

规则和人

规则：金额计算、权限、状态变化、重复提交控制

人：业务归属、异常解释、付款和责任认定

司机

少填、看得懂

失败后能继续

队长

核对与审核

财务

明细、单据和结算依据

经营者

可追溯的分析结果

尽可能复用现有系统

在授权范围内处理数据

适合本地识别的任务，用本地 OCR

密钥不放到前端；敏感资料按角色控制访问

直接用通用 AI 工具

客户自己试过：先人工筛数据，再逐项提问

字段一多就混淆

这套方案

接得住

客户已有的系统

真实合同的差异

一线的工作方式

原因

原自动化创建记录时，没有映射车辆字段

做法

回到源记录核对；能唯一确定的补齐

不能让 AI 根据上下文猜车牌

留下的 25 条

数量差异、多车辆候选、缺少对应关系：保留证据和人工入口

本地 PaddleOCR 减少了

对按次收费接口的依赖

仍然存在

服务器资源 · 维护 · 人工纠错 · 升级

按角色的示例

异常处理方法

维护说明

1

识别质量

字段认得对不对

2

业务结果

车辆、日期、历史归属、金额、重复提交、权限、失败后能否继续

用正常、异常、重试场景查

3

使用价值

司机少录入、少重复提交；财务少整理、少来回核对；经营者能追到原始依据

4

维护与持续成本

识别失败谁处理、规则变化谁确认、异常怎么发现、数据怎么恢复

说明

这个版本、这批样本的识别结果

不说明

长期准确率承诺

整个 AI 项目的成功率

总金额已经识别出来，却选成了小计

应付金额与实付金额混淆

水印日期被当成业务字段

理解上的突破

“我听懂了”

解释历史费用归属之后

一个功能的价值反馈

结算单自动编号

现场展示，得到认可

整套业务的验收

还没有证据

不能用前两项代替

现有材料支持

部分功能的部署和测试

数据修复

客户对关键设计的理解反馈

价值认知

和收入、成本、现金流、管理负担的关系

本案历史成本会不会算错单位；利润和现金流分开看

流程认知

实际怎样发生、在哪交接、哪里返工

本案单据准备、应收应付确认、实际付款是三个状态

体验认知

不同角色是否更容易完成工作

本案后台关系完整，前台自动带出；司机一次提交

架构认知

数据、规则、权限和历史长期一致

本案按发生日期匹配当时关系；保留原图和修正记录

六纵

让推进不跳步

四横

让局部功能不脱离整体

五性一刻

让技术工作始终连着客户为什么愿意继续

图片不清

参考：改善提交

金额录错

参考：试识别，加复核

合同口径不同

参考：先找确认人

1

写验收清单

按四层（识别质量、业务结果、使用价值、维护与持续成本）各写至少 2 条

每条写：怎么查、谁确认

2

课堂推演：预算减半

哪些可以缩？哪些必须保留？

1

为什么选这个问题？

2

什么时候换方案？

3

什么证据会推翻当前选择？

4

失败时谁接手？