Update from Sync Service
This commit is contained in:
49
wiki/Resources/方法论/HarnessEngineering-清华报告.md
Executable file
49
wiki/Resources/方法论/HarnessEngineering-清华报告.md
Executable file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
created: 2026-04-28
|
||||
type: concept
|
||||
tags: [Harness-Engineering, 清华大学, AI-Agent, 驾驭工程]
|
||||
---
|
||||
|
||||
# Harness Engineering 清华大学报告
|
||||
|
||||
> 清华大学 2026 年研究报告(78 页)
|
||||
|
||||
## 报告简介
|
||||
|
||||
清华大学对 **Harness Engineering(驾驭工程)** 的系统性研究报告,涵盖:
|
||||
|
||||
- Harness 的定义与核心概念
|
||||
- 各机构对 Harness 的理解(LangChain、Anthropic、OpenAI、Thoughtworks 等)
|
||||
- Harness 的技术架构与实现
|
||||
- AI Agent 可靠性保障
|
||||
- 实践案例与应用场景
|
||||
|
||||
## 核心概念
|
||||
|
||||
**Harness Engineering** = 在 AI 编程工具之上构建约束框架,确保 AI 编程可约束、可评估、可追溯
|
||||
|
||||
### 四大目标
|
||||
|
||||
| 目标 | 说明 | 手段 |
|
||||
|------|------|------|
|
||||
| 可约束 | AI 输出符合团队规范 | Skill 体系 + 上下文注入 |
|
||||
| 可评估 | 产物质量可度量 | 质量门禁 + 评估机制 |
|
||||
| 可追溯 | 过程透明可审计 | 记录 + 日志 + Hook |
|
||||
| 可扩展 | 持续扩展能力边界 | 可插拔 Skill 体系 |
|
||||
|
||||
## 与其他方法的关系
|
||||
|
||||
| 方法 | 关系 |
|
||||
|------|------|
|
||||
| [[AgenticSE智能体软件工程]] | Harness 是解决 AI 队友可靠性的具体技术 |
|
||||
| [[SDD 规格驱动开发]] | Harness 关注环境,SDD 关注规格 |
|
||||
| [[Superpowers 技能框架]] | Harness 关注环境,Superpowers 关注流程 |
|
||||
|
||||
## 原文档
|
||||
|
||||
- `/obsidian/参考资料/HarnessEngineering_清华大学报告/`
|
||||
- `/obsidian/参考资料/Harness_Engineering/`
|
||||
|
||||
---
|
||||
|
||||
*整理自 Obsidian vault 参考资料*
|
||||
@@ -1,39 +1,41 @@
|
||||
---
|
||||
created: 2026-04-28
|
||||
type: concept
|
||||
tags: [SDD, 规格驱动开发, AI-Engineering, 开发方法论]
|
||||
source: /obsidian/参考资料/SDD_规格驱动开发/
|
||||
tags: [SDD, 规格驱动开发, AI-Engineering]
|
||||
---
|
||||
|
||||
# SDD 规格驱动开发
|
||||
|
||||
> Spec-Driven Development:以结构化的功能规格说明为起点,分解为更小片段、解决方案和任务
|
||||
> Spec-Driven Development:以结构化的功能规格说明为起点的开发工作流
|
||||
|
||||
## 核心公式
|
||||
## 核心定义
|
||||
|
||||
**规格驱动开发 (Spec-Driven Development)**:以结构化的功能规格说明为起点,再经过多步骤将其分解为更小的片段、解决方案和任务的开发工作流。
|
||||
|
||||
### 核心理念
|
||||
- 规格说明优先于代码 (spec-first)
|
||||
- 规格是人与 AI 的共同真相来源
|
||||
- 代码是派生产物,规格是主制品
|
||||
|
||||
### 核心公式
|
||||
|
||||
```
|
||||
传统模式:思考 → 编码 → 文档
|
||||
SDD<EFBFBD><EFBFBD>式:规格 → 生成 → 验证
|
||||
```
|
||||
|
||||
## 核心理念
|
||||
|
||||
- 规格说明优先于代码 (spec-first)
|
||||
- 规格是人与 AI 的共同真相来源
|
||||
- 代码是派生产物,规格是主制品
|
||||
|
||||
## 规格层级
|
||||
|
||||
| 层级 | 说明 |
|
||||
|------|------|
|
||||
| Spec-first | 任务开始时写规格,完成后可丢弃 |
|
||||
| Spec-anchored | 任务完成后保留规格,后续演时使用 |
|
||||
| Spec-anchored | 任务完成后保留规格,后续演进时继续使用 |
|
||||
| Spec-as-source | 规格是持续维护的主制品,代码完全由规格生成 |
|
||||
|
||||
## 工作流阶段
|
||||
|
||||
| 来源 | 阶段 |
|
||||
|------|------|
|
||||
| 来源 | 阶段划分 |
|
||||
|------|----------|
|
||||
| Kevin Ryan / Papalini | Specify → Plan → Tasks → Implement |
|
||||
| GitHub spec-kit | Constitution → Specify → Plan → Tasks → Implement |
|
||||
| Kiro (AWS) | Requirements → Design → Tasks |
|
||||
@@ -43,8 +45,12 @@ SDD<44><44>式:规格 → 生成 → 验证
|
||||
| 方法 | 关系 |
|
||||
|------|------|
|
||||
| [[Harness Engineering]] | SDD 关注规格,Harness 关注运行时环境 |
|
||||
| [[Superpowers技能框架]] | SDD 关注规格,Superpowers 关注执行流程 |
|
||||
| [[Superpowers 技能框架]] | 互补:SDD 关注规格,Superpowers 关注执行流程 |
|
||||
|
||||
## 原文档
|
||||
|
||||
- `/obsidian/参考资料/SDD_规格驱动开发/`
|
||||
|
||||
---
|
||||
|
||||
*整理自 Obsidian 参考资料*
|
||||
*整理自 Obsidian vault 参考资料*
|
||||
|
||||
Reference in New Issue
Block a user