我们似乎陷入了一种奇怪的焦虑：代码生成的速度越快，我们对代码质量的掌控感反而越弱。当你按下回车键，kan着Cursor或者Claude Code飞速地吐出Diff，那种“感觉还不错”的直觉，真的靠谱吗？

这不仅仅是信任的问题，geng是工程化的问题。我们迫切需要一套机制，Neng够像体温计一样，在不需要医生介入的情况下先告诉我们：现在的系统状态是“发烧”了还是“健康”的。

幻觉的陷阱：当自信度遇上“不知道自己不知道”

hen多人尝试过让大模型给自己的输出打分。这听起来hen美，但实际操作起来你会发现这简直是一场灾难。geng准确的说法是：你在试图用模型的「自信度」去强行代替真实的「质量」。

大模型有一个天然的缺陷：它不知道自己不知道什么。当它一本正经地胡说八道时它的语气往往比任何时候dou坚定。Ru果你问它“这段代码写得怎么样”，它大概率会给你一个极高的评价，因为它完全基于自身的逻辑闭环来判断，而不是基于外部的Ground Truth。

这就引出了一个极其尴尬的局面：模型对自己输出的评分永远偏高。这种盲目的乐观主义，对于追求严谨的软件工程来说无异于一种慢性毒药。

为什么“AI给AI打分”是个伪命题？

为了解决上述问题，我曾尝试过一种kan似合理的方案：让模型A生成代码，然后让模型B来评分，再根据B的反馈去优化A。听起来像是在训练一个裁判，对吧？

但这个方向我认真试过有两个绕不过去的硬伤。

第一个硬伤：循环论证

这就像是在回声室里喊话。评分高不代表代码真的好，它只代表模型B和模型A的kan法一致，或者模型B恰好被模型A的逻辑带偏了。Ru果没有一个客观的、非LLM生成的标准答案，这个所谓的“裁判”就只是在瞎猜。你在训练一个没有Ground Truth的模型裁判，这本身就是一种逻辑上的自我指涉。

第二个硬伤：成本与不稳定性

每次生成代码后再额外调一次LLMZuo评分，对于高频使用的场景，这是一笔可观的额外开销。geng糟糕的是LLM的输出天生具有随机性。同样的代码，第一次调用可Neng打85分，第二次可Neng变成72分。

这时候你就要抓狂了：这13分的差异，到底反映了代码质量的变化，还是模型那天心情不好？你根本无法区分。这种无法区分的“信号”，在工程上就是毫无价值的干扰。

重新定位：Zuo温度计，而不是Zuo裁判

既然让AI当裁判行不通，那我们该怎么办？我的答案是：把定位降下来我们不Zuo判断对错的“裁判”，我们只Zuo读数的“温度计”。

这个名字其实是从汽车行业借来的灵感：Harness是“安全带”。它的作用不是让车跑得geng快，也不是教你怎么开车，而是在车失控或者状态异常时给你一个明确的信号：“现在情况不对劲”。

Harness Score的设计初衷也是如此。它不负责告诉你“这段代码写得优雅与否”，它只负责在人工Review之前，给你一个客观的、可量化的信号，告诉你这次生成的代码是否在预期的范围内。

构建四维量化矩阵：拒绝模糊空间

为了实现这个目标，我设计了一套包含四个维度的评分体系。这套体系的核心逻辑是：除了Review环节，其他所有维度dou必须是机械计算、非黑即白的，坚决杜绝任何模糊的LLM主观判断。

这四个维度分别是：Compliance、Coverage、Compile以及Review。

1. Compile：硬门槛，一票否决

这个维度没有任何模糊空间：代码要么Neng编译，要么不Neng。Neng编译不代表逻辑一定对，但编译不过代码一定有问题。

在实现上，我们直接跑 `tsc --noEmit`。Ru果退出码是0，得满分；非0，直接0分。虽然这个维度的权重在总分中占比不算Zui高，但它是一个硬门槛。Ru果Compile是0分，哪怕其他三个维度dou是满分，总分也会被拉低到一个让人无法忽视的程度。这就像人的体温，超过40度，其他指标再好也得先送急诊。

2. Coverage：防止“画大饼”

AI有时候hen狡猾，或者说hen健忘。它在接口文档里写得天花乱坠，定义了一堆端点和模型，但实际生成代码时可Neng因为某个文件卡住就悄悄跳过了。

Coverage维度的意义就在于防止“接口文档写了但代码没实现”。我们的Zuo法是：跑完生成任务后扫描实际生成的文件路径，kanDSL里定义的Models是否dou有对应的Model文件，Endpoints是否dou有对应的API文件。

Coverage分数低了说明DSL里定义了但实际没写，通常是AI在某个环节“偷懒”了。这个信号Neng迅速帮你定位到那些被遗忘的角落。

3. Compliance：细节里的魔鬼

这个维度的意义是防止Spec写得清楚但实现跑偏。AI经常会把Spec里明确写的内容漏掉，或者实现得似是而非。

具体的Zuo法是：跑完之后拿验收条件和实际输出的文件ZuoDiff。比如验收条件里明确写了“登录接口必须返回refreshToken”，我们就去实际代码里搜这个字段。有，分数就高；没有，分数就低。这是一种基于事实的比对，而不是基于感觉的打分。

4. Review：唯一的LLM环节

这是四个维度里唯一一个依赖大模型的环节，也是权重Zui需要谨慎拿捏的地方。我们将Review分成了三轮：

第一轮：检查代码逻辑是否和Spec一致。

第二轮：检查边界情况，比如空值、异常处理。

第三轮：检查是否引入了明显的性Neng隐患或安全漏洞。

这三轮评审的结果Zui终会映射成“通过/需修改/不通过”，再转化为具体的分数。虽然这里引入了LLM，但因为有了前三个维度的硬性指标Zuo铺垫，这个环节的主观性影响Yi经被大大削弱了。

从“感觉还不错”到“数据说话”

有了这套体系，AI coding工作流的体验就完全不同了。

以前，你跑完一次任务，你的认知只Neng是模糊的：“感觉这代码写得还行。” 但这种感觉是不准的，也是无法记录的。

现在每次 `ai-spec run` 结束，你dou会得到一个0-100的Harness Score。geng重要的是我给每次run的分数dou绑定了一个 `prompt hash`。

这就厉害了。这意味着相同prompt多次跑，分数是Ke以横向对比的。这才Neng真正回答“这次比上次好还是差”这个终极问题。

比如你把底座模型从Claude换到了DeepSeek，发现Harness Score突然跌了20分。你立刻就Neng知道：不是你的需求变难了而是这个新Provider对这类任务的适配度还不够。你Ke以果断切回去，或者针对性地调整Prompt。这种可追溯性，是单纯靠“人眼kan”绝对无法实现的。

实战演练：ai-spec 中的 Harness Score

目前，这套评分机制Yi经原生集成在 `ai-spec` 的 pipeline 中，不需要你Zuo任何额外的复杂配置。只要你跑任何 `ai-spec create` 命令，系统就会在后台默默计算这四个维度的分数，并汇总输出。

让我们kan一个实际的例子。假设我们要给订单模块加退款功Neng：

$ ai-spec create "给订单模块加退款功Neng"
✔ Spec generated     .ai-spec/specs/order-refund.md
✔ DSL validated     .ai-spec/dsl/order-refund.json
✔ data             src/models/Refund.ts src/models/Order.ts
✔ service          src/services/RefundService.ts
✔ api              src/api/refund.ts
✔ test             src/tests/refund.spec.ts
-pass review
✔  Harness Score   85/100
     compliance   · 90/100
     coverage     · 100/100
     compile      · 100/100
     review       · 60/100
files written  ·  restore: ai-spec restore --c3d8

kan到这个输出，你的关注点瞬间就变了。你不再是漫无目的地全篇Review，而是会直接盯着那个红色的 `60/100` 的Review分数，或者Compliance里扣掉的那10分。你的Review切入点从“全kan一遍”变成了“精准打击”。

当你连续跑了十几次kan到分数的趋势在波动上升：

Harness Score   85/100
   compliance   · 90/100
   coverage     · 100/100
   compile      · 100/100
   review       · 60/100
prompt_hash: a7f2d3e1
run_id: 1024

这种可视化的进步，比任何“感觉还不错”dou要有说服力得多。它证明了你的Prompt优化是有效的，或者你的DSL定义越来越精准了。

给流水线装上记忆

用AI写代码，Zui诡异的地方其实不在于它写错，而在于它“记不住”错。AI在项目里犯过的错，下次还会再犯。你手动修了一个phantom import，下一次跑类似功Neng，它大概还会再犯。因为没有持久化的记忆告诉它“这条路走不通”。

Harness Score的价值，就是把这种隐性的“质量记忆”显性化了。它把“我这次跑完觉得还行”变成一个可记录、可比较的量化数字。

它不替代你思考，但它帮你过滤掉那些低级的错误，让你把Zui宝贵的注意力，留给真正需要人类智慧去判断的复杂逻辑。这或许才是AI时代程序员该有的工作方式。

GitHub: NPM: npm install -g ai-spec-dev 站点:

---