第 1 章 企业 AI 为什么难以稳定产出
企业使用 AI 时，常会同时出现两种体验：一些个人任务的初稿、整理或查询速度提高了；同一套做法进入多人协作、关键流程或持续运行后，却出现输出波动、审核负担、知识失效、责任不清或难以复用等问题。这两种体验并不矛盾，因为个人效率改善与组织稳定产出衡量的是不同层次的结果。
本章不试图用单一比例判断“企业 AI 成功率”，也不把个别企业案例外推为普遍规律。它说明一类常见的结构性问题：当组织只引入工具而未同步定义任务、数据、验证、责任和运行控制时，局部收益未必能转化为可重复的业务结果。
一、个人提效不等于组织稳定产出
个人层面的 AI 使用，通常围绕一项即时任务展开：写邮件、整理会议纪要、准备初稿、转换格式、生成代码建议或辅助检索。使用者可以凭个人经验补足缺失信息、判断输出是否可用，并在结果不理想时自行重试或放弃。
组织层面的用例则需要面对更多条件：输入由谁提供、规则何时更新、错误如何发现、谁有最终决定权、输出是否可以发送或写入、多人能否复现、发生异常时是否能够回退。若这些条件没有被设计出来，某个人的熟练操作通常难以稳定迁移给团队。
| 维度 | 个人任务辅助 | 组织稳定产出 |
|---|---|---|
| 主要目标 | 完成一次任务，提升个人效率 | 持续产出可复核、可维护的业务结果 |
| 输入与知识 | 由使用者即时补充和判断 | 需要明确来源、版本、权限与更新责任 |
| 输出处理 | 使用者自行采用、修改或放弃 | 需要定义验证、人工确认、发送/写入边界与记录 |
| 责任 | 主要由单一使用者承担 | 需要业务、知识、技术和风险等角色协同 |
| 变更与异常 | 临时调整或重新尝试 | 需要回归、发布、Runbook、人工备用与复盘 |
| 成功证据 | 一次输出可用或节省时间 | 质量、价值、风险、采用和运行证据共同支持阶段决策 |
因此，本书所说的“稳定产出”并不是要求每次输出完全相同，也不是要求自动化率最大化。它指的是：在已定义的范围内，组织能够解释结果从何而来、如何验证、谁负责、何时暂停，以及怎样在变化或异常后恢复。
二、企业采用的常见起点与相应风险
企业的采用路径不止一种。以下三种起点可以并存；它们不是优劣排序，而是提醒团队识别需要补齐的条件。
| 起点 | 常见优势 | 常见缺口 | 应优先补齐的机制 |
|---|---|---|---|
| 自上而下 | 资源、方向和跨部门协调相对容易获得 | 容易把工具采购或使用量误当作业务结果 | 用例立项、业务 Owner、阶段闸门和价值证据 |
| 自下而上 | 更贴近一线任务，容易发现具体痛点 | 资产分散、数据边界不清、难以复用 | Skill/工作流资产、知识责任、风险初筛与组合台账 |
| 混合推进 | 既有资源支持，也有真实任务反馈 | 如果决策权和接棒责任不清，仍可能形成双重管理 | RACI、共创交付、验收与能力移交 |
工程、运营、客服、销售或其他职能都可能成为先行者，取决于任务结构、数据条件、专业风险和业务 Owner 是否愿意参与。与其预设哪个部门一定领先，不如从低风险、高频、可验证且人工备用可行的用例开始，用实际证据决定下一步。
三、结果难以稳定的四类结构性原因
1. 预期与证据错位
当组织把“模型能力提升”“账号开通”或“单次演示效果”直接视为业务收益时，项目目标容易失焦。管理者可能期待短期节省或规模化，使用者则更关心输出是否可靠、审核是否增加负担、发生错误后由谁处理。若成功标准、停止条件和证据口径没有事先约定，不同角色即使都在投入，也可能对项目状态作出相反判断。
应对方向：先用用例立项卡定义业务问题、当前基线、边界、成功/停止条件与下一决策；再用实际评测和运行记录讨论是否扩大，而非用调用量或宣传性指标替代业务证据。
2. 能力边界与任务风险错位
大模型能够生成、整理、分类和辅助推理，但输出并不天然等于事实、规则或最终决定。输入不完整、知识过期、任务目标模糊、上下文变化、模型或工具版本变化，都可能影响结果。多步骤流程和工具调用还会把错误传递到后续环节。
应对方向：根据结果容错率、信息完整性、可验证性、行动影响和回退能力确定 AI 的参与深度。对外沟通、写入、敏感数据、高影响决策或高自主性用例，应提高人工控制、风险评估、证据和回退要求。第 3、9、14 章分别说明能力边界、Agent 治理和风险控制。
3. 工具引入与流程设计错位
如果只在原有流程上增加“让 AI 生成”这一步，任务拆解、输入准备、验证标准、例外处理和结果沉淀仍然缺失，AI 往往只会加快某个局部环节，而无法减少整体摩擦。有时，额外的审核、格式转换和沟通成本会抵消局部节省。
应对方向：将高频任务逐步封装为 Prompt、Skill、固定工作流或受控 Agent；同时明确输入输出契约、质量 Rubric、人工控制点、异常路径、版本、Owner 和回退方式。是否采用 Agent 应由任务和控制条件决定，而不是由工具功能决定。
4. 一次性试点与持续运营错位
试点完成后，知识会更新，模型、工具和权限会变化，人员也会轮换。若没有 Golden Set、回归报告、发布登记、健康卡、Runbook 和移交机制，团队很难判断质量变化来自何处，也无法在异常时安全暂停、恢复或转人工。
应对方向：把试点看作运营起点，而不是项目终点。用例在扩大前应完成必要的风险初筛、评测、发布、观察和接棒验证；不满足条件时，缩小范围、修复或停止都是合理决策。
四、从“使用工具”转向“经营用例”
企业 AI 落地的基本单位不是模型账号，而是一个有明确业务目的、边界、Owner、控制与证据的用例。围绕每个用例，组织需要持续回答以下问题：
- 业务问题是否真实存在，当前基线和成功标准是什么？
- 哪些输入、知识、模型、工具、权限和人员依赖会影响结果？
- 输出由谁审核、谁决定采用、哪些动作必须禁止或转人工？
- 发生知识、版本、工具或人员变化时，如何评测、发布、回退和通知？
- 用例是否持续产生足以支持扩大、维持、修复或退役的证据？
这些问题不会让项目变慢。相反，它们帮助团队在投入更多资源前发现范围、控制和责任上的缺口，并将讨论从“某个工具好不好用”转向“这个用例是否值得、是否可控、是否可以持续运行”。
五、本章小结
企业 AI 难以稳定产出，通常不是由单一模型能力决定，而是由预期、任务、知识、流程、责任和运营控制之间是否匹配决定。个人提效可以成为起点，但只有当组织把这些要素转化为可复核的资产和运行机制时，局部改进才可能形成稳定的业务能力。
下一章将从自诊断开始，帮助团队定位当前最优先需要修复的层面。