---
title: "Claude Code 自动化流程：让 AI 替你做重复工作"
description: "判断一项工作值不值得自动化，再把触发、处理、输出三件事串成一条能反复跑的线，并用样本数据验证它不会在真数据上翻车。"
updated: 2026-11-13
canonical: https://docai.cc/learn/workflow-automation-guide/
markdown_mirror: https://docai.cc/learn/workflow-automation-guide.md
---
## 自动化的分界：规则能不能写下来

同一件事做第三遍，你就该问：这套动作能不能写成规则？能，就交给流程；不能，就别硬上。

判断标准只有四条：规则明确、输入格式稳定、发生频率高、不需要临场揣摩人的情绪。四条都占，值得做；缺一条可以半自动；缺两条以上，通常是白忙。

反过来看那些失败的自动化：给不同客户手写措辞、处理格式千奇百怪的老表格、替老板回一封需要拿捏语气的邮件。它们共同点是每次都不一样。把每次都不同的东西硬塞进固定流程，只会让人多一道返工。

## 一条线只有三个部件

| 环节 | 要回答的问题 | 常见做法 |
| --- | --- | --- |
| 触发 | 什么时候开始 | 定时、收到新文件、点一下按钮 |
| 处理 | 按什么规则做 | 脚本算数、模型写文字 |
| 输出 | 结果去哪 | 存文件、写进表格、发出去 |

新手常把三件事混在一起想，结果写完发现不知道从哪启动。先把这三格填满，再动手。填不满说明还没想清楚，不是工具不好用。

还有一条隐藏的线：每一步的中间结果放在哪。想省事的人都栽在这——脚本跑到一半崩了，前面算的全丢。先想清楚中间文件叫什么、放在哪个目录，比事后补救便宜得多。

## 一个能落地的例子：月报

原始做法是导数据、手工整理、写分析、调排版，一下午就没了。拆成三个部件之后：

- **触发**：每月最后一个工作日，你运行一条命令。
- **处理**：脚本读表、算指标、生成一份数据摘要；模型按固定模板把摘要写成段落。
- **输出**：一份初稿落在指定目录，加一段「需要你确认」的清单。

真正省时间的不是让模型写完，而是让它承担结构化的部分：数字、排名、同比、异常项。判断和背景补充还是你来——这部分模型看不到，也猜不准。

邮件分流的例子更典型：先让模型把来信分成咨询、投诉、退款几类，再按类别套不同的处理方式。咨询可以自动起草；投诉和退款只出草稿、标上「需人工确认」。敏感类别不越过人这一关，这是[人在回路](/concepts/human-in-the-loop/)最实用的用法。

## 把一周的活排成班次

内容生产这类流程，拆成「哪天人做什么」比画一张复杂流程图有用。一条跑得顺的周线大致是这样：

| 时间 | 谁 | 做什么 | 产出 |
| --- | --- | --- | --- |
| 周一上午 | 人 | 定本周十个选题，标出哪个是重点 | 选题表 |
| 周二上午 | 模型 | 按选题表批量出初稿 | 十篇草稿 |
| 周三至周四 | 人 | 改稿、配图、补案例 | 可发布稿 |
| 周五 | 人 | 按渠道发布，记录时间和链接 | 发布记录 |
| 下周一 | 模型加人 | 汇总上周数据，找规律 | 下周选题建议 |

批量出稿的提示词要一次把变量说全：

「按下面十个选题各写一篇初稿，每篇四百字上下。读者是刚接触这类工具的新手。结构统一为：一个具体场景、三步做法、一个常见坑。不要写行业趋势，不要用「赋能」这类词。选题：1. …… 2. ……」

周一那半小时不能省。选题方向错了，后面五天都在给错误的方向抛光。同样，周五的发布记录要留链接和数据截图，否则下周一的分析只能凭印象。

## 日报线：十分钟里，八分钟在核对

每天固定时间看数的工作，最适合做成一条短流程：脚本拉数、算指标、套模板生成一段摘要，你核对后转发。准备一次，之后每天只花十来分钟。

真正要设计的是核对环节。给自己定三条：总量和昨天比是否在同一量级；最大项和最小项有没有换人；摘要里每个形容词能不能在表里找到对应数字。三条过不了，就退回脚本查，不要直接发。

常见的三种翻车方式，症状和原因往往对不上号：

| 现象 | 为什么 | 怎么办 |
| --- | --- | --- |
| 某天输出是空的 | 源文件换了命名，脚本按旧规则没找到 | 让脚本找不到文件时直接报错退出，不要静默生成空报告 |
| 数字对，结论读着别扭 | 摘要用的是脚本算好的汇总，模型没看到原始分布 | 把分布或异常值一并交给模型，并要求它只根据给定数字下结论 |
| 同一份报告发了两次 | 触发条件重复触发，或手动补跑没有去重 | 输出文件名带日期，发送前检查当天是否已发 |

这条线的边界要说清：涉及对外承诺、付款、合同变更的内容，自动生成到草稿为止，发送必须由人点。想理解「人卡在哪一步」的设计，可以看[人在回路](/concepts/human-in-the-loop/)。

还有一条判断：一个月才做一次的事，别急着自动化。搭建和调试的时间可能比省下来的还多，先用模板加一段提示词顶着，等频率上来了再动手。批量任务怎么扩容，可以接着看[自动化重复任务](/learn/automate-repetitive-tasks/)。

## 怎么开口让它帮你搭

不要一上来要代码。先让它画流程：

```
帮我设计一条自动化流程，别写代码：
工作内容：每月把销售表变成部门月报
输入：从系统导出的表格，固定四列
输出：一份初稿，我自己再改
频率：每月一次
请给我：每一步做什么、哪几步必须人工、哪些步骤容易出错
```

流程确认了，再逐段要脚本。一次只写一段，写完立刻用样本数据试。

## 用样本跑，用真数据验收

先用几行假数据跑通整条线。然后做一件容易被跳过的事：拿上个月的真实数据重跑一遍，把结果和当时人工做的版本对照。

对照时重点看三处：数字有没有差、模型写的段落有没有「看起来对但没依据」的句子、格式是不是每次一致。这三处对上，才敢每月都用。

出错时也别急着重写。把报错、命令、数据位置一起贴回去，多数问题一两轮就能定位。真正常见的不是报错，而是「安静地错了」——所以每一条自动化线都该有一个检查点：这次结果和上次比，量级对不对。

一条线稳定跑起来之后，下一步是把它扩展到几十上百条数据：[批量处理](/learn/scale-up-batch-processing/)。