# 翻译即 Harness：一个非代码场景的 Harness Engineering 实践 > 日期：2026-04-14 > 关联：works/ 翻译作品、references/articles.md 文章索引（写作时点快照：11 篇翻译 / 18 篇文章；现况以两处文件为准） --- ## 问题描述 在两周内完成 11 篇高质量中文翻译（含 2 篇学术论文），总计超过 5 万字原文。单纯靠人工翻译不现实，纯 AI 翻译质量不可接受（术语不一致、欧化表达、丢失语境）。 核心挑战：如何让 AI 智能体在翻译场景中可靠工作，同时保持术语一致性和出版级质量？ 回顾整个过程，我意识到我们的翻译工作流就是一个 Harness Engineering 实践——只是域从"代码"换成了"文本"。 --- ## 翻译工作流 → Harness Engineering 映射 ### 约束文件 = AGENTS.md `EXTEND.md` 是翻译的 AGENTS.md： ```yaml target_language: zh-CN default_mode: refined audience: technical style: technical chunk_threshold: 4000 chunk_max_words: 5000 ``` 6 行配置，定义了翻译的目标语言、质量模式、受众、风格、分块参数。加上 40+ 条术语表（glossary）。这就是 HumanLayer 说的"控制在 60 行以内的 AGENTS.md"。 ### 术语表 = Custom Linter 40+ 条术语对照表是翻译场景的"机械化执行"： | 术语表规则 | Linter 类比 | |-----------|-----------| | `Harness → Harness（保留英文）` | 命名约定规则 | | `Feedforward → 前馈` | 术语标准化规则 | | `AGENTS.md → AGENTS.md（保留原样）` | 不可修改的常量 | 和代码 linter 一样，术语表不告诉 AI "怎么翻译"，而是设置**不变量**："无论你怎么翻，这些术语必须这样处理"。这是背压（back-pressure），不是规定（prescription）。 ### 五轮流水线 = Feedback Flywheel baoyu-translate 的 refined 模式有五个阶段： ``` 01-analysis.md → 分析原文（领域、语气、术语、翻译难点） 02-prompt.md → 组装翻译指令（术语表 + 风格 + 上下文） 03-draft.md → 初稿翻译 04-critique.md → 批判性审查（诊断：准确性、欧化、策略执行、表达） 05-revision.md → 根据审查修订 translation.md → 最终版本（润色） ``` 这就是 Rahul Garg 的反馈飞轮：观察失败（04-critique）→ 诊断根因 → 系统性修复（05-revision）→ 验证效果。每篇翻译都跑一遍这个闭环。 **关键细节：** 04-critique 只做诊断，不做修复。05-revision 才执行修复。这和 Anthropic #4 分离 Evaluator 的理念一致——评估者不应该同时是修复者，否则容易自我欺骗。 ### 并行分块翻译 = 多智能体协调 Inside the Scaffold 论文（19,547 字）超过了单次翻译的质量阈值。处理方式： 1. **分块**：用 `scripts/main.ts --max-words 5000` 拆成 5 个 chunk（4989, 4740, 4847, 4444, 1817 字） 2. **共享上下文**：所有 chunk 共享同一个 `02-prompt.md`（包含术语表、语气分析、翻译难点） 3. **并行翻译**：5 个子智能体并行翻译各自的 chunk 4. **合并清理**：合并后清理 HTML 残留（`` 标签）和 LaTeX 符号（`$\rightarrow$` → `→`） 这就是 Anthropic #7 的"多大脑"架构的简化版：无状态的翻译智能体，通过共享的 `02-prompt.md` 保持一致性。和 Session 外部存储异曲同工——上下文不锁在单个智能体内，而是通过文件共享。 ### 术语一致性 = 上下文一致性 跨 5 个独立翻译的 chunk 保持术语一致，靠的是 `02-prompt.md` 中内嵌的完整术语表。这和 OpenAI 的"仓库即记录系统"是同一个原理：所有智能体读同一份文件，就像所有开发者读同一个 AGENTS.md。 实际效果：5 个 chunk 合并后，术语一致性极高，主要的合并清理工作集中在 HTML/LaTeX 格式问题上，而不是翻译质量问题。 --- ## 原因分析：为什么这套流程有效 ### 有效的部分 1. **约束够紧**：术语表 + 模式 + 受众 + 风格，把 AI 的翻译自由度限制在可接受的范围内（Ashby 定律的应用——通过定义"拓扑"来削减多样性） 2. **反馈有回路**：不是一次性翻译然后验收，而是 draft → critique → revision 的闭环。critique 阶段专门检查欧化表达、术语一致性、语境理解——这些是 AI 翻译最容易犯的错 3. **分治可扩展**：19K 字论文拆成 5 × 4-5K 字的 chunk，每个 chunk 在 AI 的"甜点区"内。这和 OpenAI 的吞吐量理念一致——不是让一个智能体做所有事，而是把任务拆小 4. **所有中间产物都持久化**：analysis、prompt、draft、critique、revision——全部保存在文件系统中。三天后回来审查时，可以追溯每个翻译决策的理由。这就是"仓库即记录系统" ### 暴露的问题 1. **LaTeX/HTML 格式清理是手动的**：合并后发现 `$\rightarrow$`、`` 等残留，需要手动 sed 批量替换。这说明翻译 harness 缺少一个**格式验证传感器**——理想情况下应该有一个后处理步骤自动检测和清理这些 2. **critique 阶段的评估深度有限**：04-critique 由同一个 LLM 完成，存在 self-eval 偏差（和 Anthropic #4 的发现一致）。理想情况下应该由不同模型做 critique，或者引入人类抽检 3. **首篇翻译的术语表是空的**：第一篇翻译时术语表还没建立，之后的翻译才逐步补充。这意味着早期翻译的术语一致性不如后期。一个改进是在开始翻译前先做一次全量术语扫描 --- ## 解决方案（已实施 + 待改进） ### 已实施 - **EXTEND.md 配置**：一次设定，所有翻译自动继承 - **40+ 术语对照表**：随翻译进度持续扩充 - **refined 模式**：五轮流水线保证质量 - **并行分块**：大文档拆分 + 共享 prompt + 并行翻译 + 合并 - **中间产物保存**：`translate/` 目录保留完整工作记录 ### 待改进 - **格式后处理自动化**：添加一个清理步骤，自动检测和修复 LaTeX/HTML 残留 - **交叉模型 critique**：用不同模型做审查（如 GPT 审查 Claude 的翻译） - **术语表前置扫描**：在首篇翻译前，先对所有待翻译文章做一次术语提取 - **翻译质量回归测试**：保留几个已确认正确的翻译片段作为基准，检测模型更新后的翻译质量变化 --- ## 收获 ### 1. Harness Engineering 不限于代码 翻译流程证明了 harness engineering 的原理是**通用的**：约束 + 反馈 + 分治 + 持久化。域可以是代码、文本、设计、任何 AI 智能体需要可靠完成的任务。 核心不变量：**人类定义"什么是好的"（术语表、风格、受众），AI 负责执行，harness 负责检查。** ### 2. 术语表是翻译领域最高杠杆的 harness 组件 和代码场景中 linter 是最高杠杆的 harness 组件一样，术语表在翻译场景中的投入产出比最高。40 条术语规则消除了跨首批 11 篇翻译、跨 5 个并行 chunk 的绝大部分一致性问题。 ### 3. 中间产物的价值超过最终产物 `translate/` 目录中的 analysis、critique、revision 文件，比最终的 `translation.md` 更有价值——它们记录了**翻译过程中的判断**。当用户提出修改意见时，可以回溯到 critique 阶段看 AI 是否已经发现了同样的问题。 ### 4. 五轮比一轮好，但不是线性好 refined 模式（五轮）比 quick 模式（一轮）质量明显更高，但边际收益递减： - analysis → translate（最大提升：理解上下文后翻译更准确） - critique → revision（中等提升：修复欧化表达和术语偏差） - polish（小幅提升：润色文字，但本质改进有限） 这和 Anthropic #4 的发现一致："有趣的 harness 组合空间不会随模型改进而缩小——它会移动"。模型变好了，五轮中前几轮的价值可能降低，但最后几轮的价值反而增加（因为基线质量提高了，polish 才有意义）。