Loop —— 文档还是脚本？让 AI 自动干活的完整指南

loop 文档还是脚本？------ 让 AI 自动干活的完整指南

系列第 3 篇 · 前置：第 1 篇 → 第 2 篇

第 2 篇我们设计好了一个 Loop（三张卡 + 独立评审）。这一篇回答最后一个问题：设计好的 Loop，怎么让它跑起来？

有两种方式：文档驱动 （喂给对话）和脚本驱动（写成程序）。很多人在这里纠结，因为没搞清楚两者的真正区别。这篇用最直白的对比讲清楚。

一、两种载体：遥控车 vs 自动驾驶车

arduino 复制代码

文档驱动（对话式）           脚本驱动（程序化）
─────────────            ─────────────
把设计文档喂给 AI          写成 workflow 脚本
说一句"按这个干"            命令行/调度启动
AI 在对话里转             程序按脚本循环

先说清：脚本是文档的「翻译」，但翻译后多了「强制力」

很多人会困惑：「脚本不就是把文档翻译成代码？那脚本和文档不是一样？」

内容上确实一样------文档（三张卡 + 六构件）和脚本（workflow）是同一套规则的两种表达：

复制代码

文档 = 自然语言写的「规格」（AI 读它，然后 AI 自己决定怎么做）
脚本 = 同一套规格的「代码实现」（程序按它走，AI 不能跳过）

但翻译成「程序」后，多了文档没有的东西------强制力：

复制代码

文档（自然语言）：
  AI 读规则 → AI 自己理解着执行
  → 可能理解错、可能跳过某步、可能自由发挥
  = 「建议」，靠 AI 自觉

脚本（可执行代码）：
  循环控制 / 分支判断 / 数据传递写在程序里
  → 程序强制按流程走，测试必须跑、不达标必须反馈
  = 「强制」，靠程序保证

打个比方 ：文档是给员工的「工作要求」（员工理解着做，可能打折）；脚本是给机器的「生产流水线程序」（机器严格按流程，不打折）。内容相同，但一个是建议、一个是强制。

这也是「一次性任务用文档就够」的原因：你在场盯着，AI 自觉执行够了；要无人值守，AI 自觉不可靠，必须脚本（程序强制）。

二、一个关键认知：文档也能「不用人管」

很多人以为「不用人管 = 必须写脚本」，这是误区 。真正的开关不是载体，是授权 + 判定权：

diff 复制代码

文档 + 一句「所有细节你自己决定，不要回头问我」
+ 判定权给独立评审
→ 文档也能甩手，AI 自己转到达标

喂完文档，AI 自动生成 → 独立评审 → 不达标就改 → 达标停。全程没插话。所以文档不是只能对话式，关键看你授不授权。

三、但「不用人管」有区别：会话内 vs 进程级

复制代码

文档的「不用人管」= 会话内等价
  → AI 在对话里转，但对话崩溃 / 上下文溢出 / 客户端关闭 → 直接中断
  → 没有恢复能力，中断就没了
脚本的「不用人管」= 进程级可靠
  → 独立运行，能异常重启、断点续跑、状态持久化到文件
  → 容错性和可靠性高一个量级

适用性：

短时间、低风险任务 → 两者体验几乎无差别
长时间、高重要性任务 → 脚本化是必须的

四、工作流/脚本的触发方式：三种，决定要不要你

写脚本 ≠ 一定无人值守。怎么触发，决定了你要不要在场：

bash 复制代码

方式 1：对话内官方 Workflows 命令
  Claude Code  原生支持动态工作流：
  - 内置工作流直接启动，比如 /deep-research 调研指定问题
  - 自定义Loop保存为工作流后，直接用 /你的工作流名 启动
  - 运行中输入 /workflows可查看、暂停、重启所有工作流，支持一键保存为可复用命令
  → 工作流在当前会话后台运行，关闭对话会中断，适合边看边调整的一次性任务
方式 2：命令行直接跑（不依赖对话）
  claude -p "按这份设计开发登录模块"
  → 命令行后台运行，不用打开交互对话
方式 3：系统调度（真正的自动驾驶）
  cron 定时跑 / GitHub Actions / Claude Routines 云端托管
  → 到点自动触发，你完全不在，崩了能自己重启

所以同样是工作流/脚本，对话内触发还是需要你在场------它是遥控车，只有挂到系统调度（方式 3）才是真正的自动驾驶车。

五、脚本化不可替代的三样价值

除了「能挂定时」，脚本还有文档难以替代的三样东西：

复制代码

① 可观测性
   脚本：打日志、上报指标、接监控告警，运行状态可统计、可追溯
   文档：状态散在对话里，难批量管理、难复盘
② 确定性容错
   脚本：重试次数、超时时间、异常降级逻辑写死，行为可控
   文档：容错全靠模型自行判断，稳定性波动大
③ 权限隔离
   脚本：通过系统权限控制读写范围，风险边界清晰
   文档：权限和当前 Agent 完全绑定，不利于最小权限管控

这才是生产级要脚本化的真正理由 ------不是「能不能不用人管」，是可观测、可容错、可隔离。

六、最佳实践：不是二选一，是递进

工业界最常用路径，分两个阶段：

vbnet 复制代码

阶段 1：原型验证 → 用文档
   快速写规则、快速迭代 Loop 逻辑，跑通流程
阶段 2：固化生产 → 转工作流/脚本
   验证稳定后，把成熟规则保存为官方Workflows或封装成脚本，接入自动化调度
一句话：文档做设计和调试，脚本做交付和运行 ------ 上下游关系，不是互斥关系。

什么时候该转脚本：当这个任务变得「高价值、稳定、需要重复跑」时。

更明确的判断标准（4 条，出现任一条就该上脚本/工作流） ：

复制代码

① 需要并行执行 ------ 多个任务要同时跑（文档只能串行）
② 需要异常自动回退 ------ 出错了要自动重试/回退（文档靠人盯）
③ 需要脱离对话独立运行 ------ 你不在场它也要跑（文档依赖会话）
④ 需要状态持久化 ------ 中断后能续跑（文档状态在上下文，会丢）

4 条都没有 → 文档 + 主 Agent 就够，硬上脚本是过度工程化

这 4 条比「高价值、稳定、重复跑」更可落地------它给了你具体的判断点，而不只是「感觉值得才上」。

七、官方现成命令速查

除了自己写文档/脚本，Claude Code 还内置了四个相关命令，覆盖不同场景，不用自己手写循环逻辑。

/goal：设定目标，达标即停

bash 复制代码

/goal 把所有单元测试跑到全部通过

设定一个可验证的完成条件，Claude 会自主循环工作直到条件满足
内置目标达成校验，自动判断是否满足终止条件；如果需要严格的独立评审（避免自评放水），仍需自行拆分为生成+评审双Sub-agent
达标后自动清除目标，停止工作
适合：修 bug、实现功能、跑通测试等有明确完成标准的单次任务

/loop：定时重复，会话内轮询

arduino 复制代码

/loop 5m check the deploy

每 5 分钟重复跑一次指定 prompt
注意：/loop 是会话内临时循环------对话关了就停，不是持久化调度
适合：临时轮询部署状态、盯 PR、短时间快速检查

/workflows：动态多Agent工作流管理

bash 复制代码

/workflows

列出当前会话所有运行中/已完成的多Agent工作流，支持查看实时进度、暂停、重启、保存为可复用斜杠命令
适合：大规模代码审计、批量文件迁移、多来源交叉调研等需要多Agent并行的复杂任务
保存后的工作流直接用 /工作流名 即可一键启动，团队内可共享

/schedule：持久化定时任务

bash 复制代码

/schedule daily 9:00 运行日报生成Loop

创建持久化的定时任务，支持本地定时和Claude Routines云端托管两种模式
关闭客户端、退出会话也会按计划自动运行，支持失败重试和状态通知
适合：每日巡检、定时报告、周期性维护等长周期无人值守任务

关键区别

bash 复制代码

/goal → 按「完成条件」跑（达标即停，无固定时长，单次任务）
/loop → 按「时间间隔」跑（每N分钟一次，会话内临时循环，关对话即停）
/workflows → 多Agent并行编排（会话内后台运行，支持保存复用）
/schedule → 持久化定时（支持本地/云端，关客户端也能跑）
真正的长周期无人值守任务 → 优先用 /schedule 或系统级调度（cron/GitHub Actions），这些是 /loop 替代不了的

八、这一篇总结

markdown 复制代码

1. 要不要人管 = 授权 + 判定权，不是载体（文档也能甩手）
2. 但文档的无人值守是「会话内」，脚本是「进程级」（可靠性不同）
3. 触发方式决定要不要你：对话内命令要你在场，系统调度不用
4. 脚本化真正价值：可观测、确定性容错、权限隔离
5. 最佳实践：文档做设计调试 → 工作流/脚本做交付运行（递进）
6. 官方命令：/goal 达标即停、/loop 临时轮询、/workflows 多Agent管理、/schedule 持久化定时