翻译即 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：
target_language: zh-CN
default_mode: refined
audience: technical
style: technical
chunk_threshold: 4000
chunk_max_words: 50006 行配置，定义了翻译的目标语言、质量模式、受众、风格、分块参数。加上 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 字）超过了单次翻译的质量阈值。处理方式：
- 分块：用
scripts/main.ts --max-words 5000拆成 5 个 chunk（4989, 4740, 4847, 4444, 1817 字） - 共享上下文：所有 chunk 共享同一个
02-prompt.md（包含术语表、语气分析、翻译难点） - 并行翻译：5 个子智能体并行翻译各自的 chunk
- 合并清理：合并后清理 HTML 残留（
<sup>标签）和 LaTeX 符号（$\rightarrow$→→）
这就是 Anthropic #7 的"多大脑"架构的简化版：无状态的翻译智能体，通过共享的 02-prompt.md 保持一致性。和 Session 外部存储异曲同工——上下文不锁在单个智能体内，而是通过文件共享。
术语一致性 = 上下文一致性
跨 5 个独立翻译的 chunk 保持术语一致，靠的是 02-prompt.md 中内嵌的完整术语表。这和 OpenAI 的"仓库即记录系统"是同一个原理：所有智能体读同一份文件，就像所有开发者读同一个 AGENTS.md。
实际效果：5 个 chunk 合并后，术语一致性极高，主要的合并清理工作集中在 HTML/LaTeX 格式问题上，而不是翻译质量问题。
原因分析：为什么这套流程有效
有效的部分
约束够紧：术语表 + 模式 + 受众 + 风格，把 AI 的翻译自由度限制在可接受的范围内（Ashby 定律的应用——通过定义"拓扑"来削减多样性）
反馈有回路：不是一次性翻译然后验收，而是 draft → critique → revision 的闭环。critique 阶段专门检查欧化表达、术语一致性、语境理解——这些是 AI 翻译最容易犯的错
分治可扩展：19K 字论文拆成 5 × 4-5K 字的 chunk，每个 chunk 在 AI 的"甜点区"内。这和 OpenAI 的吞吐量理念一致——不是让一个智能体做所有事，而是把任务拆小
所有中间产物都持久化：analysis、prompt、draft、critique、revision——全部保存在文件系统中。三天后回来审查时，可以追溯每个翻译决策的理由。这就是"仓库即记录系统"
暴露的问题
LaTeX/HTML 格式清理是手动的：合并后发现
$\rightarrow$、<sup>等残留，需要手动 sed 批量替换。这说明翻译 harness 缺少一个格式验证传感器——理想情况下应该有一个后处理步骤自动检测和清理这些critique 阶段的评估深度有限：04-critique 由同一个 LLM 完成，存在 self-eval 偏差（和 Anthropic #4 的发现一致）。理想情况下应该由不同模型做 critique，或者引入人类抽检
首篇翻译的术语表是空的：第一篇翻译时术语表还没建立，之后的翻译才逐步补充。这意味着早期翻译的术语一致性不如后期。一个改进是在开始翻译前先做一次全量术语扫描
解决方案（已实施 + 待改进）
已实施
- 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 才有意义）。