Parallel Translation

gsd:workflow gsd:meta parallel-translation translation-tools Glob, Task, Write, translation-worker(haiku) gsd:goal根据输入规模自动选择单文件或并行多文件策略，低成本完成高质量翻译。 <gsd:phase name="analyze" order="1"> gsd:step识别输入是单文件、目录还是文件列表。 gsd:step提取目标语言与格式约束。 <gsd:phase name="dispatch" order="2"> gsd:step单文件走 single_file_strategy。 gsd:step多文件分组并在同一响应中并行启动 translation-worker。 <gsd:phase name="report" order="3"> gsd:step汇总各 agent 结果并标记失败项。 gsd:step输出最终文件清单和下一步建议。

成本对比：

节省：60x 相比 opus，12x 相比 sonnet

提取关键信息：

• 源文件路径或目录
• 目标语言（默认中文）
• 是否有特殊要求（保持格式、术语表等）

从用户输入中提取文件路径，确定输出位置：

• 输出路径规则：同目录添加 .zh-CN 后缀
• README.md → README.zh-CN.md

启动单个 translation-worker agent：

Task(
  subagent_type="translation-worker",
  model="haiku",
  description="翻译文件 {文件名}",
  prompt="翻译任务：

**文件路径**: {提取的文件路径}
**输出位置**: {输出路径}

请读取文件，翻译为中文，写入输出位置。

要求：
- 保持原有 Markdown 格式
- 代码块内的内容不翻译
- frontmatter 只翻译 value，不翻译 key
- 返回确认信息，不要返回翻译内容"
)

等待 agent 完成，继续到 generate_report。

使用 Glob 工具扫描目录：

# 扫描目标目录
Glob pattern: "**/*.{md,txt,rst,adoc}"
Glob path: {用户指定的目录}

过滤规则：

• 排除 node_modules/**
• 排除 .git/**
• 排除 dist/**, build/**
• 排除已存在的翻译文件 *.zh-CN.md
• 排除 *.min.*

根据文件数量决定分组策略：

分组方法：将文件列表按每组指定数量拆分

继续到 spawn_parallel_agents。

Use Task tool with subagent_type="translation-worker", model="haiku", and run_in_background=true for parallel execution.

CRITICAL: 所有 Task 调用必须在同一条响应中发起，才能并行执行。

Agent 1: 第 1 组

Task(
  subagent_type="translation-worker",
  model="haiku",
  run_in_background=true,
  description="翻译组 1/{总组数}",
  prompt="翻译任务（第 1 组，共 {N} 组）：

**文件列表**:
- {file1_path}
- {file2_path}
- {file3_path}

请逐个读取、翻译、写入。输出文件添加 .zh-CN 后缀。

要求：
- 保持原有格式
- 代码块不翻译
- 完成后返回确认信息，格式：
  ## 翻译完成
  - file1.zh-CN.md (N 行)
  - file2.zh-CN.md (N 行)"
)

Agent 2: 第 2 组

Task(
  subagent_type="translation-worker",
  model="haiku",
  run_in_background=true,
  description="翻译组 2/{总组数}",
  prompt="翻译任务（第 2 组，共 {N} 组）：

**文件列表**:
- {file4_path}
- {file5_path}
- {file6_path}

请逐个读取、翻译、写入。输出文件添加 .zh-CN 后缀。

要求：
- 保持原有格式
- 代码块不翻译
- 完成后返回确认信息"
)

Agent 3: 第 3 组（如有更多分组）

Task(
  subagent_type="translation-worker",
  model="haiku",
  run_in_background=true,
  description="翻译组 3/{总组数}",
  prompt="翻译任务（第 3 组，共 {N} 组）：..."
)

记录每个 Task 返回的 task_id：task_id_1, task_id_2, task_id_3...

继续到 collect_results。

使用 TaskOutput 工具获取每个任务的结果：

TaskOutput(task_id="{task_id_1}", block=true)
TaskOutput(task_id="{task_id_2}", block=true)
TaskOutput(task_id="{task_id_3}", block=true)

收集每个 agent 的返回信息：

• 成功：记录翻译的文件和行数
• 失败：记录失败的文件和原因

继续到 generate_report。

## 翻译完成报告

| 指标 | 值 |
|------|-----|
| 总文件数 | {N} |
| 成功翻译 | {N} |
| 失败 | {N} |
| 使用模型 | haiku |
| 并行 agents | {N} |

**成功翻译的文件**:
- {file1.zh-CN.md} ({N} 行)
- {file2.zh-CN.md} ({N} 行)
- ...

**失败的文件**（如有）:
- {fileX.md}: {失败原因}

---

## ▶ 下一步

- 查看翻译结果：`cat {file1.zh-CN.md}`
- 修改翻译：直接编辑 `.zh-CN.md` 文件
- 重新翻译失败文件：告诉我具体文件名

End workflow.

排除的路径：

• node_modules/
• .git/
• dist/, build/
• *.min.*
• 已存在的翻译文件（如 *.zh-CN.md）

错误做法：在主会话中直接翻译大段文字

正确做法：始终委派给 translation-worker agent（haiku 模型）

❌ 错误 2：串行处理多文件

错误做法：等一个 Task 完成后再启动下一个

Task(...)  // 等待完成
Task(...)  // 再启动下一个

正确做法：在同一条响应中发起所有 Task 调用

// 同一条响应中：
Task(run_in_background=true, ...)
Task(run_in_background=true, ...)
Task(run_in_background=true, ...)
// 同时启动，并行执行

❌ 错误 3：使用昂贵模型

错误做法：使用 sonnet 或 opus 模型做翻译

正确做法：翻译工作始终使用 haiku 模型

❌ 错误 4：TaskOutput 遗漏

错误做法：启动后台 Task 后不获取结果

正确做法：每个 run_in_background=true 的 Task 都要用 TaskOutput 获取结果

核心结论

并行方案优势: 速度快 46%，成本低 80%

Task = Agent 工具的别名，用于启动子代理执行任务