如何给公司做AI赋能--立项篇
目录
立项篇:先回答”为什么是现在”——标准化率、白屏率,与一个诚实的立项叙事
《给公司做 AI 赋能》系列第 1 篇
大多数 AI 赋能项目,死在立项时讲错了故事
2024 年以来,几乎每个工程团队都被问过同一个问题:“我们能不能用 AI 做点什么?”这个问题本身就是陷阱——它把技术当成了目的。我见过不少项目从”我们要用上大模型”出发,demo 惊艳,试点热闹,半年后悄悄归档。复盘时的死因高度一致:AI 接手的那件事,本来就没有被这个组织真正定义清楚过。
我们的 DE 项目立项时,讲的是另一个故事。不是”AI 很强”,而是一组朴素的观察:SRE 团队每月工作量的大头是变更工单——审核扩容请求、校验配置变更、收集审批证据——其次是告警分诊和跨系统的状态同步杂务。单个任务只要几分钟,加在一起吃掉团队大部分注意力。这类工作高频、有模式、被规则约束,恰好是 AI 擅长的,也恰好是把人烧穿的。
烧穿人的从来不是难题,是重复。立项叙事如果从这里出发,你会发现听众——无论是管理层还是一线工程师——的表情是不一样的:前一个故事里他们是被革新的对象,后一个故事里他们是被解救的对象。
立项前先量两个数:白屏率和 SOP 覆盖率
这是整个系列里我最想让你带走的一条经验:标准化是前提,不是并行任务。
如果一个变更今天还是靠工程师 SSH 到机器上敲凭记忆的命令来执行,那么没有任何 AI 能安全地接手它——不是模型不够聪明,是这件事本身不可见、不可脚本化、不可审计。所以我们在设计文档里写下了一条设计承诺:立项前先测两个就绪指标,而且它们是门槛(gating),不是参考:
-
白屏率:目标团队的操作中,有多大比例已经通过可审计的平台 UI/API 执行(所谓”白屏操作”),而不是黑屏 SSH。
-
SOP 覆盖率:团队的例行程序中,有多大比例已经存在书面的、现行有效的 SOP。技能(skill)本质上是 SOP 的代码化;SOP 不存在或已过时,技能就是建在沙子上。
两个数低,结论不是”上 AI 帮忙管一管”,而是先去做标准化,做完再回来。这个结论在立项会上不讨喜——它意味着某些团队要先做几个月”没有 AI 含量”的脏活。但据我观察,愿意接受这个结论的团队,后来都跑得比跳过它的团队快。AI 赋能里最反直觉的一课:赋能的瓶颈在被赋能的一侧。
“成员,而不是工具”:一个决定了所有后续设计的框架
立项时还要回答一个定位问题:我们做的到底是什么?我们的答案是一张对照表——数字员工是组织成员,不是聊天机器人:
| 人类团队成员有… | DE 的对应物 |
|---|---|
| 名字和角色 | 实例声明里的 identity(编号、团队、职责描述) |
| 明确的责任范围 | scope——它可以操作的服务目录路径,是硬边界不是建议 |
| 学过且考核过的技能 | 版本化的 skill,每个都带测试、经 CI 门禁发布 |
| 对团队实践的了解 | 可检索的知识库(runbook、SOP) |
| 入职期的导师 | escalation 配置里的 mentor——不确定或被卡住时必须上报的人 |
| 有限的权限 | 操作分级 L1–L4:自由读、提议改、毁灭性操作根本不存在对应技能 |
| 绩效评估 | 评估框架:触发测试、安全门禁、端到端回放,加线上成功率追踪 |
| 人事档案 | 完整会话转录(JSONL),可审计、可回查 |
这个框架听起来像修辞,但它有非常实际的后果:DE 的上岗遵循和初级工程师完全一样的弧线——从只读工作开始、在导师密切督导下干活、一个场景一个场景地挣得自主权,并且永远处于可上报、可审计的状态。它把”我们该给 AI 多大权限”这个让所有人焦虑的问题,转换成了每个管理者都熟悉的问题:“你会给一个入职三个月的新人多大权限?”
焦虑消失了大半。因为组织本来就知道怎么带新人。
信任架构:立项时就要能回答”它会不会闯祸”
立项评审会上一定会有人问安全问题,而且问的人越资深越好——这说明有人认真对待。我们准备的答案不是”模型很可靠”,而是三条从构造上成立的机制,后来它们成为整个平台的地基:
-
**范围是硬边界。**每个实例声明自己可操作的服务路径,触碰之外的工具调用被机制性拒绝——不是提示词里的一句”请不要”,是代码里的一个 deny。
-
**操作分级。**读操作(L1)自由执行;变更(L2/L3)需要导师/主管审批;毁灭性操作(L4)干脆没有实现——不存在的能力不需要防御。
-
**提议而非执行。**DE 的”写”是一份结构化的变更提议,提交到组织已有的工单/审批系统;人来批准,确定性的平台代码来执行。DE 进程里不持有任何生产写凭证。
第三条是整个信任架构的基石,也是我建议每个 AI 赋能项目立项时就锁死的一条:把”AI 能不能闯祸”变成”AI 根本没有闯祸的手”。它不依赖模型的品行,只依赖你的架构。
立项时就说清楚:成功不是替换人
最后是立项叙事的收尾,也是我认为最需要人文自觉的部分。我们在愿景文档里写的成功画像是这样的:一个成熟的 DE 用几分钟完成一次变更审核里的取证、算数、填表,产出一份结构化的 pass/warn/fail 评审意见,而决定权留给人——那个人原来要花三十分钟收集信息,现在花三十秒做判断。乘以每月数千张工单,团队把注意力拿回来做工程。
“目标不是替换工程师,是把他们往栈的上层移。“这句话不能只是 PPT 上的漂亮话,它必须变成你后续每一个设计决策的约束——下一篇讲目标定义时你会看到,我们把它直接写进了指标体系:衡量项目的不是”省了几个人头”,而是任务量、成功率、守护栏通过率和”省回来的注意力”。
本篇清单
立项前,请确认你能诚实地回答:
-
我们要接管的工作,高频、有模式、被规则约束吗?能列出具体的任务类别和月度量级吗?
-
目标团队的白屏率和 SOP 覆盖率是多少?低的话,标准化计划在哪?
-
AI 的权限模型用一句话讲得清吗?(“提议而非执行”是个好起点)
-
出事时的责任链是什么?导师是谁?转录在哪查?
-
你的成功叙事里,现在做这些工作的人,是被解救者还是被替代者?
第五个问题没有标准答案,但你的项目能走多远,大概率取决于它。
下一篇:目标定义篇——把”成功”写成可以验收的东西。