Harness Engineering：AICode 的灵魂

Ooder A2UI 从难产到重生的深度实践 —— 当 AI 原生编程遇上渐进式披露，Harness 如何让不确定的 LLM 输出变成可驾驭的工程系统

​

Ooder 架构团队 · 2026 年 4 月 30 日 · Java + Harness Engineering + 渐进式披露 + SPI

1. 引言：A2UI，ooder 家族中最难产的"孩子"

在 ooder 庞大的技术家族中，**A2UI（Augmented & Autonomous UI）**堪称最"难产"的一个。它的诞生史，几乎是一部微缩的 AI 原生编程进化史。

1.1 三段式难产历程

第一阶段：RAD 可视化设计器时代

最初的 A2UI 脱胎于传统的 RAD（Rapid Application Development）可视化设计器。开发者通过拖拽组件、配置属性来生成界面。这个阶段的核心理念是"所见即所得"，但问题是——它仍然需要人类开发者手动操作。当业务需求爆炸式增长时，这种人工配置的方式成为了瓶颈。

第二阶段：NLP A2UI 引擎的觉醒

随着大语言模型（LLM）的崛起，团队开始探索"说一句话，生成一个界面"的可能性。自然语言处理（NLP）被引入 A2UI，用户可以用"给我一个带分页的员工列表"这样的描述，直接生成对应的 UI 组件。这听起来很美好，但很快遇到了一个根本性问题：LLM 的输出是不确定的。同样的输入，可能今天生成 TreeGrid，明天生成 FormLayout；置信度高低无从得知；出错时更是"哑巴吃黄连"——系统不会告诉你它哪里没把握。

第三阶段：SkillFlow 与 A2UI 的整合阵痛

为了解决纯 LLM 的不可靠性，团队引入了 SkillFlow 架构——通过预定义的技能（Skill）来约束 LLM 的输出空间。TreeGridSkill、FormSkill、ChartSkill……每个技能都是一个精确定义的"模具"。但新的问题随之而来：技能系统和 LLM 引擎之间如何协作？当技能无法匹配时，是回退到 LLM，还是直接报错？多个引擎的决策如何融合？这一阶段，A2UI 面临的是多引擎协作的复杂性危机。

1.2 当前版本：基于 Harness Engineering 的重构

直到 Harness Engineering 方法论的引入，A2UI 才真正找到了自己的"灵魂"。

Harness Engineering 不是又一个框架，而是一种_工程哲学__：它承认 LLM 的不确定性，但不放任这种不确定性；它接受 AI 的"黑盒"本质，但要求在黑盒外面装上"缰绳"（Harness）——置信度仪表盘、渐进式披露开关、多引擎协作协议、反馈学习回路。_

图 1：A2UI 从 RAD 到 Harness Engineering 的四阶段演进

---

2. AICode 发展的三个阶段与 A2UI 的宿命

2.1 阶段一：模板式生成（Template-Driven）

早期的 AICode 工具本质上是"高级模板引擎"。它们根据固定模板填充变量，生成代码。优点是确定性高，缺点是灵活性低——面对稍微复杂的业务逻辑就束手无策。A2UI 在 RAD 时代就是这个阶段。

2.2 阶段二：提示工程（Prompt Engineering）

LLM 出现后，AICode 进入了提示工程阶段。开发者精心构造 Prompt，试图"诱导"模型生成正确的代码。这个阶段的核心矛盾是：Prompt 的脆弱性——换一个模型、调一个参数，结果可能天差地别。A2UI 的 NLP 引擎阶段正是如此。

2.3 阶段三：Harness 式驾驭（Harness-Driven）

Harness Engineering 代表了 AICode 的第三个阶段。它不再试图消除不确定性，而是将不确定性纳入工程体系进行管理。

图 2：Prompt Engineering 与 Harness Engineering 的核心差异对比

维度	Prompt Engineering	Harness Engineering
对不确定性的态度	试图消除	承认并管理
输出质量评估	主观判断	置信度量化
失败处理	重试/报错	渐进降级/澄清请求
可解释性	黑盒	全程透明报告
多引擎协作	串行回退	并行融合
学习能力	无	反馈闭环修正

---

3. Harness Engineering：从"祈祷式编程"到"驾驭式工程"

3.1 什么是 Harness Engineering？

Harness（驾驭）一词借自马术——不是让马消失，而是给马配上鞍、缰、镫，让骑手能够安全、可控地驾驭这匹力量强大的动物。

在 AICode 语境下，LLM 就是那匹"烈马"：力量强大但难以预测。Harness Engineering 就是给 LLM 装上：

• 缰绳（Confidence Thresholds）：置信度阈值控制，让系统知道"什么时候该停"
• 鞍具（Stage Contracts）：阶段契约，每个处理节点都有输入验证、输出验证和失败回退
• 仪表盘（Transparency Report）：透明度报告，全程记录"系统在想什么"
• 训练场（Feedback Harness）：反馈系统，让系统从错误中学习

3.2 为什么 Harness 是 AICode 的灵魂？

传统的软件工程建立在确定性之上：给定输入 A，必然得到输出 B。但 AICode 的核心——LLM——本质上是概率性的：给定输入 A，得到输出 B 的概率是 85%，输出 C 的概率是 10%，还有 5% 的概率会胡说八道。

Harness Engineering 的灵魂在于：它让概率性系统变得可工程化。通过置信度量化、渐进披露、契约验证、反馈学习，我们第一次可以对 LLM 说——"我知道你不确定，但没关系，告诉我你有多确定，我们按确定程度来决定下一步。"

---

4. Harness 五层模型：给 AI 装上"缰绳"与"仪表盘"

在 A2UI 的重构中，我们设计了 Harness 五层模型：

图 3：Harness 五层模型 —— 从意图理解到反馈学习的完整驾驭体系

4.1 第一层：意图驾驭（Intent Harness）

职责：理解用户到底想要什么。

自然语言是模糊的。"做一个员工管理页面"——是要列表？表单？还是仪表盘？Intent Harness 通过多维度分析（关键词匹配、上下文推断、历史行为）来量化"理解程度"。

// IntentAnalysisStage 的核心逻辑
public HarnessResult<JSONObject> process(Object input) {
    String userInput = (String) input;

    // 多维度意图分析
    double keywordConfidence = analyzeKeywords(userInput);
    double contextConfidence = analyzeContext(userInput);
    double historyConfidence = analyzeHistory(userInput);

    // 加权融合
    double overallConfidence = weightedFusion(
        keywordConfidence, contextConfidence, historyConfidence
    );

    if (overallConfidence < CLARIFICATION_THRESHOLD) {
        // 不够确定？直接问用户！
        return HarnessResult.needsClarification(
            "您需要的是：1) 数据列表 2) 录入表单 3) 统计仪表盘？",
            "IntentAnalysis"
        );
    }

    return HarnessResult.success(requirement, overallConfidence, "IntentAnalysis");
}

​

​

4.2 第二层：策略驾驭（Strategy Harness）

职责：选择最优的执行策略。

A2UI 中有多个"引擎"可以完成同一个任务：A2uiSkill（精确匹配，置信度高但覆盖率低）、SkillsBridge（本地规则匹配，速度快）、LLMInterface（通用能力强，但成本高、延迟大）。Strategy Harness 不是简单地"选一个"，而是并行执行所有可用引擎，然后基于置信度做加权融合。

4.3 第三层：组件驾驭（Component Harness）

职责：将策略输出转化为具体的 UI 组件。

这一层处理组件选择、属性绑定、事件关联。每个决策都带有置信度标签——"这个组件选择我有 92% 的把握"，"这个事件绑定我只有 65% 的把握，建议人工复核"。

4.4 第四层：契约驾驭（Contract Harness）

职责：确保每个阶段都"说到做到"。

通过 StageContract 接口，每个 Pipeline Stage 都必须实现：输入验证、核心处理、输出验证、失败回退。这是 Harness Engineering 的工程根基——契约化编程。

4.5 第五层：反馈驾驭（Feedback Harness）

职责：让系统从"一次性执行"变成"可学习进化"。

记录每次执行轨迹、缓存历史结果、应用人工修正、提升后续置信度。

---

5. 渐进式披露：当系统说"我不太确定"时

5.1 核心理念

渐进式披露（Progressive Disclosure）是 Harness Engineering 最具用户价值的设计。它回答了一个关键问题：当系统不确定时，应该给用户看什么？

传统方案是"全有或全无"——要么生成完整代码，要么报错。Harness 方案是"有多少给多少"：

图 4：渐进式披露 —— 根据置信度自动决定生成内容的详细程度

置信度区间	披露级别	用户看到的内容
0.00 - 0.30	骨架	只有组件框架，没有细节
0.30 - 0.60	基础	核心组件 + 基本配置
0.60 - 0.85	完整	完整实现（含事件、样式）
0.85 - 1.00	优化	生产级优化代码

5.2 代码实现

public enum DisclosureLevel {
    SKELETON(0.30, "骨架", "仅生成组件框架结构"),
    ESSENTIAL(0.60, "基础", "生成核心组件和基本配置"),
    COMPLETE(0.85, "完整", "生成完整实现包括事件和样式"),
    POLISHED(0.95, "优化", "生成优化后的生产级代码");

    public boolean shouldProceed(double currentConfidence) {
        return currentConfidence >= confidenceThreshold;
    }
}

​

​

在 Pipeline 执行过程中，每个 Stage 完成后都会检查当前置信度对应的披露级别。如果某个 Stage 的置信度跌破阈值，Pipeline 不会直接失败，而是：

1. 返回已生成的部分结果（Partial Result）
2. 附带澄清问题（Clarification Questions）
3. 标记需要人工复核的节点（Requires Review）

这种设计让 A2UI 从"要么成功要么失败"的二元系统，变成了"连续谱系"的渐进系统。

---

6. 协作式策略：多引擎共舞的置信度加权融合

6.1 从"单选"到"协作"

传统多引擎架构通常是串行回退：先试试 A，不行再试 B，再不行试 C。这种模式的缺点是延迟累积、失败隔离差、没有融合。

Harness 的 CollaborativeHarnessStrategy 采用并行执行 + 置信度加权融合：

图 5：协作式策略 —— 多引擎并行执行，按置信度加权融合决策

public HarnessResult<Object> execute(ConversionRequest request) {
    // Step 1: 并行执行所有可用引擎
    Future<HarnessResult<Object>> skillFuture =
        executor.submit(() -> executeSkillsBridge(request));
    Future<HarnessResult<Object>> llmFuture =
        executor.submit(() -> executeLLMInterface(request));
    Future<HarnessResult<Object>> a2uiSkillFuture =
        executor.submit(() -> executeA2uiSkill(request));

    // Step 2: 收集结果（带超时保护）
    HarnessResult<Object> skillResult = skillFuture.get(SKILL_TIMEOUT, MS);
    HarnessResult<Object> llmResult = llmFuture.get(LLM_TIMEOUT, MS);
    HarnessResult<Object> a2uiResult = a2uiSkillFuture.get(SKILL_TIMEOUT, MS);

    // Step 3: 置信度加权融合决策
    return makeFusionDecision(a2uiResult, skillResult, llmResult, request);
}

​

​

6.2 融合决策逻辑

融合不是简单的"选最高的"，而是根据业务场景动态决策：

private HarnessResult<Object> makeFusionDecision(
    HarnessResult<Object> a2uiResult,
    HarnessResult<Object> skillResult,
    HarnessResult<Object> llmResult,
    ConversionRequest request) {

    // 优先级1：A2uiSkill 高置信度 → 直接使用
    if (a2uiResult != null && a2uiResult.isReliable()) {
        return a2uiResult;
    }

    // 优先级2：多引擎都可靠 → 加权融合
    if (isMultiEngineReliable(a2uiResult, skillResult, llmResult)) {
        return weightedFusion(a2uiResult, skillResult, llmResult);
    }

    // 优先级3：部分可靠 → 返回最佳 + 建议
    return selectBestWithSuggestions(a2uiResult, skillResult, llmResult);
}

​

​

---

7. 反馈闭环：让系统从"一次性"变成"可学习"

7.1 FeedbackHarness 设计

public class FeedbackHarness {
    private final List<ExecutionTrace> traces;           // 执行轨迹
    private final Map<String, List<Correction>> correctionMap; // 修正记录
    private final Map<String, HarnessResult<?>> historyCache;  // 历史缓存

    public void recordTrace(String stage, HarnessResult<?> result, Object input);
    public void addCorrection(String stage, Correction correction);
    public HarnessResult<?> applyCorrection(HarnessResult<?> result, String stage);
    public ExplainabilityReport generateReport();
}

​

​

图 6：Feedback Harness —— 从执行到学习到进化的完整闭环

7.2 自我修正机制

当用户对某个生成结果进行人工修正后，系统会：

1. 记录修正：什么 Stage、什么输入、从什么改为什么
2. 提升置信度：下次遇到类似输入，该 Stage 的初始置信度提升
3. 缓存结果：相同输入直接返回修正后的结果
4. 生成报告：透明度报告包含所有修正历史

这让 A2UI 从一个" Stateless 的生成器"变成了" Stateful 的学习系统"。

---

8. 代码实战：Harness 核心实现解析

8.1 HarnessResult：让结果"会说话"

public class HarnessResult<T> {
    private final T data;              // 实际数据
    private final double confidence;   // 置信度 0.0-1.0
    private final String source;       // 来源：SKILL / LLM / RULE / HYBRID
    private final List<String> harnessLog;  // 驾驭日志
    private final boolean requiresReview;   // 是否需要复核
    private final List<String> suggestions; // 改进建议

    public boolean isReliable() {
        return confidence >= 0.85;
    }

    public boolean needsClarification() {
        return confidence < 0.60;
    }
}

​

​

HarnessResult 解决了 AICode 的核心痛点：LLM 输出不再是裸数据，而是带有完整元信息的"会说话的结果"。

8.2 NlpHarnessPipeline：契约化编排

public class NlpHarnessPipeline {
    private final List<PipelineStage<?, ?>> stages;
    private final FeedbackHarness feedbackHarness;

    private void initializeStages() {
        stages.add(new IntentAnalysisStage());      // 意图分析
        stages.add(new ComponentSelectionStage());  // 组件选择
        stages.add(new EventDesignStage());         // 事件设计
        stages.add(new StyleGenerationStage());     // 样式生成
        stages.add(new LayoutCompositionStage());   // 布局编排
        stages.add(new CodeGenerationStage());      // 代码生成
    }

    public JSONObject execute(String userInput) {
        // 每个 Stage 都有输入验证、处理、输出验证、失败回退
        for (PipelineStage stage : stages) {
            ValidationResult inputValidation = stage.validateInput(currentData);
            if (!inputValidation.isValid()) {
                HarnessResult fallback = stage.fallback(currentData, error);
                continue;
            }

            HarnessResult stageResult = stage.process(currentData);

            if (stageResult.needsClarification()) {
                return createClarificationResponse(stageResult);
            }

            currentData = stageResult.getData();
        }
    }
}

​

​

8.3 TransparencyReport：可解释性的工程化

public class TransparencyReport {
    public void addDecisionStep(String stage, String decision,
                                String reason, double confidence);
    public void recordEngineUsed(String engineName);
    public void setFinalResult(double confidence, String source);

    // 生成人类可读报告
    public String generateHumanReadableReport();

    // 生成 JSON 报告供系统消费
    public JSONObject generateJsonReport();
}

​

​

---

9. 结语：Harness Engineering 是 AICode 的灵魂

回顾 A2UI 的演进历程——从 RAD 可视化设计器，到 NLP A2UI 引擎，到 SkillFlow 整合，再到如今的 Harness Engineering 重构——我们走过了一条从"确定性幻觉"到"不确定性驾驭"的认知升级之路。

9.1 三个核心洞察

洞察一：LLM 的不确定性不是 Bug，是 Feature

Harness Engineering 的伟大之处，在于它不再试图消除 LLM 的不确定性，而是将其转化为可量化的工程参数。置信度、披露级别、契约验证——这些概念让"不确定"变得可以计算、可以控制、可以优化。

洞察二：AICode 的质量不是"生成得好不好"，而是"驾驭得好不好"

一个好的 AICode 系统，不是每次都能生成完美代码的系统，而是：

• 知道自己什么时候确定、什么时候不确定
• 不确定时能优雅降级，而不是硬撑
• 失败时能给出清晰的诊断和建议
• 能从错误中学习，越用越好

这正是 Harness Engineering 所定义的"驾驭"。

洞察三：渐进式披露是 AI 与人类的"共同语言"

在传统的软件工程中，机器要么完全服从，要么完全拒绝。Harness 的渐进式披露创造了一种新的交互范式：机器可以"试探性地"给出部分结果，人类可以"指导性地"提供反馈，双方在迭代中共同逼近最优解。

9.2 面向未来

Harness Engineering 在 A2UI 中的实践只是一个开始。随着多模态模型、Agent 系统、AutoML 的发展，Harness 的五层模型可以自然扩展：

• Intent Harness → 多模态意图理解（文本 + 语音 + 草图）
• Strategy Harness → Agent 协作网络（多个 AI Agent 的置信度博弈）
• Component Harness → 动态组件市场（实时下载、验证、集成第三方组件）
• Contract Harness → 形式化验证（用数学证明替代单元测试）
• Feedback Harness → 联邦学习（跨用户、跨组织的集体进化）

9.3 最后的话

A2UI 是 ooder 家族中最难产的"孩子"，但也许正是因为这份"难产"，让它成为了最有深度的"孩子"。Harness Engineering 不是银弹，它不能消除 AI 的不确定性，但它给了我们一套_与不确定性共处的工程智慧__。_

在 AICode 的时代，写代码的方式正在发生根本性变革。但有一条工程法则永远不会变：好的系统不是不出错的系统，而是出错时知道如何优雅处理的系统。

Harness Engineering，就是让 AI 学会"优雅"的那根缰绳。

​