# Harness 会过期，Criteria 会复利 > loop engineering 系列第二篇。上一篇拆开了委派阶梯的官方结构，这篇用我自己做的翻译质量系统 TQEF 当实例：那套系统里，跑起来的机制（harness）坏过好几次，得整个重建；但评分标准（criteria）从第一天定下来，改到现在都还在用。这篇讲具体踩过的坑，也诚实讲哪些部分还没做完。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-10 - Pillar: 创造与建构 / Creation & Enterprise - Tags: Loop Engineering, TQEF, Harness Engineering, 翻译质量工程, 阿戈拉广场, 超级个体, AI协作 - Canonical: https://paulkuo.tw/zh-cn/articles/harness-criteria-compounding/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/harness-criteria-compounding.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR：** loop engineering 系列第二篇。上一篇讲完官方的委派阶梯结构，这篇用我自己做的翻译质量系统 TQEF 当例子，说明两种东西不同的寿命：harness，也就是让事情跑起来的机制，会不断被替换；criteria，也就是判断成果是否合格的标准，则能在一次次重建中累积下来。文章里有几个真的踩过的坑，也诚实交代这套系统还有哪些部分没做完。
▶ 听摘要
AI 合成语音・作者本人声线克隆
上一篇文章的最后一句话留了一笔债：「我自己这几个月怎么一轮一轮撞出同样的结构、踩过哪些坑，留到下一篇细谈。」这篇来还。 先讲结论，再讲我是怎么撞出来的。 在一套持续运作的 AI 系统里，有些东西很快就会过期，例如 prompt、工具、数据库和排程。这些让系统跑起来的机制，我把它统称为 harness。一次意外、一次升级，甚至一次架构调整，都可能让它必须重做。 但判断输出好不好的标准不一样。我把这一层称为 criteria。只要定义得够具体，它就能撑过一次次重建，还会随着每次出错，变得更完整。 ## 我做的系统长什么样子 TQEF 是我做的一套翻译质量评分框架，全名 Translation Quality Evaluation Framework，服务对象是阿戈拉广场，我自己开发的即时会议翻译工具。 这套系统由四层循环组成。 最里面的一层负责翻译：模型接收四路语音识别结果，逐段产生译文。第二层负责检查：TQEF 依照五个维度评分，没有过关，就把问题交回去重新翻译。第三层以每场会议为单位运作，会议结束后，译文会进入语料库，成为后续改善的材料。最外层则定期检查多轮结果，找出反复出现的问题，再回头调整 prompt 和辞典。 ![阿戈拉的四层循环堆叠：代理循环、验证循环、事件驱动循环、爬山循环，套在一起运作](/images/articles/loop-engineering-agora-loops.svg) TQEF 用五个维度评分。 第一是术语准确度，权重最高。因为「半导体」如果被翻成别的东西，其他句子再流畅也没有意义。第二是忠实度，检查译文有没有偏离原意。第三是关键信息保留，确认数字和专有名词有没有遗漏或错译。第四是自然度，也就是译文读起来像不像人话。最后是严重错误，只要出现一次，就直接判定不合格。 这五个维度是 criteria 这层。前面提到的翻译、检查、事件触发这三层具体运作，都是 harness 这层。接下来的坑，全部发生在 harness 这层。 ## harness 怎么过期的：三个实际踩过的坑 第一个坑最戏剧化。有一次我在协作 session 里用 osascript 写文件，引号嵌套出了错，226 行的核心评估脚本 eval_runner.py 被截断成只剩一行，`#!/usr/bin/env python3`，整支脚本毁了。这不只是「重写就好」的小事，更像一个系统性的警告：当同一个工作阶段同时负责策略、写代码和部署，任何一步出错，都可能一路影响到后面的工作。那次之后我把整个协作流程拆成三轨：一轨只负责侦察跟策略，不碰代码；一轨负责批量文件操作；一轨负责精准的单文件修改跟部署。三轨不能同时修改同一个文件；每个阶段结束前，也必须确认变更已经保存、提交，并留下可以回复的版本。这个分工是那次事故逼出来的，不是我事先设计好的，事后看是整段开发历程里报酬率最高的一个决定，因为后面再也没有发生过类似的版本混乱。 第二个坑比较安静。系统扩充时，我依照文件猜测数据库字段的名称，实际查询后才发现，数据结构和文件写的不一样。类似情况发生过两次，幸好都在前期检查时被拦下，没有造成实际损害。从此我多了一条硬规矩：数据库字段一律以实际查询结果为准，不能依靠文件或记忆猜测。 第三个坑是评分记录重复入库。同一轮、同一句话的评分结果，被写进数据库两次，原因是当初没有设定唯一性约束。修法很直接：补上约束，再清掉重复数据。 还有一个反复出现、比较不戏剧化但更常见的模式：代码写好了，但没接通。功能看起来写完了，但 import 没加、路由没接、部署没跑，或前端根本没有渲染。各个零件可能都在，整条流程却从来没有真正走通。这个教训养成了一个习惯：任何改动完成后，一定要做一次完整的端到端验证，从头走一遍，确认东西真的活着，而不是相信「应该有动」。 ## criteria 怎么复利的：一次可以说清楚原因的提升 跟前面那几个坑对照最鲜明的一轮，发生在辞典上线那天。基线评分是 4.69（满分 5），还有一个严重错误。那一轮我把三个产业辞典和一套商业用语规则同时上线，一次补齐半导体、循环经济、再生医学与常用商业词汇的翻译校正。下一轮结果：整体评分跳到 4.97，严重错误归零。 这次提升可以清楚追溯到辞典上线。分数提高能对应到一项具体的工程改动，不只是主观感觉。这正是 criteria 这层的价值：即使 harness 一再重建，它仍让前后几轮的结果可以用同一套标准比较。不管底层脚本是不是被 osascript 炸过、数据库字段名是不是查对过、有没有重复入库的 bug，五个评分维度虽然持续补充细节，但从第一轮到现在，核心判断逻辑都没有改变。每一次工程改动的效果，都可以叠加在同一把尺上比较。这把尺没有被任何一次 harness 重建打掉重练，这就是复利的意思。 后续几轮分数在 4.78 到 4.90 之间浮动，这种波动是正常的，29 句语料的样本量不大，评分模型本身也有随机性。但整体趋势仍然向上，也可以回头比对每一轮做过哪些工程改动，以及它们可能带来的影响。这件事跟上一篇提过的原则呼应：循环可以帮你把生成跟评估拆开，但「怎样算一句翻译过关」这件事，永远得是你自己先讲清楚，讲到能拿去打分。 ## 诚实讲还没做完的部分 TQEF 目前完成的是 Phase 1：单一评分引擎、29 句测试语料、跑过七轮评估。Phase 2 设计了五个自动收集语料的通道，目前只完成两个，其余还在规划。我另外规划了一个 Stage B，专门验证评分器本身是否可靠。除了调整评分 prompt，还要用另一套指标交叉比对、请真人专家评分校准，并重复测试同一批数据，确认结果是否稳定。这个阶段到现在都还没真正推进，卡在其他优先顺序后面，是诚实留着的一个坑，不是随口说说。 这部分不能省略。既然我主张 criteria 比 harness 更持久、更值得投资，就也必须说清楚：criteria 也不是写完一次就能定案。它仍然需要交叉比对、真人校准和稳定性测试。不同的是，这些工作通常是在修正同一把尺，而不是每次都换掉整套判断方式。这个验证我自己都还没做完。 ## 这两篇合起来想说的事 上一篇讲完 loop engineering 的官方结构之后，留了一句话：Loop engineering 可以自动化「流程怎么跑」，却不能替你决定「怎样才算跑对」。这一篇用自己踩过的坑，把这句话落到实处。harness 这一层，我炸过、修过、重建过，三轨分工是被那次事故逼出来的。criteria 这一层，从第一天定义清楚之后，撑过了每一次重建，还随着每一次踩坑补得更完整。 如果你手上没有 TQEF 这种现成系统，这个对比一样用得上。任何持续运作的 AI 系统，让它跑起来的机制迟早会被打掉重练，这几乎是必然。真正值得先花力气想清楚的，是「怎样才算做完」。把标准写得够具体，具体到不同的人或模型，都能拿它判断成果是否过关。这件事很难完全外包给模型。但只要把标准建立起来，它通常会比任何一版 prompt、工具或工作流程都活得更久。 ## 参考资料 **同系列前一篇** - [循环工程到底在教你委派什么](/zh-cn/articles/loop-engineering-the-layer-you-own/)：loop engineering 系列第一篇，拆开官方委派阶梯的结构、它解决的三个真问题，以及 Anthropic 自己的实测数据对照 **TQEF 相关素材** - 本文所有评分数据、事故记录、开发时程均为 Paul 自建系统的第一手记录，非第三方报告转述