Harness Engineering：从”AI 辅助”到”驾驭 AI”的工程效能革命

本文是【AI 专题精讲】系列第 13 篇。 上一篇：Cursor Skill 开发：把工程经验变成 AI 可执行的技能

---

这篇文章你会得到什么

上一篇我们学了怎么开发 Skill，把工程经验教给 AI。但单个 Skill 只是一个”技能点”。如果把 Rule、Skill、Hook、Subagent 系统化地组合起来，你就不再是”被 AI 辅助写代码”，而是在驾驭 AI 做工程。

这就是 Harness Engineering（驾驭工程）——一种系统化利用 AI 能力来放大工程效能的方法论。

大多数人用 AI 的方式停留在”对话式”：遇到问题问一下 AI，写段代码让它补全。这就像有一台挖掘机，你只用它的铲子当凳子坐。

今天要讲的是：怎么真正开上这台挖掘机。

---

认知转变：三个层次的 AI 使用

L1：被动使用——“AI 帮我写代码”

特征：

• 遇到问题才想起用 AI
• 主要用自动补全和问答
• AI 输出直接复制粘贴，不怎么审查
• 没有任何定制化配置

这是大多数人的状态。AI 是一个”比 Google 方便一点”的搜索工具。

L2：主动指挥——“我指挥 AI 做事”

特征：

• 会写结构化 Prompt 引导 AI
• 用 AI 做 Code Review、写测试、生成文档
• 配置了一些 Rule 约束 AI 行为
• 开始用 AI 处理重复性工作

这一层已经比大多数人强了。你知道怎么让 AI 做事，但还是每次都要手动指挥。

L3：系统化驾驭——“我建了一套 AI 基础设施”

特征：

• Rule + Skill + Hook + Subagent 形成完整体系
• AI 自动守护代码质量（无需手动触发）
• 工程经验持续沉淀为 AI 可执行的知识
• 整个开发流程都有 AI 参与，从需求到部署

这一层的核心转变是：不再是”你用 AI”，而是”你的 AI 基础设施在替你工作”。

三层对比

维度	L1 被动使用	L2 主动指挥	L3 系统化驾驭
触发方式	遇到问题才用	主动发起	自动 + 主动
AI 角色	搜索替代品	执行助手	工程基础设施
知识沉淀	无	在对话中	在 Rule/Skill 中
一致性	低	中	高
团队效应	个人技巧	个人经验	团队资产
效能放大	1.2x	2-3x	5-10x

---

四大 AI 基础设施

要从 L2 跃升到 L3，核心是建立四层 AI 基础设施。这四层与上一篇讲的 Cursor 扩展机制一一对应，但这里从工程效能的角度来理解它们的组合。

第一层：Rules（约束层）

Rules 定义 AI 的行为边界和代码规范。它们是被动生效的——不需要你触发，只要条件匹配就自动应用。

工程效能价值：确保 AI 生成的代码从一开始就符合团队规范，减少 Code Review 的返工。

# .cursor/rules/typescript-standards.mdc
---
description: TypeScript 编码规范，写 TS 代码时自动应用
globs: "**/*.ts,**/*.tsx"
alwaysApply: false
---

# TypeScript Standards

- 禁止 `any`，用 `unknown` + 类型守卫
- async 函数必须有 try/catch
- 组件 props 定义 interface，不用 inline type
- 工具函数必须有 JSDoc + 示例

# .cursor/rules/git-commit.mdc
---
description: Git commit 规范
alwaysApply: true
---

# Commit Convention

- 使用 Conventional Commits: type(scope): description
- type: feat | fix | refactor | test | docs | chore
- description 用英文，不超过 72 字符
- body 说明 why，不只是 what

关键实践：

• 一个关注点一个 Rule，不要写超大 Rule
• globs 精确匹配，避免 alwaysApply: true 泛滥
• 定期 Review Rule 是否过时

第二层：Skills（能力层）

Skills 是 AI 的”技能包”——教它完成特定任务。详细开发方法见上一篇。

工程效能价值：把团队的隐性知识标准化，一次编写永久执行。

常见的 Skill 设置：

~/.cursor/skills/               # 个人技能
├── deploy-project/             # 项目部署
├── git-workflow/               # Git 工作流
└── tech-writing/               # 技术写作风格

.cursor/skills/                  # 项目技能
├── api-standards/              # API 设计规范
├── db-migration/               # 数据库迁移
└── incident-response/          # 故障响应流程

第三层：Hooks（守护层）

Hooks 是自动触发的守卫——在特定事件发生时自动执行，不需要你记得去做。

工程效能价值：把”别忘了做 X”变成”系统自动帮你做 X”。

{
  "version": 1,
  "hooks": {
    "afterFileEdit": [
      {
        "command": ".cursor/hooks/auto-format.sh",
        "matcher": "Write"
      }
    ],
    "beforeShellExecution": [
      {
        "command": ".cursor/hooks/safety-check.sh",
        "matcher": "rm|drop|delete|truncate",
        "failClosed": true
      }
    ]
  }
}

常见 Hook 场景：

事件	Hook	作用
afterFileEdit	auto-format	保存后自动格式化
beforeShellExecution	safety-check	拦截危险命令
afterShellExecution	audit-log	记录所有执行的命令
stop	summary-report	Agent 结束时生成总结

第四层：Subagents（专家层）

Subagents 是独立的 AI 专家——有自己的上下文和专业知识。

工程效能价值：复杂任务委派给专家，主对话保持轻量。

# .cursor/agents/security-reviewer.md
---
name: security-reviewer
description: >-
  安全审查专家。在涉及认证、授权、数据库操作、文件上传、
  用户输入处理时自动触发。
---

你是安全审查专家，重点关注：

## 审查清单
- SQL 注入：参数化查询 vs 字符串拼接
- XSS：用户输入是否经过转义
- CSRF：表单操作是否有 token
- 认证：JWT 是否正确验证
- 授权：是否检查了用户权限
- 文件上传：是否限制类型和大小
- 敏感数据：日志中是否有密钥/密码

## 输出格式
- CRITICAL: 必须修复，有安全漏洞
- WARNING: 建议修复，潜在风险
- INFO: 最佳实践建议

四层协同示例

假设你说了一句：“帮我加一个用户注册接口”。

你的指令 → "帮我加一个用户注册接口"
  │
  ▼
Rule 层自动约束：
  ├─ TypeScript 规范：函数式、有类型
  ├─ API 规范：RESTful、统一错误格式
  └─ Git 规范：commit 用 conventional 格式
  │
  ▼
Skill 层执行流程：
  └─ api-standards Skill：
     ├─ 生成 POST /api/users endpoint
     ├─ 定义 CreateUserDTO interface
     ├─ 实现 validation + error handling
     └─ 生成对应的 unit test
  │
  ▼
Hook 层自动守护：
  ├─ afterFileEdit → auto-format（自动格式化）
  └─ beforeShellExecution → safety-check（拦截危险命令）
  │
  ▼
Subagent 层专家审查：
  └─ security-reviewer 自动审查：
     ├─ 密码是否 hash 存储
     ├─ 输入是否做了校验
     └─ SQL 是否参数化

一句话指令，四层基础设施自动协作。这就是 L3 驾驭的威力。

---

驾驭模式一：AI 驱动的全链路开发

传统流程 vs AI 驱动流程

阶段	传统方式	AI 驱动方式
需求分析	手动拆解	AI 辅助拆解为技术任务
方案设计	手动写设计文档	AI 生成初版 + 你审查修改
编码	手敲 / 补全	AI 生成 + Rule 约束 + 你审查
Code Review	同事审查	AI 初审 + 同事终审
测试	手写	AI 生成测试用例 + 你补充边界
文档	事后补	AI 同步生成
Commit	手写 message	AI 根据 diff 生成
部署	手动执行	Skill 一键部署

一个实际的开发循环

1. 需求输入
   "需要一个文件上传功能，支持图片和 PDF，最大 10MB"

2. AI 拆解任务（你审查确认）
   ├─ 后端：upload API + 文件校验 + 存储
   ├─ 前端：拖拽上传组件 + 进度显示
   └─ 测试：上传成功 / 超大文件 / 非法类型

3. 逐项实现（Rule 自动约束代码规范）
   ├─ AI 生成代码 → 你审查 → 修改
   └─ 每次修改 → Hook 自动格式化

4. 安全审查（Subagent 自动介入）
   └─ security-reviewer 检查文件上传安全

5. 测试生成
   └─ AI 生成 unit + integration tests

6. 提交
   └─ AI 根据 diff 生成 commit message

7. 部署
   └─ deploy Skill 一键发布

关键：你的角色从”执行者”变成了”决策者和审查者”。AI 做执行，你把关质量。

---

驾驭模式二：质量守护自动化

痛点

代码质量靠人盯着，总有疏漏：

• Code Review 赶时间就走过场
• Lint 规则配了但总有人 // eslint-disable
• 安全漏洞在 Review 时不一定能发现
• 测试覆盖率达标但测试质量堪忧

AI 质量守护体系

建立三道防线：

第一道：编码时——Rule 实时约束

AI 在写代码的同时就已经受到 Rule 约束，从源头减少问题。

第二道：提交时——Hook 自动检查

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": ".cursor/hooks/pre-commit-check.sh",
        "matcher": "git commit"
      }
    ]
  }
}

pre-commit-check.sh 可以：

• 运行 Lint 检查
• 运行类型检查
• 检查是否有 console.log 残留
• 检查是否有 TODO 未处理

第三道：Review 时——AI Review Pipeline

在 CI 中接入 AI Code Review 工具（比如 ai-review-pipeline），对每个 PR 自动：

• 逐文件审查代码变更
• 生成审查报告（Critical / Warning / Info）
• 发现问题自动提交修复建议
• 生成 HTML 报告方便人工复审

# .github/workflows/ai-review.yml
name: AI Code Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx ai-review-pipeline --mode=review --format=html

三道防线层层把关：编码时预防 → 提交时拦截 → Review 时兜底。

---

驾驭模式三：知识飞轮

这是 L3 最核心的模式。它让你的 AI 基础设施越用越强。

飞轮循环

     ┌─────────────────────────┐
     │  1. 日常开发中发现模式    │
     │  "每次部署都要做这几步"   │
     └───────────┬─────────────┘
                 ▼
     ┌─────────────────────────┐
     │  2. 沉淀为 Rule/Skill   │
     │  写成 SKILL.md 或 .mdc  │
     └───────────┬─────────────┘
                 ▼
     ┌─────────────────────────┐
     │  3. AI 自动应用          │
     │  下次触发自动执行         │
     └───────────┬─────────────┘
                 ▼
     ┌─────────────────────────┐
     │  4. 使用中发现改进点      │
     │  "这个步骤还漏了 XX"     │
     └───────────┬─────────────┘
                 │
                 └──────→ 回到 1

实际案例

第一周：手动告诉 AI 部署命令

> ssh 到服务器，cd /var/www/blog，
> git pull，pnpm install，pnpm build

第二周：发现重复，写成 Skill

---
name: deploy-blog
description: Deploy blog to server...
---
# 部署流程
1. SSH to server
2. git pull
3. pnpm install --frozen-lockfile
4. pnpm build

第三周：用了几次发现问题

• 有时候 build 失败忘了回滚
• nvm 环境没加载导致 node 找不到

更新 Skill，加上 nvm 环境加载和错误处理。

第四周：加 Hook 自动守护

• 部署前自动检查本地是否有未提交的代码
• 部署后自动检查服务是否正常响应

两个月后：一套完善的部署体系

• 一句”部署博客”搞定一切
• 自动确认 → 自动执行 → 自动验证
• 新人入职直接用，零学习成本

这就是飞轮：使用 → 发现问题 → 优化 → 更好地使用。每一次使用都在让系统变得更好。

知识沉淀的时机

什么时候该把经验沉淀为 Rule/Skill？

信号	沉淀为
第二次跟 AI 说同样的话	Skill
AI 生成的代码每次都犯同一个错	Rule
某个检查总是忘记做	Hook
某类任务需要专门的知识	Subagent

经验法则：重复两次就沉淀。第一次是学习，第二次是信号，第三次就是浪费。

---

度量 AI 驾驭成熟度

团队 AI 成熟度模型

级别	特征	度量指标
L1 初始	个别人用 AI	AI 工具使用率 < 30%
L2 受管	有基础 Rule	Rule 覆盖率 > 50%，AI 代码采纳率 > 40%
L3 定义	Rule + Skill 体系化	Skill 数量 > 10，重复任务自动化率 > 70%
L4 量化	有度量有改进	AI 代码贡献率 > 50%，Bug 率下降 > 30%
L5 优化	知识飞轮运转	Skill 月更新率 > 20%，新人上手时间减半

关键度量指标

效率指标：

AI 代码采纳率 = AI 生成并被保留的代码行数 / 总新增代码行数

重复任务自动化率 = Skill 自动完成的任务数 / 总重复任务数

部署频率提升 = 当前部署频率 / 引入 AI 前部署频率

质量指标：

AI Review 发现率 = AI Review 发现的问题数 / 总问题数

Bug 逃逸率 = 线上 Bug 数 / 总提交数

代码规范符合率 = 通过 Rule 检查的文件比例

知识沉淀指标：

Skill 覆盖率 = 有对应 Skill 的工作流数 / 总工作流数

Rule 活跃度 = 最近 30 天被触发的 Rule 数 / 总 Rule 数

知识更新频率 = Rule/Skill 月更新次数

简单的度量脚本

import subprocess
import json
from pathlib import Path
from datetime import datetime, timedelta

def measure_ai_maturity(project_path: str):
    """度量项目的 AI 驾驭成熟度"""

    project = Path(project_path)
    cursor_dir = project / ".cursor"

    rules = list((cursor_dir / "rules").glob("*.mdc")) if (cursor_dir / "rules").exists() else []
    skills = list((cursor_dir / "skills").glob("*/SKILL.md")) if (cursor_dir / "skills").exists() else []
    hooks_file = cursor_dir / "hooks.json"
    agents = list((cursor_dir / "agents").glob("*.md")) if (cursor_dir / "agents").exists() else []

    hook_count = 0
    if hooks_file.exists():
        hooks_data = json.loads(hooks_file.read_text())
        for event_hooks in hooks_data.get("hooks", {}).values():
            hook_count += len(event_hooks)

    thirty_days_ago = datetime.now() - timedelta(days=30)

    recent_rules = sum(
        1 for r in rules
        if datetime.fromtimestamp(r.stat().st_mtime) > thirty_days_ago
    )

    report = {
        "rules": len(rules),
        "skills": len(skills),
        "hooks": hook_count,
        "subagents": len(agents),
        "total_components": len(rules) + len(skills) + hook_count + len(agents),
        "rules_updated_last_30d": recent_rules,
        "rule_activity_rate": f"{recent_rules / max(len(rules), 1) * 100:.0f}%",
    }

    total = report["total_components"]
    if total == 0:
        report["level"] = "L1 - 初始"
    elif total < 5:
        report["level"] = "L2 - 受管"
    elif total < 15:
        report["level"] = "L3 - 定义"
    elif total < 30:
        report["level"] = "L4 - 量化"
    else:
        report["level"] = "L5 - 优化"

    return report

if __name__ == "__main__":
    import sys
    path = sys.argv[1] if len(sys.argv) > 1 else "."
    result = measure_ai_maturity(path)
    print(json.dumps(result, indent=2, ensure_ascii=False))

运行：

python measure_maturity.py /path/to/project

输出：

{
  "rules": 8,
  "skills": 5,
  "hooks": 3,
  "subagents": 2,
  "total_components": 18,
  "rules_updated_last_30d": 3,
  "rule_activity_rate": "38%",
  "level": "L4 - 量化"
}

---

避坑：过度依赖 vs 有效驾驭

过度依赖的信号

信号	说明
AI 写的代码不看就合并	失去了质量把关
离开 AI 不会写代码了	基础能力退化
AI 出错不知道怎么修	丧失了理解力
所有决策都交给 AI	放弃了判断力

有效驾驭的原则

1. AI 做执行，你做决策

✅ 正确姿势：
- AI 生成代码 → 你审查逻辑、性能、安全
- AI 提出方案 → 你评估取舍
- AI 做 Review → 你做最终判断

❌ 错误姿势：
- AI 说什么就做什么
- AI 生成的代码不看直接用
- 遇到问题只会问 AI，不自己思考

2. 保持核心能力

即使有了 AI，这些能力不能丢：

• 架构设计：AI 不理解你的业务上下文
• 问题诊断：AI 经常在复杂 Bug 上绕弯路
• 代码审查：AI 可能引入微妙的逻辑错误
• 技术决策：AI 不知道团队的历史债务和约束

3. 渐进式信任

第一阶段：AI 做 → 你全部审查
第二阶段：AI 做 → 你抽查 + 自动测试
第三阶段：AI 做简单任务 → 自动化验证 → 你审查复杂任务

信任是逐步建立的。先在低风险任务上验证 AI 的可靠性，再逐步扩大授权范围。

---

团队落地路线图

Phase 1：基础建设（1-2 周）

目标：建立最基本的 AI 约束和能力。

.cursor/
├── rules/
│   ├── code-standards.mdc    # 编码规范
│   ├── git-conventions.mdc   # Git 规范
│   └── security-basics.mdc   # 基础安全规范
└── skills/
    └── deploy/               # 部署流程
        └── SKILL.md

关键动作：

• 梳理团队最核心的编码规范，转化为 Rule
• 把最高频的重复操作写成第一个 Skill
• 团队内部做一次 AI 工具使用培训

Phase 2：流程贯通（3-4 周）

目标：AI 参与开发全流程。

.cursor/
├── rules/
│   ├── code-standards.mdc
│   ├── git-conventions.mdc
│   ├── security-basics.mdc
│   ├── api-design.mdc        # API 设计规范
│   └── test-requirements.mdc  # 测试要求
├── skills/
│   ├── deploy/
│   ├── pr-workflow/            # PR 工作流
│   └── incident-response/      # 故障响应
├── hooks.json                  # 自动化守护
└── agents/
    └── security-reviewer.md    # 安全审查专家

关键动作：

• Hook 接入自动格式化和安全检查
• 建立 AI Code Review 流水线
• Subagent 覆盖安全审查

Phase 3：知识飞轮（持续）

目标：系统持续自我优化。

关键动作：

• 建立 Skill 更新机制（谁发现问题谁更新）
• 月度 Review 所有 Rule/Skill 的有效性
• 度量 AI 效能指标，持续优化
• 新人入职以 Skill 为导航，加速上手

---

从个人到团队：推广策略

先自己用起来

不要等团队统一决策。先在自己的开发中实践：

• 配几条 Rule
• 写两个 Skill
• 用起来，积累效果数据

用数据说话

"自从用了部署 Skill：
 - 部署时间从 15 分钟降到 2 分钟
 - 部署失败率从 20% 降到 0%
 - 新人第一天就能独立部署"

找同盟

找 1-2 个对 AI 感兴趣的同事一起搞。三个人的实践比一个人的布道有说服力。

提供脚手架

不要让每个人从零开始。提供：

• 模板 Rule 和 Skill
• 配置指南
• 常见问题 FAQ

降低上手门槛，才能形成普及。

---

总结

Harness Engineering 的核心是一句话：不要只”用”AI，要建一套系统来”驾驭”AI。

层级	做法	效果
L1 被动使用	遇到问题才问 AI	略有提效
L2 主动指挥	结构化 Prompt + 主动安排	明显提效
L3 系统化驾驭	Rule + Skill + Hook + Subagent	效能革命

关键行动：

1. 先建约束（Rule）：确保 AI 产出符合标准
2. 再建能力（Skill）：教 AI 做重复性工作
3. 加上守护（Hook）：自动化的质量关卡
4. 引入专家（Subagent）：复杂任务专人负责
5. 启动飞轮：使用 → 发现 → 沉淀 → 更好地使用

别等”完美方案”。今天就开始写第一条 Rule、第一个 Skill。用起来，你就能感受到从”AI 辅助”到”驾驭 AI”的质变。

---

本系列完整回顾：

编号	主题	一句话
01	RAG 文件解析	把 PDF/Word/Excel 变成 AI 能理解的文本
02	文档切片策略	固定 / 递归 / 语义三种切片对比
03	大文件上传	分片上传 + 异步处理全链路
04	Embedding 选型	OpenAI / BGE / Jina 怎么选
05	向量数据库选型	Chroma / pgvector / Pinecone / Milvus
06	RAG 检索优化	混合检索 + 重排序 + 多路召回
07	意图识别	关键词 / LLM / Embedding 三级分类
08	结构化输出	让 AI 稳定输出 JSON
09	AI 缓存	精确 + 语义两级缓存
10	Token 管理	上下文窗口和成本控制
11	大模型微调	LoRA 到部署上线
12	Cursor Skill	把工程经验变成 AI 技能
13	Harness Engineering	驾驭 AI 的工程效能革命（本篇）

每篇都是独立可读的深度专题，串起来就是一套 AI 应用工程知识体系。系列持续更新中。

---

讨论话题：你的团队在 AI 驾驭成熟度上处于哪一层？有哪些 AI 基础设施是你想建但还没建的？评论区聊聊。