当客服工单像雪花一样飘来时
你的客服团队每天要处理 300+ 个 Jira 工单,其中 40% 被分配到了错误的团队。工程师们抱怨说:"我一天要花 2 小时处理不属于我的工单。"Slack 里的求助消息淹没在信息流中,新员工入职第一天就在问:“VPN 账号怎么申请?”——而这个问题的答案已经在 Notion 文档里被回答了 50 次。
这是 Imprint 公司在 18 个月前面临的真实困境。作为一家金融科技公司,他们决定不再只是"买个 ChatGPT 企业版"就算完成 AI 转型,而是真正从 0 到 1 搭建内部 Agent 系统。负责这个项目的,是他们的 CTO Will Larson。
你把 Jira 换成飞书工单/禅道,把 Slack 换成飞书群,把 Notion 换成语雀/Confluence,故事几乎一模一样。
我之所以愿意花时间完整拆解这篇文章,不是因为它来自一位硅谷 CTO,而是因为它解释了一个我在国内企业反复看到的现象:AI 落地失败,几乎从来不是模型问题。
Will Larson 用 18 个月的实战,验证了一个残酷的事实——真正卡死企业 AI 的,是那些最传统、最不性感、最容易被忽视的细节。
残酷真相 1:AI adoption 的第一性原理是"降摩擦",不是"做战略"
采用率的上限,往往由"入职第一天能不能用起来"决定,而不是由战略 PPT 决定。
很多 AI 转型项目的第一步是"开会定战略"。但 Will 的第一步是:花 2-10 小时亲手做一个能调用工具的 Agent。 不是让你成为 AI 专家,而是建立对"什么能做、什么做不到"的直觉。
有了实操经验后,他制定了 AI 落地的核心策略。这套战略的关键是:反对一切只为"看起来在用 AI"的行为。
铺平采用路径:如果团队不用工具,先问"我们让它足够简单了吗?"
核心做法:
- 所有 AI 工具账号入职第一天自动开通 ,无需申请
- 移除一切需要"提交申请-等待审批"的流程
- 默认信任团队,而非默认怀疑
Will 说了一句很扎心的话:
“很多革命性的 AI 采用,其实就是……账号开通和权限管理这些 IT 基础工作。”
这句话在国内听起来甚至有点反直觉。
因为我们习惯把 AI 失败归因于"模型不行"“员工不配合”“业务场景不适合”。大家都在焦虑要不要换更贵的模型、要不要上更多培训。但真正卡死 AI 的,往往是最传统的 IT 细节:新员工入职第二周还在等 AI 工具的账号审批,业务部门提了需求三个月还在走流程。这不是技术问题,是组织问题。
机会无处不在 + 高层以身作则
他们还建了一个跨部门的"AI 技巧库"(Notion 数据库)。价值不在炫耀,而在"跨团队迁移灵感":客服能分类工单,市场就会想能不能分类客户反馈。adoption 的扩散,靠的就是这种"看见—模仿—复用"。
Will 强调:
“在这个充满’AI 作秀’的时代,高层领导亲自深入细节,是我们为数不多的防御手段之一。”
现实中,很多"高层以身作则"的版本,只是高层在全员大会上多说了几句 AI。 真正的以身作则,是愿意为一线用户去修那些看起来"不值得 CTO 花时间"的问题。因为只有这样,你才能知道哪些"小问题"正在杀死你的 AI 落地计划。
残酷真相 2:Prompt 必须变成"公共资产",否则永远是 IT 的玩具
所有 Prompt 存在 Notion,全公司可见,大部分可编辑
这是他们做的第一个关键决策:所有 Agent 的 Prompt 都存在一个 Notion 数据库里,全公司可见,大部分可编辑。
为什么?解决了五个问题:可见性、可学习、可复用、共同所有权、发现系统性问题。
举个例子,他们用来自动分类 Jira 工单的 Prompt 是这样的:
关键设计:回复自动附上 Prompt 链接
他们做了一个非常"产品化"的设计:每次回复都自动附上 Prompt 链接。回复不好?用户不需要吐槽,也不需要提工单——点进去就能改。Prompt 由此从"某个工程师的魔法"变成"组织的公共资产"。
国内的反对声音:这么核心的东西怎么能随便改?
但坦白说,这一步在国内很多公司几乎会天然被否决。
我能想象到的反对声音:“Prompt 怎么能随便改?万一出事谁负责?”“这么核心的东西,必须要有权限控制。”
这些担忧不是没道理。但问题是:如果你不允许业务团队编辑 Prompt,那他们永远不会真正用起来。 他们会把 Agent 当成"IT 部门的工具",有问题就提工单,而不是自己动手优化。最后的结果就是——AI 永远停留在 demo 阶段,永远在"等 IT 有空"。
解决办法:可控的三层权限设计
解决办法不是"全放开"或"全封死",而是做一个可控的三层权限:
- L1:所有人可见(让 Prompt 变成组织知识)
- L2:领域 Owner 可编辑(客服/HR/运营各自负责自己的 Prompt)
- L3:平台层强约束不可编辑(权限、数据访问、格式化、安全策略写进框架)
这样业务能改"表达方式",平台控制"安全边界"。你才能同时得到:迭代速度 + 风险可控。
前提是:平台层必须把"权限、数据访问、审计、回滚"做成默认能力,否则开放编辑就是在赌运气。
残酷真相 3:工程细节决定生死——外键、格式、日志是采用率的地基
一个看似简单的噩梦:用户名解析
你以为最难的是模型,其实最难的是把一个"@张三"变成系统能识别的 ID。在 Slack 里,@Will Larson 这种写法,API 根本不认,它只认 <@U12345>。
听起来简单?实际上:
Slack 用户有三种名称: 显示名、用户名、真实姓名。而且每个用户设置的字段不一样!如果你"找到第一个匹配就返回",会在某些场景下匹配到错误的人。
正确的逻辑是:先匹配显示名,没找到再匹配用户名,还没找到再匹配真实姓名。
Will 为此开发了三个工具,还加了一个"最终强制检查":Agent 生成回复后,系统会验证所有引用是否真实存在。如果不存在,会把错误信息注入上下文,让 Agent 重新跑一遍。
他自己都说:“这感觉很荒谬,但只有做到这一步,才真正稳定下来。”
双通道日志:给工程师看 Datadog,给业务看 Slack
他们搭建了一个双通道日志系统:
通道 1:Datadog - 完整的工程日志,给开发者和平台团队看
通道 2:Slack#ai-logs 频道 - 简化版日志,让非工程师能理解"Agent 在做什么"
Will 的答案很现实:
“开发 Agent 的人愿意接受一点粗糙的工具。而不开发 Agent 的人,他们只想要工具完美运行,根本不会花时间看日志。”
这就是务实主义:不追求完美的监控系统,而是用最快的方式满足当前需求。
格式化陷阱
Slack、Jira 各有各的"格式方言",渲染错一次,用户的信任就掉一截——所以格式化必须从 Prompt 上移到框架层解决。
成功案例:工单路由错误率从 40% 降到 5%
Jira 工单自动分类 Agent:
- 读取工单内容和评论
- 查询内部文档
- 确定应该由哪个团队处理
- 自动打标签并 @ 对应团队的 oncall 人员
效果: 错误分配率从 40% 降到 5%。
类似的场景还包括:
- Slack 新人答疑:常见问题 30 秒内自动回复
- 基础设施请求处理:团队被打断时间 -60%
尾声:理性的非采用者 + 三问
Will 每月至少看一次工具使用数据,重点关注两个问题:
- 对于重度用户: 他们到底在做什么?为什么觉得有用?
- 对于低/非使用者: 为什么不用?我们能帮他们解决什么?
他的假设是:
“不采用工具的人是理性的非采用者。 花时间理解这种’阻力’,比自上而下的强制推行更有效。”
大多数"不用 AI 工具"的情况,往往只是教育缺口,而不是抵触情绪:不知道这个工具能解决他们的问题、不知道怎么开始用、遇到了一个小障碍就放弃了。
如果你要在组织里启动 AI adoption,我建议只做 5 件事:
- 把"入职即开通"做成默认(账号/权限/入口)
- 选一个高频痛点先打穿(工单路由/重复问答)
- Prompt 公共化,并建立可控编辑机制(三层权限)
- 把最烦的工程细节做成框架能力(外键/格式/审计)
- 每月只盯两类人:重度用户在干嘛?不使用者卡在哪?
如果你也在负责公司的 AI 转型,不妨问自己三个问题:
- 我自己用过这些工具吗?真的用过吗?
- 我们在解决真实的业务痛点,还是在追赶潮流?
- 我们有没有花时间理解"为什么有人不用",而不是只看"有多少人在用"?
这三个问题,本质上是同一个问题:
你是否真的愿意为一线体验负责?
如果答案是否定的——如果你只是想在 PPT 里加几页 AI 战略、在预算里加一行 AI 工具采购、在 KPI 里加一个 AI 使用率——那不管你选 GPT-4、Claude 还是 Gemini,结果都不会有本质区别。
AI 落地从来不是"买什么工具"的问题,而是"谁真正在乎用户用不用得起来"的问题。
Will Larson 的经验告诉我们:这个人,必须是高层。而且必须愿意深入到那些看起来"不值得花时间"的细节里。
这很难。但这也是唯一的路。
写在最后
这篇文章基于 Will Larson 的原文整理,但我加入了很多自己的判断和对比。如果你想看原汁原味的工程细节,可以直接读原文(链接见下方)。那里面还有更多关于 MCP 配置、日志系统设计、模型选择的技术讨论。
但如果你想知道"为什么国内企业的 AI 落地这么难",我希望这篇文章给了你一些答案。
参考资料: 本文基于 Will Larson 的文章《Facilitating AI adoption at Imprint》整理而成,点击「原文链接」访问原文。