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