流浪小鱼1. Harness Engineering与SDD：AI工程化的双轨演进
在2026年的AI工程领域，Mitchell Hashimoto和OpenAI团队相继提出的Harness Engineering概念，正在重塑我们构建软件的方式。作为一名长期实践AI辅助开发的工程师，我发现这背后隐藏着一个关键认知转变：当AI成为代码生产的主力，人类工程师的核心价值从"写代码"转向了"设计让AI可靠工作的环境"。
规范驱动开发（Spec-Driven Development，简称SDD）正是在这个背景下展现出新的生命力。它不再只是传统软件开发中的文档先行实践，而是演变为构建AI可消费的工程知识体系的方法论。就像高速公路需要护栏不是因为它比乡间小路更危险，而是因为车速更快、事故后果更严重——Harness Engineering让AI的开发效率倍增，同时也放大了规范体系的重要性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Harness Engineering的本质解析
2.1 从纠错机制到系统工程
Mitchell Hashimoto的定义直指核心："每当发现Agent犯错，就工程化一个解决方案使其永不再犯"。这包含两个关键实践：
- 行为模式记录：如在
AGENTS.md中记录错误模式（Ghostty项目案例显示，记录后的问题解决率接近100%） - 验证工具链：开发专用脚本（截图工具、测试过滤器等）让Agent能自我验证
OpenAI则展示了团队级的Harness实现：
plaintext复制docs/
product-specs/ # 产品规格
exec-plans/ # 执行计划
design-docs/ # 设计文档
tools/
custom-linter/ # 架构约束检查
observability/ # 运行时反馈系统
agents/
doc-gardening/ # 文档维护Agent
2.2 工程纪律的范式转移
OpenAI的洞见尤为深刻："纪律从代码转移到支撑结构（scaffolding）"。传统开发中，我们通过代码评审、编码规范来保证质量；AI时代，这些纪律体现在：
- 结构化文档体系
- 机器可执行的约束规则
- 实时反馈回路
最震撼的实践是：他们的Agent在5个月内完成了1500个PR、100万行代码，人类只负责定义产品规格和设计反馈系统。这验证了一个事实：Agent的效能上限取决于其输入信息的质量。
3. SDD在Harness中的三大核心角色
3.1 推理导航系统
优秀的Spec应该像城市地铁图：
- 提供全局网络拓扑（系统架构）
- 标明换乘节点（服务边界）
- 分层展示细节（按需深入）
反例是某金融系统迁移项目，初期未定义清晰的服务边界，导致多个Agent重复实现相同功能，后期合并成本高达300人时。
3.2 语义约束载体
机械约束（如linter）无法处理的典型场景：
- 跨服务错误码映射
- 业务状态流转规则
- 领域特定验证逻辑
我们在电商平台实践中发现：将促销规则用Spec的WHEN/THEN格式定义后，优惠券叠加计算的错误率从12%降至0.3%。
3.3 验证判据体系
完整的验收标准应包含：
markdown复制## 验收标准
- [SC-001] 用户登录
WHEN 输入正确凭证
THEN 返回200及JWT令牌
WHEN 输入错误密码(3次)
THEN 锁定账户1小时
某物流系统通过自动化Spec验证，将生产环境配置错误导致的异常下降了89%。
4. SDD实践方法论
4.1 分层规范体系
成熟方案通常包含三层：
- 系统级：服务网格、领域边界
- 服务级：API契约、状态机
- 组件级：算法逻辑、异常处理
在微服务架构中，我们使用OpenAPI规范作为载体：
yaml复制paths:
/orders:
post:
x-spec:
business-rule: |
新订单必须通过风控检查
error-mapping:
4001: 库存不足 → 前端显示补货提醒
4.2 增量精化流程
有效的Spec开发遵循：
code复制原始需求 → AI生成草案 → 人工精化 → Agent实现 → 差异分析 → Spec迭代
某IoT项目数据显示：经过3轮迭代后，Spec与实现的一致性从初期的65%提升至98%。
4.3 工具链集成
必备工具组合：
- Spec模板引擎（如AsyncAPI）
- 规范检查器（自定义规则）
- 双向追溯系统（Req→Spec→Code）
我们开发的VSCode插件能在编写Spec时：
- 实时提示冲突条款
- 生成测试用例骨架
- 可视化服务依赖
5. 典型挑战与解决方案
5.1 规范漂移防控
实施策略：
- 每日构建时运行Spec-Code一致性检查
- 设置架构守护者Agent（如OpenAI的doc-gardening）
- 强制变更联动机制（修改API必须同步更新Spec）
在某政务云项目中，这套机制将技术债务积累速度降低了72%。
5.2 认知负荷管理
避免AGENTS.md陷阱的方法：
- 保持文件体积<100行
- 只包含导航性内容
- 深层规则链接到具体Spec
我们建立的"规范门户"方案：
mermaid复制graph LR
A[AGENTS.md] --> B(系统概览)
A --> C(服务目录)
A --> D(变更流程)
B --> E[产品规格]
C --> F[API规范]
5.3 团队能力转型
培养"环境设计师"需要：
- 规范写作工作坊（学习WHEN/THEN句式）
- 契约设计演练（模拟跨团队协商）
- AI提示工程训练（精确表达意图）
某车企软件部门通过3个月转型，工程师的Spec产出效率提升4倍。
6. 未来演进方向
下一代Harness可能需要：
- 动态规范调整（根据运行时反馈自动更新Spec）
- 多模态规范表达（结合图表、示例代码）
- 规范影响度预测（修改前评估波及范围）
在机器学习领域，我们正在试验：
- 将模型监控指标反向生成Spec
- 用Diff算法自动检测规范偏离
- 构建规范知识图谱
Harness Engineering不是SDD的替代品，而是让它价值倍增的放大器。当AI的代码生成能力越来越强，那些能设计出优秀规范体系的团队，将获得真正的竞争优势。正如OpenAI工程师所说："解决方案不再是'更努力地编码'，而是'更聪明地设计环境'"。