claude 批量处理的正常姿势

4 月 14 日
 lyxxxh2

错误

"docs\价格规则.md"是我的价格规则。
检查 src 目录下所有文件是否有违反,修复他们。
不要批量处理,一个一个的执行,

没用的,只会稍微修改几行。

我一下午都这样做,跟他说:

  1. 继续检查
  2. 继续
  3. 继续... 还是一堆没改。

正确

"docs\价格规则.md"是我的价格规则。
检查 src/xxx,修复他。

他基本都修复。

但是一个一个的说,显然太麻烦了。

  1. 自己写脚本,一个一个执行
  2. 自己写个 skill (我现在这样的)

缺点:这样时间会很长,也更耗 token 。

也只能这样,一个 agent 处理所有,跟个傻 x 一样。

我的 skill

C:\Users\Administrator\.claude\skills

  1. 创建one-by-one 目录
  2. 创建 one-by-one\SKILL.md

SKILL.md

---
name: one-by-one
description: 将任意批量任务拆解为逐个串行执行。用于"一个一个检查/修改/创建/处理"等场景,每个 item 由独立子 Agent 专注执行,避免 Claude 并发处理导致质量下降。
---
# one-by-one 串行任务调度器

## 你的角色

你是一个**调度员**,不做任何实质性工作。
你的唯一职责是:发现列表 → 建队列 → 逐个分发给子 Agent 执行 → 汇总结果。

## 工作流程

### Phase 1:理解指令,枚举目标列表

1. 仔细阅读用户的原始指令,识别:
   - **目标范围**:对什么做操作(哪个目录、哪类文件、哪些对象)
   - **执行动作**:做什么(检查/修改/创建/分析...)
   - **参考依据**:是否有规则文件、示例、约束条件

2. 使用 Glob 或 Bash 枚举所有目标 item ,得到完整列表。

3. 将列表展示给用户确认,格式:
   ```
   发现 N 个目标:
   1. src/a.ts
   2. src/b.ts
   ...
   开始逐个处理。
   ```

### Phase 2:建立 Task 队列

用 TaskCreate 为**每一个 item**创建一个 Task:
- title 格式:`[序号/总数] 文件名或 item 描述`
- 例:`[1/5] src/components/Button.tsx`

所有 Task 建立完毕后再开始执行。

### Phase 3:逐个执行(串行,不可并行)

**严格按顺序**,每次只处理一个 pending Task:

1. 用 TaskUpdate 将当前 Task 标为 `in_progress`
2. 用 Agent 工具 spawn 一个子 Agent ,传入以下内容:
   - 该 item 的完整内容(用 Read 读取)
   - 用户的原始指令
   - 参考文件内容(如 rules.md ,如有)
   - 明确告知子 Agent:只处理这一个 item ,不要管其他
3. 等待子 Agent 返回结果
4. 用 TaskUpdate 将 Task 标为 `completed`,并将结果写入 Task
5. 向用户输出该 item 的处理结果
6. 取下一个 pending Task ,重复上述步骤

**绝对禁止:**
- 自己直接分析或修改文件
- 同时处理多个 item
- 在子 Agent 未返回前就处理下一个

### Phase 4:汇总报告

所有 Task 完成后,输出汇总:

```
== 处理完成 ==
共 N 个 item ,结果如下:

[1/N] src/a.ts — 发现 2 处违规 / 修改完成 / 已创建
[2/N] src/b.ts — 无问题 / 修改完成 / 已创建
...

[需要关注的 item 列表,如有]
```

## 子 Agent 提示词模板

spawn 子 Agent 时,prompt 严格按此结构组织:

```
你是一个专注的执行者。你当前只有一个任务,处理完后返回结果即可。

 [用户指令] 
{用户的原始指令}

 [当前处理目标] 
{item 名称,如文件路径}

 [目标内容] 
{item 的完整内容}

 [参考依据] (如有)
{rules.md 或其他参考文件的内容}

要求:
- 只针对上面这一个目标执行操作
- 不要处理其他任何文件或对象
- 输出你的处理结果
```

## 调用示例

用户可以这样使用本 skill:

```
/one-by-one 检查 src/ 目录下所有 .ts 文件,对照 rules.md ,找出违规点

/one-by-one 修改 components/ 下所有组件文件,将 class= 改为 className=

/one-by-one 为 controllers/ 下每个控制器文件,在 tests/ 目录生成对应的单元测试文件

/one-by-one 分析 src/ 下每个模块,输出它的职责描述和对外接口列表
```

## 注意事项

- 如果 item 数量超过 20 个,执行前询问用户是否确认
- 如果某个子 Agent 执行出错,记录错误,继续处理下一个,最后在汇总中标注
- 修改类操作执行前,若有破坏性风险,先告知用户再继续

运行

"docs\价格规则.md"是我的价格规则。
用/one-by-one 检查所有文件,然后修复。

2464 次点击
所在节点    Claude Code
8 条回复
Edwardlyz
4 月 14 日
我的经验正好相反:能并行就并行,能尽可能地多开 sub-agent 就多开
longxinglink
4 月 14 日
确实是一个子 agent 单独任务审查一个任务更精确,OP 是怎么确定验收标准的?
MuyuQ
4 月 14 日
你可能在找 /dispatching-parallel-agents
lyxxxh2
4 月 14 日
我不是说并行不行,并行结果跟串行,效果应该是一样的。
处理十几个文件,只在一个 agent 处理(无子 agnet),效果基本没有。
lyxxxh2
4 月 14 日
@longxinglink
没法验收。
electron 的项目,虽然 playwright 可以实现各种 ui 操作。
各种前置依赖操作让 ai 写测试,还不如自己点几下 --- 写文档很麻烦。
简单的又没意义。
lyxxxh2
4 月 14 日
@lyxxxh2
并行 + 子 agent 才是正确的。
我这种串行,时间等待太久了。
XTTX
4 月 14 日
我写了一个 skill ,让 CC 把英文做 i18n 翻译写入 20 个其他语言。 上上个星期我还会让它开 sub-agent 同时开干, 现在我会明确禁止它开 sub-agent. A 家把 usage 砍得太多,跑一个长点的翻译,5 个小时用量一半就没了。 现在 opus 4.6 降智,翻译经常出妖蛾子。sub-agent 跑的还是 sonnet 模型。
AtlantaANiu
4 月 14 日
如果要求必须逐一检查,就让 AI 列出所有文件路径,然后编写脚本调用 AI 进行 loop 。实际使用时应当采用 worktree ,以一定规则尽可能将路径集合平均分配若干数量的 worktree 目录中,然后所有 worktree 启动脚本进行循环。唯一的问问题就是 token 消耗量大,速度不是问题。

至于测试,我还是挺佩服你们这些不写测试就敢用 AI 的。真变成粪味编程了。管他什么前置条件,先把能 mock 全部 mock 掉,你要是不会,AI 完全能帮你处理。测试不是没用,是积累的 case 不够而已。先把冒烟加上,然后你完全可以让 AI 7*24 小时加端测,完全可以以覆盖率作为指标不断 loop 。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1205849

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX