"docs\价格规则.md"是我的价格规则。
检查 src 目录下所有文件是否有违反,修复他们。
不要批量处理,一个一个的执行,
没用的,只会稍微修改几行。
我一下午都这样做,跟他说:
"docs\价格规则.md"是我的价格规则。
检查 src/xxx,修复他。
他基本都修复。
但是一个一个的说,显然太麻烦了。
缺点:这样时间会很长,也更耗 token 。
也只能这样,一个 agent 处理所有,跟个傻 x 一样。
C:\Users\Administrator\.claude\skills
one-by-one 目录one-by-one\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 检查所有文件,然后修复。

1
Edwardlyz 1 天前
我的经验正好相反:能并行就并行,能尽可能地多开 sub-agent 就多开
|
2
longxinglink 22 小时 26 分钟前
确实是一个子 agent 单独任务审查一个任务更精确,OP 是怎么确定验收标准的?
|
3
MuyuQ 22 小时 12 分钟前 你可能在找 /dispatching-parallel-agents
|
4
lyxxxh2 OP 我不是说并行不行,并行结果跟串行,效果应该是一样的。
处理十几个文件,只在一个 agent 处理(无子 agnet),效果基本没有。 |
5
lyxxxh2 OP @longxinglink
没法验收。 electron 的项目,虽然 playwright 可以实现各种 ui 操作。 各种前置依赖操作让 ai 写测试,还不如自己点几下 --- 写文档很麻烦。 简单的又没意义。 |
7
XTTX 20 小时 58 分钟前
我写了一个 skill ,让 CC 把英文做 i18n 翻译写入 20 个其他语言。 上上个星期我还会让它开 sub-agent 同时开干, 现在我会明确禁止它开 sub-agent. A 家把 usage 砍得太多,跑一个长点的翻译,5 个小时用量一半就没了。 现在 opus 4.6 降智,翻译经常出妖蛾子。sub-agent 跑的还是 sonnet 模型。
|
8
AtlantaANiu 20 小时 14 分钟前
如果要求必须逐一检查,就让 AI 列出所有文件路径,然后编写脚本调用 AI 进行 loop 。实际使用时应当采用 worktree ,以一定规则尽可能将路径集合平均分配若干数量的 worktree 目录中,然后所有 worktree 启动脚本进行循环。唯一的问问题就是 token 消耗量大,速度不是问题。
至于测试,我还是挺佩服你们这些不写测试就敢用 AI 的。真变成粪味编程了。管他什么前置条件,先把能 mock 全部 mock 掉,你要是不会,AI 完全能帮你处理。测试不是没用,是积累的 case 不够而已。先把冒烟加上,然后你完全可以让 AI 7*24 小时加端测,完全可以以覆盖率作为指标不断 loop 。 |