Harness Engineering：AI 编程工程化的完整方法论
·
Harness Engineering：AI 编程工程化的完整方法论
作者按： 本文系统讲解 Harness Engineering 的核心原理，并通过 Spec Kit、Superpower、Claude Code、DeepEval、Instructor、Langfuse 六个工具，逐一演示每一条原理如何在实践中落地。这不是工具推荐清单，而是一张从方法论到工具链的完整映射图。
目录
一、什么是 Harness Engineering？
Harness Engineering 是 AI 编程领域新兴的工程化学科。
“Harness” 一词来自软件工程中的 test harness（测试套件）——指包裹在被测系统外层的一套框架，用于在受控条件下运行、观测和验证目标系统的行为。
在 AI 编程的语境下，harness 是包裹在 AI 模型或 AI Agent 外层的基础设施层。它的核心使命是：
让 AI 编程从"碰运气"变成可控、可验证、可复现的工程活动。
Harness Engineering 解决了什么问题？
不做 Harness Engineering 的 AI 编程，长这样：
用户输入 → LLM 直接输出 → 祈祷结果是对的 → 手动验证
问题很明显：
- 不可预期：同样的提示词，每次输出可能不同
- 不可验证：没有客观标准衡量输出质量
- 不可追溯：出了问题不知道是模型的问题还是提示词的问题
- 不可迭代：不知道改了什么，性能是变好了还是变坏了
Harness Engineering 的出现，正是为了系统性地解决上述问题。
二、六大核心原理
Harness Engineering 建立在以下六条核心原理之上。理解这六条原理，是理解整个工具链设计逻辑的前提。
原理一：结构化输入（Structured Input）
定义： AI 系统的输入必须是结构化、无歧义的，而不是随意的自然语言描述。
为什么重要：
模糊的输入会导致模糊的输出。"帮我写个登录功能"和一份严格定义了接口、验证规则、边界条件的规格文档，会产生截然不同质量的代码。
原理的本质是：
- 用结构化格式代替自由文本输入
- 明确界定"做什么"（What），而非"怎么做"（How）
- 提前消除歧义，降低 AI 误解需求的概率
❌ 低质量输入："帮我做个用户登录"
✅ 高质量输入（结构化规格）：
{
"feature": "user-login",
"requirements": [
"支持邮箱 + 密码登录",
"密码错误 5 次锁定账户 30 分钟",
"登录成功返回 JWT，有效期 24 小时"
],
"acceptance_criteria": [
"正常登录返回 200 + token",
"密码错误返回 401",
"锁定期间登录返回 423"
]
}
原理二：能力编排（Capability Orchestration）
定义： AI 系统的能力边界不应受单次调用上下文的限制。通过编排，AI 可以访问工具、记忆和其他 Agent 协作完成复杂任务。
为什么重要：
单个 LLM 调用存在三个天然瓶颈：
- 上下文窗口有限：无法记住上次对话的内容
- 工具访问受限：不能直接调用外部 API、查询数据库
- 能力单一：一个模型难以同时扮演"编码者"和"审查者"
能力编排通过以下机制突破限制：
- Memory（记忆）：在对话之间持久化知识
- Tool Use（工具调用）：让 AI 能调用外部函数、API
- Multi-Agent（多 Agent 协作）：不同专长的 Agent 分工合作
原理三：受控执行（Controlled Execution）
定义： AI 生成的代码或操作指令，必须在受控环境中执行，而不是直接在生产系统上运行。
为什么重要：
AI 会犯错——幻觉、误解需求、生成危险代码。受控执行的核心是：
先执行，后验证，失败则重试，通过则提交。
受控执行的关键设计：
- 沙箱隔离：在独立容器中运行生成的代码，防止副作用
- 多步验证：跑单元测试 → 集成测试 → 代码审查
- 原子性：要么全部成功，要么全部回滚
- 人工介入点：高风险操作需要人类确认
原理四：结构化输出（Structured Output）
定义： LLM 的输出必须被强制转换为结构化、类型安全的格式，才能被下游系统可靠消费。
为什么重要：
LLM 的原始输出是自由文本，天然不可靠：
LLM 原始输出（不可靠）：
"我帮你分析了一下，这段代码大概有 2-3 个 bug 吧，
主要是空指针那块，建议你加个判断，希望有帮助！"
↓ 下游系统需要的（可靠）：
{
"bug_count": 2,
"severity": "medium",
"affected_lines": [42, 87],
"fix_suggestion": "在第 42 行添加 null check"
}
如果不做结构化输出处理，下游系统要么崩溃，要么依赖脆弱的字符串解析。
原理五：系统性评估（Systematic Evaluation）
定义： AI 系统的质量必须通过客观的量化指标持续评估，不能依赖人工抽查。
为什么重要：
AI 系统最大的工程风险之一是性能退化（regression）：
- 换了一个模型版本
- 修改了提示词措辞
- 更换了检索策略
任何一个看似微小的变更都可能导致整体质量下降，而且往往在生产环境出问题后才被发现。
系统性评估要求：
- 标准化基准：固定的测试集，可重复运行
- 多维度指标：不只是"对不对"，还要看"幻觉率"、“相关性”、“一致性”
- 自动化运行：每次变更都触发评估，不依赖人工
- 历史对比：与基线版本对比，检测退化
原理六：全链路可观测性（Full-chain Observability）
定义： AI 系统的每一次调用、每一个中间步骤都应被记录、追踪和分析，以支持调试、优化和成本控制。
为什么重要：
传统软件出了问题，看日志基本能定位。AI 系统出了问题，需要回答的问题复杂得多：
- 这次回答质量差，是提示词问题还是模型问题？
- 哪个步骤的延迟最高？
- 这个月花了多少 token，哪些用户消耗最多？
- 用户反馈差的请求，有什么共同特征？
没有全链路可观测性，这些问题无法回答，AI 系统就是一个黑盒。
三、工具链：原理的工程化实现
以下六个工具，与上述六条原理形成严格的一一对应关系。
| 工具 | 对应原理 | 核心职能 |
|---|---|---|
| Spec Kit | 结构化输入 | 将需求转为结构化规格文档 |
| Superpower | 能力编排 | 扩展 LLM 的记忆、工具和多 Agent 能力 |
| Claude Code | 受控执行 | 在受控环境中执行 AI 生成的代码操作 |
| Instructor | 结构化输出 | 强制 LLM 输出符合 Pydantic Schema |
| DeepEval | 系统性评估 | 量化评估 LLM 输出质量，支持 CI 集成 |
| Langfuse | 全链路可观测性 | 全链路追踪、成本监控、提示词版本管理 |
四、原理与工具一一对应
原理一 × Spec Kit：结构化输入
Spec Kit 是什么
Spec Kit 是**规格驱动开发（Spec-Driven Development）**的工具，核心思想是：在 AI 生成代码之前，先用结构化格式精确定义需求。
如何对应原理
原理要求：AI 系统的输入必须是结构化、无歧义的。
Spec Kit 的实现方式：
# specs/user-login.spec.yaml
feature: user-login
description: 用户邮箱密码登录功能
requirements:
- 支持邮箱 + 密码登录
- 密码错误超过 5 次，锁定账户 30 分钟
- 登录成功返回 JWT token，有效期 24 小时
interfaces:
input:
email: string (email format)
password: string (min 8 chars)
output:
token: string (JWT)
expires_at: datetime
acceptance_criteria:
- case: 正常登录
input: { email: "user@test.com", password: "correctPass123" }
expected: { status: 200, has_token: true }
- case: 密码错误
input: { email: "user@test.com", password: "wrongPass" }
expected: { status: 401 }
- case: 账户锁定
input: { email: "locked@test.com", password: "anyPass" }
expected: { status: 423 }
原理对应关系：
原理：结构化输入（消除歧义）
↕ 完全对应
工具：Spec Kit（YAML 规格文件）
- "需求是什么" → 在 spec.yaml 中明确定义
- "验收标准是什么" → acceptance_criteria 中量化定义
- "接口规范是什么" → interfaces 中类型化定义
没有 Spec Kit 的问题：
AI 接到"做个登录功能"，生成了不需要的短信验证码逻辑，没有实现账户锁定，JWT 有效期也写成了永久。
有了 Spec Kit：
AI 接到精确的规格文档，每一个边界条件都有明确定义，生成偏差的概率从 60% 降至 10% 以下。
原理二 × Superpower：能力编排
Superpower 是什么
Superpower 是一类 AI 能力扩展框架，通过插件式架构为 LLM 附加记忆、工具调用和多 Agent 协作能力，使其突破单次调用的上下文限制。
如何对应原理
原理要求：通过编排，让 AI 能访问工具、维持记忆、与其他 Agent 协作。
Superpower 的实现方式：
from superpower import Agent, MemoryStore, ToolRegistry
# 1. 长期记忆：跨对话持久化知识
memory = MemoryStore(backend="sqlite")
memory.store("项目技术栈", "Java SpringBoot + Vue3 + MySQL")
memory.store("代码风格", "使用 Lombok，禁止使用 @Autowired 字段注入")
# 2. 工具注册：让 AI 能调用外部函数
tools = ToolRegistry()
tools.register("query_db", lambda sql: db.execute(sql))
tools.register("run_tests", lambda: subprocess.run("mvn test"))
tools.register("search_docs", lambda q: rag_search(q))
# 3. 多 Agent 协作：专业分工
code_generator = Agent(
name="code-generator",
model="claude-3-5-sonnet",
memory=memory,
tools=tools,
system_prompt="你是一名专注于代码生成的 AI 工程师"
)
code_reviewer = Agent(
name="code-reviewer",
model="claude-3-5-sonnet",
system_prompt="你是一名专注于代码审查的资深工程师，对安全漏洞尤其敏感"
)
# 执行：两个 Agent 协作完成代码生成与审查
draft = code_generator.generate(spec)
review = code_reviewer.review(draft)
final_code = code_generator.revise(draft, review.feedback)
原理对应关系：
原理：能力编排（突破单次调用限制）
↕ 完全对应
工具：Superpower（记忆 + 工具 + 多 Agent）
- "AI 需要记住上下文" → Memory 模块
- "AI 需要调用外部系统" → Tool Registry
- "一个 AI 无法搞定复杂任务" → Multi-Agent 协作
原理三 × Claude Code：受控执行
Claude Code 是什么
Claude Code 是 Anthropic 推出的 CLI 编程 Agent，直接在终端中运行，能自主读取代码库、修改文件、运行测试并提交变更。
如何对应原理
原理要求：AI 生成的操作必须在受控环境中执行，有验证，有回滚。
Claude Code 的受控执行机制：
# 在受控模式下运行：先规划，再执行，人工确认后才提交
claude --plan "根据 user-login.spec.yaml 实现登录功能"
# Claude Code 执行流程（受控的关键在于每一步有验证）：
#
# 步骤 1：读取相关文件（只读，无副作用）
# → 读取 spec 文件
# → 读取现有认证相关代码
# → 读取项目技术栈配置
#
# 步骤 2：生成实现方案（思考，无副作用）
# → 制定修改方案
# → 展示 diff 给用户确认
#
# 步骤 3：执行修改（写操作，需确认）
# → 创建 LoginService.java
# → 修改 AuthController.java
#
# 步骤 4：验证（自动）
# → 运行 mvn test
# → 检查编译是否通过
# → 运行对应 spec 的 acceptance tests
#
# 步骤 5：提交或回滚（基于验证结果）
# ✅ 测试全通过 → git commit
# ❌ 测试失败 → 自动重试或报告失败原因
与普通 AI 代码生成的关键区别：
| 维度 | 普通 AI 代码生成 | Claude Code（受控执行） |
|---|---|---|
| 执行环境 | 用户手动复制粘贴 | 直接在项目目录操作 |
| 验证机制 | 无，靠人工检查 | 自动运行测试套件 |
| 失败处理 | 用户重新描述问题 | 自动分析报错并修复 |
| 上下文理解 | 只看粘贴的代码片段 | 遍历整个代码库 |
| 回滚能力 | 手动撤销 | Git diff + 原子操作 |
原理对应关系：
原理：受控执行（先执行后验证，失败则重试）
↕ 完全对应
工具：Claude Code
- "沙箱隔离" → 在项目目录中操作，不影响生产
- "多步验证" → 自动运行测试 → 检查编译 → Acceptance Test
- "失败重试" → 分析报错 → 自动修复 → 再次测试
- "人工介入点" → --plan 模式，执行前展示 diff 确认
原理四 × Instructor：结构化输出
Instructor 是什么
Instructor 是基于 Pydantic 的 LLM 结构化输出库，通过 Function Calling 或 JSON Mode 强制 LLM 按照预定义 Schema 输出，并在解析失败时自动重试。
如何对应原理
原理要求：LLM 输出必须是类型安全的结构化格式。
Instructor 的实现方式：
import instructor
from anthropic import Anthropic
from pydantic import BaseModel, Field
from typing import List
# 1. 定义期望的输出结构（Schema）
class CodeGenerationResult(BaseModel):
"""Claude Code 执行后的结构化结果"""
files_created: List[str] = Field(
description="新创建的文件路径列表"
)
files_modified: List[str] = Field(
description="被修改的文件路径列表"
)
tests_passed: int = Field(
description="通过的测试数量", ge=0
)
tests_failed: int = Field(
description="失败的测试数量", ge=0
)
compilation_success: bool = Field(
description="代码是否编译通过"
)
coverage_percent: float = Field(
description="测试覆盖率百分比", ge=0, le=100
)
known_issues: List[str] = Field(
default=[],
description="已知问题或警告"
)
# 2. 用 Instructor 封装客户端
client = instructor.from_anthropic(Anthropic())
# 3. 调用 LLM，强制返回结构化结果
result: CodeGenerationResult = client.messages.create(
model="claude-3-5-haiku", # 解析用便宜模型即可
messages=[{
"role": "user",
"content": f"分析以下代码生成任务的执行结果：\n\n{raw_output}"
}],
response_model=CodeGenerationResult # ← 核心：强制结构化
)
# 4. 下游系统安全消费（类型安全，无需解析字符串）
if result.compilation_success and result.tests_failed == 0:
print(f"✅ 生成成功：{len(result.files_created)} 个新文件")
print(f" 测试通过率：{result.tests_passed}/{result.tests_passed + result.tests_failed}")
print(f" 测试覆盖率：{result.coverage_percent:.1f}%")
else:
print(f"❌ 生成失败：{result.known_issues}")
Instructor 的自动重试机制：
LLM 第一次输出 → 解析失败（字段缺失/类型错误）
↓
Instructor 自动将错误信息附加到对话
↓
LLM 第二次输出 → 解析成功
↓
返回 CodeGenerationResult 实例
原理对应关系：
原理：结构化输出（类型安全，下游可靠消费）
↕ 完全对应
工具：Instructor
- "自由文本 → 结构化" → Pydantic Schema 强制约束
- "解析失败崩溃" → 自动重试机制（max_retries=3）
- "类型不安全" → Pydantic 类型验证（int/float/bool/List）
- "多 Provider 兼容" → 统一接口（OpenAI/Anthropic/Cohere）
原理五 × DeepEval：系统性评估
DeepEval 是什么
DeepEval 是专为 LLM 应用设计的开源评估框架，提供 15+ 种内置评估指标，支持 pytest 集成和 CI/CD 自动化评估。
如何对应原理
原理要求：客观量化地持续评估 AI 系统质量，检测性能退化。
DeepEval 的实现方式：
# tests/eval/test_code_generation.py
import pytest
from deepeval import assert_test, evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
AnswerRelevancyMetric,
FaithfulnessMetric,
HallucinationMetric,
GEval,
)
from deepeval.metrics.base_metric import BaseMetric
# 1. 自定义指标：代码符合规格程度
class SpecComplianceMetric(BaseMetric):
"""衡量生成代码是否满足 Spec Kit 规格中的验收条件"""
threshold = 0.85
name = "Spec Compliance"
def measure(self, test_case: LLMTestCase) -> float:
# 用 LLM-as-judge 评估代码与规格的符合度
...
# 2. 定义评估套件
def get_eval_metrics():
return [
# 答案相关性：生成的代码与需求是否相关
AnswerRelevancyMetric(threshold=0.7),
# 忠实性：生成的代码是否基于规格，而非编造
FaithfulnessMetric(threshold=0.8),
# 幻觉率：是否生成了规格中未要求的功能
HallucinationMetric(threshold=0.1),
# 规格合规度：自定义指标
SpecComplianceMetric(),
# G-Eval：用 LLM 评估代码质量（可读性、安全性）
GEval(
name="Code Quality",
criteria="代码是否遵循 SOLID 原则，是否有明显安全漏洞",
evaluation_params=["actual_output"],
threshold=0.75
)
]
# 3. 参数化测试（覆盖多个功能点）
@pytest.mark.parametrize("spec_name,expected_lines", [
("user-login", 50),
("user-register", 80),
("password-reset", 60),
])
def test_code_generation_quality(spec_name, expected_lines):
# 加载规格和生成的代码
spec = load_spec(spec_name)
generated_code = load_generated_code(spec_name)
test_case = LLMTestCase(
input=str(spec),
actual_output=generated_code,
expected_output=spec.get("reference_implementation", ""),
retrieval_context=[spec.get("description", "")]
)
assert_test(test_case, get_eval_metrics())
# 4. CI 回归测试：对比基线版本
def test_no_regression_from_baseline():
current_results = run_full_eval()
baseline_results = load_baseline()
# 任何指标下降超过 5% 都视为退化
for metric_name, baseline_score in baseline_results.items():
current_score = current_results[metric_name]
assert current_score >= baseline_score * 0.95, \
f"性能退化：{metric_name} 从 {baseline_score:.2f} 降至 {current_score:.2f}"
评估结果示例：
=============================== DeepEval Results ================================
✅ Answer Relevancy: 0.89 (threshold: 0.70) PASSED
✅ Faithfulness: 0.92 (threshold: 0.80) PASSED
✅ Hallucination: 0.04 (threshold: 0.10) PASSED
✅ Spec Compliance: 0.91 (threshold: 0.85) PASSED
✅ Code Quality: 0.83 (threshold: 0.75) PASSED
Overall: 5/5 metrics passed
Regression check: No degradation from baseline ✅
原理对应关系：
原理：系统性评估（客观量化，检测退化）
↕ 完全对应
工具：DeepEval
- "标准化基准" → 固定的 LLMTestCase 测试集
- "多维度指标" → 相关性/忠实性/幻觉率/自定义指标
- "自动化运行" → pytest 集成，CI 触发
- "历史对比" → baseline 对比，5% 退化即告警
原理六 × Langfuse：全链路可观测性
Langfuse 是什么
Langfuse 是开源的 LLM 应用可观测性平台，提供全链路追踪、提示词版本管理、评估集成和成本分析四大核心模块。
如何对应原理
原理要求：AI 系统每一次调用、每一个步骤都应被记录、追踪和分析。
Langfuse 的实现方式：
from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context
langfuse = Langfuse(
public_key="pk-lf-...",
secret_key="sk-lf-..."
)
# 1. @observe 装饰器：自动追踪函数调用（零侵入）
@observe(name="full-pipeline")
def run_pipeline(spec_name: str) -> PipelineResult:
@observe(name="load-spec")
def step1_load_spec():
spec = load_spec(spec_name)
langfuse_context.update_current_observation(
output=spec,
metadata={"spec_file": f"specs/{spec_name}.yaml"}
)
return spec
@observe(name="generate-code")
def step2_generate_code(spec):
result = claude_code.generate(spec)
# 记录模型调用详情（token 用量、成本）
langfuse_context.update_current_observation(
model="claude-3-5-sonnet",
input=spec,
output=result,
usage={
"input": result.input_tokens,
"output": result.output_tokens,
"unit": "TOKENS"
}
)
return result
@observe(name="evaluate")
def step3_evaluate(code_result):
eval_result = deepeval.evaluate(code_result)
# 将 DeepEval 评估结果上报 Langfuse
langfuse_context.score_current_trace(
name="spec-compliance",
value=eval_result.spec_compliance_score,
comment=f"通过 {eval_result.tests_passed} / {eval_result.tests_total} 测试"
)
return eval_result
spec = step1_load_spec()
code_result = step2_generate_code(spec)
eval_result = step3_evaluate(code_result)
return PipelineResult(spec=spec, code=code_result, eval=eval_result)
# 2. 提示词版本管理
prompt = langfuse.get_prompt(
name="code-generation-prompt",
version="v2", # 精确指定版本，便于 A/B 测试和回滚
label="production"
)
# 3. 用户反馈收集
def collect_user_feedback(trace_id: str, rating: int, comment: str):
langfuse.score(
trace_id=trace_id,
name="user-satisfaction",
value=rating, # 1-5 分
comment=comment
)
Langfuse Dashboard 可观测的指标：
Langfuse 可视化看板
│
├── 实时追踪（Traces）
│ ├── 每次 pipeline 运行的完整调用链路
│ ├── 每个步骤的耗时分布（P50/P90/P99）
│ └── 失败步骤的错误原因
│
├── 成本分析（Cost Analytics）
│ ├── 按日/周/月的 token 消耗趋势
│ ├── 按模型分类的成本占比
│ └── 高成本用户/请求识别
│
├── 质量追踪（Quality Tracking）
│ ├── DeepEval 评分的历史趋势
│ ├── 用户满意度评分分布
│ └── 低质量请求的特征分析
│
└── 提示词管理（Prompt Management）
├── 各版本提示词的性能对比
├── 在线编辑和版本发布
└── 生产版本一键回滚
原理对应关系：
原理：全链路可观测性（记录每一步，支持调试和优化）
↕ 完全对应
工具：Langfuse
- "追踪每次调用" → Trace + Span 全链路记录
- "成本控制" → Token 用量 + 成本实时统计
- "延迟分析" → 每步耗时 + P99 延迟看板
- "提示词版本" → 版本管理 + A/B 测试 + 一键回滚
- "用户反馈" → Score API 收集满意度
五、完整工具栈架构图
┌──────────────────────────────────────────────────────────────────────┐
│ Harness Engineering 完整工具栈 │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理一：结构化输入 工具：Spec Kit │ │
│ │ │ │
│ │ 需求描述 ──YAML规格化──→ 明确的 acceptance_criteria │ │
│ └───────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理二：能力编排 工具：Superpower │ │
│ │ │ │
│ │ 单次 LLM 调用 ──记忆/工具/多Agent──→ 具备完整上下文的 AI 系统 │ │
│ └───────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理三：受控执行 工具：Claude Code │ │
│ │ │ │
│ │ AI 指令 ──沙箱+验证+重试──→ 经过测试验证的代码变更 │ │
│ └───────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理四：结构化输出 工具：Instructor │ │
│ │ │ │
│ │ 自由文本输出 ──Pydantic Schema──→ 类型安全的结构化数据 │ │
│ └───────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理五：系统性评估 工具：DeepEval │ │
│ │ │ │
│ │ 每次变更 ──多维指标+回归测试──→ 量化的质量报告 │ │
│ └───────────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ 原理六：全链路可观测性 工具：Langfuse │ │
│ │ │ │
│ │ 每个步骤 ──Trace+Score+Cost──→ 可调试可优化的 AI 系统 │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────┘
六个工具的数据流
用户需求
│
▼
[Spec Kit] 结构化规格文件 (user-login.spec.yaml)
│
▼
[Superpower] 加载记忆 + 注册工具 + 启动 Agent 协作
│
▼
[Claude Code] 读取规格 → 生成代码 → 运行测试 → 提交
│
▼
[Instructor] 将执行结果解析为 CodeGenerationResult 实例
│
▼
[DeepEval] 对结构化结果运行多维评估
│ ├── AnswerRelevancy: 0.89 ✅
│ ├── Faithfulness: 0.92 ✅
│ └── Spec Compliance: 0.91 ✅
│
▼
[Langfuse] 全链路追踪 + 评分上报 + 成本记录
│ ├── 本次 pipeline 耗时: 45s
│ ├── Token 消耗: 3,200 input + 1,800 output
│ └── 评估分数: 91/100
│
▼
最终结果：
✅ 代码已生成并提交
📊 评估报告：5/5 指标通过
🔗 追踪链接：https://cloud.langfuse.com/trace/abc123
六、总结
原理与工具的完整对应表
| 原理 | 工具 | 解决的核心问题 | 没有它会怎样 |
|---|---|---|---|
| 结构化输入 | Spec Kit | AI 接到模糊需求，生成偏差大 | 生成代码功能不全，频繁返工 |
| 能力编排 | Superpower | AI 无法跨对话记忆，无法调用工具 | 每次都要重新解释项目背景 |
| 受控执行 | Claude Code | AI 生成的代码没有验证直接投产 | 代码正确性无法保证 |
| 结构化输出 | Instructor | LLM 自由文本输出无法被程序消费 | 下游系统脆弱，易崩溃 |
| 系统性评估 | DeepEval | 不知道 AI 系统质量是否在退化 | 改了提示词不知道变好变坏 |
| 全链路可观测 | Langfuse | 出了问题无从定位，成本不可控 | AI 系统是一个黑盒 |
关键结论
Harness Engineering 的本质，是将 AI 系统从"艺术创作"变成"工程实践"。
- 没有结构化输入，AI 是个读心术表演者
- 没有能力编排，AI 是个健忘的实习生
- 没有受控执行，AI 是个莽撞的操作员
- 没有结构化输出，AI 是个只会口头报告的员工
- 没有系统性评估，AI 系统是个无法量化的玄学
- 没有全链路可观测，AI 系统是个成本失控的黑盒
六个原理，六个工具，每一个工具解决一个原理级别的问题，共同构成一套可落地的 AI 编程工程化方法论。
本文最后更新于 2026 年 6 月
如有问题或建议，欢迎在评论区交流。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
3
0- 0
已为社区贡献2条内容
所有评论(0)