purple痛点三：数据孤岛严重。5个独立系统之间缺乏数据互通机制，同一指标在不同系统中的定义和口径完全不同。数据标准化的工作量远大于AI模型开发的投入。
顾问洞察顾问团队在诊断中总结了一句核心洞察：「问题不在技术，在于人」
行业背景公共服务领域正经历从经验驱动到数据驱动的范式转移。约94%的头部企业已完成第一阶段的AI部署，行业平均效率提升约23%。
gold痛点四：资源错配。管理层希望AI项目不增加预算，用现有团队完成。但现有IT团队在AI领域经验几乎为零，缺乏外部技术支持。人力资源和技术能力的双重不足构成项目最大风险。
变革路线图认知对齐期（0.5-1月）：高管工作坊+AI认知培训+战略共识。快速验证期（3-2月）：选定高频低风险场景落地。价值扩展期（3-7月）：扩展场景+内部推广。运维成熟期（8-11月）：建立持续运营+知识沉淀。
blue痛点二：一线焦虑。员工最关心三个问题：这个系统是来监控我的吗？学会用这个系统算KPI吗？我学不会怎么办？这些担忧如果不解决，任何技术方案都难以推行。
企业概况扎根公共服务领域25年的某气象AI强对流预警，成立于2000年 总部位于华东地区，员工约1632人，年营收约5.9亿元。公司拥有235项核心专利，技术研发团队约11人。
痛点一：需求模糊。管理层说要用AI，但对AI的能力边界缺乏基本认知。三位核心高管对项目预期存在明显分歧——CEO关注品牌提升，CTO关注技术先进性，运营负责人关注效率提升。需求不是从业务问题推导出来的，而是从「别人有我们也得有」的从众心理产生的。
※ 案例信息已脱敏处理。仅供教学参考。以下展示本案例将应用的层面。Step2展开。
通过某气象AI强对流预警深入学习道法术器框架在公共服务企业的实战应用，建立系统的诊断思维。
核心挑战：本案例最大的难点在于客户对AI的认知偏差与组织变革疲劳的双重叠加——这不是技术问题，而是管理问题。
理论概述：区分症状问题和根因问题是顾问的核心能力。症状是客户描述的，根因是顾问发现的。
理论概述：组织变革中成员经历可预测的情绪曲线：震惊→否认→愤怒→讨价还价→沮丧→接受→探索→承诺。
理论概述：组织拥有对变革的内在防御机制。识别并化解这些防御，比推动变革方案更重要。
理论概述：连续追问为什么，但不是机械地问五次，而是在不同深度层面对症下药。
理论概述：情境式、比较式、假设式、过程式、回溯式、前瞻式——六种提问各有适用场景。
理论概述：顾问不是解决方案的提供者，而是客户自我发现的催化剂。真正的变革来自客户自己的认知和承诺。
理论概述：目标（Goal）→现实（Reality）→选项（Options）→意愿（Will），让客户主动探索方案。
不要急着给方案——你的价值在于帮客户发现正确答案
| 层 | 参考问题 | 意图 | 追问 |
|---|---|---|---|
| S1 | 您对这个项目的最高预算和资源投入是什么？ | 了解资源约束和真实投入意愿 | 追问"如果预算不够，您愿意调整范围吗？" |
| T2 | 您能描述一下目前公共服务业务整体的运营情况吗？ | 开放式开场，让客户主动说出全貌 | 等他自然说完后追问"还有吗？" |
| A3 | 你觉得团队对新技术的接受度如何？有没有预见到什么阻力？ | 评估组织变革准备度 | 注意客户是否回避或粉饰这个问题 |
| R4 | 您认为最重要的成功标准是什么？ | 了解客户价值观和优先级 | 注意客户是否过度关注技术指标 |
| S5 | 如果这个项目不做，9个月后会发生什么？ | 建立紧迫感 | 帮助客户认识到不做的风险 |
| T6 | 您对这个项目的成功是如何定义的？ | 了解客户的顶层期望 | 注意是否存在多个不同的成功标准 |
| A7 | 您希望用什么机制来定期评估项目进展？ | 建立持续沟通机制 | 建议每月正式review+每周非正式同步 |
| R8 | 还有没有其他重要的事情我没有问到？ | 收尾开放性问题 | 通常客户会在这里说出最重要的担忧 |
• 客户问"你做过我们行业吗？"——回应"跨行业经验可迁移性强"
• 客户坚持"先说说方案"——引导"好方案源自深入了解，给我30分钟"
• 客户期望不切实际——用对比法"这个目标需要的资源要翻倍"
推荐：《系统思考》丹尼斯·舍伍德
自我检查：建立了足够信任？识别了真正根因？给了客户有价值的洞察？客户愿意继续合作？