企业官网建设流程全解析

• AI 技能/插件
• 提示工程
• AI 评测
• 人工智能

Context Engineering Kit是一个手工打磨的 Claude Code 技能（Skills）开源仓库，兼容 OpenCode、Cursor、Gemini CLI 等主流 AI 编程工具。其 SADD 插件（Subagent-Driven Development，子代理驱动开发）提供的/do-and-judge命令，正是目前落地LLM-as-Judge（大模型当评委）最完整的质量门（Quality Gate）实践之一：先让子代理干活，再让独立的"评委代理"按评分标准打分，不达标就带着反馈自动重试，直到通过为止。本文将带你从零看懂这套"执行 + 评审 + 重试"闭环的设计原理与使用方法。

为什么 Agent 需要一道"LLM-as-Judge"质量门？

用 AI 编程代理写代码时，最常见的问题是：代理自己说"做完了"，但结果质量参差。长会话中上下文会不断"污染"——假设过期、实现漂移、注意力涣散，代理往往对自己的疏漏毫无察觉。

LLM-as-Judge 的思路很直白：用一个独立的模型（或代理）来评审另一个模型的工作成果，按结构化评分标准（Rubric）打分、列证据、下结论。这比"让代理自查"可靠得多，因为评委与执行者上下文隔离，能发现自查的盲区。

Context Engineering Kit 的 SADD 插件把这一思路工程化为一条完整的流水线：

• 🧩新鲜上下文：每个子代理干净启动，不受之前任务污染；
• ⚖️外部验证：独立的 judge 代理机械地套用评分标准，捕获自查遗漏的盲点；
• 🔄反馈循环：不达标时把评委指出的问题原样喂回执行代理，最多重试 3 次；
• 🚦质量门：分数不达标的产出，不会"发货"。

/do-and-judge 的三角色分工：谁来干活、谁来定标准、谁来打分

/do-and-judge的核心设计是三个角色分离，分别对应"生产者—标准制定者—评估者"：

三个角色各司其职的关键好处：评分标准是"先于实现"制定的，评委无法事后迎合实现；评委"只认规范、不认人情"，连及格线是多少都不告诉它，从机制上避免打分偏松。

第一步：meta-judge 生成"本任务专属"评分标准

普通评审最大的坑是标准模糊——"代码质量良好"这种话没法机械执行。meta-judge 代理的职责就是把抽象的"质量"分解成可测量的具体维度，输出一份 YAML 评估规范，包含：

• Rubric 维度：每个维度带权重、评分说明，以及一对"锚点样例"（一段明显不合格的score_2片段、一段明显达标的score_4片段），强制评委把成果定位在这两极之间的具体轴线上，而不是凭印象打分；
• Checklist 布尔清单：原子化的是/否问题，按essential / important / optional / pitfall分级——关键项答"否"会触发总分封顶，反模式项答"是"会扣分；
• 评分元数据：权重求和、门限与罚则。

这样评委拿到的不再是一句"请评审"，而是一份可以直接照章执行的检查表。

第二步：并行派发——评审标准与实现同时进行

编排器（Orchestrator）在同一条消息里并行派发两个子代理：

1. meta-judge 先生成评分规范（先派发是为了让它在实现改动文件之前观察代码基线）；
2. 实现子代理开始干活，其提示词自带"零样本思维链前缀 + 强制自我批判校验表"，要求它提交前逐项回答"是否覆盖全部需求、是否遗漏边界情况"等问题并附证据。

并行执行让"定标准"不占用额外时间——这是该技能宣称的关键提速点。

第三步：judge 严格打分，且不知道及格线

实现完成后，编排器把 meta-judge 的评分规范 YAML原封不动（不得增删、缩写、改写）连同实现摘要一起交给 judge 代理。judge 的工作流是：

1. 收集上下文，必要时运行 build/test/lint 做实证验证；
2. 先独立起草"我认为正确答案应该长什么样"的参照基线，防止被实现输出带偏；
3. 对照基线做差异分析（匹配/缺口/偏差/错误）；
4. 逐项过 Checklist，逐维度做"锚点定位"式评分——先写推理和证据，后出数字，杜绝"先给分再圆理由"；
5. 加权汇总、应用门限罚则，最后还做一轮自我校验（5 个自问问题）再提交报告。

值得注意的是：编排器永远不会告诉评委"4 分及格"。评委只知道证据和规范，分数是否达标由编排器判断——这是防止评委"放水凑及格"的刻意设计。

评分与重试循环：4 分及格、3 次重试上限

拿到VERDICT / SCORE / ISSUES结构化结论后，决策逻辑非常清晰：

• score ≥ 4.0→ ✅ PASS，输出最终报告（含可选改进建议）；
• 3.0 ≤ score < 4.0→ 处于"自由裁量区间"：若未决问题只有低/中优先级的"小瑕疵"，可接受为 PASS 并列出遗留问题；只要有 High/Critical 问题则必须重试；
• score < 3.0→ 无条件 FAIL，带着评委的具体问题清单进入重试。

重试时有一个容易被忽略的精细设计——模型分级升级（Escalation）：

• 如果首轮分数过低、或问题暴露出"模型没理解任务"而非"漏了细节"，下一次重试把执行代理和评委一起升一档（haiku → sonnet → opus）；
• 如果只是明确的、可定位的具体缺陷，则保持原档位，用精确反馈重跑更快；
• meta-judge不重跑：评分标准在整个重试周期内保持不变，保证跨轮次可比；
• 3 次重试后仍不通过，立即停下来升级给人，给出全部评分历史、顽固问题和四个选项（补充上下文 / 升档重跑 / 修改需求 / 中止），绝不在opus档反复空转。

一行命令启用质量门：/do-and-judge 使用说明

先获取项目（安装 SADD 插件即可启用/do-and-judge命令）：

git clone https://gitcode.com/gh_mirrors/co/context-engineering-kit

基本用法就是把任务描述直接交给命令：

/do-and-judge 重构 UserService 类，使用依赖注入

两个常用参数：

例如：/do-and-judge 重写 API 认证文档覆盖 OAuth2 流程 --strict

模型档位怎么选？haiku / sonnet / opus 决策表

技能文档强调，选模型是"杠杆最大的决策"，比任何提示词技巧都重要。默认档位是sonnet/haiku，opus必须"挣到"才启用：

两条铁律：多条规则同时命中时取最高档（4 行安全关键代码也是 opus 的活）；"纯机械的广范围改动"（如跨 40 个文件改名）不因此升档。

什么时候该用 /do-and-judge？

• ✅ 单任务、边界清晰的实现工作（写功能、修 Bug、改文档）——最典型的场景；
• ✅ 质量要求高、不能靠"看起来不错"交付的任务（用--strict）；
• ✅ 希望自动化闭环、少盯过程的日常开发；
• ⚠️ 任务依赖你的整体架构愿景、需要与 Spec 严格对齐时，可考虑仓库中的 Spec-Driven Development（SDD）插件；
• ⚠️ 多方案对比择优请用/do-competitively，多轮多评委辩论请用/judge-with-debate（见 SADD 命令总览）。

关键文件与延伸阅读

小结：质量门的价值不止于"打分"

/do-and-judge把 LLM-as-Judge 从论文概念变成了可运行、可重试、可升级的工程质量流程：标准前置（meta-judge）、执行与评审上下文隔离、评分有证据可审计、重试带精确反馈、失败有明确的"升级给人"出口。对新手来说，只需记住一句话——把它当成一条带自动返工的流水线：你说清任务，它负责做到"4 分"才交卷。

• AI 技能/插件
• 提示工程
• AI 评测
• 人工智能