如何在公司内部推动 AI 转型——不只是技术问题
如何在公司内部推动 AI 转型——不只是技术问题
2023 年底，我接到一个活儿——帮一家做金属制造的公司评估 AI 转型方案。
公司老板是个 58 岁的浙江人，做了 30 年钢材，厂子有 600 多工人，年营业额过亿，但利润率越来越薄。他儿子在外面见了一些 AI 的东西，回来跟老爷子说：AI 可以帮咱们降本增效，应该做。老爷子半信半疑，托人介绍，找到了我。
我去了一趟，在工厂里待了两天。
第一天，我和几个中层管理者开了个座谈会。销售总监直接问我："AI 是不是要替代我们的销售团队？"仓储主管说："我们用 Excel 管库存几十年了，你让我们换系统，万一出问题谁负责？"IT 部门的小伙子则显得很兴奋，但他的兴奋很快被同事们的沉默压下去了。
这就是我见过的、最典型的企业 AI 转型现场。
技术从来不是最难的那部分。
推动 AI 转型的三层阻力
在开始讲怎么推之前，先把阻力的来源说清楚。这些阻力如果不理解，技术方案做得再好也没用。
管理层的阻力：看不到明确的 ROI
大多数传统企业的老板，做决策的逻辑是：投入多少，回报多少，多久回本。
"AI 很强大"这句话对他们没用。他们需要的是："我们做这件事，花 50 万，预计 18 个月收回成本，因为 XXX 流程的效率提升了 40%，对应减少了 3 个人力"。
管理层阻力的本质，是你给他们的方案还不够具体，或者你在讲技术他们听不懂。这是信息不对称问题，不是他们保守。
我在那家制造企业，在第二天的汇报会上，没有 ppt 里一页画大模型架构，而是直接拉了一个 Excel，把他们现在的生产计划排程流程里每个环节的时间成本全列出来，然后说："这个环节，用 AI 预测排程，可以把从接单到排产的时间从平均 4 小时压到 40 分钟，保守估计每年节省的生产等待成本是 XX 万。"
老板当场有兴趣了。
业务方的阻力：不是反对 AI，是担心自己
销售总监问的那句话——"是不是要替代我们的销售团队"——才是业务方阻力的核心。
人们害怕失去工作、害怕被重组、害怕新系统上线后自己不会用、害怕出了问题被追责。
这种阻力不是靠讲道理可以消除的。你要做的，是把业务方从被 AI 影响的对象，变成 AI 项目的受益者和参与者。
具体来说：
- 让销售总监自己定义 AI 能帮他们做什么，而不是由你告诉他们 AI 能做什么
- 第一个 AI 项目，明确表达是为了让销售团队更轻松，而不是减少人数
- 让业务方参与需求定义和验收，让他们有主人翁感
我在那家工厂，后来第一个项目切入点是"销售报价辅助"——帮销售人员快速生成客户报价单，减少他们手工查价、算利润的时间。销售总监从质疑者变成了最积极的推动者，因为这件事直接让他的团队每天少加两小时班。
同事的阻力：沉默的多数
同事的阻力是最隐性的。他们不会站出来反对，但会用各种方式消极配合：不提供真实数据、反馈问题拖延、测试阶段找各种理由说效果不好。
这种阻力来自两个源头：一是不理解，不知道 AI 系统会对自己的工作有什么影响；二是不信任，觉得这是上面折腾人的事，过一阵子就过去了。
解决方法是提前沟通，而不是事后解释。在项目启动前就找关键的基层员工做深度访谈，了解他们真实的工作流程和痛点，然后把这些痛点纳入项目目标。这样他们会觉得被尊重，也会更愿意配合。
从小项目切入：不要一上来就做大
这是我踩过坑才总结出来的原则。
我见过太多企业 AI 转型方案，第一步就是"建立企业知识库"，"全面上线 AI 助手"，"替换现有业务系统"。
这些方案大多数死在了：需求不清晰、数据质量太差、落地验收没有明确指标、一旦效果不理想就被全盘否定。
正确的路径是从一个具体的、可验证的小场景切入，快速交付，用结果说话。
选小项目的标准：
- 痛点清晰——业务方自己知道这里很痛，不需要你解释
- 数据可得——不需要大规模数据清洗就能启动
- 效果可量化——有明确的前后对比指标
- 影响面小——失败了不会影响核心业务
几个适合大多数企业的小切入点：
FAQ 智能问答：把企业内部常见问题文档化，搭一个基于 RAG 的内部问答 Bot，让员工不用每次都去找 HR 或者翻文档。
合同/文档辅助审阅：销售合同、采购合同里的关键条款提取，用大模型做初筛，让法务审核更高效。
会议纪要自动生成：把会议录音转文字，再用大模型提炼结论和 action items，这是效果最立竿见影、接受度最高的场景之一。
报表自动解读：BI 系统已有数据，让大模型做自然语言解读，管理层不用看一堆图表。
讲业务价值，不讲技术方案
这是我在内部推 AI 项目时最核心的沟通原则。
我见过很多技术同学，在给业务方或者管理层汇报时，ppt 第一页就是技术架构图：RAG pipeline、向量数据库选型、Embedding 模型对比。
业务方看到这些东西，眼睛是空的。他们不在乎你用的是 Milvus 还是 Qdrant，他们在乎的是：这件事做了，我的什么问题解决了，能省多少时间，能减少多少错误，能让我的 KPI 好看多少。
我在推那家制造企业的 AI 项目时，每次汇报都用这个结构：
- 问题是什么（用业务语言，不用技术语言）
- 我们现在的方案（一句话概括，不展开技术细节）
- 预期效果（量化）
- 需要业务方配合什么（具体到人和时间）
- 风险和预案（让他们放心）
技术方案的细节，只在技术评审会上讲，不拿到业务方会议上占用时间。
真实案例：在一家传统制造业公司推 AI 的完整经历
让我把那家制造企业的故事讲完整。
第一个月：建立信任
我做的第一件事，不是写代码，而是和 8 个关键人做了一对一的深度访谈，包括销售总监、仓储主管、生产排程负责人、IT 小伙子、两个一线销售、两个仓库员工。
每次访谈，我不讲 AI，只问：你们现在最痛的是什么？每天最花时间的是什么？经常出错的地方在哪里？
这 8 次访谈下来，我整理了一张"业务痛点地图"，按照影响程度和可解决性做了排序。
最高优先级的问题是：报价单生成流程。
销售每次接到新询价，需要手工查历史订单价格、查原材料价格、算运费和利润，一个报价单平均要花 45 分钟到 2 小时，而且经常因为查到的价格不是最新的，导致报低了价格，损失利润。
这个问题，全公司 8 个销售，每个人每天平均做 3-5 个报价，每年因为报价错误损失的利润保守估计在 30 万以上。
第二个月：最小化原型
我用了 3 周做了第一版原型：用 Python 接入公司的历史订单数据库（主要是 MySQL），构建了一个简单的 RAG 系统，允许销售用自然语言描述询价需求，系统自动检索历史类似订单价格，生成报价草稿，同时拉取当天的原材料价格（接了一个数据源 API）。
代码结构大致如下：
# 核心流程：报价辅助生成
class QuoteAssistant:
def __init__(self):
self.vector_store = MilvusClient(uri="./local.db")
self.llm = OpenAI(model="gpt-4o-mini")
self.embedder = OpenAIEmbeddings()
def generate_quote_draft(self, inquiry: str, customer_info: dict) -> dict:
# 1. 检索历史相似订单
similar_orders = self._retrieve_similar_orders(inquiry)
# 2. 获取当前原材料价格
current_prices = self._get_current_material_prices(inquiry)
# 3. 构建报价上下文
context = self._build_context(similar_orders, current_prices, customer_info)
# 4. 生成报价草稿
prompt = f"""
你是一个金属材料的报价专家，请根据以下信息生成报价草稿：
询价信息：{inquiry}
历史参考订单：{context['similar_orders']}
当前原材料价格：{context['current_prices']}
客户等级：{customer_info.get('level', '普通')}
请生成：
1. 建议单价（含合理利润区间）
2. 价格依据说明
3. 需要人工确认的风险点
注意：这是辅助草稿，最终报价需要销售人员审核确认。
"""
response = self.llm.invoke(prompt)
return {
"draft_price": response.content,
"reference_orders": similar_orders[:3],
"confidence": self._calculate_confidence(similar_orders)
}
def _retrieve_similar_orders(self, inquiry: str) -> list:
inquiry_vector = self.embedder.embed_query(inquiry)
results = self.vector_store.search(
collection_name="historical_orders",
query_vectors=[inquiry_vector],
limit=10,
output_fields=["order_id", "product_spec", "unit_price", "quantity", "date"]
)
return results[0]原型做好之后，我没有全员推广，而是只找了两个愿意尝试的销售，让他们用了一周，然后每天收集反馈。
第三个月：优化和正式上线
根据两个销售的反馈，主要的问题有两个：
- 历史订单的语义描述不规范，导致检索结果偏差较大（比如"Q235 钢板"和"低碳钢板 Q235"是同一种东西，但向量相似度较低）
- 生成的价格草稿格式不统一，销售还要手工整理
解决第一个问题，我加了一个产品规格标准化的预处理层：先用大模型把各种不规范的产品描述转为标准格式，再存入向量库。解决第二个问题，就是固定输出格式，加了个结构化输出的要求。
from pydantic import BaseModel
from typing import Optional
class QuoteDraft(BaseModel):
product_name: str
spec: str
suggested_unit_price: float
price_range_low: float
price_range_high: float
price_basis: str
risks: list[str]
confidence_level: str # "高" | "中" | "低"
needs_manual_review: bool
# 使用 structured output
response = self.llm.with_structured_output(QuoteDraft).invoke(prompt)正式上线后，8 个销售全部接入，用了 3 个月的数据对比：
- 平均报价时间从 78 分钟下降到 22 分钟，降幅 72%
- 因价格判断失误导致的利润损失，3 个月内为零（虽然样本量不大）
- 销售团队满意度：8 个人有 7 个表示"明显有用"
老板看到这个数据，主动问：还有哪里可以做？
这就是我说的路径：一个小项目，用结果建立信任，然后自然扩展。
内部推广的节奏控制
成功的第一个项目之后，很多人容易犯的错误是：急着把 AI 推广到所有场景，雄心勃勃地规划整个公司的 AI 转型蓝图。
这往往是失败的开始。
我的建议是：让成功案例自己说话，让业务方来找你，而不是你去找他们。
当报价辅助系统的效果出来之后，仓储主管主动来找我，说他们也有类似的问题——盘点准确性差，每次盘点要花三四天时间。这时候你再做第二个项目，成功率会高很多，因为对方是带着真实需求来的，而不是被你说服来配合你的。
推广的节奏：
- 第一个月：小场景验证，内部小范围测试
- 第二到三个月：迭代优化，收集量化效果数据
- 第四个月：向管理层汇报，让成功案例可见
- 第五到六个月：让第一批受益的业务方去跟其他部门讲效果，不是你去讲
- 第七个月以后：根据自然产生的新需求，按优先级推进
一个反面教材
说完正面的，再说一个我亲眼看到失败的案例。
某个中型保险公司，技术团队花了 6 个月，搭了一套"AI 智能核保系统"，号称可以用大模型辅助核保员判断保单风险。
系统上线那天，核保部门的主管看了演示，问了一个问题："如果 AI 判断有误，出了赔付问题，责任在谁？"
技术团队没有准备好这个答案。
会议室陷入沉默，然后散会了。这个系统此后的命运，就是被搁置在内网服务器上，偶尔有人演示用，但从没真正用于实际业务。
这个失败的根本原因，不是技术问题。是在整个 6 个月的开发过程中，技术团队从未认真解答业务方最核心的担忧：这件事出了问题，谁负责。
责任归属、容错机制、人工覆盖路径——这些不是技术问题，但没有这些，任何 AI 系统在高风险业务场景里都推不下去。
写在最后：推动 AI 转型，需要工程师扩展自己的边界
作为一个技术人，我在做这件事的过程中，深刻感受到：光懂技术是不够的。
你需要能和业务方说他们听得懂的话，需要理解人在组织变革面前的心理，需要有足够的耐心在第 N 次解释后还保持清晰，需要在遇到阻力时不气馁。
这些都不是技术能力，但都是推动 AI 转型的核心能力。
我见过一些技术能力非常强的工程师，做出来的 AI 系统很好，但因为沟通方式不对，项目最终没有落地，也没有产生业务价值。这是很可惜的。
如果你现在在公司里想推 AI 项目，我的建议只有一句话：先找到一个业务方真正在痛的问题，做一个小的、能快速出结果的东西，然后让结果替你说话。