Harness Engineering：AICode 的灵魂——Ooder A2UI 从难产到重生的深度实践

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 的核心差异对比

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 的核心逻辑publicHarnessResult<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){// 不够确定？直接问用户！returnHarnessResult.needsClarification("您需要的是：1) 数据列表 2) 录入表单 3) 统计仪表盘？","IntentAnalysis");}returnHarnessResult.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：渐进式披露 —— 根据置信度自动决定生成内容的详细程度

5.2 代码实现

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

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

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

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

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

6.1 从"单选"到"协作"

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

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

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

publicHarnessResult<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: 置信度加权融合决策returnmakeFusionDecision(a2uiResult,skillResult,llmResult,request);}

6.2 融合决策逻辑

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

privateHarnessResult<Object>makeFusionDecision(HarnessResult<Object>a2uiResult,HarnessResult<Object>skillResult,HarnessResult<Object>llmResult,ConversionRequest request){// 优先级1：A2uiSkill 高置信度 → 直接使用if(a2uiResult!=null&&a2uiResult.isReliable()){returna2uiResult;}// 优先级2：多引擎都可靠 → 加权融合if(isMultiEngineReliable(a2uiResult,skillResult,llmResult)){returnweightedFusion(a2uiResult,skillResult,llmResult);}// 优先级3：部分可靠 → 返回最佳 + 建议returnselectBestWithSuggestions(a2uiResult,skillResult,llmResult);}

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

7.1 FeedbackHarness 设计

publicclassFeedbackHarness{privatefinal List<ExecutionTrace>traces;// 执行轨迹privatefinal Map<String,List<Correction>>correctionMap;// 修正记录privatefinal Map<String,HarnessResult<?>>historyCache;// 历史缓存publicvoidrecordTrace(String stage,HarnessResult<?>result,Object input);publicvoidaddCorrection(String stage,Correction correction);publicHarnessResult<?>applyCorrection(HarnessResult<?>result,String stage);publicExplainabilityReportgenerateReport();}

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

7.2 自我修正机制

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

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

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

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

8.1 HarnessResult：让结果"会说话"

publicclassHarnessResult<T>{privatefinalTdata;// 实际数据privatefinal double confidence;// 置信度 0.0-1.0privatefinal String source;// 来源：SKILL / LLM / RULE / HYBRIDprivatefinal List<String>harnessLog;// 驾驭日志privatefinal boolean requiresReview;// 是否需要复核privatefinal List<String>suggestions;// 改进建议publicbooleanisReliable(){returnconfidence>=0.85;}publicbooleanneedsClarification(){returnconfidence<0.60;}}

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

8.2 NlpHarnessPipeline：契约化编排

publicclassNlpHarnessPipeline{privatefinal List<PipelineStage<?,?>>stages;privatefinal FeedbackHarness feedbackHarness;privatevoidinitializeStages(){stages.add(newIntentAnalysisStage());// 意图分析stages.add(newComponentSelectionStage());// 组件选择stages.add(newEventDesignStage());// 事件设计stages.add(newStyleGenerationStage());// 样式生成stages.add(newLayoutCompositionStage());// 布局编排stages.add(newCodeGenerationStage());// 代码生成}publicJSONObjectexecute(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()){returncreateClarificationResponse(stageResult);}currentData=stageResult.getData();}}}

8.3 TransparencyReport：可解释性的工程化

publicclassTransparencyReport{publicvoidaddDecisionStep(String stage,String decision,String reason,double confidence);publicvoidrecordEngineUsed(String engineName);publicvoidsetFinalResult(double confidence,String source);// 生成人类可读报告publicStringgenerateHumanReadableReport();// 生成 JSON 报告供系统消费publicJSONObjectgenerateJsonReport();}

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 学会"优雅"的那根缰绳。