先给结论：企业准备做 AI 自动化时，第一步通常不是选模型、买工具或接 API，而是把现有流程画清楚。至少要知道什么事件触发流程、输入从哪里来、谁做判断、哪些动作必须人工批准、最后输出到哪里，以及失败时谁接手。这些信息不清楚，自动化项目很容易变成“把混乱流程搬进系统”。
一张好的 Workflow Map 不需要画得复杂。它的作用不是做漂亮的流程图，而是帮助团队回答一个更重要的问题：这个步骤到底应该继续由人做、改成固定规则、交给 AI 辅助，还是通过系统 Integration 自动执行？
为什么很多 AI 自动化项目不应该从“选工具”开始
当团队先看到 Chatbot、AI Agent、Automation Platform 或某个新模型时，很容易反过来找工作给工具做。但业务流程真正的限制通常来自另外几件事：输入不完整、规则没有写下来、不同员工处理方式不一致、系统没有权限连接、异常发生后没有负责人，或者某个动作本来就需要人工判断。
如果这些问题没有先被拆开，换成更强的 AI 也不会自动让流程变得可靠。更实际的顺序是：
Current Workflow → Process Boundary → Decision Rules → Human Approval → Integration Feasibility → AI Role → Pilot
Social Plus System 的中文 AI Automation 服务页也采用类似原则：先梳理真实 Workflow，再决定哪些部分用规则、哪些需要 Integration、哪些适合 AI，以及哪里必须保留 Human Approval。
一张 Workflow Map 至少写清楚这 7 个字段
下面这 7 个字段不是行业标准，而是一套用于项目讨论的实用模板。团队可以放进文档、Spreadsheet、白板或需求说明书中，不需要先购买流程设计软件。
| 字段 | 要回答的问题 | 常见遗漏 |
|---|---|---|
| 1. Trigger | 什么事件让流程开始？例如收到 Lead、表单提交、订单状态变化、固定时间到达。 | 把“员工想起来就做”当成 Trigger，导致自动化没有明确起点。 |
| 2. Input | 流程需要哪些数据？从哪里来？哪些字段是必填？ | 没有定义缺字段、重复数据、格式错误怎么处理。 |
| 3. Steps | 从开始到结束，人和系统实际上做了哪些动作？ | 只写理想流程，没有记录复制粘贴、等待、确认和补资料。 |
| 4. Decision | 哪些地方需要判断？判断依据能不能写成规则？ | 把员工经验一句“看情况”直接交给 AI，却没有拆出判断条件。 |
| 5. Approval | 哪些动作执行前必须有人批准？谁有最终权限？ | 自动化做到最后一步才发现发布、付款或客户沟通不能自动执行。 |
| 6. Output | 流程结束后要产生什么结果？写入哪个系统？通知谁？ | 只关心 AI 输出文字，没有定义真正的业务完成状态。 |
| 7. Exception / Owner | 数据缺失、API 失败、AI 不确定或规则冲突时，谁接手？ | 只有 Happy Path，没有 Manual Fallback、Alert 或负责人。 |
不要问“这一步能不能用 AI”——先问它属于哪一种工作
同一个 Workflow 里，不是所有步骤都应该交给 AI。为了减少不必要的复杂度，可以先把每一步分到四种执行方式之一。
| 执行方式 | 更适合的情况 | 例子 |
|---|---|---|
| Human | 需要责任判断、例外处理、敏感沟通或不可逆决定。 | 批准报价、确认退款、发布重要内容、处理特殊客户。 |
| Rule | 条件清楚、输入结构化、结果可以直接验证。 | 金额超过某值就升级审批、缺手机号就停止进入下一步。 |
| Integration | 本质只是把可靠数据从一个系统送到另一个系统。 | 表单提交后写入 CRM、订单完成后发送通知、同步状态字段。 |
| AI | 需要处理非结构化信息，输出可以被验证或继续经过人审。 | 分类客户问题、摘要会议记录、从文本抽取信息、准备初稿。 |
这个分类有一个实际好处：它会迫使团队承认“自动化”不等于“全部使用 AI”。有些流程用固定规则更简单；有些只是系统连接；有些步骤继续保留人工反而更安全、更容易维护。
示例：把“收到新 Lead 后跟进”拆成可执行 Workflow
假设一家 B2B 企业现在的流程是：有人看到网站表单通知后，把资料复制到 Spreadsheet，再判断客户类型，然后在群里通知销售。
不要直接写需求“做一个 AI Agent 自动处理 Lead”。先把流程拆开：
| 节点 | 当前动作 | 可能的执行方式 | 需要确认 |
|---|---|---|---|
| Trigger | 网站表单提交 | Integration | 表单是否有稳定 Webhook/API 或受支持出口 |
| Input validation | 员工检查姓名、公司、联系方式 | Rule | 哪些字段缺失就不能继续 |
| Lead classification | 员工阅读需求后判断类型 | Rule 或 AI 辅助 | 能否先写出明确分类规则；模糊文本是否需要 AI |
| Assignment | 员工决定交给哪位销售 | Rule | 地区、产品、客户类型或轮转规则 |
| Customer reply | 销售写第一封回复 | AI Draft + Human Approval | 哪些信息允许自动生成，发送前由谁批准 |
| Record | 复制到 Spreadsheet/CRM | Integration | 目标系统权限、字段映射、重复记录规则 |
| Exception | 资料不全时私下问同事 | Human + Alert | 明确 Exception Owner 和响应路径 |
这样拆完以后，团队可能会发现真正需要 AI 的只有“理解自由文本并准备草稿”这一小段，其余部分用规则与 Integration 就能完成。这个结果通常比“一开始就做全流程 AI Agent”更容易测试，也更容易知道哪里出了问题。
用 5 个问题筛选第一个 Pilot，而不是一次自动化整个部门
Workflow Map 画完后，下一步不是马上 Build。先挑一个适合 Pilot 的流程。下面这 5 个问题可以作为内部筛选矩阵；它不是行业评分标准，而是帮助团队做 Scope 讨论的工具。
- 重复频率：这个流程是否持续重复发生，而不是一年只做几次？
- 边界清楚：开始和结束能否明确写出来？
- 输入可用：需要的数据是否稳定取得，并有权限使用？
- 结果可验证：团队能否判断输出是正确、错误还是需要人工复核？
- 失败可接管：自动化停止时，是否有人可以手动继续，不会让业务卡死？
如果其中几项仍说不清楚，先不要急着开发。通常应该回到流程本身，把字段、权限、Owner 或异常路径补齐。
什么时候 Workflow Map 会变成 Web App / Backoffice 需求？
有些流程一开始只是“自动把 A 送到 B”，后来会逐渐需要状态、权限、历史记录、人工审批、搜索、Dashboard、Audit Log 或多人协作。到了这个阶段，单纯串接 Automation Tool 可能已经不是全部需求，团队可能需要一个稳定的业务界面来管理流程。
如果 Workflow 需要保存结构化数据、区分用户权限、管理多步骤状态或让多人在同一个流程上工作，可以进一步评估是否需要 企业 Web App / 后台系统 来承接核心业务状态，再让 Automation 负责连接和重复动作。
可直接复制的 Workflow Map 模板
下面这个版本可以直接复制到项目 Brief。每个字段如果答不出来，就先把它当作 Discovery Question，而不是用假设填满。
Workflow Name: 这个流程叫什么？
Business Goal: 这个流程完成后，业务上什么才算“完成”？
Trigger: 什么事件开始？
Input: 需要哪些字段、文件或上下文？来源在哪里？
Current Steps: 现在真实执行的步骤是什么？包括等待、复制、确认。
Decision Rules: 哪些判断能写成明确条件？哪些仍依赖经验？
Human Approval: 哪些动作必须由谁批准？
System / Integration: 涉及哪些系统？是否有受支持的 API、Webhook 或导入导出方式？
AI Role: AI 只负责什么？输出如何验证？
Output: 最终写到哪里、通知谁、产生什么业务状态？
Exception: 缺数据、服务失败、AI 不确定时怎么办？
Fallback Owner: 谁负责人工接管？
Pilot Boundary: 第一个版本明确不做什么？
最后一个字段很重要。一个可控的 Pilot 不只是写“要做什么”，还应该写这次明确不做什么，避免项目在开发过程中不断扩大。
常见问题
做 AI 自动化之前，一定要先画 Workflow Map 吗？
不一定要使用专业流程图软件，但建议至少把 Trigger、Input、关键步骤、判断、人审、Output 和异常接管写清楚。否则团队很难判断哪些问题来自原流程，哪些问题来自自动化系统。
哪些步骤应该用 AI，哪些应该用固定规则？
条件明确、结果可直接验证的步骤优先考虑固定规则；需要理解非结构化文字、分类、摘要或准备初稿时才考虑 AI。涉及客户影响、发布、付款、权限或重要业务结果时，应根据风险保留人工审批。
第一次做 AI Automation 应该从多大范围开始？
优先选择一个边界清楚、输入输出容易验证、负责人明确、异常可人工接管的 Workflow。先验证正常路径和失败路径，再决定是否扩展。
结论：先把流程变成“可描述”，再把它变成“可自动化”
AI Automation 的价值不在于让每个步骤都出现 AI，而在于让重复工作、规则、系统连接与人工判断各自放到合适的位置。
如果一个流程还无法清楚描述 Trigger、Input、Decision、Approval、Output 和 Exception，就先不要急着选工具。先把 Workflow Map 做完，通常已经能发现不少问题：哪些步骤重复、哪些判断其实有规则、哪些数据根本拿不到、哪些风险必须保留人工，以及第一个 Pilot 应该切在哪里。
当流程边界已经清楚，再进入 AI Automation 与业务流程自动化 的 Discovery / Pilot 阶段，会更容易把技术 Scope、权限、异常处理与维护责任讲清楚。更多中文内容可从 Social Plus System 中文文章中心 继续查看。
说明：本文中的字段模板和 Pilot 筛选问题是项目规划框架，不是行业统一标准，也不代表任何特定平台的功能承诺。实际可行性仍取决于现有系统权限、数据、业务规则与风险要求。
常见问题
做 AI 自动化之前，一定要先画 Workflow Map 吗？
不一定要使用专业流程图软件，但建议至少把 Trigger、Input、关键步骤、判断、人审、Output 和异常接管写清楚。否则团队很容易把不稳定的人工习惯直接自动化，最后只是把问题跑得更快。
业务流程里哪些步骤应该用 AI，哪些应该用固定规则？
条件明确、结果可验证的判断优先考虑固定规则；需要理解非结构化文本、分类、摘要或生成草稿时才考虑 AI。影响客户、发布、付款、权限或重要业务结果的动作，应根据风险保留人工审批。
没有 API 的系统还能做自动化吗？
要看现有系统允许的连接方式和业务风险。若没有受支持的 API、Webhook、导入导出或其他可靠接口，自动连接可能受限。此时应先确认权限和可维护性，而不是默认用脆弱的方式绕过系统限制。
第一次做 AI Automation 应该选多大的流程？
优先选边界清楚、输入输出容易验证、负责人明确、异常可人工接管的单一 Workflow。先用 Pilot 验证正常案例和失败案例，再决定是否扩展到更多系统或步骤。