真实变化已经发生：流程岗位正在被 AI 重新定义

这件事不是概念。岗位、项目和组织机制都在把流程管理者推到一个新位置。

头部公司不是多装工具，而是在重组业务流程的最小单元

Uber 的 Agentic Pods 实验更直接：约 30 名熟练使用 AI 的工程师进入多个业务职能，与业务专家组成 Pod，用两周时间把流程片段跑成可用版本。

今天就按这张图走：从一条流程，到一组可运行的 AI 能力

案例说明外部已经在变。回到企业内部，今天只讲一条路径：围绕一条真实业务流程，把 AI 机会点做成可运行、可验证、可持续运营的能力。

先别急着做 AI，先把业务边界说清楚

本步通过标准：负责人在场，范围可控，目标可观察，不做清单写清楚。

例子：本轮只做“客户反馈到评审准备”，不做自动排期、不做客户承诺、不直接改版本计划。

不看想象中的流程，要看现场真实怎么跑

这一阶段要把“流程文件写的”和“现场真实跑的”对齐。这里的流程文件不只是流程图，而是包含流程说明、操作说明、职责、输入输出、例外处理和控制点的详细文件。

关键不是证明流程文件正确，而是用真实样本校正流程、规则和例外。

例子：拿 10 条历史反馈来看，可能发现 3 条缺客户场景，2 条已经在需求池里，1 条涉及重大客户承诺，这些都会改变 AI 的处理方式。

不是什么都做，而是选出第一批真正能落地的节点

这里不做泛泛的机会点头脑风暴，而是确定首批建设边界。

本步通过标准：业务负责人同意首批范围，不做清单被记录，后续不再随意加范围。

不是加一个 AI 节点，而是重新分配流程主语

未来流程要逐步说清楚：

本步产出：正常链路、异常链路、人工断点、系统回写和日志位置。

例子：AI 可以生成“需求澄清清单”，但优先级、排期、对客户的承诺必须由产品经理或业务负责人确认。

先做一个最小可运行能力，不做大而全平台

首批能力包至少包含：

本步通过标准：能跑一条正常样本，缺材料时会追问或停止。

例子：客户只说“导出太慢”，AI 应先追问使用场景、数据量、页面入口和期望时长，而不是直接生成需求结论；客户补齐信息后，AI 再输出“问题摘要、缺失项、相似需求、评审准备清单”。

能力能不能上线，先看资产是否完整

不要急着跑业务样本，先做能力资产检查：

本步通过标准：资产信息不完整，不进入真实样本运行测试。

例子：如果没有写清“哪些信息缺失必须追问、哪些风险必须人工确认”，这个能力就不能进入试用；否则它可能把客户一句抱怨直接写成正式需求。

从“能跑一次”，变成“知道哪里会失败”

10 个用例建议这样配：

逐例记录：输入材料、AI 输出、人工修改、失败原因、风险等级、下一步修复人。只测正常样本等于没有测。

例子：同样是客户反馈，要同时测试描述完整、字段缺失、截图混乱、涉及重点客户承诺四类样本；尤其要看 AI 是否会在承诺风险出现时主动停下来。

不要继续堆功能，先把问题关闭

1. 把失败样本聚类，分清是材料问题、规则问题、提示问题、工具问题还是权限问题。
2. 一次性修整体规则，不要每个 case 打补丁。
3. 用原 10 个用例复测，确认问题是否关闭。
4. 找第二名使用者试用，看是否离开构建者也能跑。

通过标准：严重问题关闭，剩余风险写清；例如分类混淆就补规则，漏客户等级就补材料清单。

做出能力不是终点，有人接管才算进入运营

没有三类资产交接，项目就只是一场演示；有了三类资产，才有后续运营和规模化复制的起点。

例子：交接时要留下需求澄清规则、能力入口、测试样本、失败记录、负责人和复核周期，而不是只留一个页面链接。

从“一个 AI 功能”，变成“可运行的产品”

这部分只讲四类形态：插件、云端智能体、本地端智能体、人机协同平台。学员要记住的是 AI 能力放在哪里、由谁触发、能不能进入流程、能不能自己执行。

一句话总结：产品形态不是越高级越好，而是看它承接的是页面辅助、云端执行、本地构建，还是全流程协同。

插件不是平台，它解决的是“先进入人的工作现场”

插件的价值是轻：不等系统改造，不等接口开放，先让 AI 出现在业务人员正在处理的页面旁边。

例子：产品经理打开客户反馈，插件读取需求描述、客户等级、截图和历史沟通，提示缺失信息、相似需求和承诺风险。

一句话总结：插件适合快跑，但它仍然是人身边的助手，不是组织级流程运行系统。

云端智能体开始进入流程，但必须被权限和日志兜住

云端智能体部署在云端，能接入 API、知识库、流程事件和工具调用。它可以被流程节点触发，也可以围绕一个目标持续推进。

一句话总结：云端智能体的关键不是“会思考”，而是能安全接进流程、调用工具、留下日志、接受人工确认。

本地端智能体更像构建者，适合把想法变成原型和代码

本地端智能体更像构建者：读本地文件、改代码、跑测试、生成页面、整理资料。它对应 Codex、Claude Code、Qoder 这类工作台。

例子：先写清楚需求澄清助手的产品说明，本地端智能体生成原型、插件或评测工作台；跑通后，再决定是否沉淀到云端。

一句话总结：本地端智能体是 AI 能力建设的施工队，不是最终承接企业流程运行的控制台。

固定工作流 vs 目标执行智能体：两种界面完全不同

两种界面不能混着讲：固定工作流解决“按既定步骤跑完”，目标执行智能体解决“围绕目标把事情推进到下一状态”。

先看任务在哪里发生，再决定 AI 放在哪里

对于本课主案例，推荐路径是：插件先验证需求澄清价值；本地端智能体生成原型和评测工作台；云端智能体接入需求池和评审材料；最后把重点客户需求放进人机协同平台。

一句话总结：AI 产品形态的核心选择，不是工具品牌，而是任务发生的位置、触发方式、责任边界和运行深度。

从客户反馈到需求评审，先改一个高频片段

选定流程片段：客户反馈 → 需求澄清 → 需求池查重 → 影响分析准备 → 评审记录 → 行动项跟进。

AI 不替产品经理做承诺，只替他完成可验证的前置工作

这页的重点是边界：AI 可以让专业判断更有材料，但不能替业务负责人承担承诺。

流程 AI 落地最怕六种失真

1. 一开始范围过大，想一次改完整条端到端流程。
2. 没有真实样本，只靠会议印象和流程图。
3. 不敢写不做清单，导致范围不断膨胀。
4. 只画 AI 节点，没有正常/异常链路和人工断点。
5. 只做页面，不写能力边界、输入输出和测试样例。
6. 只测正常样本，不测异常和高风险。
7. 只做演示，没有上线、限定上线或暂缓判断。
8. 没有接管人，能力无法进入 30 天运营。

失败通常不是 AI 不会，而是流程事实、责任、证据和验收被跳过。

例子：如果没有真实缺材料样本，AI 可能每次都硬写结论；如果没有人工断点，它可能把草稿误当最终承诺；如果没有下游接收人，输出再漂亮也没人用。

能力上线后，先证明它能被持续运营

30 天观察期不是继续堆功能，而是证明这项能力能被组织持续运营。

例子：观察需求澄清助手一个月，不只看调用次数，还要看节省了多少澄清时间、减少了多少重复需求、哪些失败样本反复出现。