翻译即 Harness：一个非代码场景的 Harness Engineering 实践

日期：2026-04-14 关联：works/（11 篇翻译）、references/articles.md（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: 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 字）超过了单次翻译的质量阈值。处理方式：

分块：用 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 才有意义）。

Quartz 4

Explorer

2026-04-14-translation-as-harness