夜雨聆风最容易的 AI 转型，是给员工买设备。最容易失败的，也是这一种。
一家公司采购一批适合移动编程、随时调用大模型的设备，给研发、销售、运营和管理层统一配发。发布会上看起来很像一次生产力升级：终端更轻，模型更强，调用更方便，员工随时可以把 AI 带进工作现场。
但几个月后，很多设备只是变成了更贵的办公电脑。有人用来写邮件，有人用来整理会议纪要，少数技术人员拿来写代码。效率可能提升了 10%，甚至 20%。可公司的交付方式、部门边界和管理动作几乎没有变化。
问题不是工具不够好，而是采购发生在最容易改变的一层。真正难改的东西，还留在原地。
设备热潮，本质上是最轻的一次组织改造
企业喜欢从采购开始做 AI 转型，因为采购是一个边界清楚的项目：有预算，有型号，有数量，有交付日期，也有负责人。买 100 台设备，比重写 100 个岗位的工作流程容易得多。
这和二十年前的企业信息化很像。买服务器、上 ERP、装 CRM 都不难。难的是让销售如实录入客户进度，让仓库按新规则流转，让财务接受数据口径变化，让管理者放弃一部分过去依靠经验完成的判断。
AI 设备也是一样。它看似在购买生产力，其实只是在购买生产力的互补品。
真正的 AI Native，不是员工手边多了一个能回答问题的助手，而是公司开始允许 AI 参与交付。它能接到定义清楚的任务，拿到必要的上下文和权限，产出可验证的结果，并且在出错时被追溯到明确的责任边界。
少一个环节，AI 就只能停留在聊天框里。
买完没人用，不一定是员工保守
很多管理者会把使用率低归因于员工习惯。于是公司做培训、发教程、设立 AI 使用次数指标，甚至要求每周提交提示词案例。
但员工通常比管理层更早发现一件事：如果原来的验收方式不变，AI 只是在制造额外工作。
例如，销售可以让 AI 自动整理客户沟通记录、生成跟进建议。但如果客户资料散落在微信、邮件和 CRM 里，AI 没有权限读取；如果最后仍然要销售逐字检查、手动录入、自己承担全部误差，AI 就只是多了一道中间步骤。
客服也一样。AI 可以生成回复，但如果知识库半年没有更新，退款权限没有分级，复杂问题没有清晰的转人工条件，那么回复越快，返工可能越多。
员工抵触的未必是 AI。他们抵触的是一套没有减少责任、却增加操作步骤的伪自动化。
这里有一个反转：企业缺的不是更多 AI 工具，而是一套允许 AI 真正参与交付的工作制度。
四个瓶颈，决定 AI 能不能离开演示环境
第一个瓶颈，是任务定义。
很多部门习惯用模糊语言分配工作：“整理一下客户情况”“优化一下页面”“看看这个需求怎么做”。人类员工可以靠经验补齐上下文，也可以在会议里反复确认。AI 不行。AI 会把模糊任务做得很快，但不一定做得对。
AI Native 的第一步，不是写更长的提示词，而是把工作改造成可交付的任务单：输入是什么，输出是什么，约束是什么，完成标准是什么，遇到例外时交给谁。
第二个瓶颈，是权限。
AI 要真正干活，必须读取资料、调用系统、写入结果。但多数企业的权限设计只有两档：能看，或者不能看；能改，或者不能改。对于 AI 来说，这太粗了。
真正需要的是分层权限：哪些数据可以读取，哪些动作可以自动执行，哪些修改必须人工审批，哪些敏感操作需要双重确认。没有权限改造，Agent 只能成为一个聪明的旁观者。
第三个瓶颈，是验收。
过去的管理方式，是盯过程：人是否在线，日报是否提交，会议是否参加。AI 参与交付后，过程会变得更便宜，也更难观察。管理必须转向结果：准确率、覆盖率、响应时间、返工率、异常升级率。
例如客服试点，不要只看 AI 回复了多少条，而要看一次解决率是否上升、投诉率是否变化、人工接管是否集中在少数问题类型。没有可验证的验收指标，管理者只能靠感觉判断 AI 有没有用。
第四个瓶颈，是责任边界。
AI 出错时，谁负责？是使用 AI 的员工，是批准上线的主管，是维护知识库的部门，还是提供模型的厂商？
这个问题不能用一句“最终由人负责”敷衍过去。所有责任都压回一线员工，员工就不会把关键任务交给 AI。所有责任都推给技术部门，业务部门就不会认真维护规则。真正有效的制度，是把错误拆成可追溯的类型：任务定义错误、数据错误、模型错误、审批错误、执行错误。不同错误，落到不同责任人。
部门改造，不是先问能不能用 AI
以销售跟进为例，传统做法是给销售配一个 AI 助手，让它写跟进邮件。更好的做法，是重画整个流程。
客户会议结束后，录音自动转写；AI 按统一字段提取预算、决策人、时间表和风险点；低风险跟进邮件自动生成；涉及价格承诺、合同条款的内容进入主管审批；CRM 自动写回；超过三天没有动作的客户进入提醒队列。最后验收的不是“销售用了多少次 AI”，而是 CRM 完整率、跟进及时率和有效商机转化率。
内部知识库也是如此。不是上线一个问答机器人，而是先规定哪些文档是有效版本，谁负责更新，答案引用什么来源，置信度低于多少必须转人工，错误答案如何回流修正。
研发验收更典型。买了编程设备，不等于研发效率自然提升。真正的改造是把需求拆成更小的可验证单元，补齐测试，明确代码审查规则，让 AI 生成的代码能够进入一条可控的验收流水线。
设备只是入口。流程才是杠杆。
一份 30 天试点清单
AI 转型不需要一开始就覆盖整个公司。选一个高频、可量化、风险可控的流程，用 30 天跑通闭环更重要。
- 第 1 周：选定一个流程，记录当前基准。统计耗时、返工率、错误率和人工介入次数。
- 第 2 周：把任务拆成标准输入、标准输出、异常条件和验收指标。只开放必要权限。
- 第 3 周：让 AI 参与真实交付，但保留人工审批。每天复盘失败案例，区分任务、数据、模型、审批和执行错误。
- 第 4 周：只放开低风险动作的自动执行。比较试点前后数据，决定扩大、修改还是停止。
30 天后，管理层真正需要看的不是调用次数，也不是员工写了多少提示词，而是三个问题：交付周期有没有缩短，返工有没有下降，责任是否仍然清晰。
如果答案是否定的，再买一批设备也不会解决问题。
公司是否 AI Native，不取决于员工桌上放着什么，而取决于组织敢不敢把工作重新定义成可托付、可验证、可追溯的交付系统。
