先说工具全貌：hmharness 是一个开源的 HarmonyOS/OpenHarmony 开发智能体框架（MIT），把工程创建、检查、构建、签名、安装、启动、日志读取和结果验证接成本地工具链，让 AI 不只是生成代码，还要用本机环境证明结果；自进化行为受审批、预算、canary 和回滚约束。它不是 DevEco Studio 的替代品，而是开发智能体和鸿蒙工具链之间的验证层。本文只展开其中一个功能：自进化的考官——bench 门禁，以及一次真实的误杀修复。
十连死现场
框架的自进化机制会不断提出「新技能」候选，每个候选上岗前都要过一场考试（bench 基准）。某一天起，候选开始连续阵亡：一个又一个，死法一模一样——不是不会做题，是被一道微型考题的「成本门」弹了出来。连数下来，整整十个。
考题：4 个 token 的针尖
那道考题的期望输出只有四个字：等待中……折算约 4 个 token。而成本门的规则是：候选的输出成本超过基线的 1.3 倍就否决。4 个 token 的 1.3 倍，余量只有 1 个 token——任何技能哪怕让输出变动一个字符，都算「成本回归」，直接出局。
规则没错，错的是规则对微型考题太敏感：真啰嗦是 2 到 10 倍的量级，而针尖级的扰动不该死。
修复：乘法帽加绝对余量地板。新规则：超过基线 1.3 倍，且「超出部分超过 8 个 token」，才判成本回归。公式写成 cand > max(base×1.3, base+8)。保住了对真啰嗦的判别力，也放过了针尖级扰动。第十一个候选，活着过了门。
门禁为什么存在：考试会被作弊
最早的判卷方式是子串匹配——输出里「包含关键词」就算对。这放行了一类聪明的废物：啰嗦但错误的输出，比如把失败标记一起打印出来的 "OHM OK (error ignored)"，关键词全在，整体全错。所以判卷升级成了四种断言模式：
-
expect-exact：要输出一字不差
-
expect-regex：正则卡形状，坏正则按「判例写错了」处理而不是蒙混过关——门禁不许自欺
-
expect-none：禁词表，失败标记一出现就否决
-
expect-any：允许多个可接受答案
旧子串语义完全兼容，老用例零改动。
成本估算与围栏约定
成本按「中日韩字符约 1 token、ASCII 约 1/4」折算——想靠切回中文灌水绕过帽，门掐得一样准。还有个细节：断言读的是代码围栏的内部——我们发现模型在散文里会改写、在围栏里却逐字保留（day-55 的发现），围栏于是成了让「精确」可达成的话术约定。
两条设计原则
一、成本只否决、不判分：通过率门仍是主判据，成本门只拦「靠啰嗦通过」——只用成本门会误杀合理的长输出，只用通过率门会放行啰嗦作弊，双指标各管一半。
二、门禁本身要可测试：这套规则有 10 个单元测试守着（gate.test.ts），包括「换中文绕不过帽」和「+8 地板」两个专门用例。
边界与口径
本文对应 npm @hmharness/cli 0.23.10 的 bench.ts / evolve.ts（gate.test.ts 10 用例）；GitHub Release 页版本可能滞后，安装以 npm 为准；项目与华为、开放原子无隶属关系，净室设计。
GitHub: github.com/swsgbl/hmha…
