一家旅游科技行业的B2B公司的企业AI化日记

一、写在开头

1890年代，电力开始取代蒸汽机。新英格兰的纺织厂是第一批行动的，他们把蒸汽机换成了电动机，效率却几乎没有提升。整整三十年，电力带来的生产力红利迟迟没有兑现。

直到1920年代，一批工厂做了一件更彻底的事：他们把整个工厂推倒重建，重新设计了生产线、工人的分工、机器的布局。这一次，生产力真的爆发了。

吃到红利的，不是第一批换机器的人，而是第一批重构范式的人。

今天，AI正在重演这个故事。每家公司都在谈AI化，都在采购工具、培训员工、上线系统。但"重构范式"到底意味着什么，没有人真正说得清楚。

因为我自己也正在这场风暴之中。所以这篇文章想记录一下我目前正在经历的探索过程：我们在做什么，做到了哪里，以及我看到的那些还没有答案的问题。

二、公司在做什么，我又在做什么

大概背景

我们是一家做旅游科技的公司，业务分为酒店和机票两大块，核心是做分销平台，大家可以理解成一个“批发商”，找供应商收集资源，然后提供平台卖给采购商。至于我呢，岗位是AI产品管培，这个岗是一个toB（Boss）的角色。平时工作直接跟CEO汇报，所以能看到老板的视角。再加上老板招我就是专门拉来做AI创新的。所以公司里和AI相关的事情，我多多少少都会插一脚。

我接手的第一个具体项目，是酒店售后客服中一个"创利"的场景。这个场景里，客服每天需要处理大量来自我们客户的取消申请，并通过邮件往来完成沟通和确认。

在这个场景里，客服需要执行两类操作：

第一类是邮件回复。 根据不同的场景类型，调用对应的邮件模板，把具体的请求字段填进去发出去。这类操作规则固定、边界清晰，有点类似于财务人员按照既定格式填写报销单，只要信息对了，动作本身没有太多判断空间。

第二类是罚金建议。 针对具体情况，客服需要综合取消原因、供应商状态、采购商政策等多个变量，给出一个罚金金额的建议。这类操作没有唯一答案，更像是医生在问诊后给出用药建议。不同经验水平的人，给出的结果会差很多。资深客服和新人之间的表现差距，主要就体现在这里。

这是我们要做AI化改造的场景。

Agent = Model + Harness

在介绍具体做法之前，需要先说清楚我们理解这件事的框架。

Agent = Model + Harness。

模型（Model）是AI的核心，它负责感知、推理和决策，这是它在训练中习得的能力，不是靠外部代码堆出来的。Harness则是围绕模型搭建的一切基础设施：工具、知识、上下文管理、权限边界。两者缺一不可。模型是驾驶员，Harness是车，好的Harness不会试图替代模型的判断，而是给模型一个清晰的环境，让它的能力得以发挥。

理解了这个框架之后，我也需要坦白：我们现在做的方案，还不是真正意义上的Harness工程。我们把模型嵌进了一个相对固化的工作流框架里。它能跑，但它是僵化的，换一个场景就不适用。这是一种暂时性的做法，我自己清楚它迟早需要被迭代。

但这不意味着这一步是浪费的。工作流只是一种形式，把业务逻辑梳理清楚、转化成AI可以读懂的结构，这个内容是可以迁移的。 找到真正适合这个业务场景的Harness，是我们下一步要探索的方向。

流程闭环

我们设计了一套四步闭环：

第一步：业务梳理

在做任何AI化之前，必须先把业务流程图梳理清楚。流程图有明确的输入和输出，规定好这个场景从哪里开始、最后产出什么。这一步听起来简单，实际上是整个范式里最费时间的一步。因为现有的业务流程文档通常都是给人看的，不是给AI看的。所以需要在懂业务的基础上，将现有流程翻译成AI Version。

第二步：环节判别

流程图梳理完之后，需要对每一个业务环节做判别：它是"确定类"还是"概率类"？

确定类，指的是规则可以写死的环节。比如一些特殊地区的酒店，受当地消费者保护政策限制，某些罚金操作是不被允许的。这类规则清晰、无需判断，直接执行。

概率类，指的是语义模糊、需要综合多个变量来判断的环节。"要不要收罚金、收多少"就是一个典型的概率类操作：它依赖于取消原因、供应侧状态、渠道政策等多个因素，没有唯一正确答案。这里是AI真正能发挥价值的地方。

第三步：AI化方案构建

判别完成后，针对确定类和概率类，分别使用不同的技术选型。确定类用工具（Tools）直接处理；概率类用Skills来干掉，通过明确的决策框架约束模型的输出范围。

这里有一个关键动作：让AI学会"判断"。我们的做法是，先根据历史数据把客服人员按经验分级（一般/中等/资深），然后通过问卷和深度访谈，提取不同级别客服在处理罚金时的决策思路，包括好的决策和坏的决策。相当于将厉害的客服和比较一般的客服都给“蒸馏”出来，把这些内容喂给模型，除了让模型知道该怎么想，也知道不该怎么想。

第四步：运营与评估

AI上线之后，真正的工作才刚刚开始。

第一层：人机协作

我们采用Human-in-the-loop的设计。AI在处理每个场景时，不只是给出结果，还会把推理过程一并展示。它看了哪些变量，怎么排优先级，最后为什么得出这个结论。客服拿到的是"答案+解题过程"，而不是一个黑盒输出。客服的工作是审查这个推理过程：方向对不对？变量完不完整？优先级合不合理？发现问题就纠偏。

第二层：数据沉淀

每一次纠偏都会被完整记录下来。这些数据持续回流到模型里，AI从每一次"被纠正"中学习，推理的准确率随着历史数据的积累不断提升。短期内优化推荐质量，长期来看是在训练一个越来越懂业务的模型。

第三层：评分与权重调整

积累了足够的数据之后，我们可以对AI的表现做量化评估。参照前期调研建立的人类baseline，给AI在不同场景下的决策打分。分数决定它在实际业务里承接的权重：初期只做推荐，随着表现越来越稳定，逐步过渡到半自动，最终走向全自动。

第四层：宏观价值评估

从四个维度持续衡量整个AI化项目的价值：人力（释放了多少）、收益（带来了多少）、风险（出错率和数据安全）、成本（模型调用的费用和频次）。这四个维度在项目启动前做一次前置评估，上线后持续复评，发现问题及时调整。

四、这只是起点，不是终点

上面这整套组合拳打完，说句实话：这不是"重构范式"，其实还是在旧有范式下的提速。但我说这句话，并不是在否定我们做的事。

从一开始就找到重构的答案，这个要求本身就不现实。业界没有标准答案，AI化的"正确范式"是什么，没有人知道。先把AI融入现有的工作方式、在实践中积累数据和经验、再逐步探索更深层的可能性，这是一条合理的路径，也是大多数企业正在走的路。

我们公司也在做更大层面的布局。内部搭建了一个类似ClawHub的平台，按照组织架构为每个二级部门设计了对应的数字员工Agent，员工可以为自己的Agent编写Skill，平台通过Gateway与内部系统打通，获取业务字段。与此同时，公司正在推进全员AI培训，愿景是用最少的开发资源，让各部门自主完成业务场景下的规则维护和功能实现。相当于先用AI将对当前的业务降本提效，然后探索数字员工和当前业务的重构。

但如果仔细看，会发现：平台的架构照着现有部门结构搭的，数字员工在模拟现有岗位，Skill在复刻现有流程。这不是批评，这是现阶段的合理选择。但是：现有的架构设计是否是可以同时容纳“人类员工”和“数字员工”？对“数字员工”的考核机制是什么？Agent和Owner有利益关系吗？怎么管理这些“Agent”？他们的产出应该归给Owner吗？如果一个员工造了一个skill/Agent干了很多的活，这个员工应该得到奖励吗？

五、那"重构"长什么样？

我和老板聊过这个问题。他描述了一个关于旅游行业未来形态的想象：

现在的酒店产业链是线性的：从“酒店-->一级批发-->二级批发-->OTA-->消费者”。每一层都在截留信息，用户能看到的，只是最终到达OTA的那个版本。他描述的未来，不是这条链的加速，而是这条链的瓦解。用户通过一个统一的入口。比如一个对话界面：完成出行前、出行中、出行后的所有操作。产业链不再是线性的，而是点对点的直接连接，类似于一种去中心化的结构。

这个愿景，他自己也说还很模糊。但它指向了一件事：重构之后的形态，不是现有链条的加速版，而是链条本身的瓦解和重组。如果这个方向是对的，那么对我们这样的分销商来说，就很尴尬了。中间商的价值，本来就是建立在手里的上下游信息差上。一旦信息变得透明、连接变得直接，中间层最容易被压缩甚至消失。

这让我想到一个更根本的问题：公司AI化，到底是为了省钱，还是为了赚钱？

目前大多数非AI-Naitve的公司做的是前者。但省钱的终点是裁员，它不会创造新的价值。如果我们这个行业的链条真的在瓦解，那降本增效只是在延缓问题，不是在解决问题。

赚钱的路径在哪里？我一个刚刚入行3个月的小白很难给出答案。但我隐约觉得，答案可能藏在AI化过程中积累的那些专有数据里，采购的决策逻辑、踩过的坑、对供应侧的判断。在一个信息越来越透明的市场里，这些东西反而可能是最难被复制的资产。

这只是一个方向，不是答案。